Êtes-vous confronté à la nécessité de vous conformer aux exigences CMS? Dans cet article, j'aimerais vous faire part de notre expérience consistant à rendre le système médical patrimonial d'un régime de santé américain conforme aux règles CMS.

Commençons par définir ce qu'est réellement la conformité CMS. Selon la règle finale sur l'interopérabilité et l'accès aux données des patients du CMS (CMS-9115-F), tout régime de santé qui travaille avec des patients CMS doit se conformer aux règles CMS. En résumé, pour être conformes, les régimes de santé doivent partager leurs répertoires de prestataires, leurs réclamations, leurs formulaires et leurs données cliniques avec leurs membres. Cela signifie que ces régimes de santé doivent disposer de données médicales cohérentes au format FHIR et offrir un accès API conforme à FHIR à ces données.

Examinons maintenant notre expérience concrète avec un régime de santé américain et la façon dont nous l'avons rendu conforme à FHIR grâce à une nouvelle solution basée sur Aidbox. Nous passerons également en revue nos défis techniques spécifiques et vous expliquerons exactement comment nous les avons résolus.

Cet article sera utile aux directeurs techniques, aux gestionnaires techniques, aux chefs de projet, aux chefs d'équipe et aux autres experts techniques responsables de la mise en conformité CMS de leur système d'information de santé.

Continuez votre lecture pour en savoir plus sur :

• L'origine du projet de conformité CMS
• Les exigences de la solution d'intégration basée sur Aidbox
• Les fonctionnalités et caractéristiques d'Aidbox utilisées
• Les défis liés à l'intégration
• La structure et le flux de travail de l'adaptateur d'intégration

Une brève présentation : je m'appelle Paul Chayka. Je suis chef d'équipe et chef de projet chez WaveAccess, et je travaille avec des systèmes d'information de santé et l'intégration FHIR.

Origine du projet

Permettez-moi de vous donner un bref aperçu de l'origine du projet. Le régime de santé américain s'est trouvé dans l'obligation de se conformer aux règles CMS et a entrepris de rechercher une plateforme FHIR. Il a décidé d'utiliser Aidbox et a demandé à Health Samurai d'intégrer une solution basée sur Aidbox dans son écosystème numérique existant et de mettre en œuvre l'intégration FHIR de ses données médicales conformément aux règles CMS.

Les résultats de la recherche initiale ont montré que la structure des données médicales dans le système du client était propriétaire et qu'une solution d'intégration personnalisée était nécessaire. Health Samurai a donc fait appel à WaveAccess, en tant qu'entreprise partenaire, pour aider à la mise en œuvre des intégrations FHIR personnalisées et à l'intégration de la solution dans l'environnement du client.

Collecte des exigences

La première étape consiste à collecter les exigences. Notre équipe a donc analysé les demandes du client et préparé une liste d'exigences que la future solution d'intégration devrait respecter :

• Les données médicales doivent être converties en ressources FHIR conformément aux guides d'implémentation FHIR prédéfinis par CMS
• Les données médicales doivent être stockées au format FHIR dans Aidbox
• Le processus d'intégration doit être mis en œuvre de façon régulière, selon les délais prédéfinis par CMS
• La solution doit offrir un accès API conforme à FHIR à ces données
• Certains jeux de données doivent être publics et d'autres protégés

Selon ces exigences, le schéma de base de la solution est présenté ci-dessous :

Le système patrimonial envoie les données médicales au format CSV à la plateforme FHIR. Ces données sont reçues par la couche d'intégration, qui joue également le rôle d'adaptateur entre le système et Aidbox. Dans ce module, les données médicales sont transformées en ressources FHIR et envoyées à Aidbox, qui fournit également une API conforme à FHIR. Celle-ci peut être utilisée par les développeurs de portails membres et d'applications mobiles pour donner aux membres accès à leurs données.

Aidbox

Aidbox est une plateforme pilotée par les métadonnées et fondée sur FHIR. Elle peut être utilisée comme stockage FHIR offrant une API FHIR, ainsi que comme dorsal pour le système d'information de santé. Aidbox fournit certaines fonctionnalités et caractéristiques que nous avons utilisées dans ce projet. Examinons-les.

Stockage FHIR

En tant que solution avancée de stockage FHIR, Aidbox peut être utilisé pour stocker tous les types de ressources FHIR, y compris les ressources utilisées dans les guides d'implémentation FHIR des règles CMS. De plus, Aidbox offre des fonctionnalités supplémentaires pour la personnalisation des ressources et la création de nouvelles ressources.

