5 enseignements tirés d'une intégration de DPI transfrontalière
J'ai passé des mois à connecter des dossiers de patients entre deux pays différents. J'ai travaillé avec une Business Analyst Lead ayant dix ans d'expérience clinique. Son approche a changé ma vision des logiciels de santé.
Voici cinq leçons tirées de ce projet.
- Le mappage de la terminologie est plus difficile que le mappage des données
Les ingénieurs traitent souvent l'intégration comme un problème de schéma. On mappe le champ A au champ B et c'est fini. Dans le domaine de la santé, cela ne fonctionne pas.
Un système utilisait la CIM-10 et l'autre la CIM-11. Ils ne se correspondent pas parfaitement. Un système utilisait LOINC pour les analyses de laboratoire tandis que l'autre utilisait d'anciens codes internes.
Notre BA a élaboré un tableau de correspondance des concepts avant que nous n'écrivions le moindre code. Elle a mappé les codes locaux vers un ensemble standard comme SNOMED CT. Sans cela, nous aurions corrompu la signification clinique.
Un mappage de champs défectueux crée des valeurs erronées. Un mappage de terminologie défectueux crée des valeurs plausibles mais cliniquement fausses. Cette dernière situation est bien plus dangereuse.
- Les lois sur les données façonnent l'architecture dès le départ
Je pensais que nous concevrions d'abord le modèle de données et que nous gérerions la conformité plus tard. Je me trompais.
Le transfert de données de patients au-delà des frontières est soumis à de multiples lois comme HIPAA ou le RGPD. Certains pays interdisent que les données de santé quittent leur territoire.
Notre BA a travaillé avec les équipes juridiques dès le début. Elle a décidé quels champs pouvaient être répliqués et lesquels nécessitaient une désidentification.
Cela a modifié notre architecture. Nous avons construit une couche de requête fédérée au lieu d'une base de données répliquée unique. Nous avons ajouté des balises de classification des données directement dans notre schéma.
Réunissez des experts en conformité et une BA avant de concevoir votre modèle de données.
- Les standards ne suffisent pas
Les deux systèmes prenaient en charge HL7. Cependant, l'un utilisait HL7 v2 et l'autre FHIR R4. Ils ne pouvaient pas communiquer sans une couche de traduction.
Même au sein de FHIR, nous avons rencontré des incompatibilités de profils. Les deux systèmes prétendaient être conformes, mais utilisaient des guides d'implémentation différents.
Ne supposez pas que l'intégration est facile simplement parce qu'un système prend en charge un standard. Demandez toujours la version et le profil spécifiques. Prévoyez du temps pour une couche d'adaptation.
- Les diagrammes de flux de travail permettent de détecter les cas limites cachés
J'avais l'habitude de considérer les diagrammes de flux de travail comme de la documentation supplémentaire. Je me trompais.
Notre BA a cartographié les transferts de patients en détail. Elle a examiné ce qui se passe lorsqu'un patient est transféré en cours de traitement ou lorsqu'un résultat de laboratoire arrive après sa sortie de l'hôpital.
Ce ne sont pas des cas limites dans un hôpital. Cela arrive tous les jours.
Ces diagrammes ont modifié notre modèle de données. Nous avons ajouté un concept d'épisode de soins pour suivre la continuité des soins à travers les deux systèmes.
- Établissez un glossaire partagé dès le début
Des termes comme « encounter » ou « discharge » ont des significations différentes selon les systèmes. Nous avons perdu du temps parce que les équipes interprétaient les termes différemment.
Notre BA a créé un glossaire partagé. Chaque partie prenante a examiné et approuvé ces définitions. Nous avons fait référence à ce document dans chaque exigence.
Considérez que chaque terme métier est ambigu. Définissez-le dans un document signé par les deux parties.
Résumé
Une bonne BA fait plus que rédiger des tickets. Elle agit comme une architecte pour les contraintes réglementaires et la signification clinique. Si vous développez des logiciels complexes, ne considérez pas ce rôle comme une simple charge administrative. Cela empêche le succès technique de se transformer en échec clinique.
Communauté d'apprentissage optionnelle: https://t.me/GyaanSetuAi