Ehscda:CDA-CH-LREP (specification)

Sprachen:	Deutsch • français

eHealth Suisse

Austauschformat eLaborbefund

CDA-CH-LREP

Pre-Publication Review
(Aktualisierte Version vom 12.08.2019)

Copyright © 2017-2019: "eHealth Suisse" - Koordinationsorgan Bund-Kantone

Schwarzenburgstrasse 157

3097 Liebefeld

Versionierung
Version	Datum	Status	Änderungen gegenüber Vorversion	Download
1.0	19.07.2016	Ersetzt mit V1.1		kein download verfügbar
1.1	13.04.2017	Ersetzt mit V1.2	Reviewrückmeldungen eingepflegt ART-DECOR Harmonisierungsarbeiten erledigt	kein download verfügbar
1.2	09.08.2017	Ersetzt mit V1.3	Formelle Korrekturen	kein download verfügbar
1.3.0	19.04.2018	Ersetzt mit V1.3.1		kein download verfügbar
1.3.1	07.05.2018	Pre-Publication Review	Formelle Anpassungen in ART-DECOR Korrektur PDF URL	Dokument
1.3.2	14.07.2018	Pre-Publication Review	Korrekturen auf Art-Decor	Dokument
1.3.3	12.08.2019	Draft	Korrekturen auf Art-Decor: Organizer enthält component statt entryRelationship Laboratory Results Validator auf 2 Templates aufgeteilt (header und body) Section id Kardinalitäten korrigiert (0..1) Laboratory Report Data Processing Entry für Pathogen spezialisiert	[coming soon Dokument]

Identifikation dieses Dokuments
Abkürzung: CDA-CH-LREP
OID: 2.16.756.5.30.1.1.1.1.3.9.1.1

Impressum

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

© eHealth Suisse, Kompetenz- und Koordinationsstelle von Bund und Kantonen

Lizenz: Dieses Ergebnis gehört eHealth Suisse (Kompetenz- und Koordinationsstelle von Bund und Kantonen). Das Schlussergebnis wird unter der Creative Commons Lizenz vom Typ „Namensnennung - Weitergabe unter gleichen Bedingungen 4.0 Lizenz“ über geeignete Informationskanäle veröffentlicht. Lizenztext: http://creativecommons.org/licenses/by-sa/4.0

Weitere Informationen und Bezugsquelle: www.e-health-suisse.ch

Autoren Tony Schaller (medshare GmbH und IHE Suisse), Thomas Weilenmann (Viollier), Walter Fierz (lmz dr risch), Oliver Egger und Marcel Hanselmann (beide HL7 Benutzergruppe Schweiz)

Zweck und Positionierung

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Das vorliegende Dokument definiert den technischen und semantischen Standard für den elektronischen und strukturierten Austausch der beschriebenen Informationen rund um das elektronische Patientendossier (EPD).

Gleichstellung

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Im Interesse einer besseren Lesbarkeit wird auf die konsequente gemeinsame Nennung der männlichen und weiblichen Form verzichtet. Wo nicht anders angegeben, sind immer beide Geschlechter gemeint.

Elektronische Version

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Die Inhalte dieses Dokuments können auch auf dem Wiki abgerufen werden: http://e-health-wiki.ch/index.php/Ehscda:CDA-CH-LREP_(specification).

Die normative Spezifikation inklusive den Schematron-Regeln ist auf Art-Decor unter folgendem Link publiziert: http://ehealthsuisse.art-decor.org/index.php?prefix=cdachlrep-

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Zusammenfassung

Das vorliegende Austauschformat definiert einen allgemeinen Laborbefund (eLaborbefund). Damit können Laboratorien in der Schweiz für deren Kunden - wie Ärzte oder Spitäler - elektronische Laborbefunde herstellen, die sowohl von Menschen gelesen, wie auch von Softwaresystemen elektronisch verarbeitet werden können. Für den Leser eines solchen, elektronischen Laborbefundes sind keine Investitionen notwendig, da sich das elektronische Dokument in jedem Webbrowser für den Menschen lesbar darstellen lässt. Will der Empfänger die strukturierten Inhalte des Laborbefunds in seiner Software weiterverarbeiten, muss ihm der Softwarehersteller eine entsprechende Funktion anbieten. Die Informationen im eLaborbefund sind vollstrukturiert. Damit lässt sich von einem Softwaremodul jede Information gezielt auslesen und weiterverarbeiten (z.B. einzelne Laborresultate inkl. deren LOINC Codes, Referenzbereiche und Interpretationscodes, demografische Patientenstammdaten, Verweise auf externe Laboratorien, die gegebenenfalls Teilmengen von Resultaten beigesteuert haben, etc.).

Die vorliegende Spezifikation definiert den technischen und semantischen Standard für den elektronischen und strukturierten Austausch der eLaborbefunde . Sie baut auf den bestehenden Austauschformaten im Laborbereich auf, richtet sich an denselben internationalen Normen und Standards aus und erlaubt es Sender und Empfänger, sich ohne vorherige Absprache zu verstehen.

Als Basistechnologie wurde das IHE Inhaltsprofil "Sharing Laboratory Reports (XD-LAB)" gewählt (siehe Volume 3 (PaLM TF-3): Content Modules des IHE Pathology and Laboratory Medicine Technical Frameworks (Revision 7.0 - July 5, 2016)), das auf die HL7 Clinical Document Architecture (CDA), Release 2, 2005 referenziert.

Damit ist die internationale Interoperabilität der eLaborbefunde gewährleistet. IHE XD-LAB ist ebenfalls Grundlage für weitere Austauschformate wie Meldepflichtige Laborbefunde (CDA-CH-LRPH), Laborbefunde für den Transplantationsprozess (CDA-CH-LRTP) und Laborbefunde für Qualitätskontrolle (CDA-CH-LRQC).

Bei allen Labor-Austauschformaten werden die gleichen technischen Strukturen angewendet, was einen hohen Wiederverwendungsgrad von Softwarebestandteilen ermöglicht. Eine Software, die in der Lage ist, den eLaborbefund gemäss vorliegender Spezifikation zu erstellen oder zu verarbeiten, kann mit minimalem Aufwand so erweitert werden, dass die anderen oben genannten Austauschformate ebenfalls unterstützt werden.

Kapitel #Anwendungsfälle zeigt auf, in welchen Bereichen der eLaborbefund eingesetzt werden kann.

Kapitel #Spezifikation (normativ) enthält die normative Spezifikation. Sie dokumentiert konkrete Umsetzungshinweise, Feldinhalte und Ergänzungen rund um den eLaborbefund, IHE XD-LAB und HL7 CDA.

Kapitel #Validierung, Technologien und Tools enthält Links auf Beispieldokumente und nennt das gültige Validierungskonzept für alle Austauschformate. Dieses führt zu einer hohen Konformität der eLaborbefunde. Die Schematronregeln, welche die Geschäftsregeln im vorliegenden Austauschformat abbilden, erlauben eine automatisierte Validierung der entstehenden CDA Dokumente. Damit wird erreicht, dass für alle Beteiligten die gleichen Validierungsregeln gelten und diese sowohl bei Sender und Empfänger identisch angewendet werden.

eHealth Suisse empfiehlt allen betroffenen Akteuren im Gesundheitswesen, sich mit dieser Spezifikation und den sich daraus ergebenden neuen Möglichkeiten zur Verbesserung von Prozessen auseinander zu setzen und die Laborinformationssysteme (LIS) entsprechend zu erweitern.

Einleitung

Ausgangslage und Motivation

