Volet Structuration Minimale de Documents Médicaux

Transcription

1 Cadre d Interopérabilité des SIS Couche Contenu Volet Structuration Minimale de Documents Médicaux Identification du document Référence Date de création 26/05/2009 Date de dernière mise à jour 25/06/2009 Rédaction Cadre d'interopérabilité SIS - couche Contenu - Volet Structuration Minimale DRAS Version V Nombre de pages 27 Documents de référence 1. HL7 : Clinical Document Architecture, Release 2.0 Normative Edition September 25, IHE : Cadre Technique IT Infrastructure, volumes 1 et 2 3. HL7 France : Spécifications françaises Guide d Implémentation de l en-tête CDA r2 v ASIP : Cadre_Interop_SIS_Annexes_Nomenclatures_Métadonnées.xls 5. ASIP : Cadre_Interop_SIS_Annexes_Liens_entre_entête_CDA_et_Métadonnées.xls Classification : public 1 / 27

2 Historique du document Version Date Action V /06/2009 Publication pour première phase de concertation Classification : public 2 / 27

3 Sommaire 1 POSITIONNEMENT DANS LE CADRE D INTEROPERABILITE PRE-REQUIS SPECIFICATIONS ENTETE DES DOCUMENTS CDA (HEADER) Portée Références Universalité et souplesse du standard CDA Espaces de nommage XML Eléments non renseignés et usage de l attribut nullflavor Règles de structuration génériques Identifiants de professionnels et de structures de santé Eléments de l entête qualifiant le document realmcode Périmètre d utilisation typeid templateid Déclarations de conformité id Identification du document effectivetime Date et heure de création relateddocument Version précédente à remplacer code Type du document title Titre du document confidentialitycode Niveau de confidentialité languagecode Langue principale Eléments de l entête relatifs aux participants recordtarget - Patient recordtarget/patientrole/id Identifiants patient recordtarget/patientrole/patient/name Identité patient author Auteur du document legalauthenticator Responsable du document custodian Organisation émettrice Eléments de l entête qualifiant l acte documenté documentationof/serviceevent Acte ou diagnostic documenté Cadre d exercice de l acte principal infulfillmentof - Prescription participant[@typecode=«ref»] - Prescripteur componentof/encompassingencounter Rencontre ou venue componentof/encompassingencounter/location/healthcarefacility/code CORPS NON STRUCTURE (NIVEAU 1) D UN DOCUMENT CDA R Références ClinicalDocument/component/nonXMLBody DISPOSITIONS DE SECURITE IMPUTABILITE ET INTEGRITE DU DOCUMENT MEDICAL Documents élaborés par un PS ou un système sous la responsabilité d un PS ANNEXES ANNEXE 1 : EXEMPLE D UNE FICHE DE CONSULTATION PATIENT Classification : public 3 / 27

4 1 Positionnement dans le cadre d interopérabilité Le texte surligné en jaune de ce document signale du texte temporaire en attente d une décision ou d une ressource extérieure. Ce volet fait partie de la couche «Contenu» du Cadre d Interopérabilité des Systèmes d Information de Santé. Il spécifie la structuration minimale des documents médicaux requise pour tout projet d échange ou de partage d informations de santé s appuyant sur ce Cadre d Interopérabilité. Les documents médicaux partagés ou échangés dans le périmètre du Cadre d Interopérabilité des SIS doivent se conformer aux spécifications HL7 Clinical Document Architecture, Release 2.0 (CDA R2) publiées dans l Edition Normative HL7 v3 de Mai Ce standard CDA R2 de documents médicaux électroniques s appuie sur une syntaxe xml. Les documents médicaux sont des documents xml bien formés qui doivent être valides au regard du schéma CDA.xsd, partie intégrante de la spécification CDA R2. Un document CDA se compose d un entête qui précise le contexte, et d un corps. Le présent volet affine les spécifications du standard CDA R2 concernant le remplissage de l entête. Cette partie des spécifications du volet est applicable à tous les contenus partagés ou échangés dans le périmètre du Cadre d Interopérabilité des SIS en France, toutes spécialités confondues. A ce titre, tous les autres volets de la couche «Contenu» de ce Cadre d Interopérabilité, dépendent du présent volet pour ce qui concerne le remplissage de l entête CDA des documents médicaux. Ceci n exclut pas que certains des volets de la couche Contenu apportent des contraintes supplémentaires à l entête CDA, inhérentes à une spécialité particulière ou propres à certains types d organisations de santé. De plus, le présent volet spécifie le formatage dans le corps CDA R2, des documents médicaux non structurés se présentant sous la forme d un document textuel (ex : pdf/a-1, txt, rtf) ou d une image (ex : jpeg, tiff). A ce titre, ce volet est une déclinaison du profil IHE XDS-SD décrit dans le cadre technique IT Infrastructure d IHE. Les contenus conformes à ce volet sont partageables ou échangeables en s appuyant sur les spécifications des volets de la couche «Service» du Cadre d Interopérabilité des SIS. Le présent volet «Structuration Minimale de Documents Médicaux» s appuie sur les volets de la couche «Service» du Cadre d Interopérabilité. Classification : public 4 / 27

