OpenHIE Shared Health Record (SHR)/Dossier médical partagé

Le dossier médical partagé (SHR) facilite le partage d’informations cliniques entre les systèmes d’information de santé afin de permettre une meilleure prise en charge des patients, améliorant ainsi les résultats en matière de santé. Le dossier médical partagé est un moyen permettant à différents services de partager des données de santé stockées dans un référentiel de données centralisé. Il contient un sous-ensemble de données normalisées pour un patient provenant de divers systèmes tels qu’un dossier médical électronique ou le système de gestion des informations de laboratoire. Ce dossier est interrogé et mis à jour par les différentes institutions et systèmes habilités à le faire. Le dossier médical partagé est distinct d’un entrepôt de données ; il s’agit d’une source de données transactionnelle opérationnelle en temps réel.

Un dossier médical partagé est normalisé si tous les éléments de métadonnées tels que les identificateurs de patient, de fournisseur et d’établissement sont résolus en identificateurs universels appropriés (par opposition à leurs identificateurs locaux utilisés par un système client). De plus, tous les codes terminologiques utilisés doivent être mis en correspondance avec une terminologie de référence appropriée pour s’assurer que l’information est bien comprise.

Voir également Exigences non fonctionnelles.

Exigences de flux de travail relatives à OpenHIE SHR

Un principe de base de l’architecture OpenHIE est de permettre aux différents services d’infrastructure (tels que le SHR) d’être interchangeables. Pour cela, les normes et profils OpenHIE utilisés par le dossier médical partagé sont décrits dans les flux de travail ci-dessous.

Pour être un composant de OHIE SHR, l’application SHR doit être en mesure de prendre en charge les flux de travail OHIE répertoriés ci-dessous. Les implémentations ne peuvent prendre en charge que les flux de travail nécessaires pour prendre en charge leur cas d’utilisation :

N°	Flux de travail SHR (décrits en détail dans la dernière partie de ce document)	Recommandation/Exigence
SHRWF-1	Enregistrer le flux de travail des données cliniques au niveau du patient	Exigence
SHRWF-2	Interroger le flux de travail des données cliniques au niveau du patient	Exigence

Exigences fonctionnelles relatives à OpenHIE SHR

N°	Exigences fonctionnelles relatives au SHR	Recommandation/Exigence
SHRF-1	Stocke des données cliniques au niveau du patient qui forment le dossier médical électronique du patient a. Stocke des données cliniques non structurées telles que des fichiers PDF et des textes narratifs b. Stocke des données cliniques structurées telles qu’une rencontre avec plusieurs observations discrètes, compatibles avec un format d’échange standard c. Relie les informations cliniques à d’autres informations cliniques, par exemple, annotations/description d’un document avec des observations discrètes	Recommandé
SHRF-2	Exposer les services qui ont la capacité de recevoir et d’enregistrer les données cliniques des patients sous une forme non structurée, à la fois texte ou binaire (PDF/image), annotées avec suffisamment de métadonnées pour identifier le patient/le prestataire.	Recommandé
SHRF-3	Exposer les services qui ont la capacité de recevoir et d’enregistrer les données cliniques des patients sous une forme structurée, comme des documents CDA ou des ressources FHIR.	Recommandé
SHRF-4	Exposer les services qui ont la capacité de recevoir et d’enregistrer les données cliniques des patients sous une forme qui contient à la fois des éléments structurés et non structurés.	Recommandé
SHRF-5	Expose les services qui répondent aux requêtes concernant le dossier médical électronique d’un patient a. Peut retourner un document connu spécifique ou une liste de documents concernant un patient (tel qu’il a été soumis) b. Peut retourner une liste d’observations discrètes concernant un patient qui satisfont des paramètres de requête spécifiques. Ces données peuvent ensuite être utilisées pour établir des tendances ou fournir les rencontres précédentes d’un patient c. Peut retourner un ensemble complet d’informations cliniques stockées sur un patient d. Retourner le résumé du patient : tout ce que le SHR sait sur un patient, avec des liens pour récupérer les éléments de données individuels	Recommandé
SHRF-6	Le SHR maintient le contexte dans lequel les données ont été soumises.	Recommandé
SHRF-7	Le SHR devrait conserver des journaux d’audit détaillés de toutes les interactions avec les données cliniques a. Conserver des journaux d’audit de toutes les données cliniques et démographiques stockées ou modifiées. Il n’est PAS nécessaire d’enregistrer qui a accédé/consulté les informations cliniques, car c’est quelque chose qu’une couche d’interopérabilité pourrait enregistrer. b. Mises à jour des dossiers et des versions ; les dossiers ne peuvent jamais être supprimés, seulement marqués comme tels ; aucune mise à jour précédente ne devrait réécrire les anciennes données ; aucune information ne devrait jamais être supprimée du système.	Recommandé
SHRF-8	Le SHR devrait prendre en charge la possibilité d’exporter des données pour une utilisation secondaire.	Recommandé
SHRF-9	Le SHR devrait fournir des interfaces/points d’extension à différentes étapes du cycle de vie des données afin de permettre une validation sémantique ou une simple aide à la décision.	Recommandé
SHRF-10	Le SHR devrait permettre le stockage et la récupération des contraintes de confidentialité/de politique de base (contrôle d’accès/restriction d’une partie de l’enregistrement et restriction de l’intégralité de l’enregistrement).	Recommandé
SHRF-11	Le SHR devrait être capable de stocker des données d’observation identifiées et prédéfinies mises en correspondance avec la terminologie de référence standard.	Recommandé
SHRF-12	Le SHR devrait disposer d’un mécanisme pour résoudre les conflits si les dossiers sont soumis simultanément.	Recommandé