API FHIR

Aidbox fournit une API FHIR et une passerelle API. Elle respecte toutes les exigences RESTful de HL7 FHIR et dispose de tous les paramètres de recherche par défaut des ressources FHIR. Les utilisateurs d'Aidbox peuvent également personnaliser les paramètres de recherche et en créer de nouveaux.

Téléversement des données

Aidbox offre plusieurs façons de téléverser des données :

• API REST. Une API REST est une solution simple pour créer et mettre à jour une ressource. Toutefois, si vous devez charger plusieurs enregistrements simultanément, cette méthode n'est pas appropriée, car vous devrez effectuer un grand nombre d'appels API.

• Batch Upsert. Pour plusieurs enregistrements, Aidbox propose le téléversement par lots (batch upsert). Cela permet aux utilisateurs de bénéficier de tous les avantages de l'API CRUD, mais pour plusieurs enregistrements. Cette méthode permet de contrôler le statut de téléversement de chaque enregistrement individuellement. Aidbox valide immédiatement la conformité des enregistrements avec le profil spécifié et conserve un historique pour chaque enregistrement. Si vous devez téléverser une très grande quantité de données, cette méthode n'est pas optimale, car toutes les fonctions supplémentaires ralentiront le téléversement.

• Bulk Import API. Si vous devez téléverser des dizaines de milliers d'enregistrements ou plus, il est préférable d'utiliser l'API Bulk. Elle vous permet de téléverser une quantité illimitée de données à vitesse maximale. Cependant, la validation des données ne sera pas effectuée et l'historique sera désactivé par défaut. Vous devrez contrôler la qualité des données téléversées à l'avance. Pour téléverser des données, vous devrez générer un fichier NDJSON et le téléverser dans un dépôt avec un lien public, ou avec des URL signées par Amazon S3 ou Google Cloud Storage. Vous pouvez également ajouter des identifiants pour accéder au stockage dans Aidbox.

Sécurité

Aidbox est fourni avec un module d'authentification intégré clé en main, qui offre :

• Diverses implémentations de serveur d'authentification (OAuth 2.0 et OpenID)
• Autorisation inter-domaines et module de gestion des groupes
• Flux d'inscription et de connexion par courriel ou numéro de téléphone
• Connexion avec Google, Facebook, Auth0, etc.
• Accès par JSON Web Token pour Aidbox en tant que serveur de ressources

Aidbox offre un modèle flexible pour personnaliser les règles d'autorisation des requêtes. Les utilisateurs peuvent déclarer un ensemble de vérifications pour toutes les requêtes entrantes. Si la requête entrante satisfait à ces vérifications, elle est considérée comme « autorisée » et traitée. Dans le cas contraire, la requête est refusée et le client reçoit l'erreur « 403 Unauthorized ». Ces vérifications sont déclarées à l'aide de la ressource AccessPolicy.

Déploiement

Aidbox est fourni avec une infrastructure infonuagique automatisée construite sur Kubernetes (K8s) pour AWS, Azure et GCP, et offre des solutions de sauvegarde, de surveillance et de journalisation clé en main. Cette infrastructure peut être utilisée pour déployer d'autres parties de l'application en développement. Vous trouverez une liste complète des fonctionnalités d'infrastructure d'Aidbox ci-dessous :

• Pipeline CI/CD automatisé : Drone CI / Kustomize pour K8s
• Réplication de base de données et sauvegardes pour la haute disponibilité et la reprise après sinistre
• Journal d'audit basé sur Elasticsearch / Kibana / Grafana
• Surveillance basée sur Prometheus & Grafana
• Stockage de fichiers pour les fichiers et documents
• Gestionnaire de certificats SSL pour assurer le chiffrement des données en transit
• Toutes les autres mesures de protection technique HIPAA

Commencez avec le serveur FHIR Aidbox pour le stockage des données, les intégrations, l'analytique en santé et plus encore, ou engagez notre équipe pour soutenir vos besoins en développement de logiciels.

Résumé

Comme vous pouvez le constater, Aidbox fournit un serveur FHIR haute performance, une infrastructure infonuagique et une API sécurisée conforme à FHIR. Il peut servir de dorsal de bout en bout pour un système d'information de santé moderne. Dans ce projet, cependant, nous avons rencontré des défis supplémentaires qui nous ont obligés à étendre Aidbox avec un module d'intégration supplémentaire. Dans la prochaine section, nous passerons en revue ces défis et verrons exactement comment notre solution d'intégration personnalisée les a résolus.

