Cadre d’interopérabilité des SIS - Couche Contenus …esante.gouv.fr/.../ci-sis_volet-lettre_de_liaison_20180129_v1.3.pdf · ASIP Santé |DGOS CI-SIS - Volet Lettre de Liaison

ASIP Santé |DGOS CI-SIS - Volet Lettre de Liaison 29/01/2018

Classification : public 1/90

V 1.3

RÉFÉRENTIELS

Cadre d’interopérabilité des SIS - Couche Contenus

Volet Lettre de liaison (LDL) Lettre de liaison à l’entrée d'un établissement de santé (LDL-EES)

Lettre de liaison à la sortie de l'établissement de santé (LDL-SES)

29 Janvier 2018



Sommaire 1 POSITIONNEMENT DANS LE CADRE D'INTEROPERABILITE ............................................................................. 3

2 MODELE METIER ........................................................................................................................................... 5

2.1 INTRODUCTION ................................................................................................................................................ 5 2.2 ELEMENTS METIER DES LETTRES DE LIAISON ............................................................................................................ 5

2.2.1 Lettre de liaison à l’entrée en établissement de santé ............................................................................ 5 2.2.2 Lettre de Liaison à la sortie de l’établissement de santé ......................................................................... 6

2.3 TABLEAUX DES DONNEES METIER ......................................................................................................................... 7 2.3.1 Lettre de liaison à l’entrée en établissement de santé ............................................................................ 7 2.3.2 Lettre de Liaison à la sortie de l’établissement de santé ......................................................................... 8

3 SPECIFICATIONS TECHNIQUES ......................................................................................................................10

3.1 TRANSPOSITION EN CDA R2 ............................................................................................................................. 10 3.1.1 Standards et spécifications utilisés ........................................................................................................ 10 3.1.2 Document CDA R2 à corps structuré ..................................................................................................... 10 3.1.3 Cardinalités............................................................................................................................................ 11 3.1.4 Types des données ................................................................................................................................. 11 3.1.5 NullFlavor .............................................................................................................................................. 12 3.1.6 Éléments narratifs référencés dans les entrées ..................................................................................... 13 3.1.7 Terminologies et jeux de valeurs ........................................................................................................... 14 3.1.8 Cas des PS et des structures dans les documents médicaux .................................................................. 14

3.2 SPECIFICATIONS TECHNIQUES DU MODELE LETTRE DE LIAISON A L’ENTREE EN ETABLISSEMENT DE SANTE (LDL-EES) ........... 15 3.2.1 Structuration de l'en-tête de la LDL-EES ................................................................................................ 15 3.2.2 Structuration du corps de la LDL-EES ..................................................................................................... 26

3.3 SPECIFICATIONS TECHNIQUES DU MODELE LETTRE DE LIAISON A LA SORTIE DE L’ETABLISSEMENT DE SANTE (LDL-SES) ........ 38 3.3.1 Structuration de l’en-tête de la LDL-SES ................................................................................................ 38 3.3.2 Structuration du corps de la LDL-SES ..................................................................................................... 49

4 IMPLEMENTATION DANS LES LOGICIELS ......................................................................................................85

4.1 STRUCTURATION DES DONNEES ......................................................................................................................... 85 4.2 ECHANGE ET PARTAGE DES DOCUMENTS STRUCTURES ............................................................................................ 85 4.3 DISPOSITIONS DE SECURITE ............................................................................................................................... 85

5 ANNEXES......................................................................................................................................................86

5.1 DECRET NO 2016-995 DU 20 JUILLET 2016 RELATIF AUX LETTRES DE LIAISON ........................................................... 86 5.2 DOCUMENTS DE REFERENCE .............................................................................................................................. 88 5.3 HISTORIQUE DU DOCUMENT ............................................................................................................................. 88



1 Positionnement dans le cadre d'interopérabilité Les systèmes d’information dans les domaines sanitaire et médico-social doivent être communicants pour favoriser la coopération des professionnels dans le cadre des parcours de santé centrés sur le patient et pour aider la décision médicale.

Le Cadre d’Interopérabilité des Systèmes d’Information de Santé (CI-SIS) fixe les règles d’une informatique de santé communicante. Il couvre :

l’interopérabilité sémantique, portant sur les contenus métiers, qui permet le traitement des données de santé et leur compréhension par les systèmes d’information en s’appuyant sur un langage commun ;

l’interopérabilité technique, qui porte sur les services garantissant l’échange et le partage des données de santé et sur le transport des flux dans le respect des exigences de sécurité et de confidentialité des données personnelles de santé.

L’interopérabilité sémantique, portant sur les contenus métiers, est assurée par la définition de modèles de documents médicaux à implémenter dans les logiciels médicaux. Ces modèles sont décrits dans des Volets Modèles de documents médicaux (aussi appelés Modèles de contenus) qui appartiennent à la couche Contenus du CI-SIS (encadré orangé de la Figure 1 ci-dessous).

Figure 1 – Les volets Modèles de documents médicaux dans le CI-SIS



Ce volet spécifie le modèle de document utilisé pour la Lettre de Liaison dans le format CDA R2. Il fait partie de la couche Contenu du CI-SIS.

Ce volet est composé des parties suivantes :

Le modèle métier élaboré par la Direction Générale de l’Offre de Soins (DGOS).

Les spécifications techniques, qui exposent les règles d'implémentation de ce modèle métier.

L'interopérabilité est garantie car ces spécifications sont exprimées sous la forme du standard

Clinical Architecture Document (CDA R2), en s'appuyant sur les profils de contenus publiés par le

domaine international IHE PCC (Patient Care Coordination) et les spécifications techniques du

Cadre d'Interopérabilité des Systèmes d'Information de Santé (CI-SIS).

La déclinaison technique du modèle métier abouti à la création de 2 documents CDA R2 :

la Lettre de liaison à l’entrée en établissement de santé (LDL-EES),

la Lettre de liaison à la sortie de l’établissement de santé (LDL-SES).

Un exemple d'implémentation en CDA R2.

La terminologie dédiée utilisée par les modèles de documents LDL.

Les fichiers de tests Schematron.

Dès lors qu’ils sont mis en œuvre par les éditeurs dans les logiciels des professionnels de santé, les trois documents structurés du Dossier de liaison d’urgence, définis et décrits dans ce volet, peuvent être mis en partage ou échangés par les professionnels de santé dans le cadre de la prise en charge des personnes âgées en situation d’urgence.



2 Modèle métier

2.1 Introduction La lettre de liaison (LDL), qui s’intègre dans le « programme national pour la sécurité du patient » (PNSP) 2013 – 2017, est mise en place par l’article 95 de la loi de modernisation du système de santé du 26 janvier 2016. Les modalités de mise en œuvre du dispositif sont définies par le décret en conseil d’État du 20 juillet 2016 relatif aux lettres de liaison (1).

La LDL est un document destiné d’une part, à accompagner la demande d’un praticien qui adresse un patient à un établissement de santé (lettre de liaison à l’entrée) et d’autre part, à être remis au patient et adressée au médecin traitant et, le cas échéant, au praticien adresseur, le jour de la sortie de l'établissement de santé du patient (lettre de liaison à la sortie).

Cette LDL a pour vocation d’assurer la continuité de la prise en charge du patient entre l'hôpital et la ville. Les éléments que doivent contenir les LDL sont listés dans le décret du 20 juillet 2016.

Le présent volet a été réalisé en se fondant sur ces éléments.

2.2 Eléments métier des lettres de liaison

Le décret n°2016-995 du 20 juillet 2016 relatif aux lettres de liaison (1) définit deux documents de santé ayant pour objectif d’assurer la transmission d’informations de manière sécurisée entre les professionnels de santé impliqués dans la prise en charge du patient et en contribuant à l’information de celui-ci en lui en remettant un exemplaire.

2.2.1 Lettre de liaison à l’entrée en établissement de santé

2.2.1.1 Production « Le praticien qui adresse un patient à un établissement de santé accompagne sa demande d’une lettre de liaison synthétisant les informations nécessaires à la prise en charge du patient dont il dispose sur son lieu d’intervention, dans le respect des conditions prévues à l’article L. 1110-4 [du CSP] ».

« Elle est adressée par messagerie sécurisée répondant aux conditions prévues à l’article L. 1110-4-1, ou par tout moyen garantissant la confidentialité des informations. Elle est versée dans le dossier médical partagé du patient si ce dossier a été créé, ou lui est remise » (1).

2.2.1.2 Structuration

Cette lettre comprend notamment :

l’identification du patient, du médecin traitant, le cas échéant du praticien adresseur.

les motifs de la demande d’hospitalisation,

les traitements en cours et

les allergies connus ».



2.2.2 Lettre de Liaison à la sortie de l’établissement de santé

2.2.2.1 Production « Lors de la sortie de l’établissement de santé, une lettre de liaison, rédigée par le médecin de l’établissement qui l’a pris en charge, est remise au patient par ce médecin, ou par un autre membre de l’équipe de soins mentionnée au 1° de l’article L. 1110-12 [du CSP] qui l’a pris en charge, et qui s’assure que les informations utiles à la continuité des soins ont été comprises ».

«Dans le respect des dispositions des articles L. 1110-4 et L. 1111-2, la lettre de liaison est transmise le même jour, au médecin traitant et, le cas échéant, au praticien qui a adressé le patient. Elle est adressée par messagerie sécurisée répondant aux conditions prévues à l’article L. 1110-4-1, ou par tout moyen garantissant la confidentialité des informations, et versée dans le dossier médical partagé du patient si ce dossier a été créé » (1).

2.2.2.2 Structuration « Cette lettre de liaison contient les éléments suivants:

L’identification du patient, du médecin traitant, le cas échéant du praticien adresseur, ainsi que l’identification du médecin de l’établissement de santé qui a pris en charge le patient avec les dates et modalités d’entrée et de sortie d’hospitalisation ;

Le motif d’hospitalisation ;

Une synthèse médicale du séjour précisant le cas échéant, les événements indésirables survenus pendant l’hospitalisation, l’identification de micro-organismes multirésistants ou émergents, l’administration de produits sanguins ou dérivés du sang, la pose d’un dispositif médical implantable ;

Les traitements prescrits à la sortie de l’établissement (ou ordonnances de sortie) et les traitements arrêtés durant le séjour et le motif d’arrêt ou de remplacement, en précisant, notamment pour les traitements médicamenteux, la posologie et la durée du traitement ;

L’annonce, le cas échéant, de l’attente de résultats d’examens ou d’autres informations qui compléteront cette lettre de liaison ;

Les suites à donner, le cas échéant, y compris d’ordre médico-social, tels que les actes prévus et à programmer, recommandations et surveillances particulières » (1).



2.3 Tableaux des données métier

2.3.1 Lettre de liaison à l’entrée en établissement de santé

Cette lettre de liaison contient les éléments suivants.

Élément de donnée Card Type Jeu de valeurs

Données administratives

Identification du (de la) patient(e) [1..1]

Adresse [1..1] AD

Coordonnées télécom

Téléphone Fixe [0..1] TEL

Téléphone Portable [0..1] TEL

Email [0..1] TEL

Prénom [1..3] ST

Nom de naissance* [1..1] ST

Nom d’usage* [0..1] ST

Sexe [1..1] CE

Date de naissance [1..1] TS

Lieu de naissance [0..1] AD

Médecin traitant [1..1] PN

Praticien adresseur [1..1] PN

Rédacteur [1..1] PN

Le rédacteur est soit le médecin traitant, soit le praticien adresseur

Motif de la demande d’hospitalisation [1..1] ST

Traitements en cours connus [1..1] BL

Si oui, description [0..1] ST

Allergies connues [1..1] BL


Autres informations [1..1] BL


Tableau 1- Données métier de la LDL-EES



2.3.2 Lettre de Liaison à la sortie de l’établissement de santé

Cette lettre de liaison contient les éléments suivants :


Données administratives

Identification du patient

Adresse [1..1] AD

Téléphone

Téléphone Fixe [0..1] TEL

Téléphone Portable [0..1] TEL

Email [0..1] TEL

Prénom *[1..3] ST

Nom de naissance* [1..1] ST

Nom d’usage* [0..1] ST

Sexe [1..1] CE

Date de naissance [1..1] TS

Lieu de naissance [0..1] AD

Médecin qui a pris en charge le patient [1..1] PN

C’est aussi le rédacteur de la LDL

Destinataires de la LDL à la sortie de l’établissement de santé

[1..2] PN

Médecin traitant [1..1] PN

Praticien adresseur* [1..1] PN

Entrée en établissement de santé [1..1]

Date [1..1] TS

Modalité (entrée) [1..1] CD Urgences / Programmé / Transfert / Autre

Si réponse « Autre » [0..1] ST

Sortie de l’établissement de santé [1..1]

Date [1..1] TS

Modalité (destination) [1..1] CD Domicile / EHPAD / SSR / HAD / Autre établissement de santé / Autre

Si réponse « Autre » [0..1] ST

Motif d’hospitalisation [1..1] ST

Synthèse médicale du séjour [1..1] ST

Événements indésirables survenus pendant l’hospitalisation

[1..1] BL


Identification de micro-organismes multirésistants (BMR) ou émergents (BHRe)

[1..1] BL


Transfusion de produits sanguins labiles [1..1] BL




Si oui, accident transfusionnel [0..1] BL


Administration de dérivés du sang [1..1] BL

Si oui, événements indésirables [0..1] BL


Pose d’un dispositif médical implantable (DMI) durant le séjour

[1..1] BL

Si oui, nature du DMI [0..1] ST

Si oui, site d’implantation [0..1] ST

Traitements

Traitements médicamenteux prescrits à la sortie de l’établissement (ordonnances de sortie)

[1..1] BL

Nom du médicament [1..1] ST

Dose [1..1] PQ

Voie d’administration [1..1] CD

Date de début [1..1] TS

Durée prévue du traitement [1..1] TS

Traitements médicamenteux arrêtés durant le séjour

[1..1] BL

Nom du medicament [1..1] ST

Motif de l’arrêt [1..1] ST

Autres traitements prescrits à la sortie de l’établissement (non médicamenteux)

[1..1] BL

Si oui, lesquels ? [0..1] ST

Résultats d’examens et autres informations

Attente de résultats d’examens à venir ou d’autres informations

[1..1] BL


Suites à donner

Soins ou actes prévus ou à programmer [1..1] BL


Recommandations et surveillances particulières

[1..1] BL

Si oui, lesquelles ? [0..1] ST

Suites à donner d’ordre médico-social [1..1] BL

Si oui, lesquelles ? [0..1] ST

Autres suites à donner [0..1] ST Tableau 2- Données métier de la LDL-SES



3 Spécifications techniques

3.1 Transposition en CDA R2

3.1.1 Standards et spécifications utilisés

Les spécifications techniques de ce volet de contenu définissent les sections, les entrées et les vocabulaires utilisés et sont conformes aux spécifications techniques :

du Cadre d'Interopérabilité des Systèmes d'Information de Santé (CI-SIS) de l’ASIP Santé, en

particulier le CI-SIS - Volet Structuration Minimale de Documents de Santé (2) de la couche

Contenu du Cadre d’Interopérabilité des Systèmes d’Information de Santé (CI-SIS), ce dernier

volet s’appuyant lui-même sur le standard CDA R2, spécifié par HL7 Clinical Document

Architecture Normative Edition (CDA R2) (3).

du domaine international IHE Patient Care Coordination (PCC) (4).

du CI-SIS - Couche Contenu - Volet Modèles de Contenu CDA (5) qui spécifie l'ensemble des

entrées utilisées. Il constitue la référence principale de ce volet.

Le présent document ne présente que les contraintes spécifiques aux documents de la Lettre de Liaison. Il ne reprend pas, sauf si une clarification s'avère nécessaire, les définitions établies dans les standards cités ci-dessus.

3.1.2 Document CDA R2 à corps structuré Tout document CDA possède un en-tête véhiculant le contexte de soins et un corps avec les informations du document.

3.1.2.1 L’en-tête d’un document CDA

L’en-tête fournit le contexte destiné à être affiché au lecteur du document. Une partie des données de l’en-tête alimente les métadonnées qui indexent le document dans un système de partage ou d’échange. Les règles de structuration de l’en-tête CDA et les modèles associés sont spécifiés dans le CI-SIS - Volet Structuration Minimale de Documents de Santé (2).

3.1.2.2 Le corps d’un document CDA

Le corps qui présente le contenu au lecteur sous la forme d’une liste hiérarchisée de sections et fournit les données codées pour le SIS sous la forme d’entrées. On distingue deux grandes catégories de documents CDA :

Les documents à corps non structuré : Le corps encapsule un texte ou une image dans l'un des formats pdf, txt, rtf, jpeg ou tiff.

Les documents à corps structuré : Le corps est organisé en structures de données XML afin de permettre ou simplifier les traitements informatiques. Plus précisément, un tel corps structuré se présente comme un ensemble hiérarchisé de sections. Chacune de ces sections possède un type codé, un titre en clair, et un bloc narratif mis en page pour la visualisation. En outre, un certain nombre d'informations présentes dans le bloc narratif peuvent être répétées, à la suite de ce bloc, sous une forme structurée interprétable par les SI consommateurs du document. La granularité de cette structuration varie alors d'une section à l'autre et d'une donnée à l'autre. Le modèle spécifié par ce volet de contenu est un modèle à corps structuré.

Les 2 modèles de documents de la LDL (LDL-EES et LDL-SES) sont des modèles à corps structuré.



3.1.3 Cardinalités

La cardinalité d'un élément permet d'établir le nombre minimum et maximum d'instances de la classe de cet élément pour une situation donnée. Les différentes cardinalités utilisées dans les volets de contenus du CI-SIS sont exposées dans le tableau suivant.

Card Définition

