Le coût de l’adoption de l’API FHIR dans les soins de santé
Carmody explique qu’à l’UPMC, de nombreuses interfaces et échanges de données sont actuellement utilisés.
« Vous avez déjà ces coûts pour prendre en charge l’environnement actuel du point de vue de l’infrastructure, et maintenant vous adoptez de nouvelles capacités qui justifient des investissements pour les concrétiser », dit-il.
Cela comprend l’investissement dans des mesures de sécurité supplémentaires telles que le cryptage des données pour les informations personnelles sur la santé transférées entre les parties.
APPRENDRE ENCORE PLUS: La norme FHIR va-t-elle révolutionner l’interopérabilité des soins de santé ?
« La prise en charge de l’infrastructure supplémentaire entraîne des coûts supplémentaires, que ce soit dans un centre de données ou dans le cloud », explique Carmody. « Ces coûts vont continuer à augmenter. C’est là que les coûts s’additionnent du point de vue de l’adoption.
Jason Warrelmann, directeur mondial des soins de santé et des sciences de la vie d’UiPath, est d’accord, notant que même si l’adoption du FHIR permet aux organisations de soins de santé d’accroître l’interopérabilité, le partage des données représente toujours un coût énorme.
« Depuis la mise en place de la norme FHIR, les systèmes de santé tentent de réduire le coût de l’abrasion des données et de gérer la simplification d’une partie du poids administratif qui entoure l’utilisation des données », dit-il.
Éliminer les obstacles à l’adoption de l’API FHIR
Les organisations de santé peuvent réduire leurs coûts en tirant parti du logiciel d’automatisation compatible FHIR pour ouvrir de nouvelles opportunités de cas d’utilisation clinique au sein du système de santé, ainsi qu’en partageant des informations entre les systèmes de santé.
Warrelmann ajoute qu’avec l’adoption et la mise en œuvre de normes d’API ouvertes réglementées par le gouvernement et de configurations FHIR, les organisations de soins de santé se rendent rapidement compte qu’elles manquent de processus internes pour gérer la gouvernance des données et que leur plate-forme de dossier de santé électronique doit encore être optimisée pour tirer pleinement parti de les intégrations de données.
« Les obstacles à l’adoption prendront du temps à surmonter à mesure que les EHR mûriront pour gérer à la fois l’API bidirectionnelle, le développement d’API personnalisées et le partage sécurisé des données basées sur FHIR dans un échange peer-to-peer », explique-t-il.
DÉCOUVRIR: Ce que vous devez savoir sur FHIR vs HL7 v.2 pour l’interopérabilité des soins de santé
Miles Romney, co-fondateur et CTO d’eVisit, dit que sans une appréciation de l’étendue et de la complexité potentielles de l’effort de migration, il est facile d’être frustré par des attentes non satisfaites.
« En migrant de HL7 v.2 ou d’un format propriétaire vers FHIR, les ingénieurs d’échange de données apprendront peut-être à une douzaine de systèmes différents à parler un nouveau langage – un nouveau langage hautement technique », dit-il.
Du point de vue de Romney, cependant, dans de nombreux cas à l’aide de FHIR sera un peu comme écraser une mouche avec un marteau.
« Il a été conçu pour s’adapter à tout dans les soins de santé, ce qui signifie nécessairement qu’il sera surmené pour de nombreuses tâches plus simples », dit-il. « Mais il est hautement modulaire, donc cela peut être atténué dans une certaine mesure. »
La collaboration informatique en santé peut améliorer l’interopérabilité
Carmody souligne l’importance pour les professionnels de l’informatique de la santé de partager leurs expériences et leurs meilleures pratiques afin de déterminer les défis de l’API FHIR et de définir les meilleures pratiques.
« Si vous avez ouvert cette voie, le partage de ces informations avec d’autres peut garantir que leur processus est un peu plus fluide lorsqu’ils adoptent une nouvelle norme comme FHIR dans leur environnement », dit-il.
