Ehscda:CDA-CH-RESP (specification)

Sprachen:	Deutsch • français

Austauschformat Rettungsprotokoll

CDA-CH-RESP

HL7 Benutzergruppe Schweiz

Geschäftsstelle
Oberstrasse 222
9014 St.Gallen

Switzerland

Versionierung
Version	Datum	Status	Änderungen gegenüber Vorversion	Download
0.91	26.03.2018	Draft		kein download verfügbar
1.0.0	01.06.2018	Pre-Publication Review	Release für Eingabe eCH	Dokument

Identifikation dieses Dokuments
Abkürzung: CDA-CH-RESP
OID: 2.16.756.5.30.1.143.1.1

Autoren Oliver Egger (ahdis GmbH); Felix Fischer (SRZ); Christian Kohler (KDS GmbH)

Projektorganisation

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 .

Auftraggeber:

• Interverband für Rettungswesen
• eCH
  

Arbeitsgruppe:

• Vereinigung Rettungssanitäter Schweiz (VRS), Daniel Weibel, Rettungsdienst Winterthur
• Schweizerische Gesellschaft für Notfall- und Rettungsmedizin (SGNOR), Micha Dambach, Kantonsspital Luzern
• Schweizerische Gesellschaft für Anästhesiologie und Reanimation (SGAR), Micha Dambach, Kantonsspital Luzern
• VBS, Koordinierter Sanitätsdienst (KSD), Mario Kaufmann
• Schweizerische Rettungsflugwacht (Rega), Marco Keller
• Die Spitäler der Schweiz (H+), Bernhard Freudiger
• Vertreter aus der Westschweiz und dem Tessin, Mattia Lepori, EOC Bellinzona
• Fachspezialisten von HL7 Schweiz und IHE Suisse, Christian Kohler, KDS GmbH
• Stadtspital Triemli / Stadt Zürich, Patrik Kaiser
• Schutz & Rettung der Stadt Zürich (SRZ), Felix Fischer
  

Umsetzung durch:

• Schutz & Rettung der Stadt Zürich (SRZ), Felix Fischer
• KDS Consulting GmbH, Christian Kohler
• ahdis GmbH, Oliver Egger

Zweck und Positionierung

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

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

Gleichstellung von Mann und Frau

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

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

Elektronische Version

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

Die Inhalte dieses Dokuments können auch auf dem Wiki unter Implementierungsleitfaden Rettungsprotokoll abgerufen werden. Die normative Spezifikation inklusive den Schematron-Regeln ist auf Art-Decor unter folgendem Link publiziert: Art-Decor Rettungsdienstprotokoll

Zusammenfassung

Ausgangslage

Als Grundlage für Projekte zur Digitalisierung der Prozesse im Schweizer Rettungswesen und zur Anbindung dieser Organisationen am Elektronischen Patientendossier (EPD) soll ein für Schweizer Rettungsorganisationen anwendbarer, standardisierter Informationsfluss definiert werden. Das Projekt läuft unter der Führung des Interverbandes für Rettungswesen. Dabei sind die Informationsinhalte auf der Basis des internationalen Standards HL7, im Speziellen der Clinical Document Architecture (CDA) und die Abläufe technisch nach IHE Integrationsprofilen (ebenfalls eine internationale, mit HL7 eng kooperierende Organisation) beschrieben. Dieser Informationsfluss wird beim Verein eCH unter der Nummer eCH-0207 und bei eHealth Suisse unter der Bezeichnung CDA-CH-RESP als Standard etabliert.

Die Dokumentation erfolgt mit den Mitteln, die durch eHealth Suisse bereitgestellt werden (e-health-wiki und ART-DECOR). So wird eine maximale Verbindung mit bereits bestehenden Leitfäden (eMedikation, Laborbefunde, Impfdossier) und künftigen sichergestellt.

Es herrscht Konsens darüber, dass dieser Implementationsleitfaden verhindern soll, dass weiterhin jede Rettungsorganisation eigene Lösungen beschreiben und implementieren muss. Viele Rettungsorganisationen haben die Absicht geäussert, einen landesweit standardisierten Informationsfluss in ihren Systemen zu implementieren, sobald ein solcher verfügbar ist. Mit Blick auf das EPD und die entsprechende eHealth Architektur Schweiz ist es ein Gebot der Zeit, die Spitäler als Partner im Informationsfluss des Rettungswesens unter den Aspekten einer EPD-Gemeinschaft einzubeziehen. Das entsprechende eidgenössische Gesetz (EPDG) wurde im Frühjahr 2017 in Kraft gesetzt.

Mit einer breiten Abstützung bei vielen Stakeholdern (Rettungsorganisationen, Berufsgruppen) können Unsicherheiten und Risiken aufgefangen werden. Die unterschiedlichen Zuordnungen von Rettungsorganisationen und Spitälern zu Gemeinden und Kantonen werden bei der Entwicklung des Leitfadens abgefangen. So kann dieser dann bei Projekten als Vorgabe und Ausschreibungsbestandteil genutzt werden.

Ziele

Gesucht ist eine Dokumentation, die die Use Cases beschreibt und die Spezifikationen für Ausschreibungen und Implementationen liefert. Im Wesentlichen handelt es sich um:

1. die Beschreibung eines generischen (nicht abschliessenden) Informationsflusses unter den Teilnehmenden bei einem Rettungseinsatz (Sanitätsnotrufzentrale, Rettungsfahrzeuge, Zielspital, Backoffice des Rettungsdienstes, etc.)

2. die Definition eines elektronischen Einsatzprotokolls, d. h. eines Informationscontainers, der die benötigten medizinischen, demografischen und sonstigen Informationen zwischen den Teilnehmenden transportiert

Randbedingung: Die Wiederverwendung von geeigneten internationalen Standards oder Teilen davon ist ausdrücklich beabsichtigt.

Ergebnis

Das Ergebnis ist ein Implementationsleitfaden nach Massgabe der Regulatorien zum EPD und als Grundlage für jegliche digitalen Prozesse im Zusammenhang mit dem Rettungswesen.

Grundlegend für den Implementationsleitfaden sind:

• zwei generische Use Cases, die sachdienlich sind, Diskussionen im Detail aber vermeiden
• eine umfassende Beschreibung der Datenstrukturen und Value Sets in ART-DECOR
• ein Set an CDA Templates für die sinnvollerweise strukturierten Elemente als Grundlage für die Implementation

Auf der Basis dieses Leitfadens können sowohl Ausschreibungen als auch Implementationen vollzogen werden.

Einleitung

Ausgangslage und Motivation

Im schweizerischen Rettungswesen ist die Dokumentation nach wie vor papierbasiert. Die Folgen sind oftmals schlecht leserliche Dokumente und es kann sein, dass während eines Einsatzes auf mehreren Formularen dokumentiert wird und diese Informationen im Rettungsteam gezielt ausgetauscht werden müssen. Vollständigkeitskontrollen sind schwierig und nach der Übergabe an die nachbehandelnde Stelle (Notfallaufnahme o. Ä.) müssen die Informationen übernommen und ggf. übertragen werden. Immer mehr Geräte, die bei Rettungen eingesetzt werden, sind in der Lage, Informationen digital bereitzustellen, was genutzt werden soll. Das Rettungsprotokoll der Zukunft wird deshalb ein elektronisches Dokument sein. Mit dem Projekt „Elektronisches Rettungsprotokoll“ will eCH mit eHealth Suisse ein weiteres national koordiniertes eHealth-Vorhaben unterstützen. Die Thematik Rettung und Rettungsprotokoll eignet sich gut, um mit digitalen Prozessen „bis auf die Strasse“ vorzudringen und die Arbeit auf den Rettungsplätzen zu erleichtern.

Status und Zweck

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

Das vorliegende Dokument beschreibt den Inhalt von „CDA-CH-RESP (specification)“ und definiert damit ein einheitliches Austauschformat für den Informationsaustausch im Gesundheitswesen Schweiz. Es enthält den Text wie er vom Projektteam erarbeitet wurde und beinhaltet die normative Spezifikation basierend auf HL7 CDA. Dieses Austauschformat ist nach einer breiten Anhörung als nationaler Standard durch eHealth Suisse zur Verwendung empfohlen.

Angesprochene Leserschaft

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

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

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

Ziele und Abgrenzungen

Voraussetzungen Interoperabilität

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

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

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

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

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

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

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

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

Ziele

Mit Blick auf das EPD und die entsprechende eHealth Architektur Schweiz ist es ein Gebot der Zeit, die Spitäler als Partner im Informationsfluss des Rettungswesens unter den Aspekten einer EPD-Gemeinschaft einzubeziehen.

Der vorliegende Implementierungsleitfaden beinhaltet die Spezifikationen für die semantische Interoperabilität von Systemen rund um das schweizerische Rettungswesen. Er enthält:

• die Beschreibung eines allgemein akzeptierten, generischen Prozesses bei der Behandlung von Opfern bei akuten Ereignissen mit gesundheitlichen Folgen
• die Beschreibung eines allgemein akzeptierten, generischen Protokolls zur Dokumentation der Erhebungen, Befundungen/Diagnosen und Behandlungen von Opfern bei akuten Ereignissen mit gesundheitlichen Folgen; abgebildet ist dieses mit Struktur und Value Sets in ART-DECOR

Der Implementationsleitfaden beschreibt die Anforderungen für Evaluationen oder Implementationen von ICT-Lösungen im schweizerischen Rettungswesen.

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

Dieser Leitfaden beschreibt ein eHealth- und damit EPD-taugliches Informationsobjekt und führt aus, in welchem generischen Prozess dieses eingesetzt werden soll.

Unterschiede, die sich aus den Regionen der Rettungsdienste ergeben, spiegeln sich in den Value Sets und Codesystemen. Im Zweifelsfall und wenn das möglich ist, konzentriert sich der Leitfaden darauf, die Grundlagen für solche Zuordnungen zu erheben, die Scores o. Ä. zu generieren und nicht direkt erfassen zu lassen.

Dieser Implementationsleitfaden beschreibt ausdrücklich nicht, wie sich Rettungsdienste in der Welt des EPD mit den Gemeinschaften verbinden sollen. Es bleibt also diesen selbst überlassen, ob sie eigenständig oder als Teil eines Leistungserbringers funktionieren und welcher (Stamm-)Gemeinschaft sie sich anschliessen wollen, respektive ob sie selber eine bereichsspezifische Gemeinschaft bilden wollen.