0..1 Aucune instance obligatoire mais au maximum une instance (l'élément est optionel). Exemple: Nom d'épouse

1..1 Une et une seule instance (l'élément est obligatoire). Exemple: Nom de famille

0..* Aucune instance ou plusieurs (l'élément est optionel mais pas de limite quant au nombre). Exemple: Alias

1..* Au minimum une instance (une instance au moins mais pas de limite quant au nombre). Exemple: adresse

0..n 0 instances au minimum, n instances au maximum (n entier) Exemple: numéro(s) de téléphone

1..n 1 instance au minimum, n instances au maximum (n entier) Exemple: prénoms (n=3)

Tableau 3 - Types des cardinalités

3.1.4 Types des données

Les types des données sont précisés pour chaque élément constituant une entrée du document et sont récapitulés dans le tableau suivant:

Type de données

Définition

ST Le type ST (String) représente une chaîne alphanumérique.

INT Le type INT (Integer) représente un chiffre entier naturel signé ou non.

REAL Le type REAL (Real) représente un chiffre décimal signé ou non.

TS Le type TS (Timestamp) représente un horodatage. Son format et sa précision peuvent être précisés AAAA, JJMMAAAAHHMMSS, etc.

CD

Le type CD (Concept Descriptor) représente un choix effectué sur une liste finie d’éléments (value sets ou jeux de valeurs).

Ce type de données permet l’expression simultanée d’un concept dans plusieurs systèmes de codage. Il permet la post-coordination de codes, ainsi que le transport du texte original dont a été déduit le codage.

PQ

Le type PQ (Physical Quantity) représente une grandeur dimensionnée. Il est en général exprimé par une valeur réelle associée à une unité.

Il peut aussi exprimer la grandeur mesurée dans plusieurs unités différentes.

Le séparateur décimal est le point.

Les unités sont codées selon le référentiel UCUM (http://unitsofmeasure.org/)

BL Le type BL (Boolean) représente un booléen. Les valeurs attendues sont donc true (vrai) ou false (faux).

IVL_PQ Intervalle de grandeurs dimensionnées

IVL_TS Intervalle de dates

IVL_REAL Intervalle de réels non dimensionnés

Tableau 4 - Type des données

http://unitsofmeasure.org/



3.1.5 NullFlavor

La présence d'un certain nombre d'informations est requise, contrainte rendue nécessaire par les spécifications du standard CDA et par des exigences métier. Cette contrainte ne signifie pas que le contenu de ces éléments soit nécessairement renseigné. En effet, dans le cas où l'information est indisponible, l'utilisation de l'attribut nullFlavor permet de l'indiquer et d'en préciser la raison.

Par exemple, au moins une adresse géographique est requis pour le patient (cardinalité [1..*]) mais le médecin de la connait pas au moment de la réalisation du document. Dans ce cas, on peut utiliser un nullFlavor :

<telecom nullFlavor='NAV'>

L'utilisation de la valeur nullFlavor est autorisée pour tous les éléments dont la présence est requise et dont la valeur n'est pas fixée, sauf dans les cas où elle est explicitement interdite auquel cas obligation est faite de renseigner le contenu de l'élément.

Les valeurs les plus courantes pour nullFlavor dans les corps des CDA sont les suivantes:

nullFlavor description

NA Pas de valeur applicable dans ce contexte UNK Valeur inconnue ASKU Demandé mais valeur inconnue NAV Valeur temporairement indisponible NASK Non demandé NI Valeur absente sans autre information OTH Valeur existante, mais non prévue dans la liste proposée pour le codage de l’élément NINF Borne inférieure infinie (pour des valeurs numériques PQ ou REAL) PINF Borne supérieure infinie (pour des valeurs numériques PQ ou REAL) TRC Quantité présente à l’état de trace non quantifiable (pour des valeurs de type PQ ou REAL)

Tableau 5 - Liste des nullFlavor



3.1.6 Éléments narratifs référencés dans les entrées

Les règles de syntaxe de CDA permettent, pour une section donnée, de présenter l'information médicale sous un format texte et de l’accompagner, ou pas, de la même information codée.

La codification des données permet une meilleure intégration et exploitation de ces données médicales par les systèmes d'information consommateurs.

Cette « mixité » texte/code permet une implémentation progressive du modèle métier dans les logiciels tout en préservant l'objectif en cible d'un document entièrement codifié dans les vocabulaires spécifiés.

De plus, CDA permet (cf. (3) § 4.3.5.1) de référencer des éléments du bloc narratif d'une section à partir des entrées de celle-ci. Ce référencement se fait à partir de trois éléments :

La balise <content>, élément optionnel du bloc narratif de la section, qui permet de délimiter la zone de texte à référencer.

L'attribut ID de l'élément <content> est affecté d'un index de valeur unique dans le document, qui permet le référencement de la zone balisée.

Le composant <originalText>, présent dans toute entrée CDA permet de référencer explicitement la zone du bloc narratif associée à cette entrée en pointant sur la valeur de l'index ID de cette zone.

<section>

<code code="10153-2"

codeSystem="2.16.840.1.113883.6.1"

codeSystemName="LOINC"/>

<title>Past Medical History</title>

<text>

Notion d'un <content ID="p1">épisode de dyspnée asthmatiforme</content> dans l'enfance

</text>

<entry>

<observation classCode="OBS" moodCode="EVN">

<code code="J44"

codeSystem="2.16.840.1.113883.6.3"

codeSystemName="CIM10"

displayName="Asthme">

<originalText>

<reference value="#p1"/>

</originalText>

</code>

<statusCode code="completed"/>

</observation>

</entry>

</section>

Exemple 1 – Référencement d'une zone de texte

Zone de texte référencée

Pointeurs sur la zone de texte référencée



3.1.7 Terminologies et jeux de valeurs

Les jeux de valeurs associés aux données sont en général des éléments de vocabulaires codés (code + libellé) pris dans des nomenclatures internationales.

Les nomenclatures les plus communément utilisées dans le CI-SIS sont :

SNOMED 3.5 VF et CIM-10 pour le codage des pathologies : SNOMED 3.5 VF pour la section Allergies and other adverse rections et CIM-10 pour les sections Active problem et History of past illness.

LOINC pour les documents et ses sections CDA

CCAM pour les actes médicaux (section Coded list of surgeries)

CIS (Code Identifiant de Spécialité) et CIP (Code Identifiant de Présentation) pour le codage des médicaments. La compatibilité de ces deux nomenclatures avec les bases de médicaments éventuellement utilisées par les LPS (logiciel de professionnel de santé) des médecins est assurée dans la majorité des cas. Les bases de données principalement utilisées en France1, signataires de la charte de qualité des bases de données sur les médicaments de la DGOS (6), intègrent ces deux nomenclatures comme composants de leur fiche médicament.

etc…

Les éléments d'un même jeu de valeurs pouvant être utilisés pour une donnée peuvent appartenir à des nomenclatures différentes.

Certains jeux de valeurs sont des éléments intégrés au système CDA et sont utilisés comme jeux de valeurs 'système'. Ces derniers ne sont ni modifiables, ni substituables.

Dans un contexte clinique spécifique donné, lorsqu’une valeur n’existe dans aucune nomenclature existante, l’ASIP Santé crée cette nouvelle valeur et l’ajoute dans un jeu de valeur maintenu par l’ASIP Santé. Ces jeux de valeurs sont en général attachés au volet dans lequel ils sont utilisés.

Ce document comprend des termes issus de la nomenclature LOINC® protégés par copyright © et utilisables sans coût dans le respect du "copyright notice and license" publié à l'adresse http://loinc.org/terms-of-use .

3.1.8 Cas des PS et des structures dans les documents médicaux

Le document doit identifier tous les intervenants (personnes physiques et personnes morales) ayant participé aux actes et à la production des résultats listés dans le document, conformément au référentiel des PS et des organisations de santé publié par l’ASIP Santé. Ces intervenants doivent figurer dans le document en regard des actes qu’ils ont effectués ou des résultats qu’ils ont produits ou validés.

Pour un PS, généralement, on indique l’identifiant national du PS propre aux SI de l’ASIP Santé et au CI-SIS, le nom d’exercice, le prénom d’exercice, les adresses de correspondance et de télécommunication, la modalité d’exercice (profession) et la structure de rattachement.

1 Banque Claude Bernard, Vidal, Thesorimed et Thériaque

http://loinc.org/terms-of-use



3.2 Spécifications techniques du modèle Lettre de liaison à l’entrée en établissement de santé (LDL-EES)

3.2.1 Structuration de l'en-tête de la LDL-EES La structure de l'en-tête de ce volet de contenu clinique est conforme aux contraintes et définitions présentées dans le Volet Structuration Minimale du CI-SIS (2). Les contraintes spécifiques à la LDL sont indiquées dans les sections suivantes.

3.2.1.1 templateId – Déclaration de conformité au modèle LDL-EES La déclaration de conformité commune à tous les documents se réclamant du modèle LDL-EES est obligatoire. Elle utilise un élément templateId et vient s'ajouter aux deux déclarations de conformité obligatoires pour tout document CDA compatible avec le CI-SIS - Volet Structuration Minimale de Documents de Santé (2).

Modèle de Document dans l’en-tête CDA Métadonnées XDS DoumentEntry

typeCode typeCodeDisplayName formatCode (codingScheme)

Lettre de Liaison à l’entrée d’un établissement de santé (LDL-EES)

1.2.250.1.213.1.1.1.21

34133-9 Synthèse d’épisode de soins urn:asip:ci-sis:ldl-

ees:2017

(1.2.250.1.213.1.1.4.2.282)

<templateId root="1.2.250.1.213.1.1.1.21"/>

Exemple 2 - Déclaration de conformité au modèle LDL-EES (<templateId>)

3.2.1.2 id – Identifiant du LDL Cet identifiant unique du document est formaté conformément à la spécification du CI-SIS - Volet Structuration Minimale de Documents de Santé (2).

3.2.1.3 code – Type de document L'élément obligatoire code désigne le type de document. Le code 18761-7, représentant le type Note de transfert (dont lettre de liaison à l’entrée en établissement de soins) est tiré d’une nomenclature LOINC, identifiée via son OID 2.16.840.1.113883.6.1.

<code codeSystem="2.16.840.1.113883.6.1" code="18761-7" displayName="Note de transfert (dont lettre de liaison à l’entrée en établissement de soins)"/>

Exemple 3 - Type du document LDL-EES (<code>)

3.2.1.4 title – Titre du document L'élément obligatoire title porte le libellé fixe 'Lettre de Liaison à l’entrée en établissement de santé'.



3.2.1.5 recordTarget – Patient L'identification et les coordonnées du patient sont définies dans l'élément de l'en-tête recordTarget présenté dans CI-SIS - Volet Structuration Minimale de Documents de Santé (2).

Dans le cadre de ce volet au moins un identifiant, le nom, la date de naissance et le sexe du patient sont des éléments obligatoires.

3.2.1.5.1 recordTarget/patientRole/id – Identifiants du patient

Au moins un identifiant est obligatoire et plusieurs identifiants peuvent être utilisés pour identifier un patient :

L’Identifiant National de Santé (INS) L'INS du patient, tel que défini dans le cadre juridique et réglementaire ou de façon transitoire l’INS-C, est obligatoire pour un document mis en partage dans un SI de santé partagé (comme le DMP par exemple). Dans le cadre d’un échange d’un document par messagerie sécurisée de santé, l’INS n’est pas requis.

Autres identifiants possibles Plusieurs autres identifiants peuvent être utilisés, par exemple des identifiants de portée locale (IPP, NIP, etc…), attribués par les systèmes d’information producteurs de données.

3.2.1.5.2 recordTarget/patientRole/addr - adresse du patient

Dans le cadre de ce volet, l’adresse géopostale (<addr>) n’est pas obligatoire. Si aucune adresse n’est connue, utiliser la valeur nullFlavor='UNK'.

3.2.1.5.3 recordTarget/patientRole/telecom - adresse du patient

Dans le cadre de ce volet, les coordonnées de télécommunication (<telecom>) ne sont pas obligatoires. Si aucune coordonnée n’est connue, utiliser la valeur nullFlavor='UNK'.

3.2.1.5.4 recordTarget/patientRole/patient - nom, date de naissance et sexe du patient

Le nom (<name>), le sexe (<administrativeGenderCode>) et la date de naissance (<birthTime>) sont obligatoires et définis dans l’élément <patient>. Si les éléments sexe et date de naissance ne sont pas connus, on peut utiliser la valeur nullFlavor='UNK'.



<recordTarget>

<patientRole>

<id extension="1234567890112345678901" root="1.2.250.1.213.1.4.2"/>

<id extension="2760375106693" root="1.2.250.1.213.1.4.8"/>

<addr use="H">

<houseNumber>24</houseNumber>

<streetNameType>Avenue</streetNameType>

<streetName>de Breteuil</streetName>

<postalCode>75007</postalCode>

<city>Paris</city>

<additionalLocator>Escalier A</additionalLocator>


<city>PARIS</city>

</addr>

<telecom value="tel:0686970800" use="MC"/>

<telecom value="tel:0186940900" use="H"/>

<patient classCode='PSN'>

<name>

<prefix>Mme</prefix>

<given>Alice</given>

<family qualifier='BR'>DECOURCY</family>

</name>

<administrativeGenderCode code='F'/>

<birthTime value='19760318'/>

<birthplace>

<place>

<addr>

<city>Paris</city>


</addr>

</place>

</birthplace>

</patient>

</patientRole>

</recordTarget>

Exemple 4– Patient (<recordTarget>)



3.2.1.6 author – Auteur du document LDL L'élément obligatoire et répétable author désigne le Professionnel de santé (PS) ayant contribué à la rédaction de la LDL. Les règles d'implémentation de l'élément author sont exposées en détail dans CI-SIS - Volet Structuration Minimale de Documents de Santé (2), et sont reprises sans modification dans le cadre de ce volet.

L’auteur d’un document LDL est nécessairement un professionnel de santé.

<author>

<time value="20120328111700+0100"/>

<assignedAuthor classCode="ASSIGNED">



<id root="1.2.250.1.71.4.2.1" extension="801234567897"

assigningAuthorityName="ASIP Santé"/>

<code code="G15_10/SM27" codeSystem="1.2.250.1.213.1.1.4.5"

codeSystemName="RPPS"

displayName="Médecin - Médecine interne (SM)"/>

<addr>


<streetNameType>Rue</streetNameType>

<streetName>rue Rabelais</streetName>


<city>Fontenay-le-Comte Cedex</city>

</addr>

<telecom nullFlavor="NASK"/>

<assignedPerson>

<name>

<given>Charles</given>

<family>RICA</family>

<prefix>Dr.</prefix>

<suffix/>

</name>

</assignedPerson>



<representedOrganization>





<name>Centre Hospitalier de Fontenay-le-Comte</name>

<telecom nullFlavor="NAV"/>

<addr>



<streetName>Rabelais</streetName>



</addr>

<standardIndustryClassCode code="ETABLISSEMENT"

displayName="Établissement de santé"

codeSystem="1.2.250.1.213.1.1.4.9"

codeSystemName="practiceSettingCode"/>

</representedOrganization>

</assignedAuthor>

</author>

Exemple 5- Auteur du document (<author>)



3.2.1.7 custodian – Organisation chargée de la conservation du document

L'élément obligatoire custodian décrit l'organisation chargée de la conservation du document, c'est-à-dire de garder physiquement le document qui lui est confié tout en garantissant son cycle de vie. Les règles d'implémentation de l'élément custodian sont exposées en détail dans CI-SIS - Volet Structuration Minimale de Documents de Santé (2) et sont reprises sans modification dans la cadre de ce volet. Dans la cadre de ce volet, il devrait logiquement s'agir de l'hôpital où la LDL est produite. <custodian typeCode="CST">

<assignedCustodian>

<representedCustodianOrganization>





<addr>






</addr>

</representedCustodianOrganization>

</assignedCustodian>

</custodian>

Exemple 6– Organisation chargée de la conservation du document (<custodian>)

Si l’organisation de l’hôpital nécessite un découpage administratif plus précis, on pourra préciser celui-ci à partir de l’élément <asOrganizationPartOf> associé à l’élément <representedOrganization>, comme il a été procédé dans l’exemple donné pour illustrer l’élément <documentationOf> (cf. §0).

3.2.1.8 legalAuthenticator – Responsable/signataire légal L'élément obligatoire legalAuthenticator représente le responsable du document : le PS qui prend la responsabilité du contenu et dans le cas où la signature électronique est mise en œuvre, en est le signataire légal. Les règles d'implémentation de l'élément legalAuthenticator sont exposées en détail dans CI-SIS - Volet Structuration Minimale de Documents de Santé (2) et sont reprises sans modification.

Dans le cadre de ce volet, il s'agit du professionnel référent de la prise en charge du patient pendant son hospitalisation.

<legalAuthenticator>

<time value="20120329094914-0100"/>

<signatureCode code="S"/>

<assignedEntity>

<realmCode code="FR"/>




<code code="G15_10/SM27" codeSystem="1.2.250.1.213.1.1.4.5" codeSystemName="RPPS"

displayName="Médecin - Médecine interne (SM)"/>

<assignedPerson>

<name>

<given>Léon </given>

<family>AUGUIN</family>

<prefix>Pr.</prefix>

</name>

</assignedPerson>

</assignedEntity>

</legalAuthenticator>

Exemple 7– Responsable/Signataire du document (<legalAuthenticator>)



3.2.1.9 participant – Médecin traitant

Le médecin traitant est un élément obligatoire du modèle LDL.

L'identification et les coordonnées du médecin traitant sont définies dans l'élément de l'en-tête participant dont la structuration est définie dans CI-SIS - Volet Structuration Minimale de Documents de Santé (2) et reprise sans modification dans le cadre de ce volet.

Ses contraintes sont :

C1. L'attribut typeCode de l'élément participant prend la valeur typeCode="INF" pour le médecin traitant dans son rôle d'informateur.

C2. Les attributs de l'élément functionCode sont fixés aux valeurs suivantes : - @code="PCP"

- @displayName="Médecin Traitant"

- @codeSystem="2.16.840.1.113883.5.88"

C3. L'adresse de télécomunication telecom a une cardinalité [1..*] (au lieu de [0..*])

<participant typeCode="INF">

<functionCode code="PCP"

codeSystem="2.16.840.1.113883.5.88"

displayName="Médecin Traitant"/>

<time xsi:type="IVL_TS">

<low value="20120505111700+0100"/>

</time>



<associatedEntity classCode="PROV">



<addr>


<streetNameType>rue</streetNameType>

<streetName>de Chat qui Pêche</streetName>


<city>Paris</city>

</addr>

<telecom value="tel:0147150000" use="WP"/>

<associatedPerson>

<name>




</name>

</associatedPerson>

</associatedEntity>

</participant>

Exemple 8– Médecin traitant (<participant>)



3.2.1.10 participant – PS accompagnant la remise des documents au patient

Le PS accompagnant le patient au moment de la remise des éléments correspondant à des documents d’informations (type brochure) sur la maladie, des documents d’éducation thérapeutique, au carnet de suivi (par exemple, AVK), aux coordonnées des associations patients, etc.

Les règles d’implémentation de l’élément paticipant sont exposées en détail dans CI-SIS - Volet Structuration Minimale de Documents de Santé (2) et sont reprises sans modificaiton dans le cadre de ce volet.


C1. L'attribut typeCode de l'élément participant prend la valeur typeCode="DIST" pour le PS dans son rôle d'accompagnateur.

C2. Les attributs de l'élément functionCode sont fixés aux valeurs suivantes : - @code="APSIN"

- @displayName="PS accompagnant la remise des documents au patient"

- @codeSystem="2.16.840.1.113883.5.88"



<participant typeCode="DIST">

<functionCode code="APSIN" codeSystem="2.16.840.1.113883.5.88"

displayName="PS accompagnant la remise des documents au patient"/>

<time xsi:type="IVL_TS">

<low value="20120505111700+0100"/>

</time>

<associatedEntity classCode="PROV">




<code code="G15_10/SM27" codeSystem="1.2.250.1.213.1.1.4.5"

codeSystemName="RPPS"

displayName="Médecin - Médecine Interne (SM)"/>

<associatedPerson>

<name>

<given>Léon</given>



</name>

</associatedPerson>

</associatedEntity>

</participant>

Exemple 9 - PS accompagnant la remise des documents au patient (<participant>)



3.2.1.11 documentationOf – Acte(s) documenté(s)

documentationOf est un élément obligatoire et répétable représentant le (ou les) acte(s) documenté(s) par le document.

Les règles d'implémentation de l'élément documentationOf sont exposées en détail dans CI-SIS - Volet Structuration Minimale de Documents de Santé (2).

Contraintes :

C1. Acte principal documenté : <documentationOf/serviceEvent/code> Les attributs de cet élément prennent les valeurs suivantes :

o @code="P0-10000"

o @displayName="Hospitalisation"

o @codeSystem="1.2.250.1.213.2.12"

o @codeSystemName="SNOMED 3.5"

C2. Lieu d'exercice du PS : <representedOrganization>

Cet élément permet, si on l'utilise avec le sous-élément <asOrganizationOf>, d'identifier respectivement le service dans lequel est hospitalisé le patient et l'hôpital dont le service est une composante.

C3. Professionnel ayant effectué la prise en charge : <performer>

Cet élément permet d'identifier le professionnel ayant effectué la prise en charge (il s'agit en pratique de la personne identifiée comme <legalAuthenticator>) qui est identifié avec les éléments suivants:

o performer/assignedEntity/id pour son numéro RPPS o performer/assignedEntity/code pour sa qualification professionnelle o performer/assignedEntity/assignedPerson pour son état civil

C4. Le service auquel est rattaché le PS : <representedOrganization>

Cet élément permet d’identifier la structure infra-hospitalière (le service) du PS ayant effectué la prise en charge du patient.

C5. La structure hospitalière à laquelle est rattaché le service: <representedOrganization/asOrganizationPartOf>

Notes :

La LDL peut être réalisée par un auteur appartenant à l'un de ces deux services.

La LDL permet de décrire plusieurs séjours d’un même épisode de soins. Les séquences composant le séjour peuvent ne pas se dérouler dans des services différents et des établissements différents. (voir les exemples ci-après).



<documentationOf>

<serviceEvent>

<code code="P0-10000" displayName="Hospitalisation"

codeSystem="1.2.250.1.213.2.12" codeSystemName="SNOMED 3.5"/>

<effectiveTime>



<low value="201507011200+0100"/>



<high value="201509301605+0100"/>

</effectiveTime>

<performer typeCode="PRF">

<templateId root="1.3.6.1.4.1.19376.1.3.3.1.7"/>

<time>

<high value="201503021605+0100"/>

</time>

<assignedEntity>



<idroot="1.2.250.1.71.4.2.1" extension="801234567897"


<code code="G15_10/SM27" displayName="Médecin - Médecine interne (SM)"

codeSystem="1.2.250.1.213.1.1.4.5" codeSystemName="RPPS"/>

<assignedPerson>

<name>




</name>

</assignedPerson>


<name>Service de Cardiologie</name>


<standardIndustryClassCode code="ETABLISSEMENT"

displayName="Établissement de santé"

codeSystem="1.2.250.1.213.1.1.4.9" codeSystemName="practiceSettingCode"/>

<asOrganizationPartOf>

<wholeOrganization>







<addr>


<streetNameType>Rue Rabelais </streetNameType>



</addr>

</wholeOrganization>

</asOrganizationPartOf>


</assignedEntity>

</performer>

</serviceEvent>

</documentationOf>

Exemple 10 – Acte documenté par le document (<documentationOf>)



Si le patient a séjourné dans plusieurs services/hôpitaux, il est possible, lors de la rédaction de la lettre de liaison, de mentionner les différentes séquences de l’épisode de soins.

La cardinalité [1..*] de l'élément <documentationOf> le permet.

Les dates d'entrée et de sortie des structures de soins permettent alors d'ordonner chronologiquement les différentes séquences de cet épisode de soins.

Dans l’exemple ci-dessous, le parcours de soins du patient comprend :

Un séjour aux urgences psychiatriques du 01/07/2015 au 03/07/2015 et

Un séjour en médecine interne du 03/07/2015 au 30/09/2015.



<documentationOf>

<serviceEvent>



<effectiveTime>


<low value="201507011200+0100"/>


<high value="201507031605+0100"/>

</effectiveTime>

<performer>

<assignedEntity>

<id root="1.2.250.1.71.4.2.1" extension="801234567897"/>

<code code="G15_10/SM42" displayName="Médecin - Psychiatrie (SM)"


<assignedPerson>

<name>

<given>Gisèle</given>

<family>SOULARD</family>


</name>

</assignedPerson>


<name>Service d'Urgences Psychiatriques</name>

:

</documentationOf>



<documentationOf>

<serviceEvent>



<effectiveTime>


<low value="201507031605+0100"/>


<high value="201509301605+0100"/>

</effectiveTime>

<performer>

<assignedEntity>


<code code="G15_10/SM27" displayName="Médecin - Médecine Interne (SM)"


<assignedPerson>

<name>




</name>

</assignedPerson>


<name>Service de Médecine Interne</name>

:

</documentationOf>

Exemple 11 – Acte documenté par le document (<documentationOf>) - Prise en charge par deux services



3.2.1.12 relatedDocument - Version antérieure à remplacer relatedDocument est un élément qui référencie une version antérieure du document courant.

Les règles d'implémentation de l'élément relatedDocument sont exposées en détail dans CI-SIS - Volet Structuration Minimale de Documents de Santé (2).

La première version d’une LDL ne comporte pas d’élément <relatedDocument>.

Les versions successives de cette LDL, produites pour compléter la LDL initiale ou les versions qui ont suivies (par exemple pour intégrer des résultats d’examens), comporteront un élément <relatedDocument> faisant référence à la version à remplacer.



<relatedDocument typeCode="RPLC">

<parentDocument>



<id root="1.2.250.1.213.1.1.9" extension="A7102400008_0444"/>

</parentDocument>

</relatedDocument>

Exemple 12 - Version à remplacer (<relatedDocument>)

3.2.1.13 componentOf - Association du document à une prise en charge L'élément componentOf, obligatoire, relie la LDL à la prise en charge du patient par un PS ou par un établissement, dans le contexte dans lequel ce document a été produit.

Les règles d'implémentation de l'élément componentOf sont exposées dans le CI-SIS - Volet Structuration Minimale de Documents de Santé (2) et sont reprises sans modification dans le cadre de ce volet.

Dans le cadre du volet LDL et dans le cas où le patient a été hospitalisé dans des structures de soins différentes ou des services différents d'une même structure de soins, il est recommandé que la LDL soit écrite par la personne ayant pris en charge le patient en dernier.

<componentOf>

<encompassingEncounter>

<code/>

<effectiveTime>

<low value="20120328111700+0100"/>

<high value="20120401111700+0100"/>

</effectiveTime>

<location>

<healthCareFacility>


<code code="SA01" displayName="Etablissement Public de Santé"

codeSystem="1.2.250.1.71.4.2.4" codeSystemName="R02"/>

</healthCareFacility>

</location>

</encompassingEncounter>

</componentOf>

Exemple 13 – Association du document à une prise en charge (<componentOf>)



3.2.2 Structuration du corps de la LDL-EES

3.2.2.1 Correspondance entre le modèle métier de la LDL-EES et le document au format CDA

Le modèle du document LDL-EES décrit les éléments nécessaires à la venue du patient en établissement de santé. Il comporte les sections listées dans le tableau ci-dessous.

Modèle métier card. Section Code LOINC Entrées

Motif d’hospitalisation Liste des pathologies diagnostiquées avant la prise en charge par l'hôpital et des symptômes initiaux qui motivent l'hospitalisation du patient.

[1..1]

Raison de la recommandation (Reason for referral) 1.3.6.1.4.1.19376.1.5.3.1.3.1

42349-1 Raison de la recommandation

Pas d'entrée

Traitements en cours et allergies connues Traitements en cours et allergies connues du patient avant sont arrivée en établissement de soins.

[1..1]

Liste des problèmes actifs (ActiveProblem) 1.3.6.1.4.1.19376.1.5.3.1.3.6

11450-4 Liste des problèmes actifs

Pathologies non allergiques (Problem Concern Entry) 1.3.6.1.4.1.19376.1.5.3.1.4.5.2

Autres informations Toutes autres informations utiles concernant le patient avant son entrée en établissement de soins.

[1..1]

Commentaire (section spécifique ASIP Santé) 1.2.250.1.213.1.1.2.47

48767-8 Commentaire

Simple observation (Simple observation) 1.3.6.1.4.1.19376.1.5.3.1.4.13

Tableau 6- Sections et entrées utilisées dans le modèle LDL-EES



3.2.2.2 Exemple de structuration au format CDA de la LDL-EES

<ClinicalDocument xmlns="urn:hl7-org:v3">


<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>



<templateId root="2.16.840.1.113883.2.8.2.1"/>



<templateId root="1.2.250.1.213.1.1.1.1"/>



<templateId root="1.2.250.1.213.1.1.1.21"/>

<id ……/>

<code code="18761-7" displayName="Note de transfert (dont lettre de liaison à l’entrée en

établissement de soins)"

codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>

<title>Lettre de liaison à l'entrée en établissement de santé</title>

<effectiveTime value=" 20160810"/> <confidentialityCode code="N" displayName="Normal"

codeSystem="2.16.840.1.113883.5.25" codeSystemName="Confidentiality"/>

<languageCode code="fr-FR"/>

:

<component>

<structuredBody>



<component>

<section>

<templateId root=" 1.2.250.1.213.1.1.2.47"/>

:

<code code="48767-8" displayName="Commentaire"


<title>Autres informations</title>

:

</section>

</component>

:

Exemple 14- Structuration générale d’un document LDL-EES à l’entrée de l’établissement de soins



3.2.2.3 Section Raison de la recommendation (Reason for referral - 1.3.6.1.4.1.19376.1.5.3.1.3.1)

Cette section permet d'identifier la ou les pathologies diagnostiquées avant la prise en charge par l'hôpital ou les symptômes initiaux qui motivent l'hospitalisation du patient. L'information est portée par le bloc narratif de la section (pas d'entrée).

Niv Elément XML card Contenu de l’élément ou valeur de l’attribut

0 section [1..1] Section Raison de la recommendation

1 templateId [1..1] Déclaration de conformité root='1.3.6.1.4.1.19376.1.5.3.1.3.1'

1 id [0..1] Identifiant de la section

1 code [1..1]

Les attributs de cet élément prennent les valeurs suivantes : code='42349-1'

displayName='Raison de la recommandation'

codeSystem='2.16.840.1.113883.6.1'

codeSystemName='LOINC'

1 title [0..1] Titre de la section. Fixé à 'Motif d'hospitalisation'

1 text [1..1] Partie narrative de la section

Tableau 7 - Structuration des données de la section Raison de la recommendation

<!— Section Raison de la recommendation (Reason for referral) ->

<component>

<section>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.1"/>

<id root='3f8201b6-e1dc-4093-ae73-62e6df2212a2'/>

<code code="42349-1" displayName="Raison de la recommandation"


<title>Motif d'hospitalisation</title>

<text>

<table border="1">

<tbody align="left">

<tr><td>Episode psychotique - cachexie/anorexie</td></tr>

</tbody>

</table>

</text>

</section>

</component>

Exemple 15 – Section Raison de la recommendation



3.2.2.4 Section Liste des problèmes actifs (ActiveProblem - 1.3.6.1.4.1.19376.1.5.3.1.3.6)

Cette section permet de renseigner les traitements en cours et allergies connues du patient avant son arrivée en établissement de soins.

Niv Elément XML card. Contenu de l’élément ou valeur de l’attribut

0 section [0..1] Section Liste des problèmes actifs

1 templateId [1..1] Déclaration de conformité root="1.3.6.1.4.1.19376.1.5.3.1.3.6"

root="2.16.840.1.113883.10.20.1.11"

1 id [0..1] Identifiant de la section

1 code [1..1]


displayName=’Liste des problèmes actifs’

codeSystem='2.16.840.1.113883.6.1'


1 title [0..1] Titre de la sous-section. Fixé à 'Traitements et allergies connues'

1 text [1..1] Partie narrative de la section.

1 entry [1..*]

Entrée de type Pathologies non allergiques (Problem Concern Entry -

1.3.6.1.4.1.19376.1.5.3.1.4.5.2)

Les spécifications de cette entrée décrites dans PCC sont reprises ici sans contraintes spécifiques.

2 act [1..1] Les attributs de cet élément sont fixés aux valeurs suivantes:

classCode="ACT" moodCode="EVN"

3 temlpateId [3..3]

Déclarations de conformité root="2.16.840.1.113883.10.20.1.27"

root="1.3.6.1.4.1.19376.1.5.3.1.4.5.1"

root="1.3.6.1.4.1.19376.1.5.3.1.4.5.2"

3 id [1..1] Identifiant de l'act, il a la forme UID (UUID ou OID)

3 code [1..1] Valeur fixée à nullFlavor='NA'

3 statusCode [1..1] L’attribut code de cet élément est fixé à la valeur «completed»

3 effectiveTime [1..1] Date de mise à jour de l’information.

3 entryRelationship [1..*] Problème L’attribut typeCode de l’élement entryRelationship est fixé à la valeur ’SUBJ’

4 Observation [1..1]

Elément de type Problem Entry Ses attributs sont fixés aux valeurs suivantes:

classCode="OBS"

moodCode="EVN"

5 templateId [2..2] Déclarations de conformité root="2.16.840.1.113883.10.20.1.28"

root="1.3.6.1.4.1.19376.1.5.3.1.4.5"

5 id [1..1] Il a la forme UID (UUID ou OID)

5 code [1..1]

Les attributs de l'élément prennent les valeurs suivantes:

code="G-1009"

displayName="Diagnostic"

codeSystem="1.2.250.1.213.2.12"

codeSystemName="SNOMED 3.5"

5 text [1..1] Partie narrative de l’entrée

6 reference [1..1] Valeur renvoyant à la partie narrative de la section

5 statusCode [1..1] Valeur fixée à «completed»

5 effectiveTime [1..1] Date de l’observation.

5 value [1..1] Valeur codée de l’observation pour préciser le problème




3 entryRelationship [1..*] Traitements L’attribut typeCode de l’élement entryRelationship est fixé à la valeur ’REFR’


Elément de type Simple Observation Ses attributs sont fixés aux valeurs suivantes:

classCode="OBS"

moodCode="EVN"

5 templateId [1..1] Déclarations de conformité root='1.3.6.1.4.1.19376.1.5.3.1.4.13'


5 code [1..1]


code="MED-156"

displayName="Traitements connus"

codeSystem="1.2.250.1.213.1.1.4.322"

codeSystemName="TA_ASIP"



5 statusCode [1..1] Valeur fixée à ’completed’


5 value [1..1] Valeur booléenne (xsi:type="BL") pour préciser s’il y a des traitements en cours ou pas

3 entryRelationship [0..*] Description des traitements L’attribut typeCode de l’élement entryRelationship est fixé à la valeur ’REFR’



classCode="OBS"

moodCode="EVN"



5 code [1..1]


code="GEN-089"

displayName="description"

codeSystem="1.2.250.1.213.1.1.4.322"




5 statusCode [1..1] Valeur fixée à ’completed’


5 value [1..1] Valeur textuelle (xsi:type="ST") pour décrire les traitements en cours

3 entryRelationship [1..*] Allergies connues L’attribut typeCode de l’élement entryRelationship est fixé à la valeur ’REFR’



classCode="OBS"

moodCode="EVN"






5 code [1..1]


code="MED-155"

displayName="Allergies connues"

codeSystem="1.2.250.1.213.1.1.4.322"




5 statusCode [1..1] Valeur fixée à ‘completed’


5 value [1..1] Valeur booléenne (xsi:type="BL") de l’observation pour préciser s’il y a des allergies connues

3 entryRelationship [0..*] Description des allergies connues L’attribut typeCode de l’élement entryRelationship est fixé à la valeur ’REFR’



classCode="OBS"

moodCode="EVN"



5 code [1..1]


code="GEN-089"


codeSystem="1.2.250.1.213.1.1.4.322"




5 statusCode [1..1] Valeur fixée à ‘completed’


5 value [1..1] Valeur tectuelle (xsi:type="ST") de l’observation pour décrire les allergies connues

Tableau 8 - Structuration des données de la section Liste des problèmes actifs





<component>

<section>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.6"/>

<templateId root="2.16.840.1.113883.10.20.1.11"/>

<id root="b841c1b2-6374-44f0-9640-ca1b46e69870"/>

<code code='11450-4' displayName=’Liste des problèmes actifs’


<title>Traitements et allergies connus</title>

<text>

<table border="1">

<thead>

<tr><th>Date</th><th>Traitement</th></tr>

</thead>

<tbody>

<tr>

<td>06/12/2016</td>

<td><content ID="TraitementConnus">Oui</content></td>

</tr>

<tr>

<td>06/12/2016</td>

<td><content ID="descriptionTraitements">PLAVIX</content></td>

</tr>

</tbody>

</table>

<table border="1">

<thead>

<tr><th>Date</th><th><content ID="allerg">Allergies</content></th></tr>

</thead>

<tbody>

<tr>

<td>06/12/2016</td>

<td>

<content ID="AllergiesConnues">Oui</content>

</td>

</tr>

<tr>

<td>06/12/2016</td>

<td><content ID="descriptionAllergies">Allergie

Médicamenteuse</content></td>

</tr>

</tbody>

</table>

</text>



<entry>

<act classCode='ACT' moodCode='EVN'>

<templateId root="2.16.840.1.113883.10.20.1.27"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.1"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.2"/>

<id root="d56d4739-a486-4d4a-856b-be7571c0a41c"/>

<code nullFlavor="NA"/>


<effectiveTime nullFlavor="NASK"/>

<entryRelationship typeCode="SUBJ">


<templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.5'/>

<templateId root="2.16.840.1.113883.10.20.1.28"/>

<id root="1f3d5406-46a4-4ad0-b92c-67934eb86f05"/>

<code code="G-1009" displayName="Diagnostic"

codeSystem="1.2.250.1.213.2.12"/>

<text>

<reference value="allerg"></reference>

</text>


<effectiveTime>

<low value="20120328111700+0100"/>

</effectiveTime>

<value xsi:type="CD" code="T78.4" displayName="Allergie"

codeSystem="2.16.840.1.113883.6.3" codeSystemName="CIM10">

<originalText>

<reference value="allerg"></reference>



</originalText>

</value>

</observation>

</entryRelationship>



<entryRelationship typeCode="REFR">


<templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.13'/>

<id root="4a197a91-fc28-4995-a8eb-92a9ab8f0996"/>

<code code="MED-156" displayName="Traitements connus"

codeSystem="1.2.250.1.213.1.1.4.322"

codeSystemName="TA_ASIP"/>

<text>

<reference value="TraitementsConnus"></reference>

</text>


<effectiveTime>

<low value="20120328111700+0100"/>

</effectiveTime>

<value xsi:type="BL" value="true"/>

</observation>






<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="76cd365c-2714-4fd8-bb3a-9fa6f13b9045"/>

<code code="GEN-089" displayName="description"

codeSystem="1.2.250.1.213.1.1.4.322" codeSystemName="TA_ASIP"/>

<text>

<reference value="#descriptionTraitements"/>

</text>


<effectiveTime>

<low value="20120328111700+0100"/>

</effectiveTime>

<value xsi:type="ST">PLAVIX</value>

</observation>






<templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.13'/>

<id root="473da754-04fa-429f-9b14-23bcf867a826"/>

<code code="MED-155" displayName="Allergies connues"


<text>

<reference value="AllergiesConnues"></reference>

</text>


<effectiveTime>

<low value="20120328111700+0100"/>

</effectiveTime>

<value xsi:type="BL" value="true"/>

</observation>






<templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.13'/>

<id root="69c1134e-ba17-430b-b5f4-7bb1392f91f2"/>

<code code="GEN-089" displayName="description"


<text>

<reference value="#descriptionAllergies"/>

</text>


<effectiveTime>

<low value="20120328111700+0100"/>

</effectiveTime>

<value xsi:type="ST">Allergies alimentaires</value>

</observation>




</act>

</entry>

</section>

</component>

Exemple 16- Section Liste des problèmes actifs



3.2.2.5 Section Commentaire (Section spécifique ASIP Santé - 1.2.250.1.213.1.1.2.47)

Cette section permet de renseigner toutes autres informations utiles concernant le patient avant son entrée en établissement de santé.


0 section [0..1] Section Commentaire

1 templateId [2..2] Déclarations de conformité root="1.2.250.1.213.1.1.2.47"


1 code [1..1]

Les attributs de cet élément prennent les valeurs suivantes :

code="48767-8"

displayName="Commentaire"

codeSystem="2.16.840.1.113883.6.1"

codeSystemName="LOINC"

1 title [0..1] Titre de la sous-section. Fixé à "Autres informations"


1 entry [1..1] Entrée de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5) sont reprises ici sans contraintes spécifiques.

2 observation [1..1]

Un élèment de type observation est utilisé pour porter l’information. Valeur des attributs de l’observation:

classCode=’OBS’

moodCode=’EVN’

3 templateId [1..1] Déclaration de conformité

root="1.3.6.1.4.1.19376.1.5.3.1.4.13"

3 id [1..1] Identifiant de l'observation. Il aura la forme UID (UUID ou OID)

3 code [1..1]

Les attributs de l'élément <code> prennent les valeurs suivantes:

code='GEN-091'

displayName='Autre information'

codeSystem='1.2.250.1.213.1.1.4.322'

codeSystemName='TA_ASIP'



3 statusCode [1..1] Valeur fixée à 'completed'

3 effectiveTime [1..1] Dans le cas où la date n’est pas connue, la valeur ‘nullFlavor’ est autorisée.

3 value [1..1] Valeur booléenne pour préciser s’il y a d’autres informations à renseigner

1 entry [0..1] Entrée de type Simple Observation

(1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5) sont reprises ici sans contraintes spécifiques.



classCode=’OBS’

moodCode=’EVN’

3 templateId [1..1] Déclaration de conformité

root="1.3.6.1.4.1.19376.1.5.3.1.4.13"

3 id [1..1] Identifiant de l'observation. Il aura la forme UID (UUID ou OID)

3 code [1..1]


code='GEN-089'

displayName='description'

codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Valeur textuelle pour indiquer toute autre information




1 entry [0..1] Entrée de type Simple Observation

(1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications, décrites dans (5), sont reprises ici sans contraintes spécifiques.



classCode=’OBS’

moodCode=’EVN’

3 templateId [1..1] déclaration de conformité

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

3 id [1..1] Identifiant de l'observation. Obligatoire, il aura la forme UID (UUID ou OID)

3 code [1..1]


code='CDA_008'

displayName='Objet du commentaire'

codeSystem='1.2.250.1.213.1.1.4.2.286'

codeSystemName='TA_CDA'





3 value [1..1] Valeur textuelle pour indiquer toute autre information

Tableau 9- Structuration des données de la section Commentaire



<component>

<section>

<templateId root="1.2.250.1.213.1.1.2.47"/>

<id root="a6c982f6-acae-4cdc-a901-c400ab8972e6"/>

<code code="48767-8" displayName="Commentaire"

codeSystem="2.16.840.1.113883.6.1"

codeSystemName="LOINC"/>

<title>Autres informations</title>

<text>

<table border="1">

<thead>

<tr><th colspan="3">Commentaires</th></tr>

</thead>

<tbody>

<tr><td><content ID="autreInf">Non</content></td></tr>

<tr><td><content ID="descriptionAutreInfo">-</content></td></tr>

</tbody>

</table>

</text>

<entry>


<templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.13'/>

<id root="ad5c6f5a-0225-46d7-bdf2-ee496e06f190"/>

<code code="GEN-091" displayName="Autre information"

codeSystem="1.2.250.1.213.1.1.4.322" codeSystemName="TA_ASIP »/>

<text>

<reference value=”autreInf”></reference>

</text>

<statusCode code=”completed”/>

<effectiveTime value=’20110314’/>

<value xsi:type=”BL” value=”true”/>

</observation>

</entry>

<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="d9a9a520-a701-4a21-95d5-33dda9b6d5e6"/>

<code code="GEN-089"


codeSystem="1.2.250.1.213.1.1.4.322"

codeSystemName="TA_ASIP"/>

<text>

<reference value="descriptionAutreInfo"/>



</text>


<effectiveTime value="20110314"/>

<value xsi:type="ST">-</value>

</observation>

</entry>

</section>

</component>

Exemple 17- Section Commentaire



3.3 Spécifications techniques du modèle Lettre de Liaison à la sortie de l’établissement de santé (LDL-SES)

3.3.1 Structuration de l’en-tête de la LDL-SES La structure de l’en-tête d’une LDL-SES est conforme aux contraintes et définitions présentées dans le CI-SIS – Volet Structuration Minimale de Documents de Santé (2). Les contraintes spécifiques à la LDL sont indiquées dans les sections suivantes.

3.3.1.1 templateId – Déclaration de conformité au modèle LDL-SES Elle utilise un élément templateId et vient s’ajouter aux deux déclarations de conformité obligatoires pour tout document CDA compatible avec le CI-SIS – Volet Structuration Minimale de Documents de Santé (2).

Modèle de Document dans l’en-tête CDA Métadonnées XDS DoumentEntry

typeCode typeCodeDisplayName formatCode (codingScheme)

Lettre de Liaison à la sortie de l’établissement de santé (LDL-SES)

1.2.250.1.213.1.1.1.29

11490-0 Lettre de liaison à la sortie d’un établissement de soins

urn:asip:ci-sis:ldl-

ses:2017

(1.2.250.1.213.1.1.4.2.282)

<templateId root= »1.2.250.1.213.1.1.1.29 »/>

Exemple 18 – Déclaration de conformité au modèle LDL-SES pour un document CDA

3.3.1.2 id – Identifiant du LDL Cet identifiant unique du document est formaté conformément à la spécification du CI-SIS – Volet Structuration Minimale de Documents de Santé (2).

3.3.1.3 code – Type de document L’élément obligatoire code désigne le type de document. Le code 11490-0, représentant le type Lettre de liaison à la sortie d’un établissement de soins, est tiré d’une nomenclature LOINC, identifiée dont l’OID est 2.16.840.1.113883.6.1.

<code codeSystem= »2.16.840.1.113883.6.1 » code= »11490-0 » displayName= »Lettre de

liaison à la sortie d’un établissement de soins »/>

Exemple 19 – Type du document LDL-SES

3.3.1.4 title – Titre du document L’élément obligatoire title porte le libellé fixe ‘Lettre de liaison à la sortie de l’établissement de santé’.



3.3.1.5 recordTarget – Patient L’identification et les coordonnées du patient sont définies dans l’élément de l’en-tête recordTarget présenté dans le CI-SIS – Volet Structuration Minimale de Documents de Santé (2).

Dans le cadre de ce volet au moins un identifiant, le nom, la date de naissance et le sexe du patient sont des éléments obligatoires.

3.3.1.5.1 recordTarget/patientRole/id – Identifiants du patient

Au moins un identifiant est obligatoire et plusieurs identifiants peuvent être utilisés pour identifier un patient :

L’Identifiant National de Santé (INS) L'INS du patient, tel que défini dans le cadre juridique et réglementaire ou de façon transitoire l’INS-C, est obligatoire pour un document mis en partage dans un SI de santé partagé (comme le DMP par exemple). Dans le cadre d’un échange d’un document par messagerie sécurisée de santé, l’INS n’est pas requis.

Autres identifiants possibles Plusieurs autres identifiants peuvent être utilisés, par exemple des identifiants de portée locale (IPP, NIP, etc…), attribués par les systèmes d’information producteurs de données.

3.3.1.5.2 recordTarget/patientRole/addr – adresse du patient

Dans le cadre de ce volet, l’adresse géopostale (<addr>) n’est pas obligatoire. Si aucune adresse n’est connue, utiliser la valeur nullFlavor=’UNK’.

3.3.1.5.3 recordTarget/patientRole/telecom – adresse du patient

Dans le cadre de ce volet, les coordonnées de télécommunication (<telecom>) ne sont pas obligatoires. Si aucune coordonnée n’est connue, utiliser la valeur nullFlavor=’UNK’.

3.3.1.5.4 recordTarget/patientRole/patient – nom, date de naissance et sexe du patient

Le nom (<name>), le sexe (<administrativeGenderCode>) et la date de naissance (<birthTime>) sont obligatoires et définis dans l’élément <patient>. Si les éléments sexe et date de naissance ne sont pas connus, on peut utiliser la valeur nullFlavor=’UNK’.



<recordTarget>

<patientRole>

<id extension=”1234567890112345678901” root=”1.2.250.1.213.1.4.2”/>

<addr use=”H”>


<streetNameType>Avenue</streetNameType>

<streetName>de Breteuil</streetName>



<city>PARIS</city>

</addr>

<telecom value=”tel:0686970800” use=”MC”/>

<patient classCode=’PSN’>

<name>

<prefix>Mme</prefix>

<given>Alice</given>

<family qualifier=’BR’>DECOURCY</family>

</name>

<administrativeGenderCode code=’F’/>

<birthTime value=’19760318’/>

<birthplace>

<place>

<addr>

<city>PARIS</city>


</addr>

</place>

</birthplace>

</patient>

</patientRole>

</recordTarget>

Exemple 20 – Patient (<recordTarget>)



3.3.1.6 author – Auteur du document L’élément obligatoire et répétable author désigne le PS ayant contribué à la rédaction du LDL. Les règles d’implémentation de l’élément author sont exposées en détail dans le CI-SIS – Volet Structuration Minimale de Documents de Santé (2) et sont reprises sans modification dans le cadre de ce volet.

L’auteur d’un document LDL est nécessairement un professionnel de santé.

<author>

<time value=”20120328111700+0100”/>

<assignedAuthor classCode=”ASSIGNED”>

<!–PS identifié par son N°RPPS

<id root=”1.2.250.1.71.4.2.1” extension=”801234567897”

assigningAuthorityName=”ASIP Santé”/>

<code code=”G15_10/SM27” codeSystem=”1.2.250.1.213.1.1.4.5”

codeSystemName=”RPPS”

displayName=”Médecin – Médecine interne (SM)”/>

<addr>



<streetName>rue Rabelais</streetName>



</addr>

<telecom nullFlavor=”NASK”/>

<assignedPerson>

<name>




<suffix/>

</name>

</assignedPerson>

<!–Numéro FINESS de l’ES (optionnel)


<!–établissement identifié par son N° FINESS




<telecom nullFlavor=”NAV”/>

<addr>






</addr>

<standardIndustryClassCode code=”ETABLISSEMENT”

displayName=”Établissement de santé”

codeSystem=”1.2.250.1.213.1.1.4.9”

codeSystemName=”practiceSettingCode”/>


</assignedAuthor>

</author>

Exemple 21 – Auteur du document (<author>)



3.3.1.7 custodian – Organisation chargée de la conservation du document L’élément obligatoire custodian décrit l’organisation chargée de la conservation du document, c’est-à-dire de garder physiquement le document qui lui est confié tout en garantissant son cycle de vie. Les règles d’implémentation de l’élément custodian sont décrites dans le CI-SIS – Volet Structuration Minimale de Documents de Santé (2) et sont reprises sans modification dans la cadre de ce volet. Dans la cadre de ce volet, il devrait logiquement s’agir de l’hôpital où le document est produit.

<custodian typeCode=”CST”>

<assignedCustodian>

<representedCustodianOrganization>





<addr>






</addr>

</representedCustodianOrganization>

</assignedCustodian>

</custodian>

Exemple 22 – Organisation chargée de la conservation du document (<custodian>)

Si l’organisation de l’hôpital nécessite un découpage administratif plus précis, on pourra préciser celui-ci à partir de l’élément <asOrganizationPartOf> associé à l’élément <representedOrganization>, comme décrit dans l’exemple donné pour illustrer l’élément <documentationOf> de la LDL-EES (cf. LDL-EES §3.2.1.11).



3.3.1.8 informationRecipient – Destinataire en copie

L’élément obligatoire informationRecipient décrit le destinataire en copie du document

Les règles d’implémentation de l’élément informationRecipient sont sont décrites dans le CI-SIS – Volet Structuration Minimale de Documents de Santé (2) et sont reprises sans modification.

<informationRecipient>

<intendedRecipient>


<informationRecipient>

<name>NomDestinataire</name>

</informationRecipient>

<receivedOrganization>


<name>LE 15</name>

</receivedOrganization>

</intendedRecipient>

</informationRecipient>

Exemple 23 –Destinataire en copie du document (<informationRecipient>)

3.3.1.9 LegalAuthenticator – Responsable/signataire légal

L’élément obligatoire legalAuthenticator représente le responsable du document : le PS qui prend la responsabilité du contenu et dans le cas où la signature électronique est mise en œuvre, en est le signataire légal.

Les règles d’implémentation de l’élément legalAuthenticator sont sont décrites dans le CI-SIS – Volet Structuration Minimale de Documents de Santé (2) et sont reprises sans modification.

Dans le cadre de ce volet, il s’agit du professionnel référent de la prise en charge du patient pendant son hospitalisation.

<legalAuthenticator>

<time value=”20120329094914-0100”/>

<signatureCode code=”S”/>

<assignedEntity>

<realmCode code= »FR »/>

< !–PS identifié par son N°RPPS



<code code=”G15_10/SM27” codeSystem=”1.2.250.1.213.1.1.4.5” codeSystemName=”RPPS”

displayName=”Médecin – Médecine interne (SM)”/>

<assignedPerson>

<name>




</name>

</assignedPerson>

</assignedEntity>

</legalAuthenticator>

Exemple 24 – Signataire du document (<legalAuthenticator>)



3.3.1.10 Participant – Médecin traitant Le médecin traitant est un élément obligatoire du modèle LDL.

L’identification et les coordonnées du médecin traitant sont définies dans l’élément de l’en-tête participant dont la structuration est définie dans dans le CI-SIS – Volet Structuration Minimale de Documents de Santé (2) et reprise sans modification dans le cadre de ce volet.


C1. L’attribut typeCode de l’élément participant prend la valeur typeCode= »INF » pour le Médecin traitant dans son rôle d’informateur.

C2. Les attributs de l’élément functionCode sont fixés aux valeurs suivantes : @code= »PCP »

@displayName= »Médecin Traitant »

@codeSystem= »2.16.840.1.113883.5.88 »

C3. L’adresse de télécomunication telecom a une cardinalité [1..*] (au lieu de [0..*])

<participant typeCode= »INF »>

<functionCode code= »PCP »

codeSystem= »2.16.840.1.113883.5.88 »

displayName= »Médecin Traitant »/>

<associatedEntity classCode=”PROV”>



<addr>


<streetNameType>rue</streetNameType>

<streetName>de Chat qui Pêche</streetName>


<city>Paris</city>

</addr>

<telecom value=”tel:0147150000” use=”WP”/>

<associatedPerson>

<name>




</name>

</associatedPerson>

</associatedEntity>

</participant>

Exemple 25 – Médecin traitant (<participant>)



3.3.1.11 documentationOf – Acte(s) documenté(s)

documentationOf est un élément obligatoire et répétable représentant le (ou les) acte(s) documenté(s) par le document.

Les règles d’implémentation de l’élément documentationOf sont exposées en détail dans CI-SIS – Volet Structuration Minimale de Documents de Santé (2).

Contraintes :

C6. Acte principal documenté : <documentationOf/serviceEvent/code> Les attributs de cet élément prennent les valeurs suivantes :

o @code= »P0-10000 »

o @displayName= »Hospitalisation »

o @codeSystem= »1.2.250.1.213.2.12 »

o @codeSystemName= »SNOMED 3.5 »

C7. Lieu d’exercice du PS : <representedOrganization>

Cet élément permet, si on l’utilise avec le sous-élément <asOrganizationOf>, d’identifier respectivement le service dans lequel est hospitalisé le patient et l’hôpital dont le service est une composante.

C8. Professionnel ayant effectué la prise en charge : <performer>

Cet élément permet d’identifier le professionnel ayant effectué la prise en charge (il s’agit en pratique de la personne identifiée comme <legalAuthenticator>) qui est identifié avec les éléments suivants :

o performer/assignedEntity/id pour son numéro RPPS o performer/assignedEntity/code pour sa qualification professionnelle o performer/assignedEntity/assignedPerson pour son état civil

C9. Le service auquel est rattaché le PS : <representedOrganization>

Cet élément permet d’identifier la structure infra-hospitalière (le service) du PS ayant effectué la prise en charge du patient.

C10. La structure hospitalière à laquelle est rattaché le service : <representedOrganization/asOrganizationPartOf>

Notes :

La LDL peut être réalisée par un auteur appartenant à l’un de ces deux services.

La LDL permet de décrire plusieurs séjours d’un même épisode de soins. Les séquences composant le séjour peuvent ne pas se dérouler dans des services différents et des établissements différents. (voir les exemples ci-après).



<documentationOf>

<serviceEvent>

<code code= »P0-10000 » displayName= »Hospitalisation »

codeSystem= »1.2.250.1.213.2.12 » codeSystemName= »SNOMED 3.5 »/>

<effectiveTime>

< !–Date de début d’hospitalisation

<low value= »201507011200+0100 »/>

< !–Date de fin d’hospitalisation (date de décès le cas échéant)

<high value= »201509301605+0100 »/>

</effectiveTime>

< !–Réalisation de l’acte

<performer typeCode=”PRF”>

<templateId root=”1.3.6.1.4.1.19376.1.3.3.1.7”/>

<time><high value=”201503021605+0100”/></time>

<assignedEntity>


< !–PS identifié par son N°RPPS

<idroot=”1.2.250.1.71.4.2.1” extension=”801234567897”


<code code= »G15_10/SM27 » displayName= »Médecin – Médecine interne (SM) »

codeSystem=”1.2.250.1.213.1.1.4.5” codeSystemName=”RPPS”/>

<assignedPerson>

<name>




</name>

</assignedPerson>


<name>Service de Cardiologie</name>


<standardIndustryClassCode code= »ETABLISSEMENT »

displayName= »Établissement de santé »

codeSystem= »1.2.250.1.213.1.1.4.9 » codeSystemName= »practiceSettingCode »/>

<asOrganizationPartOf>

<wholeOrganization>

< !–établissement identifié par son N° FINESS

<id root= »1.2.250.1.71.4.2.2 » extension= »101238887 »

assigningAuthorityName= »ASIP Santé »/>


<telecom nullFlavor= »NAV »/>

<addr>


:


</addr>

</wholeOrganization>

</asOrganizationPartOf>


</assignedEntity>

</performer>

</serviceEvent>

</documentationOf>

Exemple 26 – Acte documenté par le document (<documentationOf>)



Si le patient a séjourné dans plusieurs services/hôpitaux, il est possible, lors de la rédaction de la lettre de liaison, de mentionner les différentes séquences de l’épisode de soins.

La cardinalité [1..*] de l’élément <documentationOf> le permet.

Les dates d’entrée et de sortie des structures de soins permettent alors d’ordonner chronologiquement les différentes séquences de cet épisode de soins.

Dans l’exemple ci-dessous, le parcours de soins du patient comprend :

Un séjour aux urgences psychiatriques du 01/07/2015 au 03/07/2015 et

Un séjour en médecine interne du 03/07/2015 au 30/09/2015.

< !–1ère séquence : séjour du Service d’Urgences Psychiatriques

<documentationOf>

<serviceEvent>



<effectiveTime>


<low value= »201507011200+0100 »/>

< !–Date de fin d’hospitalisation

<high value=”201507031605+0100”/>

</effectiveTime>

<performer>

<assignedEntity>

<id root=”1.2.250.1.71.4.2.1” extension=”801234567897”/>

<code code= »G15_10/SM42 » displayName= »Médecin – Psychiatrie (SM) »


<assignedPerson>

<name>

<given>Gisèle</given>

<family>SOULARD</family>


</name>

</assignedPerson>


<name>Service d’Urgences Psychiatriques</name>

:

</documentationOf>

< !–2ème séquence : séjour en Service de Médecine Interne

<documentationOf>

<serviceEvent>



<effectiveTime>


<low value= »201507031605+0100 »/>

< !–Date de fin d’hospitalisation

<high value=”201509301605+0100”/>

</effectiveTime>

<performer>

<assignedEntity>


<code code= »G15_10/SM27 » displayName= »Médecin – Médecine Interne (SM) »


<assignedPerson>

<name>




</name>

</assignedPerson>


<name>Service de Médecine Interne</name>

:

</documentationOf>

Exemple 27 – Acte documenté par le document (<documentationOf>) – Prise en charge par deux services



3.3.1.12 componentOf – Association du document à une prise en charge

L’élément componentOf, obligatoire, relie la LDL à la prise en charge du patient par un PS ou par un établissement, dans le contexte dans lequel ce document a été produit.

Les règles d’implémentation de l’élément componentOf sont exposées dans le CI-SIS – Volet Structuration Minimale de Documents de Santé (2) et sont reprises sans modification dans le cadre de ce volet.

Dans le cadre du volet LDL et dans le cas où le patient a été hospitalisé dans des structures de soins différentes ou des services différents d’une même structure de soins, il est recommandé que la LDL soit écrite par la personne ayant pris en charge le patient en dernier.

<componentOf>

<encompassingEncounter>

<code/>

<effectiveTime>

<low value=”20120328111700+0100”/>

<high value=”20120401111700+0100”/>

</effectiveTime>

<location>

<healthCareFacility>


<code code= »SA01 » displayName= »Etablissement Public de Santé »

codeSystem=”1.2.250.1.71.4.2.4” codeSystemName=”R02”/>

</healthCareFacility>

</location>

</encompassingEncounter>

</componentOf>

Exemple 28 – Association du document à une prise en charge (<componentOf>)



3.3.2 Structuration du corps de la LDL-SES

3.3.2.1 Correspondance entre le modèle métier de la LDL-SES et le document au format CDA

Ce modèle de document décrit les éléments à renseigner dans la LDL-SES en vue puis lors de la sortie du patient de l’établissement de santé. Il comporte les sections listées dans le tableau ci-dessous.

Modèle métier card. Section Code LOINC Entrées

Motif d’hospitalisation Liste des pathologies diagnostiquées avant la prise en charge par l’hôpital et des symptômes initiaux qui motivent l’hospitalisation du patient.

[1..1]

Raison de la recommandation (Reason for referral) 1.3.6.1.4.1.19376.1.5.3.1.3.1

42349-1 Raison de la recommandation

Pas d’entrée

Synthèse médicale du séjour Éléments concernant les événements indésirables survenus pendant l’hospitalisation du patient. Identifcation des micro-organismes multirésistants (BMR), transfusions de produits sanguins ou de dérivés du sang et pose d’un dispositif médical implantable (DMI) durant le séjour.

[1..1]

Résultats d’évènements (Coded Event Outcomes) 1.3.6.1.4.1.19376.1.7.3.1.1.13.7 Parent Template : (Event Outcomes) 1.3.6.1.4.1.19376.1.5.3.1.1.21.2.9

42545-4 Evènements observés

Simple observation (Simple observation) 1.3.6.1.4.1.19376.1.5.3.1.4.13

Traitements arrêtés durant le séjour Traitements habituels du patient arrêtés durant son séjour en établissement de santé.

[1..1]

Médicaments administrés (Medications Administered) 1.3.6.1.4.1.19376.1.5.3.1.3.21 Cette section a été retenue même si le libellé ne correspond pas à l’expression de besoin, car IHE n’a pas de section pour porter les traitements arrêtés.

18610-6 Médication administrée

Traitement (Medication) 1.3.6.1.4.1.19376.1.5.3.1.4.7

Traitements à la sortie Conciliation médicamenteuse (bilan comparatif) afin de proposer un traitement de sortie qui intègre, avec les adaptations nécessaires, le traitement personnel du patient (avant son hospitalisation) et le traitement résultant du motif de l’hospitalisation.

[1..1]

Ordonnance de sortie (codé) (Hospital Discharge Medications) 1.3.6.1.4.1.19376.1.5.3.1.3.22

10183-2 Ordonnance de sortie

Traitement (Medication) 1.3.6.1.4.1.19376.1.5.3.1.4.7

Résultats d’examens Résultats d’investigations diagnostiques particulièrement significatifs réalisées durant la période de prise en charge du patient par l’hôpital.

[1..1]

Résultats d’examens (codé) (Coded Results Section) 1.3.6.1.4.1.19376.1.5.3.1.3.28

30954-2 Résultats d’examens

Simple observation (Simple observation) 1.3.6.1.4.1.19376.1.5.3.1.4.13 Intervention (Procedure) 1.3.6.1.4.1.19376.1.5.3.1.4.19

Suites à donner Volet de continuité de soins (RDV médicaux, examens complémentaires à faire, soins infirmiers, soins de rééducation) et volet médicosocial (actions déjà mises en place, actions préconisées, demandes d’ALD faite ou à demander, point de vigilance, conseils, recommandations).

[1..1]

Plan de soins (codé) (Coded Care Plan Section) 1.3.6.1.4.1.19376.1.5.3.1.3.36 Parent Template : (CCD 3.16 Care Plan) 2.16.840.1.113883.10.20.1.10

18776-5 Plan de soins

Demande d’examen (Observation Requests) 1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1

Tableau 10- Sections et entrées utilisées dans le modèle LDL-SES



3.3.2.2 Exemple de structuration au format CDA de la LDL-EES

<ClinicalDocument xmlns= »urn :hl7-org :v3 »>


<typeId root= »2.16.840.1.113883.1.3 » extension= »POCD_HD000040 »/>

< !–Conformité spécifications HL7 France

<templateId root= »2.16.840.1.113883.2.8.2.1 »/>

< !–Conformité spécifications au CI-SIS

<templateId root= »1.2.250.1.213.1.1.1.1 »/>

< !–Conformité au Document LDL à la sortie de l’établissement de santé (LDL-SES)

<templateId root=”1.2.250.1.213.1.1.1.29”/>

<id root=”1.2.250.1.213.1.1.9” extension=”A7102400008.6.1”/>

<code code= »11490-0 » displayName= »Lettre de liaison à la sortie d’un établissement de

soins »

codeSystem= »2.16.840.1.113883.6.1 » codeSystemName= »LOINC »/>

<title>Lettre de liaison à la sortie de l’établissement de santé</title>

<effectiveTime value=”20150930145100+0100”/>

<confidentialityCode code=”N” displayName=”Normal”

codeSystem=”2.16.840.1.113883.5.25” codeSystemName=”Confidentiality”/>

<languageCode code=”fr-FR”/>

:

<component>

<structuredBody>

<!— Section Raison de la recommendation (Reason for referral) ->

<component>

<section>

<templateId root=”1.3.6.1.4.1.19376.1.5.3.1.3.1” />

</section>

</component>

<!- Section Résultats d’évènements (Coded Event Outcomes) ->

<component>

<section>

<templateId root=’ 1.3.6.1.4.1.19376.1.5.3.1.1.21.2.9”/>

<templateId root=’1.3.6.1.4.1.19376.1.7.3.1.1.13.7”/>

</section>

</component>

<!–Section Médicaments 50dministers (medications administred)

<component>

<section>

<templateId root=”1.3.6.1.4.1.19376.1.5.3.1.3.21”/>

</section>

</component>

<!–Section Ordonnance de sortie (codé) (Hospital Discharge Medications) ->

<component>

<section>

<templateId root= »1.3.6.1.4.1.19376.1.5.3.1.3.22 »/>

</section>

</component>

< !–Section Résultats d’examens (codé) (Coded results)

<component>

<section>

<templateId root= »1.3.6.1.4.1.19376.1.5.3.1.3.28 »/>

</section>

</component>

< !—Section Plan de soins (codé) (Coded Care Plan)

<component>

<section>

<templateId root=”2.16.840.1.113883.10.20.1.10”/>

<templateId root=”1.3.6.1.4.1.19376.1.5.3.1.3.36”/>

</section>

</component>

</structuredBody>

</component>

</ClinicalDocument>

Exemple 29 – Structuration générale d’un document LDL



3.3.2.3 Section Raison de la recommendation (Reason for referral – 1.3.6.1.4.1.19376.1.5.3.1.3.1)

Cette section permet d’identifier la ou les pathologies diagnostiquées avant la prise en charge par l’hôpital ou les symptômes initiaux qui motivent l’hospitalisation du patient. L’information est portée par le bloc narratif de la section (pas d’entrée).


0 section [1..1] Section Raison de la recommendation

1 templateId [1..1] Déclaration de conformité root=’1.3.6.1.4.1.19376.1.5.3.1.3.1’

1 id [0..1] Identifiant de la section, il a la forme UID (UUID ou OID)

1 code [1..1]

Les attributs de cet élément prennent les valeurs suivantes : code=’42349-1’

displayName=’Raison de la recommandation’

codeSystem=’2.16.840.1.113883.6.1’

codeSystemName=’LOINC’

1 title [0..1] Titre de la section. Fixé à ‘Motif d’hospitalisation’


Tableau 11 – Structuration des données de la section Raison de la recommendation

< !— Section Raison de la recommendation (Reason for referral) ->

<component>

<section>

<templateId root= »1.3.6.1.4.1.19376.1.5.3.1.3.1 » />

<id root=’3f8201b6-e1dc-4093-ae73-62e6df2212a2’/>

<code code= »42349-1 » displayName= »Raison de la recommandation »

codeSystem=”2.16.840.1.113883.6.1” codeSystemName=”LOINC”/>

<title>Motif d’hospitalisation</title>

<text>

<table border=”1”>

<tbody align=”left”>

<tr><td>Episode psychotique – cachexie/anorexie</td></tr>

</tbody>

</table>

</text>

</section>

</component>

Exemple 30 – Section Raison de la recommendation



3.3.2.4 Section Résultats d’évènements (Coded Event Outcomes – 1.3.6.1.4.1.19376.1.7.3.1.1.13.7

Cette section permet d’indiquer

La modalité (codée ou par un texte libre si la modalité choisie est « autre ») et la date d’entrée en hospitalisation ;

La modalité (codée ou par un texte libre si la modalité choisie est « autre ») et date de sortie d’hospitalisation ;

Une synthèse médicale (texte libre) ;

La présence ou pas d’événements indésirables pendant l’hospitalisation et en cas de présence, une description des événements indésirables survenus (texte libre) ;

L’identification ou pas de micro-organismes multirésistants et en cas d’identification, une description de ces micro-organismes (texte libre)

La présence ou pas de transfusion de produits sanguins, d’éventuels accidents transfusionnels et en cas de présence, une description des accidents transfusionnels (texte libre)

L’administration ou pas de dérivés du sang, la présence ou pas d’événements indésirables suite à l’administration de dérivés du sang et en cas de présence, une description des événements indésirables ;

La pose ou pas d’un dispositif médical implantable et si un DMI a étéimplanté, la nature et le site d’implantation du DMI


0 section [1..1] Section Résultats d’évènements

1 templateId [1..1] Déclaration de conformité root=’1.3.6.1.4.1.19376.1.7.3.1.1.13.7’

root=’1.3.6.1.4.1.19376.1.5.3.1.1.21.2.9’


1 code [1..1]


displayName=’Evènements observés’

codeSystem='2.16.840.1.113883.6.1'


1 title [0..1] Titre de la section. Fixé à ‘Synthèse médicale du séjour’


1 entry [1..1]

Modalité et date d’entrée en hospitalisation Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]

Les attributs de cet élément prennent les valeurs suivantes : code='ORG-070'

displayName='Modalité d’entrée'

codeSystem='1.2.250.1.213.1.1.4.322'






4 reference [1..1] Valeur pour faire référence à la partie narrative de la section

3 statusCode [1..1] Valeur fixée à statusCode='completed'

3 effectiveTime [1..1] Date de l’entrée du patient en hospitalisation

3 value [1..1] Modalité d’entrée en hospitalisation Code issu du jeu de valeurs JDV_ModaliteEntree_CI-SIS (1.2.250.1.213.1.1.5.73)

1 entry [0..1]

Texte libre pour préciser la modalité d’entrée si la réponse était « autre » Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]

Les attributs de cet élément prennent les valeurs suivantes : code='GEN-093'

displayName='Si réponse autre'

codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Texte libre pour préciser la modalité d’entrée si la réponse était « autre »

1 entry [1..1]

Modalité et date de sortie d’hospitalisation Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]

Les attributs de cet élément prennent les valeurs suivantes : code='ORG-074'

displayName='Modalité de sortie'

codeSystem='1.2.250.1.213.1.1.4.322'





3 effectiveTime [1..1] Date de la sortie d’hospitalisation

3 value [1..1] Modalité de sortie d’hospitalisation Code issu du jeu de valeurs JDV_ModaliteSortie_CI-SIS (1.2.250.1.213.1.1.5.74)




1 entry [0..1]

Texte libre pour préciser la modalité de sortie si la réponse était « autre » Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]


