FHIR pour la persistance des données cliniques, implications et limites d’un choix controversé

Quelle est l’efficacité d’utiliser le modèle de données FHIR pour stocker et rechercher des données cliniques ? Est-ce un choix raisonné ou un raccourci pour simplifier le problème ?

FHIR est un standard, comme l’indique la lettre I – Interopérabilité – de l’acronyme, pour l’échange de données de santé qui sont exposées comme des ressources (pour en savoir plus, voir ici). Dans la conception du nouveau dossier de santé électronique, ainsi que dans les appels d’offres régionaux de télémédecine, le FHIR a été indiqué non seulement pour assurer l’interopérabilité avec d’autres systèmes, mais aussi comme format de persistance des informations. Autrement dit, il a été décidé d’adopter le FHIR pour créer le Health Data Ecosystem (en FSE 2.0) ou le Clinical Data Repository (CDR) de la télémédecine.

L’équation du serveur CDR égal FHIR a également été utilisée comme modèle dans de nombreux projets de dossier médical électronique régional-entreprise ou dans le cas de nouveaux systèmes territoriaux. La question que nous devons nous poser est de savoir si ce choix est le plus approprié pour le stockage et la recherche de données cliniques. Avant de répondre à la question, il est cependant nécessaire de définir le contexte et la finalité pour laquelle on doit/vouloir gérer des données cliniques structurées et non structurées.

Le contexte

Si le contexte comprend plusieurs sources de données pour les mêmes classes, par exemple une région où il existe plusieurs systèmes de laboratoire (SIL) ou dossiers médicaux électroniques (CCE), il devient essentiel de pouvoir organiser et agréger les informations afin, par exemple , pouvoir afficher graphiquement l’évolution de la glycémie (qui peut être mesurée de différentes manières et avec différentes unités de mesure) ou de la pression artérielle.

Que voulons-nous faire avec les données

Si l’on veut utiliser les données pour enrichir les systèmes cliniques et les doter de fonctions intelligentes (voir par exemple ici) il faut leur associer une signification médicale précise, opération qui nécessite une compréhension exacte des informations qu’elles expriment. Cette tâche est désormais effectuée par des médecins qui, en lisant les données, sont capables de les interpréter, de les corréler et de les utiliser dans leur processus décisionnel. Si l’on veut implémenter ces logiques dans un logiciel clinique, il est indispensable d’attribuer un sens précis aux données.

L’importance de la sémantique

Pour utiliser les données dans les deux domaines décrits ci-dessus, il ne suffit pas de fixer un format de données, c’est-à-dire la syntaxe, mais il faut définir une sémantique qui exprime le sens que les données expriment et qui, en médecine, peut être très large. Prenons l’exemple de la tension artérielle. Celle-ci est exprimée en deux mesures, la diastolique (appelée aussi minimum) et la systolique (maximale). La pression peut être mesurée dans différentes parties du corps, au repos ou en mouvement, dans différentes positions (par exemple assis ou couché), avec différents dispositifs médicaux et méthodes. Dans certains cas, les deux mesures peuvent être suffisantes alors que dans d’autres, par exemple dans le cas d’une forme instable d’hypertension, les autres informations peuvent également être pertinentes.

Le modèle de données de FHIR

Le modèle de données FHIR est composé de 157 ressources réparties en 5 niveaux logiques comprenant chacun un ou plusieurs modules.

En principe, les ressources sont conçues pour être échangées entre systèmes, plutôt que comme un format de stockage de base de données. Une conséquence pratique de cela est que, d’une manière ou d’une autre, les ressources sont fortement dénormalisées, de sorte que les échanges granulaires sont assez indépendants. Chaque ressource gère un type de données, par exemple, les données démographiques des patients se trouvent uniquement dans la ressource Patient, mais au niveau clinique, il peut y avoir des chevauchements (par exemple, un problème de santé exprimé sous la forme d’une observation plutôt que d’une condition).

Le Observation

Une des ressources les plus utilisées est l’Observation qui peut exprimer :

• Signes vitaux tels que le poids corporel, la tension artérielle et la température
• Données de laboratoire telles que la glycémie ou une mesure GFR
• Résultats d’imagerie tels que la densité osseuse ou les mesures fœtales
• Signes cliniques tels que tension abdominale
• Mesures de dispositifs médicaux telles que données d’électrocardiogramme ou d’oxymétrie de pouls
• Paramètres de l’appareil, tels que les paramètres du ventilateur mécanique.
• Outils d’évaluation clinique tels que APGAR ou Glasgow Coma Score
• Caractéristiques personnelles telles que la couleur des yeux
• Antécédents sociaux, tels que la consommation de tabac, le soutien familial ou l’état cognitif.
• Caractéristiques clés telles que le statut de grossesse ou le certificat de décès
• Tests de qualité des produits tels que le pH, le dosage, les limites microbiennes, etc. sur le produit et la substance

Les données exprimées par Observation sont identifiées par un code et un système de codage (par exemple LOINC). La structure des ressources comprend diverses données, notamment la date et l’heure, la partie du corps observée, la méthode, l’échantillon, l’appareil, les valeurs de référence. Le sens sémantique est donc laissé au codage et est intégré par les données présentes dans la structure, avec le risque d’éventuelles incohérences avec ce qui est défini par le système de codage (par exemple un code LOINC qui fait référence à un échantillon différent de celui exprimé dans l”Observation).

Dans l’écosystème des données de santé, LOINC est mentionné comme système de codage (déjà utilisé dans l’ESF actuel) et SNOMED est mentionné, qui n’a cependant pas été officiellement adopté par notre pays.

Dans le prochain épisode nous verrons en détail comment LOINC est structuré et quels problèmes il présente.

1 – Continuer