HL7 et FHIR expliqués aux directions d'établissements de soins

HL7 et FHIR : de quoi parle-t-on exactement ?

HL7 International est une organisation de normalisation ; HL7 v2 et FHIR sont deux de ses normes, pas deux produits. La messagerie HL7 v2 est le langage historique des échanges entre systèmes hospitaliers. FHIR, plus récent, est présenté par eHealth Suisse comme une « norme internationale d'interopérabilité pour l'échange de données médicales » qui « utilise des technologies web modernes comme les REST API et les formats de données JSON, XML et Turtle (RDF) ».

Les versions comptent autant que le nom. FHIR R4 porte le numéro 4.0.1, publiée le 30 octobre 2019, avec un statut mixte : une partie normative, une partie en essai (Standard for Trial Use). La version courante, FHIR R5 (5.0.0), date de mars 2023. La spécification paraît sous licence ouverte CC0 : votre responsable informatique peut la lire gratuitement et vérifier ce qu'annonce un fournisseur.

FHIR ne remplace pas pour autant la génération précédente : « FHIR complète les anciennes normes HL7 V2 et V3, mais ne les remplace pas complètement, puisque de nombreux systèmes continuent à les utiliser activement », écrit eHealth Suisse.

HL7 v2 et FHIR : la différence qui change quelque chose pour vous

HL7 v2 fonctionne par messages déclenchés par un événement. Une admission, un transfert ou une sortie produisent un message ADT ; un résultat de laboratoire produit un message ORU. Le chapitre 1 de la version 2.7 en énonce l'objectif : des standards d'échange qui éliminent ou réduisent substantiellement la programmation d'interfaces sur mesure.

Le même chapitre pose la limite, à retenir avant toute négociation. Seuls sont obligatoires les champs nécessaires à la logique des messages ; beaucoup d'autres sont spécifiés, mais laissés optionnels. Le texte en tire lui-même la conséquence : HL7 v2.7 ne peut pas être une véritable norme d'interface « plug and play », et les différences d'un site à l'autre exigeront très probablement des accords négociés site par site.

FHIR raisonne autrement : il découpe l'information en ressources (Patient, Observation, DocumentReference) qu'un système va chercher par une requête web. C'est plus simple à tester et à documenter. Mais l'optionnalité ne disparaît pas : elle se déplace dans des « profils », qui précisent pour un pays ou un cas d'usage quels champs sont exigés. D'où une règle pratique : faire préciser la version exacte, car deux logiciels qui « font du FHIR » dans des versions différentes ne se parlent pas sans adaptation.

Ce que l'interopérabilité apporte vraiment à un établissement

eHealth Suisse définit l'interopérabilité comme « la capacité de deux systèmes informatiques à échanger des données, à les interpréter correctement et à les réutiliser sans intervention humaine ».

La même source distingue cinq niveaux : politique et droit, organisation, technique, syntaxe, sémantique. Cette liste explique pourquoi tant de projets d'interface déçoivent. Le niveau technique — faire circuler les données — est le plus simple, et le seul que montre une démonstration commerciale. Le sémantique et l'organisationnel décident du résultat : si « allergie » ou « chute » ne sont pas codés de la même manière des deux côtés, l'échange fonctionne et l'information clinique se perd quand même.

Le gain concret tient en peu de mots : données d'admission saisies une seule fois, résultats de laboratoire arrivant dans le dossier au lieu d'un fax, rapport de transfert lisible à la sortie de l'hôpital. Rien de spectaculaire — du temps soignant rendu aux soins.

Le lien avec le DEP suisse, et ce que FHIR n'y fait pas

La loi fédérale sur le dossier électronique du patient (LDEP) est en vigueur depuis le 15 avril 2017. Selon l'OFSP, l'affiliation au DEP est une obligation légale pour les établissements stationnaires qui facturent à la charge de l'assurance obligatoire des soins : hôpitaux, cliniques de réadaptation et psychiatriques, EMS et maisons de naissance ; depuis le 1er janvier 2022, elle vaut aussi pour les médecins nouvellement admis. Elle reste facultative pour les autres professionnels de l'ambulatoire — dont les services d'aide et de soins à domicile — et pour la population.