displayName='Si réponse autre'

codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Texte libre pour préciser la modalité de sortie si la réponse était « autre »

1 entry [1..1]

Synthèse médicale Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]

Les attributs de cet élément prennent les valeurs suivantes : code='MED-142'

displayName=' Synthèse médicale'

codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Synthèse médicale Texte libre

1 entry [1..1]

Présence d’événements indésirables pendant l’hospitalisation Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’






3 code [1..1]


displayName='Evenements indésirables survenus pendant

l'hospitalisation'

codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Présence d’événements indésirables pendant l’hospitalisation Valeur Booléenne

1 entry [0..1]

Description des événements indésirables survenus pendant l’hospitalisation Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]


displayName='description'

codeSystem='1.2.250.1.213.1.1.4.322'


3 Text [1..1] Partie narrative de l’entrée




3 value [1..1] Description des événements indésirables survenus pendant l’hospitalisation Texte libre

1 entry [1..1]

Identification de micro-organismes multirésistants Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]


displayName='Identifiants de micro-organismes

multirésistants'

codeSystem='1.2.250.1.213.1.1.4.322'









3 value [1..1] Identification de micro-organismes multirésistants Valeur booléenne

1 entry [0..1]

Description des micro-organismes identifiés Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]


displayName='Description'

codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Description des micro-organismes identifiés Texte libre

