Ehscda:CDA-CH 2017 (specification)

Aus eHealth Suisse
Wechseln zu: Navigation, Suche
Sprachen: Deutsch français




Identifikation dieses Dokuments
Abkürzung: CDA-CH V2 (2017)
OID: 2.16.756.5.30.1.1.1.1.4

Impressum

Ausserkraftsetzung vorbestehender Spezifikationen

Zweck und Positionierung

Gleichstellung von Mann und Frau

Elektronische Version

Inhaltsverzeichnis

Zusammenfassung

Ein Patient durchläuft während einer Behandlung in der Regel mehrere, oft sogar zahlreiche Institutionen. Auf dem Behandlungspfad eines Patienten werden zahlreiche medizinische Dokumente ausgetauscht. Ein isolierter Betrieb von Informationssystemen führt nebst Mehrfacherfassungen, Medienbrüchen und anderen negativen Begleiterscheinungen vor allem zu unnötigem personellen Aufwand. Oft wird auch heute noch das Papier als Medium und der Patient als Kurier eingesetzt. Mit den heute verfügbaren Mitteln der Informations- und Kommunikationstechnologie (ICT) sind demgegenüber wesentliche Verbesserungen möglich.
Beispiele:

  • Automatische Verteilung der Dokumente aufgrund der, im Dokumentenkopf genannten Empfänger
  • Elektronische Verarbeitung der Nutzdaten
    • Sendende Informationssysteme können Inhalte aus deren Datenbeständen automatisch generieren
    • Empfangende Informationssysteme können ihre Datenbestände aus elektronisch erhaltenen Dokumenten automatisch nachführen
    • Alarmierungen oder Workflows können bei Bedarf initialisiert werden

Um einen einheitlichen, ökonomisch vertretbaren Einsatz des elektronischen Austausches medizinischer Dokumente zu ermöglichen, ist der Einsatz von Standards notwendig. Dadurch wird sichergestellt, dass mehrere in sich autonome Systeme und Organisationen ohne vorherige Absprachen miteinander kommunizieren können. CDA-CH ist genau dazu etabliert worden und soll als Instrument dienen, die Interoperabilität zwischen Leistungserbringern im schweizerischen Gesundheitswesen erhöhen. CDA-CH V2 (2017) bietet eine Konformität zu eCH Normen für Postadresse und Personendaten, sowie zum EPDG (Anhang 3: Metadaten und Anhang 4: Austauschformate). Damit wird sichergestellt, dass CDA-CH V2 Dokumente optimal in Prozesse rund ums elektronische Patientendossier (EPD) integriert werden können. Der Einsatz im EPD ist allerdings nur eines von zahlreichen Szenarien für den Einsatz von CDA-CH V2. CDA-CH V2 kann und wird auch ausserhalb des EPD eingesetzt werden.


Einleitung

Ausgangslage und Motivation

Die Grundlage für die Austauschformate in der Schweiz bildet die CDA-CH Spezifikation. Diese wurde im 2009 etabliert und seither nicht mehr aktualisiert. Die vorliegende Überarbeitung dient insbesondere der Anpassung an Vorgaben aus dem Gesetz zum elektronischen Patientendossier. Ausserdem wurden auch Vorgaben von eCH Standards zu Adressen und Personendaten berücksichtigt.
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.

Status und Zweck des Dokuments

Angesprochene Leserschaft


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 .

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
  • Harmonisierung der Informationen im CDA Header, da mit diese in den verschiedenen - von CDA-CH abgeleiteten - Austauschformaten identisch wiederverwendet werden können.
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

Die vorliegende Spezifikation fokussiert auf die Strukturierung der administrativen Informationen in einem HL7 CDA Dokument (CDA Header), wie sie beim Einsatz in der Schweiz angewendet werden sollen. Es handelt sich dabei z.B. um Sprache, Autor, Verweis auf ein allfällig zu ersetzendes Dokument oder einen Auftrag der zur Erstellung des neuen Dokuments geführt hat, weitere beteiligte Personen oder Organisationen (wie Notfallkontakte, Versicherungen, Arbeitgeber, rechtsgültiger Unterzeichner, etc.). Eine genauere Übersicht befindet sich im Kapitel Spezifikation (normativ).

Da es sich bei dieser Spezifikation um die Grundlage für den Austausch von strukturierten Dokumenten handelt wird von einer Strukturierung von medizinischen Daten ausgegangen. Es wird aber nicht auf die Strukturierung von medizinischen Daten eingegangen, denn dies ist Inhalt der verschiedenen Austauschformate, welche von CDA-CH für entsprechende Anwendungsfälle (wie z.B. elektronisches Impfdossier, eMedikation oder allgemeine Laborbefunde) abgeleitet werden.

Eine genauere Übersicht über die verschiedenen Varianten im CDA Body kann dem Wiki von HL7 Deutschland entnommen werden: CDA Body im Arztbrief V2.

