Ressources d'interopérabilité des soins de santé rapides (FHIR) expliquées

Définition du FHIR

La spécification FHIR (ressources d'interopérabilité des soins de santé rapides) est une norme permettant l'échange électronique d'informations sur les soins de santé. Les dossiers de santé sont de plus en plus numérisés. À mesure que les patients évoluent dans l’écosystème de la santé, leurs dossiers de santé électroniques doivent être disponibles, accessibles à toute personne et compréhensibles. En outre, pour prendre en charge l'aide à la décision clinique automatisée et d'autres traitements sur machine, les données doivent être structurées et normalisées.

FHIR vise à simplifier la mise en œuvre sans sacrifier l'intégrité de l'information. Il exploite les modèles logiques et théoriques existants pour fournir un mécanisme cohérent, facile à mettre en œuvre et rigoureux pour l'échange de données entre des applications de soins de santé.

Les solutions FHIR sont construites à partir d'un ensemble de composants modulaires appelés «Ressources». Ces ressources peuvent facilement être assemblées dans des systèmes opérationnels résolvant les problèmes cliniques et administratifs du monde réel à une fraction du prix des alternatives existantes. FHIR est adapté à une utilisation dans une grande variété de contextes – applications de téléphonie mobile, communications en nuage, partage de données basé sur le DSE, communication de serveur dans de grands fournisseurs de soins de santé institutionnels, etc.

Pourquoi est-il important?

API mobile les applications et FHIR représentent l'avenir de l'interopérabilité et l'avenir est là.

Mais que sont les API?

Les API sont des ensembles d'exigences qui régissent la manière dont les applications communiquent et interagissent les unes avec les autres. Une API est une interface qui fournit aux développeurs un accès par programme à une application logicielle propriétaire. Les API connectent tout système de santé, médecin, patient ou dispositif médical en normalisant toutes les demandes entrantes et les données en tant que ressources FHIR appropriées. FHIR est attrayant car il repose sur une approche réellement moderne des services Web, qui permet aux systèmes d’échanger plus facilement des informations très spécifiques et bien définies, telles qu'une liste de médicaments, une liste de problèmes ou les résultats de laboratoire, plutôt que des documents entiers. [19659003] L'informatique médicale devrait toujours concerner le patient . À cette fin, l'interopérabilité est la pierre angulaire de cette perspective du patient avant tout – en tant que mécanisme de soutien important pour l'échange rapide et efficace d'informations essentielles à la prestation des soins, l'une des nombreuses raisons pour lesquelles le FHIR est important.

de la poussée pour l'interopérabilité découle directement des exigences réglementaires. Cependant, la nécessité pour divers systèmes de partager des informations à l'aide d'une norme de l'industrie telle que FHIR est réelle et ne se limite pas à ce qui a été mandaté par le gouvernement. Il est important que les systèmes traitant les données des patients interagissent de manière sécurisée afin d’assurer une prestation de soins efficace et rentable. Cette libre circulation et ce partage de données sécurisés, basés sur l'accès, sont également importants pour aider les consommateurs à maintenir et à gérer leur santé. Une institution gouvernementale peut demander à une institution / pratique d'utiliser FHIR pour la collecte de données.

Avantages de FHIR

– La spécification est libre d'utilisation, sans restrictions.

– Prend en charge les architectures RESTful: échange transparent d'informations à l'aide de messages ou de documents et architectures basées sur les services.

-XML ou JSON comme format de transmission de données.

-Un accent particulier sur l'implémentation – rapide et facile à implémenter (plusieurs développeurs ont eu des interfaces simples fonctionnant le même jour). [19659003] – Indépendante de tout fournisseur de DSE, système de santé ou autre entité de santé à but lucratif.

– Serveur FHIR à code ouvert appelé HAPI FHIR pouvant être implémenté par n'importe qui.

Utilisations pratiques de FHIR

FHIR peut être implémenté. utilisé dans plusieurs scénarios de cas d'utilisation. Comprendre FHIR, c'est comprendre le cadre sur lequel la spécification est construite. FHIR utilise le modèle de maturité RESTful niveau 2 et peut prendre en charge des extensions de niveau 3.

Cas d'utilisation 1 :

Enregistrements de santé personnels: le système EMR (Electronic Medical Record) fournit une API RESTful qui permet patients d'accéder à leurs propres dossiers médicaux via un portail Web commun d'application mobile. Dans cet exemple, Patient sera le type de ressource. Il fournira des informations démographiques au client.

Cependant, seule une partie du PHR (Personal Health Record) figure dans le système 1 DME. Cela inclut les visites au bureau, un résumé médical, les médicaments actuels, les allergies connues, mais n'inclut pas les mises à jour de ces données provenant de cliniciens extérieurs au système. Il existe de nombreux spécialistes, DME hors réseau.

Cas d'utilisation 2 :

Outre l'utilisation générique du maintien du PHR du patient, il existe certains cas d'utilisation, flux de travail, collections de documents concernant le patient, avec charge administrative / financière. . L’un de ces domaines est celui des règlements pour les patients blessés et leur traitement / couverture relève d’une litanie d’assurances, y compris les régimes de soins de santé hors groupe… Comp. Dans ce cas, définissant des éléments tels que Care Team, un ensemble de personnes à limiter aux modalités / spécialités médicales, mais impliquant des experts en sinistres, des experts médicaux. Cela aide à exploiter les ressources FHIR telles que les ressources d'organisation, les ressources de praticien – qui peuvent être n'importe quel type de professionnel, clinique et non clinique. Les DME ne couvrent pas ce type de cas d'utilisation – ils ne sont pas destinés non plus. Si vous vous fiez à des systèmes d’information disparates dotés de leurs propres normes de données pour communiquer ces informations, c’est un casse-tête majeur. C'est là que FHIR entre en jeu.

Cas d'utilisation 3 :

Partage de documents: Un moyen courant d'intégrer des informations de santé provenant de diverses sources consiste à créer un référentiel de documents autour du dossier du patient. La création d'un référentiel de documents permet un alignement moins strict sur les règles, les procédures et les normes de tenue de registres / informatique.

FHIR fournit une fonctionnalité équivalente à XDS (Cross Enterprise Document Sharing).

Cas d'utilisation 4 : [19659021] Ouverture des systèmes d'information – Scénario pratique fictif pour FHIR.

Le réseau de santé Abbey compte 4 hôpitaux, 25 cliniques de jour et 200 prestataires de soins. Ils ont accumulé plus de dix ans de dossiers médicaux des patients et ont encouragé le passage d'un dossier de dossiers médicaux électronique à un autre, vers 2005.

L'abbaye du réseau de santé est en cours de fusion / acquisition avec le réseau de santé Bennet, dont le montant est identique. des hôpitaux, des soins ambulatoires et des prestataires de soins, mais fait partie d’un système de DME totalement distinct.

Parlons de certaines des solutions du passé. Les réseaux de santé Abbey et Bennet vont tous les deux parler à leur fournisseur de DME, avec une solide gestion de compte / développement commercial, des relations suivies avec les entreprises… les fournisseurs veulent vraiment répondre à leurs besoins… passer des mois / années à délibérer sur la construction de interfaces dollar, échanges de santé entre les vendeurs. En fin de compte, les fournisseurs doivent se parler, plus de mois et d’années, des confrontations, des désaccords sur les spécifications techniques. Chacun a peut-être un consortium de formats d’échanges / d’interopérabilité dans le domaine de la santé, comme le NHIN Direct / Cerner / Epic, qu’ils doivent maintenant s’essayer et se forcer mutuellement à s’associer.

D’autre part, chaque système pourrait simplement accepter de mettre ses données au format FHIR, dans un serveur / une instance de base de données distinct (FHIR), afin que l’autre partie puisse simplement les consommer. FHIR est ici un intermédiaire objectif.

Un mot sur moi-même

Je suis un consultant technique du projet BCBS MA, travaillant sur le projet de mise à disposition de sites Web numériques qui utilise des API RESTful pour connecter des systèmes hérités en arrière-plan et des bases de données relationnelles. UI. J'ai été chargé de connaître les spécifications FHIR et de rédiger un article de blog à ce sujet.