1 entry [1..1]

Transfusion de produits sanguins Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]


displayName='Transfusion de produits sanguins'

codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Transfusion de produits sanguins Valeur booléenne

1 entry [0..1]

Accidents transfusionnels Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques






classCode=’OBS’

moodCode=’EVN’



3 code [1..1]


displayName='Accidents transfusionnels'

codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Accidents transfusionnels Valeur booléenne

1 entry [0..1]

Description des accidents transfusionnels Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]



codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Description des accidents transfusionnels Texte libre

1 entry [1..1]

Administration de dérivés du sang Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]


displayName='Administration de dérivés du sang'

codeSystem='1.2.250.1.213.1.1.4.322'









3 value [1..1] Administration de dérivés du sang Valeur booléenne

1 entry [0..1]

Événements indésirables suite à l’administration de dérivés du sang Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]


displayName='Evenements indésirables'

codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Événements indésirables suite à l’administration de dérivés du sang Valeur booléenne

1 entry [0..1]

Description des événements indésirables suite à l’administration de dérivés du sang Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]



codeSystem='1.2.250.1.213.1.1.4.322'









3 value [1..1] Description des événements indésirables suite à l’administration de dérivés du sang Texte libre

1 entry [1..1]

Pose d’un dispositif médical implantable Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]


displayName='Pose d'un dispositif médical implantable'

codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Pose d’un dispositif médical implantable (DMI) Valeur booléenne

1 entry [0..1]

Nature du DMI Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]


displayName='Nature du DMI'

codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Nature du DMI Texte libre

1 entry [0..1]

Site d’implantation du DMI Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13) dont les spécifications décrites dans (5), sont reprises ici sans contraintes spécifiques



classCode=’OBS’

moodCode=’EVN’






3 code [1..1]


displayName='Site d’implantation'

codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Site d’implantation du DMI Texte libre

Tableau 12 - Structuration des données de la section Résultats d’évènements

<!- Section Résultats d’évènements (Coded Event Outcomes) ->

<component>

<section>

<templateId root=' 1.3.6.1.4.1.19376.1.5.3.1.1.21.2.9"/>

<templateId root='1.3.6.1.4.1.19376.1.7.3.1.1.13.7"/>

<id root='E52A7B75-3B12-44DF-80B3-3DEA64E25B4B'/>

<code code='42545-4' displayName='Evènements observés'

codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" />

<title> Synthèse médicale du séjour </title> <text>

<table border="1">

<thead>

<tr><th colspan="2">Synthèse médicale du séjour</th></tr>

</thead>

<tbody>

<tr>

<td>Modalité et date d'entrée en hospitalisation </td>