Grundlagen und Basistechnologien

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

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

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-RESP (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 Anwendenden.

Die Kodierung von einzelnen Informationen in diesem Austauschformat basiert auf definierten Value Sets, welche die akzeptierten Codes enthalten.

Die Value Sets basieren auf:

• SNOMED CT
• ICD-10
• IVR Codeset

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

Die Anwendungsfälle rund um das Rettungsprotokoll lassen sich nach dem EPDG mit TOZ und der Strategie eHealth Schweiz umsetzen. Die elektronischen Informationen dazu sollen im elektronischen Patientendossier zugänglich gemacht und für gerichtete Kommunikation eingesetzt werden können sowie den Beteiligten eine elektronische Verarbeitung ermöglichen. Das vorliegende Austauschformat basiert auf Integrationsprofilen von IHE und auf der HL7 Clinical Document Architecture (CDA).

Das vorliegende Austauschformat baut auf folgenden Grundlagen auf:

Bezug zu anderen Standards und Leitfäden – Referenzpyramide

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

Dokumente, welche basierend auf IHE Inhaltsprofilen (Content Profiles) erstellt werden, können in einem Ordner (Folder) in der IHE-Cross-Enterprise-Document-Sharing-Architektur (XDS) abgelegt werden. Dieses IHE Integrationsprofil ist die Basis für das Elektronische Patientendossier (EPD) in der Schweiz.

Die im vorliegenden Austauschformat referenzierten IHE Inhaltsprofile beziehen sich auf HL7 CDA R2 als Basisstandard für Dokumenteninhalte.

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

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

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

Zusätzlich, was nicht direkt in oben dargestellter Referenzpyramide integrierbar ist, nimmt das vorliegende Dokument Bezug auf bereits bestehende Empfehlungen von eHealth Suisse respektive auf das EPDG und diesbezüglich in erster Linie auf die Verordnung und deren Anhänge. Insbesondere der Anhang 4 mit den Austauschformaten orientiert sich an HL7 CDA als Dokumentenformat.

Das vorliegende Austauschformat ist konform zu den oben genannten Empfehlungen von eHealth Suisse und damit zur eHealth-Strategie und -Architektur in der Schweiz. Durch die Wahl von IHE und HL7 als technologische Basis sind entsprechend erstellte Dokumente zudem auch grenzüberschreitend interoperabel.

IHE Integrationsprofile

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

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

Dokumente, welche basierend auf IHE Inhaltsprofilen (Content Profiles) erstellt werden, können in der IHE Cross-enterprise document sharing Architektur (XDS.b) abgelegt, gemäss IHE Cross-Enterprise Document Reliable Interchange (XDR) an einen Empfänger gesendet oder wie von IHE Cross-Enterprise Document Media Interchange (XDM) vorgegeben auf ein Medium geschrieben und von dort wieder gelesen werden. Das IHE Integrationsprofil XDS.b ist im Übrigen die Basis für das verteilte elektronische Patientendossier (EPD) in der Schweiz.

Die, im vorliegenden Austauschformat referenzierten IHE Inhaltsprofile referenzieren auf HL7 CDA R2 als Basisstandard für Dokumenteninhalte.

HL7 V3

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

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

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

HL7 Clinical Document Architecture (CDA)

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

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

Gesetzgebung Elektronisches Patientendossier (EPDG)

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

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

Übersetzungen

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

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

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

Die nachfolgenden Definitionen sind wichtig für ein gemeinsames Verständnis. Sie stammen unter anderem aus dem Internet (z.B. von Firmen- und Institutionswebseiten, Wikipedia, Google). Sie dienen zum Verständnis der gebrauchten Begriffe insbesondere im Kapitel Anwendungsfälle.

Begriff	Definition
ART-DECOR	Modellierungswerkzeug von eHealth Suisse für Gesundheitsdaten www.art-decor.org
BAG	Bundesamt für Gesundheit
CDA	Clinical Document Architecture;
CDA-CH	CDA mit Helvetisierungen
eHealth Suisse	Schweizerische Kompetenz- und Koordinationsstelle von Bund und Kantonen für eHealth
EPD	Elektronisches Patientendossier, https://www.e-health-suisse.ch/elektronisches-patientendossier.html
EPDG	Bundesgesetz über das elektronische Patientendossier, https://www.admin.ch/opc/de/classified-compilation/20111795/index.html
EPDV	Verordnung über das elektronische Patientendossier, https://www.admin.ch/opc/de/classified-compilation/20163256/index.html
EPDV-EDI	Verordnung des EDI über das elektronische Patientendossier, https://www.admin.ch/opc/de/classified-compilation/20163257/index.html
GLN	Global Location Number; weltweit eindeutige Bezeichnung von juristischen und natürlichen Partnern im Gesundheitswesen, Datenbank wird gepflegt von www.refdata.ch
H+	Die Spitäler der Schweiz ist der nationale Verband der öffentlichen und privaten Spitäler, Kliniken und Pflegeinstitutionen.
HL7	Health Level 7, internationaler Standard für den Austausch von Daten zwischen Organisationen im Gesundheitswesen und deren Computersystemen
HL7 Schweiz	Verein, der die Förderung, Verbreitung und Weiterentwicklung des HL7-Standards im schweizerischen Gesundheitswesen bezweckt.
ICD-10	International Statistical Classification of Diseases and Related Health Problems Codierungs-System (primär) für Diagnosen
IHE	Integrating the Healthcare Enterprise; internationale Initiative, welche die Umsetzung von medizinischen Prozessabläufen zwischen Organisationen und Systemen im Gesundheitswesen harmonisieren will. Die Schaffung von Interoperabilität steht hierbei im Vordergrund.
IHE Switzerland	Der Verein IHE Suisse engagiert sich für die Umsetzung der „Strategie eHealth Schweiz“. Er ist die Plattform zur Evaluation und Erarbeitung von IHE-Profilen, welche die Strategieumsetzung unterstützen.
IPAG	Interprofessionelle Arbeitsgruppe Elektronisches Patientendossier
IVR	Interverband für Rettungswesen
LOINC	Logical Observation Identifiers Names and Codes Codierungs-System für medizinische Begriffe
OID	Object Identifier; weltweit eindeutiger Bezeichner, der benutzt wird um ein Informationsobjekt zu benennen
RD	Rettungsdienst
Rega	Schweizerische Rettungsflugwacht
SGAR	Schweizerischen Gesellschaft für Anästhesiologie und Reanimation
SGNOR	Schweizerischen Gesellschaft für Notfall- und Rettungsmedizin
SNOMED CT	Systematized Nomenclature of Medicine - Clinical Terms Codierungs-System für medizinische Begriffe
SNZ	Sanitätsnotrufzentrale
VRS	Verband der Rettungssanitäter

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

In Abhängigkeit vom Ereignis, das den Rettungseinsatz auslöst, kann der Ablauf im Detail unterschiedlich ausfallen. Wir gehen in diesem Leitfaden jedoch davon aus, dass jeder Einsatz mit einem Auslöser bei der Disposition in einer Notrufzentrale beginnt und mit der Qualitätskontrolle und der Verrechnung abgeschlossen wird. Die Daten, die dabei erhoben werden, sind immer wieder dieselben und Teil einer vereinigten Gesamtmenge aller Möglichkeiten. Die Unterschiede in den Abläufen führen dazu, dass Datengruppen oder einzelne Elemente ausführlich und detailliert, in einfacher Form oder gar nicht erhoben und bearbeitet werden. Im Gegensatz zu einem Papierformular kann ein elektronisches auf solche Unterschiede eingehen, was die Erfassung erheblich vereinfacht. Allerdings ist die Spezifikation dazu nicht Teil dieses Leitfadens.

Die Grafik beschreibt also einen möglichst generischen Ablauf, der sachdienlich ist, Diskussionen im Detail aber vermeidet.

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

In der Sanitätsnotrufzentrale geht ein Anruf ein. Dieser geht entweder (a) von einem Unfall- oder einer akuten Gesundheitsattacke aus und ist schnellstmöglich mit höchster Priorität auszuführen oder betrifft (b) einen geplanten Transport einer Person mit medizinischen Einschränkungen.

Bei diesem Anruf werden die ersten Daten zur Domäne Einsatz (Einsatz- und Zielort) erhoben und dokumentiert. Beim Zielort sind bei einem Grossereignis Vorbehalte möglich, die aber zwischen dem Start des Teams von der Basis und der Abfahrt vom Einsatzort geklärt werden müssen.

Die Disposition in der Zentrale lässt sich möglichst viele Informationen zu den betroffenen Personen geben. Während das im Fall (a) möglicherweise auf die (Anzahl) Person(en), deren ungefähres Alter und deren Geschlecht beschränkt bleiben muss, können sie im Fall (b) mit dem Auftrag abschliessend erfasst werden.

Aufgrund der verfügbaren Informationen bestimmt die Disposition die nötige Besetzung und Ausrüstung des Einsatzteams, wählt ein verfügbares aus oder organisiert ein solches, durch Umstellungen in den laufenden Einsätzen oder bei Partnerorganisationen.

Damit sind alle Informationen zum Szenario „Einsatz“ bestimmt. Einzig die Statuszeiten müssen noch hergeleitet oder erfasst werden.

Das Einsatzteam erhält den Einsatzauftrag und beginnt mit der Umsetzung. Auf dem Weg zum Einsatzort können die verfügbaren Informationen ausgewertet und ggf. weitere Informationen angefordert werden.

Am Einsatzort wird eine Lagebeurteilung gemacht, es werden:

• eine Anamnese erstellt
• Erstbefunde erhoben
• Diagnosen gestellt
• Massnahmen eingeleitet
• Die Medikation muss auf die Anamnese und vor allem auf eine laufende Medikation abestimmt werden.

Alle diese Schritte werden im Rettungsprotokoll festgehalten und dokumentiert.

Während die Daten zur Person und zur Administration bei einem geplanten Einsatz von Beginn an bekannt sind, müssen Sie bei einem Noteinsatz oft am Einsatzort noch einmal ergänzt werden. Dies kann parallel zur Erhebung der Anamnese und Befunde geschehen; im einfachsten Fall verfügt der Patient über einen Ausweis und/oder eine Versicherungskarte.

Sobald der Patient transportfähig und der Zielort (meist Notfallstation mit Aufnahmekapazität) bekannt ist, wird der Transport ausgelöst.

Am Zielort wird der Patient sowie das Rettungsprotokoll übergeben.

Bei einem Notfalleinsatz ist auch zu diesem Zeitpunkt noch nicht garantiert, dass der Patient abschliessend identifiziert werden konnte. Die Aufgabe, dies zu tun und den Fall auch administrativ zum Abschluss zu bringen, liegt dann beim behandelnden Spital.

Das Team kehrt mit dem Fahrzeug auf die Basis zurück, führt die Retablierung durch und schliesst das Protokoll ab. Die Qualitätssicherung und die Abrechnung (gegenüber dem Patienten oder gegenüber dem Zielort) sind nun Aufgabe des Backoffice des Rettungsdienstes.

Use cases - Vorbemerkungen

Für das Rettungsdienstprotokoll werden 2 Use cases beschrieben:

1. Primäreinsatz mit identifizierbarem Patienten: Einsatz, in dem der Rettungsdienst den ersten Kontakt mit dem Patienten hat und diesen auf Grund eines Ausweises, auf Grund einer Aussage des Patienten o.Ä. eindeutig identifizieren kann. Häufig handelt es sich hierbei um Notfalleinsätze. Primäreinsätze sind für den Rettungsdienst mehrheitlich nicht planbar. 2. Primäreinsatz mit unbekanntem Patienten: Einsatz, in dem das Team des Rettungsdienstes bis zum Abschluss des Einsatzes den Patienten nicht identifizieren kann. Gründe dafür können z.B. sein, dass sich die Person nicht äussern kann und keine Ausweise auf sich trägt oder dass im Falle eines Grossereignisses die Identifikation der Verletzen auf dem Schadenplatz mangels Zeit nicht erfolgen konnte.

Beide Use Cases sind frei erfunden. Sie dienen allein der Illustration, wie Angaben, die im Verlauf eines Einsatzes erfahren werden, im Datensatz des CDA-CH-RESP abgebildet werden. Die Use Cases können deshalb Angaben enthalten, die einsatztaktisch oder medizinisch nicht sinnvoll sind. Die Beschreibung der beiden Use Cases enthält Daten, die in den Beispieldaten des Datensatzes soweit möglich wieder aufgenommen werden. Falls bei einem Datensatz-Attribut mehr als ein Beispiel aufgeführt wird, so betreffen diese einen oder beide der Use Cases. Die Beschreibung der Use Cases ist weniger detailliert als die Beispieldaten. Dies bedeutet, dass es Beispieldaten gibt, die in beiden oder nur in einem der beiden Use Cases erwähnt werden, aber auch Daten, die in den Use Cases gar nicht erwähnt werden.

Use case 1 - Primäreinsatz mit identifizierbarem Patienten

Am 10.12.2016 um 12.09 Uhr (Statuszeit ALARM) ruft Herr Peter Muster den Notruf 144 an. Er befindet sich irgendwo oberhalb Zürichs am Waldrand und schildert, dass er starke Schmerzen in der Brust und im linken Oberarm verspürt und kaum atmen kann. Die Sanitätsnotrufzentrale Zürich (GLN 7601002156370) vermutet aufgrund der Befragung des Patienten ein akutes Koronarsyndrom (ACS) und definiert dies als Einsatzstichwort. Die Ortung des Patienten ergibt, dass er sich auf den Koordinaten 47.392115, 8.553192 befindet.

Die Sanitätsnotrufzentrale (SNZ) legt am 10.12.2016 um 12.11 Uhr (Statuszeit DISPOSITION, Bezeichnung Status: DP) einen Einsatz mit der Einsatznummer S12345678 an und disponiert unter der Nummer D12345678 das Team 111 des Rettungsdienstes Schutz & Rettung (GLN 7601002156363) mit einem Rettungswagen (Z-220) und der Besatzung Petra Muster, dipl. Rettungssanitäterin HF (höhere Fachschule), GLN 7601003330434, und Hans Beispiel, Transportsanitäter FA (Fachausweis), GLN 7601000211804, an den Einsatzort. Die Fahrt ist dringlich und wird deshalb mit Sondersignal ausgeführt. Sie fahren 12.13 Uhr in der Wache von Schutz und Rettung Zürich (SRZ) los (Statuszeit ROLLOUT, Bezeichnung Status: 1). Parallel dazu wird auch ein Notarzt aufgeboten (Dr. med. Hans Notarzt, Notarzt SGNOR, GLN 7601000028105, fix bei SRZ stationiert), der separat mit einem Fahrzeug an den Einsatzort kommen wird. Aufgrund der Schilderung des Patienten und des Einsatzortes legt die SNZ provisorisch fest, dass der Transport in die interdisziplinäre Notfallstation des Universitätsspitals Zürich (USZ, Rämistrasse 100, 8091 Zürich, GLN 7601002155939) erfolgen soll.

Die Fahrt des Rettungswagens dauert vier Minuten, d. h. Ankunftszeit am Ereignisort ist 12.17 Uhr (Statuszeit ARRIVAL ON SCENE, Bezeichnung Status: 2). Allerdings kann der Rettungswagen nicht direkt zum Patienten vorfahren. Das Team braucht weitere fünf Minuten, um mit sämtlichem Material zu Fuss zum Patienten zu gelangen. Statuszeit ARRIVAL PATIENT (Bezeichnung Status: Kontakt Patient) ist demzufolge 12.22 Uhr. (Bemerkung: Für statistische Auswertungen wird als Ankunftszeit immer die Statuszeit ARRIVAL ON SCENE verwendet.) Die betreuende Rettungssanitäterin Petra Muster und der kurz darauf ebenfalls eintreffende Notarzt beurteilen den Patienten mittels des standardisierten ABCDE-Abfragealgorithmus. Dabei werden die folgenden Beobachtungen um 12.25 Uhr gemacht: Glasgow Coma Scale (GCS): Augenöffnung spontan (4), verbale Antwort orientiert (5), motorische Reaktion befolgt Anweisungen (6), total 15; Schmerz 5; Blutdruck 120/80, gemessen am rechten Arm; Temperatur 37,2 °C. Der Notarzt kommt zum Schluss, dass die Einschätzung der SNZ (ACS) richtig gewesen ist und erstellt die Verdachtsdiagnose eines akuten transmuralen Myokardinfarkts der Vorderwand, kurz ACS/STEMI VW mit dem ICD-10-Code I21.0. Sie legen dem Patienten sofort eine Infusion und verabreichen ihm um 12.30 Uhr eine erste Dosis von zwei Hüben Nitrolingual-Spray. Parallel zur Erstversorgung des Patienten stellt Petras Teamkollege anhand der Krankenkassenkarte des Patienten fest, dass es sich um Peter Muster, männlich, geb. 10.1.1961, AHV-Nr. 7560123123499 mit der Kartennummer 80756003760012390001 von der Krankenversicherung KPT handelt. Gemäss der Aussage seiner Ehefrau Erika Muster, die ebenfalls anwesend ist, wohnt der Patient an der Bahnhofstr. 1, 8001 Zürich und ist Bürger von Musterdorf ZH. Seine Frau hat mitgeteilt, dass er ein elektronisches Patientendossier hat. Herr Muster wurde von SRZ schon einmal transportiert und hat deshalb bei SRZ bereits eine Patienten-ID: 762354. Das Team hat von der Ehefrau die folgenden Informationen erhalten:

• Peter Muster hat keine Patientenverfügung erstellt
• Er ist allergisch auf Baumpollen und es gibt eine bekannte Unverträglichkeitsreaktion auf einzelne Medikamente
• Seit einem Herzvorfall vor vier Jahren, der im Triemlispital in Zürich behandelt wurde, nimmt Peter Muster Aspirin Cardio 100 (1 Tbl./Tag)
• Es sind keine anderen medizinischen Probleme bekannt.

Seit dem Frühstück um ca. 8 Uhr hat er nichts mehr gegessen. Der Patient wird nach der Erstversorgung mit einem Rettungsbrett in den Rettungswagen gebracht und transportbereit gemacht. Der Rettungswagen fährt um 12.48 Uhr am Einsatzort ab (Status: DEPARTURE FROM SCENE, Bezeichnung Status: 3). Während sich der Notarzt unterwegs um den Patienten kümmert, meldet Hans Beispiel den Patienten bereits mit allen relevanten Informationen in der Notaufnahme des USZ an. Er fährt aufgrund der Verdachtsdiagnose mit Sondersignal ins USZ. Petra verstaut die Effekten von Peter Muster in einen Wertsachenbeutel und erstellt ein Wertsachenverzeichnis, welches später zusammen mit dem Wertsachenbeutel im USZ abgegeben wird. Um 12.54 Uhr trifft der Rettungswagen im USZ ein (Status: ARRIVAL AT TARGET, Bezeichnung Status: 4). Der Notarzt und Petra übergeben den Patienten dem zuständigen Arzt, Dr. Spitalarzt, GLN 7601000404268, in der Notaufnahme des USZ. Parallel dazu trägt Hans Beispiel noch die folgenden Informationen im Protokoll nach: Der GCS beträgt immer noch 15; der NACA bei der Übergabe ist III (stationärer Aufenthalt des Patienten angezeigt); der Schmerz hat sich etwas reduziert auf 4; der Zustand des Patienten hat sich im Verlauf des Einsatzes verbessert. Petra unterzeichnet das Dokument um 13.05 Uhr und sendet dieses medizinische Abschlussprotokoll verschlüsselt an die E-Mail-Adresse des USZ. Alternativ hätte sie das Protokoll auch lokal im Rettungswagen ausdrucken und in der Notaufnahme in Papierform abgeben können. Dieses medizinische Abschlussprotokoll wird bei SRZ rechtsverbindlich archiviert, falls es zu juristischen Abklärungen mit medizinischem Hintergrund kommen sollte.

Während sich der Notarzt nach der Patientenübergabe an den Stützpunkt zurückbegibt, bereiten Petra und Hans den Rettungswagen wieder so weit vor, dass das Team für einen weiteren Notfalleinsatz bereit wäre. Dafür wird Reservematerial, das auf dem Rettungswagen vorhanden ist, verwendet. Da kein Anschlusseinsatz erfolgt, fährt das Team nun mit dem Rettungswagen zum Stützpunkt zurück. Abfahrt am Zielort (Status: DEPARTURE FROM TARGET, Bezeichnung Status: 5). Dort wird das Fahrzeug wieder vollständig einsatzbereit gemacht, d.h. sämtliches verwendetes Material wird wieder aufgefüllt, das Fahrzeug gereinigt, etc. Danach ist das Team wieder voll einsatzbereit (Status: OPERATIONAL READINESS, Bezeichnung Status: 6). Das Team 111 erfasst nun alle weiteren für den Einsatz relevanten Daten (alternative Rechnungsadresse, verbrauchtes Material, gefahrene Kilometer, Daten für die Gewaltstatistik, …) im elektronischen Patientenprotokoll. Nachdem alle notwendigen Daten erfasst worden sind, schliessen Petra und ihr Kollege den Einsatz auch administrativ ab. Das Einsatzprotokoll wird nun nochmals archiviert, jetzt aber mit allen administrativen und verrechnungstechnisch relevanten Daten. Damit können auch juristische Fragen mit nicht-medizinischem Hintergrund zweifelsfrei dokumentiert werden.

Mit diesem Schritt ist der Einsatz für das Team vollständig abgeschlossen.

Umsetzungsbeispiele:

• Elektronisch: 1-Einsatzprotokoll.xml
• Elektronisch: 1b-Einsatzprotokoll.xml

Use case 2 - Primäreinsatz mit unbekanntem Patienten

Am 10.12.2016 um 12.09 Uhr erhält die Sanitätsnotrufzentrale Zürich (GLN 7601002156370) einen Notruf (Status ALARM). Es wird gemeldet, dass eine unbekannte Person auf der Strasse zusammengebrochen und nicht ansprechbar ist, aber atmet und deshalb Nothilfe benötigt wird. Als Einsatzort wird 8050 Zürich, Sternen Oerlikon, Schaffhauserstr. 350, angegeben. Genauere Angaben sind zum Zeitpunkt des Anrufs nicht vorhanden.

Die Sanitätsnotrufzentrale Zürich disponiert um 12.11 Uhr (Status: DISPOSITION, DP) das Team 111 mit dem Rettungswagen (Z-211) mit Sondersignal an den Einsatzort. Das Team 111 besteht aus Petra Muster, dipl. Rettungssanitäterin HF, GLN 7601003330434, und Hans Beispiel, Transportsanitäter FA, GLN 7601000211804. Beide nehmen die Rolle von Betreuungspersonen ein. Der Einsatz erhält von der SNZ die Einsatznummer S12345678 und die Dispositionsnummer D12345678. Als Einsatzstichwort wird aufgrund des unklaren Geschehens „unklare Situation, Abklärung vor Ort“ angegeben. Aufgrund der wenigen verfügbaren Informationen und des Einsatzortes legt die SNZ provisorisch fest, dass der Transport des Patienten bei Bedarf in die interdisziplinäre Notfallstation des Universitätsspitals Zürich (USZ, Rämistrasse 100, 8091 Zürich, GLN 7601002155939) erfolgen soll.

Team 111 fährt um 12.13 Uhr in der Wache von SRZ los (Status: ROLLOUT, Bezeichnung Status: 1) und trifft 12.17 Uhr am Ereignisort ein (Statuszeit ARRIVAL ON SCENE, Bezeichnung Status: 2). Bei der Ankunft des Teams wird festgestellt, dass der Patient von einem Laienhelfer betreut wird, der bereits erste Hilfe geleistet hat. Das Team übernimmt daraufhin den Patienten vom Laienhelfer. Da der Patient keine Angaben zu seiner Person machen kann, keine Identitätsmittel auf sich trägt und ihn keine anwesende Person kennt, versieht ihn Petra Muster zur Identifikation mit einer Patientenleitsystem (PLS) Tasche mit der Nummer MU43221.

Die betreuende Rettungssanitäterin Petra Muster beurteilt den männlichen Patienten, ca. 50-jährig, mittels des standardisierten ABCDE-Abfragealgorithmus. Dabei werden die folgenden Beobachtungen um 12.25 Uhr gemacht. Airway: die Atemwege sind nicht verlegt; Breathing: der Patient hat eine unauffällige Spontanatmung; Cardiology: sein Puls ist tastbar, es liegt kein Herz-Kreislauf-Stillstand vor; Frequenz 84/Minute, Blutdruck 170/90, gemessen am rechten Arm; Disabilities AVPU: V (reagiert auf laute Ansprache); Glasgow Coma Scale: Augenöffnung bei Ansprache (3), gibt Einzelworte von sich (3), Dekortikationsstarre (3), total 9; Temperatur 37,2 °C; die Augen zeigen eine deutliche Anisokorie auf.

Petra stellt damit die Verdachtsdiagnose „Stroke“ mit dem ICD-10-Code I63.-.

Sie legt dem Patienten sofort eine Infusion mit 500 ml Ringer. Der Patient wird liegend in den Rettungswagen verladen.

Der Rettungswagen fährt um 12.48 Uhr am Einsatzort ab (Status: DEPARTURE FROM SCENE, Bezeichnung Status: 3). Während sich Petra unterwegs um den Patienten kümmert, meldet Hans Beispiel den Patienten bereits mit allen relevanten Informationen in der Notaufnahme des USZ an. Er fährt aufgrund der Verdachtsdiagnose mit Sondersignal ins USZ und meldet, dass der Patient in der Notaufnahme das Stroke-Team benötigt und deshalb die Aufnahmedringlichkeit „rot“ ist. Petra verstaut die Effekten des Patienten in einen Wertsachenbeutel und erstellt ein Wertsachenverzeichnis, welches später zusammen mit dem Wertsachenbeutel im USZ abgegeben wird. Um 12.54 Uhr trifft der Rettungswagen im USZ ein (Status: ARRIVAL AT TARGET, Bezeichnung Status: 4).

Petra übergibt den Patienten dem zuständigen Arzt, Dr. Spitalarzt, GLN 7601000404268, in der Notaufnahme des USZ. Parallel dazu trägt Hans Beispiel noch die folgenden Informationen im Protokoll nach: Der GCS beträgt jetzt 10; der NACA bei der Übergabe ist III (stationärer Aufenthalt des Patienten angezeigt); der Zustand des Patienten hat sich im Verlauf des Einsatzes verbessert. Petra unterzeichnet das Dokument um 13.05 Uhr und sendet dieses medizinische Abschlussprotokoll verschlüsselt an die E-Mail-Adresse des USZ. Dieses medizinische Abschlussprotokoll wird bei SRZ rechtsverbindlich archiviert, falls es zu juristischen Abklärungen mit medizinischem Hintergrund kommen sollte.

Petra und Hans bereiten den Rettungswagen wieder so weit vor, dass das Team für einen weiteren Notfalleinsatz bereit wäre. Dafür wird Reservematerial, das auf dem Rettungswagen vorhanden ist, verwendet. Da kein Anschlusseinsatz erfolgt, fährt das Team nun mit dem Rettungswagen zum Stützpunkt zurück. Abfahrt am Zielort (Status: DEPARTURE FROM TARGET, Bezeichnung Status: 5). Dort wird das Fahrzeug wieder vollständig einsatzbereit gemacht, d. h. sämtliches verwendetes Material wird wieder aufgefüllt, das Fahrzeug gereinigt, etc. Danach ist das Team wieder voll einsatzbereit (Status: OPERATIONAL READINESS, Bezeichnung Status: 6). Das Team 111 erfasst nun alle weiteren für den Einsatz relevanten Daten (alternative Rechnungsadresse, verbrauchtes Material, gefahrene Kilometer, Daten für die Gewaltstatistik, …) im elektronischen Patientenprotokoll. Nachdem alle notwendigen Daten erfasst worden sind, schliessen Petra und ihr Kollege den Einsatz auch administrativ ab.

Mit diesem Schritt ist der Einsatz für das Team vollständig abgeschlossen.

Umsetzungsbeispiele:

• Elektronisch: 2-Einsatzprotokoll.xml
• Elektronisch: 2b-Einsatzprotokoll.xml

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

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 vorstehend beschriebenen Anwendungsfälle erfordern eine Kommunikation zwischen den Applikationen bei Sender und Empfänger. Bei der Implementierung ist zwischen medizinischem bzw. fachlichem Inhalt (Content) und eigentlichem Transport dieser Inhalte (Communication) zu unterscheiden.

Communication vs. Content

Das vorliegende Dokument spezifiziert den Inhalt (Content). Die Spezifikation des Transportweges ist nicht Teil dieses Dokumentes.

Empfehlung zum Transportmechanismus

Der Inhalt (Content), der mit vorliegendem Dokument spezifiziert wird, soll mit sogenannten Metadaten (Angaben zum Typ, Inhalt, Autor, Empfänger, Patient, etc.) angereichert werden und als Paket (Dokument plus Metadaten) über einen sicheren Kanal übertragen werden. Dazu eignen sich folgende Transaktionen aus dem IHE IT Infrastructure Technical Framework:

• Cross-Enterprise Document Media Interchange (XDM)
  • Distribute Document Set on Media [ITI-32]
• Cross-Enterprise Document Reliable Interchange (XDR)
  • Provide and Register Document Set-b [ITI-41]
• Cross-Enterprise Document Sharing (XDS.b)
  • Provide and Register Document Set-b [ITI-41]
  • Registry Stored Query [ITI-18]
  • Retrieve Document Set [ITI-43]

Diese Transaktionen sind auch Rahmen des elektronischen Patientendossiers (EPD) anwendbar.

Umgang mit Metadaten

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

Empfehlung zum Umgang mit Metadaten

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

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

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.

Der CDA Header basiert auf CDA-CH V2 mit ein paar Präzisierungen für CDA-CH RESP. Der CDA Body wird durch einzelne Sections spezifisch für CDA-CH RESP definiert.

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 .

Ein Dokument, welches anhand dieser Spezifikation erstellt wird, ist ein HL7 CDA Dokument und damit ein definiertes und komplettes Informationsobjekt, das Texte, Bilder und andere multimediale Objekte enthalten kann. CDA Dokumente dokumentieren den Gesundheitszustand eines Patienten zu einem bestimmten Zeitpunkt. Sie enthalten administrative (Header) und medizinische (Body) Daten und sind mittels eXtensible Markup Language (XML) kodiert.

Die normative Spezifikation definiert das Dokument „CDA-CH-RESP (specification)“ als HL7 CDA Vorlage, welche helvetische Präzisierungen für den CDA Header festlegt. Damit produzierte Dokumente sind vollständig kompatibel zum internationalen HL7 CDA R2 Standard (Normative Edition 2005) und somit international interoperabel.

Die normative Spezifikation bezweckt, dass Systeme für das Handling von Informationen im CDA Header durch die Softwarehersteller unabhängig von Sender und Empfänger implementiert werden können.

Die vorliegende Spezifikation wurde in ART-DECOR modelliert und daraus können auch Schematron-Regeln generiert werden, welche eine automatisierte und harmonisierte Validierung der CDA-Dokumente erlauben.

Schlüsselwörter

Die normative Spezifikation verwendet folgende, jeweils in Grossbuchstaben geschriebene Schlüsselwörter zu Angabe von Verbindlichkeiten. Siehe auch [ELGA Allgemein], Kap. 4.1 resp. RFC 2119.

MUSS (engl. MUST) bedeutet eine verpflichtend einzuhaltende Vorschrift. Entspricht der Optionalität [R] und [M].

NICHT ERLAUBT (engl. NOT PERMITTED) formuliert ein verpflichtend einzuhaltendes Verbot. Entspricht der Optionalität [NP].

SOLL oder EMPFOHLEN (engl. SHOULD) steht für eine pragmatische Empfehlung. Es ist gewünscht und empfohlen, dass die Anforderung umgesetzt wird, es kann aber Gründe geben, warum dies unterbleibt. Entspricht der Optionalität Required [R]. Wenn kein Wert angegeben werden kann, MUSS nullFlavor angegeben werden.

KANN oder OPTIONAL (engl. MAY, OPTIONAL). Die Umsetzung der Anforderung ist optional, sie kann auch ohne zwingenden Grund unterbleiben. Entspricht dem Optionalität [O].

Optionalität

Nachfolgende Tabelle legt die Verwendung von zwingenden, empfohlenen und optionalen Elementen und den dazu gehörenden Kardinalitäten inkl. Verwendung von nullFlavor normativ fest. Die nachfolgende Definition wurde aus IHE Technical Frameworks General Introduction, Appendix E: Standards Profiling and Documentation Conventions, Revision 1.0, July 1, 2014, "Table E.4.2.2.1-1: Data Element Optionality Constraints" übernommen und mit dem Element [NP] ergänzt.

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

Notationen in diesem Dokument

nullFlavor

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

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

Hierarchie der Spezifikationen

Diese Spezifikation basiert in nachstehender Rangfolge auf folgenden Grundlagen:

1. HL7 Version 3
2. HL7 Clinical Document Architecture, Release 2.0
3. Spezifikation CDA-CH V2 (2017)

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 .

Dataset & Szenario

Für den Primäreinsatz wurde ein Datenset/Szenario festgelegt, die den Umfang und Optionalitäten der einzelnen Datenelemente definieren. Dieses Szenario ist direkt in Art-Decor ersichtlich.

CDA Struktur

CDA Document Level Templates

EmergencyMedicalServiceProtocol

Id	2.16.756.5.30.1.1.10.1.2	Effective Date	2017‑06‑13 17:19:29 Other versions this id: EmergencyMedicalServiceProtocol as of 2017‑05‑31 17:19:29
Status	Under pre-publication review	Version Label	2017
Name	EmergencyMedicalServiceProtocol	Display Name	EmergencyMedicalServiceProtocol
Description	Emergency Medical Service Protocol for Switzerland
Context	Pathname //
Classification	CDA Document Level Template
Open/Closed	Open (other than defined elements are allowed)
Used by / Uses	Used by 0 transactions and 1 template, Uses 15 templates Used by as Name Version 2.16.756.5.30.1.1.10.1.2 Include EmergencyMedicalServiceProtocol (2017) 2017‑05‑31 17:19:29 Uses as Name Version 2.16.756.5.30.1.1.10.2.25 Include Document Realm (2017) DYNAMIC 2.16.756.5.30.1.1.10.2.18 Include Document Template Ids CDA-CH v2.0 - structuredBody (2017) DYNAMIC 2.16.756.5.30.1.1.10.9.40 Include RESP Header Template Compilation (2017) DYNAMIC 2.16.756.5.30.1.1.10.3.7 Containment Mission (2017) DYNAMIC 2.16.756.5.30.1.1.10.3.8 Containment Patient (2017) DYNAMIC 2.16.756.5.30.1.1.10.3.43 Containment Administrative (2017) DYNAMIC 2.16.756.5.30.1.1.10.3.42 Containment Pretreatment (2017) DYNAMIC 2.16.756.5.30.1.1.10.3.41 Containment Anamnesis (2017) DYNAMIC 2.16.756.5.30.1.1.10.3.14 Containment Findings (2017) DYNAMIC 2.16.756.5.30.1.1.10.3.16 Containment Diagnosis (2017) DYNAMIC 2.16.756.5.30.1.1.10.3.17 Containment Procedures (2017) DYNAMIC 2.16.756.5.30.1.1.10.3.18 Containment EventOfDeath (2017) DYNAMIC 2.16.756.5.30.1.1.10.3.19 Containment Transport (2017) DYNAMIC 2.16.756.5.30.1.1.10.3.15 Containment Handover (2017) DYNAMIC 2.16.756.5.30.1.1.10.3.2 Containment Remarks Section - coded (2017) DYNAMIC
Relationship	Specialization: template 2.16.756.5.30.1.1.10.1.9 (2017‑03‑28 23:43:12)
Example	Example <hl7:ClinicalDocument xsi:schemaLocation="urn:hl7-org:v3 ../../../../schemas/PHARM/schemas/cda/extendedschemas/CDA_extended_pharmacy.xsd">   <hl7:realmCode code="CHE"/>  <hl7:typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>  <!-- CDA-CH v2.0 ART-DECOR model - structuredBody.  -->   <hl7:templateId root="2.16.756.5.30.1.1.10.1.9"/>  <!-- HL7 CDA R2 (2005); contains ClinicalDocument.component as structuredBody.  -->   <hl7:templateId root="2.16.840.1.113883.10.12.2"/>  <!-- HL7 CDA R2 (2005).  -->   <hl7:templateId root="2.16.840.1.113883.10.12.1"/>  <!-- CDA-CH RESP -->   <hl7:templateId root="2.16.756.5.30.1.1.10.1.2"/>  <hl7:id root="B4044742-AB2C-49F6-8151-0E2BE5D3F923"/>  <!-- A LOINC based document type of a CDA document instance including a translation to the Swiss EPR XDS.b metadata.  -->   <hl7:code code="67796-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="EMS Patient Care Report">     <!-- Mapping to the Swiss EPR XDS.b metadata -->     <hl7:translation code="371535009" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Transfer summary report"/>  </hl7:code>  <hl7:title>Einsatzprotokoll</hl7:title>  <hl7:effectiveTime value="20161210124000.0000+0100"/>  <hl7:confidentialityCode code="1051000195109" codeSystem="2.16.840.1.113883.6.96" displayName="Normal" codeSystemName="SNOMED CT"/>  <hl7:languageCode code="de-CH"/>  <hl7:setId root="662E3C16-0AAC-11E8-BA89-0ED5F89F718B"/>  <hl7:versionNumber value="2"/>  <hl7:recordTarget>     <hl7:patientRole>       <hl7:id extension="MU43221" root="2.16.756.5.30.1.143.20"/>      <hl7:patient>         <hl7:name>           <!-- cdachresp-data​element-8 -->           <hl7:family nullFlavor="UNK"/>          <!-- cdachresp-data​element-9 -->           <hl7:given nullFlavor="UNK"/>        </hl7:name>        <!-- cdachresp-data​element-11 -->         <hl7:administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1" displayName="Male" codeSystemName="HL7 AdministrativeGender"/>        <!-- cdachresp-data​element-10 -->         <hl7:birthTime nullFlavor="UNK"/>      </hl7:patient>    </hl7:patientRole>  </hl7:recordTarget>  <!-- Rettungssanitäterin -->   <hl7:author>     <hl7:functionCode displayName="Andere Gesundheitsfachperson" code="223366009" codeSystemName="SNOMED CT" codeSystem="2.16.840.1.113883.6.96">       <hl7:translation code="133932002" displayName="Betreuer" codeSystem="2.16.840.1.113883.6.96" codeSystemName="IVR Codesystem RESP"/>    </hl7:functionCode>    <hl7:time value="20161210121305.0000+0100"/>    <hl7:assignedAuthor>       <hl7:id extension="7601003330434" root="2.51.1.3"/>      <hl7:assignedPerson>         <hl7:name>           <hl7:given>Petra</hl7:given>          <hl7:family>Muster</hl7:family>        </hl7:name>      </hl7:assignedPerson>    </hl7:assignedAuthor>  </hl7:author>  <hl7:informant>     <hl7:assignedEntity>       <!-- cdachresp-data​element-60 aufbietende Organisation -->       <hl7:id root="2.51.1.3" extension="7601002156370"/>    </hl7:assignedEntity>  </hl7:informant>  <hl7:custodian>     <hl7:assignedCustodian>       <hl7:representedCustodianOrganization>         <!-- cdachresp-data​element-61 aufgebotene Organisation -->         <hl7:id root="2.51.1.3" extension="7601002156363"/>        <!-- cdachresp-data​element-384 aufgebotene Organisation -->         <hl7:name>Rettungsdienst Schutz & Rettung Zürich</hl7:name>      </hl7:representedCustodianOrganization>    </hl7:assignedCustodian>  </hl7:custodian>  <hl7:informationRecipient typeCode="PRCP">     <hl7:intendedRecipient>       <hl7:id root="2.51.1.3" extension="7601000404268"/>      <hl7:informationRecipient>         <hl7:name>           <hl7:given>Hans</hl7:given>          <hl7:family>Spezialarzt</hl7:family>        </hl7:name>      </hl7:informationRecipient>      <hl7:receivedOrganization>         <hl7:id root="2.51.1.3" extension="7601002155939"/>        <!-- cdachresp-data​element-174 -->         <hl7:name>USZ</hl7:name>        <hl7:addr>           <hl7:streetAddressLine>Rämistrasse 100</hl7:streetAddressLine>          <hl7:city>Zürich</hl7:city>          <hl7:postalCode>8091</hl7:postalCode>          <hl7:country>CH</hl7:country>        </hl7:addr>      </hl7:receivedOrganization>    </hl7:intendedRecipient>  </hl7:informationRecipient>  <hl7:legalAuthenticator>     <hl7:time value="20161210124000.0000+0100"/>    <hl7:signatureCode code="S"/>    <hl7:assignedEntity>       <hl7:id extension="7601003330434" root="2.51.1.3"/>      <hl7:assignedPerson>         <hl7:name>           <hl7:given>Petra</hl7:given>          <hl7:family>Muster</hl7:family>        </hl7:name>      </hl7:assignedPerson>    </hl7:assignedEntity>  </hl7:legalAuthenticator>  <hl7:documentationOf typeCode="DOC">     <hl7:templateId root="2.16.756.5.30.1.1.10.2.46"/>    <hl7:serviceEvent classCode="ACT" moodCode="EVN">       <!-- cdachresp-data​element-55 Einsatznummer -->       <!-- Extension: Einsatznummer SNZ root: OID vom SNZ -->       <hl7:id root="2.16.756.5.30.1.9999999999.1" extension="S12345678"/>      <hl7:effectiveTime>         <!-- cdachresp-data​element-54: Einsatzdatum -->         <hl7:low value="20161210"/>        <hl7:high nullFlavor="NA"/>      </hl7:effectiveTime>      <!-- cdachresp-data​element-102 Team -->       <hl7:performer typeCode="PRF">         <hl7:templateId root="2.16.756.5.30.1.1.10.9.31"/>        <hl7:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.24.3.5"/>        <hl7:functionCode displayName="Andere Gesundheitsfachperson" code="223366009" codeSystemName="SNOMED CT" codeSystem="2.16.840.1.113883.6.96">           <hl7:translation code="133932002" displayName="Betreuer" codeSystem="2.16.840.1.113883.6.96" codeSystemName="IVR Codesystem RESP"/>        </hl7:functionCode>        <hl7:assignedEntity>           <!-- cdachresp-data​element-281 -->           <hl7:id extension="7601003330434" root="2.51.1.3"/>          <hl7:addr>             <hl7:streetAddressLine>Bahnhofquai 3, Amtshaus I</hl7:streetAddressLine>            <hl7:postalCode>8001</hl7:postalCode>            <hl7:city>Zürich</hl7:city>            <hl7:country>CH</hl7:country>          </hl7:addr>          <hl7:telecom nullFlavor="NA"/>          <hl7:assignedPerson>             <hl7:name>               <hl7:given>Petra</hl7:given>              <hl7:family>Muster</hl7:family>            </hl7:name>          </hl7:assignedPerson>          <hl7:representedOrganization>             <hl7:id root="2.51.1.3" extension="7601002156363"/>            <hl7:name>Rettungsdienst Schutz & Rettung Zürich</hl7:name>            <hl7:telecom nullFlavor="NA"/>            <hl7:addr>               <hl7:streetAddressLine>Bahnhofquai 3, Amtshaus I</hl7:streetAddressLine>              <hl7:postalCode>8001</hl7:postalCode>              <hl7:city>Zürich</hl7:city>              <hl7:country>CH</hl7:country>            </hl7:addr>          </hl7:representedOrganization>        </hl7:assignedEntity>      </hl7:performer>      <hl7:performer typeCode="PRF">         <hl7:templateId root="2.16.756.5.30.1.1.10.9.31"/>        <hl7:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.24.3.5"/>        <hl7:functionCode displayName="Andere Gesundheitsfachperson" code="223366009" codeSystemName="SNOMED CT" codeSystem="2.16.840.1.113883.6.96">           <hl7:translation code="133932002" displayName="Betreuer" codeSystem="2.16.840.1.113883.6.96" codeSystemName="IVR Codesystem RESP"/>        </hl7:functionCode>        <hl7:assignedEntity>           <!-- cdachresp-data​element-281 -->           <hl7:id extension="7601000211804" root="2.51.1.3"/>          <hl7:addr>             <hl7:streetAddressLine>Bahnhofquai 3, Amtshaus I</hl7:streetAddressLine>            <hl7:postalCode>8001</hl7:postalCode>            <hl7:city>Zürich</hl7:city>            <hl7:country>CH</hl7:country>          </hl7:addr>          <hl7:telecom nullFlavor="NA"/>          <hl7:assignedPerson>             <hl7:name>               <hl7:given>Hans</hl7:given>              <hl7:family>Beispiel</hl7:family>            </hl7:name>          </hl7:assignedPerson>          <hl7:representedOrganization>             <hl7:id root="2.51.1.3" extension="7601002156363"/>            <hl7:name>Rettungsdienst Schutz & Rettung Zürich</hl7:name>            <hl7:telecom nullFlavor="NA"/>            <hl7:addr>               <hl7:streetAddressLine>Bahnhofquai 3, Amtshaus I</hl7:streetAddressLine>              <hl7:postalCode>8001</hl7:postalCode>              <hl7:city>Zürich</hl7:city>              <hl7:country>CH</hl7:country>            </hl7:addr>          </hl7:representedOrganization>        </hl7:assignedEntity>      </hl7:performer>    </hl7:serviceEvent>  </hl7:documentationOf>  <hl7:component> ... </hl7:component></hl7:ClinicalDocument>
Item DT Card Conf Description Label hl7:ClinicalDocument 1 … 1 M (Eme...col) Included 1 … 1 M from 2.16.756.5.30.1.1.10.2.25 Document Realm (DYNAMIC) hl7:realmCode CS 1 … 1 M Swiss Realm (CHE) of HL7 CDA. CDA‑CH V2 @code CONF 1 … 1 F CHE hl7:typeId II 1 … 1 M HL7 CDA R2, 2005 (Eme...col) @root uid 1 … 1 F 2.16.840.1.113883.1.3 @extension st 1 … 1 F POCD_HD000040 Included from 2.16.756.5.30.1.1.10.2.18 Document Template Ids CDA-CH v2.0 - structuredBody (DYNAMIC) hl7:templateId II 0 … 1 CDA-CH v2.0 specification. This is an informational reference, only. CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.1.1.4 hl7:templateId II 1 … 1 M HL7 CDA R2 (2005); contains ClinicalDocument.component as structuredBody. CDA‑CH V2 @root uid 1 … 1 F 2.16.840.1.113883.10.12.2 hl7:templateId II 1 … 1 M HL7 CDA R2 (2005). CDA‑CH V2 @root uid 1 … 1 F 2.16.840.1.113883.10.12.1 hl7:templateId II 1 … 1 R Template ID describing CDA-CH RESP (Eme...col) @root uid 1 … 1 F 2.16.756.5.30.1.1.10.1.2 Included from 2.16.756.5.30.1.1.10.9.40 RESP Header Template Compilation (DYNAMIC) Included 1 … 1 M from 2.16.756.5.30.1.1.10.2.23 Document Id (DYNAMIC) hl7:id II 1 … 1 M A unique identifier for each CDA document instance. CDA‑CH V2 @root uid 1 … 1 R The document's id as Globally Unique Identifier (GUID). @extension st 0 NP NP/not present Included 1 … 1 M from 2.16.756.5.30.1.1.10.2.45 Document Code RESP (DYNAMIC) hl7:code CE 1 … 1 M The LOINC code for this document is 67796-3 (Eme...col) @code st 1 … 1 F 67796-3 @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.1 @codeSystemName st 1 … 1 F LOINC @displayName st 1 … 1 F EMS Patient Care Report hl7:translation CD 1 … 1 R A translation to the Swiss EPR XDS.b metadata SHALL be specified. (Eme...col) @code st 1 … 1 F 371535009 @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.96 @codeSystemName st 1 … 1 F SNOMED CT @displayName st 1 … 1 F Transfer summary report hl7:title ST 1 … 1 M EmergencyServiceProtocol (Eme...col) hl7:effectiveTime TS.CH.TZ 1 … 1 M The 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. (Eme...col) Included 1 … 1 M from 2.16.756.5.30.1.1.10.2.19 Document Confidentiality Code (DYNAMIC) hl7:confidentialityCode CE (required) 1 … 1 M Swiss Realm of Confidentiality Code according to the Swiss EPR regulation. CDA‑CH V2 @code cs 1 … 1 R The value of @code MUST be drawn from value set EprDocumentConfidentialityCode (2.16.756.5.30.1.127.3.10.1.5) @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.96 @codeSystemName st 1 … 1 F SNOMED CT @displayName st 1 … 1 R The value of @displayName MUST be drawn from value set EprDocumentConfidentialityCode (2.16.756.5.30.1.127.3.10.1.5)   CONF The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.5 EprDocumentConfidentialityCode (DYNAMIC) Included 1 … 1 M from 2.16.756.5.30.1.1.10.2.22 Document Language (DYNAMIC) hl7:language​Code CS 1 … 1 M The RFC 1766 (ISO-639-1 and ISO 3166) based language in which the narrative texts in this CDA document instance are written. CDA‑CH V2   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) hl7:setId II 1 … 1 R The setId element MUST match the document id of the very first version of that document. It MUST remain the same for all document versions. CDA‑CH V2 @root uid 1 … 1 R The root attribute MUST contain the setId as Globally Unique Identifier (GUID). @extension st 0 NP NP/not present   Schematron assert role  error     test (parent::*/hl7:versionNumber[@value='1'] and @root=parent::*/hl7:id/@root and (@extension=parent::*/hl7:id/@extension or (not(@extension) and not(parent::*/hl7:id/@extension)))) or (parent::*/hl7:versionNumber[not(@value ='1')] and ((@root=parent::*/hl7:id/@root and @extension and not(@extension=parent::*/hl7:id/@extension)) or(not(@root=parent::*/hl7:id/@root))))     Message The setId MUST be equal with the document id for version 1 and it MUST differ for all other versions.   hl7:versionNumber INT.​NONNEG 1 … 1 R The versionNumber element MUST contain the value 1 for the very first version of that document. For later versions, the version number MUST be increased by 1 each. CDA‑CH V2 Included 1 … 1 R from 2.16.756.5.30.1.1.10.2.1 Patient - recordTarget (DYNAMIC) hl7:recordTarget 1 … 1 R 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 hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.1 hl7:patientRole 1 … 1 R CDA‑CH V2 hl7:id II 1 … * R The patient's id. CDA‑CH V2 @root uid 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   The id itself. It MUST be unique within the issuing system. hl7:addr AD 0 … * The patient's address. Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC) CDA‑CH V2 hl7:telecom TEL 0 … * The patient's means of communication (phone, eMail, ...). CDA‑CH V2 hl7:patient 1 … 1 R Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) CDA‑CH V2 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]] hl7:administrative​Gender​Code CE 1 … 1 R The patient's gender according to the Swiss EPR XDS.b metadata. CDA‑CH V2 @code cs 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.1 @codeSystemName st 1 … 1 F HL7 AdministrativeGender @displayName st 1 … 1 R   CONF The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.25 EprGender (DYNAMIC) hl7:birthTime TS.CH.TZ 1 … 1 R The patient's birthdate. CDA‑CH V2 hl7:marital​Status​Code CE 0 … 1 The patient's marital status. CDA‑CH V2 @code cs 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.1.11.12212 @codeSystemName st 1 … 1 F HL7 MaritalStatus @displayName st 1 … 1 R   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.12212 MaritalStatus (DYNAMIC) hl7:translation 0 … * A translation of the code to another coding system CDA‑CH V2 @code cs 1 … 1 R @codeSystem oid 1 … 1 R @codeSystemName st 1 … 1 R @displayName st 1 … 1 R hl7:religious​Affiliation​Code CE 0 … 1 The patient's religion. CDA‑CH V2 @nullFlavor cs 0 … 1 F NAV @code cs 0 … 1   @codeSystem oid 0 … 1   @codeSystemName st 0 … 1   @displayName st 0 … 1   Included 0 … 1 C 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. hl7:originalText ED 0 … 1 C CDA‑CH V2 hl7:reference TEL 1 … 1 M The reference to the corresponding text in the human readable part must be specified by reference to content[@ID]: reference[@value='#xxx'] CDA‑CH V2 @value 1 … 1 R Reference to the narrative part of the section in the format '#xxx', where xxx is the ID of the corresponding <content></content> element.   Schematron assert role  error     test starts-with(@value,'#')     Message The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding <content/> element.     Variable let Name idvalue     Value substring-after(@value,'#')     Schematron assert role  error     test ancestor::hl7:structuredBody//*[@ID=$idvalue]     Message No narrative text found for this reference (no content element within this document has an ID that corresponds to '<value-of select="$idvalue"/>').     Schematron assert role  error     test parent::*/text()=ancestor::hl7:structuredBody//*[@ID=$idvalue]/text()     Message The originalText content MUST be identical to the narrative text for this reference.     Schematron assert role  error     test (@nullFlavor='NAV' and originalText and not(@codeSystem or @codeSystemName or @code or @displayName)) or (@codeSystem and @codeSystemName and @code and @displayName)     Message Either a code described by code, codeSystem, codeSystemName and displayName or originalText and nullFlavor="NAV" is REQUIRED.   hl7:guardian 0 … * The patient's guardian. CDA‑CH V2 hl7:id II 0 … * The guardian's id. CDA‑CH V2 @root uid 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   The id itself. It MUST be unique within the issuing system. hl7:code CE 0 … 1 The guardian's role. CDA‑CH V2 @nullFlavor cs 0 … 1   @code cs 0 … 1   @codeSystem oid 0 … 1 F 2.16.840.1.113883.5.111 @codeSystemName st 0 … 1 F HL7RoleCode @displayName st 0 … 1     Schematron assert role  error     test (not(@nullFlavor) and @displayName and @code and @codeSystem and @codeSystemName) or (@nullFlavor and not(@displayName or @code or @codeSystem or @codeSystemName))     Message Either nullFlavor or a valid code is required.   hl7:addr AD 0 … * The guardian's address. Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC) CDA‑CH V2 hl7:telecom TEL 0 … * The guardian's means of communication (phone, eMail, ...). CDA‑CH V2 Choice 1 … 1 Elements 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) hl7: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 hl7: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 hl7:birthplace 0 … 1 The patient's birthplace. CDA‑CH V2 hl7:place 1 … 1 CDA‑CH V2 hl7:name EN 0 … 1 The patient's birthplace name. CDA‑CH V2 hl7:addr AD 1 … 1 R The patient's birthplace address. Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC) CDA‑CH V2 hl7:language​Communication 0 … * The patient's language skills. CDA‑CH V2 hl7:language​Code CS 1 … 1 CDA‑CH V2   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.11526 HumanLanguage (DYNAMIC) hl7:modeCode CE 0 … 1 CDA‑CH V2   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.12249 LanguageAbilityMode (DYNAMIC) hl7:proficiency​Level​Code CE 0 … 1 CDA‑CH V2   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.12199 LanguageAbilityProficiency (DYNAMIC) hl7:preference​Ind BL 0 … 1 In case of @value=true it is the patient's correspondence language. CDA‑CH V2 hl7:providerOrganization 0 … 1 The 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 Included 1 … * M from 2.16.756.5.30.1.1.10.9.23 Author (DYNAMIC) hl7:author 1 … * M Information about the author of a CDA document, section or entry. An author MAY be a person or a device. CDA‑CH V2 hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.9.23 hl7:functionCode CE 1 … 1 R The functionCode MUST be taken from the Swiss EPR Value-Set for author roles. See FDHA Ordinance on the Electronic Patient Record (EPRO-FDHA), Appendix 3: Metadata, Section 2.1. If the desired functionCode is not available in the Swiss EPR Value-Set for author roles, nullFlavor='NAV' MUST be used. In this case, the originalText element MUST contain the description of the role. Translations to other vocabularies are allowed. CDA‑CH V2 @nullFlavor st 0 … 1 F NAV @code cs 0 … 1   @codeSystem oid 0 … 1 F 2.16.840.1.113883.6.96 @codeSystemName st 0 … 1 F SNOMED CT @displayName st 0 … 1     CONF The value of @code shall be drawn from value set 2.16.756.5.30.1.127.3.10.1.1.3 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 assert role  error     test (@code and @codeSystem) or (@nullFlavor='NAV')     Message Either a code with its code system or nullFlavor='NAV' is required.     Schematron assert role  error     test not(@nullFlavor) or (hl7:originalText)     Message Other Caregivers description MUST be declared in the originalText element in case of nullFlavor.   hl7:translation 0 … * A translation of the code to another coding system (e.g. ISCO-08: 2.16.840.1.113883.2.9.6.2.7) CDA‑CH V2 @code cs 1 … 1 R @codeSystem oid 1 … 1 R @codeSystemName st 1 … 1 R @displayName st 1 … 1 R hl7:time TS.CH.TZ 1 … 1 R Timestamp of the authorship. CDA‑CH V2 hl7:assignedAuthor 1 … 1 R CDA‑CH V2   Schematron assert role  error     test not(assignedAuthoringDevice/softwareName) or (representedOrganization)     Message For device authors the element representedOrganization is REQUIRED.   hl7:id II 1 … 1 R The specification of GS1 GLN is REQUIRED. If it is not (yet) known, this MUST be declared using nullFlavor. For persons: their personal GLN MUST be declared. For devices or software modules: the GLN of their organization MUST be declared. CDA‑CH V2 @nullFlavor cs 0 … 1 F NAV   Temporarily unknown, will be filled later. @root cs 0 … 1 F 2.51.1.3   OID for GS1 GLN. @extension st 0 … 1   The GS1 GLN.   Schematron assert role  error     test (@root='2.51.1.3' and @extension) or (@nullFlavor='NAV')     Message Either the GS1 GLN or nullFlavor='NAV' is REQUIRED   hl7:id II 0 … * Other ids are allowed. CDA‑CH V2 @root cs 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   Contains the ID itself. The ID MUST be unique within the system that issued the ID. hl7:addr AD 0 … * The author's address. Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC) CDA‑CH V2 hl7:telecom TEL 0 … * The author's means of communication (phone, eMail, ...). CDA‑CH V2 Choice 1 … 1 Elements to choose from: hl7:assigned​Person containing template 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) hl7:assigned​Authoring​Device containing template 2.16.756.5.30.1.1.10.9.21 Device Compilation with name (DYNAMIC) hl7:assigned​Person 0 … 1 The author as a person. Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) CDA‑CH V2 hl7:assigned​Authoring​Device 0 … 1 The author as a device. Contains 2.16.756.5.30.1.1.10.9.21 Device Compilation with name (DYNAMIC) CDA‑CH V2 hl7:represented​Organization 0 … 1 The author's organization. Contains 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC) CDA‑CH V2 Included 0 … 1 from 2.16.756.5.30.1.1.10.2.7 Data Enterer (DYNAMIC) hl7:dataEnterer 0 … 1 Information about the person that entered information in this CDA document. It SHALL be declared, when data recorded in this document has been entered by a person other than the author but only when this is relevant for some reason. CDA‑CH V2 hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.7 hl7:time TS.CH.TZ 0 … 1 Timestamp of the data input. CDA‑CH V2 hl7:assignedEntity 1 … 1 R Contains 2.16.756.5.30.1.1.10.9.12 Assigned Entity Compilation with id (DYNAMIC) CDA‑CH V2 Included 0 … * from 2.16.840.1.113883.10.12.154 CDA Informant (DYNAMIC) hl7:informant 0 … * (Eme...col) @typeCode 0 … 1 F INF @context​Control​Code 0 … 1 F OP Choice 1 … 1 Elements 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) hl7:assignedEntity Contains 2.16.840.1.113883.10.12.153 CDA AssignedEntity (DYNAMIC) (Eme...col) hl7:relatedEntity Contains 2.16.840.1.113883.10.12.316 CDA RelatedEntity (DYNAMIC) (Eme...col) Included 1 … 1 R from 2.16.756.5.30.1.1.10.2.3 Custodian (DYNAMIC) hl7:custodian 1 … 1 R The organization in whose name this CDA document has been created (corresponds to the sender of a letter). CDA‑CH V2 hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.3 hl7:assignedCustodian 1 … 1 R CDA‑CH V2 hl7:represented​Custodian​Organization 1 … 1 R CDA‑CH V2 hl7:id II 1 … * M The custodian's id. CDA‑CH V2 @root uid 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   Contains the ID itself. The ID MUST be unique within the system that issued the ID. hl7:name ON 1 … 1 R The custodian's name. CDA‑CH V2 hl7:telecom TEL 0 … * The custodian's means of communication (phone, eMail, ...). CDA‑CH V2 hl7:addr AD 0 … * 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 Included 1 … * M from 2.16.756.5.30.1.1.10.2.4 Recipient - informationRecipient (DYNAMIC) hl7: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 @typeCode cs 0 … 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) hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.4 hl7:intended​Recipient 1 … 1 R CDA‑CH V2 hl7:id II 0 … * R The recipient's identification(s). CDA‑CH V2 @root uid 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   Contains the ID itself. The ID MUST be unique within the system that issued the ID. hl7:addr AD 0 … * 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 hl7:telecom TEL 0 … * The recipient's means of communication (phone, eMail, ...). CDA‑CH V2 hl7:information​Recipient 0 … 1 The addressee person. Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) CDA‑CH V2 hl7:received​Organization 0 … 1 The addressee organization. Contains 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC) CDA‑CH V2 Included 0 … 1 from 2.16.756.5.30.1.1.10.2.5 Legal Authenticator (DYNAMIC) hl7:legalAuthenticator 0 … 1 Information about the legal authenticator of a CDA document. A legal authenticator MUST be a person. CDA‑CH V2 hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.5 hl7:time TS.CH.TZ 1 … 1 R Timestamp of the signature. CDA‑CH V2 hl7:signatureCode CS 1 … 1 R CDA‑CH V2 @code cs 1 … 1 F S @codeSystem oid 0 NP NP/not present @codeSystemName st 0 NP NP/not present @displayName st 0 NP NP/not present   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC) hl7:assignedEntity 1 … 1 R Contains 2.16.756.5.30.1.1.10.9.12 Assigned Entity Compilation with id (DYNAMIC) CDA‑CH V2 Included 0 … * from 2.16.756.5.30.1.1.10.2.6 Authenticator (DYNAMIC) hl7:authenticator 0 … * Information about an authenticator of a CDA document. An authenticator MUST be a person. CDA‑CH V2 hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.6 hl7:time TS.CH.TZ 1 … 1 R Timestamp of the signature. CDA‑CH V2 hl7:signatureCode CS 1 … 1 R CDA‑CH V2 @code cs 1 … 1 F S @codeSystem oid 0 NP NP/not present @codeSystemName st 0 NP NP/not present @displayName st 0 NP NP/not present   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC) hl7:assignedEntity 1 … 1 R Contains 2.16.756.5.30.1.1.10.9.12 Assigned Entity Compilation with id (DYNAMIC) CDA‑CH V2 Included 0 … * from 2.16.756.5.30.1.1.10.2.40 Employer - participant (DYNAMIC) hl7:participant 0 … * Information on the patient's employer, school or other affiliated (e.g., volunteer) organization. CDA‑CH V2 @typeCode cs 1 … 1 F IND hl7:templateId II 1 … 1 M CDA-CH v2.0 ART-DECOR model of Employer. CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.40 hl7:templateId 1 … * M CH-PCC ART-DECOR model of IHE PCC Employer and School Contacts. CDA‑CH V2 @root cs 1 … 1 F 2.16.756.5.30.1.1.10.2.41 hl7:templateId II 1 … 1 M IHE PCC Employer and School Contacts. CDA‑CH V2 @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.5.3.1.2.2 hl7:time IVL_TS.CH.TZ 0 … 1 Validity period of contract. CDA‑CH V2 hl7:low TS.CH.TZ 1 … 1 R Start of the contract. CDA‑CH V2 hl7:high TS.CH.TZ 1 … 1 R End of the contract. CDA‑CH V2 hl7:associated​Entity 1 … 1 R CDA‑CH V2 @classCode cs 1 … 1 F CON hl7:id II 0 … 1 R The id of the contract ([ge]: Mitarbeiternummer; [fr]: Numéro d'employé). CDA‑CH V2 @root uid 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   The id itself. It MUST be unique within the issuing system. hl7:code CE 1 … 1 R CDA‑CH V2 @code cs 1 … 1 R @codeSystem oid 1 … 1 F 1.3.6.1.4.1.19376.1.5.3.3 @codeSystemName st 1 … 1 F IHERoleCode @displayName st 0 NP NP/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) hl7:associated​Person 0 … 1 Contact 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 hl7:scoping​Organization 1 … 1 The 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 Included 0 … * from 2.16.756.5.30.1.1.10.2.15 Insurance - participant (DYNAMIC) hl7:participant 0 … * Information on a patient's insurance. CDA‑CH V2 @typeCode cs 1 … 1 F COV hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.15 hl7:time IVL_TS.CH.TZ 0 … 1 Validity period of the contract. CDA‑CH V2 hl7:low TS.CH.TZ 1 … 1 R Start of the contract. CDA‑CH V2 hl7:high TS.CH.TZ 1 … 1 R End of the contract. CDA‑CH V2 hl7:associated​Entity 1 … 1 R CDA‑CH V2 @classCode cs 1 … 1 F PAYOR hl7:id II 1 … 1 R The id of the contract ([ge]: Versichertennummer; [fr]: Numéro d'assuré). CDA‑CH V2 @root uid 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   The id itself. It MUST be unique within the issuing system. hl7:code CE 1 … 1 R The underlying law for the contract. CDA‑CH V2 @nullFlavor cs 0 … 1 F NAV @code cs 0 … 1   832.10, 832.20, 221.229.1, 833.1, 831.20 @codeSystem oid 0 … 1 F 2.16.756.5.30.2.1.1.11 @codeSystemName st 0 … 1 F ins-laws @displayName st 0 … 1   Federal Act on Health Insurance (HIA), Federal Act on Accident Insurance (AIA), Federal Act on Insurance Policies (Insurance Policies Act, IPA), Federal Act on Military Insurance (MilIA), Federal Act on Invalidity Insurance (InvIA)   Schematron assert role  error     test (@nullFlavor='NAV' and not(@codeSystem or @codeSystemName or @code or @displayName)) or (@codeSystem='2.16.756.5.30.2.1.1.11' and @codeSystemName='ins-laws' and @code and @displayName)     Message Either a valid insurance law or nullFlavor="NAV" is REQUIRED.   hl7:associated​Person 0 … 1 Contact person at the insurance company. Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) CDA‑CH V2 hl7:scoping​Organization 1 … 1 The insurance company. Contains 2.16.756.5.30.1.1.10.9.26 Organization Compilation with GLN, name, addr and telecom (DYNAMIC) CDA‑CH V2 Included 0 … * from 2.16.756.5.30.1.1.10.2.14 Insurance Card - participant (DYNAMIC) hl7:participant 0 … * Information on a patient's insurance card. CDA‑CH V2 @typeCode cs 1 … 1 F HLD hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.14 hl7:time IVL_TS.CH.TZ 1 … 1 R Validity period of the insurance card. CDA‑CH V2 hl7:low TS.CH.TZ 1 … 1 CDA‑CH V2 @nullFlavor cs 1 … 1 F NASK hl7:high TS.CH.TZ 1 … 1 R Expiration date of the insurance card. CDA‑CH V2 hl7:associated​Entity 1 … 1 R CDA‑CH V2 @classCode cs 1 … 1 F POLHOLD hl7:id II 1 … 1 R The insurance card's id. CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.123.100.1.1.1 @extension st 1 … 1 R Number of the insurance card. hl7:associated​Person 0 … 1 Family and given name on the insurance card. Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) CDA‑CH V2 hl7:scoping​Organization 0 … 1 The insurance company which issued the insurance card. Contains 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC) CDA‑CH V2 Included 0 … * from 2.16.756.5.30.1.1.10.2.49 Invoice Recipient (DYNAMIC) hl7:participant 0 … * Information on a invoice recipient. (Eme...col) @typeCode cs 1 … 1 F IND hl7:templateId II 1 … 1 M (Eme...col) @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.49 hl7:functionCode CE 0 … 1 (Eme...col)   CONF The value of @code shall be drawn from value set 2.16.756.5.30.1.1.11.26 IVR valueset role (.143.11.21) (DYNAMIC) hl7:associated​Entity ANY 1 … 1 R (Eme...col) @classCode cs 1 … 1 F GUAR hl7:addr AD 1 … 1 R Invoice to address Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC) (Eme...col) hl7:associated​Person 0 … 1 person to invoice Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) (Eme...col) hl7:scoping​Organization 0 … 1 If invoice recipient is a company Contains 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC) (Eme...col) Included 0 … * from 2.16.756.5.30.1.1.10.2.43 Patient Contact - participant (DYNAMIC) hl7:participant 0 … * Information on a patient contact. CDA‑CH V2 @typeCode cs 1 … 1 F IND hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.43 hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.5.3.1.2.4 hl7:time IVL_TS.CH.TZ 0 … 1 Validity period of the participation. CDA‑CH V2 hl7:low TS.CH.TZ 1 … 1 R Start of participation. CDA‑CH V2 hl7:high TS.CH.TZ 1 … 1 R End of participation. CDA‑CH V2 hl7:associated​Entity 1 … 1 R Either the contact person or the contact's organization SHALL be present. CDA‑CH V2 @classCode cs 1 … 1 R 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 hl7:code CE 1 … 1 R The contact's role. CDA‑CH V2 @nullFlavor cs 0 … 1   @code cs 0 … 1   @codeSystem oid 0 … 1 F 2.16.840.1.113883.5.111 @codeSystemName st 0 … 1 F HL7RoleCode @displayName st 0 … 1     Schematron assert role  error     test (not(@nullFlavor) and @displayName and @code and @codeSystem and @codeSystemName) or (@nullFlavor and not(@displayName or @code or @codeSystem or @codeSystemName))     Message Either nullFlavor or a valid code is required.   hl7:addr AD 0 … * The contact's address. Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC) CDA‑CH V2 hl7:telecom TEL 0 … * The contact's means of communication (phone, eMail, ...). CDA‑CH V2 hl7:associated​Person 0 … 1 C The contact person. Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC) CDA‑CH V2 hl7:scoping​Organization 0 … 1 C The contact's organization. Contains 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC) CDA‑CH V2   Schematron assert role  error     test @classCode=('AGNT','CAREGIVER','ECON','NOK','PRS')     Message The 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.   Included 0 … * from 2.16.756.5.30.1.1.10.2.16 Order Reference - inFulfillmentOf (DYNAMIC) hl7: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 hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.16 hl7:order 1 … 1 R CDA‑CH V2 hl7:id II 1 … * R Order number. CDA‑CH V2 @root uid 1 … 1 R Either the same GUID (order id) or the same OID (order issuing system) as the order itself. @extension st 0 … 1   Contains the order ID itself. The ID MUST be unique within the system that issued the ID. Included 0 … * from 2.16.756.5.30.1.1.10.2.46 Health Service - documentationOf (DYNAMIC) hl7:documentationOf 0 … * Information about a health service describing the context of this CDA document. CDA‑CH V2 @typeCode cs 1 … 1 F DOC hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.46 hl7:serviceEvent 1 … 1 R CDA‑CH V2 @classCode cs 1 … 1 F ACT @moodCode cs 1 … 1 F EVN hl7:id II 0 … * Health service identifiers such as case number ([ge]: Fallnummer; [fr]: Numéro de cas), consultation id, episode id, etc. CDA‑CH V2 @root uid 1 … 1 R The OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED. @extension st 0 … 1   The id itself. It MUST be unique within the issuing system. hl7:code CE 1 … 1 R As long as the eventCodeList for the Swiss EPR metadata is not defined yet by the FDHA Ordinance on the Electronic Patient Record (EPRO-FDHA), the nullFlavor='NAV' MUST be used in this template. Other codes MAY be declared as translation. CDA‑CH V2 @nullFlavor st 1 … 1 F NAV @code cs 0 NP NP/not present @codeSystem oid 0 NP NP/not present @codeSystemName st 0 NP NP/not present @displayName st 0 NP NP/not present hl7:translation 0 … * A translation of the code to another coding system. CDA‑CH V2 @code cs 1 … 1 R @codeSystem oid 1 … 1 R @codeSystemName st 1 … 1 R @displayName st 1 … 1 R hl7:effectiveTime IVL_TS.CH.TZ 1 … 1 R Duration of the health service. CDA‑CH V2 hl7:low TS.CH.TZ 1 … 1 R Start of the health service. CDA‑CH V2 hl7:high TS.CH.TZ 1 … 1 R End of the health service. CDA‑CH V2 Included 0 … * from 2.16.756.5.30.1.1.10.9.31 Performer (DYNAMIC) hl7:performer 0 … * Information about a healthcare provider who was the primary performer of the act. CDA‑CH V2 @typeCode cs 1 … 1 F PRF hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.9.31 hl7:templateId 1 … 1 R CDA‑CH V2 @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.5.3.1.1.24.3.5 hl7:functionCode CE 1 … 1 R The functionCode MUST be taken from the Swiss EPR Value-Set for author roles. See FDHA Ordinance on the Electronic Patient Record (EPRO-FDHA), Appendix 3: Metadata, Section 2.1. If the desired functionCode is not available in the Swiss EPR Value-Set for author roles, 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 @code cs 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.96 @codeSystemName st 1 … 1 F SNOMED CT @displayName st 1 … 1 R   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 assert role  error     test not(@code='133932002') or (hl7:originalText/text())     Message Other Caregivers description MUST be declared in the originalText element.   Included 0 … 1 C 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. hl7:originalText ED 0 … 1 C CDA‑CH V2 hl7:reference TEL 1 … 1 M The reference to the corresponding text in the human readable part must be specified by reference to content[@ID]: reference[@value='#xxx'] CDA‑CH V2 @value 1 … 1 R Reference to the narrative part of the section in the format '#xxx', where xxx is the ID of the corresponding <content></content> element.   Schematron assert role  error     test starts-with(@value,'#')     Message The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding <content/> element.     Variable let Name idvalue     Value substring-after(@value,'#')     Schematron assert role  error     test ancestor::hl7:structuredBody//*[@ID=$idvalue]     Message No narrative text found for this reference (no content element within this document has an ID that corresponds to '<value-of select="$idvalue"/>').     Schematron assert role  error     test parent::*/text()=ancestor::hl7:structuredBody//*[@ID=$idvalue]/text()     Message The originalText content MUST be identical to the narrative text for this reference.   hl7:translation 0 … * A translation of the code to another coding system (e.g. ISCO-08: 2.16.840.1.113883.2.9.6.2.7) CDA‑CH V2 @code cs 1 … 1 R @codeSystem oid 1 … 1 R @codeSystemName st 1 … 1 R @displayName st 1 … 1 R hl7:time IVL_TS.CH.TZ 0 … 1 Duration of the performance. CDA‑CH V2 hl7:low TS.CH.TZ 1 … 1 R Start of the performance. CDA‑CH V2 hl7:high TS.CH.TZ 1 … 1 R End of the performance. CDA‑CH V2 hl7:assignedEntity 1 … 1 R Contains 2.16.756.5.30.1.1.10.9.32 Assigned Entity Compilation with id, name, addr, telecom, person and organization (DYNAMIC) CDA‑CH V2 Included 0 … * from 2.16.756.5.30.1.1.10.2.13 Document Replacement - relatedDocument (DYNAMIC) hl7:relatedDocument 0 … * Relationship to another CDA-CH V2 based document that is replaced by the current one. Notes: For correction of wrong information, a new document that replaces the earlier document MUST be created. The new document corrects previously incorrect information. This also applies to the case where information in the CDA header has been corrected (e.g., if the original document has been issued to the wrong patient). While processing the new document at the recipient, all values from the previous document MUST be interpreted as deprecated (deleted/marked as deleted/deprecated) and all values in the new document MUST be marked as valid: Values that were only contained in the previous document have to be treated as deleted. Values that are present in both documents are overwritten with the contents of the new document. Values that are only contained in the new document are to be added. CDA‑CH V2 @typeCode cs 1 … 1 F RPLC   Indicates that it is a relationship to another document that needs to be replaced. hl7:templateId II 1 … 1 M CDA‑CH V2 @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.13 hl7:parentDocument 1 … 1 R Relationship to the document that needs to be replaced. CDA‑CH V2 hl7:id II 1 … 1 M The id of the document to be replaced MUST be declared. CDA‑CH V2 @root uid 1 … 1 R The id (GUID) of the document to be replaced. @extension st 0 NP NP/not present hl7:setId II 1 … 1 M The setId of the document to be replaced MUST be declared. CDA‑CH V2 @extension st 0 NP NP/not present @root uid 1 … 1 R The setId (GUID) of the document to be replaced and MUST be identical with the content of the setId of the current document.   Schematron assert role  error     test (@root=/hl7:ClinicalDocument/hl7:id/@root) and not(@extension) and not(/hl7:ClinicalDocument/hl7:id/@extension)     Message ClinicalDocument/setId: MUST be identical to the one of the replaced document   hl7:versionNumber INT 1 … 1 M The version number of the document to be replaced. CDA‑CH V2   Schematron assert role  error     test @value > /hl7:ClinicalDocument/hl7:versionNumber/@value     Message ClinicalDocument/versionNumber: MUST be higher than the one of the replaced document   Included 0 … * from 2.16.840.1.113883.10.12.114 CDA Authorization (DYNAMIC) hl7:authorization 0 … * (Eme...col) @typeCode 0 … 1 F AUTH hl7:consent 1 … 1 (Eme...col) @classCode 0 … 1 F CONS @moodCode 0 … 1 F EVN hl7:id II 0 … * (Eme...col) hl7:code CE 0 … 1 (Eme...col) @codeSystem CONF 0 … 1 F 2.16.840.1.113883.5.4 (Act Code) hl7:statusCode CS 1 … 1 R (Eme...col) @code CONF 0 … 1 F completed Included 0 … 1 from 2.16.840.1.113883.10.12.113 CDA componentOf (DYNAMIC) hl7:componentOf 0 … 1 (Eme...col) @typeCode 0 … 1 F COMP hl7:encompassing​Encounter 1 … 1 (Eme...col) @classCode 0 … 1 F ENC @moodCode 0 … 1 F EVN hl7:id II 0 … * (Eme...col) hl7:code CE 0 … 1 (Eme...col)   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.13955 ActEncounterCode (DYNAMIC) hl7:effectiveTime IVL_TS 1 … 1 R (Eme...col) hl7:discharge​Disposition​Code CE 0 … 1 (Eme...col)   CONF shall be drawn from concept domain "EncounterDischargeDisposition" hl7:responsible​Party 0 … 1 Contains 2.16.840.1.113883.10.12.153 CDA AssignedEntity (DYNAMIC) (Eme...col) @typeCode 0 … 1 F RESP hl7:encounterParticipant 0 … * (Eme...col) @typeCode cs 1 … 1 R   CONF The value of @typeCode shall be drawn from value set 2.16.840.1.113883.1.11.19600 x_EncounterParticipant (DYNAMIC) hl7:time IVL_TS 0 … 1 (Eme...col) hl7:assignedEntity 1 … 1 Contains 2.16.840.1.113883.10.12.153 CDA AssignedEntity (DYNAMIC) (Eme...col) hl7:location 0 … 1 (Eme...col) @typeCode 0 … 1 F LOC hl7:health​Care​Facility 1 … 1 (Eme...col) @classCode 0 … 1 F SDLOC hl7:id II 0 … * (Eme...col) hl7:code CE 0 … 1 (Eme...col)   CONF The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.17660 ServiceDeliveryLocationRoleType (DYNAMIC) hl7:location 0 … 1 Contains 2.16.840.1.113883.10.12.317 CDA Place (DYNAMIC) (Eme...col) hl7:service​Provider​Organization 0 … 1 Contains 2.16.840.1.113883.10.12.151 CDA Organization (DYNAMIC) (Eme...col) hl7:component 1 … 1 R (Eme...col) hl7:structuredBody 1 … 1 R (Eme...col) hl7:component 1 … 1 M Contains 2.16.756.5.30.1.1.10.3.7 Mission (DYNAMIC) (Eme...col) where [hl7:section [hl7:code [(@code='1100001' and @codeSystem='2.16.756.5.30.1.143.5.1')]]] hl7:component 1 … 1 M Contains 2.16.756.5.30.1.1.10.3.8 Patient (DYNAMIC) (Eme...col) where [hl7:section [hl7:code [(@code='1100002' and @codeSystem='2.16.756.5.30.1.143.5.1')]]] hl7:component 1 … 1 M Contains 2.16.756.5.30.1.1.10.3.43 Administrative (DYNAMIC) (Eme...col) where [hl7:section [hl7:code [(@code='1100003' and @codeSystem='2.16.756.5.30.1.143.5.1')]]] hl7:component 1 … 1 M Contains 2.16.756.5.30.1.1.10.3.42 Pretreatment (DYNAMIC) (Eme...col) where [hl7:section [hl7:code [(@code='1100004' and @codeSystem='2.16.756.5.30.1.143.5.1')]]] hl7:component 1 … 1 M Contains 2.16.756.5.30.1.1.10.3.41 Anamnesis (DYNAMIC) (Eme...col) where [hl7:section [hl7:code [(@code='1100005' and @codeSystem='2.16.756.5.30.1.143.5.1')]]] hl7:component 1 … 1 M Contains 2.16.756.5.30.1.1.10.3.14 Findings (DYNAMIC) (Eme...col) where [hl7:section [hl7:code [(@code='1100006' and @codeSystem='2.16.756.5.30.1.143.5.1')]]] hl7:component 1 … 1 M Contains 2.16.756.5.30.1.1.10.3.16 Diagnosis (DYNAMIC) (Eme...col) where [hl7:section [hl7:code [(@code='1100007' and @codeSystem='2.16.756.5.30.1.143.5.1')]]] hl7:component 1 … 1 M Contains 2.16.756.5.30.1.1.10.3.17 Procedures (DYNAMIC) (Eme...col) where [hl7:section [hl7:code [(@code='1100008' and @codeSystem='2.16.756.5.30.1.143.5.1')]]] hl7:component 1 … 1 M Contains 2.16.756.5.30.1.1.10.3.18 EventOfDeath (DYNAMIC) (Eme...col) where [hl7:section [hl7:code [(@code='1100009' and @codeSystem='2.16.756.5.30.1.143.5.1')]]] hl7:component 1 … 1 M Contains 2.16.756.5.30.1.1.10.3.19 Transport (DYNAMIC) (Eme...col) where [hl7:section [hl7:code [(@code='1100010' and @codeSystem='2.16.756.5.30.1.143.5.1')]]] hl7:component 1 … 1 M Contains 2.16.756.5.30.1.1.10.3.15 Handover (DYNAMIC) (Eme...col) where [hl7:section [hl7:code [(@code='1100011' and @codeSystem='2.16.756.5.30.1.143.5.1')]]] hl7:component 1 … 1 M Contains 2.16.756.5.30.1.1.10.3.2 Remarks Section - coded (DYNAMIC) (Eme...col) where [not(@nullFlavor)]

