# 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 ](https://wiki.ohie.org/display/resources/Architectural%2BPrincipals)est de permettre aux différents services d’infrastructure (tels que le SHR) d’être interchangeables. Pour cela, les [normes et profils OpenHIE ](https://wiki.ohie.org/display/documents/OpenHIE%2BStandards%2Band%2BProfiles)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é |
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://guides.ohie.org/arch-spec/5.0-fr-1/openhie-component-specifications-1/openhie-shared-health-record-shr.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.