<td><content ID="modaliteE">02/01/2015, Transfert</content></td>

</tr>

<tr>

<td>Précision Modalité d’entrée</td>

<td><content ID="autreModaliteE">-</content></td>

</tr>

<tr>

<td>Modalité et date de sortie d'hospitalisation</td>

<td><content ID="modDest">05/01/2015, Autre établissement de

santé</content></td>

</tr>

<tr>

<td>Précision Modalité de sortie</td>

<td><content ID="autreModDest">-</content></td>

</tr>

<tr>

<td>Synthèse Medicale du séjour </td>

<td><content ID="synthMed">Infection respiratoire aigue</content></td>

</tr>

<tr>

<td>Présence d’événements indésirables pendant l’hospitalisation</td>

<td><content ID="EveInd">Non</content></td>

</tr>

<tr>

<td>Description des événements indésirables</td>

<td><content ID="desc">-</content></td>

</tr>

<tr>

<td>Identification de micro-organismes multirésistants</td>

<td><content ID="idMicroMulti">Oui</content></td>

</tr>

<tr>



<td>Description des micro-organismes multirésistants</td>

<td><content ID="descMulti">Streptococcus pneumoniae</content></td>

</tr>

<tr>

<td>Transfusion de produits sanguins</td>

<td><content ID="transfu">Non</content></td>

</tr>

<tr>

<td>Accidents transfusionnels</td>

<td><content ID="quelsTransfu">Non</content></td>

</tr>

<tr>

<td>Description des accidents transfusionnels</td>

<td><content ID="descTransfu">-</content></td>

</tr>

<tr>

<td>Administration de dérivés du sang</td>

<td><content ID="admiSang">Non</content></td>

</tr>

<tr>

<td>Évènements indésirables suite à l’administration de dérivé du sang</td>

<td><content ID="evenInd">Non</content></td>

</tr>

<tr>

<td>Description Évènements indésirables suite à l’administration de dérivé du

sang</td>

<td><content ID="descEvenInd">-</content></td>

</tr>

<tr>

<td>Pose d'un dispositif médical implantable</td>

<td><content ID="posedispoImpl">Non</content></td>

</tr>

<tr>

<td>Nature du DMI</td>

<td><content ID="natureDispoImp">-</content></td>

</tr>

<tr>

<td>Site d'implantation du DMI</td>

<td><content ID="siteImpl">-</content></td>

</tr>

</tbody>

</table>

</text>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="f597bfd5-2bd0-4163-892a-7c51830e2ba6"/>

<code code="ORG-070" displayName="Modalité d’entrée"

codeSystem="1.2.250.1.213.1.1.4.322" codeSystemName='TA_ASIP'/>

<text>

<reference value="modaliteE"></reference>

</text>




<effectiveTime value='20150102'/>



<value xsi:type="CD" code="ORG-069" displayName="Transfert"


</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="e7d0207b-d370-4bad-994d-f1e54c075759"/>

<code code="GEN-093" displayName="Si réponse autre"


<text>

<reference value="autreModaliteE"></reference>

</text>





<value xsi:type="ST"/>

</observation>



</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="1e384ea2-2083-4f17-b825-6a088d2a0e6e"/>

<code code="ORG-074" displayName="Modalité de sortie"


<text>

<reference value="modDest"></reference>

</text>







<value xsi:type="CD" code="ORG-073" displayName="Autre établissement de santé"


</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="11739c89-578a-4e30-9e35-80be527c84e9"/>

<code code="GEN-093" displayName="Si réponse autre"


<text>

<reference value="autreModDest"></reference>

</text>





</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="174f6d84-986e-4032-8f99-91975403b955"/>

<code code="MED-142" displayName="Synthèse médicale"


<text>

<reference value="synthMed"></reference>

</text>




<value xsi:type='ST'/>

</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="cdbd5b08-6cde-11db-9fe1-0800200c9a66"/>

<code code="MED-143" displayName="Evenements indésirables survenus pendant l'hospitalisation"


<text>

<reference value="EveInd"></reference>

</text>





<value xsi:type='BL' value="false"/>

</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>



<id root="12da3a06-18e7-40b7-9397-1fa5b1552472"/>

<code code="GEN-089" displayName="Description"


<text>

<reference value="desc"></reference>

</text>





</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="53c6c420-96ef-47d4-8eca-b25460140b8f"/>

<code code="MED-144" displayName="Identification de micro-organismes multirésistants"


<text>

<reference value="idMicroMulti"></reference>

</text>





<value xsi:type='BL' value="true"/>

</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="12da3a06-18e7-40b7-9397-1fa5b1552472"/>



<text>

<reference value="descMulti"></reference>

</text>




<value xsi:type='ST'>Streptococcus pneumoniae</value>

</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>


<code code="MED-145" displayName="Transfusion de produits sanguins"


<text>

<reference value="transfu"></reference>

</text>






</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="12da3a06-18e7-40b7-9397-1fa5b1552472"/>

<code code="MED-146" displayName="Accidents transfusionnels"


<text>

<reference value="quelsTransfu"></reference>

</text>








</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>




<text>

<reference value="descTransfu"></reference>

</text>





</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="12da3a06-18e7-40b7-9397-1fa5b1552472"/>

<code code="MED-147" displayName="Administration de dérivés du sang"


<text>

<reference value="admiSang"></reference>

</text>






</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="8eb396a9-79a4-4716-bf9d-38f5ce2652e3"/>

<code code="MED-148" displayName="Evenements indésirables"


<text>

<reference value="evenInd"></reference>

</text>






</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="D3DCE1E0-EB52-47CB-8507-D33F0041D138"/>



<text>

<reference value="descEvenInd"></reference>

</text>





</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>



<id root="21872220-FBDF-4BCC-85B1-61D1BBB420A5"/>

<code code="MED-149" displayName="Pose d'un dispositif médical implantable"


<text>

<reference value="posedispoImpl"></reference>

</text>






</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="fc21dc59-43d5-4bb0-acc7-3601784bfbc0"/>

<code code="MED-150" displayName="Nature du DMI"


<text>

<reference value="natureDispoImp"></reference>

</text>





</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>


<code code="MED-151" displayName="Site d'implantation"


<text>

<reference value="siteImpl"></reference>

</text>





</observation>

</entry>

</section>

</component>

Exemple 31 – Section Résultats d’évènements



3.3.2.5 Section Médicaments administrés pendant l’épisode de soins (Medications Administred Section - 1.3.6.1.4.1.19376.1.5.3.1.3.21)

Cette section décrit les médicaments arrêtés durant le séjour du patient à l’hôpital, bien que le titre de la section IHE retenue ne corresponde pas au contenu (IHE n’a pas de section pour les traitements arrêtés). Par médicaments arrêtés durant le séjour, il est fait référence aux traitements habituels du patient avant l’hospitalisation qui sont arrêtés durant le séjour. La formalisation de l’arrêt explicite d’un traitement classiquement recommandé (par exemple pour insuffisance cardiaque, IDM) est conseillée afin d’éviter que cela puisse être considéré comme un oubli par le médecin qui prend le patient en charge à la sortie de l’hospitalisation. Cette section la liste des médicaments administrés durant le séjour et qui ne sont pas prolongés à la sortie. Le Volet Modèles de Contenu CDA (5) spécifie que chaque médicament doit être décrit dans une entrée de type Traitement (Medications - 1.3.6.1.4.1.19376.1.5.3.1.4.7), obligatoire (cardinalité [1..1]), et que cette entrée comporte obligatoirement une description du médicament en CIS_Spécialité (1.2.250.1.213.2.3.1) et optionnellement, des traductions en CIP_Présentation

(1.2.250.1.213.2.3.3) et en CIS_Composition (1.2.250.1.213.2.3.2).

Note sur CIS_Composition (1.2.250.1.213.2.3.2) :

Cette ressource comporte les éléments permettant temporairement de décrire certains médicaments en DC mais ne saurait se substituer de manière satisfaisante au futur référentiel opposable des médicaments virtuels.

Le motif de l’arrêt du médicament est précisé en texte libre dans la partie narrative de l’entrée Traitement.


0 section [1..1] Section Médicaments administrés pendant l’épisode de soins La présence de cette section indique qu’il y a des Traitements médicamenteux arrêtés durant le séjour



1 code [1..1]

Les attributs de cet élément prennent les valeurs suivantes : code='18610-6 '

displayName='Médicaments administrés'

codeSystem='2.16.840.1.113883.6.1'


1 title [0..1] Titre de la sous-section. Fixé à ‘Traitements arrêtés durant le séjour’


1 entry [1..*] Traitement arrêté durant le séjour Élément(s) de type Medications (1.3.6.1.4.1.19376.1.5.3.1.4.7)

2 substanceAdministration [1..1]

Valeur des attributs de l’entrée :

classCode='SABDM'

moodCode='EVN' (signifie que le médicament a déjà été administré)

3 templateId [3..3] Déclarations de conformité root='2.16.840.1.113883.10.20.1.24'

root='1.3.6.1.4.1.19376.1.5.3.1.4.7'




3 templateId [1..1] Déclaration de conformité liée au mode d'administration = ‘Normal’ root=’1.3.6.1.4.1.19376.1.5.3.1.4.7.1’

3 id [1..1] Identifiant de l’entrée, il aura la forme UID (UUID ou OID)

3 code [0..1]

Acte ou situation

Pour le mode d’administration (par exemple une injection

intraveineuse), le code est issu du jeu de valeurs

JDV_ModeAdministration_CI-SIS

(1.2.250.1.213.1.1.5.75).

Pour décrire les situations dans lesquelles il n’y a pas de traitement décrit, le code est isssu du jeu de valeurs JDV_CodeNoMedication_CI-SIS (1.2.250.1.213.1.1.5.30)

3 text [1..1] Motif de l’arrêt du traitement (texte libre) La partie narrative de l’entrée contient le motif de l’arrêt du traitement.

4 reference value=’’ [1..1] Réference à l’élément narratif de la section

3 statusCode [1..1] Fixé à la valeur code=’completed’, l’administration ayant déjà été réalisée ou ordonnée.

3 effectiveTime [1] [1..1] Durée du traitement Voir Volet Modèles de Contenu CDA (5)

La valeur nullFlavor est autorisée.

3 effectiveTime [2] [1..1] Date et heure de la dernière prise du traitement habituel Voir Volet Modèles de Contenu CDA (5)

3 routeCode [0..1] Voie d’administration Voir Volet Modèles de Contenu CDA (5) La valeur nullFlavor est autorisée.

3 approachSiteCode [0..1] Région anatomique d’administration Voir Volet Modèles de Contenu CDA (5)

3 doseQuantity [1..1] Dose administrée Voir Volet Modèles de Contenu CDA (5)

4 low [1..1] Dose minimale Voir Volet Modèles de Contenu CDA (5)

4 high [1..1] Dose maximale Voir Volet Modèles de Contenu CDA (5)

3 rateQuantity [0..1] Rythme d’administration Voir Volet Modèles de Contenu CDA (5)

3 maxDoseQuantity [0..1] Dose maximale Voir Volet Modèles de Contenu CDA (5)

3 consumable [1..1] Médicament

4 manufacturedProduct [1..1] Cet élément correspond au medicament pris par le patient.

5 tempalteId [2..2] Déclarations de conformité root='1.3.6.1.4.1.19376.1.5.3.1.4.7.2'

root='2.16.840.1.113883.10.20.1.53'

5 manufacturedMaterial [1..1] Médicament administré

6 code [1..1] Codification CIS_Spécialité (8 caractères) (1.2.250.1.213.2.3.1)

Voir Volet Modèles de Contenu CDA (5)

7 originalText [1..1] Partie narrative du code

8 reference [1..1] Réference à l'élément narratif de la section

7 translation [0..1] Codification CIP_Présentation (13 caractères) (1.2.250.1.213.2.3.3)


7 translation [0..1] Codification CIS_Composition (1.2.250.1.213.2.3.2)


6 name [0..1] Nom de spécialité du médicament

6 lotNumberText [0..1] Numéro de lot

Tableau 13 - Structuration des données de la section Médicaments administrés pendant l’épisode de soins









<component>

<section>

<templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.21'/>

<id root='4A402640-1CF6-4153-B5BA-D56B623004C8'/>

<code code='18610-6' displayName="Médication administrée"


<title>Traitements arrêtés durant le séjour</title>

<text>

<table border="1">

<thead>

<tr>

<th>Date de début et de fin</th>

<th>Médicament</th>

<th>Composition</th>

<th>Posologie</th>

<th>Motif de l’arrêt</th>

</tr>

</thead>

<tbody>

<tr>

<td>01/08/2008 au 31/08/2008</td>

<td><content ID="trait101">PLAVIX 75mg</content></td>

<td><content ID="trait102">CLOPIDOGREL (HYDROGÉNOSULFATE DE)</content></td>

<td>1 cp/j</td>

<td><content ID="trait103">arrêt suite à analyses médicales</content></td>

</tr>

<tr>

<td>01/08/2008 au 08/08/2008</td>

<td><content ID="trait201">KETOPROFENE BIOGARAN LP 100 mg</content></td>

<td><content ID="trait202">KETOPROFENE</content></td>

<td>1 cp/matin et soir</td>

<td><content ID="trait203">arrêt suite à analyses médicales</content></td>

</tr>

</tbody>

</table>

</text>



<entry typeCode="DRIV">

<substanceAdministration classCode="SBADM" moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.1.24"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1"/>

<id root="AADC9C14-F1CA-4177-B2C8-A5178D5B3CA0"/>

<text><reference value="#trait103"/></text>




<effectiveTime xsi:type="IVL_TS">

<low value="20080801"/>

<high value="20080831"/>

</effectiveTime>



<effectiveTime xsi:type="PIVL_TS" operator="A">

<period value="1" unit="d"/>

</effectiveTime>



<doseQuantity>

<low value="2" unit="tbl"></low>

<high value="2" unit="tbl"></high>

</doseQuantity>



<consumable>

<manufacturedProduct>

<templateId root="2.16.840.1.113883.10.20.1.53"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>

<manufacturedMaterial>



<code code="63564053" displayName="PLAVIX 75 mg, comprimé pelliculé"

codeSystem="1.2.250.1.213.2.3.1" codeSystemName="CIS_Spécialité">

<originalText>



<reference value="#trait101"/>

</originalText>



<translation code="52920" displayName="CLOPIDOGREL (HYDROGÉNOSULFATE DE)"

codeSystem="1.2.250.1.213.2.3.2" codeSystemName="CIS_Composition">

<originalText>


</originalText>

</translation>

</code>

<name>PLAVIX 75 mg</name>

<lotNumberText nullFlavor="NA"/>

</manufacturedMaterial>

</manufacturedProduct>

</consumable>

</substanceAdministration>

</entry>




<substanceAdministration classCode="SBADM" moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.1.24"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1"/>


<text><reference value="#trait203"/></text>




<low value="20080801"/>

<high value="20080808"/>

</effectiveTime>





</effectiveTime>

<routeCode code="PO" displayName="prendre par la bouche"

codeSystem="2.16.840.1.113883.5.112"/>



<doseQuantity>



</doseQuantity>



<consumable>


<templateId root="2.16.840.1.113883.10.20.1.53"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>



<code code="63586338"

displayName="KETOPROFENE BIOGARAN LP 100 mg, comprimé sécable à libération prolongée"


<originalText>


</originalText>


<translation code="823" displayName="KÉTOPROFÈNE"


<originalText>


</originalText>

</translation>

</code>

<name>KÉTOPROFÈNE 100 mg</name>




</consumable>


</entry>

</section>

</component>

Exemple 32 – Section Médicaments administrés pendant l’épisode de soins



3.3.2.6 Section Ordonnance à la sortie (codée) (Hospital Discharge Medications - 1.3.6.1.4.1.19376.1.5.3.1.3.22)

Cette section rassemble les éléments liés aux traitements médicamenteux prescrits au patient à la sortie d’hospitalisation. Cette section ne contient pas :

la liste des médicaments arrêtés, qui sont décrits dans la section décrite au § 3.3.2.5), la liste des médicaments administrés durant le séjour et qui ne sont pas prolongés à la sortie.

Le Volet Modèles de Contenu CDA (5) spécifie que chaque médicament doit être décrit dans une entrée de type Traitement (Medications - 1.3.6.1.4.1.19376.1.5.3.1.4.7), obligatoire (cardinalité [1..1]), et que cette entrée comporte obligatoirement une description du médicament en CIS_Spécialité (1.2.250.1.213.2.3.1) et optionnellement, des traductions en CIP_Présentation

(1.2.250.1.213.2.3.3) et en CIS_Composition (1.2.250.1.213.2.3.2).

Note sur CIS_Composition (1.2.250.1.213.2.3.2) :

Cette ressource comporte les éléments permettant temporairement de décrire certains médicaments en DC mais ne saurait se substituer de manière satisfaisante au futur référentiel opposable des médicaments virtuels.

Or, la loi du 29 décembre 2011 et le décret consécutif à cette loi du 14 novembre 2014 ont instauré l'obligation effective au 1er janvier 2015 de prescription en Dénomination Commune (DC). Cependant, aucun référentiel opposable de médicaments dits virtuels n’est actuellement disponible pour le codage en DC. Il est donc accepté, dans cette version de la LDL, pour les logiciels qui ne peuvent pas coder le médicament en CIS_Spécialité (1.2.250.1.213.2.3.1), de ne pas utiliser l’entrée Traitement

(Medications - 1.3.6.1.4.1.19376.1.5.3.1.4.7) et de décrire la prescription dans la partie narrative de la section uniquement (<section>/<text>).