Folgende Themen werden vom vorliegenden Austauschformat nicht behandelt:

  • Dokumente mit unstrukturierten Daten (CDA Body).
  • Eigentliche Strukturierung von medizinischen Daten (CDA Body).
  • Eigentliche Übertragung der Dokumente (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 .

Verantwortlichkeiten

Die Herausgeberin genehmigt ausdrücklich die Anwendung des vorliegenden Leitfadens ohne Lizenz- und Nutzungsgebühren zum Zweck der Übermittlung von "CDA-CH 2017 (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 dieser Spezifikation 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:

Cdach Referenzpyramide.png

Cdach Referenzpyramide.png

[Abbildung 1] Bezug zu anderen Standards und Leitfäden – Referenzpyramide

IHE Integrationsprofile

HL7 V3

HL7 Clinical Document Architecture (CDA)

Gesetzgebung Elektronisches Patientendossier (EPDG)

Ü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 .

Begriffsdefinitionen

In diesem Dokument verwendete Begriffe halten sich an die Begriffsdefinition im Glossar von eHealth Suisse.


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

Diese Spezifikation dient der Unterstützung des elektronischen Austauschs medizinischer Dokumente. Der bewusst weitgefasste Begriff des „medizinischen Dokuments“ ermöglicht die Anwendung dieser Vorgaben für eine Vielzahl von Situationen des medizinischen Alltags, insbesondere die Kommunikation mit Stellen in anderen Betrieben betreffend. Die Vielzahl der Dokumente wird anhand der folgenden, nicht abschliessenden Auflistung von Beispielen deutlich:

Dokumentart Zweck Beispiele
Medizinischer Bericht Orientierung einer behandlungsbeteiligten Stelle über den Verlauf einer Behandlung Austrittsbericht / Abschlussbericht, Übergabebericht an eine weiterbehandelnde Stelle, Zwischenbericht betreffend einer laufenden Behandlung
Auftrag Auslösen einer Massnahme im Zusammenhang mit der Behandlung eines Patienten Zuweisung zur stationären oder ambulanten Übernahme der Behandlung (z.B. Spitaleinweisung), Auftrag zur konsiliarischen Durchführung von diagnostischen oder therapeutischen Massnahmen, Weitere Verordnungen an behandlungsbeteiligte Stellen: SPITEX, Physiotherapie etc., Rezept
Bericht über Teilaspekte einer Behandlung Orientierung über einzelne Teilaspekte einer Behandlung, häufig im Zusammenhang mit der Durchführung von therapeutischen oder diagnostischen Massnahmen Operationsbericht, Laborresultate resp. Zusammenfassung der Laborresultate, Radiologiebefund, Pathologiebefund
Pflegeberichte Orientierung über Pflegeinformationen betreffend Behandlung, Therapie und Pflege eines Patienten. Pflegebericht, Behandlungsbericht Physiotherapie
etc.

[Tabelle 1] Auflistung von Beispielen von medizinischen Dokumenten

Der Austausch medizinischer Dokumente kann verschiedene Ziele verfolgen:

  • Als medizinischer Bericht dient er dem Informationsaustausch über Daten aus der Krankengeschichte eines Patienten zwischen Sender und Empfänger eines Dokumentes.
  • In Form eines Auftrags dient er der Veranlassung weiterer Massnahmen durch den Empfänger eines Dokumentes in Bezug auf eine Patientenbehandlung.

Medizinische Dokumente sind traditionell zumeist in Absätzen gegliedert und häufig ausgezeichnet durch eine Überschrift. Die Absätze entsprechen dabei jeweils einer Informations-Entität oder einem Informationsaspekt, wie in den nachfolgenden Beispielen verdeutlicht wird. Allerdings ergibt sich die Wertigkeit einer Entität häufig erst aus dem Gesamtkontext eines Dokumentes. Abschnitte mit ähnlich lautender oder gleichlautender Bezeichnung sind also nicht in jedem Fall Sinn-äquivalent. So wird z.B. die Liste der Operationsdiagnosen aus einem Operationsbericht häufig nicht deckungsgleich mit der Diagnosenliste des späteren Austrittsberichtes dieses Patienten sein.

Der Austausch von Dokumenten ist meist Teil eines Workflows. Oft werden auch mehrere Dokumente, bezugnehmend aufeinander, im Rahmen eines medizinischen Ablaufes ausgetauscht. So wird sich der Befund einer diagnostischen Untersuchung beispielsweise auf die Fragestellung beziehen, welche im Auftrag zu dieser Untersuchung formuliert wurde. Es ist nicht Gegenstand des vorliegenden Dokumentes, Empfehlungen zur Implementierung medizinischer Abläufe abzugeben. Allerdings soll die Integration elektronischer Workflows durch die Definitionen dieser Spezifikation erleichtert und vereinfacht werden. Zur Demonstration der möglichen Ausgestaltung medizinischer Dokumente wird nachfolgend zusammenfassend das in CDA-CH V1 (2009) ausführlich beschriebene Fallbeispiel "Hüftgelenkersatz" dargestellt.

Die, in den nachfolgenden Unterkapiteln genannten Fallbeispiele sind frei erfunden und haben keinen didaktischen Anspruch. Sie könnten sich tatsächlich so abspielen, und dienen somit der Veranschaulichung der Situation. Gleiches gilt für die erwähnten Dokumente, deren Inhalte auf das Fallbeispiel abgestimmt sind.

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 .

Storyboard "Hüftgelenkersatz"

Dieses Fallbeispiel dient lediglich der Illustrierung für eine mögliche Umsetzung der vorliegenden Spezifikation und ist selbstverständlich nicht als Vorgabe zu werten.

Ein 70-jähriger Patient wendet sich wegen belastungsabhängigen Schmerzen im rechten Hüftgelenk, welche schon seit längerer Zeit bestehen, in den vergangenen Monaten aber deutlich zugenommen haben, an seinen Hausarzt.
Aufgrund der Anamnese und des klinischen Status des Patienten stellt der Hausarzt die Verdachtsdiagnose einer Arthrose des rechten Hüftgelenkes als Ursache für die Beschwerden. Der Hausarzt entschliesst sich, den Verdacht durch eine Röntgenuntersuchung des Hüftgelenkes zu bestätigen. Da er selbst keine Röntgenuntersuchungen durchführt, meldet er den Patienten in einem externen Röntgeninstitut mittels eines Auftragsformulars an und vereinbart auch gleich einen Untersuchungstermin. Die Bilder der Untersuchung sowie ein Röntgenbefund mit Beurteilung durch den radiologischen Facharzt werden dem Hausarzt kurz nach Durchführung der Untersuchung zugestellt.

Bei der nächsten Konsultation bespricht der Hausarzt die Situation mit dem Patienten. Es wird gemeinsam entschieden, den Patienten an einen Facharzt für Orthopädie zur Besprechung der Therapieoptionen zu überweisen. Der Hausarzt verfasst einen Überweisungsbericht, welcher den bisherigen Krankheitsverlauf und die Untersuchungsergebnisse umreisst und übermittelt diesen, zusammen mit den Röntgenbildern an die Praxis des Orthopäden.

Nachdem er sich über den radiologischen Befund anhand der übermittelten Röntgenbilder bereits vorgängig orientiert hat, empfiehlt der Orthopäde dem Patienten die operative Sanierung des rechten Hüftgelenkes mittels Implantation einer Hüftgelenks-Endoprothese. Der Patient erklärt sich mit dem Vorschlag einverstanden.

Der Orthopäde informiert den Hausarzt über den Entscheid und bittet ihn, die Spitaleinweisung zu organisieren und die präoperativen Laboruntersuchungen in der Hausarztpraxis durchzuführen.

Kurz vor dem Spitaleintritt hat der Patient einen Termin bei seinem Hausarzt, um die vor der Operation notwendigen Laborwerte bestimmen zu lassen. Die Laborwerte werden vom Hausarzt der Klinik übermittelt, wo sie ins elektronische Patientendossier aufgenommen werden.

Während der Operation stehen dem Orthopäden die Röntgenbilder der Hüfte zur Verfügung. Die Lage der Endoprothese wird intraoperativ mittels C-Bogen kontrolliert. Postoperativ werden in der Klinik erneut Kontroll-Röntgenbilder der Hüfte erstellt. Der Orthopäde dokumentiert den Operationsverlauf und gibt Instruktionen für die weitere Nachbehandlung in einem Operationsbericht. Dem Hausarzt wird eine Kopie dieses Operationsberichtes zugestellt.

Der Patient kann nach einer Woche Spitalaufenthalt in eine stationäre Rehabilitation entlassen werden. Die Ärztliche Leitung des Rehabilitationshauses wird über den Krankheits- und OP-Verlauf durch einen zusammenfassenden Entlassbrief informiert. Dem Bericht werden eine Zusammenfassung der Laborresultate, eine Kopie der Röntgenbilder und eine Kopie des Operationsberichts beigelegt. Der Hausarzt erhält ebenfalls eine Kopie des Austrittsberichtes.

Nach abgeschlossener Rehabilitation des Patienten erstellt die Rehabilitationsklinik ihrerseits einen orientierenden Bericht zuhanden des Hausarztes mit Kopie an den Orthopäden. Die Behandlung wird mit einer Abschusskonsultation beim Hausarzt schliesslich beendet.

Dokumenten-Workflow Fallbeispiel Hüftgelenkersatz

Cdach Hueftgelenkersatz DocWorkflow de.png

Cdach Hueftgelenkersatz DocWorkflow de.png

[Abbildung 2] Dokumenten-Workflow Fallbeispiel Hüftgelenkersatz

UC 1-1: Zuweisung zur Radiologischen Diagnostik

Ein Patient wird dabei durch seinen Arzt zur radiologischen Untersuchung angemeldet. Es wird um Rückmeldung eines möglichen Termins ersucht. Der resultierende Radiologiebefund wird Bezug nehmen auf dieses Zuweisungsschreiben. Es handelt sich im obigen Fallbeispiel um den Auftrag zur radiologischen Untersuchung vom Hausarzt an das Radiologieinstitut.

Umsetzungsbeispiele:

UC 1-2: Rückmeldung Radiologiebefund

Dieses Dokument beinhaltet die Rückmeldung der vorgängig beauftragen Radiologieuntersuchung und nimmt Bezug auf das Zuweisungsschreiben. Es handelt sich im obigen Fallbeispiel um die Rückübermittlung der resultierenden Bilder und des Befundes vom Radiologen an den Hausarzt.

Umsetzungsbeispiele:

UC 1-3: Überweisung zur konsiliarischen Beurteilung durch den Facharzt

Ein Patient wird durch seinen Hausarzt zur konsiliarischen Beurteilung an einen Facharzt überweisen. Es handelt sich im obigen Fallbeispiel um das Überweisungsschreiben vom Hausarzt an den Orthopäden, zusammen mit den Röntgenbildern und einer Zusammenfassung der Vorgeschichte und der erhobenen Befunde.

Umsetzungsbeispiele:

UC 1-4: Konsiliarbericht

Konsiliarischer Untersuchungsbericht des Facharztes an den Hausarzt. Dieses Dokument beinhaltet die Rückmeldung der vorgängig beauftragen Radiologieuntersuchung und nimmt Bezug auf das Zuweisungsschreiben. Es handelt sich im obigen Fallbeispiel um den ärztlichen Bericht des Orthopäden an den Hausarzt mit der fachärztlichen Beurteilung und einer Beschreibung des weiteren Vorgehens (OP).

Umsetzungsbeispiele:

UC 1-5: Reguläre Spitaleinweisung

Einweisung eines Patienten durch den Hausarzt zur stationären Behandlung in einer Klinik. Es handelt sich im obigen Fallbeispiel um die Bitte des Hausarztes an das Spital, den Patienten zur Operation aufzubieten.

Umsetzungsbeispiele:

UC 1-6: Präoperative Untersuchungsresultate

Übermittlung der, vor der Hospitalisation in der Hausarztpraxis erhobenen Befunde ans Spital. Es handelt sich im obigen Fallbeispiel um die aktuellen Befunde aus der körperlichen Untersuchung und Übermittlung von Laboranalyse-Resultaten vom Hausarzt ans Spital.

Umsetzungsbeispiele:

UC 1-7: Operationsbericht

In Form eines Operationsberichtes dokumentiert der Operateur durchgeführte Eingriffe. Es ist die Dokumentation der durchgeführten Operation für die Spitalakte. Kopien dieses Dokuments werden üblicherweise an die direkt an der Behandlung beteiligten Stellen geschickt: an den zuweisenden Arzt und gegebenenfalls an weitere behandelnde Stellen. Es handelt sich im obigen Fallbeispiel um den Operationsbericht des Orthopäden an den Hausarzt.

Umsetzungsbeispiele:

UC 1-8: Kurzbericht bei Spitalentlassung

Kurzbericht, kann dem Patienten bei Austritt direkt mitgegeben werden und dient zur Groborientierung des nachbehandelnden Arztes. Es handelt sich im obigen Fallbeispiel um eine Grobinformation des Spitals an den nachbehandelnden Arzt im Rehabilitationszentrum.

Umsetzungsbeispiele:

UC 1-9: Spital-Austrittsbericht

Zusammenfassung der Patientenakte bezogen auf die aktuelle Behandlung. Dieses Dokument soll eine Übersicht über die behandlungsrelevanten Fakten ermöglichen. Eine Kopie des Dokumentes geht üblicherweise an den zuweisenden Arzt und gegebenenfalls an weitere behandelnde Stellen. Es handelt sich im obigen Fallbeispiel um das Überweisungsschreiben an die Rehabilitationsklinik (inklusive postoperative Röntgenbilder mit der Total-Endoprothese und Zusammenfassung der Laborresultate) mit Kopie an den Hausarzt.

Umsetzungsbeispiele:

UC 1-10: Austrittsbericht Reha-Klinik

Bericht über den Rehabilitationsverlauf, mit Kopie an gewisse in die Behandlung involvierte Stellen. Es handelt sich im obigen Fallbeispiel um den Entlassbrief der Rehabilitationsklinik an den Hausarzt mit Kopie an den Orthopäden.

Umsetzungsbeispiele:



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.

Transportmechanismus

Umgang mit Metadaten

Wie bei den Empfehlungen zum Transportmechanismus genannt und auch im Zusammenhang mit dem elektronischen Patientendossier ist ein harmonisierter Umgang mit Metadaten zu den Dokumenten, welche mit CDA-CH V2 erstellt werden, sehr empfehlenswert.

In den Header Informationen eines HL7 CDA Dokuments befinden sich zahlreiche Informationen, die auch in den Metadaten einer IHE XDS.b Registry genannt werden. Unabängig davon, ob es sich um eine IHE XDS.b Umgebung im Rahmen des EPDG handelt oder ob es sich um eine andere Affinity Domain (auch Gemeinschaft oder Community genannt) handelt, können bestimmte XDS.b Metadaten aus den CDA Header Informationen extrahiert werden. Dabei gilt zu beachten, dass mit dem IHE Profil 'XDS Metadata Update' die Metadaten in einer XDS.b Registry verändert werden können. Die Metadaten im CDA Dokument bleiben dabei aber unverändert.

eHealth Suisse hat hier konkrete Umsetzungshinweise zum Mapping Metadaten und dem Einsatz von Value Sets dokumentiert: Metadaten gemäss EPDV.

Umgang mit Original Darstellung und PDF Dokumenten

Die Digitalisierung ist ein grosser Fortschritt, der gerade auch bei betriebsübergreifenden Prozessen zahlreiche Verbesserungen mit sich bringen kann.

So ist z.B. aus Sicht eines Spitals die Liste der aktuellen Medikamente, die ein Patient beim Austritt einnimmt, in der Regel ein Kapitel am Ende des Spitalaustrittsberichts. Gerade diese Liste ist aber für die nachbehandelnde Stelle besonders wichtig. Es macht also durchaus Sinn, für die Darstellung des Spitalaustrittsberichts im Spital und bei der nachbehandelnden Stelle (z.B. Hausarzt, Spitex oder Rehabilitations-Klinik) verschiedene Stylesheets auf das gleiche CDA Dokument anzuwenden. Damit kann bei der nachbehandelnden Stelle das Kapitel mit den Medikamenten bei Austritt aus dem Spital zuoberst dargestellt werden. Das erlaubt es den nachbehandelnden Gesundheitsfachpersonen wichtige Informationen zuerst zu finden.

Ein anderes Beispiel findet man bei Laborbefunden: Für die Laboratorien ist es wichtig, dass der Empfänger die Originaldarstellung eines Laborbefundes erhalten kann, weil die elektronisch strukturierten Befunde (oft auch in Form von HL7 V2 Nachrichten ausgetauscht) nicht in allen Empfänger-Systemen korrekt wiedergegeben werden. Die Laboratorien können aber für falsche Darstellungen keine Verantwortung tragen und dies gilt nicht nur für HL7 V2 Nachrichten, sondern auch für Laborbefunde basierend auf HL7 CDA (z.B. mit dem Austauschformat eLaborbefund – CDA-CH-LREP).

Die Verantwortung für die korrekte Anwendung von Gesundheitsinformationen in einem CDA Dokument kann also nicht alleine vom Absender (Autor/Unterzeichner) wahrgenommen werden, sondern der Empfänger muss ebenfalls seine Verantwortung wahrnehmen. Der rechtsgültige Unterzeichner eines CDA Dokuments kann keinesfalls dafür haften, wenn beim Empfänger infolge der Anwendung eines anderen Stylesheets bestimmte Informationen anders, falsch oder gar nicht dargestellt werden.

Es geht aber nicht darum, aus diesem Grund auf die Anwendung von CDA Dokumenten zu verzichten, sondern es geht darum, die daraus entstehenden Vorteile (wie oben anhand des Beispiels der Medikamentenliste beschrieben) zu nutzen, ohne aber neue Probleme im Bereich der Verantwortung oder Haftung zu schaffen.

Aus diesen Gründen sind nachfolgende Empfehlungen hervorgegangen.

Empfehlung zum Umgang mit der Original Darstellung

  • In einem CDA Dokument soll, wenn es der Autor des Dokuments als wichtig erachtet oder wenn es in einem bestimmten Anwendungsfall notwendig ist, die Originaldarstellung so mitgegeben werden wie sie der rechtsgültige Unterzeichner zum Zeitpunkt seiner Signatur gesehen hat. Ob also die Original Darstellung in ein CDA Dokument integriert wird, ist somit auf der Ebene von CDA-CH V2 freiwillig. Eine Präzisierung dazu kann in den Austauschformaten festgehalten werden, welche von CDA-CH V2 ableiten.
  • Wenn die Originaldarstellung mitgegeben wird, dann soll sie in Form eines PDF Dokuments in HL7 CDA Dokumente integriert werden (siehe CDA Beispieldokument mit eingebetteter Original Darstellung im PDF/A Format).


Cdach content org representation de.png

Cdach content org representation de.png

[Abbildung 4] Original Darstellung mittels eingebettetem PDF/A im CDA Body

Empfehlung zum Umgang mit PDF Dokumenten

  • Wenn PDF Dokumente in einem CDA Dokument eingebettet oder referenziert werden, dann sollen diese in Form von PDF/A in CDA integriert werden. Dies gilt sowohl für die Original Darstellung, wie auch für allfällige Beilagen oder referenzierte Dokumente.
  • Dabei soll die Ausprägung PDF/A-1 verwendet werden, denn PDF/A-1 basiert auf PDF V1.4 und ist somit auch mit älteren Systemen erzeug- und nutzbar.
  • Dabei soll der Konformitätsgrad PDF/A-1a eingehalten werden, denn jedes Dokument, welches dem strengeren Standard PDF/A-1a genügt, genügt auch dem weniger strengen Standard PDF/A-1b.
  • PDF Dokumente in den Ausprägungen PDF/A-2 oder PDF/A-3 sollen im Zusammenhang mit CDA-CH nicht verwendet werden. Stattdessen sollen die mit PDF/A-2 oder PDF/A-3 spezifizierten Attachments als eigenständige Attachments in CDA eingebettet oder referenziert werden.

Cdach pdf editions de.png

Cdach pdf editions de.png

[Abbildung 5] PDF/A Ausprägungen


Hinweise und Begründungen zu den obenstehenden Empfehlungen

  • Die Einbettung von Multimedia Objekten (also auch PDF Dokumente) in ein HL7 CDA Dokument erfolgt Base64 codiert, damit auch binäre Datenströme in XML eingebettet werden können.
  • Es würde auch die Varianten geben, CDA- und PDF-Dokumente separat als eigenständige Dokumente zu übertragen und miteinander zu verlinken oder das CDA Dokument als XML Element in das PDF Dokument zu integrieren. Auf diese Varianten wird aber nicht eingegangen.
    Gründe für den Variantenentscheid, CDA in PDF zu integrieren:
    • Aus Sicht der Softwarehersteller ist es wichtig, dass für die Umsetzung der Original Darstellung nur eine von mehrere Varianten implementiert werden muss (Vermeidung von n*m Schnittstellen).
    • HL7 CDA Dokumente sind XML Dokumente. XML kann in den gängigen Datenbanksystemen als eigenständiger Datentypen abgelegt und zu einem späteren Zeitpunkt mittels Datenbankabfragen wieder strukturiert ausgewertet werden.
  • PDF/A ist unabdingbar:
    • Ein herkömmliches PDF ist nicht geeignet für eine Langzeitarchivierung, weil wichtige Informationen (wie z.B. die Schriftart) nicht zwingend im Dokument eingebettet sein müssen, die aber für die identische Darstellung auf einem anderen Computer essentiell sind.
    • Sowohl das Merkblatt Archivtaugliche Dateiformate des Bundesarchivs, sowie auch der Anhang 2 der Verordnung des EDI über das elektronische Patientendossier (Zertifizierungsvoraussetzungen Gemeinschaften und Stammgemeinschaften) verlangen deshalb PDF/A.
    • Die PDF Ausprägungen (A-1, A-2, A-3) sind nicht voneinander ableitbar und auch nicht ineinander subsummierbar. Bei vielen der gängigen PDF Validatoren muss deshalb der PDF Konformitätsgrad vor der Validierung definiert werden. Sollten also mehrere PDF Ausprägungen zugelassen werden, müsste die Validierung pro eingebettetes PDF Dokument mehrmals aufgerufen werden.
    • Die obenstehende Empfehlung nach dem Konformitätsgrad PDF/A-1a erfüllt einerseits die Anforderungen des Bundesarchivs und des EPDG und es sind andererseits genügend Softwarekomponenten für die Generierung von PDF Dokumenten auf dem Markt, welche diesen Standard erfüllen.

Umgang mit Identifikatoren

Bei den nachfolgenden Empfehlungen zu Identifikatoren wird Rücksicht genommen auf die rechtlichen Vorgaben in der Schweiz und es gilt zu berücksichtigen, dass CDA-CH V2 sowohl im Rahmen verschiedener Gesetze (z.B. EPDG[Anmerkung 2], EpG[Anmerkung 3], IVG[Anmerkung 4], AHVG[Anmerkung 5],KVG[Anmerkung 6], etc.), wie auch im bilateralen Austausch zwischen Behandelnden oder Gesundheitseinrichtungen eingesetzt wird. Die nachfolgenden Empfehlungen zu Identifikatoren erfüllen diese übergeordneten Vorgaben. Weitere Vorgaben werden in CDA-CH V2 nicht formuliert. Solche können gegebenenfalls in den Austauschformaten festgehalten werden, welche von CDA-CH V2 ableiten.

Empfehlung zum Umgang mit Identifikatoren für Patienten

Folgende Identifikatoren für Patienten sollen in CDA-CH V2 Dokumenten verwendet werden:

  • Alle lokalen Identifikatoren der Primärsysteme
  • Eindeutige Patientenidentifikation im Master-Patient Index einer Gemeinschaft (MPI-PID)

Folgende Identifikatoren für Patienten sollen in CDA-CH V2 Dokumenten nur nach Prüfung der gesetzlichen Grundlage verwendet werden:

  • AHV Nummer (Sozialversicherungsnummer)
    Darf bei der Einstellung des Dokuments ins EPD nicht vorhanden sein. Ausserhalb des EPD legen Artikel 50d und 50e AHVG den allgemeinen Rahmen der gesetzlichen Grundlagen für die systematische Verwendung der AHV Nummer fest. Diese hängen von der Art der Organisation sowie ihren Tätigkeiten ab. So dürfen Leistungserbringer nach KVG in bestimmten Fällen die AHV Nummer nutzen. Es obliegt allein der Organisation, die massgebliche gesetzliche Grundlage zu benennen.
  • Patientenidentifikationsnummer (EPR-SPID)
    Diese wird im Rahmen des EPDG bei Eröffnung eines Patientendossiers einem Patienten von der ZAS[Anmerkung 7] herausgegeben und darf gemäss EPDG, Art. 6 nur verwendet werden, wenn eine formelle gesetzliche Grundlage dies vorsieht sowie der Verwendungszweck und die Nutzungsberechtigten bestimmt sind.

Empfehlung zum Umgang mit Identifikatoren für Behandelnde und Gesundheitseinrichtungen

Folgende Identifikatoren für Behandelnde und Gesundheitseinrichtungen sollen in CDA-CH V2 Dokumenten verwendet werden:

  • Alle lokalen Identifikatoren der Primärsysteme
  • Eindeutige Identifikation von Behandelnden und Gesundheitseinrichtungen, sowie Gruppen von Behandelnden im Healthcare Provider Directory einer Gemeinschaft (HPD-ID):
    • Für Behandelnde und Gesundheitseinrichtungen ist insbesondere die GLN erlaubt und empfohlen.
      Hinweis: Ab 15.4.2020 wird die GLN im Rahmen des EPDG für alle Behandelnden zwingend.
    • Für Gruppen von Behandelnden ist insbesondere die OID, wie sie gemäss Ergänzung 1 zu Anhang 5 der EPDV-EDI (Nationale Anpassungen) eingetragen wird, erlaubt und empfohlen.

Folgende Identifikatoren für Behandelnde und Gesundheitseinrichtungen sollen in CDA-CH V2 Dokumenten nicht verwendet werden:

  • AHV Nummer (Sozialversicherungsnummer)
  • Patientenidentifikationsnummer (EPR-SPID)


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)