CDA Header Level Templates

Document Code RESP

Id	2.16.756.5.30.1.1.10.2.45	Effective Date	2017‑09‑14 12:29:20
Status	Under pre-publication review	Version Label	2017
Name	DocumentCodeRESP	Display Name	Document Code RESP
Description	The document code MUST be specified using LOINC and a translation to the Swiss EPR XDS.b metadata SHALL be specified.
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Used by / Uses	Used by 0 transactions and 3 templates, Uses 0 templates Used by as Name Version 2.16.756.5.30.1.1.10.9.40 Include RESP Header Template Compilation (2017) 2017‑11‑20 13:35:46 2.16.756.5.30.1.1.10.1.2 EmergencyMedicalServiceProtocol (2017) 2017‑06‑13 17:19:29 2.16.756.5.30.1.1.10.1.2 EmergencyMedicalServiceProtocol (2017) 2017‑05‑31 17:19:29
Relationship	Specialization: template 2.16.756.5.30.1.1.10.2.44 (2017‑09‑14 11:36:18)
Example	CDA-CH-RESP <code code="67796-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="EMS Patient Care Report">   <!-- Mapping to the Swiss EPR XDS.b metadata -->   <translation code="371535009" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Transfer summary report"/></code>
Item DT Card Conf Description Label hl7:code CE 1 … 1 R The LOINC code for this document is 67796-3 (Doc...ESP) @code st 1 … 1 F 67796-3 @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.1 @codeSystemName st 1 … 1 F LOINC @displayName st 1 … 1 F EMS Patient Care Report hl7:translation CD 1 … 1 R A translation to the Swiss EPR XDS.b metadata SHALL be specified. (Doc...ESP) @code st 1 … 1 F 371535009 @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.96 @codeSystemName st 1 … 1 F SNOMED CT @displayName st 1 … 1 F Transfer summary report

