Partage via

Introduction à la règle d’interopérabilité et d’accès aux patients des centres pour l’assurance santé et les services Medicaid (CMS)

  • Article

Important

L’API Azure pour FHIR sera mise hors service le 30 septembre 2026. Suivez les stratégies de migration pour passer au service FHIR® de Services de données de santé Azure d’ici à cette date. En raison de la mise hors service de l’API Azure pour FHIR, les nouveaux déploiements ne seront plus autorisés à compter du 1er avril 2025. Le service FHIR des Services de données de santé Azure est la version évoluée de l’API Azure pour FHIR qui permet aux clients de gérer les services FHIR, DICOM et MedTech avec des intégrations dans d’autres services Azure.

Dans cette série de tutoriels, nous allons aborder un résumé de haut niveau de la règle d’interopérabilité et d’accès aux patients du Center for Medicare and Medicaid Services (CMS) et des exigences techniques décrites dans cette règle. Nous allons parcourir les différents guides d’implémentation référencés pour cette règle. Nous allons aussi fournir des détails sur la configuration de l’API Azure pour FHIR® afin de prendre en charge ces guides d’implémentation.

Vue d’ensemble de la règle

Le CMS a publié la règle d’interopérabilité et d’accès aux patients le 1er mai 2020. Cette règle nécessite un flux de données gratuit et sécurisé entre toutes les parties impliquées dans les soins des patients (patients, fournisseurs et payants) pour permettre aux patients d’accéder à leurs informations de santé lorsqu’ils en ont besoin. L’interopérabilité a envahi l’industrie de la santé depuis des décennies, ce qui entraîne des données en silo qui provoquent des résultats négatifs sur la santé avec des coûts plus élevés et imprévisibles pour les soins. CMS utilise son autorité pour réglementer l’avantage médical (MA), Medicaid, le Programme d’assurance maladie des enfants (CHIP) et les émetteurs du Plan de santé qualifié (QHP) sur les échanges fédéraux facilités (FFEs) pour appliquer cette règle.

En août 2020, CMS a détaillé la façon dont les organisations peuvent respecter le mandat. Pour garantir des échanges de données sécurisés et standardisés, le CMS a identifié la version 4 (R4) de Fast Healthcare Interoperability Resources (FHIR®) comme la norme fondamentale requise pour l’échange de données.

Il existe trois éléments principaux dans la décision d’interopérabilité et d’accès aux patients :

  • API Accès Patient (obligatoire le 1er juillet 2021) – Les organismes de remboursement de frais médicaux réglementés par le CMS (tels que définis précédemment) doivent implémenter et maintenir une API sécurisée basée sur des normes qui permet aux patients d’accéder facilement à leurs droits et leurs informations, notamment leurs frais, ainsi qu’une partie définie de leurs informations médicales par le biais d’applications tierces de leur choix.

  • API d’annuaire de fournisseurs (obligatoire le 1er juillet 2021) – les payants réglementés par CMS sont requis par cette partie de la règle pour rendre les informations d’annuaire du fournisseur accessibles publiquement via une API basée sur des normes. Grâce à la mise à disposition de ces informations, les développeurs d’applications tierces pourront créer des services permettant d’aider les patients à trouver des prestataires de santé spécifiques et les praticiens à trouver d’autres prestataires pour la coordination des soins.

  • Échange de données entre organismes de remboursement de frais médicaux (initialement requis le 1er janvier 2022 - actuellement retardé) – Les organismes de remboursement de frais médicaux réglementés par le CMS sont tenus d’échanger certaines données médicales à la demande du patient avec les autres organismes. Bien qu’il n’y ait aucune obligation de suivre un type de norme, l’application de FHIR pour échanger ces données est encouragée.

Concepts clés de FHIR

