Schematron
Les modèles de documents médicaux spécifiées par l’ANS et publiés dans le CI-SIS s’appuient sur des normes et des standards internationaux. Les documents produits par les logiciels qui s’appuient sur ces modèles doivent être conformes aux spécifications publiés par l’ANS (référentiels du CI-SIS). Pour effectuer cette vérification, l’ANS a développé un outil de vérification de la conformité des documents CDA appelé « testContenuCDA ». Plusieurs niveaux de vérification sont réalisés par cet outil :
- Conformité au standard CDA R2 (schéma xml CDA_extended.xsd).
- Conformité aux spécifications internationales IHE de l’en-tête,
- Conformité aux spécifications françaises de l’en-tête (Volet Structuration minimale des documents de santé),
- Conformité aux spécifications internationales IHE du corps (sections, entrées et jeux de valeurs),
- Conformité aux spécifications françaises du corps (sections, entrées et jeux de valeurs IHE) (Volet Modèles de contenus CDA),
- Conformité aux spécifications françaises du corps (sections et entrées créées par l’ANS pour les volets français) (Volet Modèles de contenus CDA),
- Conformité aux spécifications d’un document (en-tête et corps) (Volet du document) Le présent document vise à décrire comment l’outil testContenuCDA réalise ces différentes vérifications.
Le principe de fonctionnement de schématron est le suivant :
-
Un document CDA est vérifié
- avec des schématrons génériques (communs à tous les documents CDA)
- Schématron IHE_XDS-SD.sch qui vérifie la conformité aux spécifications internationales IHE de l’en-tête
- Schématron CI-SIS_StructurationMinimale.sch qui vérifie la conformité aux spécifications françaises de l’en-tête,
- Schématron IHE.sch qui vérifie la conformité aux spécifications internationales IHE du corps (sections, entrées et jeux de valeurs),
- Schématron ModelesDeContenuCDA.sch qui vérifie la conformité aux spécifications françaises du corps (sections, entrées et jeux de valeurs IHE),
- Schématron ModelesASIP.sch qui vérifie la conformité aux spécifications françaises du corps (sections et entrées créées par l’ANS pour les volets français),
- avec un schématron CI-SIS_NomDuDocument.sch spécifique au modèle de document qui vérifie la conformité aux spécifications d’un document (en-tête et corps)
- avec des schématrons génériques (communs à tous les documents CDA)
-
Un rapport est produit à l’issue de cette vérification. Il contient des messages indiquant la conformité aux spécifications ou les erreurs détectées.
Sous Oxygen, l’appel à ces schematrons se fait dans chaque fichier CDA avant la balise .
Exemple :
Note
Lors de son exécution, un schématron (format.sch) est compilé (format .xsl) à l'aide de la feuille de style XSLT cda_asip.xsl.
La déclaration de la feuille de style se fait au niveau de l'exemple CDA :
S'il y a un bug (non-respect des règles crées au niveau des schematrons), la compilation échoue sinon elle se terminera avec succès.
Le schématron CI-SIS_NomDuDocument.sch spécifique au modèle d’un document fait lui-même appel à d’autres schématrons:
- Shématron de l’entête
- Shématrons des sections
- Shématrons des entrées
- Shématrons des jeux de valeurs spécifiques au volet
Le schematron spécifique au modèle du document CDA contient un ensemble d’asserts qui vont tester des parties bien définies dans le fichier CDA.
Plusieurs tests (asserts) peuvent exister dans un fichier schématron et la compilation échoue si un parmi ces tests échoue.
Le schématron est contenu dans un élément
- Un title (titre du schématron repris dans le rapport)
- Les namespaces utilisés.
- Les includes (chemins vers les sous-schématrons)
- La phase (ordonnancement des schématrons exécutés)
- Les patterns contenant les contrôles effectués directement par le schématron principal
La validation d'un document avec un schématron consiste à traiter séquentiellement chacun des blocs de contrôles (pattern et sous-schématrons) selon l’ordre définit dans la phase. Les différents contrôles sont réalisés et des messages sont ajoutés au rapport en fonction des résultats de ces tests.
Titre du schématron repris dans le rapport
Exemple :
<title>Rapport de conformité du document aux spécifications du modèle CNAM-HR</title>Exemple:
Il est obligatoire de déclarer les namespace des éléments utilisés dans le document CDA et de leur associer des préfixes. Les préfixes sont nécessaires pour nommer correctement les éléments dans les expressions XPath des règles.
Ce sont les chemins vers les sous-schématrons qui seront appelés dans le bloc .
Ces sous-schématrons sont :
- Soit des sous-schématrons communs à plusieurs documents :
Exemple:
- Soit des sous-schématrons spécifiques au modèle du document
Exemple:
Ordonnancement des schématrons exécutés
Exemple:
Théoriquement, un schématron peut contenir plusieurs phases, chacune identifiée par un attribut id. Lors de la validation d'un document par un schematron, il est alors possible de spécifier la phase à effectuer et seuls les pattern appartenant à cette phase sont alors exécutés. Un pattern peut appartenir à plusieurs phases.
En pratique, les schématrons de l’outil testContenuCDA ne contiennent qu’une phase contenant tous les pattern à exécuter.
Si aucune phase n'est spécifiée, la validation utilise tous les blocs du schématron. Chaque pattern est identifié par un élément < active >
Contrôles effectués directement par le schématron principal
Exemple:
Les contrôles sont regroupés en blocs (élément < pattern >).
Les contrôles qui s’appliquent au même contexte (même document ou même section ou même entrée) sont regroupés dans un élément < rule > dont l’attribut context précise le contexte (XPath).
Chaque contrôle est défini dans un élément < assert > ou un élément < report >. On peut utiliser les deux dans un même pattern.
L'ordre de ces différents éléments est sans importance.
Des variables locales peuvent être définies par des éléments < let >.
Elles permettent de mémoriser une valeur pour son utilisation dans un contrôle.
Chaque élément < let > a des attributs name et value pour spécifier le nom et la valeur de la variable.
L'attribut value doit contenir une expression XPath. Cette valeur ne peut plus ensuite être modifiée.
Les éléments < let > doivent être les premiers enfants de l'élément < rule >. La variable ainsi déclarée est disponible dans toute la règle.
Un contrôle défini dans un élément < assert > possède un attribut test dont la valeur est une expression XPath et un message d’erreur qui est utilisé pour construire le rapport.
Un test introduit par < assert > est réalisé de la façon suivante :
L'expression XPath contenue dans l'attribut test est évaluée en prenant le nœud sélectionné comme contexte et le résultat de l'évaluation est converti en une valeur booléenne.
- Si le résultat est « false », le message d’erreur est ajouté au rapport.
- Si le résultat est « true », rien n'est ajouté au rapport.
Dans l'exemple
si l'élément cda:component/cda:section/cda:templateId[@root='1.3.6.1.4.1.19376.1.4.1.2.16'] n’est pas présent, le message d'erreur « [CI-SIS_Modèle] Erreur de conformité au modèle : La section "Section Commentaire" (1.3.6.1.4.1.19376.1.4.1.2.16) pour la mention Usage et Responsabilités" doit être présente. » est ajouté au rapport.
Un contrôle est défini dans un élément < report > possède un attribut test dont la valeur est une expression XPath et un message d’erreur qui est utilisé pour construire le rapport.
Un test introduit par < report > est réalisé de la façon suivante :
L'expression XPath contenue dans l'attribut test est évaluée en prenant le nœud sélectionné comme contexte et le résultat de l'évaluation est converti en une valeur booléenne.
- Si le résultat est « true », le message d’erreur est ajouté au rapport.
- Si le résultat est « false », rien n'est ajouté au rapport.
Dans l'exemple
si l'élément cda:templateId[@root=[@root='1.2.250.1.213.1.1.1.40'] est présent, le message d'erreur « [CI-SIS_Modèle] Erreur de conformité au modèle : Le templateId "1.2.250.1.213.1.1.1.40" ne doit pas être présent. » est ajouté au rapport.
Le message d’erreur contenu dans les éléments < assert > et < report > peut aussi contenir des éléments < name > et < value-of > qui permettent d'ajouter du contenu dynamique dans le message d’erreur du rapport.
L'élément < name > sera remplacé par le nom de l'élément sur lequel est appliqué la règle. Il est particulièrement utile dans les communs où le nom du contexte n'est pas fixé.
L'élément < value-of > a un attribut select contenant une expression XPath.
Cette expression remplace l'élément < value-of > dans le rapport. Un exemple d'utilisation de cet élément est donné à la section suivante.
C’est le notamment le cas dans le schématron dansJeuDeValeurs.sch
- abstractFunctionCode.sch
- abstractHealthcareFacilityCode.sch
- abstractInformantRelatedEntityCode.sch
- abstractSpecialty.sch
- abstractStandardIndustryClassCode.sch
- dansJeuDeValeurs.sch
- IVL_TS.sch
- typeCodeDansJeuDeValeurs.sch
- abstractEncompassingEncounterCode
- abstractTypeCode
Les Abstract patterns sont des sous-schématrons qui regroupent des contrôles < pattern > susceptibles de s'appliquer à différents contextes, contrairement au < pattern > décrit dans le paragraphe 4.1.5 dont les contrôles s’appliquent au même contexte (même document ou même section ou même entrée).
Un Abstract pattern se différencie par ces attributs abstract="true" et id qui permet de l’appeler.
Exemple dansJeuDeValeurs.sch :
Ils sont appelés par d’autres schématrons qui spécifient alors le contexte lors de l’appel.
Ils ne peuvent pas être utilisés directement.
Un schématron fait appel à un Abstract pattern grâce à l'attribut is-a="nom-abstract" de l’élément < pattern >.
| Abstract pattern | Schématron appelant |
|---|---|
| abstractHealthcareFacilityCode.sch | Schématron effectuant le contrôle de l'élément healthcareFacility/code |
| abstractInformantRelatedEntityCode.sch | Schématron effectuant le contrôle de l'élément informant/relatedEntity/code |
| abstractStandardIndustryClassCode.sch | Schématron effectuant le contrôle de l'élément standardIndustryClassCode/code |
| dansJeuDeValeurs.sch | Schématron effectuant le contrôle d'appartenance d'une valeur codée obligatoire à un jeu de valeurs externe : code, displayName et codeSystem |
| L'élément n'est pas contrôlé s'il n'est pas de type CD ou CE. | |
| IVL_TS.sch | Vérification de la conformité au CI-SIS d'un élément de type IVL_TS ou TS du standard CDAr2. |
| typeCodeDansJeuDeValeurs.sch | Schématron effectuant le contrôle d'appartenance d'une valeur codée obligatoire à un jeu de valeurs externe : code, displayName et codeSystem |
| L'élément n'est pas contrôlé s'il n'est pas de type CD ou CE. | |
| Il est appelé par CI-SIS_StructurationMinimale.sch | |
| abstractTypeCode.sch | Schématron effectuant le contrôle d'appartenance d'une valeur codée obligatoire à TRE : code, displayName et codeSystem |
| L'élément n'est pas contrôlé s'il n'est pas de type CD ou CE. | |
| abstractSpecialty.sch | Schématron effectuant le contrôle de l'élement code (spécialité d'un PS) par rapport aux JDV définis dans CI-SIS_StructurationMinimale.sch |
| abstractFunctionCode.sch | Schématron effectuant le contrôle de l'élement functionCode par rapport aux JDV définis dans CI-SIS_StructurationMinimale.sch |
| abstractEncompassingEncounterCode.sch | Schématron effectuant le contrôle de l'élement code par rapport aux TREs définis dans CI-SIS_StructurationMinimale.sch |
Exemple d’appel de l’abstract pattern dansJeuDeValeurs.sch : Le schématron JDV_clinicalStatusCodes.sch fait appel à l’abstract pattern dansJeuDeValeurs.sch dans l’élément attribut is-a="dansJeuDeValeurs"
Exemple:
Le contrôle des codes utilisés dans les documents CDA et issus des JDV est effectué à l’aide de schématrons.
On distingue deux types de schématrons de jeux de valeurs :
- Les schématrons de JDV spécifiques à l’en-tête
- Les schématrons de JDV génériques
- Les schématrons de JDV spécifiques à un volet
L’implémentation de ces schématrons diffèrent avant tout par la manière dont ils sont appelés :
- Les schématrons spécifiques à l’en-tête sont appelés depuis le schématron CI-SIS_StructurationMinimale.sch (ce choix a été fait car le schématron CI-SIS_StructurationMinimale.sch est toujours exécuté pour tous les documents).
- Les schématrons génériques sont appelés depuis le schématron CI-SIS_StructurationMinimale.sch (ce choix a été fait car le schématron CI-SIS_StructurationMinimale.sch est toujours exécuté pour tous les documents).
- Les schématrons spécifiques à un volet sont appelés depuis le schématron du modèle du document concerné
Si le code à contrôler peut être localisé de manière non ambigüe (et non pas unique), il faut créer un schématron générique, car le paramètre xpath_elt du schématron doit uniquement être non ambigüe (et non pas unique).
Par contre, si le code à contrôler ne peut être localisé de manière non ambigüe, il faut créer des schématrons un JDV spécifique.
Voici 2 exemples qui permettent d’illustrer les 2 situations :
Exemple 1 : schématron de JDV spécifique
On veut contrôler l’élément value d’une entrée FR-Habitus-Mode-de-vie (1.3.6.1.4.1.19376.1.5.3.1.4.13.4) mais le JDV utilisé pour l’élément value dépend du contexte de l’entrée qui est spécifié par son code. Ainsi :
- pour une entrée FR-Habitus-Mode-de-vie de code "ORG-075" "Activité professionnelle", on doit vérifier que la value appartient au JDV_Activité-CISIS
- pour une entrée FR-Habitus-Mode-de-vie de code "57712-2" "Niveau d’étude de la mère", on doit vérifier que la value appartient au JDV_niveauEtude-CISIS
Si on ne précise pas le code dans le paramètre xpath_elt on reste dans l’ambiguïté (on ne sait pas quel JDV utiliser)
Exemple 2 : schématron de JDV générique Un veut contrôler l’élément value dans une entrée FR-StatutClinique (1.3.6.1.4.1.19376.1.5.3.1.4.1.1) quelle que soit la position de cette entrée dans le CDA.
L’élément value est non ambigüe ici puisque c’est toujours dans le même type d’entrée qui toujours le même code. On a donc créé un schématron JDV_clinicalStatusCodes.sch générique avec le paramètre xpath_elt suivant :
Ces schématrons de JDV spécifiques à l’en-tête sont dans le répertoire schematrons\include\jeuxDeValeurs\en-tête. Ils font eux-mêmes appel à des abstract patterns différents, selon qu’ils utilisent 1 seul JDV (abstract pattern "dansJeuDeValeurs") ou plusieurs JDV (abstract pattern spécifique).
| JDV spécifiques à l’en-tête | abstract pattern appelé |
|---|---|
| JDV_authenticatorSpecialty.sch | dansJeuDeValeurs.sch |
| JDV_authorFunctionCode.sch | abstractFunctionCode.sch |
| JDV_authorSpecialty.sch | abstractSpecialty.sch |
| JDV_componentOfResponsibleSpecialty.sch | dansJeuDeValeurs.sch |
| JDV_healthcareFacilityTypeCode.sch | abstractHealthcareFacilityCode.sch |
| JDV_informantRelatedEntityCode.sch | abstractInformantRelatedEntityCode |
| JDV_legalAuthenticatorSpecialty.sch | dansJeuDeValeurs.sch |
| JDV_participantAssociatedEntityCode.sch | abstractSpecialty.sch |
| JDV_participantFunctionCode.sch | abstractFunctionCode.sch |
| JDV_standardIndustryClassCode.sch | abstractStandardIndustryClassCode.sch |
| JDV_typeCode.sch | dansJeuDeValeurs.sch |
| JDV_confidentialityCode | dansJeuDeValeurs.sch |
| JDV_encompassingEncounterCode | abstractEncompassingEncounterCode.sch |
Appel de ces schématrons de JDV spécifiques à l’en-tête par le schématron CI-SIS_StructurationMinimale.sch
Ils sont appelés par le schématron CI-SIS_StructurationMinimale.sch (dans le répertoire schematrons\profils).
Exemple avec l’abstract pattern dansJeuDeValeurs.sch
Le schématron dansJeuDeValeurs.sch est dans le répertoire testContenuCDA_DeTravail\schematrons\abstract Il contrôle l'appartenance d'une valeur codée obligatoire à un jeu de valeurs (code, displayName et codeSystem). L'élément n'est pas contrôlé s'il n'est pas de type CD ou CE.
Si le code contrôlé n’existe pas dans le JDV générique, le message d’erreur suivant est ajouté dans le rapport :
[dansJeuDeValeurs] L'élément vue_elt [att_code:att_displayName:att_codeSystem] doit faire partie du jeu de valeurs ../../jeuxDeValeurs/path_jdv.
[dansJeuDeValeurs] L'élément entryRelationship/observation/value [DF-D0000X:Décédé:1.2.250.1.213.2.12] doit faire partie du jeu de valeurs ../../jeuxDeValeurs/JDV_HealthStatusCodes-CISIS.xml.
Un JDV générique peut être utilisé dans plusieurs CDA différents.
Ces schématrons de JDV génériques sont dans le répertoire \schematrons\include\jeuxDeValeurs
- JDV_actSubstanceAdministrationImmunizationCode.sch
- JDV_administrativeGenderCode.sch
- JDV_clinicalStatusCodes.sch
- JDV_healthStatusCodes.sch
- JDV_observationIntoleranceType.sch
- JDV_problemCodes.sch
- JDV_substanceAdministration_approachSiteCode.sch
- JDV_substanceAdministration_ImmunizationRouteCodes.sch
- JDV_substanceAdministration_RouteOfAdministration.sch
- JDV_vitalSignCode.sch
Les JDV eux-mêmes sont dans le répertoire testContenuCDA_DeTravail\jeuxDeValeurs
Les valeurs de ces JDV génériques utilisés dans les documents CDA sont systématiquement contrôlées car les schématrons de ces JDV sont appelés par le schématron CI-SIS_StructurationMinimale.sch qui est lui-même systématiquement exécuté pour chaque document contrôlé.
Appel dans le schématron CI-SIS_StructurationMinimale.sch (dans l’élément < phase >) :
Un schématron de JDV générique fait lui-même appel au schématron dansJeuDeValeurs.sch dans l’élément < pattern > attribut is-a="dansJeuDeValeurs"
Exemple :
Exception : le schématron JDV_administrativeGenderCode.sch ne fait pas appel à l’abstract pattern dansJeuDeValeurs.sch et les contrôles des codes sont fait directement dans le schématron.
Les paramètres du schématron d’un JDV générique :
- path_jdv : chemin relatif du fichier jeu de valeurs (ici jdv_healthStatusCodes a été valorisé à ../../jeuxDeValeurs/JDV_HealthStatusCodes-CISIS.xml dans le schématron CI-SIS_StructurationMinimale.sch)
- vue_elt : chemin de l'élément codé dans les CDAs affiché dans le message d’erreur
- xpath_elt : contexte xpath de l'élément codé (ici cda:observation[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.4.1.2']/cda:value) à contrôler dans le JDV
- nullFlavor : nullFlavor autorisé (1) ou non (0)
Un JDV spécifique est généralement utilisé dans un seul modèle de document CDA.
Ils sont dans le répertoire testContenuCDA_DeTravail\jeuxDeValeurs (le même que les JDV génériques).
Exemple : JDV_Activité-CISIS.xml
Ces schématrons de JDV spécifiques sont dans le répertoire \schematrons\include\jeuxDeValeurs\nom du modèle
Exemple :
- \schematrons\include\jeuxDeValeurs\CSE\JDV_Activite_CSE.sch
Les valeurs d’un JDV spécifique utilisés dans un document CDA sont contrôlées si le schématron de ce JDV est appelé par le schématron du modèle de document.
Exemple :
Appel dans le schématron CI-SIS_CSE_CS8_2021.01.sch (dans l’élément < phase >) :
Chacun de ces schématron de JDV spécifique fait lui-même appel au schématron dansJeuDeValeurs.sch dans l’élément < pattern > attribut
is-a="dansJeuDeValeurs"
Exemple :
Les paramètres du schématron d’un JDV spécifique :
- path_jdv : chemin relatif du fichier jeu de valeurs (ici jdv_Activite a été valorisé à ../jeuxDeValeurs/JDV_Activité-CISIS.xml dans le schématron du modèle CI-SIS_CSE_CS8.sch)
- vue_elt : chemin de l'élément codé dans les CDAs affiché dans le message d’erreur
- xpath_elt : contexte xpath de l'élément codé (ici cda:value) à contrôler dans le JDV
- nullFlavor : nullFlavor autorisé (1) ou non (0)
Attention :
Pour les shématrons de JDV spécifiques, il faut donc distinguer 3 cas :
1er cas : un JDV est utilisé dans un seul type d'entrée de même code (situation non ambigüe)
- C’est le cas présenté précédemment. Le schématron du JDV spécifique précise le type d’entrée et le code de cette entrée.
2ème cas : un JDV est utilisés dans un seul type d'entrée mais cette entrée peut avoir des codes différents (situation ambigüe)
- Dans ce cas, il faut créer un schématron du JDV spécifique par type d’entrée et code de cette entrée, pour éviter que le contrôle ne se déclenche sur les mêmes types d’entrées ayant un autre code et utilisant un autre JDV.
Attention Une même entrée de même code peut être utilisée à des niveaux différents, en particulier si on ajoute des sur-sections.
Dans l’exemple précédent :
L’entrée d’OID '1.3.6.1.4.1.19376.1.5.3.1.4.13.4' et de code 'ORG-075'est directement positionnée sous la section.
Si dans un document CDA, j’ajoute une sur-section, le chemin est plus complexe : ="/cda:ClinicalDocument/cda:component/cda:structuredBody/cda:component/cda:section/cda:component/cda:section/cda:entry/cda:observation[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.4.13.4' and cda:code/@code='ORG-075']/cda:value"
Du coup, le contrôle ne fonctionne plus
Il est possible de simplifier le paramètre xpath_elt
En remplaçant :