Vereinfachte Zusammenfassung der CDA Struktur

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

Cdach content doc de.png

Cdach content doc de.png

[Abbildung 6] Inhalt CDA Dokument

Die Auflistungen und Abbildungen in diesem Kapitel (inkl. Unterkapitel) enthalten vereinfachte Darstellungen des Dokumenteninhalts und zeigen den Inhalt des CDA Dokuments symbolhaft auf.

CDA Header

  • Dokumentinformation (Dokumenten-Id, Code, Titel, Erstellungszeitpunkt, Vertraulichkeitsstufe, Sprache, Version)
  • Angaben zum Patient (Patientenidentifikation, Name, Adresse, Geburtsdatum, Geburtsort, Geschlecht, Zivilstand, Religion, Sprachfähigkeiten) resp. zu nicht-menschlichen Proben
  • Mitwirkende am Dokument: Autoren, Erfasser
  • Rechtsgültiger Unterzeichner, weitere Unterzeichner wie z.B. klinische Validatoren
  • Absender (Verwalter)
  • Empfänger inkl. allfälliger Kopie-Empfänger
  • Patienten-Kontakte (z.B. Notfallkontakt, Arbeitgeber, Versicherung und Versichertenkarte)
  • Verweis auf den Auftrag oder ein allfällig zu ersetzendes Dokument


Cdach content header de.png

Cdach content header de.png

[Abbildung 7] Administrative Daten im CDA Header

CDA Body

Der CDA Body wird von dieser Spezifikation nicht normiert. Die medizinischen Inhalte im CDA Body werden von den entsprechenden Austauschformaten spezifiziert.