Techniquement, le DEP ne repose pas d'abord sur FHIR. Ses spécifications, annexées à l'ordonnance du DFI sur le dossier électronique du patient (ODEP-DFI), imposent des profils IHE : CH:XDS pour le partage de documents, CH:XUA pour l'authentification, CH:PIXV3 et CH:PDQV3 pour l'identification des patients, CH:ATNA pour la journalisation. L'accès dit mobile, lui, s'appuie sur FHIR R4, via le guide d'implémentation CH EPR FHIR d'eHealth Suisse (MHD, PDQm, PIXm, IUA).

Pour la suite, la direction est annoncée : « pour l'élaboration de nouveaux formats d'échange, eHealth Suisse mise sur la norme HL7 FHIR ». La conséquence : un logiciel qui « fait du FHIR » n'est pas pour autant raccordé au DEP. Le raccordement suppose d'implémenter soi-même les interfaces du DEP ou de passer par un connecteur — eHealth Suisse met à disposition son connecteur open source HUSKY — et, dans tous les cas, une affiliation à une communauté ou à une communauté de référence certifiée.

Du DEP au DES : ce que prévoit la LDSan

Le Conseil fédéral a transmis au Parlement, le 5 novembre 2025, le message relatif à une nouvelle loi fédérale sur le dossier électronique de santé (LDSan), appelée à remplacer la LDEP. Le Conseil national l'a adoptée le 14 septembre 2026 par 134 voix contre 53 et 10 abstentions ; le dossier passe au Conseil des États.

Ce que prévoit le projet, selon l'OFSP : un DES ouvert automatiquement et gratuitement pour toute personne résidant en Suisse, qui peut s'y opposer ; une obligation de raccordement étendue à tous les fournisseurs de prestations facturant à la charge de l'assurance obligatoire des soins ; la Confédération exploitant le système technique, les cantons en assumant les coûts d'exploitation. Le nouveau système pourrait être mis en service « au plus tôt en 2030 ». En parallèle court le programme national DigiSanté (2025-2034).

Le terrain bouge plus vite que la loi. Le 25 juin 2026, eHealth Suisse annonçait que Post Sanela cesse ses activités de fournisseur de plateforme et de communauté de référence DEP d'ici la fin 2026 ; un changement de fournisseur évite une interruption de la disponibilité des données. Le 21 août 2026, la faîtière ARTISET relevait que la CSSS-N laissait en suspens la question de l'obligation de se raccorder, et recommandait en septembre de la lever pour les EMS jusqu'à l'introduction du DES.

Les questions à poser à un fournisseur qui annonce « HL7/FHIR »

Ces questions ne demandent aucune compétence technique, seulement des réponses écrites. Une réponse vague est déjà une réponse.

Une dimension traverse toutes les autres : la protection des données. Depuis le 1er septembre 2023, la loi fédérale révisée sur la protection des données s'applique. Les données de santé y sont des données sensibles au sens de l'art. 5 let. c ch. 2 LPD, et le PFPDT rappelle qu'un thérapeute ne peut en principe pas les communiquer à des tiers sans l'accord de la personne concernée, le secret professionnel de l'art. 321 CP s'ajoutant à la protection des données.

