fermer
Développement

Comment FHIR et les API améliorent l’interopérabilité dans la santé ?

Comment FHIR et les API améliorent l'interopérabilité dans la santé ?

L’interopérabilité dans le secteur de la santé a fait l’objet d’une attention particulière au cours de la dernière décennie, tant dans le cadre législatif que dans le secteur des technologies de la santé. Les API constituent un espace de développement crucial pour une meilleure interopérabilité, et de nombreux développeurs de systèmes d’information hospitalier (SIH) les déploient pour améliorer les offres de logiciels intégrés.

Comme ces plateformes traitent des informations sensibles, leurs API doivent être à la pointe du développement et de la sécurité.

En 2021, cela signifie utiliser le format FHIR (Fast Healthcare Interoperability Resources), de plus en plus populaire. Si vous êtes un développeur cherchant à pénétrer dans le secteur de la santé, ou un cabinet médical essayant de discerner les qualifications nécessaires pour un développeur, une compréhension de FHIR et d’autres formats d’API de soins de santé est pratiquement obligatoire.

FHIR

Fast Healthcare Interoperability Resources, plus connu sous le nom de FHIR, est une norme qui décrit les formats et les éléments de données ainsi qu’une API pour l’échange, utilisée par Apple Health Records et d’autres sociétés développant des solutions pour améliorer l’accès aux dossiers médicaux des patients.

Le format FHIR est considéré comme l’avenir du format des données de santé car il continue de supplanter des normes plus anciennes telles que Health Level Seven International (HL7). À des fins de développement, il ressemble beaucoup à un autre format populaire, JSON, car tous deux utilisent des objets comme JavaScript. Comme FHIR ressemble beaucoup à JSON, il peut être facilement converti si nécessaire, contrairement à HL7 qui crée quelques maux de tête lors de la conversion.

FHIR commence même à passer du statut de chouchou de l’industrie des technologies de la santé à celui de format codifié de choix dans cet espace. De récentes politiques commencent à encourager ou carrément à exiger la transition vers les formats FHIR.

Si vous êtes un développeur dans le secteur de la santé, il est fortement recommandé d’adopter FHIR dans votre répertoire. Ce format s’avère être un puissant élément de base pour améliorer l’interopérabilité de la santé, et le développement des API.

JSON

JSON a été adopté par de nombreux secteurs d’activité comme format privilégié pour l’envoi et la réception d’informations depuis les API, mais ce n’est en aucun cas le seul moyen d’afficher des informations. HL7 est un premier ensemble de normes spécifiques au secteur de la santé pour le transport des informations cliniques. Bien qu’il soit toujours utilisé, il n’est plus particulièrement encouragé pour le développement de nouvelles applications dans le secteur.

Pour les développeurs qui ont besoin de données au format HL7, des intégrations d’applications sont souvent disponibles pour convertir les informations, mais il est recommandé de construire une API dans un langage moderne et de prévoir l’option de conversion HL7 dans les cas limites où le format tend à devenir obsolète.

Architecture : API REST

Les API REST sont importantes pour les plateformes qui gèrent des appels de données continus, et elles ont tendance à être préférées aux protocoles SOAP plus rigides. Les API REST sont plus compatibles avec l’envoi et la réception de grandes quantités de données, notamment pour les applications mobiles. Par exemple, si vous envoyez des informations en HTTP (Hypertext Transfer Protocol), vous aurez beaucoup de endpoints qui sont essentiellement une série d’URL vers lesquels les gens peuvent se rendre.

Sécurité

Comme les technologies de santé traitent souvent des informations très sensibles et privées, des mesures de sécurité renforcées sont nécessaires. De nombreux tiers peuvent se connecter à une API de santé, de sorte qu’aucun compromis ne peut être fait en matière de sécurité.

OAuth 2.0 est une norme fiable pour garantir une connexion sécurisée à l’API. Bien qu’elle ne soit pas encore omniprésente dans le secteur, elle est appréciée comme une mesure de sécurité précieuse et est utilisée par les grandes entreprises technologiques.

Elle est particulièrement importante lorsqu’il s’agit de données relatives aux patients, et elle deviendra probablement une norme industrielle pour les connexions sécurisées. Il s’agit généralement d’un moyen plus facile d’obtenir une autorisation, car il suffit à l’utilisateur de confirmer l’accès, plutôt que d’utiliser une clé API.

Documentation et support

La documentation est l’un des composants les plus cruciaux lorsqu’il s’agit d’une API offrant une bonne expérience aux développeurs, et son importance ne doit pas être sous-estimée. Une bonne documentation facilite considérablement le travail des développeurs dans l’API. Si tout est correctement décrit, les développeurs peuvent trouver un endpoint particulier, voir ce qu’il fait et le comprendre un peu mieux.

La documentation aide non seulement à trouver les endpoints, mais elle aide également les développeurs à compléter le processus d’autorisation de manière plus transparente, à se connecter avec des Webhooks, à intégrer des iframes et bien plus encore.

En outre, le maintien d’un forum communautaire aide ceux qui tentent de s’appuyer sur une API à surmonter les obstacles qu’ils peuvent rencontrer. Google Groups, par exemple, est fréquemment utilisé pour mettre en relation les développeurs avec ceux qui ont déjà rencontré des difficultés analogues.

Si la plupart de ces caractéristiques ont été largement adoptées dans d’autres secteurs, leur utilisation devient encore plus cruciale à mesure que les patients, les prestataires, les législateurs et les systèmes de santé se rapprochent d’une solide normalisation des données de santé. Des normes comme FHIR, en particulier, s’avéreront essentielles pour l’avenir du développement d’API dans le secteur de la santé.

Tags : APIFHIRsanté
Yohann Poiron

The author Yohann Poiron

J’ai fondé le BlogNT en 2010. Autodidacte en matière de développement de sites en PHP, j’ai toujours poussé ma curiosité sur les sujets et les actualités du Web. Je suis actuellement engagé en tant qu’architecte interopérabilité.