Documentation Of Service Event

Id	2.16.756.5.30.1.1.10.2.30	Effective Date	2017‑06‑12 14:18:48
Status	Draft	Version Label	2017
Name	DocumentationOfServiceEvent	Display Name	Documentation Of Service Event
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Used by / Uses	Used by 0 transactions and 0 templates, Uses 1 template Uses as Name Version 2.16.756.5.30.1.1.10.9.32 Containment Assigned Entity Compilation with id, name, addr, telecom, person and organization (2017) DYNAMIC
Relationship	Specialization: template 2.16.756.5.30.1.1.10.2.46 (DYNAMIC)
Example	Example <documentationOf typeCode="DOC">   <templateId root="2.16.756.5.30.1.1.10.2.46"/>  <serviceEvent classCode="ACT" moodCode="EVN">     <!-- cdachresp-data​element-55 Einsatznummer -->     <!-- Extension: Einsatznummer SNZ root: OID vom SNZ -->     <id root="2.16.756.5.30.1.9999999999.1" extension="S12345678"/>    <effectiveTime>       <!-- cdachresp-data​element-54: Einsatzdatum -->       <low value="20161210"/>      <high nullFlavor="NA"/>    </effectiveTime>    <!-- cdachresp-data​element-102 Team -->     <performer typeCode="PRF">       <templateId root="2.16.756.5.30.1.1.10.9.31"/>      <templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.24.3.5"/>      <functionCode displayName="Andere Gesundheitsfachperson" code="223366009" codeSystemName="SNOMED CT" codeSystem="2.16.840.1.113883.6.96">         <translation code="133932002" displayName="Betreuer" codeSystem="2.16.840.1.113883.6.96" codeSystemName="IVR Codesystem RESP"/>      </functionCode>      <assignedEntity>         <!-- cdachresp-data​element-281 -->         <id extension="7601003330434" root="2.51.1.3"/>        <addr>           <streetAddressLine>Bahnhofquai 3, Amtshaus I</streetAddressLine>          <postalCode>8001</postalCode>          <city>Zürich</city>          <country>CH</country>        </addr>        <telecom nullFlavor="NA"/>        <assignedPerson>           <name>             <given>Petra</given>            <family>Muster</family>          </name>        </assignedPerson>        <representedOrganization>           <id root="2.51.1.3" extension="7601002156363"/>          <name>Rettungsdienst Schutz & Rettung Zürich</name>          <telecom nullFlavor="NA"/>          <addr>             <streetAddressLine>Bahnhofquai 3, Amtshaus I</streetAddressLine>            <postalCode>8001</postalCode>            <city>Zürich</city>            <country>CH</country>          </addr>        </representedOrganization>      </assignedEntity>    </performer>    <performer typeCode="PRF">       <templateId root="2.16.756.5.30.1.1.10.9.31"/>      <templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.24.3.5"/>      <functionCode displayName="Andere Gesundheitsfachperson" code="223366009" codeSystemName="SNOMED CT" codeSystem="2.16.840.1.113883.6.96">         <translation code="133932002" displayName="Betreuer" codeSystem="2.16.840.1.113883.6.96" codeSystemName="IVR Codesystem RESP"/>      </functionCode>      <assignedEntity>         <!-- cdachresp-data​element-281 -->         <id extension="7601000211804" root="2.51.1.3"/>        <addr>           <streetAddressLine>Bahnhofquai 3, Amtshaus I</streetAddressLine>          <postalCode>8001</postalCode>          <city>Zürich</city>          <country>CH</country>        </addr>        <telecom nullFlavor="NA"/>        <assignedPerson>           <name>             <given>Hans</given>            <family>Beispiel</family>          </name>        </assignedPerson>        <representedOrganization>           <id root="2.51.1.3" extension="7601002156363"/>          <name>Rettungsdienst Schutz & Rettung Zürich</name>          <telecom nullFlavor="NA"/>          <addr>             <streetAddressLine>Bahnhofquai 3, Amtshaus I</streetAddressLine>            <postalCode>8001</postalCode>            <city>Zürich</city>            <country>CH</country>          </addr>        </representedOrganization>      </assignedEntity>    </performer>    <performer typeCode="PRF">       <templateId root="2.16.756.5.30.1.1.10.9.31"/>      <templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.24.3.5"/>      <functionCode displayName="Arzt" code="309343006" codeSystemName="SNOMED CT" codeSystem="2.16.840.1.113883.6.96">         <translation code="309343006" displayName="Notärztin / Notarzt" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>      </functionCode>      <assignedEntity>         <!-- cdachresp-data​element-281 -->         <id extension="7601000028105" root="2.51.1.3"/>        <addr>           <streetAddressLine>Bahnhofquai 3, Amtshaus I</streetAddressLine>          <postalCode>8001</postalCode>          <city>Zürich</city>          <country>CH</country>        </addr>        <telecom nullFlavor="NA"/>        <assignedPerson>           <name>             <given>Notarzt</given>            <family>Hans</family>          </name>        </assignedPerson>        <representedOrganization>           <id root="2.51.1.3" extension="7601002156363"/>          <name>Rettungsdienst Schutz & Rettung Zürich</name>          <telecom nullFlavor="NA"/>          <addr>             <streetAddressLine>Bahnhofquai 3, Amtshaus I</streetAddressLine>            <postalCode>8001</postalCode>            <city>Zürich</city>            <country>CH</country>          </addr>        </representedOrganization>      </assignedEntity>    </performer>  </serviceEvent></documentationOf>
Item DT Card Conf Description Label hl7:documentationOf 1 … 1 M Information about a health service describing the context of this CDA document. (Doc...ent) @typeCode cs 1 … 1 F DOC hl7:templateId II 1 … 1 M (Doc...ent) @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.46 hl7:templateId II 1 … 1 M (Doc...ent) @root uid 1 … 1 F 2.16.756.5.30.1.1.10.2.30 hl7:serviceEvent 1 … 1 R (Doc...ent) @classCode cs 1 … 1 F ACT @moodCode cs 1 … 1 F EVN hl7:id II 1 … 1 M misson number IMC in extension, oid of organization (IMC) in root (Doc...ent) @root oid 1 … 1 R @extension cs 1 … 1 R hl7:effectiveTime IVL_TS.CH.TZ 1 … 1 R Duration of the health service. (Doc...ent) hl7:low TS.CH.TZ 1 … 1 R Start of the health service. (Doc...ent) hl7:high TS.CH.TZ 1 … 1 R End of the health service. (Doc...ent) hl7:performer 0 … * Information about a healthcare provider who was the primary performer of the act. (Doc...ent) @typeCode cs 1 … 1 F PRF hl7:templateId II 1 … 1 M (Doc...ent) @root uid 1 … 1 F 2.16.756.5.30.1.1.10.9.31 hl7:templateId 1 … 1 R (Doc...ent) @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.5.3.1.1.24.3.5 hl7:functionCode CE 1 … 1 R The functionCode MUST be taken from the Swiss EPR Value-Set for author roles. See FDHA Ordinance on the Electronic Patient Record (EPRO-FDHA), Appendix 3: Metadata, Section 2.1. If the desired functionCode is not available in the Swiss EPR Value-Set for author roles, 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. (Doc...ent) @displayName st 1 … 1 R @code cs 1 … 1 R @codeSystemName st 1 … 1 F SNOMED CT @codeSystem oid 1 … 1 F 2.16.840.1.113883.6.96   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 assert role  error     test not(@code='133932002') or (originalText/text())     Message Other Caregivers description MUST be declared in the originalText element.   hl7:originalText ED 0 … 1 C Other Caregivers description MUST be declared in the originalText element. (Doc...ent) hl7:translation 0 … * A translation of the code to another coding system (e.g. ISCO-08: 2.16.840.1.113883.2.9.6.2.7) (Doc...ent) @displayName st 1 … 1 R @code cs 1 … 1 R @codeSystemName st 1 … 1 R @codeSystem oid 1 … 1 R hl7:time IVL_TS.CH.TZ 0 … 1 Duration of the performance. (Doc...ent) hl7:low TS.CH.TZ 1 … 1 R Start of the performance. (Doc...ent) hl7:high TS.CH.TZ 1 … 1 R End of the performance. (Doc...ent) hl7:assignedEntity 1 … 1 R Contains 2.16.756.5.30.1.1.10.9.32 Assigned Entity Compilation with id, name, addr, telecom, person and organization (DYNAMIC) (Doc...ent)