Allgemeines

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. eCH Standards
    1. Postadresse eCH-0010, Version 7.0
    2. Datenstandard Personendaten eCH-0011, Version 8.1
  4. Gesetzgebung Elektronisches Patientendossier (EPDG)
    1. Anhang 3 der Verordnung des EDI über das elektronische Patientendossier (Metadaten), Gültig ab 15.04.2017
    2. Anhang 4 der Verordnung des EDI über das elektronische Patientendossier (Austauschformate), Anhörungsversion


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 der vorliegenden Spezifikation kombinierbaren IHE Akteure und Transaktionen. Die Grafik zeigt auf, dass die involvierten Akteure ein Dokument auf Basis von CDA-CH erstellen, austauschen und verarbeiten.

Ehscda ShareContent.png

Ehscda ShareContent.png

[Abbildung 8] „Share content“ Akteure gemäss IHE

IHE nennt in verschiedenen Inhaltsprofilen die Umsetzung mit den IHE Integrationsprofilen XDS.b, XDR, XDM.

Die IHE Integrationsprofile XDS und XDR realisieren die Interaktion „Share content“ mit der IHE Transaktion „Provide and Register Document Set-b [ITI-41]“, nennen aber die Akteure unterschiedlich:

Ehscda ITI-41 XDS.png

Ehscda ITI-41 XDS.png

[Abbildung 9] „Share content“ Akteure und Transaktionen (konkret für XDS)

Ehscda ITI-41 XDR.png

Ehscda ITI-41 XDR.png

[Abbildung 10] „Share content“ Akteure und Transaktionen (konkret für XDR)

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

Ehscda ITI-32 XDM.png

Ehscda ITI-32 XDM.png

[Abbildung 11] „Share content“ Akteure und Transaktionen (konkret für XDM)

Bei allen oben genannten Transaktionen für XDS, XDR und XDM ist der Inhalt des übertragenen Dokuments (Content) identisch und gemäss Kapitel #Spezifikation (normativ) aufgebaut. Für eine genaue Beschreibung der Akteure, Transaktionen und Inhalte verweisen wir auf die IHE Dokumentation [IHE ITI TF-2b] [1] , 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 Struktur

CDA Document Level Templates

CDA-CH v2.0 - structuredBody

Id2.16.756.5.30.1.1.10.1.9Effective Date2018‑04‑18
StatusKgreen.png ActiveVersion Label2017
NameCDA-CHv2.0-structuredBodyDisplay NameCDA-CH v2.0 - structuredBody
Description
This document template is used as the primary base for CDA-CH exchange formats. All CDA-CH V2 derivatives, i.e. Swiss exchange formats SHALL use this template by specialisation.
It only specifies the usage of CDA header templates. It requires a structured CDA body, but does not define any CDA body rules. For CDA body rules, see the derived exchange formats.
ContextPathname //
ClassificationCDA Document Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 0 templates, Uses 3 templates
Uses as NameVersion
2.16.756.5.30.1.1.10.2.25IncludeKgreen.png Document Realm (2017)DYNAMIC
2.16.756.5.30.1.1.10.2.18IncludeKgreen.png Document Template Ids CDA-CH v2.0 - structuredBody (2017)DYNAMIC
2.16.756.5.30.1.1.10.9.36IncludeKgreen.png CDA-CH v2.0 Header Template Compilation (2017)DYNAMIC
RelationshipSpecialization: template 2.16.840.1.113883.10.12.2 (2005‑09‑07)
Example
Example
<!-- The following line is required in a CDA-CH document. It is commented here due to ART-DECOR validation issues, only -->
<!-- <?xml version="1.0" encoding="UTF-8"?> -->
<ClinicalDocument>
  <!-- include template cdach_header_DocumentRealm[2.16.756.5.30.1.1.10.2.25] '?' (dynamic) 1..1 M -->
  <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/>  <!-- CDA-CH v2.0 ART-DECOR model - structuredBody. -->
  <templateId root="2.16.756.5.30.1.1.10.1.9"/>  <!-- include template cdach_header_DocumentTemplateIdsCdaChV2StructuredBody[2.16.756.5.30.1.1.10.2.18] '?' (dynamic) -->
  <!-- include template cdach_other_HeaderTemplates[2.16.756.5.30.1.1.10.9.36] '?' (dynamic) -->
  <component>
    <structuredBody>
      <component/>    </structuredBody>
  </component>
</ClinicalDocument>
ItemDTCardConfDescriptionLabel
hl7:ClinicalDocument
1 … 1M

This document template is used as the primary base for CDA-CH exchange formats. It only specifies the usage of CDA header templates. It requires a structured CDA body, but does not define any CDA body rules. For CDA body rules, see the derived exchange formats.

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...ody)
Included1 … 1M from 2.16.756.5.30.1.1.10.2.25 Document Realm (DYNAMIC)
Treetree.pnghl7:realmCode
CS1 … 1MSwiss Realm (CHE) of HL7 CDA. CDA‑CH V2
Treeblank.pngTreetree.png@code
CONF1 … 1FCHE
Treetree.pnghl7:typeId
II1 … 1MHL7 CDA R2, 2005(CDA...ody)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.1.3
Treeblank.pngTreetree.png@extension
st1 … 1FPOCD_HD000040
Treetree.pnghl7:templateId
II1 … 1MCDA-CH v2.0 ART-DECOR model - structuredBody.(CDA...ody)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.1.9
Included from 2.16.756.5.30.1.1.10.2.18 Document Template Ids CDA-CH v2.0 - structuredBody (DYNAMIC)
Treetree.pnghl7:templateId
II0 … 1CDA-CH v2.0 specification. This is an informational reference, only.CDA‑CH V2
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.1.1.4
Treetree.pnghl7:templateId
II1 … 1MHL7 CDA R2 (2005); contains ClinicalDocument.component as structuredBody.CDA‑CH V2
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.10.12.2
Treetree.pnghl7:templateId
II1 … 1MHL7 CDA R2 (2005).CDA‑CH V2
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.10.12.1
Included from 2.16.756.5.30.1.1.10.9.36 CDA-CH v2.0 Header Template Compilation (DYNAMIC)
Included1 … 1M from 2.16.756.5.30.1.1.10.2.23 Document Id (DYNAMIC)
Treetree.pnghl7:id
II1 … 1MA unique identifier for each CDA document instance.CDA‑CH V2
Treeblank.pngTreetree.png@root
uid1 … 1RThe document's id as Globally Unique Identifier (GUID).
Treeblank.pngTreetree.png@extension
st0NPNP/not present
Included1 … 1M from 2.16.756.5.30.1.1.10.2.44 Document Code (DYNAMIC)
Treetree.pnghl7:code
CE1 … 1MA LOINC based document type of a CDA document instance including a translation to the Swiss EPR XDS.b metadata.CDA‑CH V2
Treeblank.pngTreetree.png@code
cs1 … 1RThe exact value of @code MUST be specified by the CDA-CH V2 derivative.
Treeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.6.1
Treeblank.pngTreetree.png@codeSystemName
st1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
st1 … 1RThe exact value of @displayName MUST be specified by the CDA-CH V2 derivative.
Treeblank.pngTreetree.pnghl7:translation
CD1 … 1RA translation to the Swiss EPR XDS.b metadata. The exact value of @code and @displayName MUST be specified by the CDA-CH V2 derivative.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1RThe exact value of @code MUST be specified by the CDA-CH V2 derivative.
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.6.96
Treeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FSNOMED CT
Treeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1RThe exact value of @displayName MUST be specified by the CDA-CH V2 derivative.
 CONF
The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.27 EprDocumentTypeCode (DYNAMIC)
Treetree.pnghl7:title
ST1 … 1MThe expected titles (at least in English, German, French and Italian) MUST be specified by the CDA-CH V2 derivative.CDA‑CH V2
Treetree.pnghl7:effectiveTime
TS.CH.TZ1 … 1MThe document's creation date and time. If this document replaces a previous version (linked via parentDocument), this is the date and time of the new version.CDA‑CH V2
Included1 … 1M from 2.16.756.5.30.1.1.10.2.19 Document Confidentiality Code (DYNAMIC)
Treetree.pnghl7:confidentialityCode
CE (required)1 … 1MSwiss Realm of Confidentiality Code according to the Swiss EPR regulation.CDA‑CH V2
Treeblank.pngTreetree.png@code
cs1 … 1RThe value of @code MUST be drawn from value set EprDocumentConfidentialityCode (2.16.756.5.30.1.127.3.10.1.5)
Treeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.6.96
Treeblank.pngTreetree.png@codeSystemName
st1 … 1FSNOMED CT
Treeblank.pngTreetree.png@displayName
st1 … 1RThe 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 EprDocumentConfidentialityCode (DYNAMIC)
Included1 … 1M from 2.16.756.5.30.1.1.10.2.22 Document Language (DYNAMIC)
Treetree.pnghl7:language​Code
CS1 … 1MThe 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
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.11526 HumanLanguage (DYNAMIC)
Included from 2.16.756.5.30.1.1.10.2.20 Document Set Id and Version Number (DYNAMIC)
Treetree.pnghl7:setId
II1 … 1RThe 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
Treeblank.pngTreetree.png@root
uid1 … 1RThe root attribute MUST contain the setId as Globally Unique Identifier (GUID).
Treeblank.pngTreetree.png@extension
st0NPNP/not present
 Schematron assertroleKred.png 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)))) 
 MessageThe setId MUST be equal with the document id for version 1 and it MUST differ for all other versions. 
Treetree.pnghl7:versionNumber
INT.​NONNEG1 … 1RThe 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
Included1 … 1R from 2.16.756.5.30.1.1.10.2.1 Patient - recordTarget (DYNAMIC)
Treetree.pnghl7:recordTarget
1 … 1R A human patient for whom this CDA document instance was created.
  • Target patient
    The HL7 CDA R2 (2005) standard allows multiple patients.
    In order to ensure that the information in a CDA document is unambiguously assigned to one and only patient, a CDA-CH V2 based document MUST contain exactly one patient.
    Special cases: In exceptional cases (e.g., new-born twins, both having jaundice), multiple documents MUST be created (all of the same content, but each with a unique patient).

  • Patient identifiers
    Multiple ids (patient identification number) MAY be declared.
    If multiple ids are known, it is highly recommended to declare all known ids. Especially in cases where the CDA document instance is kind of an answer to a preceding order (independent of its data format), all ids specified by the ordering system SHALL be declared in the CDA document instance. This allows the receiver to assign its internal patient identification.
    The patient identification number MUST be grouped with the OID of its assigning system. The patient identification number MUST be unique within the system identified by the OID.
    The declared OID MUST be found in one of the public OID registries, such as oid.refdata.ch (preferred), oid-info.com, hl7.org/oid, www.dimdi.de/static/de/klassi/oid/, gesundheit.gv.at/OID_Frontend/ etc.
    OIDs that can't be found in a public OID registry are NOT ALLOWED.

  • Pseudonymizing
    In special cases, the demographic data of the patient are not allowed to be transmitted or they have to be pseudonymized.
    While HL7 CDA or its derivatives like CDA-CH or Swiss exchange formats nevertheless require these elements in the XML structure, the affected values MUST be replaced by a nullFlavor of type "MSK" (masked), in order to support the required data format structure and simultaneously to shield the real data.