0 section [1..1] Section Ordonnance à la sortie (codée) La présence de cette section indique qu’il y a des Traitements médicamenteux prescrits à la sortie de l’hospitalisation.


1 code [1..1]


displayName=’Ordonnance de sortie'

codeSystem='2.16.840.1.113883.6.1'


1 title [0..1] Titre de la sous-section. Fixé à ‘Traitements à la sortie’


1 entry [1..*] Traitement Élément(s) de type Medications (1.3.6.1.4.1.19376.1.5.3.1.4.7)

2 substanceAdministration [1..1]

Valeur des attributs de l’entrée :

classCode='SABDM'

moodCode='INT' (signifie que le médicament est en attente d’administration)

3 templateId [2..2] Déclarations de conformité root='2.16.840.1.113883.10.20.1.24'

root='1.3.6.1.4.1.19376.1.5.3.1.4.7'




3 templateId [1..1] Déclaration de conformité liée au mode d'administration = ‘Normal’ root=’1.3.6.1.4.1.19376.1.5.3.1.4.7.1’

3 id [1..1] Identifiant de l’entrée, il aura la forme UID (UUID ou OID)

3 code [0..1]

Acte ou situation

Pour le mode d’administration (par exemple une injection

intraveineuse), le code est issu du jeu de valeurs

JDV_ModeAdministration_CI-SIS

(1.2.250.1.213.1.1.5.75).

Pour décrire les situations dans lesquelles il n’y a pas de traitement décrit, le code est isssu du jeu de valeurs JDV_CodeNoMedication_CI-SIS (1.2.250.1.213.1.1.5.30)

3 text [0..1]

4 reference value=’’ [1..1] Réference à l’élément narratif de la section

3 statusCode [1..1] Fixé à la valeur code=’completed’, l’administration ayant déjà été réalisée ou ordonnée.

3 effectiveTime [1] [1..1] Durée du traitement Voir Volet Modèles de Contenu CDA (5)

La valeur nullFlavor est autorisée.

3 effectiveTime [2] [1..1] Fréquence d’administration Voir Volet Modèles de Contenu CDA (5)

3 routeCode [0..1] Voie d’administration Voir Volet Modèles de Contenu CDA (5) La valeur nullFlavor est autorisée.

3 approachSiteCode [0..1] Région anatomique d’administration Voir Volet Modèles de Contenu CDA (5)

3 doseQuantity [1..1] Dose à administrer Voir Volet Modèles de Contenu CDA (5)

4 low [1..1] Dose minimale Voir Volet Modèles de Contenu CDA (5)

4 high [1..1] Dose maximale Voir Volet Modèles de Contenu CDA (5)

3 rateQuantity [0..1] Rythme d’administration Voir Volet Modèles de Contenu CDA (5)

3 maxDoseQuantity [0..1] Dose maximale Voir Volet Modèles de Contenu CDA (5)

3 consumable [1..1] Médicament

4 manufacturedProduct [1..1] Cet élément correspond au medicament prescrit

5 tempalteId [2..2] Déclarations de conformité root='1.3.6.1.4.1.19376.1.5.3.1.4.7.2'

root='2.16.840.1.113883.10.20.1.53'

5 manufacturedMaterial [1..1] Médicament prescrit

6 code [1..1] Codification CIS_Spécialité (8 caractères) (1.2.250.1.213.2.3.1)


7 originalText [1..1] Partie narrative

8 reference [1..1] Réference à l'élément narratif de la section

7 translation [0..1] Codification CIP_Présentation (13 caractères) (1.2.250.1.213.2.3.3)


7 translation [0..1] Codification CIS_Composition (1.2.250.1.213.2.3.2)


6 name [0..1] Nom de spécialité du médicament La valeur nullFlavor est autorisée

6 lotNumberText [0..1] Numéro de lot

Tableau 14 - Structuration des données de la section Ordonnance à la sortie









<component>

<section>

<templateId root='1.3.6.1.4.1.19376.1.5.3.1.3.22'/>

<id root='d2e72afe-401e-4cd2-8583-8473714a32a5'/>

<code code='10183-2' displayName="Ordonnance à la sortie"


<title>Traitements à la sortie</title>

<text>

<table border="1">

<thead>

<tr>

<th>Date de début et de fin</th>

<th>Médicament</th>

<th>Composition</th>

<th>Posologie</th>

</tr>

</thead>

<tbody>

<tr>

<td>01/08/2008 au 31/08/2008</td>

<td><content ID="trait010">PLAVIX 75mg, comprimé pelliculé</content></td>

<td><content ID="trait011">CLOPIDOGREL (HYDROGÉNOSULFATE DE)</content></td>

<td>1 cp/j</td>

</tr>

<tr>

<td>01/08/2008 au 08/08/2008</td>

<td><content ID="trait012">COUMADINE 5mg, comprimé sécable</content></td>

<td><content ID="trait013">(WARFARINE SODIQUE)</content></td>

<td>1 cp/j</td>

</tr>

</tbody>

</table>

</text>




<substanceAdministration classCode="SBADM" moodCode="INT">

<templateId root="2.16.840.1.113883.10.20.1.24"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1"/>


<text> </text>





<low value="20080801"/>

<high value="20080831"/>

</effectiveTime>





</effectiveTime>



<doseQuantity>



</doseQuantity>



<consumable>


<templateId root="2.16.840.1.113883.10.20.1.53"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>



<code code="63564053" displayName="PLAVIX 75 mg, comprimé pelliculé"


<originalText>




</originalText>


<translation code="52920 displayName="CLOPIDOGREL (HYDROGÉNOSULFATE DE)"


<originalText>


</originalText>

</translation>

</code>

<name>PLAVIX 75 mg</name>




</consumable>


</entry>




<substanceAdministration classCode="SBADM" moodCode="INT">

<templateId root="2.16.840.1.113883.10.20.1.24"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1"/>


<text> </text>





<low value="20080801"/>

<high value="20080808"/>

</effectiveTime>





</effectiveTime>



<doseQuantity>



</doseQuantity>



<consumable>


<templateId root="2.16.840.1.113883.10.20.1.53"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>



<code code="63586338"

displayName="KETOPROFENE BIOGARAN LP 100 mg, comprimé sécable

à libération prolongée">

codeSystem="1.2.250.1.213.2.3.1" codeSystemName="CIS_Spécialité"

<originalText>

<reference value="#vsm0015"/>

</originalText>


<translation code="823" displayName="KÉTOPROFÈNE"


<originalText>

<reference value="#vsm0016"/>

</originalText>

</translation>

</code>

<name>KÉTOPROFÈNE 100 mg</name>




</consumable>


</entry>

</section>

</component>

Exemple 33 – Section Ordonnance à la sortie



3.3.2.7 Section Résultats d’examens (Coded Results - 1.3.6.1.4.1.19376.1.5.3.1.3.28)

Cette section rassemble les résultats d'investigations diagnostiques particulièrement significatifs réalisées durant la période de prise en charge du patient par l'hôpital.

Chacun de ces éléments est porté par un élément de type Simple observation, décrit dans le Volet Modèles de Contenus CDA (5) et dont les modalités d’implémentation pour la LDL-SES sont décrites ci-dessous.

Note : La première entrée de la section (entrée Intervention) est obligatoire. Si elle ne doit comporter aucune information pertinente, les éléments de cette entrée peuvent prendre une valeur ‘nullflafor’.


0 section [1..1] Section Résultats d’examens

1 templateId [2..2] Déclarations de conformité root='1.3.6.1.4.1.19376.1.5.3.1.3.28' root="1.3.6.1.4.1.19376.1.5.3.1.3.27"

1 code [1..1]


code='30954-2'

displayName=’Résultats d’examens’

codeSystem='2.16.840.1.113883.6.1'


1 title [0..1] Titre de la section. Fixé à 'Résultats d’examens'


1

1 entry [1..1]

Intervention Élément de type Procedure entry (2.16.840.1.113883.10.20.1.29)

1

2 procedure [1..1]


classCode=’PROC’

moodCode=’EVN’

1

3 templateId [2..2]

Déclarations de conformité root='1.3.6.1.4.1.19376.1.5.3.1.4.19'

root='2.16.840.1.113883.10.20.1.29'

1

3 code [1..1]


code='MED-152'

displayName='Resultats d’examens'

codeSystem='1.2.250.1.213.1.1.4.322'


1


1


1


1

3 effectiveTime [1..1]

Dans le cas où la date n’est pas connue, la valeur ‘nullFlavor’ est autorisée.

1

1 entry [1..1]

Présence ou pas d’autres traitements de nature non médicamenteuse Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13)

1



classCode=’OBS’

moodCode=’EVN’ 1

3 templateId [1..1]

Déclaration de conformité root="1.3.6.1.4.1.19376.1.5.3.1.4.13"

1

3 id [1..1]

Identifiant de l'observation. Obligatoire, il aura la forme UID (UUID ou OID)

1

3 code [1..1]


code='MED-154'

displayName='Autres traitements'

codeSystem='1.2.250.1.213.1.1.4.322'





1


1


1


1



1

3 value [1..1]

Présence ou pas d’autres traitements de nature non médicamenteuse Valeur Booléenne

1

1 entry [0..1]

Traitements non médicamenteux Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13)

1



classCode=’OBS’

moodCode=’EVN’ 1

3 templateId [1..1]

Déclaration de conformité root="1.3.6.1.4.1.19376.1.5.3.1.4.13"

1

3 id [1..1]

Identifiant de l'observation. Obligatoire, il aura la forme UID (UUID ou OID)

1

3 code [1..1]


code='GEN-090'

displayName='Lesquels'

codeSystem='1.2.250.1.213.1.1.4.322'

codeSystemName='TA_ASIP' 1


1


1


1



1

3 value [1..1]

Traitements non médicamenteux Valeur textuelle

1

1 entry [1..1]

En attente de résultats d’examens

Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13)



classCode=’OBS’

moodCode=’EVN’



3 code [1..1]


code='MED-153'

displayName='Attente de résultats d’examens à

venir ou d’autres informations'

codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] En attente de résultats d’examens Valeur Booléenne

1 entry [0..1] Description des résultats d’examens attendus Élément de type Simple Observation (1.3.6.1.4.1.19376.1.5.3.1.4.13)



classCode=’OBS’

moodCode=’EVN’






3 code [1..1]


code='GEN-090'


codeSystem='1.2.250.1.213.1.1.4.322'






3 value [1..1] Description des résultats d’examens attendus Valeur textuelle

Tableau 15 - Structuration des données de la section Résultats d'examens



<component>

<section>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.28"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.27"/>

<code code='30954-2' displayName=’Résultats d’examens'


<title>Résultats d'examens</title>

<text>

<table border="1">

<thead>

<tr>

<th colspan="2"><content ID="resExam">Résultats d'examens</content></th>

</tr>

</thead>

<tbody>

<tr>

<td>Autres traitements (traitements non médicamenteux)</td>

<td><content ID="autresTrait">Non</content></td>

</tr>

<tr>

<td>si oui, lesquels (Autres traitements non médicamenteux)</td>

<td><content ID="quelsTrait">-</content></td>

</tr>

<tr>

<td>Attente de résultats d’examens à venir ou d’autres informations</td>

<td><content ID="att">Non</content></td>

</tr>

<tr>

<td>si oui, lesquels</td>

<td><content ID="quelsAtt">-</content></td>

</tr>

</tbody>

</table>

</text>



<entry>

<procedure classCode='PROC' moodCode='EVN'>

<templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.19'/>

<templateId root='2.16.840.1.113883.10.20.1.29'/>

<id root='7c6eb1cb-e9e9-4199-8ceb-5de37e93364f'/>

<code code="MED-152" displayName="Résultats d’examens"


<text>

<reference value="resExam"/>

</text>

<statusCode code='completed'/>

<effectiveTime nullFlavor="NA"/>

</procedure>

</entry>





<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="f3eec9af-00bd-41f9-b16c-ee77d1deaad7"/>

<code code="MED-154" displayName="Autres traitements"


<text>

<reference value="autresTrait"/>

</text>



<value xsi:type="BL" value="false"></value>

</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="eb6febae-25b2-4128-b2b1-a114679628f7"/>

<code code="GEN-090" displayName="Lesquesls"


<text>

<reference value="quelsTrait"/>

</text>



<value xsi:type="ST"></value>

</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="6F7DBEC2-0E15-48F0-B61E-00B0753BFCAD"/>

<code code="MED-153"

displayName="Attente de résultats d’examens à venir ou d’autres informations"


<text>

<reference value="att"/>

</text>



<value xsi:type="BL" value="false"></value>

</observation>

</entry>



<entry>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<id root="a6bc7fd2-ec3f-4e01-b567-854b087d1d9b"/>

<code code="GEN-090" displayName="Lesquesls"


<text>

<reference value="quelsAtt"/>

</text>



<value xsi:type="ST"></value>

</observation>

</entry>

</section>

</component>

Exemple 34 – Section Resultats d'examens



3.3.2.8 Section Plan de soins (codé) (Coded Care Plan - 1.3.6.1.4.1.19376.1.5.3.1.3.36)

Cette section rassemble le plan de soins et les recommendations (prescriptions médicamenteuses, interventions, examens paracliniques, surveillance paraclinique, consultations) qui sont à prévoir à la sortie du patient de l’hôpital.

L’information est portée par des entrées utilisant le modèle Observation Request (1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1)


0 section [1..1] Section Plan de soins (codé)

1 templateId [1..1] Déclaration de conformité root='1.3.6.1.4.1.19376.1.5.3.1.3.36’

root='2.16.840.1.113883.10.20.1.10'

1 id [0..1]

1 code [1..1]


displayName='Plan de soins'

codeSystem='2.16.840.1.113883.6.1'


1 title [0..1] Titre de la sous-section. Fixé à ‘Suites à donner’


1 entry [1..1]

Soins ou actes prévus ou à programmer (oui / non)

Élément Observation Request (1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1)

Il s'agit d'une observation particulière puisque les données cliniques qu'elle porte ne proviennent pas d'éléments observés, mais d'éléments que l'on souhaite observer dans le cadre du plan de soins.

2 observation [1..1] Les attributs de cet élément prennent les valeurs suivantes :

classCode='OBS'

moodCode='INT'

3 templateId [1..1] Déclaration de conformité root='1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1'

root='2.16.840.1.113883.10.20.1.25'

3 id [1..1] Obligatoire, il aura la forme UID (UUID ou OID)

3 code [1..1]


code='ORG-063'

displayName='Soins ou actes prévus ou à

programmer'

codeSystem='1.2.250.1.213.1.1.4.322'


3 text [1..1] Partie narrative de l’entrée.

4 reference [1..1] Valeur qui fait référence à la partie narrative de la section

3 statusCode [1..1]

Statut de l'observation Valeur issue du vocabulaire HL7 Actstatus (2.16.840.1.113883.1.11.15933)

Par exemple : statusCode='active' pour des résultats attendus

3 effectiveTime [1..1] Date prévue des soins ou actes

3 value [1..1] Soins ou actes prévus ou à programmer Valeur booléenne

1 entry [0..1]

Soins ou actes prévus ou à programmer (texte libre)







classCode='OBS'

moodCode='INT'

3 templateId [1..1] Déclaration de conformité <templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1'/> <templateId root='2.16.840.1.113883.10.20.1.25'/>


3 code [1..1]


code='GEN-090'


codeSystem='1.2.250.1.213.1.1.4.322'




3 statusCode [1..1]

Statut de l'observation Valeur issue du vocabulaire HL7 Actstatus (2.16.840.1.113883.1.11.15933) Par exemple : statusCode='active' pour des résultats attendus

3 effectiveTime [1..1] Date prévue des soins ou actes

3 value [1..1] Soins ou actes prévus ou à programmer Texte libre

1 entry [1..1]

Recommandations et surveillances particulières (oui/non) Élément Observation Request (1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1)



classCode='OBS'

moodCode='INT'


root='2.16.840.1.113883.10.20.1.25'


3 code [1..1]


code=’ORG-064'

displayName='Recommandations et surveillances

particulières'

codeSystem='1.2.250.1.213.1.1.4.322'




3 statusCode [1..1]



3 effectiveTime [1..1] Date prévue

3 value [1..1] Recommandations et surveillances particulières (oui/non) Valeur booléenne

1 entry [0..1]

Recommandations et surveillances particulières (texte libre) Élément Observation Request (1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1)



classCode='OBS'

moodCode='INT'


root='2.16.840.1.113883.10.20.1.25'





3 code [1..1]


code='GEN-090'


codeSystem='1.2.250.1.213.1.1.4.322'




3 statusCode [1..1]

Statut de l'observation Valeur issue du vocabulaire HL7 Actstatus (2.16.840.1.113883.1.11.15933) Par exemple : statusCode='active' pour des résultats attendus


3 value [1..1] Recommandations et surveillances particulières Texte libre

1 entry [1..1]

Suites à donner d’ordre médico-social (oui/non) Élément Observation Request (1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1)



classCode='OBS'

moodCode='INT'


root='2.16.840.1.113883.10.20.1.25'


3 code [1..1]


code='ORG-065'

displayName='Suites à donner d’ordre médico-

social'

codeSystem='1.2.250.1.213.1.1.4.322'




3 statusCode [1..1]




3 value [1..1] Suites à donner d’ordre médico-social (oui/non) Valeur booléenne

1 entry [0..1]

Suites à donner d’ordre médico-social (texte libre) Élément Observation Request (1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1)



classCode='OBS'

moodCode='INT'


root='2.16.840.1.113883.10.20.1.25'





3 code [1..1]


code='GEN-090'


codeSystem='1.2.250.1.213.1.1.4.322'




3 statusCode [1..1]




3 value [1..1] Suites à donner d’ordre médico-social Texte libre

1 entry [0..1]

Autres suites à donner (texte libre)




classCode='OBS'

moodCode='INT'


root='2.16.840.1.113883.10.20.1.25'


3 code [1..1]


code='ORG-066'

displayName='Autres suites à donner’

codeSystem='1.2.250.1.213.1.1.4.322'




3 statusCode [1..1]




3 value [1..1] Autres suites à donner Texte libre

Tableau 16 - Structuration des données de la section Plan de soins





<component>

<section>

<templateId root="2.16.840.1.113883.10.20.1.10"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.36"/>


<code code="18776-5" displayName="Plan de soins"


<title>Suites à donner</title>

<text>

<table border="1">

<thead>

<tr><th colspan="2">Suites à donner</th></tr>

</thead>

<tbody>

<tr>

<td>Soins ou actes prévus ou à programmer</td>

<td><content ID="soins">Non</content></td>

</tr>

<tr>

<td>Si oui, lesquels (Soins ou actes prévus ou à programmer)</td>

<td><content ID="quelsSoins">-</content></td>

</tr>

<tr>

<td>Recommandations et surveillances particulières</td>

<td><content ID="recomm">Non</content></td>

</tr>

<tr>