Informant

Id	2.16.756.5.30.1.1.10.2.29	Effective Date	2017‑06‑12 13:32:55
Status	Draft	Version Label	2017
Name	Informant	Display Name	Informant
Description	Informant (IMC)
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Used by / Uses	Used by 0 transactions and 1 template, Uses 0 templates Used by as Name Version 2.16.756.5.30.1.1.10.1.2 Include EmergencyMedicalServiceProtocol (2017) 2017‑05‑31 17:19:29
Relationship	Specialization: template 2.16.840.1.113883.10.12.154 (2005‑09‑07)
Example	GLN IMC <informant>   <assignedEntity>     <!-- cdachresp-data​element-60 aufbietende Organisation -->     <id root="2.51.1.3" extension="7601002156370"/>  </assignedEntity></informant>
Item DT Card Conf Description Label hl7:informant 1 … 1 M (Inf...ant) @typeCode cs 0 … 1 F INF @context​Control​Code cs 0 … 1 F OP hl7:assignedEntity 1 … 1 M (Inf...ant) @classCode cs 0 … 1 F ASSIGNED hl7:id II 1 … 1 M GLN of informant organisation (IMC) (Inf...ant) @root oid 1 … 1 F 2.51.1.3 @extension cs 1 … 1 R

Invoice Recipient