5 2 Pré-requis La dématérialisation d un document médical à des fins de partage ou d échange pour améliorer la coordination des soins est soumise à un certain nombre de conditions : Persistance : Le document dématérialisé doit rester inaltérable et accessible pour une période dont la durée est fonction du cadre réglementaire et des règles mises en place par la communauté de soins. Administration : L organisation émettrice du document dématérialisé doit en assurer la gestion et le suivi, en mettant à disposition les éventuelles mises à jour. Responsabilité : Le document médical dématérialisé doit être endossé par le responsable personne physique assumant l entière responsabilité du contenu du document qui est aussi le signataire légal du document lorsque la signature électronique est mise en œuvre. Cohérence : Le document embarque le contexte (médical et de gestion) de son contenu ; contenu et contexte restent indissociables et seul le tout peut être authentifié par une signature électronique. Lisibilité : Le document médical dématérialisé doit pouvoir être restitué aux personnes habilitées à le lire, dans une présentation prédéterminée par l auteur du document, au travers d un outil de visualisation banalisé tel qu un navigateur web. Le respect de ces conditions préalables exigées par le Cadre d Interopérabilité des SIS se traduit d une part sous la forme de règles organisationnelles que doit s imposer la communauté des acteurs partageant ou échangeant des documents médicaux électroniques (identification univoque du patient, du responsable, de l auteur et de l organisation émettrice à l intérieur de chaque document, mise en place de l infrastructure de persistance et des politiques d accès). D autre part ces conditions orientent le choix du standard de documents médicaux électroniques : En l occurrence HL7 CDA R2 est le standard satisfaisant le mieux les conditions énoncées, par conception. De plus ce standard est capable de coupler dans un même document : Le contenu lisible sans médiation et présenté dans son contexte avec toute la clarté requise au lecteur humain, les données de santé codées et structurées dont dérive ce contenu, directement intégrables dans les bases de données des SIS des professionnels qui le souhaitent. Classification : public 5 / 27