Adaptateur d'intégration FHIR

Couche d'intégration

Comme je l'ai mentionné précédemment, les données médicales du client ne suivaient aucune norme industrielle. Aidbox dispose d'un adaptateur EDI intégré pour les normes les plus courantes de données de santé, comme HL7 v.2 et X12, mais dans notre situation, nous devions développer une solution d'intégration personnalisée. Pour commencer, mon équipe a préparé une liste des principales fonctionnalités pour le futur adaptateur :

• Connexion à la source de données du système patrimonial
• Conversion des données médicales en ressources FHIR
• Connexion à Aidbox
• Envoi des ressources FHIR à Aidbox

Structure générale

Dans le cas général, l'architecture de l'adaptateur se présentait comme suit :

L'adaptateur recevait les données médicales du système patrimonial, les transformait en ressources FHIR et les envoyait à Aidbox. Au cours du développement, nous avons rencontré des défis supplémentaires :

• Le système patrimonial contenait une quantité considérable de données.
• Les données médicales existantes pouvaient être modifiées au fil du temps.
• Il n'y avait pas de clés primaires dans les enregistrements médicaux.
• Le système patrimonial ne fournissait pas de champs tels que « lastModifyDate » ou d'autres indicateurs de modification.

Nous avons donc dû améliorer notre adaptateur pour relever ces défis.

Cohérence des données

Les processus d'intégration doivent s'exécuter régulièrement. Comment s'assurer que les données dans Aidbox sont cohérentes? La solution la plus simple consiste à supprimer toutes les données correspondantes d'Aidbox avant chaque intégration et à téléverser les données à partir de zéro. Le principal inconvénient de cette approche est la durée d'intégration extrêmement longue. En général, les données ne changent pas beaucoup, et si nous pouvions trouver un moyen de suivre les modifications et d'ignorer les données qui n'ont pas changé au cours de la période précédente, cela améliorerait considérablement le temps d'intégration.

Dans un premier temps, nous devons séparer les données entrantes en nouvelles données et en données modifiées. Le schéma de l'adaptateur devrait ressembler à ceci :

Mais comment savoir quels enregistrements sont nouveaux et lesquels doivent être mis à jour? Rappelons qu'il n'y avait pas de clés primaires dans ces données. Pour surmonter ce défi, nous devons ajouter un nouveau module Historique qui calculera les hachages des enregistrements et les stockera avec les identifiants FHIR. De cette façon, nous pouvons différencier un nouvel enregistrement d'un enregistrement existant. De plus, nous pouvons même déterminer si un enregistrement existant a été modifié et ignorer les opérations de mise à jour inutiles.

Stockage des données et journalisation

Pour assurer la fonctionnalité du module d'historique, nous devons stocker les hachages des enregistrements avec les identifiants FHIR dans le stockage de données. L'adaptateur utilise la base de données PostgreSQL d'Aidbox à cette fin. Nous disposons d'une table d'historique distincte pour chaque profil FHIR utilisé dans les intégrations. Pour la fonctionnalité de journalisation, nous utilisons la pile ELK d'Aidbox.

Dans certains cas, l'adaptateur d'intégration doit être déployé séparément d'Aidbox, par exemple lorsqu'un client ne souhaite pas exposer son stockage de données médicales en dehors de son environnement interne. Dans ce cas, l'adaptateur peut être installé séparément dans l'environnement sécurisé du client, tandis qu'Aidbox peut être infonuagique. Pour accroître la personnalisation de l'adaptateur et préserver le niveau de sécurité du client, nous avons donc ajouté la fonctionnalité permettant d'installer l'adaptateur comme solution distincte. Il peut utiliser une base de données PostgreSQL personnalisée pour stocker les données d'historique et une instance ELK personnalisée pour la journalisation.

Flux de travail de l'adaptateur

Le diagramme final de notre adaptateur est présenté ci-dessous :

Dans un premier temps, l'adaptateur lit les données du stockage de données médicales du système patrimonial; la source de données peut être représentée sous différentes formes. Par exemple, la plus couramment utilisée est la base de données SQL.

Après l'extraction des données, l'adaptateur les convertit en ressources FHIR conformes aux guides d'implémentation requis. Il obtient ainsi un ensemble de ressources FHIR cohérentes qui doivent être téléversées dans Aidbox.