Id	2.16.756.5.30.1.1.10.2.49	Effective Date	2017‑09‑12 20:30:11
Status	Under pre-publication review	Version Label	2017
Name	ParticipantInvoiceRecipient	Display Name	Invoice Recipient
Description	Invoice recipient
Context	Parent nodes of template element with id 2.16.756.5.30.1.1.10.2.49
Classification	CDA Header Level Template
Open/Closed	Open (other than defined elements are allowed)
Used by / Uses	Used by 0 transactions and 3 templates, Uses 3 templates Used by as Name Version 2.16.756.5.30.1.1.10.9.40 Include RESP Header Template Compilation (2017) 2017‑11‑20 13:35:46 2.16.756.5.30.1.1.10.1.2 EmergencyMedicalServiceProtocol (2017) 2017‑06‑13 17:19:29 2.16.756.5.30.1.1.10.1.2 EmergencyMedicalServiceProtocol (2017) 2017‑05‑31 17:19:29 Uses as Name Version 2.16.756.5.30.1.1.10.9.35 Containment Address Information Compilation - eCH-0010 (2017) DYNAMIC 2.16.756.5.30.1.1.10.9.34 Containment Person Name Information Compilation - eCH-0011 (2017) DYNAMIC 2.16.756.5.30.1.1.10.9.24 Containment Organization Compilation with name (2017) DYNAMIC
Relationship	Specialization: template 2.16.840.1.113883.10.12.108 (2005‑09‑07)
Example	Example <participant typeCode="IND">   <templateId root="2.16.756.5.30.1.1.10.2.43"/>  <templateId root="1.3.6.1.4.1.19376.1.5.3.1.2.4"/>  <associatedEntity classCode="PRS">     <code code="WIFE" codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7RoleCode" displayName="wife"/>    <associatedPerson>       <name>         <family>Muster</family>        <given>Erika</given>      </name>    </associatedPerson>  </associatedEntity></participant>
Item DT Card Conf Description Label hl7:participant 0 … * Information on a invoice recipient. (Par...ent) @typeCode cs 1 …