CDA‑CH V2
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.1
Treeblank.pngTreetree.pnghl7:patientRole
1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *RThe patient's id.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1RThe 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.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 The id itself. It MUST be unique within the issuing system.
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … *The patient's address.
Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *The patient's means of communication (phone, eMail, ...).CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:patient
1 … 1RContains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC)CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.png where [hl7:administrative​Gender​Code [concat(@code, @codeSystem) = doc('include/voc-2.16.756.5.30.1.127.3.10.1.25-DYNAMIC.xml')//valueSet [1]/conceptList/concept/concat(@code, @codeSystem) or @nullFlavor]]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CE1 … 1RThe patient's gender according to the Swiss EPR XDS.b metadata.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.1
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7 AdministrativeGender
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
 CONF
The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.25 EprGender (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.CH.TZ1 … 1RThe patient's birthdate.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:marital​Status​Code
CE0 … 1The patient's marital status.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.1.11.12212
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7 MaritalStatus
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.12212 MaritalStatus (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:translation
0 … *A translation of the code to another coding systemCDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:religious​Affiliation​Code
CE0 … 1The patient's religion.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs0 … 1FNAV
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st0 … 1 
Included0 … 1C from 2.16.756.5.30.1.1.10.9.49 Original Text Reference (DYNAMIC)
The human-readable text MUST be generated automatically from the structured information of this element. The text element MUST contain the reference to the corresponding text in the human readable part, ONLY.
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:originalText
ED0 … 1CCDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:reference
TEL1 … 1MThe reference to the corresponding text in the human readable part must be specified by reference to content[@ID]: reference[@value='#xxx']CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
1 … 1RReference to the narrative part of the section in the format '#xxx', where xxx is the ID of the corresponding <content></content> element.
 Schematron assertroleKred.png error 
 teststarts-with(@value,'#') 
 MessageThe @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding <content/> element. 
 Variable letNameidvalue 
 Valuesubstring-after(@value,'#') 
 Schematron assertroleKred.png error 
 testancestor::hl7:structuredBody//*[@ID=$idvalue] 
 MessageNo narrative text found for this reference (no content element within this document has an ID that corresponds to '<value-of select="$idvalue"/>'). 
 Schematron assertroleKred.png error 
 testparent::*/text()=ancestor::hl7:structuredBody//*[@ID=$idvalue]/text() 
 MessageThe originalText content MUST be identical to the narrative text for this reference. 
 Schematron assertroleKred.png error 
 test(@nullFlavor='NAV' and originalText and not(@codeSystem or @codeSystemName or @code or @displayName)) or (@codeSystem and @codeSystemName and @code and @displayName) 
 MessageEither a code described by code, codeSystem, codeSystemName and displayName or originalText and nullFlavor="NAV" is REQUIRED. 
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian
0 … *The patient's guardian.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *The guardian's id.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1RThe 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.
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 The id itself. It MUST be unique within the issuing system.
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1The guardian's role.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid0 … 1F2.16.840.1.113883.5.111
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1FHL7RoleCode
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st0 … 1 
 Schematron assertroleKred.png error 
 test(not(@nullFlavor) and @displayName and @code and @codeSystem and @codeSystemName) or (@nullFlavor and not(@displayName or @code or @codeSystem or @codeSystemName)) 
 MessageEither nullFlavor or a valid code is required. 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … *The guardian's address.
Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *The guardian's means of communication (phone, eMail, ...).CDA‑CH V2
Choice1 … 1Elements to choose from:
  • hl7:guardian​Person containing template 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC)
  • hl7:guardian​Organization containing template 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Person
The guardian's as a person.
Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Organization
The guardian's as an organization.
Contains 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:birthplace
0 … 1The patient's birthplace.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:place
1 … 1CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
EN0 … 1The patient's birthplace name.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1RThe patient's birthplace address.
Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:language​Communication
0 … *The patient's language skills.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:language​Code
CS1 … 1CDA‑CH V2
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.11526 HumanLanguage (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:modeCode
CE0 … 1CDA‑CH V2
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.12249 LanguageAbilityMode (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:proficiency​Level​Code
CE0 … 1CDA‑CH V2
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.12199 LanguageAbilityProficiency (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:preference​Ind
BL0 … 1In case of @value=true it is the patient's correspondence language.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:providerOrganization
0 … 1The organization who took care of the patient in the same context with the current CDA document. E.g. entry of the Medreg, FMH Index or the Health Organisation Index (HOI) of the Swiss EPR.
Contains 2.16.756.5.30.1.1.10.9.30 Organization Compilation with GLN and name (DYNAMIC)
CDA‑CH V2
Included1 … *M from 2.16.756.5.30.1.1.10.9.23 Author (DYNAMIC)
Treetree.pnghl7:author
1 … *MInformation about the author of a CDA document, section or entry. An author MAY be a person or a device.CDA‑CH V2
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.9.23
Treeblank.pngTreetree.pnghl7:functionCode
CE1 … 1R

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‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@nullFlavor
st0 … 1FNAV
Treeblank.pngTreeblank.pngTreetree.png@code
cs0 … 1 
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
oid0 … 1F2.16.840.1.113883.6.96
Treeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1FSNOMED CT
Treeblank.pngTreeblank.pngTreetree.png@displayName
st0 … 1 
 CONF
The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.1.3 EprAuthorRole (DYNAMIC)
 Example
Patient
<functionCode code="116154003" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Patient"/>
 Example
Nurse
<functionCode code="106292003" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Professional nurse"/>
 Example
Home helper
<functionCode nullFlavor="NAV">
  <originalText>Home helper</originalText></functionCode>
 Example
Laboratory technician
<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 assertroleKred.png error 
 test(@code and @codeSystem) or (@nullFlavor='NAV') 
 MessageEither a code with its code system or nullFlavor='NAV' is required. 
 Schematron assertroleKred.png error 
 testnot(@nullFlavor) or (hl7:originalText) 
 MessageOther Caregivers description MUST be declared in the originalText element in case of nullFlavor. 
Treeblank.pngTreeblank.pngTreetree.pnghl7: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‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreetree.pnghl7:time
TS.CH.TZ1 … 1RTimestamp of the authorship.CDA‑CH V2
Treeblank.pngTreetree.pnghl7:assignedAuthor
1 … 1RCDA‑CH V2
 Schematron assertroleKred.png error 
 testnot(assignedAuthoringDevice/softwareName) or (representedOrganization) 
 MessageFor device authors the element representedOrganization is REQUIRED. 
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1R 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‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs0 … 1FNAV
 Temporarily unknown, will be filled later.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
cs0 … 1F2.51.1.3
 OID for GS1 GLN.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 The GS1 GLN.
 Schematron assertroleKred.png error 
 test(@root='2.51.1.3' and @extension) or (@nullFlavor='NAV') 
 MessageEither the GS1 GLN or nullFlavor='NAV' is REQUIRED 
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *Other ids are allowed.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
cs1 … 1RThe 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.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 Contains the ID itself. The ID MUST be unique within the system that issued the ID.
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … *The author's address.
Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *The author's means of communication (phone, eMail, ...).CDA‑CH V2
Choice1 … 1Elements 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
0 … 1The author as a person.
Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Authoring​Device
0 … 1The author as a device.
Contains 2.16.756.5.30.1.1.10.9.21 Device Compilation with name (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
0 … 1The author's organization.
Contains 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC)
CDA‑CH V2
Included0 … 1 from 2.16.756.5.30.1.1.10.2.7 Data Enterer (DYNAMIC)
Treetree.pnghl7:dataEnterer
0 … 1Information 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
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.7
Treeblank.pngTreetree.pnghl7:time
TS.CH.TZ0 … 1Timestamp of the data input.CDA‑CH V2
Treeblank.pngTreetree.pnghl7:assignedEntity
1 … 1RContains 2.16.756.5.30.1.1.10.9.12 Assigned Entity Compilation with id (DYNAMIC)CDA‑CH V2
Included0 … * from 2.16.840.1.113883.10.12.154 CDA Informant (DYNAMIC)
Treetree.pnghl7:informant
0 … *CDA‑CH V2
Treeblank.pngTreetree.png@typeCode
0 … 1FINF
Treeblank.pngTreetree.png@context​Control​Code
0 … 1FOP
Choice1 … 1Elements to choose from:
  • hl7:assignedEntity containing template 2.16.840.1.113883.10.12.153 CDA AssignedEntity (DYNAMIC)
  • hl7:relatedEntity containing template 2.16.840.1.113883.10.12.316 CDA RelatedEntity (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assignedEntity
Contains 2.16.840.1.113883.10.12.153 CDA AssignedEntity (DYNAMIC)CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:relatedEntity
Contains 2.16.840.1.113883.10.12.316 CDA RelatedEntity (DYNAMIC)CDA‑CH V2
Included1 … 1R from 2.16.756.5.30.1.1.10.2.3 Custodian (DYNAMIC)
Treetree.pnghl7:custodian
1 … 1RThe organization in whose name this CDA document has been created (corresponds to the sender of a letter).CDA‑CH V2
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.3
Treeblank.pngTreetree.pnghl7:assignedCustodian
1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Custodian​Organization
1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *MThe custodian's id.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1RThe 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.
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 Contains the ID itself. The ID MUST be unique within the system that issued the ID.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1RThe custodian's name.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *The custodian's means of communication (phone, eMail, ...).CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … *The custodian's address(es).
Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC)
CDA‑CH V2
Included1 … *M from 2.16.756.5.30.1.1.10.2.4 Recipient - informationRecipient (DYNAMIC)
Treetree.pnghl7:information​Recipient
1 … *M A recipient of this CDA document (corresponds to the addressee of a letter - person or organization).

Recipient types:
  • The main recipient of the document is indicated by typeCode 'PRCP' (primary recipient).
    Note: Since it makes no sense to create a CDA document without doing it for someone, in Switzerland at least one recipient MUST be declared. If the document is created for the user's own needs, the user itself or its organization will be the primary recipient.

  • Other recipients (copy to; Cc) are indicated with typeCode, TRC '(secondary recipient).
CDA‑CH V2
Treeblank.pngTreetree.png@typeCode
cs0 … 1 The main recipient of the document is indicated by typeCode 'PRCP' (primary recipient). This is the default value used when the attribute is not present.
Other recipients (copy to; Cc) are indicated with typeCode, TRC '(secondary recipient).
Note: Since it makes no sense to create a CDA document without doing it for someone, in Switzerland at least one recipient MUST be declared. If the document is created for the user's own needs, the user itself or its organization will be the primary recipient.
 CONF
The value of @typeCode shall be drawn from value set 2.16.840.1.113883.1.11.19366 x_InformationRecipient (DYNAMIC)
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.4
Treeblank.pngTreetree.pnghl7:intended​Recipient
1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *RThe recipient's identification(s).CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1RThe 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.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 Contains the ID itself. The ID MUST be unique within the system that issued the ID.
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … *The recipient's address(es).
Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *The recipient's means of communication (phone, eMail, ...).CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:information​Recipient
0 … 1The addressee person.
Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:received​Organization
0 … 1The addressee organization.
Contains 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC)
CDA‑CH V2
Included0 … 1 from 2.16.756.5.30.1.1.10.2.5 Legal Authenticator (DYNAMIC)
Treetree.pnghl7:legalAuthenticator
0 … 1Information about the legal authenticator of a CDA document. A legal authenticator MUST be a person.CDA‑CH V2
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.5
Treeblank.pngTreetree.pnghl7:time
TS.CH.TZ1 … 1RTimestamp of the signature.CDA‑CH V2
Treeblank.pngTreetree.pnghl7:signatureCode
CS1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1FS
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
oid0NPNP/not present
Treeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0NPNP/not present
Treeblank.pngTreeblank.pngTreetree.png@displayName
st0NPNP/not present
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC)
Treeblank.pngTreetree.pnghl7:assignedEntity
1 … 1RContains 2.16.756.5.30.1.1.10.9.12 Assigned Entity Compilation with id (DYNAMIC)CDA‑CH V2
Included0 … * from 2.16.756.5.30.1.1.10.2.6 Authenticator (DYNAMIC)
Treetree.pnghl7:authenticator
0 … *Information about an authenticator of a CDA document. An authenticator MUST be a person.CDA‑CH V2
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.6
Treeblank.pngTreetree.pnghl7:time
TS.CH.TZ1 … 1RTimestamp of the signature.CDA‑CH V2
Treeblank.pngTreetree.pnghl7:signatureCode
CS1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1FS
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
oid0NPNP/not present
Treeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0NPNP/not present
Treeblank.pngTreeblank.pngTreetree.png@displayName
st0NPNP/not present
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC)
Treeblank.pngTreetree.pnghl7:assignedEntity
1 … 1RContains 2.16.756.5.30.1.1.10.9.12 Assigned Entity Compilation with id (DYNAMIC)CDA‑CH V2
Included0 … * from 2.16.756.5.30.1.1.10.2.40 Employer - participant (DYNAMIC)
Treetree.pnghl7:participant
0 … *Information on the patient's employer, school or other affiliated (e.g., volunteer) organization.CDA‑CH V2
Treeblank.pngTreetree.png@typeCode
cs1 … 1FIND
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA-CH v2.0 ART-DECOR model of Employer.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.40
Treeblank.pngTreetree.pnghl7:templateId
1 … *MCH-PCC ART-DECOR model of IHE PCC Employer and School Contacts.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
cs1 … 1F2.16.756.5.30.1.1.10.2.41
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MIHE PCC Employer and School Contacts.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.3.6.1.4.1.19376.1.5.3.1.2.2
Treeblank.pngTreetree.pnghl7:time
IVL_TS.CH.TZ0 … 1Validity period of contract.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:low
TS.CH.TZ1 … 1RStart of the contract.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:high
TS.CH.TZ1 … 1REnd of the contract.CDA‑CH V2
Treeblank.pngTreetree.pnghl7:associated​Entity
1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1FCON
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1RThe id of the contract ([ge]: Mitarbeiternummer; [fr]: Numéro d'employé).CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1RThe 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.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 The id itself. It MUST be unique within the issuing system.
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F1.3.6.1.4.1.19376.1.5.3.3
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FIHERoleCode
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st0NPNP/not present
 CONF
The value of @code shall be drawn from value set 2.16.756.5.30.1.1.11.77 IHERoleCode Employer and School Contacts  (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
0 … 1Contact person at the employer, school or other affiliated (e.g., volunteer) organization.
Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:scoping​Organization
1 … 1The employer, school or other affiliated (e.g., volunteer) organization.
Contains 2.16.756.5.30.1.1.10.9.27 Organization Compilation with name, addr, telecom (DYNAMIC)
CDA‑CH V2
Included0 … * from 2.16.756.5.30.1.1.10.2.15 Insurance - participant (DYNAMIC)
Treetree.pnghl7:participant
0 … *Information on a patient's insurance.CDA‑CH V2
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOV
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.15
Treeblank.pngTreetree.pnghl7:time
IVL_TS.CH.TZ0 … 1Validity period of the contract.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:low
TS.CH.TZ1 … 1RStart of the contract.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:high
TS.CH.TZ1 … 1REnd of the contract.CDA‑CH V2
Treeblank.pngTreetree.pnghl7:associated​Entity
1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1FPAYOR
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1RThe id of the contract ([ge]: Versichertennummer; [fr]: Numéro d'assuré).CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1RThe 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.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 The id itself. It MUST be unique within the issuing system.
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE1 … 1RThe underlying law for the contract.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs0 … 1FNAV
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs0 … 1 832.10, 832.20, 221.229.1, 833.1, 831.20
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid0 … 1F2.16.756.5.30.2.1.1.11
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1Fins-laws
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st0 … 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 assertroleKred.png 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) 
 MessageEither a valid insurance law or nullFlavor="NAV" is REQUIRED. 
Treeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
0 … 1Contact 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
Treeblank.pngTreeblank.pngTreetree.pnghl7:scoping​Organization
1 … 1The 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
Included0 … * from 2.16.756.5.30.1.1.10.2.14 Insurance Card - participant (DYNAMIC)
Treetree.pnghl7:participant
0 … *Information on a patient's insurance card.CDA‑CH V2
Treeblank.pngTreetree.png@typeCode
cs1 … 1FHLD
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.14
Treeblank.pngTreetree.pnghl7:time
IVL_TS.CH.TZ1 … 1RValidity period of the insurance card.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:low
TS.CH.TZ1 … 1CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FNASK
Treeblank.pngTreeblank.pngTreetree.pnghl7:high
TS.CH.TZ1 … 1RExpiration date of the insurance card.CDA‑CH V2
Treeblank.pngTreetree.pnghl7:associated​Entity
1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1FPOLHOLD
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1RThe insurance card's id.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.123.100.1.1.1
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1RNumber of the insurance card.
Treeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
0 … 1Family 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
Treeblank.pngTreeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1The 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
Included0 … * from 2.16.756.5.30.1.1.10.2.43 Patient Contact - participant (DYNAMIC)
Treetree.pnghl7:participant
0 … *Information on a patient contact.CDA‑CH V2
Treeblank.pngTreetree.png@typeCode
cs1 … 1FIND
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.43
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.3.6.1.4.1.19376.1.5.3.1.2.4
Treeblank.pngTreetree.pnghl7:time
IVL_TS.CH.TZ0 … 1Validity period of the participation.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:low
TS.CH.TZ1 … 1RStart of participation.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:high
TS.CH.TZ1 … 1REnd of participation.CDA‑CH V2
Treeblank.pngTreetree.pnghl7:associated​Entity
1 … 1REither the contact person or the contact's organization SHALL be present.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1R The classCode attribute SHALL be present, and contains a value from the following set:
AGNT: agents of the patient
CAREGIVER: care givers
ECON: emergency contacts
NOK: next of kin
PRS: other relations
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE1 … 1RThe contact's role.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid0 … 1F2.16.840.1.113883.5.111
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1FHL7RoleCode
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st0 … 1 
 Schematron assertroleKred.png error 
 test(not(@nullFlavor) and @displayName and @code and @codeSystem and @codeSystemName) or (@nullFlavor and not(@displayName or @code or @codeSystem or @codeSystemName)) 
 MessageEither nullFlavor or a valid code is required. 
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … *The contact's address.
Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *The contact's means of communication (phone, eMail, ...).CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
0 … 1CThe contact person.
Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1CThe contact's organization.
Contains 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC)
CDA‑CH V2
 Schematron assertroleKred.png error 
 test@classCode=('AGNT','CAREGIVER','ECON','NOK','PRS') 
 MessageThe classCode attribute shall be present, and contains a value from the set AGNT, CAREGIVER, ECON, NOK, or PRS to identify contacts that are agents of the patient, care givers, emergency contacts, next of kin, or other relations respectively.  
Included0 … * from 2.16.756.5.30.1.1.10.2.16 Order Reference - inFulfillmentOf (DYNAMIC)
Treetree.pnghl7:inFulfillmentOf
0 … *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
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.16
Treeblank.pngTreetree.pnghl7:order
1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *ROrder number.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1REither the same GUID (order id) or the same OID (order issuing system) as the order itself.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 Contains the order ID itself. The ID MUST be unique within the system that issued the ID.
Included0 … * from 2.16.756.5.30.1.1.10.2.46 Health Service - documentationOf (DYNAMIC)
Treetree.pnghl7:documentationOf
0 … *Information about a health service describing the context of this CDA document.CDA‑CH V2
Treeblank.pngTreetree.png@typeCode
cs1 … 1FDOC
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.46
Treeblank.pngTreetree.pnghl7:serviceEvent
1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs1 … 1FACT
Treeblank.pngTreeblank.pngTreetree.png@moodCode
cs1 … 1FEVN
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *Health service identifiers such as case number ([ge]: Fallnummer; [fr]: Numéro de cas), consultation id, episode id, etc.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1RThe 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.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 The id itself. It MUST be unique within the issuing system.
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE1 … 1RAs 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
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
st1 … 1FNAV
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs0NPNP/not present
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid0NPNP/not present
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0NPNP/not present
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st0NPNP/not present
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:translation
0 … *A translation of the code to another coding system.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreeblank.pngTreetree.pnghl7:effectiveTime
IVL_TS.CH.TZ1 … 1RDuration of the health service.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
TS.CH.TZ1 … 1RStart of the health service.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:high
TS.CH.TZ1 … 1REnd of the health service.CDA‑CH V2
Included0 … * from 2.16.756.5.30.1.1.10.9.31 Performer (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:performer
0 … *Information about a healthcare provider who was the primary performer of the act.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
cs1 … 1FPRF
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.9.31
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:templateId
1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.3.6.1.4.1.19376.1.5.3.1.1.24.3.5
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:functionCode
CE1 … 1R 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, the code 133932002 (Other Caregiver) MUST be used. In this case, the originalText element MUST contain the description of the role.
Translations to other vocabularies are allowed.
CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.6.96
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FSNOMED CT
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
 CONF
The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.1.3 EprAuthorRole (DYNAMIC)
 Example<functionCode code="106292003" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Professional nurse"/>
 Example<functionCode code="133932002" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Other Caregiver">
  <originalText>Home helper</originalText></functionCode>
 Example<functionCode code="133932002" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Other Caregiver">
  <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 assertroleKred.png error 
 testnot(@code='133932002') or (hl7:originalText/text()) 
 MessageOther Caregivers description MUST be declared in the originalText element. 
Included0 … 1C from 2.16.756.5.30.1.1.10.9.49 Original Text Reference (DYNAMIC)
The human-readable text MUST be generated automatically from the structured information of this element. The text element MUST contain the reference to the corresponding text in the human readable part, ONLY.
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:originalText
ED0 … 1CCDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:reference
TEL1 … 1MThe reference to the corresponding text in the human readable part must be specified by reference to content[@ID]: reference[@value='#xxx']CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
1 … 1RReference to the narrative part of the section in the format '#xxx', where xxx is the ID of the corresponding <content></content> element.
 Schematron assertroleKred.png error 
 teststarts-with(@value,'#') 
 MessageThe @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding <content/> element. 
 Variable letNameidvalue 
 Valuesubstring-after(@value,'#') 
 Schematron assertroleKred.png error 
 testancestor::hl7:structuredBody//*[@ID=$idvalue] 
 MessageNo narrative text found for this reference (no content element within this document has an ID that corresponds to '<value-of select="$idvalue"/>'). 
 Schematron assertroleKred.png error 
 testparent::*/text()=ancestor::hl7:structuredBody//*[@ID=$idvalue]/text() 
 MessageThe originalText content MUST be identical to the narrative text for this reference. 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7: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‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:time
IVL_TS.CH.TZ0 … 1Duration of the performance.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
TS.CH.TZ1 … 1RStart of the performance.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:high
TS.CH.TZ1 … 1REnd of the performance.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:assignedEntity
1 … 1RContains 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
Included0 … * from 2.16.756.5.30.1.1.10.2.13 Document Replacement - relatedDocument (DYNAMIC)
Treetree.pnghl7: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
Treeblank.pngTreetree.png@typeCode
cs1 … 1FRPLC
 Indicates that it is a relationship to another document that needs to be replaced.
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.13
Treeblank.pngTreetree.pnghl7:parentDocument
1 … 1RRelationship to the document that needs to be replaced.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1MThe id of the document to be replaced MUST be declared.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1RThe id (GUID) of the document to be replaced.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0NPNP/not present
Treeblank.pngTreeblank.pngTreetree.pnghl7:setId
II1 … 1MThe setId of the document to be replaced MUST be declared.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0NPNP/not present
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1RThe setId (GUID) of the document to be replaced and MUST be identical with the content of the setId of the current document.
 Schematron assertroleKred.png error 
 test(@root=/hl7:ClinicalDocument/hl7:id/@root) and not(@extension) and not(/hl7:ClinicalDocument/hl7:id/@extension) 
 MessageClinicalDocument/setId: MUST be identical to the one of the replaced document 
Treeblank.pngTreeblank.pngTreetree.pnghl7:versionNumber
INT1 … 1MThe version number of the document to be replaced.CDA‑CH V2
 Schematron assertroleKred.png error 
 test@value > /hl7:ClinicalDocument/hl7:versionNumber/@value 
 MessageClinicalDocument/versionNumber: MUST be higher than the one of the replaced document 
Included0 … * from 2.16.840.1.113883.10.12.114 CDA Authorization (DYNAMIC)
Treetree.pnghl7:authorization
0 … *CDA‑CH V2
Treeblank.pngTreetree.png@typeCode
0 … 1FAUTH
Treeblank.pngTreetree.pnghl7:consent
1 … 1CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FCONS
Treeblank.pngTreeblank.pngTreetree.png@moodCode
0 … 1FEVN
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
CONF0 … 1F2.16.840.1.113883.5.4 (Act Code)
Treeblank.pngTreeblank.pngTreetree.pnghl7:statusCode
CS1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
CONF0 … 1Fcompleted
Included0 … 1 from 2.16.840.1.113883.10.12.113 CDA componentOf (DYNAMIC)
Treetree.pnghl7:componentOf
0 … 1CDA‑CH V2
Treeblank.pngTreetree.png@typeCode
0 … 1FCOMP
Treeblank.pngTreetree.pnghl7:encompassing​Encounter
1 … 1CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FENC
Treeblank.pngTreeblank.pngTreetree.png@moodCode
0 … 1FEVN
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1CDA‑CH V2
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.13955 ActEncounterCode (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:effectiveTime
IVL_TS1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:discharge​Disposition​Code
CE0 … 1CDA‑CH V2
 CONF
shall be drawn from concept domain "EncounterDischargeDisposition"
Treeblank.pngTreeblank.pngTreetree.pnghl7:responsible​Party
0 … 1Contains 2.16.840.1.113883.10.12.153 CDA AssignedEntity (DYNAMIC)CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
0 … 1FRESP
Treeblank.pngTreeblank.pngTreetree.pnghl7:encounterParticipant
0 … *CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
cs1 … 1R
 CONF
The value of @typeCode shall be drawn from value set 2.16.840.1.113883.1.11.19600 x_EncounterParticipant (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:time
IVL_TS0 … 1CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:assignedEntity
1 … 1Contains 2.16.840.1.113883.10.12.153 CDA AssignedEntity (DYNAMIC)CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:location
0 … 1CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
0 … 1FLOC
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:health​Care​Facility
1 … 1CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FSDLOC
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1CDA‑CH V2
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.17660 ServiceDeliveryLocationRoleType (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:location
0 … 1Contains 2.16.840.1.113883.10.12.317 CDA Place (DYNAMIC)CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:service​Provider​Organization
0 … 1Contains 2.16.840.1.113883.10.12.151 CDA Organization (DYNAMIC)CDA‑CH V2
Treetree.pnghl7:component
1 … 1R(CDA...ody)
Treeblank.pngTreetree.pnghl7:structuredBody
1 … 1R(CDA...ody)
Treeblank.pngTreeblank.pngTreetree.pnghl7:component
1 … *R(CDA...ody)
 Schematron assertroleKorange.png warning 
 testnot(//hl7:id[@root='2.16.756.5.30.1.127.3.10.3']) 
 MessageThis CDA-CH V2 document contains a Swiss EPR-SPID. Please make sure, that this fits the legal base. 
 Schematron reportroleKorange.png warning 
 test//hl7:id[@root=('2.16.756.5.31', '2.16.756.5.32')]/parent::hl7:patientRole 
 MessageThis CDA-CH V2 document contains a Swiss Social Security number as patient identifier. Please make sure, that this fits the legal base. 
 Schematron assertroleKred.png error 
 testnot(//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)]) 
 MessageSwiss EPR-SPID and Social Security numbers are not allowed in CDA-CH V2 documents for other objects than the patient. 

CDA-CH v2.0 - nonXMLBody

Id2.16.756.5.30.1.1.10.1.12Effective Date2018‑04‑18
StatusKgreen.png ActiveVersion Label2017
NameCDA-CHv2.0-nonXMLBodyDisplay NameCDA-CH v2.0 - nonXMLBody
Description
This document template MAY be referenced or specialized for specific, not further described use cases. CDA-CH V2 derivatives, i.e. Swiss exchange formats SHOULDN'T use this template, as they better refer to the document level template requiring a structured body. It only specifies the usage of CDA header templates. It requires a non XML CDA body, but does not define any CDA body rules. For CDA body rules, see the derived exchange formats.
ContextPathname //
ClassificationCDA Document Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 0 templates, Uses 3 templates
Uses as NameVersion
2.16.756.5.30.1.1.10.2.25IncludeKgreen.png Document Realm (2017)DYNAMIC
2.16.756.5.30.1.1.10.2.47IncludeKgreen.png Document Template Ids CDA-CH v2.0 - nonXMLBody (2017)DYNAMIC
2.16.756.5.30.1.1.10.9.36IncludeKgreen.png CDA-CH v2.0 Header Template Compilation (2017)DYNAMIC
RelationshipSpecialization: template 2.16.840.1.113883.10.12.3 (2005‑09‑07)
Example
Example
<!-- The following line is required in a CDA-CH document. It is commented here due to ART-DECOR validation issues, only -->
<!-- <?xml version="1.0" encoding="UTF-8"?> -->
<ClinicalDocument>
  <!-- include template cdach_header_DocumentRealm[2.16.756.5.30.1.1.10.2.25] '?' (dynamic) 1..1 M -->
  <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/>  <!-- include template cdach_header_DocumentTemplateIdsCdaChV2NonXmlBody[2.16.756.5.30.1.1.10.2.47] '?' (dynamic) -->
  <!-- include template cdach_other_HeaderTemplates[2.16.756.5.30.1.1.10.9.36] '?' (dynamic) -->
  <component contextConductionInd="false">
    <nonXMLBody>
      <text/>      <confidentialityCode/>      <languageCode/>    </nonXMLBody>
  </component>
</ClinicalDocument>
ItemDTCardConfDescriptionLabel
hl7:ClinicalDocument
1 … 1M

This document template MAY be referenced or specialized for specific, not further described use cases. It only specifies the usage of CDA header templates. It requires a non XML CDA body, but does not define any CDA body rules. For CDA body rules, see the derived exchange formats.

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...ody)
Included1 … 1M from 2.16.756.5.30.1.1.10.2.25 Document Realm (DYNAMIC)
Treetree.pnghl7:realmCode
CS1 … 1MSwiss Realm (CHE) of HL7 CDA. CDA‑CH V2
Treeblank.pngTreetree.png@code
CONF1 … 1FCHE
Treetree.pnghl7:typeId
II1 … 1MHL7 CDA R2, 2005(CDA...ody)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.1.3
Treeblank.pngTreetree.png@extension
st1 … 1FPOCD_HD000040
Included from 2.16.756.5.30.1.1.10.2.47 Document Template Ids CDA-CH v2.0 - nonXMLBody (DYNAMIC)
Treetree.pnghl7:templateId
II0 … 1CDA-CH v2.0 specification. This is an informational reference, only.CDA‑CH V2
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.1.1.4
Treetree.pnghl7:templateId
II1 … 1MCDA-CH v2.0 ART-DECOR model - nonXMLBody.CDA‑CH V2
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.1.12
Treetree.pnghl7:templateId
II1 … 1MHL7 CDA R2 (2005); contains ClinicalDocument.component as nonXMLBody.CDA‑CH V2
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.10.12.3
Treetree.pnghl7:templateId
II1 … 1MHL7 CDA R2 (2005).CDA‑CH V2
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.10.12.1
Included from 2.16.756.5.30.1.1.10.9.36 CDA-CH v2.0 Header Template Compilation (DYNAMIC)
Included1 … 1M from 2.16.756.5.30.1.1.10.2.23 Document Id (DYNAMIC)
Treetree.pnghl7:id
II1 … 1MA unique identifier for each CDA document instance.CDA‑CH V2
Treeblank.pngTreetree.png@root
uid1 … 1RThe document's id as Globally Unique Identifier (GUID).
Treeblank.pngTreetree.png@extension
st0NPNP/not present
Included1 … 1M from 2.16.756.5.30.1.1.10.2.44 Document Code (DYNAMIC)
Treetree.pnghl7:code
CE1 … 1MA LOINC based document type of a CDA document instance including a translation to the Swiss EPR XDS.b metadata.CDA‑CH V2
Treeblank.pngTreetree.png@code
cs1 … 1RThe exact value of @code MUST be specified by the CDA-CH V2 derivative.
Treeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.6.1
Treeblank.pngTreetree.png@codeSystemName
st1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
st1 … 1RThe exact value of @displayName MUST be specified by the CDA-CH V2 derivative.
Treeblank.pngTreetree.pnghl7:translation
CD1 … 1RA translation to the Swiss EPR XDS.b metadata. The exact value of @code and @displayName MUST be specified by the CDA-CH V2 derivative.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1RThe exact value of @code MUST be specified by the CDA-CH V2 derivative.
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.6.96
Treeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FSNOMED CT
Treeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1RThe exact value of @displayName MUST be specified by the CDA-CH V2 derivative.
 CONF
The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.27 EprDocumentTypeCode (DYNAMIC)
Treetree.pnghl7:title
ST1 … 1MThe expected titles (at least in English, German, French and Italian) MUST be specified by the CDA-CH V2 derivative.CDA‑CH V2
Treetree.pnghl7:effectiveTime
TS.CH.TZ1 … 1MThe document's creation date and time. If this document replaces a previous version (linked via parentDocument), this is the date and time of the new version.CDA‑CH V2
Included1 … 1M from 2.16.756.5.30.1.1.10.2.19 Document Confidentiality Code (DYNAMIC)
Treetree.pnghl7:confidentialityCode
CE (required)1 … 1MSwiss Realm of Confidentiality Code according to the Swiss EPR regulation.CDA‑CH V2
Treeblank.pngTreetree.png@code
cs1 … 1RThe value of @code MUST be drawn from value set EprDocumentConfidentialityCode (2.16.756.5.30.1.127.3.10.1.5)
Treeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.6.96
Treeblank.pngTreetree.png@codeSystemName
st1 … 1FSNOMED CT
Treeblank.pngTreetree.png@displayName
st1 … 1RThe 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 EprDocumentConfidentialityCode (DYNAMIC)
Included1 … 1M from 2.16.756.5.30.1.1.10.2.22 Document Language (DYNAMIC)
Treetree.pnghl7:language​Code
CS1 … 1MThe 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
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.11526 HumanLanguage (DYNAMIC)
Included from 2.16.756.5.30.1.1.10.2.20 Document Set Id and Version Number (DYNAMIC)
Treetree.pnghl7:setId
II1 … 1RThe 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
Treeblank.pngTreetree.png@root
uid1 … 1RThe root attribute MUST contain the setId as Globally Unique Identifier (GUID).
Treeblank.pngTreetree.png@extension
st0NPNP/not present
 Schematron assertroleKred.png 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)))) 
 MessageThe setId MUST be equal with the document id for version 1 and it MUST differ for all other versions. 
Treetree.pnghl7:versionNumber
INT.​NONNEG1 … 1RThe 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
Included1 … 1R from 2.16.756.5.30.1.1.10.2.1 Patient - recordTarget (DYNAMIC)
Treetree.pnghl7:recordTarget
1 … 1R A human patient for whom this CDA document instance was created.
  • Target patient
    The HL7 CDA R2 (2005) standard allows multiple patients.
    In order to ensure that the information in a CDA document is unambiguously assigned to one and only patient, a CDA-CH V2 based document MUST contain exactly one patient.
    Special cases: In exceptional cases (e.g., new-born twins, both having jaundice), multiple documents MUST be created (all of the same content, but each with a unique patient).

  • Patient identifiers
    Multiple ids (patient identification number) MAY be declared.
    If multiple ids are known, it is highly recommended to declare all known ids. Especially in cases where the CDA document instance is kind of an answer to a preceding order (independent of its data format), all ids specified by the ordering system SHALL be declared in the CDA document instance. This allows the receiver to assign its internal patient identification.
    The patient identification number MUST be grouped with the OID of its assigning system. The patient identification number MUST be unique within the system identified by the OID.
    The declared OID MUST be found in one of the public OID registries, such as oid.refdata.ch (preferred), oid-info.com, hl7.org/oid, www.dimdi.de/static/de/klassi/oid/, gesundheit.gv.at/OID_Frontend/ etc.
    OIDs that can't be found in a public OID registry are NOT ALLOWED.

  • Pseudonymizing
    In special cases, the demographic data of the patient are not allowed to be transmitted or they have to be pseudonymized.
    While HL7 CDA or its derivatives like CDA-CH or Swiss exchange formats nevertheless require these elements in the XML structure, the affected values MUST be replaced by a nullFlavor of type "MSK" (masked), in order to support the required data format structure and simultaneously to shield the real data.

CDA‑CH V2
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.1
Treeblank.pngTreetree.pnghl7:patientRole
1 … 1RCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *RThe patient's id.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1RThe 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.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 The id itself. It MUST be unique within the issuing system.
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … *The patient's address.
Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *The patient's means of communication (phone, eMail, ...).CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:patient
1 … 1RContains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC)CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.png where [hl7:administrative​Gender​Code [concat(@code, @codeSystem) = doc('include/voc-2.16.756.5.30.1.127.3.10.1.25-DYNAMIC.xml')//valueSet [1]/conceptList/concept/concat(@code, @codeSystem) or @nullFlavor]]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CE1 … 1RThe patient's gender according to the Swiss EPR XDS.b metadata.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.1
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7 AdministrativeGender
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
 CONF
The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.25 EprGender (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.CH.TZ1 … 1RThe patient's birthdate.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:marital​Status​Code
CE0 … 1The patient's marital status.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.1.11.12212
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7 MaritalStatus
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.12212 MaritalStatus (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:translation
0 … *A translation of the code to another coding systemCDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:religious​Affiliation​Code
CE0 … 1The patient's religion.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs0 … 1FNAV
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st0 … 1 
Included0 … 1C from 2.16.756.5.30.1.1.10.9.49 Original Text Reference (DYNAMIC)
The human-readable text MUST be generated automatically from the structured information of this element. The text element MUST contain the reference to the corresponding text in the human readable part, ONLY.
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:originalText
ED0 … 1CCDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:reference
TEL1 … 1MThe reference to the corresponding text in the human readable part must be specified by reference to content[@ID]: reference[@value='#xxx']CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
1 … 1RReference to the narrative part of the section in the format '#xxx', where xxx is the ID of the corresponding <content></content> element.
 Schematron assertroleKred.png error 
 teststarts-with(@value,'#') 
 MessageThe @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding <content/> element. 
 Variable letNameidvalue 
 Valuesubstring-after(@value,'#') 
 Schematron assertroleKred.png error 
 testancestor::hl7:structuredBody//*[@ID=$idvalue] 
 MessageNo narrative text found for this reference (no content element within this document has an ID that corresponds to '<value-of select="$idvalue"/>'). 
 Schematron assertroleKred.png error 
 testparent::*/text()=ancestor::hl7:structuredBody//*[@ID=$idvalue]/text() 
 MessageThe originalText content MUST be identical to the narrative text for this reference. 
 Schematron assertroleKred.png error 
 test(@nullFlavor='NAV' and originalText and not(@codeSystem or @codeSystemName or @code or @displayName)) or (@codeSystem and @codeSystemName and @code and @displayName) 
 MessageEither a code described by code, codeSystem, codeSystemName and displayName or originalText and nullFlavor="NAV" is REQUIRED. 
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian
0 … *The patient's guardian.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *The guardian's id.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1RThe 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.
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 The id itself. It MUST be unique within the issuing system.
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1The guardian's role.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid0 … 1F2.16.840.1.113883.5.111
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1FHL7RoleCode
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st0 … 1 
 Schematron assertroleKred.png error 
 test(not(@nullFlavor) and @displayName and @code and @codeSystem and @codeSystemName) or (@nullFlavor and not(@displayName or @code or @codeSystem or @codeSystemName)) 
 MessageEither nullFlavor or a valid code is required. 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … *The guardian's address.
Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *The guardian's means of communication (phone, eMail, ...).CDA‑CH V2
Choice1 … 1Elements to choose from:
  • hl7:guardian​Person containing template 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC)
  • hl7:guardian​Organization containing template 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Person
The guardian's as a person.
Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Organization
The guardian's as an organization.
Contains 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:birthplace
0 … 1The patient's birthplace.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:place
1 … 1CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
EN0 … 1The patient's birthplace name.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1RThe patient's birthplace address.
Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC)
CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:language​Communication
0 … *The patient's language skills.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:language​Code
CS1 … 1CDA‑CH V2
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.11526 HumanLanguage (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:modeCode
CE0 … 1CDA‑CH V2
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.12249 LanguageAbilityMode (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:proficiency​Level​Code
CE0 … 1CDA‑CH V2
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.12199 LanguageAbilityProficiency (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:preference​Ind
BL0 … 1In case of @value=true it is the patient's correspondence language.CDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.pnghl7:providerOrganization
0 … 1The organization who took care of the patient in the same context with the current CDA document. E.g. entry of the Medreg, FMH Index or the Health Organisation Index (HOI) of the Swiss EPR.
Contains 2.16.756.5.30.1.1.10.9.30 Organization Compilation with GLN and name (DYNAMIC)
CDA‑CH V2
Included1 … *M from 2.16.756.5.30.1.1.10.9.23 Author (DYNAMIC)
Treetree.pnghl7:author
1 … *MInformation about the author of a CDA document, section or entry. An author MAY be a person or a device.CDA‑CH V2
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1MCDA‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.9.23
Treeblank.pngTreetree.pnghl7:functionCode
CE1 … 1R

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‑CH V2
Treeblank.pngTreeblank.pngTreetree.png@nullFlavor
st0 … 1FNAV
Treeblank.pngTreeblank.pngTreetree.png@code
cs0 … 1 
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
oid0 … 1F2.16.840.1.113883.6.96
Treeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1FSNOMED CT
Treeblank.pngTreeblank.pngTreetree.png@displayName
st0 … 1 
 CONF
The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.1.3 EprAuthorRole (DYNAMIC)
 Example
Patient
<functionCode code="116154003" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Patient"/>
 Example
Nurse
<functionCode code="106292003" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Professional nurse"/>
 Example
Home helper
<functionCode nullFlavor="NAV">
  <originalText>Home helper</originalText></functionCode>
 Example
Laboratory technician
<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 assertroleKred.png error 
 test(@code and @codeSystem) or (@nullFlavor='NAV') 
 MessageEither a code with its code system or nullFlavor='NAV' is required. 
 Schematron assertroleKred.png error 
 testnot(@nullFlavor) or (hl7:originalText) 
 MessageOther Caregivers description MUST be declared in the originalText element in case of nullFlavor. 
Treeblank.pngTreeblank.pngTreetree.pnghl7: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‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreetree.pnghl7:time
TS.CH.TZ1 … 1RTimestamp of the authorship.CDA‑CH V2
Treeblank.pngTreetree.pnghl7:assignedAuthor
1 … 1RCDA‑CH V2
 Schematron assertroleKred.png error 
 testnot(assignedAuthoringDevice/softwareName) or (representedOrganization) 
 MessageFor device authors the element representedOrganization is REQUIRED. 
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1R 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‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs0 … 1FNAV
 Temporarily unknown, will be filled later.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
cs0 … 1F2.51.1.3
 OID for GS1 GLN.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 The GS1 GLN.
 Schematron assertroleKred.png error 
 test(@root='2.51.1.3' and @extension) or (@nullFlavor='NAV') 
 MessageEither the GS1 GLN or nullFlavor='NAV' is REQUIRED 
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *Other ids are allowed.CDA‑CH V2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
cs1 … 1RThe 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.
Treeblank.pngTreeblank.pngTreeblank.png