Comme mentionné précédemment, FHIR R4 doit respecter ces obligations. De plus, il existe plusieurs guides d’implémentation qui fournissent des conseils concernant cette règle. Guides d’implémentation fournir un contexte supplémentaire en plus de la spécification FHIR de base. Cela inclut la définition de paramètres de recherche supplémentaires, des profils, des extensions, des opérations, des jeux de valeurs et des systèmes de code.

L’API Azure pour FHIR dispose des fonctionnalités suivantes pour vous aider à configurer votre base de données pour les différents guides d’implémentation.

Guides d’implémentation de l’API d’accès aux patients

L’API d’accès aux patients décrit l’adhésion à quatre guides d’implémentation FHIR :

  • CARIN IG pour Blue Button®: les contribuables sont tenus de rendre les revendications des patients et de rencontrer les données disponibles en fonction du GUIDE d’implémentation de CARIN IG pour le bouton bleu (C4BB IG). Le C4BB IG fournit un ensemble de ressources que les contribuables peuvent afficher aux consommateurs via une API FHIR et inclut les détails requis pour les données de revendications dans l’API d’interopérabilité et d’accès aux patients. Ce guide d’implémentation utilise la ressource ExplanationOfBenefit (EOB) comme ressource principale, en extrayant d’autres ressources au fur et à mesure qu’elles sont référencées.

  • HL7 FHIR Da Vinci PDex IG: le Guide d’implémentation de l’échange de données du paiement (PDex IG) est axé sur la garantie que les contribuables fournissent toutes les données cliniques pertinentes pour répondre aux exigences de l’API d’accès aux patients. Cela utilise les profils US Core sur les ressources R4 et inclut (au minimum) des rencontres, des fournisseurs, des organisations, des emplacements, des dates de service, des diagnostics, des procédures et des observations. Bien que ces données soient disponibles au format FHIR, elles peuvent également provenir d’autres systèmes au format de données de revendications, de messages HL7 V2 et de documents C-CDA.

  • HL7 US Core IG: le guide d’implémentation HL7 US Core (US Core IG) est la colonne vertébrale de PDex IG décrit précédemment. Bien que le PDex IG limite encore plus certaines ressources que le US Core IG, de nombreuses ressources suivent les normes de US Core IG.

  • HL7 FHIR Da Vinci - PDex US Drug Formulary IG: Les plans d’avantage de la part D Medicare doivent rendre les informations de formule disponibles via l’API patient. Ils le font à l’aide du PDex US Drug Formulary Implementation Guide (USDF IG). Le USDF IG définit une interface FHIR à une information sur les formules de médicaments d’un assureur santé, qui est une liste de médicaments de marque et génériques que l’assureur de santé accepte de payer. Le principal cas d’utilisation est de permettre aux patients de savoir s’il existe d’autres médicaments que celui qui leur a été prescrit, et de comparer les coûts des médicaments.

Guide d’implémentation de l’API d’annuaire du fournisseur

L’API d’annuaire de fournisseurs décrit l’adhésion à un guide d’implémentation.

  • HL7 Da Vinci PDex Plan Network IG: ce guide de mise en œuvre définit une interface FHIR pour les plans d’assurance d’un assureur santé, leurs réseaux associés et les organisations et fournisseurs qui participent à ces réseaux.

Touchstone

Pour tester l’adhésion aux différents guides d’implémentation, Touchstone est une excellente ressource. Tout au long des prochains tutoriels, nous nous assurerons que l’API Azure pour FHIR est configurée pour réussir les différents tests Touchstone. Le site Touchstone dispose d’une très riche documentation pour vous aider à être opérationnel.

Étapes suivantes

Maintenant que vous avez une compréhension de base de la règle d’interopérabilité et d’accès aux patients, des guides d’implémentation et de l’outil de test disponible (Touchstone), nous allons effectuer pas à pas la configuration de l’API Azure pour FHIR pour le guide d’implémentation CARIN pour Blue Button.

Guide d’implémentation de CARIN pour Blue Button

Remarque

FHIR® est une marque déposée de HL7 utilisé avec l’autorisation de HL7.