Laborbefunde von Laboratorien an deren Kunden wie Ärzte oder Spitäler sollen im Rahmen des elektronischen Patientendossiers einerseits ein einheitliches Layout erhalten, damit sich die Behandelnden rasch und unabhängig vom erstellenden Labor über die Ergebnisse von Laboruntersuchungen informieren können. Andererseits sollen die Laborbefunde den individuellen Bedürfnissen der ausstellenden Laboratorien gestaltet werden können (Corporate Identity). Beide Anforderungen lassen sich mittels XML Stylesheets umsetzen. Die Erstellung von solchen Stylesheets richtet sich nach den Vorgaben von W3C (siehe https://www.w3.org/Style/XSL/) und wird in diesem Dokument nicht weiter behandelt.

Im Weiteren sollen die strukturierten Daten durch die empfangende Software bei Bedarf elektronisch weiterverarbeitet werden können. Die elektronische Weiterverarbeitung erlaubt dem Empfänger eine automatische Zuordnung der Laborwerte zum richtigen Patienten und ermöglicht darüber hinaus den automatisierten Anstoss von Prozessen wie z.B. Alarmierung bei pathologischen Resultaten oder die Darstellung der Verläufe von Laborwerten in Kurvenform.

Die Vorarbeiten aus den bereits verfügbaren Austauschformaten im Bereich Labor (Meldepflichtige Laborbefunde (CDA-CH-LRPH), Laborbefunde für den Transplantationsprozess (CDA-CH-LRTP) und Laborbefunde für Qualitätskontrolle (CDA-CH-LRQC)) werden im vorliegenden Austauschformat wiederverwendet. Dadurch ergibt sich bei den Softwareherstellern eine hohe Wiederverwendbarkeit von bereits getätigten Investitionen.

Der im Steuerungsausschuss von „eHealth Suisse“ verabschiedete Umsetzungsvorschlag sieht ein einheitliches Austauschformat für die hier genannten Informationen vor. Damit kann der Austausch dieser Informationen zwischen allen beteiligten Institutionen und Personen unterstützt werden.
Dokumente, welche nach diesem Austauschformat erstellt werden, sind ausserdem geeignet für die Ablage im EPD.

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Status und Zweck des Dokuments

Das vorliegende Dokument beschreibt den Inhalt von „CDA-CH-LREP (specification)“ und definiert damit ein einheitliches Austauschformat für den Informationsaustausch im Gesundheitswesen Schweiz. Es enthält den Text wie er vom Projektteam erarbeitet wurde und beinhaltet die normative Spezifikation basierend auf HL7 CDA.

Angesprochene Leserschaft

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Das vorliegende Austauschformat richtet sich an Behandelnde, Hersteller und Lieferanten von Software und Systemen sowie alle weiteren Gesundheitsfachpersonen, welche sich mit vorliegendem Thema befassen.

ICT-Fachleute finden im Kapitel #Spezifikation (normativ) die normative Spezifikation und im Kapitel #Validierung, Technologien und Tools Verweise auf Dokumente zu Technologien und Tools zur Validierung sowie weitere Hilfsunterlagen (sogenannte „Supporting Documents“). Eine Beschreibung der Anwendungsfälle findet sich in Kapitel #Anwendungsfälle.

Ziele und Abgrenzungen

Interoperabilität als Voraussetzung

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Eine sinnvolle Umsetzung elektronischer Meldungen bedingt Interoperabilität der beteiligten Systeme. Die "HL7 EHR Interoperability Work Group" hat Interoperabilität unterteilt in folgende Stufen :

• Technische Interoperabilität
• Semantische Interoperabilität
• Prozessinteroperabilität

Technisch interoperabel sind Systeme, die miteinander Daten austauschen können. Semantische Interoperabilität bedeutet, dass die Information vom empfangenen System richtig interpretiert werden kann. Die Prozessinteroperabilität befasst sich mit der Integration der Systeme in den Arbeitsablauf.

Das vorliegende Austauschformat beinhaltet die Spezifikationen für die semantische Interoperabilität von Systemen im Zusammenhang mit "CDA-CH-LREP (specification)".

Die technische Interoperabilität ist eine Voraussetzung dafür, dass die semantische Interoperabilität zum Tragen kommt. Sie beinhaltet unter anderem den Transportmechanismus von Meldungen. Dieses Austauschformat macht zum Transportmechanismus keine Vorgaben.

Kapitel #Anwendungsfälle zeigt relevante Anwendungsfälle und gibt Hinweise für eine geeignete Implementation. Den Hinweisen liegen Überlegungen zur Prozessinteroperabilität zugrunde. Vorgaben und eine vertiefte Behandlung der Prozessinteroperabilität sind jedoch nicht Gegenstand dieses Dokuments.

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Ziele

Automatisierung

• Automatisierung der Datenbereitstellung seitens der Datenlieferanten und damit Eliminierung von Fehlern, die heute durch manuelle Bearbeitung auftreten können.
• Automatisierung der Datenverarbeitung seitens der Behandelnden und damit Reduktion des Aufwandes, welcher die bisher praktizierten Verfahren und Abläufe verursachen.

Harmonisierung, Interoperabilität und Investitionsschutz

• Sicherstellung der Wiederverwendbarkeit gleicher Elemente in den verschiedenen Austauschformaten und damit Reduktion des Entwicklungsaufwandes für neue Schnittstellen
• Abbau des Aufwandes für Betrieb und Unterhalt der heute heterogenen Schnittstellen bei den Laboratorien und bei den Behandelnden.

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Abgrenzungen

Das vorliegende Austauschformat ist eine zusätzliche Form der Datenanlieferung der Laboratorien an die Behandelnden. Sämtliche bisherigen Datenlieferungen bleiben weiterhin möglich. Folgende Themen werden vom vorliegenden Austauschformat nicht behandelt:

• Eigentliche Übertragung der Laborbefunde (Kommunikation)
• Definition von Prozessen, welche beim Empfänger durch die elektronische Verarbeitung der strukturierten Daten möglich werden

Grundlagen und Basistechnologien

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Die Anwendungsfälle rund um "CDA-CH-LREP (specification)" lassen sich nach den Empfehlungen der Strategie eHealth Schweiz umsetzen. Die elektronischen Informationen dazu sollen im elektronischen Patientendossier zugänglich sein und den Beteiligten eine elektronische Verarbeitung ermöglichen.
Das vorliegende Austauschformat basiert auf Integrationsprofilen der IHE und der HL7 Clinical Document Architecture (CDA). Siehe auch Kapitel #Bezug zu anderen Standards und Leitfäden.

Verantwortlichkeiten

Die Herausgeberin genehmigt ausdrücklich die Anwendung des vorliegenden Leitfadens ohne Lizenz- und Nutzungsgebühren zum Zweck der Übermittlung von „CDA-CH-LREP (specification)“ und weist darauf hin, dass dies mit dem Einverständnis aller an der Erarbeitung des Austauschformats beteiligten Mitwirkenden erfolgt. Die Nutzung des Leitfadens erfolgt in der Verantwortung der Anwender.

Die Codierung von einzelnen Informationen in diesem Austauschformat basiert auf definierten Value-Sets und Vokabularen, welche die akzeptierten Codes definieren.

Für die Publikation von Value-Sets ist das Koordinationsorgan Bund-Kantone „eHealth Suisse“ verantwortlich.

Formelle Grundlagen

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Bezug zu anderen Standards und Leitfäden

Das vorliegende Austauschformat baut auf folgenden Grundlagen auf:

Bezug zu anderen Standards und Leitfäden – Referenzpyramide

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

IHE Integrationsprofile

IHE (Integrating the Healthcare Enterprise) ist eine internationale Initiative zur Verbesserung des elektronischen Datenaustausches zwischen IT-Systemen im Gesundheitswesen. IHE erarbeitet sogenannte Integrationsprofile, welche definieren, wie bestehende Standards (z. B. HL7, DICOM) in Arbeitsabläufen anzuwenden sind, damit Informationssysteme unterschiedlicher Hersteller interoperabel und ohne Verlust von Informationen miteinander kommunizieren können. IHE wurde im Jahr 1998 in den USA ins Leben gerufen; Europa und Asien folgten kurz darauf. 2010 wurde IHE Suisse gegründet.

Für dieses Austauschformat steht das IHE Inhaltsprofil „Sharing Laboratory Reports (XD-LAB)“ im Zentrum (siehe Volume 3 (PaLM TF-3): Content Modules des IHE Pathology and Laboratory Medicine Technical Frameworks (Revision 8.0 - June 21, 2017)). Dokumente, welche basierend auf IHE Inhaltsprofilen (Content Profiles) erstellt werden, können in einem Ordner (Folder) in der IHE Cross-enterprise document sharing Architektur (XDS) abgelegt werden. Dieses IHE Integrationsprofil ist die Basis für das verteilte elektronische Patientendossier (EPD) in der Schweiz.

Das, im vorliegenden Austauschformat referenzierte IHE Inhaltsprofil XD-LAB referenziert auf HL7 Clinical Document Architecture (CDA), Release 2, 2005 als Basisstandard für Dokumenteninhalte.

HL7 V3

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

HL7 steht für "Health Level Seven" und bezeichnet einen internationalen Standard zum elektronischen Austausch von Daten im Gesundheitswesen. Die Zahl „7“ bezieht sich auf die siebte Schicht des OSI Modells und drückt damit aus, dass HL7 primär die Kommunikation auf der applikatorischen Ebene standardisiert. HL7 hat seinen Ursprung 1987 in den USA. Mittlerweile ist es eine kommerzielle Organisation (HL7.org), die HL7 heute in den Versionen 2.x und 3.0 anbietet. Gleichzeitig ist HL7.org die Dachorganisation aller HL7 Benutzer und koordiniert deren Aktivitäten auch auf internationaler Ebene. HL7-Affiliates existieren inzwischen in über 30 Ländern, darunter auch in der Schweiz.

Das vorliegende Austauschformat baut auf HL7 Version 3 auf. Version 3 ist XML-basiert und fusst auf einem umfangreichen Objektmodell, dem Reference Information Model (RIM). Dieses Modell bildet die Grundlage für Standards wie die Clinical Document Architecture (CDA) und damit auch für dieses Austauschformat.

HL7 Clinical Document Architecture (CDA)

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Die HL7 Clinical Document Architecture ist ein offizieller ANSI und HL7 Standard mit gültiger Fassung R2 aus dem Jahr 2005. Die HL7 CDA R2 ist eine von mehr als 30 verschiedenen Domänen der HL7 V3 Standards-Familie, welche objektorientiert entworfen worden und im sogenannten HL7 Reference Information Model (RIM) dokumentiert ist.

Gesetzgebung Elektronisches Patientendossier (EPDG)

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Mit dem elektronischen Patientendossier sollen die Qualität der medizinischen Behandlung gestärkt, die Behandlungsprozesse verbessert, die Patientensicherheit erhöht und die Effizienz des Gesundheitssystems gesteigert sowie die Gesundheitskompetenz der Patientinnen und Patienten gefördert werden.
Das Bundesgesetz über das elektronische Patientendossier regelt die Rahmenbedingungen für die Einführung und Verbreitung des elektronischen Patientendossiers und ist seit 15. April 2017 in Kraft.
Für die vorliegende Spezifikation sind demnach die gesetzlichen Grundlagen zum EPDG relevant. Gesetz, Verordnungen, Erläuterungen und weitere Dokumente können beim BAG unter diesem Link bezogen werden.
Darüber sind auch OID Konzept, Empfehlungen und weitere Dokumente von "eHealth Suisse" relevant.

Übersetzungen

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Diese Version des Dokuments ist in Deutsch und Französisch verfügbar.

Anwendungsfälle

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Die hier skizzierten Anwendungsfälle (UC = Use Case) beziehen sich auf Beispiele, wie sie heute bei den verschiedenen Akteuren im Schweizer Gesundheitswesen vorkommen, die mit dem vorliegenden Thema zu tun haben. Einige Anwendungsfälle werden erst möglich, wenn durch Import/Export-Mechanismen alle relevanten Informationen interoperabel fliessen können.

Ziel ist einerseits die Bereitstellung von Informationen zum Gesundheitszustand des Patienten in einer menschlich lesbaren Form für die am Behandlungspfad beteiligten Personen. Andererseits sollen durch die elektronische Verarbeitung der Informationen Prozesse in den ICT-Systemen optimiert werden können.
Nachfolgend beschriebene Anwendungsfälle verdeutlichen diese Zusammenhänge im vorliegenden Kontext.

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Einführung

Das Whitepaper «Elektronische Laboraufträge und -befunde (HL7 V3/IHE)» der HL7 Benutzergruppe Schweiz verfolgt eine Zielsetzung mit ganzheitlichem Ansatz. Das vorliegende Austauschformat soll die Zielsetzungen, welche im Whitepaper dokumentiert sind, im Bereich der Laborbefunde erfüllen. Es soll ermöglichen, dass Laboratorien damit ihre Laborbefunde an ihre Kunden (wie z.B. Arztpraxen oder Spitäler) übermitteln können. Auch Spital- oder Praxislabors sollen damit ihre eigenen Befunde in diesem Format erstellen, verwalten und verteilen können.

Storyboard

Das Austauschformat soll einen „Proof of Concept“ durch die Umsetzung klinischer Szenarien und Testfälle erbringen. Die nachfolgenden Fallbeispiele zeigen heute praktizierte Umsetzungen und wurden als Vorbereitung im Whitepaper dokumentiert und an den heute aktuellen Stand der Kenntnisse erweitert und angepasst.

Fallbeispiele

Fallbeispiel 1: Verdacht auf tiefe Venenthrombose

Ein Patient erscheint am 09.03.2016 in der Arztpraxis bei Dr. med. Mustermann. Er identifiziert sich mündlich über seine Stammdaten als Hans Guggindieluft, 01.01.1981. Er berichtet über unklare Beinschmerzen im linken Unterschenkel sowie gleichzeitig aufgetretene atemabhängige Schmerzen und Husten. Der Arzt führt die Anamnese und körperliche Untersuchung durch und verordnet folgende Laborparameter:

• Blutbild inkl. Differenzierung
• CRP
• D-Dimer

Der Arzt führt selber das Blutbild und die CRP-Bestimmung mittels Point of care Diagnostik durch, die D-Dimer-Diagnostik wird als Quantitative Diagnostik in einem externen Einsendelabor verordnet. Zur Gewinnung der Probe wird eine Blutentnahme im Liegen durchgeführt (1 EDTA-Röhrchen, 1 Citrat-Röhrchen). Der Auftrag wird an das externe Labor übermittelt und die Probe wird mittels telefonisch geordertem Kurier in das externe Versandlabor geschickt. Die Resultate der internen Point of Care-Diagnostik (Blutbild und CRP) werden im Laborblatt des Patienten in der Arztpraxis-Software eingetragen (händisch oder über lokal installierte elektronische Schnittstellen). Es erfolgt daher eine Verordnung des Arztes an den Patienten zur Selbstverabreichung eines thrombosehemmenden Mittels.

Die Resultate des Einsendelabors treffen am gleichen Abend elektronisch beim Hausarzt ein und werden ebenfalls im Laborblatt des Patienten eingetragen. Durch den Einsatz des vorliegenden Austauschformats kann dieser Prozess vollautomatisch erfolgen. Nach telefonischer Rückfrage des Arztes beim Einsendelabor auf Grund eines grenzwertigen D-Dimer-Befundes erfolgt die Auskunft, dass mittels D-Dimer in dieser Situation eine tiefe Venenthrombose nicht ausgeschlossen werden kann und es erfolgt daher eine telefonische Wiedereinbestellung des Patienten am nächsten Tag zur Durchführung einer Sonographie der Beine.

Dazu passendes CDA Beispiel, welches dieser Spezifikation entspricht: CDA-CH-LREP-1_VerdachtAufTiefeVenenthrombose.xml

Fallbeispiel 2: Verdacht auf Keuchhusten

Zu diesem Fallbeispiel befinden sich im Whitepaper, Anhang 8.7 konkrete Beispieldokumente. Die « Abbildung 2 » im Whitepaper zeigt das zu diesem Fallbeispiel gehörende Use Case Diagramm.

Eine Mutter sucht mit ihrem 6-jährigen Sohn den Hausarzt auf, weil das Kind seit zwei Wochen zunehmend hustet, mit krampfartigen Hustenanfällen, und Fieber hat. Die MPA der Arztpraxis misst das Fieber, macht bereits eine Fingerkuppen-Blutentnahme beim Sohn, bestimmt das CRP und fertigt einen Blutausstrich an. Der Arzt vermutet einen viralen Infekt, möchte aber Keuchhusten ausschliessen, obwohl das Kind dagegen geimpft ist. Da er wegen eines Notfalles unter Zeitdruck ist, möchte er den dazu nötigen Rachenabstrich nicht selbst durchführen, sondern bittet die Mutter, das Kind ins nahegelegene Labor zu begleiten, um den Abstrich in Ruhe anfertigen zu lassen.

Er erstellt einen Laborauftrag zur Durchführung einer Pertussis-PCR im Rachenabstrich des Kindes und gibt den Auftrag der Mutter mit. Die Mutter selbst ist nicht sicher, ob sie selbst gegen Keuchhusten geimpft ist. Demzufolge nimmt der Hausarzt die Pertussis-Impfung bei ihr gleich vor und empfiehlt, dasselbe beim Kindsvater und bei den Grosseltern durchzuführen. Die MPA hat inzwischen den Blutausstrich des Sohnes im Mikroskop angeschaut und findet ausgesprochen viele reaktive Lymphozyten, die ihr verdächtig erscheinen. Sie ist unsicher und fragt den Arzt, welcher den Auftrag gibt, die Blutausstriche des Kindes der Mutter mitzugeben und ebenfalls im Labor genauer untersuchen zu lassen.

Die Mutter findet sich mit ihrem Sohn im Labor ein, wo auf Grund des Untersuchungsauftrages des Arztes vorerst die Identität des Sohnes festgestellt wird. Anschliessend wird im Blutentnahmeraum des Labors beim Kind ein Rachenabstrich sowie eine Venenpunktion cubital rechts durchgeführt und zusammen mit den mitgebrachten Blutausstrichen und dem Untersuchungsauftrag des Arztes ins Labor weitergegeben.

Dazu passendes CDA Beispiel, welches dieser Spezifikation entspricht: CDA-CH-LREP-2_VerdachtAufKeuchhusten.xml

Fallbeispiel 3: Gynäkologische Jahreskontrolle

Die MPA der Gynäkologie Praxis Dr. Pap bereitet die Konsultationen des nächsten Tages vor. Da die Praxis nur ein minimales eigenes Labor betreibt, werden gewisse Patientinnen vor dem Besuchstermin ins nahe gelegene Ambulatorium des Labors Pipette geschickt, so auch die junge Patientin Frau Rubella. Die MPA verordnet in ihrer Praxis-Software für die Patientin Rubella die mit dem Labor vereinbarten Standard-Analysen für die gynäkologische Jahreskontrolle. Dazu gehört auch die Blutentnahme für die Serothek für allfällige Nachverordnungen.
Das Labor übermittelt die Resultate spätestens 90 Minuten nach der Blutentnahme in die Praxis. Dr. Pap verordnet während der Konsultation folgende Aufträge:

• Gynäkologische Zytologie
  Pap-Abstrich - falls indiziert soll auch der Nachweis und die Typisierung von HPV (Humane Papillomaviren) durchgeführt werden.
  Entnahmematerial gemäss Angaben des Labors.
  Die zytologische Untersuchung wird im Labor Pipette durchgeführt. Die allfällige Typisierung führt das Labor Pipette nicht selber durch.
• Urin-Teilstatus (Combur9 Test) durch die MPA in der Praxis durchgeführt: folgende Parameter werden untersucht: ph, Leukozyten, Erythrozyten, Nitrit, Protein, Glucose, Ketone, Urobilinogen, Bilirubin (halbquantitative Untersuchungen, Resultate werden wahrscheinlich von Hand ins Praxis-Laborsystem eingetragen)
• Urin-Bakteriologie
  Entnahmematerial gemäss Angaben des Labors
  Allgemeine Bakt, inkl. Sprosspilze ans Labor Pipette
  Die Übermittlung des Auftrags wird durch die MPA ausgelöst (Entnahmezeitpunkt)
• Nachverordnung "Screening vor Schwangerschaft"
  Alle Untersuchungen können aus den vorgängig im Ambulatorium entnommenen Materialien (Serum, EDTA-Blut) durchgeführt werden
• Mammographie
  Auftrag für das Röntgeninstitut Dr. Curie.

Dazu passendes CDA Beispiel, welches dieser Spezifikation entspricht: CDA-CH-LREP-3_GynaekologischeJahreskontrolle.xml

Fallbeispiel 4: Verdacht auf eine Sepsis

Die Patientin Klebsiella Keller ist schon seit längerer Zeit im Regionalspital Zugersee. In der vergangenen Nacht hat sich ihr Allgemeinzustand massiv verschlechtert. Da ein Verdacht auf eine Sepsis besteht, wird der Patientin am Morgen Blut für eine Blutkultur entnommen. 30 Minuten später wird nochmals eine aerobe und eine anaerobe Blutkultur angelegt, sowie eine Urinprobe gewonnen.

Alle fünf Proben werden im externen Labor Pipette weiter bearbeitet. Dort werden in allen Materialien Keime nachgewiesen und dann mittels Massenspektrometrie identifiziert. In den vier Blutkulturflaschen konnten die Erreger „Klebsiella pneumoniae“ und „Escherichia coli“ nachgewiesen werden, in einer aeroben Flasche noch zusätzlich das Bakterium „Streptococcus mitis“. Der in der Urinprobe identifizierte Keim ist normalerweise nicht pathogen.

Von allen drei im Blut nachgewiesenen Erreger wird ein Antibiogramm erstellt. Dabei zeigt sich, dass die beiden Wirkstoffe “Amoxicillin+Clavulansäure“ und „Ceftriaxon“ bei allen drei Keimen wirksam sind. Der Mikrobiologe informiert den behandelnden Arzt regelmässig über die verschiedenen Teilresultate.

Dazu passendes CDA Beispiel, welches dieser Spezifikation entspricht: CDA-CH-LREP-4_VerdachtAufSepsis.xml

Fallbeispiel 5: Sammelauftrag „Biologisches Monitoring SUVA“

Betriebe, welche mit gesundheitsgefährdenden Stoffen arbeiten und in denen Arbeitnehmende speziellen Risiken ausgesetzt sind, werden von der SUVA der arbeitsmedizinischen Vorsorge unterstellt. Eine Kontrollmöglichkeit ist die Biologische Überwachung. Diese beurteilt die Exposition von Arbeitnehmenden gegenüber chemischen Arbeitsstoffen durch die Bestimmung der Arbeitsstoffe oder von Metaboliten (Umwandlungsprodukten) im biologischen Material (z.B. Urin).
Die Arbeitsmedizinische Vorsorge (AMV) der SUVA sendet dem Labor monatlich eine Liste mit folgenden Informationen pro Betrieb (Sammelauftrag):

• Betrieb (Name, Adresse, Betriebs-Nummer)
• Anzahl Arbeitnehmende für das Biologische Monitoring
• durchzuführende Untersuchungen (z.B. Arsen, Blei, Quecksilber, Mandelsäure)

Die Betriebe erhalten von der AMV eine Liste inkl. Etiketten mit den betroffenen Arbeitnehmenden. Das Labor bedruckt die Auftragsformulare mit der Betriebsnummer und sendet den Betrieben die notwendige Anzahl Urinbecher und Auftragsformulare zu. Im Betrieb werden Auftragsformulare und Urinbecher mit den von der AMV gelieferten Etiketten versehen und an die Arbeitnehmenden abgegeben. Die Proben inkl. Auftragsformular werden vom Betrieb ans Labor gesendet.

Dazu passendes CDA Beispiel, welches dieser Spezifikation entspricht: CDA-CH-LREP-5_BiologischesMonitoringSuva.xml

Use Cases

UC 1: Befund im herkömmlichen Sinne

Die herkömmlichen Aufträge und deren Befunde wurden in den vorhergehenden Kapiteln erläutert. Es handelt sich dabei um einen Use Case, in welchem der Auftraggeber (z.B. Arzt) beim Labor verschiedene Untersuchungen bestellt. Dabei sendet der Auftraggeber Probenmaterial an das Labor und das Labor sendet Befunde an den Auftraggeber zurück. Diese Befunde können auch gestaffelt als Teilresultate zu verschiedenen Zeitpunkten erfolgen.

Umsetzung der daraus entstehenden Anforderungen in der normativen Spezifikation:

• Angaben zum Probenmaterial: Specimen Collection und Participant (Body, specimen collection)
• Angaben zum Probeneingang beim Labor: Specimen Received
• Umgang mit Teilresultaten: Laboratory Report Data Processing Entry - statusCode:
  • completed: alle erwarteten Ergebnisse sind vorhanden und endgültig.
  • active: die Untersuchungen laufen noch. Einige Resultate sind noch ausstehend.
  • aborted: die Untersuchungen mussten abgebrochen werden. Einige Resultate können vorhanden sein.
• Endgültiger Befund: Ein Befund ist endgültig, wenn er kein Laboratory Report Data Processing Entry mit statusCode='active' enthält.

UC 2: Auftrag mit externer Phlebotomie Station

Dieser Use Case unterscheidet sich vom vorhergehenden Use Case dadurch, dass das Probenmaterial nicht beim Auftraggeber sondern bei einer externen Phlebotomie Station bereitgestellt wird (z.B. Blutentnahme).

Umsetzung der daraus entstehenden Anforderungen in der normativen Spezifikation:

• Blutentnahme in Phlebotomie Station: Specimen Collection - performer: Damit kann angegeben werden, wer die Probe entnommen hat.

UC 3: Anfordern von Befundkopien

Wenn zu einer bestimmten Fragestellung eines bestimmten Patienten bereits Untersuchungen vorliegen, kommt es nicht selten vor, dass die Resultate / Befunde auch von nachbehandelnden Ärzten angefordert werden. Dazu ist das Einverständnis des Patienten notwendig. Der Auftraggeber erstellt in diesem Fall keinen herkömmlichen Auftrag und es wird auch kein Probenmaterial an das Labor gesendet. Der Auftraggeber bestellt lediglich die Befunde zu einem früheren Auftrag.
Beispiel: Der Hausarzt bestellt Befunde, zu einem Auftrag, der vom Spital in Auftrag gegeben worden ist, weil der Spitalaustrittsbericht noch nicht vorliegt und der Patient bereits beim Hausarzt in Nachbehandlung ist. Dieser Use Case löst im Labor einen administrativen Prozess aus.

Umsetzung der daraus entstehenden Anforderungen in der normativen Spezifikation:

• Befundkopie: Wird im eLaborbefund nicht gekennzeichnet. Der nachbehandelnde Arzt erhält das gleiche, unveränderte Dokument so wie es ursprünglich ausgeliefert worden ist.
• Einverständnis des Patienten: Das Einholen des Einverständnisses ist nicht Bestandteil des eLaborbefunds. Wenn gewünscht, kann das Einverständnis aber im eLaborbefund im Header mit dem Element Authorization angegeben werden.
• Kein herkömmlicher/früherer Auftrag: Das Auftragsverfahren ist nicht Bestandteil des eLaborbefunds. Im Laborbefund wird mit <CDA-CH-ORDR> auf den Original-Auftrag verwiesen.
• Kein Probenmaterial: Specimen Collection / Specimen Received sind optional und werden hier weggelassen.

UC 4: Anfordern von Teilresultaten

Oft werden zu erteilten Laboraufträgen Teilresultate bestellt. Dies kann im Voraus erfolgen, wenn der Auftraggeber bereits weiss, dass er einzelne Teile des Auftrags früher als Befund erhalten möchte als andere Teile des Auftrags. Es kann aber auch geschehen, dass die Erfüllung des Auftrags länger dauert als angenommen und dass in einem solchen Fall der Auftraggeber diejenigen Befunde erhalten möchte, zu denen der Befund resp. das Resultat bereits vorliegt. Dieser Use Case löst im Labor einen administrativen Prozess aus. So muss allenfalls eine noch nicht erfolgte Validierung im Labor per sofort initialisiert werden.

Umsetzung der daraus entstehenden Anforderungen in der normativen Spezifikation:

• siehe UC1.

UC 5: Befunde mit Grafiken

Einzelne Laborresultate werden als Grafik zurückgeliefert (z.B. Reiberdiagramm oder Elektrophorese). Der elektronische Befund muss also auch die Integration oder Referenzierung von Multimediadateien unterstützen.

Umsetzung der daraus entstehenden Anforderungen in der normativen Spezifikation:

• Multimediadateien: Multimedia Embedded Content
• Externe Dokumente: External Document

UC 6: Befunde mit weiteren Daten zum Gesundheitszustand des Patienten

Wenn dies für die Interpretation der, im Laborbefund genannten Laborresultate von besonderem Interesse ist, müssen weitere Daten zum Gesundheitszustand des Patienten im Laborbefund aufgenommen werden können. Insbesondere Körpertemperatur, Grösse, Gewicht und Gestationsalter.

Umsetzung der daraus entstehenden Anforderungen in der normativen Spezifikation:

• Körpertemperatur, Grösse, Gewicht: Können als Vitalzeichen in der Coded Vital Signs Section dokumentiert werden.
• Gestationsalter: Kann in der Coded Results Section dokumentiert werden.
• Hinweis: Diese Kapitel werden von anderen Spezifikationen (CDA-CH und CDA-CH-VACD) gepflegt und im vorliegenden Austauschformat nicht weiter spezifiziert.

UC 7: Befunde mit zusätzlichen Angaben zur Probe

Bei gewissen Untersuchungen reichen Auftrag und Probe alleine nicht aus, um das Laborresultat zu bestimmen. In solchen Fällen müssen Beobachtungen zur Probenentnahme an das Labor geliefert werden. Als Beispiel sei hier der 24-Stunden-Urintest erwähnt. Dazu muss dem Labor die, während einer bestimmten Zeitdauer gesammelte Urinmenge bekannt sein. Das Labor dokumentiert die, bei Testdurchführung bekannten Werte im Laborbefund, um dem Empfänger eine korrekte Interpretation des Laborresultats ermöglichen zu können.

Umsetzung der daraus entstehenden Anforderungen in der normativen Spezifikation:

• Bestimmte Zeitdauer: Specimen Collection - effectiveTime (als Intervall mit low und high) angeben oder mit einer entryRelationship eine entsprechende observation (13362-9 - Collection duration of Urine) angeben.
• Gesammelte Urinmenge: Specimen Collection - mit einer entryRelationship eine entsprechende observation (19153-6 - Volume in Urine collected for unspecified duration) angeben.

UC 8: Befunde mit genauen Angaben zu Test-Kit und Analyzer

In gewissen Situationen ist es wichtig, dass der Empfänger weiss, mit welchem Test-Kit von welchem Hersteller und auf welchem Analyzer die Untersuchung durchgeführt wurde. Dies ist insbesondere dann von Bedeutung, wenn Verläufe von Laborresultaten über eine Zeitperiode analysiert werden müssen. Die einzelnen Laborresultate sind nur direkt vergleichbar, wenn diese mit dem gleichen Test-Kit auf dem gleichen Analyzer durchgeführt wurden. Bei unterschiedlichen Test-Kits/Analyzern entstehen Abweichungen.

Umsetzung der daraus entstehenden Anforderungen in der normativen Spezifikation:

• Test-Kit: Participant (Body, laboratory device) - scopingEntity: Nummer, Art und Hersteller des Test-Kits
• Analyzer: Participant (Body, laboratory device) - playingDevice: Name und Model des Analyzers

UC 9: Sammelaufträge

Bei Sammelaufträgen (z.B. #Fallbeispiel 5: Sammelauftrag „Biologisches Monitoring SUVA“) werden Arbeitslisten abgearbeitet, welche über eine längere Zeit (Tage/Wochen) andauern. In der Regel werden bestimmte Untersuchungen zu mehreren Patienten angefordert. Beispiele dazu sind:

• Suva Arbeitsmedizin: Bestellung von Laboruntersuchungen zu mehreren Patienten
• Lebensmittelindustrie: Untersuchung zu Mitarbeiterhygiene (z.B. Salmonellen-Kontaminierung)
• Polizeiliche Untersuchungen

Dabei muss insbesondere die Problematik der Mitarbeiterfluktuationen gelöst werden:

• Personen, für welche Tests angefordert sind arbeiten nicht mehr beim Auftraggeber
• Es sind Proben zu Personen eingetroffen, die nicht im Auftrag sind (neue Mitarbeiter)

Umsetzung der daraus entstehenden Anforderungen in der normativen Spezifikation:

• Untersuchungen zu mehreren Patienten: ein eLaborbefund enthält Informationen zum Gesundheitszustand genau eines Patienten. Bei Sammelaufträgen wird für jeden Patienten ein eigener eLaborbefund erstellt. Alle eLaborbefund verweisen aber mit <CDA-CH-ORDR> auf den gleichen (Sammel-)Auftrag.
• Problematik der Mitarbeiterfluktuationen: Ist nicht Bestandteil des eLaborbefunds. Für Personen, die nicht mehr beim Auftraggeber arbeiten wird kein eLaborbefund erstellt. Für neue Mitarbeiter werden eLaborbefunde erstellt.

Empfehlungen

Dieses Kapitel enthält Empfehlungen, welche im Sinne einer Harmonisierung hilfreich sind. Die nachfolgend genannten Empfehlungen können auch als "Best practices" betrachtet werden. Die nachfolgend genannten Empfehlungen sind nicht normativ und deren Umsetzung somit freiwillig.

Umgang mit Metadaten

Wie bei den Empfehlungen zum Umgang mit Metadaten in CDA-CH V2 (2017) genannt, ist im Zusammenhang mit dem elektronischen Patientendossier ist ein harmonisierter Umgang mit Metadaten zu den Dokumenten, welche mit CDA-CH V2 erstellt werden wichtig.

Empfehlung zum Umgang mit Metadaten

Wenn ein CDA Dokument, welches der vorliegenden Spezifikation entspricht, in das elektronische Patientendossier eingestellt wird, sollen die Metadaten gemäss dieser Beschreibung zugeordnet werden: Metadaten gemäss EPDV

Ausserdem enthält die vorliegende Spezifikation eine konkret Vorgabe für das Metadaten-Attribut typeCode (siehe dazu Template 'Document Code'). Das Metadaten-Attribut classCode lässt sich davon gemäss der Tabelle "2.11 Typ des Dokumentes (2.16.756.5.30.1.127.3.10.1.27)" in Anhang 3 der Verordnung des EDI über das elektronische Patientendossier (Metadaten) ableiten (Spalte 4, 'Gehört zu Dokumentenklasse aus 2.3').

Umgang mit Original Darstellung und PDF Dokumenten

CDA-CH V2 (2017) empfiehlt für bestimmte Anwendungsfälle, die Originaldarstellung so mitzugeben wie sie der rechtsgültige Unterzeichner zum Zeitpunkt seiner Signatur gesehen hat und empfiehlt dazu die Einbettung der Originaldarstellung als PDF in das CDA-Dokument.

Empfehlung zur Integration der Originaldarstellung

• Bei endgültigen Laborbefunden soll die Originaldarstellung gemäss den Empfehlungen von CDA-CH V2 (2017) in Form eines PDF/A-1a Dokuments in das CDA-Dokument integriert werden.
  • Dazu soll das Template Original Representation Section verwendet werden.
• Bei vorläufigen Laborbefunden oder Teilresultaten ist die Einbettung der Originaldarstellung erlaubt aber nicht erforderlich.

Umgang mit referenzierten oder angehängten Dokumenten

Ein Laborbefund kann sich auf extern Dokumente beziehen. Diese können dem Laborbefund entweder beigelegt oder als referenziertes Dokument angegeben werden. Damit der Umgang mit referenzierten oder angehängten Dokumenten harmonisiert werden kann, folgen hier entsprechende Empfehlungen.

Empfehlung für referenzierte oder angehängte Dokumente

Die Angabe externer Dokumente erfolgt entweder mittels Einbettung als PDF (dazu gelten die gleichen Vorgaben wie in Kapitel Umgang mit Original Darstellung und PDF Dokumenten beschrieben) oder mittels Angabe einer Referenz auf ein externes Dokument.

Die Integration kann auf verschiedenen Stufen im CDA Body mit den folgenden Templates erfolgen:

1. Verweis (reference Element) auf ein externes Dokument: Template ' External document'
2. Eingebettetes PDF (observationMedia Element): Template ' Multimedia Embedded Content'

Umgang mit menschlich lesbarem Text

Der HL7 CDA Standard schreibt vor, dass ein CDA Dokument immer menschlich lesbaren Text enthalten muss (CDA Body Level 1). Die vorliegende Spezifikation legt die Darstellung der strukturierten und maschinenauswertbaren Informationen auf Kapitel-Ebene (CDA Body Level 2) und auf Ebene der Einzelresultate (CDA Body Level 3) fest. Weder HL7 CDA, noch CDA-CH schreiben vor, wie der Zusammenhang zwischen menschlich lesbarer und maschinenauswertbarer Information hergestellt werden soll. Bei Laborbefunden handelt es sich um Dokumente, welche aus den grösstenteils strukturiert vorliegenden Informationen im Laborinformationssystem (LIS) automatisch erstellt werden. Basierend auf dieser Ausgangslage werden nachfolgende Empfehlungen abgegeben.

Empfehlung zum Umgang mit menschlich lesbarem Text

• Da ein Laborbefund ein Dokument ist, das den CI/CD Vorgaben jedes produzierenden Labors entsprechen soll, werden keine Vorschriften gemacht, wie die menschlich lesbare Form auszusehen hat.
• Um den Empfängern die Orientierung in Laborbefunden verschiedener Laboratorien zu vereinfachen macht es Sinn, sich an folgende Best-Pracices zu halten:
  • Nutzung des Stylesheets der HL7 Benutzergruppe Schweiz mit Anpassung von Farben und Logo mittels CSS. Siehe dazu Validierung, Technologien und Tools
  • Die Tabelle mit den einzelnen Laborresultaten im menschlich lesbaren Text soll automatisch generiert werden. Siehe dazu die Umsetzung im Open Source Projekt eHealth Connector. Die CDA Beispiele sind mit dem eHealth Connector produziert worden.
• Weitere hilfreiche Vorgaben können dem ELGA Implementierungsleitfaden (z.B. Laborbefund Version 2.06.2, Kapitel "4.3. Spezifikation der Befunddarstellung Level 2" entnommen werden.

Umgang mit besonderen Laborbefunden

Empfehlung für Kulturelle Erregernachweise

Der Spezifikation ELGA Implementierungsleitfaden, Laborbefund Version 2.06.2, Kapitel "4.4.8. Kultureller Erregernachweis" folgend, sollen kulturelle Erregernachweise in einem Laboratory Isolate Organizer - Pathogen Detection deklariert werden. LOINC-codierte Methoden für den kulturellen Erregernachweis sind mit der Methode „culture“ gekennzeichnet. Diese können auf http://search.loinc.org mit Eingabe des entsprechenden Suchbegriffes method:culture gefunden werden.

@code	@displayName	code/originalText
6463-4	Bacteria identified in Unspecified specimen by Culture	Kultur
634-6	Bacteria identified in Unspecified specimen by Aerobe culture	Aerobe Kultur
635-3	Bacteria identified in Unspecified specimen by Anaerobe culture	Anaerobe Kultur
580-1	Fungus identified in Unspecified specimen by Culture	Pilzkultur

Beispiele für Codes für Erregernachweis-Methodik entnommen aus LOINC

Empfehlung für Antibiogramm

Der Spezifikation ELGA Implementierungsleitfaden, Laborbefund Version 2.06.2, Kapitel "4.4.9. Antibiogramm (Laboratory Isolate Organizer)" folgend:

• Antibiogramme sollen als Laboratory Isolate Organizer - Pathogen Detection zusammengefasst werden. Das Isolat ist das Probenmaterial (specimen), an dem die Empfindlichkeitstests durchgeführt werden.
• Sind mehrere Erreger im Befund vorhanden, wird für jeden ein Isolate Organizer angelegt. Für jeden Erreger wird eine eindeutige Nummer (ID) angegeben.
• Die Empfindlichkeitstests werden dabei als Laboratory Battery Organizer - Antibiogram angegeben. Innerhalb dieses Organizers werden die einzelnen Antibiotika-Resistenztests zum Isolat wie "normale" Laboranalysen gehandhabt.
• Die einzelnen Empfindlichkeitsprüfungen werden mittels LOINC codiert.
  Bsiepiele:
  • 18993-6 steht für eine Tetracyclin-Empfindlichkeitsprüfung (Tetracycline [Susceptibility])
  • 18861-5 steht für eine Amoxicillin-Empfindlichkeitsprüfung (Amoxicillin [Susceptibility])
• Die Angabe der Interpretation erfolgt über die entsprechenden Codes aus dem HL7 Vokabular ObservationInterpretation, Rubrik ObservationInterpretationSusceptibility. Siehe dazu auch folgende Tabelle:

@code	@displayName	Bedeutung
S	susceptible	sensibel
R	resistant	resistent
I	intermediate	intermediär
SDD	Susceptible-dose dependent	sensibel (dosierungsabhängig)

Codierung der Resistenzen

Empfehlung für Minimale Hemmkonzentration

Der Spezifikation ELGA Implementierungsleitfaden, Laborbefund Version 2.06.2, Kapitel "4.4.10. Minimale Hemmkonzentration" folgend, sollen die erforderlichen Daten für die minimale Hemmkonzentration in CDA Body Level 2 und CDA Body Level 3 in unterschiedlicher Struktur erfolgen:

• In CDA Body Level 2 sollen die Werte in eine eigene Tabelle geschrieben werden (siehe auch Empfehlung zum Umgang mit menschlich lesbarem Text.
• Die Codierung in CDA Body Level 3 soll gemeinsam mit der Codierung eines Antibiogramms (siehe Template Laboratory Battery Organizer - Antibiogram) erfolgen. Der Absolutwert soll dabei innerhalb von organizer/component/observation/value als "Physical Quantity" codiert werden. Das interpretationCode-Element soll die, für das Antibiogramm notwendige Information über die Suszeptibilität enthalten (siehe auch Empfehlung für Antibiogramm).

Empfehlung für Molekulare Erregernachweise

Der Spezifikation ELGA Implementierungsleitfaden, Laborbefund Version 2.06.2, Kapitel "4.4.11. Testergebnisse/Molekularer Erregernachweis" folgend, soll die Codierung analog der Codierung von Laborergebnissen ( Laboratory Observation) erfolgen. Eine Gruppierung kann mit Hilfe von Befundgruppen ( Laboratory Battery Organizer) erfolgen.

Empfehlung für wichtige Erreger

Der Spezifikation ELGA Implementierungsleitfaden, Laborbefund Version 2.06.2, Kapitel "4.4.12. Significant Pathogens (Notifiable Conditions)" folgend, soll die Codierung wichtiger Erreger (z.B. meldepflichtige Krankheiten) mittels den Templates Notification Organizer - Significant Pathogens und Notifiable Condition - Significant Pathogen erfolgen.

Umgang mit Resultaten aus Unteraufträgen von externen Laboratorien

Auch wenn ein Labor gewisse Untersuchungen an Dritte auslagert (z.B. Spezial-Laboratorien), sollen diese Resultate im Laborbefund dargestellt werden. Unter welchen Umständen solche Aufträge an Dritte (auch Subcontracting genannt) vergeben werden (dürfen) ist nicht Gegenstand der vorliegenden Spezifikation, da hier der Befund und nicht der Auftrag spezifiziert wird. Aufgrund der Tatsache, dass in der Praxis das Subcontracting oft genutzt wird, folgen hier entsprechende Empfehlungen, wie die extern ermittelten Ergebnisse in den Laborbefund an den Endkunden integriert werden.

Empfehlung für Resultate aus Unteraufträgen von externen Laboratorien

Extern ermittelte Ergebnisse können entweder strukturiert oder unstrukturiert in den Laborbefund integriert werden. Es ist auch eine Kombination beider Arten möglich.

Strukturierte Integration von extern ermittelten Laborresultaten

Dazu sollen die gleichen Templates genutzt werden, wie wenn die Resultate im eigenen Labor ermittelt worden wären. Um die Herkunft aus einem externen Labor darzustellen werden folgende Präzisierungen in den entsprechenden Templates angegeben:

1. Das externe Labor kann im CDA Header unter documentationOf/serviceEvent/performer deklariert werden.
2. Das externe Labor soll bei jeder Befundgruppe resp. bei jedem einzelnen Labor-Resultat, zu welchem es ein Resultat geliefert hat, als participant Element mit dem Template ' Participant (Body, responsible party)' deklariert werden.
3. Sowohl im CDA Header, wie auch im CDA Body wird das externe Labor mit dem Template ' Laboratory Performer (Body)' deklariert.

Unabhängig davon, ob das Resultat extern oder intern ermittelt worden ist:

1. Die Person, welche den Test durchgeführt hat wird im performer Element deklariert (Template ' Laboratory Performer (Body)').
2. Die Person, welche den Test klinisch validiert hat wird als weitere participant Element mit dem Template ' Laboratory Results Validator (Body)' deklariert.

Unstrukturierte Integration von extern ermittelten Laborresultaten

Der externe Befund kann seinem Inhalt entsprechend auf folgenden Ebenen referenziert werden:

1. Auf Stufe Befundgruppe (z.B. wenn alle oder mindestens mehrere Labor-Resultate der entsprechenden Befundgruppe betroffen sind).
2. Auf Stufe Labor-Resultat (z.B. wenn nur dieses Labor-Resultat betroffen ist).

Die unstrukturierte Integration des externen Befunds erfolgt gemäss den Empfehlungen in Kapitel Umgang mit referenzierten oder angehängten Dokumenten.

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Spezifikation (normativ)

Die normative Spezifikation ist sehr umfangreich und detailliert. Die Komplexität der Spezifikation resultiert auf der Wiederverwendung zahlreicher Grundlagen aus dem HL7 CDA Standard, den darauf aufbauenden IHE Integrationsprofilen und den Präzisierungen für den helvetischen Gebrauch (CDA-CH). Weil so eine semantische Interoperabilität zwischen Informationssystemen (die sich nicht notwendigerweise kennen) erreicht werden kann und ein hoher Grad an Wiederverwendbarkeit des damit verbundenen Source-Codes ermöglicht wird, ist die entsprechende Komplexität der Spezifikation gerechtfertigt. Damit lassen sich die Ziele der Strategie eHealth Schweiz tatsächlich umsetzen.

Vereinfachte Zusammenfassung der CDA Struktur

Die Struktur des CDA Dokuments ist in den nachfolgenden Kapiteln im Detail beschrieben. Dem eiligen Leser bieten wir hier eine stark vereinfachte Zusammenfassung der Elemente im vorliegenden Austauschformat:

CDA Header

• Dokumentinformation (Dokumenten-Id, Code, Titel, Erstellungszeitpunkt, Vertraulichkeitsstufe, Sprache, Version)
• Angaben zum Patient (inkl. Versicherung und Versichertenkarte) resp. zu nicht-menschlichen Proben
• Mitwirkende am Dokument: Autoren, Erfasser, Klinische Validatoren, ausführende (externe) Laboratorien
• Rechtsgültiger Unterzeichner
• Absender (Verwalter)
• Empfänger inkl. allfälliger Kopie-Empfänger
• Verweis auf den Auftrag oder ein allfällig zu ersetzendes Dokument

CDA Body

• Kapitel 'Laborbefund'
  • Bei Bedarf können die Laborbefunde in Unterkapitel gegliedert werden
  • Eigentliche Laborresultate (inkl. Referenzbereiche, Interpretationscodes, allfällige frühere Resultate) in Batterien gruppiert. Mit Angaben zum Gerät, zum allfälligem externen Labor, das die Untersuchung durchgeführt hat, und wer das Resultat validiert hat.
  • Angaben zur Probenentnahme
  • Angaben zum Probeneingang beim Labor
  • Angaben zu Isolaten/Keimen in Batterien gruppiert
  • Multimedia-Objekte
  • Kommentare
• Kapitel 'Vitalzeichen'
  • Strukturierte Angabe von Vitalzeichen (Sauerstoffsättigung, Körpergewicht, -grösse, -temperatur, Kopfumfang, Blutdruck, Herzfrequenz, Atemfrequenz)
• Kapitel 'Weitere relevante Beobachtungen'
  • Strukturierte Angabe des Gestationsalters des Patienten bei seiner Geburt
• Kapitel 'Schwangerschaft'
  • Strukturierte Angaben im Falle einer aktuellen Schwangerschaft der Patientin, falls diese zur Interpretation der Laborwerte relevant sind.
    Hinweis: Diese Daten müssen beim Auftrag an das Labor mitgegeben, ansonsten hat das Labor keine Kenntnis davon.
    Mögliche Angaben sind beispielsweise:
    • Erwartetes Entbindungsdatum (klinische Schätzung)
    • Gestationsalter
    • Angaben zur Zyklusphase
• Kapitel 'Original Darstellung'
  • Eingebettetes PDF mit der Originaldarstellung des Dokuments, wie es vom rechtsgültigen Unterzeichner zum Zeitpunkt seiner Signatur gesehen wurde.

Vereinfachte grafische Darstellung des Dokumenteninhalts

Die nachfolgenden Abbildungen zeigen den Inhalt des CDA Dokuments symbolhaft auf.

Hinweise:

• Blaue Texte symbolisieren Inhalte, die Angaben übersteuern, welche zuvor auf einer höheren Stufe im Dokument angegeben sind.
• In jedem Fall gilt die Modellierung in ART-DECOR (auch bei allfälligen Abweichungen gegenüber den nachfolgenden Grafiken).

Dokument

Inhalt Laborbefund

Administrative Daten im Laborbefund (CDA Header)

Kapitel 'Laborbefunde'

Medizinische Daten im Kapitel 'Laborbefunde'

Strukturierte Laborwerte

Batterie mit Testresultaten

Testresultat

Kapitel 'Vitalzeichen'

Medizinische Daten im Kapitel 'Vitalzeichen'

Strukturierte Vitalzeichen

Vitalzeichen Messwert

Kapitel 'Weitere relevante Beobachtungen'

Medizinische Daten im Kapitel 'Weitere relevante Beobachtungen'

Gestationsalter

Kapitel 'Schwangerschaft'

Medizinische Daten im Kapitel 'Schwangerschaft'

Angaben zur aktuellen Schwangerschaft

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Allgemeines

Ein Dokument, welches anhand dieser Spezifikation erstellt wird, ist ein HL7 CDA Dokument und damit ein definiertes und komplettes Informationsobjekt, das Texte, Bilder und andere multimediale Objekte enthalten kann. CDA Dokumente dokumentieren den Gesundheitszustand eines Patienten zu einem bestimmten Zeitpunkt. Sie enthalten administrative (Header) und medizinische (Body) Daten und sind mittels eXtensible Markup Language (XML) codiert.
Die normative Spezifikation definiert das Dokument „eLaborbefund“ als HL7 CDA Vorlage, welche auf die helvetischen Präzisierungen von CDA-CH V2 (2017) aufbaut. Damit produzierte Dokumente sind vollständig kompatibel zum internationalen HL7 CDA R2 Standard (Normative Edition 2005) und somit international interoperabel.
Die normative Spezifikation bezweckt, dass Systeme für das Handling von „eLaborbefunden“ durch die Softwarehersteller unabhängig von Sender und Empfänger implementiert werden können.
Das vorliegende Austauschformat wurde in ART-DECOR modelliert und daraus können auch Schematron-Regeln generiert werden, welche eine automatisierte und harmonisierte Validierung der CDA-Dokumente erlauben.

Schlüsselwörter

Die normative Spezifikation verwendet folgende, jeweils in Grossbuchstaben geschriebene Schlüsselwörter zu Angabe von Verbindlichkeiten. Siehe auch [ELGA Allgemein], Kap. 4.1 resp. RFC 2119.
MUSS (engl. SHALL oder MUST) bedeutet eine verpflichtend einzuhaltende Vorschrift. Entspricht der Optionalität [R] und [M].
NICHT ERLAUBT (engl. NOT PERMITTED) formuliert ein verpflichtend einzuhaltendes Verbot. Entspricht der Optionalität [NP].
SOLL oder EMPFOHLEN (engl. SHOULD) steht für eine pragmatische Empfehlung. Es ist gewünscht und empfohlen, dass die Anforderung umgesetzt wird, es kann aber Gründe geben, warum dies unterbleibt. Entspricht der Optionalität Required [R]. Wenn kein Wert angegeben werden kann, MUSS nullFlavor angegeben werden..
KANN oder OPTIONAL (engl. MAY, OPTIONAL). Die Umsetzung der Anforderung ist optional, sie kann auch ohne zwingenden Grund unterbleiben. Entspricht dem Optionalität [O].

Optionalität

Nachfolgende Tabelle legt die Verwendung von zwingenden, empfohlenen und optionalen Elementen und den dazu gehörenden Kardinalitäten inkl. Verwendung von null-Flavor fest. Die nachfolgende Definition wurde aus [ELGA Allgemein] Kapitel 4.3 übernommen und auch für diese Spezifikation als normativ erklärt. Diese präzisiert die Vorgaben von IHE (erfolgt in Anlehnung an [IHE PCC-TF2] Kapitel 2.3.1) zu [R] und ergänzt die Elemente [M] und [NP].

Optionalitäten	Mögliche Kardinalitäten	Verwendung von nullFlavor	Beschreibung
[M]	1..1 1..*	NICHT ERLAUBT	Das Element MUSS mit einem korrekten "echten" Wert angegeben werden. nullFlavor oder "Dummy"-Werte sind NICHT ERLAUBT.
[NP]	0..0	NICHT ERLAUBT	Element ist NICHT ERLAUBT.
[R]	1..1 1..*	KANN verwendet werden	Das Element MUSS in der Instanz vorhanden sein. Wenn nicht bekannt, ist die Verwendung von nullFlavor vorgeschrieben, "Dummy"-Werte sind NICHT ERLAUBT.
[O]	0..1 0..*	KANN verwendet werden	Das Element ist OPTIONAL. Sender können das Element angeben. Leere optionale Elemente sind nicht zugelassen, sofern kein nullFlavor angewandt wird.
[C]	[N/A]	[N/A]	KONDITIONALES Optionalität. Die Optionalität des Elements variiert in Abhängigkeit von anderen Elementen, Situationen oder Zuständen. Die konkreten Abhängigkeiten sind jeweils angegeben.

Notationen im Dokument

nullFlavor

Wenn ein Wert nicht bekannt ist, kann dort wo es gemäss obenstehender Tabelle erlaubt ist, mit den nullFlavor-Codes in NullFlavor der Grund für die fehlende Angabe präzisiert werden. Wird ein nullFlavor eingesetzt, DÜRFEN mit Ausnahme von xsi:type KEINE weiteren Attribute angegeben werden.

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Hierarchie der Spezifikationen

Diese Spezifikation basiert in nachstehender Rangfolge auf folgenden Grundlagen:

1. HL7 Version 3
2. HL7 Clinical Document Architecture, Release 2.0
3. Spezifikation CDA-CH V2 (2017)
4. IHE Inhaltsprofil „Sharing Laboratory Reports (XD-LAB)“

Für die Umsetzung der Schematron Regeln wird auf der Grundlage von ISO Schematron aufgebaut: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40833

Dieses Material ist Teil des Leitfadens eHealth Suisse Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Akteure und Transaktionen

Nachfolgende Grafik zeigt die mit dem vorliegenden Austauschformat definierten Akteure und Transaktionen. Die Grafik zeigt auf, dass die involvierten Akteure rund um „CDA-CH-LREP (specification)“ ein Dokument auf Basis des entsprechenden IHE Inhaltsprofils machen können.

Akteure gemäss IHE PaLM TF-3

IHE XD-LAB (Kapitel „4.2“) nennt die Umsetzung mit den IHE Integrationsprofilen XDS.b, XDR, XDM. Die IHE Integrationsprofile XDS.b und XDR realisieren die Interaktion „Share content“ mit der IHE Transaktion „Provide and Register Document Set-b [ITI-41]“:

Akteure und Transaktionen (konkret für XDS und XDR)

Das IHE Integrationsprofil XDM realisiert die Interaktion „Share content“ mit der IHE Transaktion „Distribute Document Set on Media [ITI-32]“:

Akteure und Transaktionen (konkret für XDM)

Für eine genaue Beschreibung der Akteure, Transaktionen und Inhalte verweisen wir auf die IHE Dokumentation [IHE ITI TF-2b] , Kapitel „3.32 Distribute Document Set on Media“ resp. „3.41 Provide and Register Document Set-b“, da die eigentliche Übermittlung / Speicherung (Share Content) nicht Bestandteil der vorliegenden Spezifikation ist.

CDA Document Level Templates

General Laboratory Report

Id	2.16.756.5.30.1.1.10.1.10	Effective Date	2019‑07‑30 18:01:10 Other versions this id: CDA-CH-LREP-GR-V1 as of 2018‑04‑19
Status	Draft	Version Label	2019
Name	CDA-CH-LREP-GR-V1	Display Name	General Laboratory Report
Description	Swiss Laboratory Report - General Report
Context	Pathname /
Classification	CDA Document Level Template
Open/Closed	Open (other than defined elements are allowed)
Uses	Uses 29 templates Uses as Name Version 2.16.756.5.30.1.1.10.2.25 Include Document Realm (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.18 Include Document Template Ids CDA-CH v2.0 - structuredBody (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.55 Include Document Template Ids CDA-CH-LREP V1 (2018) DYNAMIC 2.16.756.5.30.1.1.10.2.23 Include Document Id (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.56 Include Document Code (2018) DYNAMIC 2.16.756.5.30.1.1.10.2.62 Include Document Title (2018) DYNAMIC 2.16.756.5.30.1.1.10.2.19 Include Document Confidentiality Code (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.22 Include Document Language (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.20 Include Document Set Id and Version Number (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.58 Include Human Patient - recordTarget (2018) DYNAMIC 2.16.756.5.30.1.1.10.2.26 Include Non-Human Subject - recordTarget (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.27 Include Human Patient with Non-Human Subject - recordTarget (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.59 Include Author (2018) DYNAMIC 2.16.756.5.30.1.1.10.2.7 Include Data Enterer (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.60 Include Custodian (2018) DYNAMIC 2.16.756.5.30.1.1.10.2.57 Include Recipient (2018) DYNAMIC 2.16.756.5.30.1.1.10.2.61 Include Legal Authenticator (2018) DYNAMIC 2.16.756.5.30.1.1.10.2.88 Include Laboratory Results Validator - authenticator (2019) DYNAMIC 2.16.756.5.30.1.1.10.2.16 Include Order Reference - inFulfillmentOf (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.46 Include Health Service - documentationOf (2019) DYNAMIC 2.16.756.5.30.1.1.10.2.28 Include Laboratory Performer - documentationOf (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.14 Include Insurance Card - participant (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.15 Include Insurance - participant (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.13 Include Document Replacement - relatedDocument (2019) DYNAMIC 2.16.756.5.30.1.1.10.3.77 Containment Laboratory Speciality Section - coded (2019) DYNAMIC 2.16.756.5.30.1.1.10.3.4 Containment Vital Signs Section - coded (2016) DYNAMIC 2.16.756.5.30.1.1.10.3.46 Containment Other Relevant Observations Section - coded (2018) DYNAMIC 2.16.756.5.30.1.1.10.3.53 Containment Current Pregnancy Section - coded (2018) DYNAMIC 2.16.756.5.30.1.1.10.3.45 Containment Original Representation Section - coded (2017) DYNAMIC
Relationship	Specialization: template 2.16.756.5.30.1.1.10.1.14 CDA-CH v2.0 - structuredBody enhanced (DYNAMIC) ref hl7chcda- Specialization: template 2.16.756.5.30.1.1.10.1.9 CDA-CH v2.0 - structuredBody (DYNAMIC) ref hl7chcda- Specialization: template 2.16.840.1.113883.10.12.2 CDA ClinicalDocument (with StructuredBody) (2005‑09‑07) ref ad1bbr-
Example	Example <!-- See https://svn.code.sf.net/p/hl7ch/code/trunk/projects/eHealthSuisse/eLaborbefund/v1.0/ for examples -->
Item DT Card Conf Description Label hl7:ClinicalDocument 1 … 1 M Swiss Laboratory Report - General Report Conformity rules that are not further modelled in ART-DECOR: XML encoding UTF-8 encoding is required. All CDA-CH V2 documents MUST start with this line: <?xml version="1.0" encoding="UTF-8"?> Phone numbers Phone numbers MUST be declared in the international format. Dots (.) MUST be used as separators for grouping of number blocks. The minus sign (-) MUST be used as a separator between public and internal telephone numbers. Purpose: Some telephone exchanges - especially in the US, allow direct dial-up of an internal telephone number after the actual connection has been established over the public telephone network. Examples: <telecom value="tel:+41.33.123.45.67"/> <telecom value="tel:+1.987.654.3210-999"/> (CDA...-V1) Included 1 … 1 M from 2.16.756.5.30.1.1.10.2.25 Document Realm (DYNAMIC) hl7:realmCode CS 1 … 1 M Swiss Realm (CHE) of HL7 CDA. CDA‑CH V2 @code CONF 1 … 1 F CHE hl7:typeId II 1 … 1 M (CDA...-V1) @root uid 1 … 1 F 2.16.840.1.113883.1.3 @extension st 1 … 1 F POCD_HD000040 Included from 2.16.756.5.30.1.1.10.2.18 Document Template Ids CDA-CH v2.0 - structuredBody (DYNAMIC) hl7:templateId II 0 … 1 CDA-CH v2.0 specification. This is an informational reference, only. CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.1.1.4 hl7:templateId II 1 … 1 M HL7 CDA R2 (2005); contains ClinicalDocument.component as structuredBody. CDA‑CH V2 @root uid 1 … 1 F 2.16.840.1.113883.10.12.2 hl7:templateId II 1 … 1 M HL7 CDA R2 (2005). CDA‑CH V2 @root uid 1 … 1 F 2.16.840.1.113883.10.12.1 Included from 2.16.756.5.30.1.1.10.2.55 Document Template Ids CDA-CH-LREP V1 (DYNAMIC) hl7:templateId II 0 … 1 CDA-CH-LREP / Laboratory Reports V1 specification. This is an informational reference, only. CDA‑...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.1.1.3.9.1 hl7:templateId II 1 … 1 M Exchange format according to the Swiss EPR CDA‑...LREP @root uid 1 … 1 F 2.16.756.5.30.1.127.1.4 hl7:templateId II 1 … 1 M Sharing Laboratory Reports (XD-LAB) Content Module, IHE PaLM Technical Framework Revision Revision 8.0 - June 21, 2017. CDA‑...LREP @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.3.3 hl7:templateId II 1 … 1 M CDA-CH-LREP / Laboratory Reports V1 ART-DECOR model for General Report. (CDA...-V1) @root uid 1 … 1 F 2.16.756.5.30.1.1.10.1.10 Included 1 … 1 M from 2.16.756.5.30.1.1.10.2.23 Document Id (DYNAMIC) hl7:id II 1 … 1 M A unique identifier for each CDA document instance. CDA‑CH V2   hl7chcda-data​element-217  Identification number of the document  CDA-CH V2 2017 @root uid 1 … 1 R The document's id as Globally Unique Identifier (GUID). @extension st 0 NP NP/not present Included 1 … 1 M from 2.16.756.5.30.1.1.10.2.56 Document Code (DYNAMIC) hl7:code CE 1 … 1 M A LOINC based document type of a CDA document instance including a translation to the Swiss EPR XDS.b metadata. Multidisciplinary laboratory findings: The LOINC code of the document MUST read: 11502-2 (LABORATORY REPORT.TOTAL) Laboratory reports of a single laboratory discipline: The LOINC code of the document MUST be taken from the value-set 'Laboratory Specialties' IHE PalM TF3 Rev.8, 6.3.2.5 @code cs 1 … 1 R The exact value of @code MUST either read '11502-2' or taken from the value-set 'Laboratory Specialties'. @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.1 @codeSystemName st 1 … 1 F LOINC @displayName st 1 … 1 R The exact value of @displayName MUST either read 'LABORATORY REPORT.TOTAL' or taken from the value-set 'Laboratory Specialties'.   CONF The value of @code shall be drawn from value set 1.3.6.1.4.1.19376.1.3.11.6 Multi-disciplinary Laboratory Report (DYNAMIC) or The value of @code shall be drawn from value set 1.3.6.1.4.1.19376.1.3.11.1 Laboratory Specialties (DYNAMIC) hl7:translation CD 1 … 1 R The translation to the Swiss EPR XDS.b metadata attribute typeCode. IHE PalM TF3 Rev.8, 6.3.2.5 @code cs 1 … 1 F 4241000179101 @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.96 @codeSystemName st 1 … 1 F SNOMED CT @displayName st 1 … 1 F Laboratory report   CONF The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.27 DocumentEntry.typeCode (DYNAMIC) Included 1 … 1 M from 2.16.756.5.30.1.1.10.2.62 Document Title (DYNAMIC) hl7:title ST 1 … 1 M The document title must follow the following text format where <human readable code> is the local translation of the document LOINC code: [de]: 'Laborbefund - <human readable code>' [fr]: 'Rapport de laboratoire - <human readable code>' [it]: 'Referto di laboratorio - <human readable code>' [en]: 'Laboratory report - <human readable code>' CDA‑...LREP   Variable let Name languageCode     Value substring(/hl7:ClinicalDocument/hl7:language​Code/@code,1,2)     Schematron assert role  error     test not($languageCode='en') or starts-with(text(),'Laboratory report')     Message The English title must start with 'Laboratory report'     Schematron assert role  error     test not($languageCode='de') or starts-with(text(),'Laborbefund')     Message The German title must start with 'Laborbefund'     Schematron assert role  error     test not($languageCode='fr') or starts-with(text(),'Rapport de laboratoire')     Message The French title must start with 'Rapport de laboratoire'     Schematron assert role  error     test not($languageCode='it') or starts-with(text(),'Rapporto di laboratorio')     Message The Italian title must start with 'Rapporto di laboratorio'   hl7:effectiveTime TS.CH.TZ 1 … 1 M ClinicalDocument/effectiveTime MUST exist. It contains the creation date and time of the laboratory report. If this document replaces a previous version (linked via parentDocument), this is the date and time of the new version. (CDA...-V1) Included 1 … 1 M from 2.16.756.5.30.1.1.10.2.19 Document Confidentiality Code (DYNAMIC) hl7:confidentialityCode CE (required) 1 … 1 M Swiss Realm of Confidentiality Code according to the Swiss EPR regulation. CDA‑CH V2   hl7chcda-data​element-222  Confidentiality level  CDA-CH V2 2017 @code cs 1 … 1 R The value of @code MUST be drawn from value set EprDocumentConfidentialityCode (2.16.756.5.30.1.127.3.10.1.5) @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.96 @codeSystemName st 1 … 1 F SNOMED CT @displayName st 1 … 1 R The value of @displayName MUST be drawn from value set EprDocumentConfidentialityCode (2.16.756.5.30.1.127.3.10.1.5)   CONF The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.5 DocumentEntry.confidentialityCode (DYNAMIC) Included 1 … 1 M from 2.16.756.5.30.1.1.10.2.22 Document Language (DYNAMIC) hl7:language​Code CS 1 … 1 M The RFC 1766 (ISO-639-1 and ISO 3166) based language in which the narrative texts in this CDA document instance are written. CDA‑CH V2   hl7chcda-data​element-219  Language of the document  CDA-CH V2 2017   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.11526 HumanLanguage (DYNAMIC) Included 1 … 1 M from 2.16.756.5.30.1.1.10.2.20 Document Set Id and Version Number (DYNAMIC) hl7:setId II 1 … 1 M The setId element MUST match the document id of the very first version of that document. It MUST remain the same for all document versions. CDA‑CH V2 @root uid 1 … 1 R The root attribute MUST contain the setId as Globally Unique Identifier (GUID). @extension st 0 NP NP/not present   Schematron assert role  error     test (parent::*/hl7:versionNumber[@value='1'] and @root=parent::*/hl7:id/@root and (@extension=parent::*/hl7:id/@extension or (not(@extension) and not(parent::*/hl7:id/@extension)))) or (parent::*/hl7:versionNumber[not(@value ='1')] and ((@root=parent::*/hl7:id/@root and @extension and not(@extension=parent::*/hl7:id/@extension)) or(not(@root=parent::*/hl7:id/@root))))     Message The setId MUST be equal with the document id for version 1 and it MUST differ for all other versions.   hl7:versionNumber INT.​NONNEG 1 … 1 M The versionNumber element MUST contain the value 1 for the very first version of that document. For later versions, the version number MUST be increased by 1 each. CDA‑CH V2   hl7chcda-data​element-223  Version  CDA-CH V2 2017 Choice 1 … 1 recordTarget MUST be present in one of the following characteristics: Human Patient: The laboratory report contain test results from samples taken exclusively from a human patient. Non-Human Subject: The laboratory report contains test results from samples taken from a non-human material (e.g., water, milk, etc.) or a living being (e.g., animal), but not related to a human patient. Human Patient with Non-Human Subject: The laboratory report contains test results from samples taken from a non-human material that is related to a human patient (e.g., food eaten by the patient or animal that has bitten the patient). Elements to choose from: hl7:recordTarget included from template 2.16.756.5.30.1.1.10.2.58 Human Patient - recordTarget (DYNAMIC) hl7:recordTarget included from template 2.16.756.5.30.1.1.10.2.26 Non-Human Subject - recordTarget (DYNAMIC) hl7:recordTarget included from template 2.16.756.5.30.1.1.10.2.27 Human Patient with Non-Human Subject - recordTarget (DYNAMIC) Included 0 … 1 from 2.16.756.5.30.1.1.10.2.58 Human Patient - recordTarget (DYNAMIC) Human Patient: The laboratory results contain test results from samples taken exclusively from a human patient. All persons (including patients) and organizations, MUST according to XD-LAB contain name, addr and telecom. hl7:recordTarget 0 … 1 R Patient (Human Patient). CDA‑...LREP hl7:templateId II 1 … 1 M CDA‑...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.58 hl7:templateId II 1 … 1 M CDA‑...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.1 hl7:patientRole 1 … 1 R Exactly one patient MUST be declared. CDA‑...LREP hl7:id II 1 … * R At least one patient identification MUST be declared. CDA‑...LREP @root uid 1 … 1 R MUST contain the OID of the system that issued the ID. OIDs of code systems, which are published in the public OID registry for the Swiss health care system (oid.refdata.ch) are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   Contains the patient number itself. The number MUST be unique within the system that has issued the number. hl7:addr AD 1 … * R All persons (including patients) and organizations, MUST according to XD-LAB contain name, addr and telecom. Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC) CDA‑...LREP hl7:telecom TEL 1 … * R All persons (including patients) and organizations, MUST according to XD-LAB contain name, addr and telecom. CDA‑...LREP hl7:patient 1 … 1 R Exactly one patient MUST be declared. CDA‑...LREP hl7:name PN 1 … * R All persons (including patients) and organizations, MUST according to XD-LAB contain name, addr and telecom. CDA‑...LREP hl7:administrative​Gender​Code CE 1 … 1 R The sex of the patient MUST be indicated according to XD-LAB. CDA‑...LREP   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.1 AdministrativeGender (DYNAMIC) hl7:birthTime TS 1 … 1 R The date of birth of the patient MUST be given according to XD-LAB. CDA‑...LREP Included 0 … 1 from 2.16.756.5.30.1.1.10.2.26 Non-Human Subject - recordTarget (DYNAMIC) Non-Human Subject: The laboratory report contains test results from samples taken from a non-human material (e.g., water, milk, etc.) or a living being (e.g., animal), but not related to a human patient. hl7:recordTarget 0 … 1 R Non-Human Subject. IHE PalM TF3 Rev.8, 6.3.2.11.2 hl7:templateId II 1 … 1 M IHE PalM TF3 Rev.8, 6.3.2.11.2 @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.3.3.1.2   Schematron assert role  error     test //hl7:templateId[@root='1.3.6.1.4.1.19376.1.3.3.1.2.1']     Message In addition to the elements specified in the CDA header for the non-human subject, this non-human subject SHALL be represented in a Subject element in level 3 entries in the structuredBody.   hl7:templateId II 1 … 1 M IHE PalM TF3 Rev.8, 6.3.2.11.2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.26 hl7:patientRole 1 … 1 R IHE PalM TF3 Rev.8, 6.3.2.11.2 hl7:id II 1 … * R IHE PalM TF3 Rev.8, 6.3.2.11.2 @root uid 1 … 1 R MUST contain the OID of the system that issued the number. OIDs of code systems, which are published in the public OID registry for the Swiss health care system (oid.refdata.ch) are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   Contains the actual number of non-human material. The number MUST be unique within the system that issued the number. hl7:patient 1 … 1 IHE PalM TF3 Rev.8, 6.3.2.11.2 @nullFlavor cs 1 … 1 F OTH   Indicates that there are laboratory tests for this non-human material in the CDA Body. Included 0 … 1 from 2.16.756.5.30.1.1.10.2.27 Human Patient with Non-Human Subject - recordTarget (DYNAMIC) Human Patient with Non-Human Subject: The laboratory report contains test results from samples taken from a non-human material that is related to a human patient (e.g., food eaten by the patient or animal that has bitten the patient). hl7:recordTarget 0 … 1 R Human Patient with Non-Human Subject. IHE PalM TF3 Rev.8, 6.3.2.11.3 hl7:templateId II 1 … 1 M IHE PalM TF3 Rev.8, 6.3.2.11.3 @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.3.3.1.3   Schematron assert role  error     test //hl7:templateId[@root='1.3.6.1.4.1.19376.1.3.3.1.3.1']     Message In addition to the elements specified in the CDA header for the patient, the non-human subject SHALL be represented in a Subject element in level 3 entries in the structuredBody.   hl7:templateId II 1 … 1 M IHE PalM TF3 Rev.8, 6.3.2.11.3 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.27 hl7:patientRole 1 … 1 R Exactly one patient MUST be declared. IHE PalM TF3 Rev.8, 6.3.2.11.3 hl7:id II 1 … * R At least one patient identification MUST be declared. Note: The identification of the non-human material MUST NOT be deklared here. This can not be specified within the same document. See also: IHE PaLM TF3, section 6.3.2.11.3. If the identification of the non-human material is important (for example in rabies), two separate documents should be created (one with the human patient and one with the non-human material). IHE PalM TF3 Rev.8, 6.3.2.11.3 @extension st 1 … 1 R MUST contain the actual number of non-human material. The number MUST be unique within the system that issued the number. @root uid 1 … 1 R MUST contain the OID of the system that issued the number. OIDs of code systems, which are published in the public OID registry for the Swiss health care system (oid.refdata.ch) are REQUIRED. Others are NOT ALLOWED. hl7:addr AD 1 … * R All persons (including patients) and organizations, MUST contain according to XD-LAB name, addr and telecom. IHE PalM TF3 Rev.8, 6.3.2.11.3 hl7:telecom TEL 1 … * R All persons (including patients) and organizations, MUST contain according to XD-LAB name, addr and telecom. IHE PalM TF3 Rev.8, 6.3.2.11.3 hl7:patient 1 … 1 R Exactly one patient MUST be declared. IHE PalM TF3 Rev.8, 6.3.2.11.3 hl7:name PN 1 … * R All persons (including patients) and organizations, MUST contain according to XD-LAB name, addr and telecom. IHE PalM TF3 Rev.8, 6.3.2.11.3 hl7:administrative​Gender​Code CE 1 … 1 R IHE PalM TF3 Rev.8, 6.3.2.11.3   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.1 AdministrativeGender (DYNAMIC) hl7:birthTime TS 1 … 1 R IHE PalM TF3 Rev.8, 6.3.2.11.3 Included 1 … * M from 2.16.756.5.30.1.1.10.2.59 Author (DYNAMIC) hl7:author 1 … * M Information about the author of the document. The author MAY be a person or a device. At least one author MUST be declared. CDA‑...LREP hl7:templateId II 1 … 1 M CDA‑...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.59 hl7:templateId II 1 … 1 M CDA‑...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.9.23 hl7:functionCode CE 1 … 1 R The functionCode MUST be taken from the Swiss EPR Value-Set for author roles. See FDHA Ordinance on the Electronic Patient Record (EPRO-FDHA), Appendix 3: Metadata, Section 2.1. If the desired functionCode is not available in the Swiss EPR Value-Set for author roles, nullFlavor='NAV' MUST be used. In this case, the originalText element MUST contain the description of the role. Translations to other vocabularies are allowed. CDA‑...LREP @nullFlavor st 0 … 1 F NAV @code cs 0 … 1   @codeSystem oid 0 … 1 F 2.16.840.1.113883.6.96 @codeSystemName st 0 … 1 F SNOMED CT @displayName st 0 … 1     CONF The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.1.3 DocumentEntry.authorRole (DYNAMIC)   Example <functionCode code="106292003" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Professional nurse"/>   Example <functionCode nullFlavor="NAV">   <originalText>Home helper</originalText></functionCode>   Example <functionCode nullFlavor="NAV">   <originalText>Laboratory technician</originalText>  <translation code="3212" codeSystem="2.16.840.1.113883.2.9.6.2.7" codeSystemName="ISCO-08" displayName="Medical and pathology laboratory technicians"/></functionCode>   Schematron assert role  error     test (@code and @codeSystem) or (@nullFlavor='NAV')     Message Either a code with its code system or nullFlavor='NAV' is required.     Schematron assert role  error     test not(@nullFlavor) or (hl7:originalText)     Message Other Caregivers description MUST be declared in the originalText element in case of nullFlavor.   hl7:translation 0 … * A translation of the code to another coding system (e.g. ISCO-08: 2.16.840.1.113883.2.9.6.2.7) CDA‑...LREP @code cs 1 … 1 R @codeSystem oid 1 … 1 R @codeSystemName st 1 … 1 R @displayName st 1 … 1 R hl7:translation 0 … 1 Use this translation when the author is the patient itself (e.g. by reporting a self medication or a medical problem). CDA‑...LREP @code cs 1 … 1 F 116154003 @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.96 @codeSystemName st 1 … 1 F SNOMED CT @displayName st 1 … 1 F Patient (person) hl7:time TS.CH.TZ 1 … 1 R Date and time of the laboratory report creation. CDA‑...LREP hl7:assignedAuthor 1 … 1 R CDA‑...LREP   Schematron assert role  error     test not(hl7:assigned​Authoring​Device/hl7:softwareName) or (hl7:represented​Organization)     Message For device authors the element representedOrganization is REQUIRED.     Schematron assert role  error     test (hl7:telecom[@use='PUB' and starts-with(@value,'tel:+')]) and (hl7:telecom[@use='PUB' and starts-with(@value,'mailto:')])     Message A public telephone number in the international format and a public eMail address are required.     Schematron assert role  error     test (hl7:addr[@use='PUB'])     Message A public address is required.   hl7:id II 1 … 1 R The specification of GS1 GLN is REQUIRED. If it is not (yet) known, this MUST be declared using nullFlavor. For persons: their personal GLN MUST be declared. For devices or software modules: the GLN of their organization MUST be declared. CDA‑...LREP @nullFlavor cs 0 … 1 F NAV   Temporarily unknown, will be filled later. @root cs 0 … 1 F 2.51.1.3   OID for GS1 GLN. @extension st 0 … 1   The GS1 GLN.   Schematron assert role  error     test (@root='2.51.1.3' and @extension) or (@nullFlavor='NAV')     Message Either the GS1 GLN or nullFlavor='NAV' is REQUIRED   hl7:id II 0 … * Other ids are allowed. CDA‑...LREP @root cs 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   The id itself. It MUST be unique within the issuing system. hl7:addr AD 1 … * Address of the laboratory. Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC) CDA‑...LREP hl7:telecom TEL 1 … * Means of communication of the laboratory (phone, eMail, ...). CDA‑...LREP Choice 1 … 1 Elements to choose from: hl7:assigned​Person containing template 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) hl7:assigned​Authoring​Device containing template 2.16.756.5.30.1.1.10.9.21 Device Compilation with name (DYNAMIC) hl7:assigned​Person 0 … 1 The author as a person. Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) CDA‑...LREP hl7:assigned​Authoring​Device 0 … 1 The author as a device. Contains 2.16.756.5.30.1.1.10.9.21 Device Compilation with name (DYNAMIC) CDA‑...LREP hl7:represented​Organization 0 … 1 The author's organization. Contains 2.16.756.5.30.1.1.10.9.27 Organization Compilation with name, addr, telecom (DYNAMIC) CDA‑...LREP   Schematron assert role  error     test /hl7:ClinicalDocument/hl7:author/hl7:functionCode/hl7:translation[@code='3212' and @codeSystem='2.16.840.1.113883.2.9.6.2.7']     Message At least one of the listed authors MUST be a laboratory specialist.   Included 0 … 1 from 2.16.756.5.30.1.1.10.2.7 Data Enterer (DYNAMIC) hl7:dataEnterer 0 … 1 Information about the person that entered information in this CDA document. It SHALL be declared, when data recorded in this document has been entered by a person other than the author but only when this is relevant for some reason. CDA‑CH V2 hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.7 hl7:time TS.CH.TZ 0 … 1 Timestamp of the data input. CDA‑CH V2 hl7:assignedEntity 1 … 1 R Contains 2.16.756.5.30.1.1.10.9.12 Assigned Entity Compilation with id (DYNAMIC) CDA‑CH V2 Included 1 … 1 M from 2.16.756.5.30.1.1.10.2.60 Custodian (DYNAMIC) hl7:custodian 1 … 1 M CDA‑...LREP hl7:templateId II 1 … 1 M CDA‑...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.3 hl7:templateId II 1 … 1 M CDA‑...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.60 hl7:assignedCustodian 1 … 1 R CDA‑...LREP hl7:represented​Custodian​Organization 1 … 1 R CDA‑...LREP   Schematron assert role  error     test (hl7:telecom[@use='PUB' and starts-with(@value,'tel:+')])     Message A public telephone number in the international format is required.     Schematron assert role  error     test (hl7:addr[@use='PUB'])     Message A public address is required.   hl7:id II 1 … * R The specification of GS1 GLN is required. If it is not (yet) known, this must be declared using nullFlavor. CDA‑...LREP @nullFlavor cs 0 … 1 F NAV   Temporarily unknown, will be filled later. @root cs 0 … 1 F 2.51.1.3   OID for GS1 GLN @extension st 0 … 1   The GS1 GLN of the laboratory or the doctor's office (in the case of individual practices, the doctor's GLN).   Schematron assert role  error     test (@root='2.51.1.3' and @extension) or (@nullFlavor='NAV')     Message Either the GS1 GLN or nullFlavor='NAV' is required.   hl7:id II 0 … * C SASIS number (ge:ZSR / fr:RCC), if the lab services are to be refunded by the insurance. CDA‑...LREP @root cs 1 … 1 F 2.16.756.5.30.1.123.100.2.1.1   OID for SASIS number (ge:ZSR / fr:RCC). @extension st 1 … 1 R SASIS number (ge:ZSR / fr:RCC) of the laboratory or the physician. hl7:name ON 1 … 1 R Name of the laboratory. CDA‑...LREP hl7:telecom TEL 1 … * R Means of communication of the laboratory (phone., eMail, ...). CDA‑...LREP hl7:addr AD 1 … * R Address of the laboratory. Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC) CDA‑...LREP Included 1 … * M from 2.16.756.5.30.1.1.10.2.57 Recipient (DYNAMIC) hl7:information​Recipient 1 … * M The laboratory report MUST contain at least one receiver. CDA‑...LREP @typeCode cs 1 … 1 R The main recipient of the document MUST be specified using typeCode 'PRCP' (primary recipient). Other receivers (copy to; Cc) MUST be specified using typeCode 'TRC' (tracker).   CONF The value of @typeCode shall be drawn from value set 2.16.840.1.113883.1.11.19366 x_InformationRecipient (DYNAMIC) hl7:templateId II 1 … 1 M CDA‑...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.4 hl7:templateId II 1 … 1 M CDA‑...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.57 hl7:templateId II 1 … 1 M CDA‑...LREP @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.3.3.1.4 hl7:intended​Recipient 1 … 1 M The laboratory report MUST contain at least one receiver. CDA‑...LREP hl7:addr AD 1 … * R An address MUST be present according to XD-LAB. Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC) CDA‑...LREP hl7:telecom TEL 1 … * R A communication mean MUST be present according to XD-LAB. CDA‑...LREP hl7:information​Recipient 0 … 1 If the person of the recipient is used, it MUST according to XD-LAB declare a name. Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) CDA‑...LREP hl7:received​Organization 0 … 1 If the organization of the recipient is used, it MUST according to XD-LAB declare name, addr and telecom. Contains 2.16.756.5.30.1.1.10.9.27 Organization Compilation with name, addr, telecom (DYNAMIC) CDA‑...LREP   Schematron assert role  error     test hl7:information​Recipient[not(@nullFlavor)] or hl7:received​Organization[not(@nullFlavor)]     Message Either the recipients person or organization MUST be declared.   Included 0 … 1 from 2.16.756.5.30.1.1.10.2.61 Legal Authenticator (DYNAMIC) hl7:legalAuthenticator 0 … 1 Legal authenticator. CDA‑...LREP hl7:templateId II 1 … 1 M CDA‑...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.61 hl7:templateId II 1 … 1 M CDA‑...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.5 hl7:time TS.CH.TZ 1 … 1 R Date of the signature. CDA‑...LREP hl7:signatureCode CS 1 … 1 R CDA‑...LREP @code cs 1 … 1 F S @codeSystem oid 1 … 1 F 2.16.840.1.113883.1.11.10282 @codeSystemName st 1 … 1 F ParticipationSignature @displayName st 1 … 1 F signed   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC) hl7:assignedEntity 1 … 1 R The GLN MUST be used to identify the legal authenticator (e.g., laboratory manager or responsible physician). All persons and organizations, MUST according to XD-LAB contain name, addr and telecom. Contains 2.16.756.5.30.1.1.10.9.47 AssignedEntity Compilation for Laboratory (DYNAMIC) CDA‑...LREP Included 0 … * from 2.16.756.5.30.1.1.10.2.88 Laboratory Results Validator - authenticator (DYNAMIC) hl7:authenticator 0 … * Information about an authenticator of a CDA document. An authenticator MUST be a person. IHE PalM TF3 Rev.9, 6.3.2.16 hl7:templateId II 1 … 1 M IHE PalM TF3 Rev.9, 6.3.2.16 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.88 hl7:templateId II 1 … 1 M IHE PalM TF3 Rev.9, 6.3.2.16 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.6 hl7:templateId II 1 … 1 M IHE PalM TF3 Rev.9, 6.3.2.16 @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.3.3.1.5 hl7:time TS.CH.TZ 1 … 1 R Timestamp of the signature. IHE PalM TF3 Rev.9, 6.3.2.16 hl7:signatureCode CS 1 … 1 R IHE PalM TF3 Rev.9, 6.3.2.16 @code cs 1 … 1 F S @codeSystem oid 0 NP NP/not present @codeSystemName st 0 NP NP/not present @displayName st 0 NP NP/not present   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC) hl7:assignedEntity 1 … 1 R Contains 2.16.756.5.30.1.1.10.9.12 Assigned Entity Compilation with id (DYNAMIC) IHE PalM TF3 Rev.9, 6.3.2.16 Included 0 … 1 from 2.16.756.5.30.1.1.10.2.16 Order Reference - inFulfillmentOf (DYNAMIC) hl7:inFulfillmentOf 0 … 1 Reference to one or more orders which led to the creation of this CDA document. It SHALL be declared, when the order reference is relevant for some reason. CDA‑CH V2 hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.16 hl7:order 1 … 1 R CDA‑CH V2 hl7:id II 1 … * R Order number. CDA‑CH V2 @root uid 1 … 1 R Either the same GUID (order id) or the same OID (order issuing system) as the order itself. @extension st 0 … 1   Contains the order ID itself. The ID MUST be unique within the system that issued the ID. Included 0 … 1 from 2.16.756.5.30.1.1.10.2.46 Health Service - documentationOf (DYNAMIC) hl7:documentationOf 0 … 1 Information about a health service describing the context of this CDA document. CDA‑CH V2 @typeCode cs 1 … 1 F DOC hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.46 hl7:serviceEvent 1 … 1 R CDA‑CH V2 @classCode cs 1 … 1 F ACT @moodCode cs 1 … 1 F EVN hl7:id II 0 … * Health service identifiers such as case number ([ge]: Fallnummer; [fr]: Numéro de cas), consultation id, episode id, etc. CDA‑CH V2 @root uid 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   The id itself. It MUST be unique within the issuing system. hl7:code CE 1 … 1 R As long as the eventCodeList for the Swiss EPR metadata is not defined yet by the FDHA Ordinance on the Electronic Patient Record (EPRO-FDHA), the nullFlavor='NAV' MUST be used in this template. Other codes MAY be declared as translation. CDA‑CH V2 @nullFlavor st 1 … 1 F NAV @code cs 0 NP NP/not present @codeSystem oid 0 NP NP/not present @codeSystemName st 0 NP NP/not present @displayName st 0 NP NP/not present hl7:translation 0 … * A translation of the code to another coding system. CDA‑CH V2 @code cs 1 … 1 R @codeSystem oid 1 … 1 R @codeSystemName st 1 … 1 R @displayName st 1 … 1 R hl7:effectiveTime IVL_TS.CH.TZ 1 … 1 R Duration of the health service. CDA‑CH V2 hl7:low TS.CH.TZ 1 … 1 R Start of the health service. CDA‑CH V2 hl7:high TS.CH.TZ 1 … 1 R End of the health service. CDA‑CH V2 Included 0 … * from 2.16.756.5.30.1.1.10.9.31 Performer (DYNAMIC) hl7:performer 0 … * Information about a healthcare provider who was the primary performer of the act. CDA‑CH V2 @typeCode cs 1 … 1 F PRF hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.9.31 hl7:templateId 1 … 1 R CDA‑CH V2 @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.5.3.1.1.24.3.5 hl7:time IVL_TS.CH.TZ 0 … 1 Duration of the performance. CDA‑CH V2 hl7:low TS.CH.TZ 1 … 1 R Start of the performance. CDA‑CH V2 hl7:high TS.CH.TZ 1 … 1 R End of the performance. CDA‑CH V2 hl7:assignedEntity 1 … 1 R Contains 2.16.756.5.30.1.1.10.9.32 Assigned Entity Compilation with id, name, addr, telecom, person and organization (DYNAMIC) CDA‑CH V2 Included 0 … * from 2.16.756.5.30.1.1.10.2.28 Laboratory Performer - documentationOf (DYNAMIC) hl7:documentationOf 0 … * IHE PalM TF3 Rev.8, 6.3.2.20 hl7:templateId II 1 … 1 M IHE PalM TF3 Rev.8, 6.3.2.20 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.28 hl7:serviceEvent 1 … 1 R IHE PalM TF3 Rev.8, 6.3.2.20 hl7:effectiveTime IVL_TS.CH.TZ 0 … 1 Use of sub element documentationOf/serviceEvent/effectiveTime to document the time boundaries of events in the document is appropriate. IHE PalM TF3 Rev.8, 6.3.2.20 hl7:performer 0 … * Laboratory Performer template in the CDA header. Contains 2.16.756.5.30.1.1.10.4.7 Laboratory Performer - performer Containment (DYNAMIC) IHE PalM TF3 Rev.8, 6.3.2.20 where [hl7:assignedEntity] Included 0 … * from 2.16.756.5.30.1.1.10.2.14 Insurance Card - participant (DYNAMIC) hl7:participant 0 … * Information on a patient's insurance card. CDA‑CH V2 @typeCode cs 1 … 1 F HLD hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.14 hl7:time IVL_TS.CH.TZ 1 … 1 R Validity period of the insurance card. CDA‑CH V2 hl7:low TS.CH.TZ 1 … 1 CDA‑CH V2 @nullFlavor cs 1 … 1 F NASK hl7:high TS.CH.TZ 1 … 1 R Expiration date of the insurance card. CDA‑CH V2 hl7:associated​Entity 1 … 1 R CDA‑CH V2 @classCode cs 1 … 1 F POLHOLD hl7:id II 1 … 1 R The insurance card's id. CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.123.100.1.1.1 @extension st 1 … 1 R Number of the insurance card. hl7:associated​Person 0 … 1 Family and given name on the insurance card. Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) CDA‑CH V2 hl7:scoping​Organization 0 … 1 The insurance company which issued the insurance card. Contains 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC) CDA‑CH V2 Included 0 … * from 2.16.756.5.30.1.1.10.2.15 Insurance - participant (DYNAMIC) hl7:participant 0 … * Information on a patient's insurance. CDA‑CH V2 @typeCode cs 1 … 1 F COV hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.15 hl7:time IVL_TS.CH.TZ 0 … 1 Validity period of the contract. CDA‑CH V2 hl7:low TS.CH.TZ 1 … 1 R Start of the contract. CDA‑CH V2 hl7:high TS.CH.TZ 1 … 1 R End of the contract. CDA‑CH V2 hl7:associated​Entity 1 … 1 R CDA‑CH V2 @classCode cs 1 … 1 F PAYOR hl7:id II 1 … 1 R The id of the contract ([ge]: Versichertennummer; [fr]: Numéro d'assuré). CDA‑CH V2 @root uid 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   The id itself. It MUST be unique within the issuing system. hl7:code CE 1 … 1 R The underlying law for the contract. CDA‑CH V2 @nullFlavor cs 0 … 1 F NAV @code cs 0 … 1   832.10, 832.20, 221.229.1, 833.1, 831.20 @codeSystem oid 0 … 1 F 2.16.756.5.30.2.1.1.11 @codeSystemName st 0 … 1 F ins-laws @displayName st 0 … 1   Federal Act on Health Insurance (HIA), Federal Act on Accident Insurance (AIA), Federal Act on Insurance Policies (Insurance Policies Act, IPA), Federal Act on Military Insurance (MilIA), Federal Act on Invalidity Insurance (InvIA)   Schematron assert role  error     test (@nullFlavor='NAV' and not(@codeSystem or @codeSystemName or @code or @displayName)) or (@codeSystem='2.16.756.5.30.2.1.1.11' and @codeSystemName='ins-laws' and @code and @displayName)     Message Either a valid insurance law or nullFlavor="NAV" is REQUIRED.   hl7:associated​Person 0 … 1 Contact person at the insurance company. Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) CDA‑CH V2 hl7:scoping​Organization 1 … 1 The insurance company. Contains 2.16.756.5.30.1.1.10.9.26 Organization Compilation with GLN, name, addr and telecom (DYNAMIC) CDA‑CH V2 Included 0 … * from 2.16.756.5.30.1.1.10.2.13 Document Replacement - relatedDocument (DYNAMIC) hl7:relatedDocument 0 … * Relationship to another CDA-CH V2 based document that is replaced by the current one. Notes: For correction of wrong information, a new document that replaces the earlier document MUST be created. The new document corrects previously incorrect information. This also applies to the case where information in the CDA header has been corrected (e.g., if the original document has been issued to the wrong patient). While processing the new document at the recipient, all values from the previous document MUST be interpreted as deprecated (deleted/marked as deleted/deprecated) and all values in the new document MUST be marked as valid: Values that were only contained in the previous document have to be treated as deleted. Values that are present in both documents are overwritten with the contents of the new document. Values that are only contained in the new document are to be added. CDA‑CH V2 @typeCode cs 1 … 1 F RPLC   Indicates that it is a relationship to another document that needs to be replaced. hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.13 hl7:parentDocument 1 … 1 R Relationship to the document that needs to be replaced. CDA‑CH V2 hl7:id II 1 … 1 M The id of the document to be replaced MUST be declared. CDA‑CH V2 @root uid 1 … 1 R The id (GUID) of the document to be replaced. @extension st 0 NP NP/not present hl7:setId II 1 … 1 M The setId of the document to be replaced MUST be declared. CDA‑CH V2 @extension st 0 NP NP/not present @root uid 1 … 1 R The setId (GUID) of the document to be replaced and MUST be identical with the content of the setId of the current document.   Schematron assert role  error     test (@root=/hl7:ClinicalDocument/hl7:setId/@root) and not(@extension) and not(/hl7:ClinicalDocument/hl7:setId/@extension)     Message ClinicalDocument/setId: MUST be identical to the one of the replaced document   hl7:versionNumber INT 1 … 1 M The version number of the document to be replaced. CDA‑CH V2   Schematron assert role  error     test /hl7:ClinicalDocument/hl7:versionNumber/@value > @value     Message ClinicalDocument/versionNumber: MUST be higher than the one of the replaced document   hl7:component 1 … 1 R (CDA...-V1) hl7:structuredBody 1 … 1 R (CDA...-V1) hl7:component 1 … * M Main section for laboratory reports A laboratory report MUST contain at least one main chapter in the structured body element, which MAY contain one or more sub-chapters. No further nesting is allowed. Each main section (Laboratory Specialty Section) contains laboratory tests of a particular discipline (e.g., microbiology or serology) and MUST contain either text and entry elements or sub-chapter (Laboratory Report Item Section). In the first case, the human-readable text in the text element MUST be generated automatically from the entry and its sub-elements, and sub-chapters ARE NOT ALLOWED. In the second case, all subsections (Laboratory Report Item Sections) must contain the examination results. Contains 2.16.756.5.30.1.1.10.3.77 Laboratory Speciality Section - coded (DYNAMIC) (CDA...-V1) where [hl7:section [hl7:code [concat(@code, @codeSystem) = doc('include/voc-1.3.6.1.4.1.19376.1.3.11.1-DYNAMIC.xml')//valueSet [1]/conceptList/concept/concat(@code, @codeSystem)]]] hl7:component 0 … 1 Main section for vital signs A laboratory report MAY include a main section in the structuredBody element that contains vital signs of the patient (e.g., body temperature, body height and weight), if this is of particular interest to the interpretation of the laboratory results. Contains 2.16.756.5.30.1.1.10.3.4 Vital Signs Section - coded (DYNAMIC) (CDA...-V1) where [hl7:section [hl7:code [(@code = '8716-3' and @codeSystem = '2.16.840.1.113883.6.1') or @nullFlavor]]] hl7:component 0 … 1 Main section for coded results A laboratory report MAY include a main section in the structuredBody element that contains coded results of the patient (e.g., gestational age of the patient), if this is of particular interest to the interpretation of the laboratory results. Contains 2.16.756.5.30.1.1.10.3.46 Other Relevant Observations Section - coded (DYNAMIC) (CDA...-V1) where [hl7:section] hl7:component 0 … 1 Main section for a current pregnancy A laboratory report MAY include a main section in the structuredBody element that contains information about a current pregnancy of the patient (e.g., estimated delivery date), if this is of particular interest to the interpretation of the laboratory results. Contains 2.16.756.5.30.1.1.10.3.53 Current Pregnancy Section - coded (DYNAMIC) (CDA...-V1) where [hl7:section] hl7:component 0 … 1 Main section for original representation This section MAY be used to provide the original representation of the current CDA document as it has been seen by the legal authenticator while signing. Contains 2.16.756.5.30.1.1.10.3.45 Original Representation Section - coded (DYNAMIC) (CDA...-V1) where [hl7:section [hl7:code [(@code = '55108-5' and @codeSystem = '2.16.840.1.113883.6.1')]]]   Schematron assert role  warning     test not(//hl7:id[@root='2.16.756.5.30.1.127.3.10.3'])     Message This CDA-CH-LREP document contains a Swiss EPR-SPID. Please make sure, that this fits the legal base.     Schematron report role  warning     test //hl7:id[@root=('2.16.756.5.31', '2.16.756.5.32')]/parent::hl7:patientRole     Message This CDA-CH-LREP document contains a Swiss Social Security number as patient identifier. Please make sure, that this fits the legal base.     Schematron assert role  error     test not(//hl7:id[@root=('2.16.756.5.30.1.127.3.10.3', '2.16.756.5.31', '2.16.756.5.32')]/../..[not(hl7:patientRole)])     Message Swiss EPR-SPID and Social Security numbers are not allowed in CDA-CH-LREP documents for other objects than the patient.

CDA Header Level Templates

Author

Id	2.16.756.5.30.1.1.10.2.59	Effective Date	2018‑04‑19
Status	Under pre-publication review	Version Label	2018
Name	cdachlrep_header_Author	Display Name	Author
Description	Information about the author of the document. The author MAY be a person or a device. At least one author MUST be declared.
Context	Parent nodes of template element with id 2.16.756.5.30.1.1.10.2.59
Label	CDA‑CH‑LREP
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Uses	Uses 4 templates Uses as Name Version 2.16.756.5.30.1.1.10.9.35 Containment Address Information Compilation - eCH-0010 (2017) DYNAMIC 2.16.756.5.30.1.1.10.9.34 Containment Person Name Information Compilation - eCH-0011 (2017) DYNAMIC 2.16.756.5.30.1.1.10.9.21 Containment Device Compilation with name (2017) DYNAMIC 2.16.756.5.30.1.1.10.9.27 Containment Organization Compilation with name, addr, telecom (2017) DYNAMIC
Relationship	Specialization: template 2.16.756.5.30.1.1.10.9.23 Author (DYNAMIC) ref hl7chcda- Specialization: template 2.16.840.1.113883.10.12.102 CDA author (2005‑09‑07) ref ad1bbr-
Example	Sample author <author>   <templateId root="2.16.756.5.30.1.1.10.2.59"/>  <templateId root="2.16.756.5.30.1.1.10.9.23"/>  <functionCode nullFlavor="NAV">     <originalText>Laboratory technician</originalText>    <translation code="3212" codeSystem="2.16.840.1.113883.2.9.6.2.7" codeSystemName="ISCO-08" displayName="Medical and pathology laboratory technicians"/>  </functionCode>  <time value="20170905"/>  <assignedAuthor>     <id root="2.51.1.3" extension="7608888888888"/>    <assignedPerson>       <name>         <prefix>Dr. med.</prefix>        <given>Allzeit</given>        <family>Bereit</family>      </name>    </assignedPerson>    <representedOrganization>       <id root="2.51.1.3" extension="7609999999999"/>      <name>Gruppenpraxis CH</name>      <telecom value="tel:+41.32.234.55.66" use="WP"/>      <telecom value="fax:+41.32.234.55.67" use="WP"/>      <telecom value="mailto:bereit@gruppenpraxis.ch" use="WP"/>      <telecom value="http:www.gruppenpraxis.ch" use="WP"/>      <addr use="WP">         <streetName>Doktorgasse</streetName>        <houseNumber>2</houseNumber>        <city>Musterhausen</city>        <postalCode>8888</postalCode>        <country>CH</country>      </addr>    </representedOrganization>  </assignedAuthor></author>
Item DT Card Conf Description Label hl7:author 1 … * R Information about the author of the document. The author MAY be a person or a device. At least one author MUST be declared. CDA-...LREP hl7:templateId II 1 … 1 M CDA-...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.59 hl7:templateId II 1 … 1 M CDA-...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.9.23 hl7:functionCode CE 1 … 1 R The functionCode MUST be taken from the Swiss EPR Value-Set for author roles. See FDHA Ordinance on the Electronic Patient Record (EPRO-FDHA), Appendix 3: Metadata, Section 2.1. If the desired functionCode is not available in the Swiss EPR Value-Set for author roles, nullFlavor='NAV' MUST be used. In this case, the originalText element MUST contain the description of the role. Translations to other vocabularies are allowed. CDA-...LREP @nullFlavor st 0 … 1 F NAV @code cs 0 … 1   @codeSystem oid 0 … 1 F 2.16.840.1.113883.6.96 @codeSystemName st 0 … 1 F SNOMED CT @displayName st 0 … 1     CONF The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.1.3 DocumentEntry.authorRole (DYNAMIC)   Example <functionCode code="106292003" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Professional nurse"/>   Example <functionCode nullFlavor="NAV">   <originalText>Home helper</originalText></functionCode>   Example <functionCode nullFlavor="NAV">   <originalText>Laboratory technician</originalText>  <translation code="3212" codeSystem="2.16.840.1.113883.2.9.6.2.7" codeSystemName="ISCO-08" displayName="Medical and pathology laboratory technicians"/></functionCode>   Schematron assert role  error     test (@code and @codeSystem) or (@nullFlavor='NAV')     Message Either a code with its code system or nullFlavor='NAV' is required.     Schematron assert role  error     test not(@nullFlavor) or (hl7:originalText)     Message Other Caregivers description MUST be declared in the originalText element in case of nullFlavor.   hl7:translation 0 … * A translation of the code to another coding system (e.g. ISCO-08: 2.16.840.1.113883.2.9.6.2.7) CDA-...LREP @code cs 1 … 1 R @codeSystem oid 1 … 1 R @codeSystemName st 1 … 1 R @displayName st 1 … 1 R hl7:translation 0 … 1 Use this translation when the author is the patient itself (e.g. by reporting a self medication or a medical problem). CDA-...LREP @code cs 1 … 1 F 116154003 @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.96 @codeSystemName st 1 … 1 F SNOMED CT @displayName st 1 … 1 F Patient (person) hl7:time TS.CH.TZ 1 … 1 R Date and time of the laboratory report creation. CDA-...LREP hl7:assignedAuthor 1 … 1 R CDA-...LREP   Schematron assert role  error     test not(hl7:assigned​Authoring​Device/hl7:softwareName) or (hl7:represented​Organization)     Message For device authors the element representedOrganization is REQUIRED.     Schematron assert role  error     test (hl7:telecom[@use='PUB' and starts-with(@value,'tel:+')]) and (hl7:telecom[@use='PUB' and starts-with(@value,'mailto:')])     Message A public telephone number in the international format and a public eMail address are required.     Schematron assert role  error     test (hl7:addr[@use='PUB'])     Message A public address is required.   hl7:id II 1 … 1 R The specification of GS1 GLN is REQUIRED. If it is not (yet) known, this MUST be declared using nullFlavor. For persons: their personal GLN MUST be declared. For devices or software modules: the GLN of their organization MUST be declared. CDA-...LREP @nullFlavor cs 0 … 1 F NAV   Temporarily unknown, will be filled later. @root cs 0 … 1 F 2.51.1.3   OID for GS1 GLN. @extension st 0 … 1   The GS1 GLN.   Schematron assert role  error     test (@root='2.51.1.3' and @extension) or (@nullFlavor='NAV')     Message Either the GS1 GLN or nullFlavor='NAV' is REQUIRED   hl7:id II 0 … * Other ids are allowed. CDA-...LREP @root cs 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   The id itself. It MUST be unique within the issuing system. hl7:addr AD 1 … * Address of the laboratory. Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC) CDA-...LREP hl7:telecom TEL 1 … * Means of communication of the laboratory (phone, eMail, ...). CDA-...LREP Choice 1 … 1 Elements to choose from: hl7:assigned​Person containing template 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) hl7:assigned​Authoring​Device containing template 2.16.756.5.30.1.1.10.9.21 Device Compilation with name (DYNAMIC) hl7:assigned​Person 0 … 1 The author as a person. Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) CDA-...LREP hl7:assigned​Authoring​Device 0 … 1 The author as a device. Contains 2.16.756.5.30.1.1.10.9.21 Device Compilation with name (DYNAMIC) CDA-...LREP hl7:represented​Organization 0 … 1 The author's organization. Contains 2.16.756.5.30.1.1.10.9.27 Organization Compilation with name, addr, telecom (DYNAMIC) CDA-...LREP   Schematron assert role  error     test /hl7:ClinicalDocument/hl7:author/hl7:functionCode/hl7:translation[@code='3212' and @codeSystem='2.16.840.1.113883.2.9.6.2.7']     Message At least one of the listed authors MUST be a laboratory specialist.

Custodian

Id	2.16.756.5.30.1.1.10.2.60	Effective Date	2018‑04‑19
Status	Under pre-publication review	Version Label	2018
Name	cdachlrep_header_Custodian	Display Name	Custodian
Description The laboratory that creates the document MUST be declared as Custodian. The GLN is the primary key and thus the unique identification of the laboratory. If the lab services are to be refunded by the insurance, the SASIS number (ge:ZSR / fr:RCC) MUST be declared in the same element as the GLN as follows.
Context	Parent nodes of template element with id 2.16.756.5.30.1.1.10.2.60
Label	CDA‑CH‑LREP
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Uses	Uses 1 template Uses as Name Version 2.16.756.5.30.1.1.10.9.35 Containment Address Information Compilation - eCH-0010 (2017) DYNAMIC
Relationship	Specialization: template 2.16.756.5.30.1.1.10.2.3 Custodian (DYNAMIC) ref hl7chcda-
Example	Example <custodian>   <templateId root="2.16.756.5.30.1.1.10.2.3"/>  <templateId root="2.16.756.5.30.1.1.10.2.60"/>  <assignedCustodian>     <representedCustodianOrganization>       <id root="2.51.1.3" extension="7606666666666"/>      <name use="L">Labor Pipette</name>      <telecom use="PUB" value="tel:+41.33.123.45.67"/>      <addr use="PUB">         <streetName>Reagenziumstrasse</streetName>        <houseNumber>321</houseNumber>        <postalCode>8888</postalCode>        <city>Analyzerstadt</city>        <country>CH</country>      </addr>    </representedCustodianOrganization>  </assignedCustodian></custodian>
Item DT Card Conf Description Label hl7:custodian 1 … 1 R CDA-...LREP hl7:templateId II 1 … 1 M CDA-...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.3 hl7:templateId II 1 … 1 M CDA-...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.60 hl7:assignedCustodian 1 … 1 R CDA-...LREP hl7:represented​Custodian​Organization 1 … 1 R CDA-...LREP   Schematron assert role  error     test (hl7:telecom[@use='PUB' and starts-with(@value,'tel:+')])     Message A public telephone number in the international format is required.     Schematron assert role  error     test (hl7:addr[@use='PUB'])     Message A public address is required.   hl7:id II 1 … * R The specification of GS1 GLN is required. If it is not (yet) known, this must be declared using nullFlavor. CDA-...LREP @nullFlavor cs 0 … 1 F NAV   Temporarily unknown, will be filled later. @root cs 0 … 1 F 2.51.1.3   OID for GS1 GLN @extension st 0 … 1   The GS1 GLN of the laboratory or the doctor's office (in the case of individual practices, the doctor's GLN).   Schematron assert role  error     test (@root='2.51.1.3' and @extension) or (@nullFlavor='NAV')     Message Either the GS1 GLN or nullFlavor='NAV' is required.   hl7:id II 0 … * C SASIS number (ge:ZSR / fr:RCC), if the lab services are to be refunded by the insurance. CDA-...LREP @root cs 1 … 1 F 2.16.756.5.30.1.123.100.2.1.1   OID for SASIS number (ge:ZSR / fr:RCC). @extension st 1 … 1 R SASIS number (ge:ZSR / fr:RCC) of the laboratory or the physician. hl7:name ON 1 … 1 R Name of the laboratory. CDA-...LREP hl7:telecom TEL 1 … * R Means of communication of the laboratory (phone., eMail, ...). CDA-...LREP hl7:addr AD 1 … * R Address of the laboratory. Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC) CDA-...LREP

Data Enterer

Id	2.16.756.5.30.1.1.10.2.7 ref hl7chcda-	Effective Date	2018‑04‑18
Status	Active	Version Label	2017
Name	cdach_header_DataEnterer	Display Name	Data Enterer
Description Information about the person that entered information in this CDA document. It SHALL be declared, when data recorded in this document has been entered by a person other than the author but only when this is relevant for some reason. All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST reference this template.
Context	Parent nodes of template element with id 2.16.756.5.30.1.1.10.2.7
Label	CDA‑CH V2
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Uses	Uses 1 template Uses as Name Version 2.16.756.5.30.1.1.10.9.12 Containment Assigned Entity Compilation with id (2017) DYNAMIC
Relationship	Specialization: template 2.16.840.1.113883.10.12.103 CDA dataEnterer (2005‑09‑07) ref ad1bbr-
Example	Example <dataEnterer>   <templateId root="2.16.756.5.30.1.1.10.2.7"/>  <time value="201709122029+0200"/>  <assignedEntity>     <id root="2.999" extension="0812763"/>    <assignedPerson>       <name>         <given>Jean</given>        <family>Dupont</family>      </name>    </assignedPerson>  </assignedEntity></dataEnterer>
Item DT Card Conf Description Label hl7:dataEnterer 0 … 1 Information about the person that entered information in this CDA document. It SHALL be declared, when data recorded in this document has been entered by a person other than the author but only when this is relevant for some reason. CDA‑CH V2 hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.7 hl7:time TS.CH.TZ 0 … 1 Timestamp of the data input. CDA‑CH V2 hl7:assignedEntity 1 … 1 R Contains 2.16.756.5.30.1.1.10.9.12 Assigned Entity Compilation with id (DYNAMIC) CDA‑CH V2

Document Code

Id	2.16.756.5.30.1.1.10.2.56	Effective Date	2018‑04‑19
Status	Under pre-publication review	Version Label	2018
Name	cdachlrep_header_DocumentCode	Display Name	Document Code
Description A LOINC based document type of a CDA document instance including a translation to the Swiss EPR XDS.b metadata. Multidisciplinary laboratory findings: The LOINC code of the document MUST read: 11502-2 (LABORATORY REPORT.TOTAL) Laboratory reports of a single laboratory discipline: The LOINC code of the document MUST be taken from the value set 'Laboratory Specialties'
Context	Pathname
Label	IHE PalM TF3 Rev.8, 6.3.2.5
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Relationship	Specialization: template 2.16.756.5.30.1.1.10.2.44 Document Code (DYNAMIC) ref hl7chcda-
Example	Laboratory Reports, CDA-CH-LREP V1, General laboratory report <!-- IHE XD-LAB defines the valid document codes --> <code code="11502-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="LABORATORY REPORT.TOTAL">   <!-- Mapping to the Swiss EPR XDS.b metadata accorting to the Value-Set EprDocumentTypeCode (201704.1-beta; 2.16.756.5.30.1.127.3.10.1.27) -->   <translation code="4241000179101" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Laboratory report"/></code>
Item DT Card Conf Description Label hl7:code CE 1 … 1 M A LOINC based document type of a CDA document instance including a translation to the Swiss EPR XDS.b metadata. Multidisciplinary laboratory findings: The LOINC code of the document MUST read: 11502-2 (LABORATORY REPORT.TOTAL) Laboratory reports of a single laboratory discipline: The LOINC code of the document MUST be taken from the value-set 'Laboratory Specialties' IHE PalM TF3 Rev.8, 6.3.2.5 @code cs 1 … 1 R The exact value of @code MUST either read '11502-2' or taken from the value-set 'Laboratory Specialties'. @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.1 @codeSystemName st 1 … 1 F LOINC @displayName st 1 … 1 R The exact value of @displayName MUST either read 'LABORATORY REPORT.TOTAL' or taken from the value-set 'Laboratory Specialties'.   CONF The value of @code shall be drawn from value set 1.3.6.1.4.1.19376.1.3.11.6 Multi-disciplinary Laboratory Report (DYNAMIC) or The value of @code shall be drawn from value set 1.3.6.1.4.1.19376.1.3.11.1 Laboratory Specialties (DYNAMIC) hl7:translation CD 1 … 1 R The translation to the Swiss EPR XDS.b metadata attribute typeCode. IHE PalM TF3 Rev.8, 6.3.2.5 @code cs 1 … 1 F 4241000179101 @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.96 @codeSystemName st 1 … 1 F SNOMED CT @displayName st 1 … 1 F Laboratory report   CONF The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.27 DocumentEntry.typeCode (DYNAMIC)

Document Confidentiality Code

Id	2.16.756.5.30.1.1.10.2.19 ref hl7chcda-	Effective Date	2018‑04‑18
Status	Active	Version Label	2017
Name	cdach_header_DocumentConfidentialityCode	Display Name	Document Confidentiality Code
Description A confidentiality level of a CDA document instance according to the Swiss EPR regulation. All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST reference this template. Language dependent references to the Swiss EPR regulation: en: Federal Act on the Electronic Patient Record (EPRA), FDHA Ordinance on the Electronic Patient Record (EPRO-FDHA), Appendix 3 (Metadata) de: Bundesgesetz über das elektronische Patientendossier (EPDG), Verordnung des EDI über das elektronische Patientendossier (EPDV-EDI), Anhang 3 (Metadaten) fr: Loi fédérale sur le dossier électronique du patient (LDEP), Ordonnance du DFI sur le dossier électronique du patient (ODEP-DFI), Annexe 3 (Métadonnées) it: Legge federale sulla cartella informatizzata del paziente (LCIP), Ordinanza del DFI sulla cartella informatizzata del paziente (OCIP-DFI), Allegato 3 (Metadati)
Label	CDA‑CH V2
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Associated with	Associated with 1 concept Id Name Data Set hl7chcda-data​element-222  Confidentiality level  CDA-CH V2 2017
Example	Example <confidentialityCode code="1051000195109" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="normal"/>
Item DT Card Conf Description Label hl7:confidentialityCode CE (required) 1 … 1 M Swiss Realm of Confidentiality Code according to the Swiss EPR regulation. CDA‑CH V2   hl7chcda-data​element-222  Confidentiality level  CDA-CH V2 2017 @code cs 1 … 1 R The value of @code MUST be drawn from value set EprDocumentConfidentialityCode (2.16.756.5.30.1.127.3.10.1.5) @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.96 @codeSystemName st 1 … 1 F SNOMED CT @displayName st 1 … 1 R The value of @displayName MUST be drawn from value set EprDocumentConfidentialityCode (2.16.756.5.30.1.127.3.10.1.5)   CONF The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.5 DocumentEntry.confidentialityCode (DYNAMIC)

Document Id

Id	2.16.756.5.30.1.1.10.2.23 ref hl7chcda-	Effective Date	2018‑04‑18
Status	Active	Version Label	2017
Name	cdach_header_DocumentId	Display Name	Document Id
Description	A unique identifier for each CDA document instance. All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST reference this template.
Label	CDA‑CH V2
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Associated with	Associated with 1 concept Id Name Data Set hl7chcda-data​element-217  Identification number of the document  CDA-CH V2 2017
Example	Example <id root="807563C2-5146-11D5-A672-00B0D022E945"/>
Item DT Card Conf Description Label hl7:id II 1 … 1 M A unique identifier for each CDA document instance. CDA‑CH V2   hl7chcda-data​element-217  Identification number of the document  CDA-CH V2 2017 @root uid 1 … 1 R The document's id as Globally Unique Identifier (GUID). @extension st 0 NP NP/not present

Document Language

Id	2.16.756.5.30.1.1.10.2.22 ref hl7chcda-	Effective Date	2018‑04‑18
Status	Active	Version Label	2017
Name	cdach_header_DocumentLanguage	Display Name	Document Language
Description The RFC 1766 (ISO-639-1 and ISO 3166) based language in which the narrative texts in this CDA document instance are written. All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST reference this template.
Label	CDA‑CH V2
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Associated with	Associated with 1 concept Id Name Data Set hl7chcda-data​element-219  Language of the document  CDA-CH V2 2017
Example	US-English <languageCode code="en-US"/>
Example	Swiss-German <languageCode code="de-CH"/>
Example	Swiss-French <languageCode code="fr-CH"/>
Example	Swiss-Italian <languageCode code="it-CH"/>
Item DT Card Conf Description Label hl7:language​Code CS 1 … 1 M The RFC 1766 (ISO-639-1 and ISO 3166) based language in which the narrative texts in this CDA document instance are written. CDA‑CH V2   hl7chcda-data​element-219  Language of the document  CDA-CH V2 2017   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.11526 HumanLanguage (DYNAMIC)

Document Realm

Id	2.16.756.5.30.1.1.10.2.25 ref hl7chcda-	Effective Date	2018‑04‑18
Status	Active	Version Label	2017
Name	cdach_header_DocumentRealm	Display Name	Document Realm
Description	Swiss Realm (CHE) of HL7 CDA. All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST reference this template.
Label	CDA‑CH V2
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Example	Example <realmCode code="CHE"/>
Item DT Card Conf Description Label hl7:realmCode CS 1 … 1 M Swiss Realm (CHE) of HL7 CDA. CDA‑CH V2 @code CONF 1 … 1 F CHE

Document Replacement - relatedDocument

Id	2.16.756.5.30.1.1.10.2.13 ref hl7chcda-	Effective Date	2019‑01‑01 21:22:58 Other versions this id: cdach_header_DocumentReplacement as of 2018‑04‑18
Status	Draft	Version Label	2019
Name	cdach_header_DocumentReplacement	Display Name	Document Replacement - relatedDocument
Description	Relationship to another CDA-CH V2 based document that is replaced by the current one. All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST reference this template.
Context	Parent nodes of template element with id 2.16.756.5.30.1.1.10.2.13
Label	CDA‑CH V2
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Relationship	Specialization: template 2.16.840.1.113883.10.12.111 CDA relatedDocument (2005‑09‑07) ref ad1bbr-
Example	Example <relatedDocument typeCode="RPLC">   <templateId root="2.16.756.5.30.1.1.10.2.13"/>  <parentDocument>     <id root="30E19F60-3DB9-48B8-9BFD-FF04C342D0B1"/>    <setId root="452A118A-06AB-47D2-A29B-709F7F2EC6FE"/>    <versionNumber value="5"/>  </parentDocument></relatedDocument>
Item DT Card Conf Description Label hl7:relatedDocument 0 … * Relationship to another CDA-CH V2 based document that is replaced by the current one. Notes: For correction of wrong information, a new document that replaces the earlier document MUST be created. The new document corrects previously incorrect information. This also applies to the case where information in the CDA header has been corrected (e.g., if the original document has been issued to the wrong patient). While processing the new document at the recipient, all values from the previous document MUST be interpreted as deprecated (deleted/marked as deleted/deprecated) and all values in the new document MUST be marked as valid: Values that were only contained in the previous document have to be treated as deleted. Values that are present in both documents are overwritten with the contents of the new document. Values that are only contained in the new document are to be added. CDA‑CH V2 @typeCode cs 1 … 1 F RPLC   Indicates that it is a relationship to another document that needs to be replaced. hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.13 hl7:parentDocument 1 … 1 R Relationship to the document that needs to be replaced. CDA‑CH V2 hl7:id II 1 … 1 M The id of the document to be replaced MUST be declared. CDA‑CH V2 @root uid 1 … 1 R The id (GUID) of the document to be replaced. @extension st 0 NP NP/not present hl7:setId II 1 … 1 M The setId of the document to be replaced MUST be declared. CDA‑CH V2 @extension st 0 NP NP/not present @root uid 1 … 1 R The setId (GUID) of the document to be replaced and MUST be identical with the content of the setId of the current document.   Schematron assert role  error     test (@root=/hl7:ClinicalDocument/hl7:setId/@root) and not(@extension) and not(/hl7:ClinicalDocument/hl7:setId/@extension)     Message ClinicalDocument/setId: MUST be identical to the one of the replaced document   hl7:versionNumber INT 1 … 1 M The version number of the document to be replaced. CDA‑CH V2   Schematron assert role  error     test /hl7:ClinicalDocument/hl7:versionNumber/@value > @value     Message ClinicalDocument/versionNumber: MUST be higher than the one of the replaced document

Document Set Id and Version Number

Id	2.16.756.5.30.1.1.10.2.20 ref hl7chcda-	Effective Date	2018‑04‑18
Status	Active	Version Label	2017
Name	cdach_header_DocumentSetIdAndVersionNumber	Display Name	Document Set Id and Version Number
Description	Unity of document versions. All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST reference this template.
Label	CDA‑CH V2
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Associated with	Associated with 1 concept Id Name Data Set hl7chcda-data​element-223  Version  CDA-CH V2 2017
Example	Version 1 <!-- For information only (see 'Document Id' template for more information): /ClinicalDocument/id/@root="807563C2-5146-11D5-A672-00B0D022E945" (equal to setId) --> <setId root="807563C2-5146-11D5-A672-00B0D022E945"/><versionNumber value="1"/>
Example	Version 2 <!-- For information only (see 'Document Id' template for more information): /ClinicalDocument/id/@root="FD05DCA1-14A9-4AAE-B57E-6B28E621D853" (not equal to setId)--> <setId root="807563C2-5146-11D5-A672-00B0D022E945"/><versionNumber value="2"/>
Item DT Card Conf Description Label hl7:setId II 1 … 1 R The setId element MUST match the document id of the very first version of that document. It MUST remain the same for all document versions. CDA‑CH V2 @root uid 1 … 1 R The root attribute MUST contain the setId as Globally Unique Identifier (GUID). @extension st 0 NP NP/not present   Schematron assert role  error     test (parent::*/hl7:versionNumber[@value='1'] and @root=parent::*/hl7:id/@root and (@extension=parent::*/hl7:id/@extension or (not(@extension) and not(parent::*/hl7:id/@extension)))) or (parent::*/hl7:versionNumber[not(@value ='1')] and ((@root=parent::*/hl7:id/@root and @extension and not(@extension=parent::*/hl7:id/@extension)) or(not(@root=parent::*/hl7:id/@root))))     Message The setId MUST be equal with the document id for version 1 and it MUST differ for all other versions.   hl7:versionNumber INT.​NONNEG 1 … 1 R The versionNumber element MUST contain the value 1 for the very first version of that document. For later versions, the version number MUST be increased by 1 each. CDA‑CH V2   hl7chcda-data​element-223  Version  CDA-CH V2 2017

Document Template Ids CDA-CH v2.0 - structuredBody

Id	2.16.756.5.30.1.1.10.2.18 ref hl7chcda-	Effective Date	2018‑04‑18
Status	Active	Version Label	2017
Name	cdach_header_DocumentTemplateIdsCdaChv2.0-structuredBody	Display Name	Document Template Ids CDA-CH v2.0 - structuredBody
Description CDA-CH V2 bases on HL7 CDA R2 (2005) and - by using this template - require a structured body. All CDA-CH V2 derivatives, i.e. Swiss exchange formats SHALL reference this template. These SHALL define further template ids in their own separate templates.
Label	CDA‑CH V2
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Example	Example <!-- CDA-CH v2.0 specification (optional, but informative template id). --> <templateId root="2.16.756.5.30.1.1.1.1.4"/><!-- HL7 CDA R2 (2005) having a structuredBody. --> <templateId root="2.16.840.1.113883.10.12.2"/><!-- HL7 CDA R2 (2005). --> <templateId root="2.16.840.1.113883.10.12.1"/>
Item DT Card Conf Description Label hl7:templateId II 0 … 1 CDA-CH v2.0 specification. This is an informational reference, only. CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.1.1.4 hl7:templateId II 1 … 1 M HL7 CDA R2 (2005); contains ClinicalDocument.component as structuredBody. CDA‑CH V2 @root uid 1 … 1 F 2.16.840.1.113883.10.12.2 hl7:templateId II 1 … 1 M HL7 CDA R2 (2005). CDA‑CH V2 @root uid 1 … 1 F 2.16.840.1.113883.10.12.1

Document Template Ids CDA-CH-LREP V1

Id	2.16.756.5.30.1.1.10.2.55	Effective Date	2018‑04‑19
Status	Under pre-publication review	Version Label	2018
Name	cdachlrep_header_TemplateIdsCdaChLrepV1	Display Name	Document Template Ids CDA-CH-LREP V1
Description	CDA-CH-LREP V1 bases on CDA-CH V2 (2017) and XD-LAB (IHE PaLM TF 8.0, 2017).
Context	Pathname
Label	CDA‑CH‑LREP
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Example	Example <ClinicalDocument>   <!-- ... -->   <templateId root="2.16.756.5.30.1.1.1.1.3.9.1"/>  <templateId root="2.16.756.5.30.1.127.1.4"/>  <templateId root="1.3.6.1.4.1.19376.1.3.3"/>  <!-- ... --> </ClinicalDocument>
Item DT Card Conf Description Label hl7:templateId II 0 … 1 CDA-CH-LREP / Laboratory Reports V1 specification. This is an informational reference, only. CDA-...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.1.1.3.9.1 hl7:templateId II 1 … 1 M Exchange format according to the Swiss EPR CDA-...LREP @root uid 1 … 1 F 2.16.756.5.30.1.127.1.4 hl7:templateId II 1 … 1 M Sharing Laboratory Reports (XD-LAB) Content Module, IHE PaLM Technical Framework Revision Revision 8.0 - June 21, 2017. CDA-...LREP @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.3.3

Document Title

Id	2.16.756.5.30.1.1.10.2.62	Effective Date	2018‑04‑19
Status	Under pre-publication review	Version Label	2018
Name	cdachlrep_header_DocumentTitle	Display Name	Document Title
Description The document MUST contain a title. The following translations of the LOINC codes specified in XD-LAB MUST be used: Multidisciplinary reports LOINC Code Text 11502-2 [ge]: Multidisziplinäre Befunde [fr]: Résultats multidisciplinaires [it]: Risultati multidisciplinari Findings of a particular discipline The same translations as for Laboratory Speciality Section are to be used.
Context	Pathname
Label	CDA‑CH‑LREP
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Example	Multidisciplinary laboratory report in German <title>Laborbefund - Multidisziplinäre Befunde</title>
Example	Multidisciplinary laboratory report in English <title>Laboratory report - Multidisciplinary Laboratory Report</title>
Example	Serology report German <title>Laborbefund - Serologiebefunde</title>
Example	Serology report Englisch <title>Laboratory report - Serologiebefunde</title>
Item DT Card Conf Description Label hl7:title ST 1 … 1 M The document title must follow the following text format where <human readable code> is the local translation of the document LOINC code: [de]: 'Laborbefund - <human readable code>' [fr]: 'Rapport de laboratoire - <human readable code>' [it]: 'Referto di laboratorio - <human readable code>' [en]: 'Laboratory report - <human readable code>' CDA-...LREP   Variable let Name languageCode     Value substring(/hl7:ClinicalDocument/hl7:language​Code/@code,1,2)     Schematron assert role  error     test not($languageCode='en') or starts-with(text(),'Laboratory report')     Message The English title must start with 'Laboratory report'     Schematron assert role  error     test not($languageCode='de') or starts-with(text(),'Laborbefund')     Message The German title must start with 'Laborbefund'     Schematron assert role  error     test not($languageCode='fr') or starts-with(text(),'Rapport de laboratoire')     Message The French title must start with 'Rapport de laboratoire'     Schematron assert role  error     test not($languageCode='it') or starts-with(text(),'Rapporto di laboratorio')     Message The Italian title must start with 'Rapporto di laboratorio'

Health Service - documentationOf

Id	2.16.756.5.30.1.1.10.2.46 ref hl7chcda-	Effective Date	2019‑01‑01 20:53:33 Other versions this id: cdach_header_HealthService as of 2018‑04‑18
Status	Draft	Version Label	2019
Name	cdach_header_HealthService	Display Name	Health Service - documentationOf
Description	Information about a health service describing the context of this CDA document. All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST use this template by either reference or specialisation.
Context	Parent nodes of template element with id 2.16.756.5.30.1.1.10.2.46
Label	CDA‑CH V2
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Uses	Uses 1 template Uses as Name Version 2.16.756.5.30.1.1.10.9.31 Include Performer (2017) DYNAMIC
Relationship	Specialization: template 2.16.840.1.113883.10.12.110 CDA documentationOf (2005‑09‑07) ref ad1bbr-
Example	Case identification and duration <documentationOf typeCode="DOC">   <templateId root="2.16.756.5.30.1.1.10.2.46"/>  <serviceEvent classCode="ACT" moodCode="EVN">     <id root="2.999" extension="FID-124982"/>    <code nullFlavor="NAV"/>    <effectiveTime>       <low value="20190101"/>      <high value="20190102"/>    </effectiveTime>  </serviceEvent></documentationOf>
Item DT Card Conf Description Label hl7:documentationOf 0 … * Information about a health service describing the context of this CDA document. CDA‑CH V2 @typeCode cs 1 … 1 F DOC hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.46 hl7:serviceEvent 1 … 1 R CDA‑CH V2 @classCode cs 1 … 1 F ACT @moodCode cs 1 … 1 F EVN hl7:id II 0 … * Health service identifiers such as case number ([ge]: Fallnummer; [fr]: Numéro de cas), consultation id, episode id, etc. CDA‑CH V2 @root uid 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   The id itself. It MUST be unique within the issuing system. hl7:code CE 1 … 1 R As long as the eventCodeList for the Swiss EPR metadata is not defined yet by the FDHA Ordinance on the Electronic Patient Record (EPRO-FDHA), the nullFlavor='NAV' MUST be used in this template. Other codes MAY be declared as translation. CDA‑CH V2 @nullFlavor st 1 … 1 F NAV @code cs 0 NP NP/not present @codeSystem oid 0 NP NP/not present @codeSystemName st 0 NP NP/not present @displayName st 0 NP NP/not present hl7:translation 0 … * A translation of the code to another coding system. CDA‑CH V2 @code cs 1 … 1 R @codeSystem oid 1 … 1 R @codeSystemName st 1 … 1 R @displayName st 1 … 1 R hl7:effectiveTime IVL_TS.CH.TZ 1 … 1 R Duration of the health service. CDA‑CH V2 hl7:low TS.CH.TZ 1 … 1 R Start of the health service. CDA‑CH V2 hl7:high TS.CH.TZ 1 … 1 R End of the health service. CDA‑CH V2 Included 0 … * from 2.16.756.5.30.1.1.10.9.31 Performer (DYNAMIC) hl7:performer 0 … * Information about a healthcare provider who was the primary performer of the act. CDA‑CH V2 @typeCode cs 1 … 1 F PRF hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.9.31 hl7:templateId 1 … 1 R CDA‑CH V2 @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.5.3.1.1.24.3.5 hl7:time IVL_TS.CH.TZ 0 … 1 Duration of the performance. CDA‑CH V2 hl7:low TS.CH.TZ 1 … 1 R Start of the performance. CDA‑CH V2 hl7:high TS.CH.TZ 1 … 1 R End of the performance. CDA‑CH V2 hl7:assignedEntity 1 … 1 R Contains 2.16.756.5.30.1.1.10.9.32 Assigned Entity Compilation with id, name, addr, telecom, person and organization (DYNAMIC) CDA‑CH V2

Human Patient - recordTarget

Id	2.16.756.5.30.1.1.10.2.58	Effective Date	2018‑04‑19
Status	Under pre-publication review	Version Label	2018
Name	cdachlrep_header_Patient	Display Name	Human Patient - recordTarget
Description Patient (Human Patient). Patient identifiers The id (patient identification number) can be declared multiple times. If multiple identifications are known, all known IDs should be specified. For laboratory reports, all IDs specified by the ordering system are to be returned. This allows the receiver to assign its internal patient identification. OIDs of code systems, which are published in the public OID registry for the Swiss health care system (oid.refdata.ch) are REQUIRED. Others are NOT ALLOWED. Pseudonymization In special cases, the demographic data of the patient need not be transmitted or they need to be pseudonymized (e.g., results of genetic or forensic toxicology). The affected values must be replaced by a nullFlavor of type "MSK" (masked), in order to shield the data.
Context	Parent nodes of template element with id 2.16.756.5.30.1.1.10.2.58
Label	CDA‑CH‑LREP
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Uses	Uses 1 template Uses as Name Version 2.16.756.5.30.1.1.10.9.35 Containment Address Information Compilation - eCH-0010 (2017) DYNAMIC
Relationship	Specialization: template 2.16.840.1.113883.10.12.101 CDA recordTarget (2005‑09‑07) ref ad1bbr-
Example	Pseudonymization with initials <recordTarget>   <templateId root="2.16.756.5.30.1.1.10.2.58"/>  <templateId root="2.16.756.5.30.1.1.10.2.1"/>  <patientRole>     <id nullFlavor="MSK"/>    <addr nullFlavor="MSK"/>    <telecom nullFlavor="MSK"/>    <patient>       <name nullFlavor="MSK">         <family>(only first letter)</family>        <given>(only first letter)</given>      </name>      <administrativeGenderCode nullFlavor="MSK"/>      <birthTime nullFlavor="MSK"/>    </patient>  </patientRole></recordTarget>
Item DT Card Conf Description Label hl7:recordTarget 1 … * R Patient (Human Patient). CDA-...LREP hl7:templateId II 1 … 1 M CDA-...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.58 hl7:templateId II 1 … 1 M CDA-...LREP @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.1 hl7:patientRole 1 … 1 R Exactly one patient MUST be declared. CDA-...LREP hl7:id II 1 … * R At least one patient identification MUST be declared. CDA-...LREP @root uid 1 … 1 R MUST contain the OID of the system that issued the ID. OIDs of code systems, which are published in the public OID registry for the Swiss health care system (oid.refdata.ch) are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   Contains the patient number itself. The number MUST be unique within the system that has issued the number. hl7:addr AD 1 … * R All persons (including patients) and organizations, MUST according to XD-LAB contain name, addr and telecom. Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC) CDA-...LREP hl7:telecom TEL 1 … * R All persons (including patients) and organizations, MUST according to XD-LAB contain name, addr and telecom. CDA-...LREP hl7:patient 1 … 1 R Exactly one patient MUST be declared. CDA-...LREP hl7:name PN 1 … * R All persons (including patients) and organizations, MUST according to XD-LAB contain name, addr and telecom. CDA-...LREP hl7:administrative​Gender​Code CE 1 … 1 R The sex of the patient MUST be indicated according to XD-LAB. CDA-...LREP   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.1 AdministrativeGender (DYNAMIC) hl7:birthTime TS 1 … 1 R The date of birth of the patient MUST be given according to XD-LAB. CDA-...LREP

Human Patient with Non-Human Subject - recordTarget

Id	2.16.756.5.30.1.1.10.2.27 ref ch-palm-	Effective Date	2017‑06‑21
Status	Under pre-publication review	Version Label	2017
Name	chpalm_header_RecordTargetHumanPatientWithNonHumanSubject	Display Name	Human Patient with Non-Human Subject - recordTarget
Description ClinicalDocument/recordTarget SHALL be present and SHALL conform to the Human Patient, Non-Human Subject or Human Patient with Non-Human Subject templates defined below. There are three varieties of laboratory reports: Human (patient): The document reports laboratory observations produced on specimens collected exclusively from the patient. Non-Human Subject: The document reports laboratory observations produced on specimens collected from a non-human material (e.g. water, milk…) or living subject (e.g. animal). Human (patient) paired with Non-Human Subject: The document reports laboratory observations produced on a non-human specimen with a relationship to a human patient, (e.g. peanut butter eaten by a patient, a ferret that bit a patient). Human Patient with Non-Human Subject When the report assembles observations for a human (patient) with observations produced using a non-human specimen, the recordTarget SHALL represent the human patient. In accordance with the HL7 CDA R2 standard and further constrained by this specification, the presence of name, addr and telecom is required for all entities in the document including the human patient. Additionally, the following SHALL be present. "1.3.6.1.4.1.19376.1.3.3.1.3" <templateId root="1.3.6.1.4.1.19376.1.3.3.1.3"/> - The templateId element identifies this recordTarget as a human patient directly impacted by a non-human subject of laboratory testing. The templateId SHALL have root="1.3.6.1.4.1.19376.1.3.3.1.3". <id/> - recordTarget/patientRole/id SHALL be present. It SHALL be representative of the id of the human patient. In this template, the id of the non-human subject is not provided in the header. On a special note, at present, if the document contains a patient and a subject (as in the case of rabies, for example), documentation of the id of the subject cannot be accomplished without an extension to CDA. <administrativeGenderCode/> - The patientRole/patient/administrativeGenderCode SHALL be present. <birthTime/> - The patientRole/patient/birthTime SHALL be present. <structuredBody> mark-up - In addition to the elements specified in the CDA header for the patient, the non-human subject SHALL be represented in a Subject element in level 3 entries in the structuredBody as described in template Non-Human Subject 1.3.6.1.4.1.19376.1.3.3.1.2.1.
Context	Parent nodes of template element with id 2.16.756.5.30.1.1.10.2.27
Label	IHE PalM TF3 Rev.8, 6.3.2.11.3
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Relationship	Specialization: template 2.16.840.1.113883.10.12.101 CDA recordTarget (2005‑09‑07) ref ad1bbr- Specialization: template 1.3.6.1.4.1.19376.1.3.3.1.3 Human Patient with Non-Human Subject (2008‑08‑08) ref XDLAB-
Example	Human patient paired with Non-Human Subject Example <recordTarget typeCode="RCT">   <templateId root="1.3.6.1.4.1.19376.1.3.3.1.3"/>  <patientRole classCode="PAT">     <id root="2.999" extension="sw54321"/>    <addr>       <streetAddressLine>Leidensweg 10</streetAddressLine>      <city>Specimendorf</city>      <postalCode>9876</postalCode>    </addr>    <telecom value="tel:+41.32.685.12.34"/>    <patient classCode="PSN">       <name>         <family>Muster</family>        <given>Max</given>      </name>      <administrativeGenderCode code="F"/>      <birthTime value="19480611"/>    </patient>  </patientRole></recordTarget>
Item DT Card Conf Description Label hl7:recordTarget 1 … * R Human Patient with Non-Human Subject. IHE PalM TF3 Rev.8, 6.3.2.11.3 hl7:templateId II 1 … 1 M IHE PalM TF3 Rev.8, 6.3.2.11.3 @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.3.3.1.3   Schematron assert role  error     test //hl7:templateId[@root='1.3.6.1.4.1.19376.1.3.3.1.3.1']     Message In addition to the elements specified in the CDA header for the patient, the non-human subject SHALL be represented in a Subject element in level 3 entries in the structuredBody.   hl7:templateId II 1 … 1 M IHE PalM TF3 Rev.8, 6.3.2.11.3 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.27 hl7:patientRole 1 … 1 R Exactly one patient MUST be declared. IHE PalM TF3 Rev.8, 6.3.2.11.3 hl7:id II 1 … * R At least one patient identification MUST be declared. Note: The identification of the non-human material MUST NOT be deklared here. This can not be specified within the same document. See also: IHE PaLM TF3, section 6.3.2.11.3. If the identification of the non-human material is important (for example in rabies), two separate documents should be created (one with the human patient and one with the non-human material). IHE PalM TF3 Rev.8, 6.3.2.11.3 @extension st 1 … 1 R MUST contain the actual number of non-human material. The number MUST be unique within the system that issued the number. @root uid 1 … 1 R MUST contain the OID of the system that issued the number. OIDs of code systems, which are published in the public OID registry for the Swiss health care system (oid.refdata.ch) are REQUIRED. Others are NOT ALLOWED. hl7:addr AD 1 … * R All persons (including patients) and organizations, MUST contain according to XD-LAB name, addr and telecom. IHE PalM TF3 Rev.8, 6.3.2.11.3 hl7:telecom TEL 1 … * R All persons (including patients) and organizations, MUST contain according to XD-LAB name, addr and telecom. IHE PalM TF3 Rev.8, 6.3.2.11.3 hl7:patient 1 … 1 R Exactly one patient MUST be declared. IHE PalM TF3 Rev.8, 6.3.2.11.3 hl7:name PN 1 … * R All persons (including patients) and organizations, MUST contain according to XD-LAB name, addr and telecom. IHE PalM TF3 Rev.8, 6.3.2.11.3 hl7:administrative​Gender​Code CE 1 … 1 R IHE PalM TF3 Rev.8, 6.3.2.11.3   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.1 AdministrativeGender (DYNAMIC) hl7:birthTime TS 1 … 1 R IHE PalM TF3 Rev.8, 6.3.2.11.3

Insurance - participant

Id	2.16.756.5.30.1.1.10.2.15 ref hl7chcda-	Effective Date	2018‑04‑18
Status	Active	Version Label	2017
Name	cdach_header_Insurance	Display Name	Insurance - participant
Description	Information on a patient's insurance. CDA-CH V2 derivatives, i.e. Swiss exchange formats MAY use this template by either reference or specialisation.
Context	Parent nodes of template element with id 2.16.756.5.30.1.1.10.2.15
Label	CDA‑CH V2
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Uses	Uses 2 templates Uses as Name Version 2.16.756.5.30.1.1.10.9.34 Containment Person Name Information Compilation - eCH-0011 (2017) DYNAMIC 2.16.756.5.30.1.1.10.9.26 Containment Organization Compilation with GLN, name, addr and telecom (2017) DYNAMIC
Relationship	Specialization: template 2.16.840.1.113883.10.12.108 CDA participant (2005‑09‑07) ref ad1bbr-
Example	Example <participant typeCode="COV">   <templateId root="2.16.756.5.30.1.1.10.2.15"/>  <time>     <low value="20170910"/>    <high nullFlavor="NASK"/>  </time>  <associatedEntity classCode="PAYOR">     <id root="2.999" extension="23.253-m"/>    <code code="832.10" codeSystem="2.16.756.5.30.2.1.1.11" codeSystemName="ins-laws" displayName="Federal Act on Health Insurance (HIA)"/>    <scopingOrganization>       <id root="2.51.1.3" extension="7607777777777"/>      <name>NousPaieronsTous assurances</name>      <telecom nullFlavor="NASK"/>      <addr use="WP">         <streetName>rue payant</streetName>        <houseNumber>89</houseNumber>        <postalCode>8888</postalCode>        <city>Guérison-ville</city>        <country>CH</country>      </addr>    </scopingOrganization>  </associatedEntity></participant>
Item DT Card Conf Description Label hl7:participant 0 … * Information on a patient's insurance. CDA‑CH V2 @typeCode cs 1 … 1 F COV hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.15 hl7:time IVL_TS.CH.TZ 0 … 1 Validity period of the contract. CDA‑CH V2 hl7:low TS.CH.TZ 1 … 1 R Start of the contract. CDA‑CH V2 hl7:high TS.CH.TZ 1 … 1 R End of the contract. CDA‑CH V2 hl7:associated​Entity 1 … 1 R CDA‑CH V2 @classCode cs 1 … 1 F PAYOR hl7:id II 1 … 1 R The id of the contract ([ge]: Versichertennummer; [fr]: Numéro d'assuré). CDA‑CH V2 @root uid 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   The id itself. It MUST be unique within the issuing system. hl7:code CE 1 … 1 R The underlying law for the contract. CDA‑CH V2 @nullFlavor cs 0 … 1 F NAV @code cs 0 … 1   832.10, 832.20, 221.229.1, 833.1, 831.20 @codeSystem oid 0 … 1 F 2.16.756.5.30.2.1.1.11 @codeSystemName st 0 … 1 F ins-laws @displayName st 0 … 1   Federal Act on Health Insurance (HIA), Federal Act on Accident Insurance (AIA), Federal Act on Insurance Policies (Insurance Policies Act, IPA), Federal Act on Military Insurance (MilIA), Federal Act on Invalidity Insurance (InvIA)   Schematron assert role  error     test (@nullFlavor='NAV' and not(@codeSystem or @codeSystemName or @code or @displayName)) or (@codeSystem='2.16.756.5.30.2.1.1.11' and @codeSystemName='ins-laws' and @code and @displayName)   &#