openEHR vs FHIR pour la persistance des données

Pourquoi FHIR n’est pas le meilleur choix pour stocker des données cliniques.

Dans un article précédent, j’ai illustré pourquoi les soins de santé ont besoin de plateformes de données ouvertes et indiqué comment le meilleur choix pour la persistance des données cliniques est openEHR plutôt que FHIR qui est actuellement la solution la plus populaire en Italie.

Dans cet article je vais vous expliquer les différences entre ces deux standards qui, je me souviens, ont été créés dans des buts différents et qui peuvent très bien coexister.

openEHR repose sur un modèle de référence très abstrait et simple sur lequel sont construits des archétypes, un modèle de données sémantique qui définit un concept clinique, par exemple la tension artérielle, l’indice de masse corporelle, etc. Chaque archétype représente un ensemble de données maximal pour un cas d’utilisation universel.

Grâce aux modèles, il est possible de créer, en combinant un ou plusieurs archétypes, des définitions de contenu, comme un « rapport radiologique », une lettre de sortie d’hôpital, un résumé patient. Il existe de nombreuses bases de connaissances contenant des archétypes et des modèles que vous pouvez adopter tels quels, modifier selon vos besoins ou en créer de nouveaux. Il existe à ce jour plus de 880 archétypes actifs.

FHIR, quant à lui, s’appuie sur un grand nombre de ressources, chacune décrivant un concept ou une action clinique. Chaque ressource possède sa propre structure qui est fixe et non modifiable. Il est possible d’ajouter des informations à l’aide d’extensions qui ne sont cependant pas standards. La ressource Observation permet d’exprimer une mesure de pression, une évaluation de la douleur ou un diagnostic qui peut cependant également être exprimé avec la ressource Condition. Ce dernier est un exemple d’ambiguïté sur la façon d’associer certains concepts aux ressources (par exemple certains CCE expriment des diagnostics avec la ressource Observation, d’autres avec Condition). Il existe à ce jour environ 150 ressources publiées, mais seule une partie est « normative », c’est-à-dire qu’elle peut être considérée comme définitive.

Les ressources de ce type ont une structure générique pour exprimer, également à travers l’utilisation de vocabulaires ou de systèmes de codage, des concepts qui peuvent être très différents les uns des autres. FHIR ne prend pas en charge nativement l’héritage de classe ou la gestion multi-types. Il n’est pas facile de codifier des concepts qui ne sont pas structurés nativement.

FHIR n’a pas d’analogue de modèle ; les éventuelles règles et contraintes sur l’utilisation des données dans des cas d’utilisation spécifiques doivent être définies en dehors de la norme. La structure des ressources FHIR crée également des problèmes de compatibilité descendante car elles varient.

openEHR dispose d’un véritable langage de requête de données, AQL, qui est un mélange de SQL et de XQuery/XPath et qui fonctionne sur des archétypes et non sur le modèle de données physique avec lequel ils sont stockés. FHIR, en revanche, a des capacités de requête limitées.

Il existe également des problèmes de performances possibles car la quantité de données gérées dans les référentiels FHIR augmente en raison de la structure même avec laquelle elles sont stockées.

Ceux que j’ai énumérés ne sont que quelques-uns des aspects qui doivent être examinés en profondeur avant de choisir la manière de stocker les données cliniques.