L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
Options d'interopérabilité pour répondre à la règle finale du CMS
La règle finale du CMS a suscité de nombreux débats au sein de l'équipe d'interopérabilité de Perficient. C’est l’une des premières fois que les payeurs ou les assureurs maladie doivent réagir à ce type de règles. La façon dont ils traitent les données et l'emplacement de toutes les données en font un jeu de balle différent de ce que vous devez suivre si vous étiez à l'hôpital. Cela signifie que si la compréhension des règles de base reste la même, les solutions que vous envisagez sont en fait assez différentes.
The Ask
Plus tôt cette année, CMS / ONC a publié sa très attendue « Final Rule ». qui oblige les payeurs qui ont quelque chose à voir avec des régimes fédéraux à faire ce qui suit:
- API d'accès aux patients – Fournit une API basée sur le FHIR qui permet aux patients d'accéder à leurs réclamations et d'accéder aux informations via des applications tierces
- API Provider Directory – Rendre les informations de l'annuaire des fournisseurs disponibles via une API FHIR accessible au public
- Transfert de payeur à payeur – Autoriser les membres ou les patients à vous demander de transférer leurs dossiers à un autre payeur
Les payeurs qui répondent aux critères clés doivent rendre ces capacités disponibles et doivent le faire il suit des normes ouvertes comme FHIR, SmartIG et OpenID.
Le défi
Comment faire Innover et évoluer dans le secteur des soins de santé B2B
La demande pendant la pandémie COVID-19 a laissé les fabricants et distributeurs du secteur de la santé B2B du mal à suivre. Par la suite, de nombreuses organisations ont découvert des lacunes dans des domaines de leur activité tels que le commerce électronique, l'expérience sur le site, la gestion des informations sur les produits (PIM), etc. ne sont pas configurés pour rendre ces données accessibles au public. De plus, une grande partie de ces données réside dans une gamme de systèmes. Ces systèmes ont également des données qui se chevauchent. C'est là que réside le problème. Le chevauchement des données signifie que vous devez les trouver, les transformer et dédupliquer ces données. Il est possible de passer un appel en temps réel, mais plus vous avez de doublons et plus le chevauchement des données est élevé, plus vous devez en faire.
En d'autres termes, créer simplement une API FHIR ne vous permettra pas de répondre au besoin.
Décider des solutions
La plupart du débat dans notre équipe est de savoir quel type d'architecture répondra aux critères exigés par la règle finale du CMS. Malheureusement, aucune approche architecturale ne fonctionnera pour chaque payeur. Cela permet aux plates-formes d'intégration prenant en charge FHIR et aux solutions de type serveur FHIR d'entrer dans le mix. Ils peuvent même coexister en fonction de votre écosystème de plateformes et de sources de données. Pour prendre une décision, vous devez prendre en compte les éléments suivants:
- Où résident vos informations patient / membre? Se trouve-t-il à plusieurs endroits pour les réclamations, les données d'examens de la vue, les données cliniques, etc.????? est-il facilement accessible via une API?
- Y a-t-il beaucoup de chevauchement de données dans les différentes sources de données?
- Avez-vous du mal à extraire des sources de données et à les mapper au bon membre?
- Avez-vous déjà ou aurez bientôt une plateforme d'intégration et de gestion des API. (les deux peuvent être nécessaires)
Quelques réflexions sur les solutions possibles
Comme indiqué, tout le monde n'aura pas la même solution. Plus l'organisation est grande et plus le nombre de sources de données est important, vous conduisant à un ensemble de solutions plus complexe pour respecter la règle finale. Je mettrais la solution en quelques catégories:
- Pour ceux qui ont peu de sources de données comme principalement des données de réclamations, vous pouvez envisager d'utiliser un fournisseur d'intégration et de gestion d'API pour afficher les données du fournisseur et du patient et pour servir le FHIR basé resources
- Pour les plus complexes, vous pouvez envisager un serveur FHIR ou une «solution» FHIR. Cela peut devoir être associé à l'intégration d'entreprise et à la plate-forme de gestion des API. Cette approche signifie ce qui suit
- Vous récupérez toutes les données dans un emplacement central
- Vous effectuez une transformation et une déduplication des données sur celui-ci afin que les données du patient soient correctement définies
- Ces données ne seront pas en temps réel. De par sa nature, il y aura une certaine latence
- Les données normalisées peuvent alors être appelées en toute sécurité par tout ce qui se trouve devant votre API
- Une option hybride peut fonctionner si les données de votre fournisseur sont facilement accessibles et déjà centralisées
- La plate-forme API appelle les données du fournisseur et active une plate-forme de données patient centralisée FHIR API
- pour les scénarios de données patient les plus complexes
L'essentiel est que chaque organisation a une variété d'options. Vous devez toujours prendre en compte vos systèmes et vos données pour créer votre architecture finale. N'oubliez pas que FHIR est la norme et non la solution. La plupart des gros travaux se produisent derrière l'appel réel FHIR.
Source link