6 3 Spécifications 3.1 Entête des documents CDA (Header) Portée Les spécifications de la présente section 3.1 s imposent à tous les contenus partagés ou échangés dans le périmètre du Cadre d Interopérabilité des SIS Références Les spécifications de cette section s appuient sur : Le standard HL7 CDA R2 dans son édition normative de mai 2005 (accessible aux adhérents de HL7 sur incluant : o le Reference Information Model (RIM) 2.07 de HL7 o Les domaines de vocabulaire de HL7, révision de janvier 2005 o La spécification abstraite des types de données HL7 V3, R o La spécification implémentable en XML des types de données HL7 V3, R o La spécification CDA R2 proprement dite, comprenant le schéma CDA.xsd Le guide d implémentation de l entête CDA dans le contexte français publié par HL7 France en tant que «draft for trial implementation» le 25 février Cette section s appuie sur les spécifications du guide d implémentation de l entête CDA dans le contexte français publié par HL7 France, et ne décrit que les différences apportées par le présent volet du Cadre d Interopérabilité des SIS, sous la forme de contraintes supplémentaires (optionalité, cardinalités, nomenclatures) Universalité et souplesse du standard CDA Le standard CDA est comme son nom l indique une architecture de documents cliniques : Il est possible de construire sur le schéma CDA.xsd des modèles de documents adaptés à la plupart des spécialités médicales et à la plupart des contextes d usage. Un document CDA se compose d un entête et d un corps. L entête est toujours structuré. En revanche, le degré de structuration du corps peut varier en fonction des besoins. Le standard CDA R2 définit trois niveaux possibles de structuration pour le corps du document : Niveau 1 = Non structuré : Le contenu texte ou image est sous une forme non xml, (pdf/a-1, txt, rtf, jpeg ou tiff), encapsulée en base 64 dans le corps. Niveau 2 = Structuré pour le lecteur : Le texte du document est formaté en xml dans le corps, organisé en une liste hiérarchisée de sections (chapitres, sous-chapitres ) A l intérieur de chaque section, le texte figure dans un bloc <text>, qui peut être organisé à l aide de structures telles que paragraphes, tableaux, notes, figures, références... Les sections annoncent leur contenu à l aide d un code de section (couramment tiré de la nomenclature LOINC) associé à un Classification : public 6 / 27

7 libellé et optionnellement à un titre. Les sections peuvent si nécessaire s emboiter les unes dans les autres. Niveau 3 = Structuré pour le lecteur et pour le SIS : Le corps du document est organisé en sections comme dans le niveau 2. Mais en plus, chaque section peut comporter un ou plusieurs blocs <entry> embarquant les données du SIS producteur dont dérive le texte de la section. La vocation d un bloc <entry> est de fournir le contenu sous une forme codée et structurée, importable et intégrable dans la base de données du SIS du professionnel de santé qui consulte le document. Figure 1 - Les trois niveaux possibles de structuration d un document CDA La structure de l entête demeure identique quel que soit le type de document et quel que soit le niveau de structuration choisi. Les éléments de l entête portent sur : La qualification du document : identifiant globalement unique, type, modèles, date de création, identifiant, titre, langage, niveau de confidentialité, version, lien avec la version précédente. La qualification de l acte (ou des) acte(s) documenté(s) : code acte, prestataire, prescription, horodatage, venue, cadre d exercice, modalité d exercice, lieu d exercice. Les participants : patient, auteur, responsable, organisation émettrice, valideurs, destinataires désignés, autres participants L entête d un document CDA fournit donc des données relativement neutres du point de vue médical, permettant de relier le document à un contexte de soins, de le classer dans les catégories adéquates, et de gérer son accessibilité dans la durée Espaces de nommage XML Les éléments XML du document CDA appartiennent à l espace de nommage HL7 V3, dont l URL est urn:hl7-org:v3. Classification : public 7 / 27

8 L élément racine d un document médical au format CDA R2 est <ClinicalDocument>. Cet élément déclare les différents espaces de nommage utilisés. Exemple : <ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi=" xsi:schemalocation="urn:hl7-org:v3 CDA.xsd"> Eléments non renseignés et usage de l attribut nullflavor Toutes les classes du RIM HL7 dérivent d une classe abstraite (InfrastructureRoot), porteuse de 4 propriétés structurelles dont elles héritent. nullflavor : de type CS realmcode : de type SET <CS> typeid : de type II templateid : de type LIST <II> Au niveau du schéma xml de CDA (CDA.xsd), tout élément de type complexe, appartenant à l entête ou au corps, hérite de ces 4 propriétés : nullflavor en tant qu attribut optionnel realmcode, typeid et templateid en tant qu éléments fils optionnels. En particulier, l attribut nullflavor doit être valorisé dans un élément lorsque le contenu de cet élément ne peut être renseigné. Cet attribut nullflavor en précise la raison. La présente spécification restreint le domaine de vocabulaire de l attribut nullflavor à ces valeurs, conformément au guide d implémentation de l entête CDA dans le contexte français publié par HL7 France : Valeur UNK NASK ASKU NAV Signification Inconnu Non demandé Demandé mais non connu Temporairement indisponible La présente spécification exige que l attribut nullflavor soit présent et valorisé dans tout élément obligatoire dont le contenu est non renseigné. Exemple : <telecom nullflavor= NASK /> En outre, la présente spécification impose que les éléments suivants de l entête CDA soient toujours présents et renseignés, et donc interdit pour ceux-ci l usage de l attribut nullflavor : Classification : public 8 / 27

9 Eléments pour lesquels l attribut nullflavor est interdit : Elément de l entête CDA (expression XPath à partir de la racine du document) Card. Contenu code [1..1] Type du document id [1..1] Identifiant globalement unique d une version du document title [1..1] Titre du document languagecode [1..1] Langue du document : «fr-fr» confidentialitycode [1..1] Niveau de confidentialité du doc. effectivetime [1..1] Date et heure de création du doc. legalauthenticator [1..1] Responsable du contenu du doc, signataire légal legalauthenticator/assignedentity/id [1..1] Identifiant du Responsable legalauthenticator/assignedentity/assignedperson [1..1] Identité du Responsable legalauthenticator/assignedentity/assignedperson/name [1..1] Nom et prénom du Responsable author [1..2] une personne et/ou un système. author/assignedauthor [1..1] une personne ou un système. author/assignedauthor/code [1..1] Profession/spécialité de l auteur author/assignedauthor/representedorganization [1..1] Entreprise de santé pour le compte de laquelle le document a été produit custodian [1..1] Structure émettrice, responsable du cycle de vie du document recordtarget/patientrole/id [1..*] Les identifiants du patient. Il faut au minimum l identifiant de santé global : INS-A ou INS-C documentationof [1..*] Au moins un acte documenté documentationof/serviceevent/ [1..1] Acte documenté. documentationof/serviceevent/code [1..1] Code de l acte documenté documentationof/serviceevent/effectivetime [0..1] Bornes temporelles de l acte principal documenté. documentationof/serviceevent/effectivetime/low [1..1] Début de l acte principal documenté documentationof/serviceevent/performer [0..1] Effecteur de l acte principal documenté documentationof/serviceevent/performer/assignedentity/ representedorganization/standardindustryclasscode componentof/encompassingencounter/location/ healthcarefacility/code [1..1] Cadre d exercice de l acte principal documenté [1..1] Modalité d exercice = Secteur d activité Classification : public 9 / 27

10 3.1.6 Règles de structuration génériques La présente spécification reprend à son compte les règles de structuration génériques énoncées dans le guide d implémentation de l entête CDA dans le contexte français publié par HL7 France, dans son chapitre 1 «Règles communes», qui comprend : 1.1 Encodage XML 1.2 Construction des identifiants 1.3 Données codées 1.4 Temps 1.5 Personnes et structures Identifiants de professionnels et de structures de santé Le Cadre d Interopérabilité des SIS utilisera deux OID distinctifs pour construire les identifiants des acteurs de santé : Un OID pour les professionnels de santé : P Un OID pour les structures de santé : S Ces deux OID sont à définir par le GIP CPS Eléments de l entête qualifiant le document realmcode Périmètre d utilisation Spécification Cet élément définit le périmètre d utilisation potentielle du document. Il est obligatoire et fixé à la valeur «FR» en majuscules, à l identique du guide d implémentation de l entête CDA dans le contexte français publié par HL7 France. <realmcode code="fr"/> Source Paramètre d utilisation ou de configuration du LPS si le progiciel a une diffusion plus large que le marché français typeid Spécification Obligatoire Cardinalités [1..1] Fixe pour tout document CDA-R2 : <typeid root=" " extension="pocd_hd000040"/> où est l OID représentant l organisation HL7 Inc. et POCD_HD représente le standard CDA R2 lui-même Source Propriété de l interface CDA du LPS. Classification : public 10 / 27

11 templateid Déclarations de conformité Spécification Deux déclarations de conformité à des modèles doivent apparaître au minimum : <templateid root=" "/> <templateid root=" x.y.z"/> La première indique que le document est en conformité avec le guide d implémentation de l entête CDA dans le contexte français publié par HL7 France. La seconde indique la conformité avec le présent volet du Cadre d Interopérabilité des SIS : X est l OID représentant l ASIP (en cours d acquisition auprès de l AFNOR), X.Y est l OID représentant le Cadre d Interopérabilité des SIS, et X.Y.Z représente le présent volet «Structuration minimale de documents médicaux» De plus, lorsque le document médical est non structuré (Niveau 1), il doit alors se conformer au profil XDS-SD publié par IHE dans le cadre technique IT Infrastructure. Dans ce cas, une troisième déclaration de conformité, formulée comme ci-dessous, complète l élément templateid de l entête : <templateid root=" "/> Source Paramètre de l interface CDA du LPS id Identification du document Spécification Cet élément porte l identifiant globalement unique de l instance courante (la version courante) du document : Lorsqu il existe plusieurs versions successives d un même document chacune est identifiée de façon unique par cet élément. Obligatoire Attribut nullflavor interdit Cardinalités [1..1] Type : II, composition : o un attribut root obligatoire, contenant obligatoirement un OID qui identifie de manière unique soit l émetteur du document, soit le document lui-même o un attribut extension qui doit être renseigné pour identifier cette instance du document si l OID de l attribut root n identifie que l émetteur. Voir exemple global de mise à jour de document sous la description de l élément relateddocument Source Valeur produite à la volée par le LPS, en s appuyant sur son paramétrage effectivetime Date et heure de création Spécification Cet élément porte la date et l heure de création de la version courante du document. Le temps de création est noté par rapport à GMT et doit être précisé à la seconde. Classification : public 11 / 27

12 Obligatoire Attribut nullflavor interdit Cardinalités [1..1] Pour le format, voir section 1.4 du guide d implémentation de l entête CDA dans le contexte français. Exemple pour un document créé le 29/05/2009 à 09:49:14 (à GMT + 1) : <effectivetime value=" "/> Source Horodatage à la volée par le LPS relateddocument Version précédente à remplacer Spécification Cet élément est présent lorsque la version courante du document remplace une version précédente. L élément désigne l instance précédente (élément fils <parentdocument>) et précise l action apportée par l instance courante : attribut typecode valorisé à «RPLC», c est-à-dire «annule et remplace». Cet élément doit être présent si et seulement si une nouvelle version d un document est publiée, en remplacement d une version précédente. Le présent volet adopte les règles de mise à jour de documents médicaux énoncées par le guide d implémentation de l entête CDA dans le contexte français publié par HL7 France, (dans sa section 2.22), en y ajoutant les contraintes suivantes, déjà énoncées plus haut : Exemple : L élément setid est facultatif et son usage n est pas recommandé L élément versionnumber est facultatif L élément effectivetime est obligatoire et représente la date et heure de production de la version courante. Publication le 29/05/2009 à 09:49:14 (GMT+1) de la version 2 d un document identifiée 456, en remplacement de la version 1 identifiée 123 : <id extension="456" root=" x.y.z.99"/> <!-- Elements intermédiaires non montrés --> <effectivetime value=" "/> <!-- Elements intermédiaires non montrés --> <relateddocument typecode="rplc"> <parentdocument> <id extension="123" root=" x.y.z.99"/> </parentdocument> </relateddocument> Source Données de gestion des versions d un même document du LPS. Classification : public 12 / 27

13 code Type du document Spécification Cet élément précise le type du document. Obligatoire Attribut nullflavor interdit Cardinalités [1..1] Nomenclature utilisée : le sous-ensemble de LOINC, défini dans l onglet «typecode» de l annexe «Cadre_Interop_SIS_Nomenclatures.xls». Composition exigée par la présente spécification : Attribut Type Card. Signification code cs 1..1 Code du type de document codesystem uid 1..1 OID du système de codage LOINC : codesystemname st 1..1 Libellé du système de codage : «LOINC» displayname st 1..1 Libellé du type de document Quelques exemples de types de documents : Code Libellé LOINC d origine Libellé du type de document Summarization of episode note Note de synthèse d épisode de soins Multidisciplinary evaluation and management note Fiche de reunion de concertation pluridisciplinaire Physician hospital discharge summary Lettre de sortie LABORATORY REPORT TOTAL Résultats d examens biologiques HISTORY OF MEDICAL DEVICE USE Prothèses et appareillages en place Allergies, adverse reactions, alerts Allergies, intolérances reconnues HISTORY OF IMMUNIZATIONS Vaccinations Functional Status Assessment Bilan d'évaluation fonctionnelle ou de la perte d'autonomie Surgical operation note anesthesia CR d'anesthésie Labor and delivery records CR accouchement Exemple tiré du guide d implémentation de l entête CDA dans le contexte français : <code /> code=" " codesystem=" " codesystemname="loinc" displayname=" Résultats d examens biologiques" Source Produit par le LPS à partir d une nomenclature externe ou paramétrée dans son interface CDA. Classification : public 13 / 27

14 title Titre du document Spécification Cet élément porte le titre du document sous la forme d une chaîne de caractères. Exemple : Obligatoire Cardinalités [1..1] Type : ST <title>compte rendu d hospitalisation court séjour</title> Source Paramètre du LPS ou donnée choisie ou saisie par l auteur confidentialitycode Niveau de confidentialité Spécification Cet élément précise le niveau de confidentialité voulu pour le document. Exemple : Obligatoire Attribut nullflavor interdit Cardinalités [1..1] Voir format dans le guide d implémentation de l entête CDA dans le contexte français. Pour mémoire, le vocabulaire comporte ces trois valeurs possibles : N = Normal, R = Restreint, V = Très Restreint. <confidentialitycode code="n" codesystem=" " displayname="normal"/> Source Donnée sélectionnée par le LPS ou choisie par l auteur languagecode Langue principale Spécification Cet élément précise la langue principalement utilisée dans le document. Exemple : Obligatoire Attribut nullflavor interdit Cardinalités [1..1] Le code à utiliser est fr-fr (Français métropolitain). La casse des caractères doit être respectée. La partie en minuscules indique le code langage utilisé (ISO-639-1), et celle en majuscules le code pays (ISO-3166). <languagecode code="fr-fr"/> Classification : public 14 / 27

15 Source Paramètre d utilisation ou de configuration du LPS si diffusion plus large que le marché français ou si le PS peut produire des documents médicaux dans différentes langues Eléments de l entête relatifs aux participants recordtarget - Patient Spécification Cet élément identifie le (ou les) 1 patient(s) concerné(s) par le document. Pour la représentation du patient, la présente spécification se conforme au guide d implémentation de l entête CDA dans le contexte français. Ellet requiert du LPS la capacité de gérer plusieurs identifiants pour un patient, dont l INS-C (calculé) et l INS-A. Elle ajoute les contraintes suivantes pour les éléments fils : recordtarget/patientrole/id Identifiants patient Spécification Cet élément contient le ou les identifiants du patient. Obligatoire Attribut nullflavor interdit Cardinalités [1..*] Composition : Les deux attributs root et extension doivent obligatoirement être renseignés. L attribut root contient obligatoirement l OID de l autorité d affectation de l identifiant du patient et l attribut extension contient cet identifiant. La présence de l Identifiant National de Santé (INS) du patient est obligatoire. Une occurrence de recordtarget/patientrole/id doit représenter cet INS, reconnaissable à son OID : OID de l INS-C : X.W.1 OID de l INS-A : X.W.2 L INS est stocké dans l attribut extension, dans son intégralité (clé de contrôle incluse). L INS-C est sur 22 chiffres. L INS-A est sur 13 chiffres. Exemple d un patient représenté par son INS-A : <recordtarget> <patientrole> <id extension=" " root=" x.w.2"/> <!-- éléments intermédiaires non montrés dans l exemple --> </patientrole> </recordtarget> 1 Un exemple de document associé à plus d un patient est celui d un document commun à la mère et à l enfant, produit après la naissance de ce dernier. Classification : public 15 / 27

16 recordtarget/patientrole/patient/name Identité patient Spécification Obligatoire Cardinalités [1..1] Composition : o name/given [1..*] : les prénoms o name/family [1..*] : les = BR nom de = SP nom d = CL pseudonyme ou alias Exemple : <recordtarget> <patientrole> <id extension="15078" root=" x.w.1"/> <addr> <streetaddressline>1, rue du Chat qui Pêche</streetAddressLine> <city>paris</city> <postalcode>75005</postalcode> <country>france</country> </addr> <telecom value="tel: "/> <patient> <name> <given>jeanne</given> <family qualifier="sp">duroc</family> <family qualifier="br">vaneau</family> </name> <administrativegendercode code="f" codesystem= " "/> <birthtime value=" "/> </patient> </patientrole> </recordtarget> author Auteur du document Spécification Cet élément représente les participations du ou des auteurs du document, ainsi que de l entreprise de santé impliquée. La présente spécification se conforme au guide d implémentation de l entête CDA dans le contexte français. En particulier, lorsque l auteur est une personne les spécifications de d implémentation de l entête CDA dans le contexte français s appliquent : Nom de la personne et identifiant sont obligatoires. La présente spécification ajoute les contraintes supplémentaires définies ci-après : Cardinalités [1..2] pour l élément author : Un auteur personne (authorperson) et/ou un auteur dispositif médical (authoringdevice). author/assignedauthor/code obligatoire, en utilisant la nomenclature authorspecialty définie dans l onglet «typecode» de l annexe Classification : public 16 / 27

17 «Cadre_Interop_SIS_Nomenclatures_Métadonnées.xls» : Le rôle structurel de l auteur représente sa profession et sa spécialité qui alimentent la métadonnée XDSDocumentEntry.authorSpecialy. author/assignedauthor/assignedperson : Identifie l auteur humain du document (1 au plus) et alimente la métadonnée XDSDocumentEntry.authorPerson. author/assignedauthor/representedorganization obligatoire : L entreprise de santé pour le compte de laquelle le document a été produit. Le nom et l identifiant de cette entreprise de santé (qui peut être un cabinet individuel) sont formatés conformément à l annexe I du guide d implémentation de l entête CDA dans le contexte français. Cet élément alimente la métadonnée XDSDocumentEntry.authorInstitution. Exemple avec un auteur personne : <author> <time value=" "/> <assignedauthor> <id root=" p" extension=" " assigningauthorityname="gip-cps"/> <code code="g15_10/r01_sm26" displayname="médecine générale" codesystem=" x.y.s"/> <assignedperson> <name> <given>charles</given> <family>dunant</family> <prefix>dr.</prefix> <suffix/> </name> </assignedperson> <representedorganization> <id root=" s" extension=" " assigningauthorityname="gip-cps"/> </representedorganization> </assignedauthor> </author> Source assignedauthor/representedorganization : Paramétrage du LPS. assignedauthor/code : Pour un auteur disposant d une CPS, spécialité tirée de la CPS et traduite par le LPS dans la nomenclature authorspecialty de l annexe Cadre_Interop_SIS_Annexes_Nomenclatures_Métadonnées.xls citée en référence. assignedauthor/assignedperson : Pour un auteur disposant d une CPS, identifiant et nom de la personne tirés de la carte. Dans les autres cas, informations fournies par le LPS. assignedauthor/assignedauthoringdevice : Identification du dispositif médical auteur. Classification : public 17 / 27

18 legalauthenticator Responsable du document Spécification Cet élément représente le responsable du document, à savoir la personne physique qui prend la responsabilité du contenu, et qui est aussi le signataire légal lorsque la signature électronique est mise en œuvre. Les spécifications du guide d implémentation de l entête CDA dans le contexte français s appliquent. Contraintes supplémentaires : Attribut nullflavor interdit sur les éléments suivants : o legalauthenticator o legalauthenticator/assignedentity/id o legalauthenticator/assignedentity/assignedperson o legalauthenticator/assignedentity/assignedperson/name Source Pour un responsable disposant d une CPS ou d une CPF, identifiant et nom de la personne sont tirés de la carte. Dans les autres cas, informations fournies par le LPS custodian Organisation émettrice Spécification Cet élément représente l organisation émettrice du document et qui assume l administration de ce document, notamment en le remplaçant par les nouvelles versions chaque fois que nécessaire. Les spécifications du guide d implémentation de l entête CDA dans le contexte français s appliquent. Exemple : <custodian> <assignedcustodian> <representedcustodianorganization> <id root=" s" extension=" " assigningauthorityname="gip-cps"/> <name>centre Hospitalier DUNANT</name> <telecom value="tel: " use="wp"/> <addr> <streetaddressline>25 rue Pasteur</streetAddressLine> <city>evry</city> <postalcode>91000</postalcode> <country>france</country> </addr> </representedcustodianorganization> </assignedcustodian> </custodian> Source Paramètre du LPS Classification : public 18 / 27

19 Eléments de l entête qualifiant l acte documenté documentationof/serviceevent Acte ou diagnostic documenté Spécification Cet élément représente un acte documenté ou cité par le document. Parmi les actes documentés, peuvent figurer une ou plusieurs pathologies identifiées codées en CIM-10 2 ou résultats de consultation codés en DRC 3. Les spécifications du guide d implémentation de l entête CDA dans le contexte français s appliquent. La présente spécification ajoute les contraintes suivantes : Cardinalités de documentationof : [1..*], attribut nullflavor interdit sur cet élément. Donc au moins un acte documenté. attribut nullflavor interdit sur les éléments documentationof/serviceevent et documentationof/serviceevent/code Nomenclatures à utiliser pour l élément documentationof/serviceevent/code qui code l acte : Nature d acte Nomenclature OID Médical CCAM X.Y.N.M Pathologie CIM Résultat de DRC?.?.?.?.?.?.?.? consultation Analyses de biologie LOINC (= chapitres NABM) X.Y.N.B Anatomopathologie LOINC ou partie 5 de NGAP X.Y.N.A Acte infirmier A définir?.?.?.?.?.?.?.? Acte paramédical A définir?.?.?.?.?.?.?.? Si plusieurs serviceevent sont présents, un et un seul d'entre eux devra contenir l'élément fils performer. C'est cet élément qui est l'acte principal documenté. L attribut nullflavor est interdit pour l élément performer. L élément fils serviceevent/effectivetime (représentant les bornes temporelles de l acte) est obligatoire sur l acte principal, et l attribut nullflavor est interdit. L élément fils serviceevent/effectivetime/low (représentant le début de l acte) est obligatoire sur l acte principal, et l attribut nullflavor est interdit Source Objets de gestion du LPS, sélectionnés par l auteur Cadre d exercice de l acte principal Spécification L élément documentationof/serviceevent/performer introduit le cadre d exercice de l acte principal documenté. Ce cadre d exercice est obligatoire et codé (nullflavor interdit) selon la nomenclature décrite dans l onglet practicesettingcode de l annexe Cadre_Interop_SIS_Nomenclatures_Métadonnées.xls citée en référence. Le code du cadre d exercice est placé dans l élément fils 2 CIM10 : Classification Internationale des Maladies publiée par l OMS 3 DRC : Dictionnaire des Résultats de Consultation, publié par la SFMG Classification : public 19 / 27

20 assignedentity/representedorganization/standardindustryclasscode Ce cadre d exercice est reporté dans la métadonnée XDSDocumentEntry.practiceSettingCode Source La nomenclature practicesettingcode comprend trois sous-tables représentées chacune par un OID différent, et correspondant à ces trois contextes : En établissement de soins : Un code représente la spécialité médicale d un service ou d une unité de soins d un établissement Hors établissement : Un code représente la profession de l auteur du document, complétée pour un médecin de sa spécialité ou de celle de ses spécialités applicables au contexte, et pour un pharmacien de sa sous-catégorie professionnelle (biologiste, pharmacien d officine, assistant ) Situations diverses : Document d expression personnelle du patient, service de soins palliatifs, SAMU/SMUR La sélection du code est faite par le LPS. En contexte hors établissement, lorsque le PS dispose d une carte, la sélection s opère à partir du code profession (table G15), ou future profession (G16), et le cas échéant de la spécialité du médecin ou de la catégorie de pharmacien, toutes ces données étant récupérées sur la carte infulfillmentof - Prescription Spécification Cet élément représente la prescription à l origine de l acte principal documenté. Les spécifications du guide d implémentation de l entête CDA dans le contexte français s appliquent Source Objet de gestion du LPS participant[@typecode=«ref»] - Prescripteur Spécification Cet élément introduit le prescripteur de l acte principal documenté. Le prescripteur lui-même est représenté par l élément fils : participant[@typecode=«ref»] /associatedentity/associatedperson Source Objet de gestion du LPS componentof/encompassingencounter Rencontre ou venue Spécification Définition : o Hors établissement : la rencontre entre le professionnel et le patient, dont est issue le document. o En établissement : la venue du patient dans l établissement. Obligatoire Attribut nullflavor interdit Cardinalités [1..1] Classification : public 20 / 27

21 Source Objet de gestion du LPS componentof/encompassingencounter/location/healthcarefacility/code Spécification Définition : Modalité d exercice ou secteur d activité Obligatoire Attribut nullflavor interdit Cardinalités [1..1] Selon la nomenclature décrite dans l onglet healthcarefacilitytypecode de l annexe Cadre_Interop_SIS_Nomenclatures_Métadonnées.xls citée en référence. Cette modalité d exercice est reportée dans la métadonnée XDSDocumentEntry.healthcareFacilityTypeCode Source Paramètre du LPS. La nomenclature utilisée est la table R02 «Secteurs d activité» du RPPS. 3.2 Corps non structuré (niveau 1) d un document CDA R Références Les spécifications de cette section s appuient sur : Le profil XDS-SD du cadre technique IT Infrastructure d IHE, téléchargeable sur : Cette section n est applicable qu aux documents CDA R2 dont le corps est non structuré ClinicalDocument/component/nonXMLBody L information médicale proprement dite est encapsulée en base 64 dans l élément fils nonxmlbody/text, qui est obligatoire, attribut nullflavor interdit, cardinalités [1..1]. Cet élément ClinicalDocument/component/nonXMLBody/text contient ces deux attributs obligatoirement présents et renseignés : mediatype - Valeurs possibles : «image/jpeg», «image/tiff», «text/rtf», «text/plain», «application/pdf» representation Fixé à la valeur «B64» De plus, si le contenu médical se trouve être dans une langue différente du français, annoncé par l entête du document (ClinicalDocument/languageCode*@code= fr-fr +), alors l élément ClinicalDocument/component/nonXMLBody/languageCode doit être présent et doit préciser la langue utilisée dans le contenu encapsulé Exemple tiré du volume 2 du cadre technique IT Infrastructure d IHE (le contenu médical en pdf, est dans la même langue que l entête du document) : Classification : public 21 / 27

22 Classification : public 22 / 27

23 4 Dispositions de Sécurité Ce chapitre présente les dispositions de sécurité locales à ce volet du cadre d Interopérabilité, permettant de couvrir les exigences de sécurité d un SIS mettant en œuvre ce volet. 4.1 Imputabilité et intégrité du document médical L imputabilité du contenu des documents est gérée par la signature électronique apposée par le Responsable du document, identifié dans l élément ClinicalDocument/LegalAuthenticator Documents élaborés par un PS ou un système sous la responsabilité d un PS Pour les documents réalisés sous la responsabilité d un PS (c.à.d. tout document en dehors d éventuels documents d expression personnelle du patient), l imputabilité est réalisée par une signature électronique de type XAdES-a utilisant un certificat de signature émis par l infrastructure de gestion des clés IGC-CPS. La signature porte sur l ensemble du contenu du document déposé (entête CDA et corps du document). La méthode de soumission de la signature lors de l échange ou du partage d un document médical, ainsi que le processus de vérification de cette signature, sont décrits dans le chapitre 4 du volet cité en référence : «Cadre d interopérabilité des SIS couche Service volet Partage de Documents Médicaux» Classification : public 23 / 27

24 5 Annexes 5.1 Annexe 1 : Exemple d une fiche de consultation patient <?xml version='1.0' encoding='utf-16'?> <?xml-stylesheet type="text/xsl" href="cda.xsl"?> <!-- ************************************************************************************** Système : ASIP Document : CDA avec corps non structuré pdf Conformité : - Cadre d Interopérabilité SIS couche Contenu - Volet Structuration Minimale de Documents Médicaux v CDA Release 2 (CDA.xsd) du standard ANSI/HL7 CDA, R /21/ Profil IHE XDS-SD - Guide d Implémentation de l entête des documents CDA (HL7 France) Date de création : 04/06/2009 ************************************************************************************** Notes: ID du patient : INS-A OID de l ASIP à remplacer ASAP par le bon. ************************************************************************************** --> <ClinicalDocument xmlns:xsi=" xsi:schemalocation="urn:hl7-org:v3 CDASchemas/cda/Schemas/CDA.xsd" xmlns="urn:hl7-org:v3"> <realmcode code="fr"/> <typeid root=" " extension="pocd_hd000040"/> <!-- Déclarations de Conformité (guide HL7 France, cadre ASIP, profil XDS-SD --> <templateid root=" " assigningauthorityname="hl7 France"/> <templateid root=" x.y.z" assigningauthorityname="cadre Interop ASIP"/> <templateid root=" " assigningauthorityname="ihe XDS-SD"/> <!-- Identifiant de cette occurrence (i.e. la version courante) du document --> <id root=" x.y.z.9" extension="15078" assigningauthorityname="asip"/> <!-- Type du document --> <code code=" " displayname="summarization of episode note" codesystem=" " codesystemname="loinc"/> <title>compte-rendu DE SCINTIGRAPHIE CARDIAQUE</title> <effectivetime value=" "/> <confidentialitycode code="n" displayname="normal" codesystem=" "/> <languagecode code="fr-fr"/> <!-- Le patient identifié par son INS-A --> <recordtarget> <patientrole> <id extension=" " root=" x.w.1"/> <addr> <streetaddressline>1, rue du Chat qui Pêche</streetAddressLine> <city>paris</city> <postalcode>75005</postalcode> <country>france</country> </addr> <telecom value="tel: "/> <patient> Classification : public 24 / 27

25 <name> <given>jeanne</given> <family qualifier="sp">duroc</family> <family qualifier="br">vaneau</family> </name> <administrativegendercode code="f" codesystem=" "/> <birthtime value=" "/> </patient> </patientrole> </recordtarget> <!-- Auteur: un PS libéral avec son identifiant RPPS (cf guide HL7 France)--> <author> <functioncode nullflavor="unk"/> <time value=" "/> <assignedauthor> <id root=" p" extension=" " assigningauthorityname="gip-cps"/> <!-- Spécialité de l auteur --> <code code="g15_10/r01_sm26" displayname="médecine générale" codesystem=" x.y.s"/> <addr nullflavor="nask"/> <telecom value="tel: "/> <assignedperson> <name> <given>charles</given> <family>dunant</family> <prefix>dr.</prefix> <suffix/> </name> </assignedperson> </assignedauthor> </author> <!-- Organisation de santé émettrice, assurant la maintenance du document = le PS --> <custodian> <assignedcustodian> <representedcustodianorganization> <id root=" p" extension=" " assigningauthorityname="gip-cps"/> <name>cabinet médical du Docteur Dunant</name> <telecom value="tel: " use="wp"/> <addr> <streetaddressline>25 rue Pasteur</streetAddressLine> <city>evry</city> <postalcode>91000</postalcode> <country>france</country> </addr> </representedcustodianorganization> </assignedcustodian> </custodian> <!-- Responsable signataire légal du contenu du document : Dans ce cas, le même PS --> <legalauthenticator> <time value=" "/> <signaturecode code="s"/> <assignedentity> <id root=" p" extension=" " assigningauthorityname="gip-cps"/> Classification : public 25 / 27

26 <addr nullflavor="nask"/> <telecom nullflavor="nask"/> <assignedperson> <name> <given>charles </given> <family>dunant</family> <prefix>dr.</prefix> </name> </assignedperson> </assignedentity> </legalauthenticator> <!-- Acte principal documenté --> <documentationof> <serviceevent> <effectivetime><low value=" "/></effectivetime> <performer> <functioncode code="pcp" codesystem=" "/> <assignedentity> <id root=" p" extension=" " assigningauthorityname="gip-cps"/> <addr nullflavor="nask"/> <telecom nullflavor="nask"/> <assignedperson> <name> <given>charles </given> <family>dunant</family> <prefix>dr.</prefix> </name> </assignedperson> <representedorganization> <id root=" p" extension=" " assigningauthorityname="gip-cps"/> <name>cabinet médical du Docteur Dunant</name> <telecom nullflavor="nask"/> <addr nullflavor="nask"/> <standardindustryclasscode> <code code=" G15_10/R01_SM26" displayname="médecine générale" codesystem=" x.y.s"> </code> </standardindustryclasscode> </representedorganization> </assignedentity> </performer> </serviceevent> </documentationof> <!-- Rencontre entre patient et PS durant laquelle a été produit le document --> <componentof> <encompassingencounter> <effectivetime><low value=" /></effectivetime> <location> <healthcarefacility> <code code="sa07" displayname="cabinet individuel" codesystem=" ?.?" codesystemname="r02"> </code> </healthcarefacility> </location> Classification : public 26 / 27

27 </encompassingencounter> </componentof> <!-- ******************************************************** Corps du document. ******************************************************** --> <component> <nonxmlbody> <text mediatype="application/pdf" representation="b64"> <!-- le contenu médical au format pdf/a, encodé en base 64 --> </text> </nonxmlbody> </component> </ClinicalDocument> Classification : public 27 / 27