<td>Si oui, lesquelles (Recommandations et surveillances

particulières)</td>

<td><content ID="quelsRecomm">-</content></td>

</tr>

<tr>

<td>Suites à donner d'ordre médico-social</td>

<td><content ID="suites">Non</content></td>

</tr>

<tr>

<td>Si oui, lesquelles (Suites à donner d'ordre médico-social)</td>

<td><content ID="quelsSuites">-</content></td>

</tr>

<tr>

<td>Autres suites à donner</td>

<td><content ID="autresSuites">-</content></td>

</tr>

</tbody>

</table>

</text>



<entry>

<observation classCode='OBS' moodCode='INT'>

<templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1'/>

<templateId root='2.16.840.1.113883.10.20.1.25'/>

<id root='D99F46A4-C196-44CC-9F77-CB034DF6D1AF'/>

<code code="ORG-063" displayName="Soins ou actes prévus ou à programmer"


<text>

<reference value="soins"></reference>

</text>

<statusCode code='active'/>


<value xsi:type="BL" value="false"/>

</observation>

</entry>



<entry>


<templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1'/>

<templateId root='2.16.840.1.113883.10.20.1.25'/>

<id root='cf5b21bc-387a-44AD-9fe9-d6582a6cf332'/>

<code code="GEN-090" displayName="Lesquels"


<text>



<reference value="quelsSoins"></reference>

</text>




</observation>

</entry>



<entry>


<templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1'/>

<templateId root='2.16.840.1.113883.10.20.1.25'/>

<id root='8378f25f-7ec2-4cee-a9a5-168030827d07'/>

<code code="ORG-064" displayName="Recommandations et surveillances particulières"


<text>

<reference value="recomm"></reference>

</text>




</observation>

</entry>



<entry>


<templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1'/>

<templateId root='2.16.840.1.113883.10.20.1.25'/>

<id root='7649c5fa-a444-49a6-91e9-78d2e5880c67'/>

<code code="GEN-090" displayName="Lesquelles"


<text>

<reference value="quelsRecomm"></reference>

</text>




</observation>

</entry>



<entry>


<templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1'/>

<templateId root='2.16.840.1.113883.10.20.1.25'/>

<id root='1269c206-4d59-4a9d-aa2d-aa0c4622d525'/>

<code code="ORG-065" displayName="Suites à donner d'ordre médico-social"


<text>

<reference value="suites"></reference>

</text>




</observation>

</entry>



<entry>


<templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1'/>

<templateId root='2.16.840.1.113883.10.20.1.25'/>

<id root='c64c6013-c8af-4938-ad10-1b7d26dee2a0'/>

<code code="GEN-090" displayName="Lesquelles"


<text>

<reference value="quelsSuites"></reference>

</text>




</observation>

</entry>





<entry>


<templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.20.3.1'/>

<templateId root='2.16.840.1.113883.10.20.1.25'/>

<id root='010a7a1c-b808-42cb-9352-ac682c57e8fb'/>

<code code="ORG-066" displayName="Autres suites à donner"


<text>

<reference value="autresSuites"></reference>

</text>




</observation>

</entry>

</section>

</component>

Exemple 35 – Section Plan de soins



4 Implémentation dans les logiciels Les aspects d'ergonomie se situent hors du périmètre de ce volet.

4.1 Structuration des données Les volets de contenu définissent la structuration des documents gérés par les logiciels métiers. Ils ne présagent pas de la structuration des données au sein de ces logiciels.

Ainsi, une donnée médicale, qui est utilisée dans plusieurs documents médicaux structurés, peut être gérée de manière unique dans le logiciel métier, sous une forme différente de celle des documents structurés. Le logiciel doit alors assurer la conversion nécessaire vers la structuration de cette donnée dans les documents.

4.2 Echange et partage des documents structurés Le partage et l’échange de documents électroniques conformes aux modèles spécifiés dans le CI-SIS, sont soumis aux prérequis suivants :

Le système initiateur (émetteur du document) doit être capable d’identifier tous les

intervenants (personne physique et personne morale) ayant participé aux actes et à la

production des résultats listés dans le document, conformément au référentiel des PS et des

organisations de santé publié par l’ASIP Santé. Ces intervenants doivent figurer dans le

document en regard des actes qu’ils ont effectués ou des résultats qu’ils ont produits ou

validés.

Le système initiateur doit disposer de certificats de signature conformes au référentiel des

PS et des organisations de santé publié par l’ASIP Santé, afin de permettre aux médecins de

signer les documents qu’ils émettent.

Dans tous les cas, l’identification du patient est obligatoire. Pour la mise en partage du

document dans le DMP, l’identifiant national de santé (INS) du patient est obligatoire. Dans

tous les autres cas (messagerie sécurisée, etc.), l’INS est facultatif, tout autre identifiant

pouvant se substituer à l’INS. Cette disposition est conforme aux spécifications du CI-SIS -

Volet Structuration Minimale de Documents de Santé (2) de la couche Contenu du Cadre

d’Interopérabilité des Systèmes d’Information de Santé (CI-SIS).

4.3 Dispositions de Sécurité Ce volet reprend intégralement les dispositions de sécurité décrites en section 4 « Dispositions de sécurité » du CI-SIS - Volet Structuration Minimale de Documents de Santé (2).

L'imputabilité du contenu d’un document est gérée par la signature électronique apposée par le Responsable du document, identifié dans l'élément ClinicalDocument/LegalAuthenticator.

Pour les spécifications techniques de cette signature, se reporter à la section 4 « Dispositions de sécurité » du CI-SIS - Volet Structuration Minimale de Documents de Santé (2).



5 Annexes

5.1 Décret no 2016-995 du 20 juillet 2016 relatif aux lettres de liaison

JORF n°0169 du 22 juillet 2016 texte n° 22

MINISTÈRE DES AFFAIRES SOCIALES ET DE LA SANTÉ Décret no 2016-995 du 20 juillet 2016 relatif aux lettres de liaison

NOR : AFSH1612283D Publics concernés: professionnels de santé, établissements de santé. Objet: contenu et modalités de transmission de la lettre de liaison. Entrée en vigueur: les dispositions entrent en vigueur le 1er janvier 2017. Notice: le présent décret a pour objet de préciser le contenu et les modalités de transmission de la lettre de liaison. Il précise le contenu attendu d’une lettre de liaison à l’entrée de l’établissement de santé et le contenu de la lettre de liaison à la sortie de cet établissement ainsi que les modalités de transmission et de remise de la lettre au patient. Références: le décret est pris pour l’application de l’article 95 de la loi no 2016-41 du 26 janvier 2016 de modernisation de notre système de santé. Les dispositions du code de la santé publique modifiées par le présent décret peuvent être consultées dans leur rédaction résultant de cette modification, sur le site Légifrance (http://www.legifrance.gouv.fr/). Le Premier ministre, Sur le rapport de la ministre des affaires sociales et de la santé, Vu le code de la santé publique, notamment son article L. 1112-1; Vu l’avis du Conseil national de l’ordre des médecins en date du 18 mai 2016; Le Conseil d’Etat (section sociale) entendu, Décrète :

Article 1 La section 1 du chapitre II du titre Ier du livre Ier de la première partie du code de la santé publique est ainsi modifiée : 1- Le quatrième alinéa de l’article R. 1112-1 est supprimé; 2- Après l’article R. 1112-1, il est inséré deux articles ainsi rédigés : « Art. R. 1112-1-1. – Le praticien qui adresse un patient à un établissement de santé accompagne sa demande d’une lettre de liaison synthétisant les informations nécessaires à la prise en charge du patient dont il dispose sur son lieu d’intervention, dans le respect des conditions prévues à l’article L. 1110-4. Cette lettre comprend notamment les motifs de la demande d’hospitalisation, les traitements en cours et les allergies connus. Elle est adressée par messagerie sécurisée répondant aux conditions prévues à l’article L. 1110-4-1, ou par tout moyen garantissant la confidentialité des informations. Elle est versée dans le dossier médical partagé du patient si ce dossier a été créé, ou lui est remise. «Lorsqu’il est fait application de l’article L. 3213-1, le certificat médical circonstancié tient lieu de lettre de liaison pour l’admission dans l’établissement d’accueil. « Art. R. 1112-1-2. – I. – Lors de la sortie de l’établissement de santé, une lettre de liaison, rédigée par le médecin de l’établissement qui l’a pris en charge, est remise au patient par ce médecin, ou par un autre membre de l’équipe de soins mentionnée au 1o de l’article L. 1110-12 qui l’a pris en charge, et qui s’assure que les informations utiles à la continuité des soins ont été comprises. Dans le respect des dispositions des articles L. 1110-4 et L. 1111-2, la lettre de liaison est transmise le même jour, au médecin traitant et, le cas échéant, au praticien qui a adressé le patient. Elle est adressée par messagerie sécurisée répondant aux conditions prévues à l’article L. 1110-4-1, ou par tout moyen garantissant la confidentialité des informations, et versée dans le dossier médical partagé du patient si ce dossier a été créé.

http://www.legifrance.gouv.fr/



II. – Cette lettre de liaison contient les éléments suivants: 1- Identification du patient, du médecin traitant, le cas échéant du praticien adresseur, ainsi que l’identification du médecin de l’établissement de santé qui a pris en charge le patient avec les dates et modalités d’entrée et de sortie d’hospitalisation ; 2- Motif d’hospitalisation ; 3- Synthèse médicale du séjour précisant le cas échéant, les événements indésirables survenus pendant l’hospitalisation, l’identification de micro-organismes multirésistants ou émergents, l’administration de produits sanguins ou dérivés du sang, la pose d’un dispositif médical implantable; 4- Traitements prescrits à la sortie de l’établissement (ou ordonnances de sortie) et ceux arrêtés durant le séjour et le motif d’arrêt ou de remplacement, en précisant, notamment pour les traitements médicamenteux, la posologie et la durée du traitement; 5- Annonce, le cas échéant, de l’attente de résultats d’examens ou d’autres informations qui compléteront cette lettre de liaison; 6- Suites à donner, le cas échéant, y compris d’ordre médico-social, tels que les actes prévus et à programmer, recommandations et surveillances particulières.»

Article 2 Le code de la santé publique est ainsi modifié: 1- Au a du 1 de l’article R. 1112-2, les mots: «de l’admission» sont remplacés par les mots: «, en cas d’admission, la lettre de liaison prévue à l’article R. 1112-1-1»; 2- Au a du 2 de l’article R. 1112-2, les mots: «Le compte rendu d’hospitalisation et la lettre rédigée à l’occasion de la sortie» sont remplacés par les mots: «La lettre de liaison remise à la sortie prévue par l’article R. 1112-1-2»; 3- A l’article R. 1112-60, les mots: «le plus tôt possible», sont remplacés par les mots: «par la lettre de liaison prévue à l’article R. 1112-1-2»; 4- A l’article R. 1112-61, après les mots: «Tout malade sortant reçoit», sont insérés les mots: «la lettre de liaison prévue à l’article R. 1112-1-2, »; 5- Le second alinéa de l’article R. 6123-22 est supprimé.

Article 3 Le présent décret entre en vigueur le 1er janvier 2017.

Article 4 La ministre des affaires sociales et de la santé est chargée de l’exécution du présent décret, qui sera publié au Journal officiel de la République française. Fait le 20 juillet 2016. Par le Premier ministre : MANUEL VALLS La ministre des affaires sociales et de la santé, MARISOL TOURAINE



5.2 Documents de référence

1. Décret n° 2016-995 du 20 juillet 2016 relatif aux lettres de liaison.

2. ASIP Santé. CI-SIS - Volet Structuration Minimale de Documents de Santé.

3. HL7. Clinical Document Architecture Normative Edition (CDAr2) - HL7, Inc. 2. September 25, 2005.

4. IHE Patient Care Coordination (PCC). Technical Framework - IHE International. [ed.] IHE PCC. Final Text rev.6. 2012. Vol. 1&2.

5. ASIP Santé. CI-SIS - Volet Modèles de Contenus CDA.

6. Haute Autorité de Santé. Charte de qualité des bases de données sur les médicaments destinés à l'usage des LAP candidats à la certification de la HAS - HAS. Juin 2008.

5.3 Historique du document

Liste des codes modifiés dans le volet LDL v1.1.18 : Libellé Ancien code

Nouveau code

Synthèse médicale LDL-01 TA_LDL 1.2.250.1.213.1.1.4.333

MED-142 TA_ASIP 1.2.250.1.213.1.1.4.322

Evenements indésirables survenus pendant l'hospitalisation

LDL-02 TA_LDL 1.2.250.1.213.1.1.4.333

MED-143 TA_ASIP 1.2.250.1.213.1.1.4.322

Description LDL-03 TA_LDL 1.2.250.1.213.1.1.4.333

GEN-089 TA_ASIP 1.2.250.1.213.1.1.4.322

Identifiants de micro-organismes multirésistants

LDL-04 TA_LDL 1.2.250.1.213.1.1.4.333

MED-144 TA_ASIP 1.2.250.1.213.1.1.4.322

Transfusion de produits sanguins LDL-05 TA_LDL 1.2.250.1.213.1.1.4.333

MED-145 TA_ASIP 1.2.250.1.213.1.1.4.322

Accidents transfusionnels LDL-06 TA_LDL 1.2.250.1.213.1.1.4.333

MED-146 TA_ASIP 1.2.250.1.213.1.1.4.322

Administration de dérivés du sang LDL-07 TA_LDL 1.2.250.1.213.1.1.4.333

MED-147 TA_ASIP 1.2.250.1.213.1.1.4.322

Evenements indésirables LDL-08 TA_LDL 1.2.250.1.213.1.1.4.333

MED-148 TA_ASIP 1.2.250.1.213.1.1.4.322

Pose d'un dispositif médical implantable

LDL-09 TA_LDL 1.2.250.1.213.1.1.4.333

MED-149 TA_ASIP 1.2.250.1.213.1.1.4.322

Nature du DMI LDL-10 TA_LDL 1.2.250.1.213.1.1.4.333

MED-150 TA_ASIP 1.2.250.1.213.1.1.4.322

Site d'implantation LDL-11 TA_LDL 1.2.250.1.213.1.1.4.333

MED-151 TA_ASIP 1.2.250.1.213.1.1.4.322

Résultats d’examens LDL-12 TA_LDL 1.2.250.1.213.1.1.4.333

MED-152 TA_ASIP 1.2.250.1.213.1.1.4.322

Attente de résultats d’examens à venir ou d’autres informations

LDL-13 TA_LDL 1.2.250.1.213.1.1.4.333

MED-153 TA_ASIP 1.2.250.1.213.1.1.4.322

Version Date Action

0.0.1 30/05/2016 Création du volet LDL

0.1.16 17/01/2017 Mise en concertation

1.1.17 19/04/2017 Publication du volet LDL

1.2 04/12/2017

Correction formatCode LDL-EES et LEL-SES. Correction section Ordonnance de sortie pour rendre l’entrée Medication facultative. Dans les spécifications, suppression des explications en double. Modification des codes LDL-XXX en nouveaux codes GEN, MED, ORG (voir tableau ci-dessous)

1.3 29/01/2018 Correction du formatCode LDL-EES etLDL-SES



Lesquesls LDL-14 TA_LDL 1.2.250.1.213.1.1.4.333

GEN-090 TA_ASIP 1.2.250.1.213.1.1.4.322

Soins ou actes prévus ou à programmer

LDL-15 TA_LDL 1.2.250.1.213.1.1.4.333

ORG-063 TA_ASIP 1.2.250.1.213.1.1.4.322

Recommandations et surveillances particulières

LDL-16 TA_LDL 1.2.250.1.213.1.1.4.333

ORG-064 TA_ASIP 1.2.250.1.213.1.1.4.322

Suites à donner d'ordre médico-social LDL-17 TA_LDL 1.2.250.1.213.1.1.4.333

ORG-065 TA_ASIP 1.2.250.1.213.1.1.4.322

Autres suites à donner LDL-18 TA_LDL 1.2.250.1.213.1.1.4.333

ORG-066 TA_ASIP 1.2.250.1.213.1.1.4.322

Allergies connues LDL-19 TA_LDL 1.2.250.1.213.1.1.4.333

MED-155 TA_ASIP 1.2.250.1.213.1.1.4.322

Traitements connus LDL-20 TA_LDL 1.2.250.1.213.1.1.4.333

MED-156 TA_ASIP 1.2.250.1.213.1.1.4.322

Autre information LDL-21 TA_LDL 1.2.250.1.213.1.1.4.333

GEN-091 TA_ASIP 1.2.250.1.213.1.1.4.322

Autres traitements LDL-22 TA_LDL 1.2.250.1.213.1.1.4.333

MED-154 TA_ASIP 1.2.250.1.213.1.1.4.322

Urgence LDL-23 TA_LDL 1.2.250.1.213.1.1.4.333

ORG-067 TA_ASIP 1.2.250.1.213.1.1.4.322

Programmée LDL-24 TA_LDL 1.2.250.1.213.1.1.4.333

ORG-068 TA_ASIP 1.2.250.1.213.1.1.4.322

Transfert LDL-25 TA_LDL 1.2.250.1.213.1.1.4.333

ORG-069 TA_ASIP 1.2.250.1.213.1.1.4.322

Autre LDL-26 TA_LDL 1.2.250.1.213.1.1.4.333

GEN-092 TA_ASIP 1.2.250.1.213.1.1.4.322

Modalité d’entrée LDL-27 TA_LDL 1.2.250.1.213.1.1.4.333

ORG-070 TA_ASIP 1.2.250.1.213.1.1.4.322

Si réponse autre LDL-28 TA_LDL 1.2.250.1.213.1.1.4.333

GEN-093 TA_ASIP 1.2.250.1.213.1.1.4.322

SSR LDL-29 TA_LDL 1.2.250.1.213.1.1.4.333

ORG-071 TA_ASIP 1.2.250.1.213.1.1.4.322

HAD LDL-30 TA_LDL 1.2.250.1.213.1.1.4.333

ORG-072 TA_ASIP 1.2.250.1.213.1.1.4.322

Autre établissement de santé LDL-31 TA_LDL 1.2.250.1.213.1.1.4.333

ORG-073 TA_ASIP 1.2.250.1.213.1.1.4.322

Modalité de sortie LDL-32 TA_LDL 1.2.250.1.213.1.1.4.333

ORG-074 TA_ASIP 1.2.250.1.213.1.1.4.322

*** FIN DU DOCUMENT ***



Réf

éren

tie

ls -

Cad

re d

’inte

rop

érab

ilité

de

s sy

stèm

es d

’info

rmat

ion

s d

e sa

nté

(C

I-SI

S) -

Co

uch

e C

on

ten

us

- V

ole

t Le

ttre

de

Liai

son

(LD

L) –

29

/01

/20

18

– V

1.3