Après le processus de conversion, la solution calcule différents hachages pour les ressources résultantes et les compare aux hachages des ressources déjà téléversées. L'adaptateur détermine ensuite quelles ressources ont été téléversées lors de la précédente itération d'intégration et doivent être mises à jour, quelles ressources de la précédente opération d'intégration sont désormais obsolètes, et quelles ressources sont nouvelles.

Enfin, l'adaptateur téléverse et met à jour les ressources nouvelles et modifiées, et supprime les ressources obsolètes. En même temps, il stocke les hachages des nouvelles ressources dans la base de données. Tout au long du processus, l'adaptateur fournit des journaux décrivant l'étape en cours de l'itération d'intégration.

Détails techniques

L'adaptateur utilise la pile technologique suivante :

• Java 11
• PostgreSQL 11
• Spring 5, Spring Boot 2
• Hibernate 5, MyBatis 3
• Maven
• Amazon S3, Google Cloud Storage
• Kubernetes, Docker

Le diagramme d'architecture de haut niveau est présenté ci-dessous :

L'adaptateur d'intégration est utilisé pour extraire les données de la source de données du client, les convertir au standard FHIR et les envoyer à Aidbox. Il peut utiliser la base de données PG d'Aidbox comme stockage d'historique, ainsi que la pile ELK d'Aidbox pour la journalisation. Cette solution peut également être déployée séparément d'Aidbox. Dans ce cas, l'adaptateur peut utiliser sa propre base de données PG et sa propre pile ELK. Il dispose également d'une API REST pour l'initialisation manuelle des processus d'intégration.

Résumé technique

Nous avons développé notre adaptateur d'intégration FHIR comme extension d'intégration pour Aidbox. Il s'agit d'une solution personnalisable dotée d'un ensemble de bibliothèques développées pour l'exécution efficace, rapide et flexible d'opérations de lecture de données provenant de diverses sources, de leur conversion en ressources FHIR et de leur téléversement dans Aidbox.

Pour conclure cette section, j'aimerais énumérer les avantages de l'adaptateur d'intégration FHIR :

• L'adaptateur utilise et personnalise des bibliothèques fiables et en constante évolution. Elles offrent un grand nombre de possibilités pour interagir avec Aidbox, convertir des ressources et d'autres fonctionnalités, ce qui peut réduire considérablement le temps de développement.
• L'adaptateur offre des possibilités d'intégration clé en main avec les types de sources de données les plus courants, tels que les bases de données SQL, le stockage S3 et autres.
• L'adaptateur offre diverses façons d'interagir avec Aidbox, qu'il s'agisse d'un téléchargement de ressource unique, d'un téléchargement par lots, d'un téléchargement d'archive, etc.
• L'adaptateur offre une capacité de mise à jour incrémentielle qui lui permet de calculer et de charger efficacement uniquement les ressources modifiées à chaque nouvelle itération de mise à jour.
• L'adaptateur fournit des opérations transactionnelles et contrôle l'intégrité des données afin qu'Aidbox ne contienne pas de ressources incohérentes.

Conclusions

Dans cet article, nous avons partagé notre expérience pour aider un client — un régime de santé américain — à se conformer aux règles CMS. Nous avons établi un partenariat avec Health Samurai et intégré Aidbox dans l'écosystème numérique du client à l'aide de l'adaptateur d'intégration FHIR, développé par notre équipe. Nous avons ainsi conçu une solution d'intégration FHIR entièrement personnalisable qui peut aider toute organisation travaillant avec des données de santé à les convertir au format FHIR et à les maintenir cohérentes en temps opportun et sans difficulté.

Si vous êtes confronté à la nécessité de vous conformer aux règles CMS, si vous souhaitez vous intégrer au standard FHIR ou si vous avez simplement des questions, communiquez avec nous. Notre équipe et celle de Health Samurai seront heureuses de vous aider.

Pour explorer comment la conformité CMS peut être intégrée à vos systèmes, essayez la version gratuite d'Aidbox. Elle offre un environnement complet pour tester et mettre en œuvre des mesures de conformité, en fournissant tous les outils nécessaires sans aucune limitation de fonctionnalités.

Auteur : Paul Chayka, Expert en solutions de santé | Chef de projet et chef d'équipe chez WaveAccess

Voir aussi : Conformité à la loi 21st Century Cures Act.