• Quelle norme et quelle version, précisément : HL7 v2 dans quelle version, FHIR R4 (4.0.1) ou R5 (5.0.0) ?
• Quels messages ou quelles ressources sont réellement implémentés : ADT, ORU, MDM d'un côté ; Patient, Observation, DocumentReference de l'autre ?
• Dans quel sens circulent les données : lecture, écriture, ou les deux ? Beaucoup d'intégrations ne font que recevoir.
• Existe-t-il un profil de conformité écrit, champ par champ ? HL7 v2 laissant la plupart des champs optionnels, cet accord site par site est le vrai contrat d'interface.
• A-t-il testé au Digital Health Projectathon d'eHealth Suisse, de l'OFSP et d'IHE Suisse ? Test volontaire, pas certification, mais la participation se vérifie.
• Pour le DEP : implémente-t-il lui-même les profils IHE exigés ou passe-t-il par un connecteur, et avec quelle communauté ?
• Qui paie l'interface, et qui la maintient quand le logiciel hospitalier change de version ? C'est là que se logent les coûts oubliés.

Transparence sur l'auteur de cet article

Cet article est publié par CareBond, plateforme de communication et de coordination hébergée en Suisse, chez Infomaniak à Genève, conçue dès l'architecture pour le RGPD et la nLPD, avec un journal d'audit immuable et une intégration HL7/FHIR (serveur FHIR R4, réception de messages HL7 v2 par HTTPS). Ce n'est ni une communauté de référence ni un fournisseur de plateforme DEP, et l'éditeur ne détient aucune certification : les questions ci-dessus valent pour lui comme pour les autres.

Sources

• OFSP — LDEP : la loi qui régit le DEP (en vigueur depuis le 15 avril 2017)
• OFSP — Dossier électronique du patient : obligation d'affiliation des établissements stationnaires et des médecins nouvellement admis depuis le 1er janvier 2022
• OFSP — LDSan : DES ouvert automatiquement avec droit d'opposition, obligation étendue aux fournisseurs facturant à l'AOS, mise en service au plus tôt en 2030
• OFSP — DES : jalons du projet et actualités (message du 5 novembre 2025 ; Conseil national, 14 septembre 2026, 134 voix contre 53 et 10 abstentions)
• OFSP — DigiSanté, programme national 2025-2034
• dossierpatient.ch — Le DEP en bref : communautés et communautés de référence, participation obligatoire et facultative
• eHealth Suisse — Normes et interopérabilité : définition et cinq niveaux
• eHealth Suisse — Normes techniques et syntaxiques : définition de FHIR, REST API, JSON/XML/Turtle, complémentarité avec HL7 V2 et V3
• eHealth Suisse — Formats d'échange nationaux : « eHealth Suisse mise sur la norme HL7 FHIR »
• eHealth Suisse — Spécifications du DEP : profils IHE (CH:XDS, CH:XUA, CH:PIXV3, CH:PDQV3, CH:ATNA) annexés à l'ODEP-DFI
• eHealth Suisse — Intégration du DEP dans un système primaire : connecteurs et connecteur open source HUSKY
• eHealth Suisse — Post Sanela se retire du DEP d'ici la fin 2026 (annonce du 25 juin 2026)
• eHealth Suisse — Digital Health Projectathon 2026 : événement de test organisé avec l'OFSP et IHE Suisse, sans certification
• HL7 International — FHIR R4, version 4.0.1, publiée le 30 octobre 2019, statut mixte normatif/STU
• HL7 International — Spécification FHIR courante : R5, version 5.0.0 (mars 2023), licence CC0
• HL7 Version 2.7, chapitre 1 : objectif de la norme, champs optionnels, absence de « plug and play » et accords négociés site par site
• eHealth Suisse — CH EPR FHIR Implementation Guide (FHIR R4 ; MHD, PDQm, PIXm, IUA)
• PFPDT — Rôle du PFPDT : entrée en vigueur de la nLPD le 1er septembre 2023
• PFPDT — Données patient et communication : données de santé comme données sensibles (art. 5 let. c ch. 2 LPD) et secret professionnel (art. 321 CP)
• ARTISET — Prises de position : « DEP : la CSSS-N laisse en suspens la question centrale de l'obligation de se raccorder » (21 août 2026)
• ARTISET — Session d'automne 2026 : recommandation de lever l'obligation de rattachement pour les EMS jusqu'à l'introduction du DES (9 septembre 2026)