Traiter un document CDA R2

Deux parcours produisent les mêmes métadonnées et pièces jointes :

• CDA XML fourni par l’EAI : créez une connexion CDA R2 HTTP ou dossier, puis sélectionnez-la dans Document CDA reçu.
• CDA encapsulé dans HL7 v2 : utilisez Message HL7 v2 reçu, reliez content à Extraire CDA de HL7 v2, puis sa sortie content à Analyser CDA R2.

L’extracteur HL7 émet content pour un document unique. Pour plusieurs documents, parcourez sa sortie documents avec Map (for-each) ; chaque élément conserve le contenu et les identifiants du message et de l’observation. Les observations ED XML prennent en charge TEXT/XML et APPLICATION/XML, en Base64 UTF-8 ou en texte A avec échappements HL7. Les observations non XML sont ignorées. Les documents référencés, les observations supprimées ou erronées, les enveloppes MIME multipart et les autres encodages ne sont pas pris en charge.

Choisir le traitement

Le port document expose l’identifiant CDA avec son autorité, le code du document, les identifiants de modèles, l’horodatage source, les identifiants patient et les sections narratives. Configurez un filtre sur le code ou le modèle attendu par votre interface pour sélectionner les prescriptions. Le titre seul ne constitue pas une classification clinique.

bodyKind distingue le corps structuré, le PDF, le texte, une référence ou un autre média. La sortie text contient le texte narratif extrait lorsqu’il est disponible. Ce texte ne résulte pas d’un OCR.

Pour un PDF incorporé dans nonXMLBody/text, le port pdf expose une pièce jointe typée : base64, mediaType, fileName, sizeBytes et sha256. Il est absent lorsqu’aucun PDF unique n’est extrait. La sortie attachments conserve la liste des pièces jointes prises en charge. Les fichiers référencés restent des adresses dans document.references ; aucun téléchargement automatique n’est effectué.

La signature %PDF- et le Base64 sont contrôlés, sans constituer une validation complète du PDF. La compression et les médias incorporés dans observationMedia d’un corps structuré ne sont pas extraits dans cette version. La limite de réception et d’extraction est de 5 Mio ; les couches Base64 réduisent la taille utile disponible pour le PDF.

Extraire une prescription avec Posos

Après avoir sélectionné les documents à traiter, éclatez le port pdf et reliez base64 et mediaType à Scanner une ordonnance. Le nœud envoie le PDF à l’API scan configurée par le plugin Posos et reçoit son résultat. Il ne crée aucune prescription dans Meridian et ne valide pas cliniquement les médicaments extraits. Prévoyez la revue des propositions avant une écriture clinique.

Ce traitement externe est indépendant de la réception CDA. Un simple parsing CDA n’appelle pas Posos. L’adaptateur OCR d’un autre fournisseur pourra consommer les mêmes octets et le même type MIME ; aucun autre service OCR n’est livré par ce parcours.

Validation et traçabilité

Le parseur contrôle la syntaxe XML, le namespace CDA, l’identité du document et le corps pris en charge. Il ne valide ni les XSD ni les Schematrons CI-SIS. Ces validations restent à configurer dans l’EAI ou dans un validateur dédié.

Les métadonnées, l’empreinte du XML et celle du PDF permettent de relier les étapes de réception, extraction et traitement. La déduplication d’une connexion CDA utilise le couple id.root et id.extension du document. Une nouvelle version doit porter l’identité prévue par le profil d’échange ; réutiliser une même identité avec un contenu différent est refusé.

La transcription par un service externe peut être répétée lors d’une reprise réseau ou d’exécution. L’API scan utilisée ne fournit pas de garantie d’idempotence vérifiée. Le résultat d’extraction reste une proposition à contrôler.

Références : transmission CDA en HL7 v2, ANS, corps non XML CDA, HL7.

Les nœuds HL7 v2 et CDA R2 appartiennent à @posos/hl7. Les nœuds SIPhII appartiennent à @posos/pn13. Le scan de prescription reste dans @posos/posos ; le plugin FHIR reste indépendant.

Kitchen sink HL7

zz-kitchen-sink-hl7.workflow.yaml contient les mappings patient et observations, l’analyse et la sérialisation HL7, une boucle sur les documents CDA, le filtre de prescription PDF et le scan Posos. L’événement synthétique content/clinical-demo/examples/hl7-cda.event.json permet de tester le parcours dans Simuler sans renseigner de patient. Son PDF minimal sert aux tests du parseur, pas à tester la qualité du scan.

La garde autoriser_scan a la condition false. La passer à true autorise l’appel Posos pour les PDF sélectionnés. Le filtre prescription_pdf utilise le code local de démonstration PRESCRIPTION dans urn:meridian:demo:document ; adaptez-le au contrat de votre EAI. La connexion HL7 sélectionnée reste en pause. Les propositions extraites ne sont pas écrites dans le dossier.

Voir aussi Connecter un EAI et Mapper un message HL7 ou PN13.