FAQ sur le CDA R2

Référentiels d’intéropérabilité | 31 mars 2011
 

 

 

Q1 - Que signifie CDA R2 ?

 

Q2 - A quoi sert l’en-tête d’un document au format CDA R2 et quelles informations y trouve-t-on ?  

 

Q3 - Comment est organisé le corps d’un document au format CDA R2 ?

 

Q4 - Comment sont décrites les structures de données médicales dans un document au format CDA R2 ? 

 

Q5 - Comment et quand renseigner les codes acte ou diagnostic ? 

 
 

Q1 - Que signifie CDA R2 ?

 
CDA R2 ou Clinical Document Architecture Release 2 est un «dialecte(1)» XML développé par l’organisation Health Level Seven International (HL7), qui permet de véhiculer des données médicales. CDA.xsd est le schéma XML validant tout document XML conforme au standard CDA R2.
 
Seuls les documents médicaux au format CDA R2 sont acceptés dans le DMP.
 
Un document XML commence toujours par un élément racine, appelé ClinicalDocument pour le CDA. Un document XML conforme au standard CDA R2 est composé après la racine, d’un en-tête et d’un corps.
 
L’en-tête structuré contient les informations générales indispensables à l’identification du document ainsi que les données du contexte médical dans lequel il a été produit, par exemple l’identifiant du document, son titre, sa date de création, son auteur, le patient, sa prise en charge, les intervenants etc.
 
Le corps véhicule la partie médicale du document. Cette partie peut contenir un simple texte, une image ou un son ou être organisée en structures de données afin de permettre ou simplifier les traitements informatiques.
 
(1) Un dialecte XML est un langage informatique en syntaxe XML ou acceptant une syntaxe XML. La nature eXtensible d'XML est vérifiée par une très grande famille catégorisée sous ce terme
http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Dialecte_XML
 
En savoir plus, consulter le volet  « Structuration minimale de documents médicaux »
 
 

Q2 - A quoi sert l’en-tête d’un document au format CDA R2 et quelles informations y trouve-t-on ?

 
L’en-tête structuré contient les données générales indispensables à l’identification du document ainsi que les données du contexte médical dans lequel il a été produit, comme par exemple l’identifiant du document, son titre, sa date de création, son auteur, le patient, sa prise en charge, les intervenants etc.

Les données de l’en-tête du document sont véhiculées dans les éléments XML entre la racine ClinicalDocument et l’élément component (non inclus), voir Figure 1. Le nombre d’éléments XML de l’en-tête peut paraître important mais tous ne sont pas obligatoires.
 
En-tête CDA figure 1
 Figure 1: Entête CDA R2 de la racine ClinicalDocument à l’élément component (extrait du schéma XML CDA R2)
 
 
Données véhiculées dans l’en-tête CDA R2
 
Les données de l’en-tête sont véhiculées dans les éléments XML entre la racine ClinicalDocument et l’élément component (non inclus). Elles sont indispensables à l’identification du document et à la transmission du contexte médical dans lequel il a été produit. Le corps d’un document même constitué d’un simple texte ou d’une image doit être affiché avec les données de l’en-tête fournissant le contexte médical.

La Figure 2 présente la correspondance entre les éléments du schéma XML CDA R2 et les informations définies dans le volet « Structuration minimale de documents médicaux » du CI-SIS.
 
 
Figure 2: En-tête CDA R2 de ClinicalDocument à component (extrait du schéma XML CDA R2) et informations définies dans le CI-SIS
 
Légende : [0..1] : zéro à une occurrence ; [0..*] : zéro à plusieurs occurrences ; [1..1] : une et une seule occurrence ; [1..*] : une à plusieurs occurrences ; [2..*] : 2 à plusieurs occurrences.
 
En savoir plus, consulter le volet  « Structuration minimale de documents médicaux »
 
 

Q3 - Comment est organisé le corps d’un document au format CDA R2 ?

 
Le corps d’un document CDA R2 véhicule la partie médicale du document. Cette partie peut contenir un simple texte, une image ou un son ou être organisée en structures de données afin de permettre ou simplifier les traitements informatiques.
 
L’extrait du schéma XML CDA R2 (Figure 1), présente le corps du document à partir de l’élément component suivi de l’élément choice. Cet élément choice implique, pour la suite du document, le choix exclusif entre le groupe d’éléments XML contenu dans nonXMLBody ou le groupe d’éléments XML contenu dans structuredBody.
 
Le groupe d’éléments XML contenu dans nonXMLBody et en particulier l’élément text véhiculent des données médicales non structurées telles qu’un simple texte, une image ou un son.
 
Le groupe d’éléments XML contenu dans structuredBody véhicule les structures de données médicales.


Figure 1: Début du corps CDA R2 à partir de l’élément component (extrait du schéma XML CDA R2)
 
En savoir plus, consulter le volet  « Structuration minimale de documents médicaux »
 

Q4 - Comment sont décrites les structures de données médicales dans un document au format CDA R2 ?

 
Les structures de données médicales sont véhiculées dans le corps d’un document CDA R2 et plus précisément le groupe d’éléments XML contenu dans structuredBody.

