FHIR, openEHR et OMOP : comparaison

Quel rôle jouent HL7 FHIR, openEHR et OMOP CDM côte à côte, et que doit en connaître un hôpital flamand à la lumière de l'EHDS (Espace européen des données de santé) ? Comme cadre, cette page utilise les trois domaines de données du guide d'implémentation HL7 FHIR-to-OMOP : soins cliniques et administration, échange de données et analyse longitudinale ^[1]. Ce guide d'implémentation considère FHIR et OMOP comme complémentaires et non comme concurrents ^[1]. Un panel d'experts aboutit à la même conclusion pour openEHR, ISO 13606 et FHIR : chacun est utile pour un objectif propre et ils sont utilisables ensemble^[2].

Selon un article du JMIR (2025), FHIR et OMOP utilisent les mêmes terminologies internationales, et OMOP convient mieux à l'analyse qu'à l'échange opérationnel^[22]. Dans les profils FHIR belges, SNOMED CT est le codage privilégié^[23], et dans le guide d'implémentation FHIR belge pour les résultats de laboratoire (v1.0.0, trial use), la plupart des mesures de laboratoire courantes doivent être codées en LOINC selon le sous-ensemble du SPF^[24]. La classification d'enregistrement ICD-10-BE se situe en dehors de ces trois modèles ; dans OMOP, les codes ICD sont mappés, comme codes sources, sur des concepts standard SNOMED^[17].

Mappings et perte d'information

• FHIR → OMOP : le HL7 Vulcan FHIR-to-OMOP IG v1.0.0 (Informative, FHIR R5) ne traite que ce sens, pour un noyau IPA ainsi que Encounter et Procedure (US Core), avec le CDM v5.4 pour cible^[1]. Un ballot 2.0.0 est en ligne comme continuous build (projet)^[25]. Ce guide d'implémentation indique que la transformation ne peut pas être sans perte et distingue les pertes de fidélité, d'information, de relations et d'exactitude^[1].
• openEHR ↔ FHIR : un guide d'implémentation qui mappe les types de données openEHR sur les types de données FHIR est en développement (R5 ; sur GitHub dans l'organisation openehr-fhir, configuré comme IG HL7 FHIR avec publisher HL7 FHIR Infrastructure ; une publication formelle de HL7 n'a pas été constatée)^[26]. FHIRconnect est une proposition de recherche (preprint 2025) qui a mappé 24 archétypes vers 15 profils FHIR^[27].
• openEHR ↔ OMOP : aucune norme de mapping officielle trouvée (lacune).

• Dates d'application : le règlement est d'application à partir du 26 mars 2027^[28]. Les dispositions sur l'enregistrement et l'échange (art. 3-15) s'appliquent à partir du 26 mars 2029 pour le résumé patient, la e-prescription et la e-délivrance, et à partir du 26 mars 2031 pour l'imagerie, les résultats de tests et les rapports de sortie^[28]. Le chapitre IV (utilisation secondaire) s'applique à partir du 26 mars 2029^[28], certaines catégories de l'art. 51(1) seulement à partir du 26 mars 2031^[28].
• Oui (avec ces dates d'application) : la Commission fixe pour le 26 mars 2027 les spécifications techniques du EEHRxF^[28] ; les prestataires de soins devront enregistrer des données prioritaires dans un système de DME^[28] ; les détenteurs de données devront notamment mettre des données de DME à disposition pour l'utilisation secondaire^[28].
• Orientation FHIR : HL7 Europe a publié des guides d'implémentation FHIR Base et Core à l'appui de l'EHDS ^[29] ; la Belgique plaide pour une seule norme FHIR européenne par type de message^[30]. Il s'agit d'une position belge, pas d'une décision de l'UE.
• Non (trouvé) : fin 2023, un panel d'experts affirmait, à propos de la proposition d'EHDS de l'époque, que l'EHDS ne règle pas de standards concrets^[2] ; le règlement définitif délègue bien les spécifications techniques de l'EEHRxF à des actes d'exécution^[28], qui peuvent contenir des standards concrets (interprétation). Dans le projet pilote DonnéesDeSanté@UE, OMOP était une option, pas une obligation^[31] ; un cadre académique cite OMOP comme standard, mais c'est une proposition^[22]. Pour openEHR, aucune référence à l'EHDS n'a été trouvée (lacune).

• Obligation (UE, future) : enregistrer des données prioritaires dans un système de DME et les échanger dans l'EEHRxF, par phases à partir du 26 mars 2029 (résumé patient, e-prescription, e-délivrance) et du 26 mars 2031 (imagerie, résultats de tests, rapports de sortie)^[28]. Le format technique sera fixé par des actes d'exécution ; que ce soit FHIR n'est pas confirmé.
• Choix politique Belgique : des champs de l'EEHRxF sont aussi utilisés dans les CareSets belges^[30].
• Réseau : il existe un nœud OHDSI belge, issu de la communauté EHDEN^[20]. Recommandation : envisager une participation OMOP via EHDEN ou le nœud OHDSI belge en cas de question de recherche concrète.

• Recommandation : voir Conclusion.

• Recommandation : traiter les profils FHIR comme couche d'échange, suivre les actes d'exécution relatifs à l'EEHRxF et évaluer séparément openEHR et OMOP comme choix pour le stockage clinique et la recherche. Conserver les données sources comme référence, car la conversion vers OMOP peut faire perdre de l'information.

Conditions d'implémentation et limites

Les guides d'implémentation belges sont en R4, alors que le guide d'implémentation FHIR-to-OMOP repose sur R5 et US Core^[19][1] ; une application directe demande donc une traduction. Pour l'utilisation de SNOMED CT dans les profils core-clinical belges, une licence Affiliate est nécessaire^[32].

• Le guide d'implémentation FHIR-to-OMOP vise le CDM v5.4, alors qu'OHDSI cite v5.5 comme version actuelle ; v5.5 est compatible avec v5.4, il s'agit donc d'un décalage dans le temps^[1][5][14].
• Les actes d'exécution relatifs à l'EEHRxF ne sont attendus que début 2027^[29] ; savoir s'ils prescriront FHIR de manière normative reste ouvert.
• L'usage d'openEHR en Belgique n'a pas été trouvé.
• L'affirmation selon laquelle l'EHDS ne règle pas de standards concrets^[2] date de décembre 2023 et porte sur la proposition de l'époque ; le règlement définitif délègue les spécifications techniques à des actes d'exécution^[28]. Les deux affirmations ne sont pas contradictoires, mais la première est datée.