Alternatives au FHIR pour la persistance des données cliniques

Voyons quels choix vous pouvez envisager pour stocker et gérer les données de santé.

Après avoir expliqué le modèle de données du FHIR dans le premier article et discuté des limites des systèmes de codage préférés au niveau national dans le deuxième article, voyons quelles sont les alternatives pour la persistance des données cliniques. Il est très important, lors du choix de la norme à utiliser, de définir clairement les finalités pour lesquelles les données doivent être gérées, par exemple pour soutenir la pratique clinique ou à des fins de recherche et d’analyses épidémiologiques.

openEHR

openEHR est une spécification standard ouverte qui décrit la gestion et le stockage, la récupération et l’échange de données de santé dans les dossiers de santé électroniques (DSE) avec une approche longitudinale »une vie“, indépendant du fournisseur et centré sur la personne.

Les spécifications openEHR sont maintenues par la fondation openEHR, une fondation à but non lucratif qui soutient la recherche, le développement et la mise en œuvre des dossiers de santé électroniques openEHR. La spécification est basée sur une combinaison de 15 ans de recherche et développement européens et australiens sur le DSE et de nouveaux paradigmes, y compris ce qui est devenu la méthodologie d’archétype pour la spécification de contenu.

openEHR repose sur quatre éléments clés :

• les modèles d’information (alias “Modèle de référence”);
• le formalisme des archétypes
• le langage d’interrogation des archétypes ;
• Les modèles de service / API.

Les deux premiers permettent le développement d’« archétypes » et de « modèles », qui sont des modèles formels de contenu clinique qui constituent une couche de normes de facto à part entière. Le langage de requête vous permet de créer des requêtes basées sur des archétypes de base de données, plutôt que sur les schémas physiques, dissociant ainsi les requêtes des détails physiques de la persistance. Les modèles de service définissent l’accès aux principaux services principaux, y compris le service EHR et le service de démographie, tandis qu’un ensemble croissant d’API légères basées sur REST et des chemins d’archétype sont utilisés pour l’accès aux applications.

Modèle de référence

L’ensemble de modèles d’information définit la sémantique invariante des modèles de dossier de santé électronique (DSE), d’extraction de DSE et de données démographiques, ainsi que les types de données, les structures de données et les identifiants.

Les entités clés incluent les classes ENTRY, dont les sous-types incluent OBSERVATION, EVALUATION, INSTRUCTION, ACTION et ADMIN_ENTRY, ainsi que l’Instruction State Machine, une machine d’état qui définit un modèle standard du cycle de vie des interventions, y compris les médicaments, les chirurgies et autres thérapies .

Archétypes et modèles

openEHR dissocie les spécificités des informations cliniques du modèle d’information (également appelé « modèle de référence »). Les contenus cliniques sont définis par deux types d’artefacts extérieurs au modèle d’information.

Le premier, appelé « archétype », permet l’expression formelle de données ponctuelles et de groupes de données réutilisables dans différents contextes comme par exemple la tension artérielle ou le sodium mesuré dans le sérum. Une collection d’archétypes compose une « bibliothèque » de définitions de contenu réutilisables. Les archétypes sont exprimés avec ADL – Archetype Definition Language, une spécification publique qui, avec son homologue AOM – Archetype Object Model – est à la base de la norme CEN et ISO « Archetype Definition Language » (norme ISO 13606-2). Les archétypes sont gérés indépendamment des implémentations logicielles et des infrastructures, par des groupes de cliniciens.

Le deuxième type d’artefact sont des modèles qui sont utilisés pour représenter un ensemble de données spécifiques à un cas d’utilisation, tels que les éléments qui composent la lettre de sortie d’un patient ou un rapport de radiologie. Les modèles incluent des éléments d’un ou plusieurs archétypes et sont généralement créés par des développeurs de logiciels et des analystes cliniques.

AQL, l’archétype du langage de requête

Archetype Query Language (AQL) est un langage de requête déclaratif développé spécifiquement pour rechercher et récupérer des données dans des bases de données basées sur des archétypes. Les exemples utilisés dans cette spécification se réfèrent principalement au modèle de référence (RM) et aux archétypes cliniques openEHR, mais la syntaxe est indépendante du modèle d’information, de l’application, du langage de programmation, de l’environnement système et du modèle de stockage.

Gestionnaire des connaissances cliniques

Le Clinical Knowledge Manager est un outil open source collaboratif qui permet de partager, discuter et approuver les archétypes et leurs structures au sein de la communauté openEHR. Il existe plusieurs logiciels remplissant ce rôle qui peuvent être téléchargés et installés gratuitement.

openEHR est utilisé par la National e-Health Transition Authority australienne, le NHS Health and Social Care Information Centre (HSCIC) britannique, l’organisation norvégienne Nasjonal IKT et le ministère slovène de la Santé. Il a également été choisi comme modèle de données pour le dossier de santé électronique du Brésil. Ensuite, il existe des solutions commerciales dans le monde basées sur openEHR.

Modèle de données commun OMOP

L’Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM) est une norme utilisée par l’association Observational Health Data Sciences and Informatics (OHDSI) dans la recherche scientifique pour représenter le format et le contenu des données d’observation, afin que les applications puissent être utilisées, outils et méthodes standardisés pour différents ensembles de données cliniques. OHDSI gère une bibliothèque open source d’outils analytiques pour la recherche et la mesure des performances à l’aide d’OMOP CDM. Les requêtes en langage structuré standardisé (SQL) sont partagées dans un référentiel open source commun, et une documentation détaillée des données est disponible gratuitement en ligne.

La structure de données centrée sur le patient d’OMOP CDM comprend des vocabulaires OHDSI standardisés qui définissent les termes médicaux utilisés dans divers domaines cliniques et est gérée à l’aide de bases de données SQL relationnelles. À l’aide de requêtes, vous pouvez effectuer des analyses standardisées qui exploitent la base de connaissances OHDSI pour construire des phénotypes d’exposition et de résultat et d’autres caractéristiques pour la caractérisation, l’estimation des effets au niveau de la population et les études de prédiction au niveau du patient.

La version actuelle du CDM est la 5.4 et est utilisée par de nombreuses institutions de recherche dans le monde, y compris en Italie. Sa nature le rend particulièrement efficace dans la recherche scientifique, mais il est moins adapté à la gestion des données pour la pratique clinique.

Autres modèles cliniques

Plusieurs fabricants de solutions cliniques ont développé leurs propres modèles cliniques qui interagissent via des API ou des normes populaires telles que FHIR. Or, l’adoption d’un modèle propriétaire détermine un lock-in du fournisseur avec toutes les conséquences qui en découlent.

3 – bien