Le schéma XML CDA R2 permet de regrouper ces informations médicales en une ou plusieurs sections dans l’élément section, voir Figure 1.


 
Figure 1: Partie du corps CDA R2 pour véhiculer les structures de données à partir de structuredBody (extrait du schéma XML CDA R2)


A l’intérieur d’un élément section, le schéma XML CDA R2 permet de véhiculer à la fois les données médicales textuelles dans l’élément text et les structures de données dans l’élément entry, voir Figure 2.


Figure 2: Partie du corps d’un CDA R2 pour les données structurées à partir de l’élément section (extrait du schéma XML CDA R2).
 
 
A l’intérieur de l' élément entry, les éléments XML allant de act à supply constituent la structure dans laquelle les données médicales sont organisées, voir Figure 3.

Figure 3: Partie du corps d’un CDA R2 pour les structures de données partir de l’élément entry (extrait du schéma XML CDA R2)
 
En savoir plus, consulter le volet  « Structuration minimale de documents médicaux »
 

Q5 - Comment et quand renseigner les codes acte ou diagnostic ?


Le document CDA R2 fait état d’un ou plusieurs actes. Chacun de ces actes est introduit par une occurrence de l’élément XML documentationOf (documentation d’acte). Cet élément optionnel et répétable dans le standard (schéma XML CDA R2) est requis par le CI-SIS qui impose la présence d'au moins un élément documentationOf (cardinalités [1..*]), voir Figure 1.


 
Figure 1: En-tête CDA R2 de ClinicalDocument à component (extrait du schéma XML CDA R2), informations définies dans le CI-SIS et zoom sur documentationOf

Légende : [0..1] : zéro à une occurrence ; [0..*] : zéro à plusieurs occurrences (correspond à [0..∞] sur le schéma XML) ; [1..1] : une et une seule occurrence ; [1..*] : une à plusieurs occurrences (correspond à [1..∞] sur le schéma XML); [2..*] : 2 à plusieurs occurrences.
 
Chaque occurrence de l’élément documentationOf contient l’élément documentationOf/serviceEvent (cardinalités [1..1]) unique et requis.
 
DocumentationOf/serviceEvent contient un certain nombre d’éléments et d’attributs pour véhiculer les informations relatives à l’acte documenté.
 
Parmi eux, l’élément DocumentationOf/serviceEvent/code contient un code d'acte ou de diagnostic, voir figure 2. Cet élément est optionnel dans le schéma XML CDA R2, le cadre d’interopérabilité précise ses conditions d’usage à « requis si connu ». Cela signifie que si le codage de l’acte ou du diagnostic est connu, il doit figurer dans cet élément.


 
Figure 2: En-tête CDA R2 de ClinicalDocument à component (extrait du schéma XML CDA R2), élément documentationOf/serviceEvent/code
 
Dans le cas où ce codage est absent, le cadre d'interopérabilité recommande d’utiliser l’attribut nullFlavor de l’élément DocumentationOf/serviceEvent/code, voir figure 3 et de le renseigner avec la raison de l’absence de ce codage.


 
Figure 3: Attribut nullFlavor de l’élement documentationOf/serviceEvent/code
 
La raison de l’absence de ce codage est exprimée sous la forme d’un code provenant d’une liste de valeurs. Le tableau 1 présente la liste des valeurs de l’attribut nullFlavor autorisé dans le CI-SIS.
 
Valeur de nullFalvor Libellé
UNK Inconnu
NASK Non demandé
ASKU Demandé mais non connu
NAV Temporairement indisponible
MSK  Masqué 
Tableau 1 : Valeurs de nullFlavor autorisées dans le CI-SIS

L’extrait ci-dessous illustre l’absence de codage d’acte ou de diagnostic parce que ceux-ci sont temporairement indisponibles :
<documentationOf>
<serviceEvent>
<code nullFlavor="NAV"/>
 
L’extrait ci-dessous présente le codage de l’acte dans un compte rendu d’examens biologiques :
 
<documentationOf>
<serviceEvent>
<code code="18719-5" displayName="Biochimie"  
                                  codeSystem="2.16.840.1.113883.6.1"
          codeSystemName="LOINC"/>
 
L’extrait ci-dessous présente le codage de l’acte dans un certificat de santé de l’enfant :
 
<documentationOf>
  <serviceEvent classCode="ACT">
         <code  code="P0-00120" displayName="Certificat Médical" 
                            codeSystem="1.2.250.1.213.2.11"
                            codeSystemName="SNOMED 3.5"/>
 
L’extrait ci-dessous présente le codage de l’acte dans un compte rendu d’anatomopathologie :
 
<documentationOf>
   <serviceEvent>
      <code code="ZZQP193" 
                   displayName="Examen anatomopathologique de pièce d'exérèse"
           codeSystem="1.2.250.1.213.2.5" 
                   codeSystemName="CCAM"/>
 
 
documentionOf/serviceEvent/code contient des informations alimentant la métadonnée evenCodeList dans le système d’indexation d’un entrepôt de données comme le DMP.
 
Pour en savoir plus, consulter le volet « Structuration minimale de documents médicaux » et l' annexe « Liens entre en-tête CDA et métadonnées » dans la rubrique Cadre d’Interopérabilité des Systèmes d’Information de Santé (CI-SIS) du présent site.