Ehscda:CDA-CH-LRTP (specification)

From eHealth Suisse
Jump to: navigation, search


Autoren Tony Schaller (medshare GmbH); Cornelia Schmid (medshare GmbH)


Identifikation dieses Dokuments
Abkürzung: CDA-CH-lrtp
OID: TODO

Zweck und Positionierung

Gleichstellung von Mann und Frau

Elektronische Version

Contents


Zusammenfassung

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 .

Einleitung

Ausgangslage und Motivation

Die ärztlichen Untersuchungen und Laborbefunde (Blut-, Urin-, Gewebeuntersuchungen etc.) sind in der Transplantationsmedizin essentiell. Es ist wichtig, dass die Laborbefunde korrekt im Organzuteilungssystem erfasst werden.

Der Erfolg einer Transplantation hängt massgeblich von der Ausprägung der Fähigkeit des Organismus ab, fremdes Eiweiss zu erkennen. Wenn das Immunsystem des Empfängers das transplantierte Organ als fremd erkennt, dann kommt es zu einer Organabstossung.

Ebenso wie die Merkmale der roten Blutkörperchen in Gruppen (Blutgruppen 0, A, B und AB) eingeteilt werden, können auch Gewebemerkmale definiert werden. Die Übereinstimmung der HLA-Merkmale zwischen Spender und Empfänger bestimmt zusammen mit der Identität bzw. Kompatibilität der Blutgruppe, ob ein transplantiertes Organ als fremd erkannt wird oder nicht. Bestehen beim Empfänger bereits Antikörper gegen spezifische HLA-Merkmale, ist die Gefahr gross, dass das Organ abgestossen wird.

Mit Einführung der Luminex-Technologie als neue Methode ist es jetzt möglich, beim Empfänger spenderspezifische Antikörper zu bestimmen. Diese werden mit einer Fluoreszenzmethode gemessen. Als semiquantitatives Mass für die Konzentration eines spezifischen Antikörpers wird der sogenannte „mean fluorescent intensity value“ (MFI) angegeben. Nach aktueller wissenschaftlicher Literatur ist ein spenderspezifischer Antikörper prognostisch relevant, wenn der MFI-Wert des HLA Antikörpers 1'000 oder mehr beträgt. Alle Patienten mit einem MFI-Wert unter 1'000 gelten somit als Patientinnen und Patienten ohne spenderspezifische Antikörper. Beträgt der MFI-Wert eines HLA Antikörpers 10‘000 oder mehr, spricht man von einem „avoid“. Ein „avoid“ ist ein klare Kontraindikation für eine Transplantation, da ein sehr hohes Risiko besteht, dass das transplantierte Organ aufgrund der vorhandenen Anti-HLA-Antikörper akut abgestossen wird.

Derzeit (2013) werden die Resultate der MFI-Bestimmung für die Allokation von Spendernieren verwendet; die Verwendung für die Allokation von Pankreata und Inselzellen wird diskutiert. Möglicherweise folgen mit der Zeit weitere Organe. Bei den Patienten auf der Warteliste werden spenderspezifische Antikörper alle drei bis vier Monate neu bestimmt. Die MFI-Werte werden einmal jährlich und zusätzlich je nach Bedarf (z.B. nach einer Bluttransfusion) neu bestimmt. Hinzu kommen Personendaten sowie nicht immunologische Daten wie z.B. Serologie, Blut- und Urin-Proben und Blutgaswerte. Zudem werden für die Patienten auf der Warteliste sowie für die Organspender auch weitere Daten wie z.B. Gewicht, Grösse, Blutdruck etc. (Vitalzeichen) dokumentiert.

Der Umfang der derzeit manuell im SOAS (Swiss Organ Allocation System) einzugebenden Daten und der damit verbundene Zeitaufwand ist hoch. Die Eingabe erfolgt zwar nach dem Vier-Augen-Prinzip; trotzdem ist eine solche manuelle Eingabe fehleranfällig.

Die Zuteilung der Organe wird durch ein spezielles Software-System SOAS (Swiss Organ Allocation System) unterstützt. SOAS wird vom Bundesamt für Gesundheit (BAG) betrieben und wird von der Nationalen Zuteilungsstelle durch die Stiftung Swisstransplant im Auftrag des BAG genutzt. SOAS speichert die Daten von Spenderinnen und Spendern bzw. Empfängerinnen und Empfängern, unterstützt die Koordination beim Zuteilungsprozess und ermöglicht so eine Vereinfachung und höhere Sicherheit. Zudem werden die Zuteilungsentscheide nachvollziehbar und die Organzuteilung transparent.

Status und Zweck des Dokuments

Das vorliegende Dokument beschreibt die Übermittlung der Laborbefunde im Transplantationsprozess und definiert damit ein einheitliches Format für den Informationsaustausch im Bereich der Allokation von Organen. Das Dokument wurde vom Projektteam erarbeitet und beinhaltet die normative Spezifikation basierend auf HL7 CDA.

Das Koordinationsorgan eHealth Bund-Kantone („eHealth Suisse“) führte vom 9. September bis zum 2. Dezember 2013 mit dem vorliegenden Stand eine öffentliche Anhörung aller interessierten Kreise durch. Die Informatio-nen zur Anhörung wurden am 9. September 2013 auf www.e-health-suisse.ch unter der Rubrik „Aktuell“ aufgeschaltet. Nach Auswertung der Anhörungsergebnisse wurde die Spezifikation in einer aktualisierten Fassung zur Umsetzung in der Schweiz empfohlen.

Angesprochene Leserschaft

Der vorliegende Implementierungsleitfaden richtet sich an Fachleute im Transplantationswesen, im Spital und Labor bzw. Laborumfeld sowie bei Herstellern und Lieferanten von Software und IT-Systemen. 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 Abgrenzung

Eine sinnvolle Umsetzung der elektronischen Übermittlung von Laborbefunden bedingt Interoperabilität der beteiligten Systeme. Die "HL7 EHR Interoperability Work Group"[Anmerkung 1] unterteilt Interoperabilität in Technische Interoperabilität, Semantische Interoperabilität und 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.

Der vorliegende Implementierungsleitfaden gibt normativ die Spezifikationen vor für die semantische Interoperabilität von Systemen, die im Rahmen von Organzuteilungen die Laborbefunde zwischen Labors und SOAS übermitteln bzw. austauschen.

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. Der Implementierungsleitfaden macht zum Transportmechanismus keine Vorgaben, gibt jedoch, wo es sinnvoll ist, Empfehlungen ab.

Zusätzlich zu den Personen- und Labordaten sind für eine erfolgreiche Organtransplantation weitere Daten relevant (persönliche Gewohnheiten, Medikamentenbedarf, Beatmungen, Intubationen, Grund für die Hospitalisation, etc.). Deren Übermittlung ist jedoch nicht Gegenstand des vorliegenden Implementierungsleitfadens. Zum jetzigen Zeitpunkt beschränkt sich der Leitfaden auf Labordaten. Eine Erweiterung ist zu einem späteren Zeitpunkt problemlos möglich.

Grundlagen und Basistechnologien

Der vorliegende Implementierungsleitfaden baut vollständig auf HL7 V3 CDA und IHE Inhaltsprofilen auf.
Nutzen des Implementierungsleitfadens:

  • Ein klar definierter Standard für alle Laboratorien in der Transplantationsmedizin
  • Vereinheitlichen der Prozesse, Spezifikationen werden konform zur Strategie eHealth Schweiz erstellt,
  • Automatisierbare Validierung der Inhalte von Nutzdaten auf Basis von XML,
  • Automatisierbare Prüfung von Geschäftsregeln (Schematron) erhöht die Qualität und Konformanz der übermittelten bzw. ausgetauschten Nachrichten,
  • Aufwendungen in der SOAS-Softwareentwicklung lassen sich für mehrere Laboratorien wieder verwenden,
  • Gewährleistung der internationalen Interoperabilität etc.

Verantwortlichkeiten

Die Herausgeber genehmigen ausdrücklich die Anwendung des vorliegenden Leitfadens ohne Lizenz- und Nutzungsgebühren zum Zweck der Übermittlung der Laborbefunde im Transplantationsprozess und weisen darauf hin, dass dies mit dem Einverständnis aller an der Erarbeitung des Leitfadens beteiligten Mitwirkenden erfolgt. Die Nutzung des Leitfadens erfolgt in der Verantwortung der Anwender. Die Kodierung von Labordiagnoseinformationen basiert auf einem definierten Value Set, welches die akzeptierten Codes zur Erfassung der Laborbefunde im Transplantationsprozess definiert. Die Verantwortung für die Pflege und Publikation dieses Value Sets liegt bei der Sektion Transplantation und Fortpflanzungsmedizin des BAG.

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 .

Formelle Grundlagen

Notation

Im vorliegenden Dokument werden folgende verkürzte Darstellungen und visuelle Orientierungshilfen eingesetzt.

Notation Bedeutung Beispiel
XXXX alphanumerischer Platzhalter
[N/A] Not applicable (nicht anwendbar)
[XXXX] Angabe von referenzierten Dokumenten [VHitG Arzt-brief]
<XXXX> CDA Regelbezeichnung gemäss deutschem [VHitG Arztbrief] <TURS>
<CH-XXXX> Bezeichnung von zusätzlichen, schweizerischen CDA Regeln <CH-TZON>
[xx] Sprachdefinitionen:

de = Deutsch
fr = Französisch
it = Italienisch
en = Englisch

[de]
[XX] Optionalität (siehe auch Kapitel #Optionalität):

M = Mandatory / Zwingend
NP = Not permitted / Nicht erlaubt
R = Required / Erforderlich
R2 = Required if known / Erforderlich, wenn bekannt
O = Optional / Erlaubt / Freiwillig
C = Conditional / Bedingt erforderlich

[O]
[X..X] Kardinalitäten:

0..1 = höchstens einmal
0..* = mehrfach ohne Mindestangabe
1..1 = genau einmal
1..* = einmal oder mehrfach

[1..*]

[Tabelle 1] Notationen in diesem Dokument

Diese Notation wird eingesetzt um die allgemeine Verständigkeit und Einheitlichkeit der Prozesse sowie Relationen zu gewährleisten.

Bezug zu anderen Standards und Leitfäden

Das vorliegende Austauschformat baut auf folgenden Grundlagen auf:

Lrtp referenzpyramide.png

Lrtp referenzpyramide.png

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

IHE Integrationsprofile

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

Für dieses Austauschformat stehen die, in Kapitel #Tutorial zu IHE Integrationsprofilen kurz erläuterten Grundlagen der IHE im Zentrum. Dokumente, welche basierend auf IHE Inhaltsprofilen (Content Profiles) erstellt werden, können in einem Ordner (Folder) in der IHE Cross-enterprise document sharing Architektur (XDS) abgelegt werden. Dieses IHE Integrationsprofil ist die Basis für das verteilte elektronische Patientendossier (EPD) in der Schweiz.

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

HL7 V3

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 Organisati-on (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)

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.

Aufbauend auf HL7 CDA sind über den Standardisierungsprozess von eCH (E-Government-Standards) die eCH Standards eCH-0089[1] und eCH-0121[2] entstanden.

Empfehlungen Standards & Architektur

Zusätzlich und nicht direkt in oben dargestellter Referenzpyramide integrierbar nimmt das vorliegende Dokument Bezug auf bereits bestehende Empfehlungen von „eHealth Suisse“ (eHealth Koordinationsorgan Bund/Kantone):
Standards & Architektur:

  • Empfehlungen I (Ausgabe 2009)[3]
  • Empfehlungen II (Ausgabe 2010)[4]
  • Empfehlungen III (Ausgabe 2011)[5]
  • Empfehlungen IV (Ausgabe 2013)[6]
  • Empfehlungen V (Ausgabe 2014)[7]
  • OID Konzept (Ausgabe 2011)[8]

Semantik & Metadaten:

  • Empfehlungen I (Ausgabe 2013)[9]

Insbesondere „Empfehlung 9: Orientierung 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 entspre-chend erstellte Dokumente zudem auch grenzüberschreitend interoperabel.

Übersetzungen

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 .

Anwendungsfälle

Ausgangslage

Die Meldung von Spender- und Empfängerdaten wird im Transplantationsgesetz (SR 810.21) und der Transplantationsverordnung (SR 810.211) definiert. Im Transplantationsprozess ist eine Reihe von Informationen zu Spendern und Empfängern von Organen wichtig, um die bestmögliche Allokation von Organen erreichen zu können. Der vorliegende Implementierungsleitfaden beschränkt sich hauptsächlich auf den Bereich der Labors und zusätzlich auf Daten, welche für den Prozess der Organallokation ebenfalls relevant sind, wie z. B. Vitalzeichen (Körpergewicht und -grösse, Blutdruck etc.) oder die Medikation. Diese Informationen entstammen aus unterschiedlichen Datenquellen (Pflegeanamnese etc.) innerhalb eines Spitals und müssen dort vor der Übermittlung an SOAS gegebenenfalls aus mehreren Informationssystemen zusammengeführt werden. Siehe Kapitel #Ziele und Abgrenzungen für weitere Informationen zur Abgrenzung.

Die nachfolgend beschriebenen Anwendungsfälle sind exemplarisch und beschreiben die Übermittlung von Spender- und Empfängerdaten zwischen den involvierten Institutionen. Dort wo sinnvoll, wird man den vorliegenden Implementierungsleitfaden auch für die Kommunikation zwischen Systemen innerhalb einer Institution (z. B. zwischen Laborsystemen, Kliniksystemen etc.) anwenden wollen. Alle denkbaren damit verbundenen Anwendungsfälle aufzuführen würde jedoch den Rahmen dieses Dokumentes sprengen.

Übermittlung von Spender-Labordaten

Für alle beschriebenen Fälle ist eine grafische Darstellung im Kapitel #Synopsis zu finden.

Zweck

Labordaten von Organspendern werden von Spitälern bzw. Transplantationszentren an SOAS übermittelt damit die Organe einem Empfänger zugeteilt werden können.

Akteuere

Es sind die folgenden Akteure beteiligt:

  • Absender der elektronischen Nachricht: Applikation in einem Spital, welche Spender-Labordaten an SOAS sendet. Zur Beachtung: In jedem Spital / Transplantationszentrum soll von genau einer Applikation mit SOAS kommuniziert werden.
  • Empfänger der elektronischen Nachricht: SOAS

In einer späteren Ausbaustufe vorgesehen:

  • Absender der elektronischen Nachricht: SOAS
  • Empfänger der elektronischen Nachricht: Applikation in einem Transplantationszentrum, welche Spender-Labordaten von SOAS empfängt. Zur Beachtung: In jedem Spital / Transplantationszentrum soll von genau einer Applikation mit SOAS kommuniziert werden.

Auf der Basis des vorliegenden Implementierungsleitfadens kann sowohl die Kommunikation von den Spitälern /Transplantationszentren zu SOAS als auch die Kommunikation in der Gegenrichtung implementiert werden. In einem ersten Schritt soll allerdings nur ersteres realisiert werden. Die praktische Umsetzung der Kommunikation in der Gegenrichtung und damit einer bidirektionalen Kommunikation wird nur die Transplantationszentren betreffen.

Ablauf Fall 1: Meldung durch Transplantationszentrum

IST Zustand

Wird in einem Transplantationszentrum ein potenzieller Spender detektiert, gibt der lokale Koordinator die benötigten Spenderdaten manuell im SOAS ein (inkl. Labordaten). Das HLA-Labor des Transplantationszentrums gibt die HLA-Typisierung separat ein. Swisstransplant hat unter anderem eine Kontrollfunktion: Sie überprüft die Daten auf Vollständigkeit. Sobald alle zuteilungsrelevanten Daten verfügbar sind, wird die Organallokation gestartet. Aus der Dateneingabe ist heute nicht ersichtlich, ob es sich um Labordaten direkt aus dem Analyzer oder um medizinisch validierte Labordaten handelt.

SOLL Zustand

Wie beim IST-Zustand mit dem Unterschied, dass die Labordaten eines Spenders vom entsprechenden Laborinformationssystem im Transplantationszentrum direkt und ohne manuelle Eingabe durch einen Benutzer elektronisch an SOAS übermittelt und dort automatisch erfasst werden. Zudem soll bei der elektronischen Datenübertragung der Autor eines Messwerts angegeben werden. Damit wird ermöglicht, dass in SOAS auch angezeigt werden könnte, ob die Messwerte medizinisch validiert sind oder nicht.

Für die Qualität der Spender-Labordaten (Vollständigkeit und Korrektheit) ist das Transplantationszentrum verantwortlich. Swisstransplant wird die Daten auf Vollständigkeit überprüfen. Sobald alle zuteilungsrelevanten Daten verfügbar sind, wird die Organallokation gestartet.

Ablauf Fall 2a: Meldung durch peripheres Spital mit SOAS-Zugriff

IST Zustand

Wird in einem peripheren Spital mit SOAS-Zugriff ein potenzieller Spender detektiert, gibt der lokale Koordinator manuell alle Spenderangaben zur Person ein (inkl. Labordaten). Das HLA-Labor des zuständigen Transplantationszentrums gibt ebenfalls manuell die HLA-Typisierungen ein. Swisstransplant hat meistens nur eine Koordinations- und Kontrollfunktion: Sie überprüft die Daten auf Vollständigkeit. Sobald alle zuteilungsrelevanten Daten verfügbar sind, wird die Organallokation gestartet.

SOLL Zustand

Wie beim IST-Zustand mit dem Unterschied, dass die Labordaten eines Spenders vom entsprechenden Laborinformationssystem im peripheren Spital oder von einem benachbarten Transplantationszentrum direkt und ohne manuelle Eingriffe durch einen Benutzer elektronisch an SOAS übermittelt und dort automatisch erfasst werden. Diese Lösung kann von peripheren Spitälern mit hohem Spenderaufkommen genutzt werden.

Für die Qualität der Spender-Labordaten (Vollständigkeit und Korrektheit) ist das Spital verantwortlich. Swisstransplant wird meistens nur eine Koordinations- und Kontrollfunktion haben: Sie überprüft die Daten auf Vollständigkeit. Sobald alle zuteilungsrelevanten Daten verfügbar sind, wird die Organallokation gestartet.

Ablauf Fall 2b: Meldung durch peripheres Spital ohne SOAS-Zugriff

IST Zustand

Wird in einem peripheren Spital ohne SOAS-Zugriff ein potenzieller Spender detektiert, reist der lokale Koordinator des zuständigen Netzwerkes in das periphere Spital und gibt analog wie im Fall 2a die Daten ein. Sehr selten werden die Daten per Fax an Swisstransplant übermittelt. Swisstransplant übernimmt in diesem Fall die SOAS-Dateneingabe und startet die Allokation.

SOLL Zustand

Periphere Spitäler ohne SOAS-Zugriff werden auch künftig keine Labordaten elektronisch an SOAS übermitteln können. Wenn diese Spitäler künftig einen SOAS-Zugriff erhalten, werden sie ihre Spenderdaten analog wie im Fall 2a an SOAS elektronisch übermitteln können.

Bemerkungen

Es sei darauf hingewiesen, dass Prozesse und Workflow innerhalb der beteiligten Institutionen zweckmässigerweise so gestaltet werden sollen, dass Medienbrüche und dadurch notwendige manuelle Bearbeitungen weitestgehend entfallen. Dort wo möglich wird man auch die Inhouse-Kommunikation zwischen Applikationen nach diesem Leitfaden implementieren und sich so Umkodierungen etc. ersparen.

Der vorliegende Implementierungsleitfaden beschränkt sich auf die Über-mittlung von Labordaten. Für andere in der Meldung enthaltene Daten wird auf Kapitel #CDA Body verwiesen. Eine spätere Erweiterung, welche zusätzlich zu den Labordaten auch die Übermittlung solcher transplantationsrelevanter Daten erlaubt, ist möglich.

Übermittlung von Empfänger-Labordaten

Zweck

Die Transplantationszentren übermitteln die Labordaten der Organempfänger an SOAS, damit diese bei der Organzuteilung berücksichtigt werden können.

Akteure

Es sind die folgenden Akteure beteiligt:

  • Absender der elektronischen Nachricht: Applikation in einem Transplantationszentrum, welche Empfänger-Labordaten an SOAS sendet. Zur Beachtung: In jedem Transplantationszentrum soll von genau einer Applikation mit SOAS kommuniziert werden.
  • Empfänger der elektronischen Nachricht: SOAS

Ablauf

IST Zustand

Wenn ein Patient eine Organtransplantation benötigt, gibt der lokale Koordinator die benötigten Empfängerdaten (inkl. Labordaten) manuell im SOAS ein. Das HLA-Labor des Transplantationszentrums gibt die HLA-Typisierung sowie die Anti-HLA-Antikörper separat ein. Swisstransplant hat unter anderem eine Kontrollfunktion: Sie überprüft die Daten auf Vollständigkeit. Wenn alle zuteilungsrelevanten Daten des Empfängers im SOAS verfügbar sind, kann der Patient bei der Organallokation berücksichtigt werden. Aus der Dateneingabe ist heute nicht ersichtlich, ob es sich um Labordaten direkt aus dem Analyzer oder um medizinisch validierte Labordaten handelt.

SOLL Zustand

Wie beim IST-Zustand mit dem Unterschied, dass die Labordaten eines Organempfängers vom entsprechenden Laborinformationssystem im Transplantationszentrum direkt und ohne manuelle Eingabe durch einen Benutzer elektronisch an SOAS übermittelt und dort automatisch erfasst werden. Zudem soll bei der elektronischen Datenübertragung der Autor zum Messwert angegeben werden. Damit wird ermöglicht, dass in SOAS auch angezeigt werden könnte, ob die Messwerte medizinisch validiert sind oder nicht.

Für die Qualität der Labordaten eines Organempfängers- (Vollständigkeit und Korrektheit) ist das zuständige Transplantationszentrum verantwortlich. Swisstransplant wird eine Kontrollfunktion haben und überprüft die Daten auf Vollständigkeit. Sobald alle zuteilungsrelevanten Daten des Organempfängers im SOAS verfügbar sind, kann der Patient bei der Organallokation berücksichtigt werden.

Bemerkungen

Siehe Kapitel #Bemerkungen.

Synopsys

Lrtp uebersicht uc.png

Lrtp uebersicht uc.png

[Abbildung 2]Immunisierung Schematische Darstellung des Transfers von Spender- und Empfängerdaten

(*) Der Datentransfer von SOAS zu den Transplantationszentren wurde 2013 noch nicht implementiert. Zur Information: Spitäler ohne Zugriff auf SOAS übermitteln die Spenderdaten entweder per Fax direkt an Swisstransplant oder der lokale Koordinator des zuständigen Netzwerkes reist in das periphere Spital und gibt die Spenderdaten im SOAS ein.

Transportmechanismus

Spezifikation (normativ)

Dieses Material ist Teil

des Leitfadens eHealth Suisse Implementierungsleitfaden.

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

Allgemeines

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

Die normative Spezifikation definiert das Dokument "Laborbefund im Transplantationsprozess" als HL7 CDA Vorlage, welche auf die helvetischen Präzisierungen ([CDA-CH][1] und [CDA-CH-II][2]) aufbaut. Damit produzierte Dokumente sind vollständig kompatibel zum internationalen HL7 CDA R2 Standard (Normative Edition 2005) und somit international interoperabel.

Die normative Spezifikation bezweckt, dass Systeme für das Handling von "Laborbefund im Transplantationsprozess" durch die Softwarehersteller unabhängig von Sender und Empfänger implementiert werden können. Zum vorliegenden Austauschformat werden auch Schematron-Regeln erarbeitet, welche eine automatisierte und harmonisierte Validierung der CDA-Dokumente erlauben.

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. VHitG Arztbrief V1.5
  4. Spezifikation CDA-CH
  5. Spezifikation CDA-CH-II
  6. IHE Laboratory (LAB) Technical Framework Volume 3 (LAB TF-3) Content Sharing Laboratory Reports (XD-LAB) Content Module

Für die Umsetzung der Schematron Regeln wird auf der Grundlage von ISO Schematron aufgebaut:

Schlüsselwörter

Die normative Spezifikation verwendet folgende, jeweils in Grossbuchstaben geschriebene Schlüsselwörter zu Angabe von Verbindlichkeiten. Siehe auch [ELGA Allgemein][11], 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 [R2].
KANN oder OPTIONAL (engl. MAY, OPTIONAL). Die Umsetzung der Anforderung ist optional, sie kann auch ohne zwingenden Grund unterbleiben. Entspricht dem Optionalität [O].

Optionalität

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

Optionalitäten Mögliche Kardinalitäten Verwendung von nullFlavor Beschreibung
[M] 1..1

1..*

NICHT ERLAUBT Das Element MUSS mit einem korrekten "echten" Wert angegeben werden.

nullFlavor oder "Dummy"-Werte sind NICHT ERLAUBT.

[NP] 0..0 NICHT ERLAUBT Element ist NICHT ERLAUBT.
[R] 1..1

1..*

KANN verwendet werden Das Element MUSS in der Instanz vorhanden sein. Wenn nicht bekannt, ist die Verwen-dung von nullFlavor vorgeschrie-ben, "Dummy"-Werte sind NICHT ERLAUBT.
[R2] 0..1

0..*

NICHT ERLAUBT Das Element SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein.

nullFlavor ist 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.

nullFlavor

Wenn ein Wert nicht bekannt ist, kann dort wo es gemäss obenstehender Tabelle erlaubt ist, mit den nullFlavor-Codes in #Sonderfälle bei fehlenden Angaben (nullFlavor) der Grund für die fehlende Angabe präzisiert 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 .

Akteure und Transaktionen

Nachfolgende Grafik zeigt die mit dem vorliegenden Implementierungsleitfaden definierten Akteure und Transaktionen. Die Illustration stammt aus [IHE LAB TF-1], Kapitel „9.1.4 Reports systematically shared by a private or hospital lab“ auf Seite 86)[13]. Die Grafik zeigt auf, dass die involvierten Akteure rund um Laborbefunde im Transplantationsprozess einen Befund auf Basis von IHE XD-LAB machen können.

Lrtp akteure ihe lap tf1.png

Lrtp akteure ihe lap tf1.png

[Abbildung 4]Akteure gemäss IHE LAB TF-1

IHE XD-LAB (IHE LAB TF-3, Kapitel „9.2.1“) nennt die Umsetzung mit den IHE Interaktionsprofilen XDS, XDR, XDM. XDM ist allerdings für die vorlie-gende Problemstellung nicht relevant; es wird deshalb nicht näher auf XDM eingegangen Die IHE Integrationsprofile XDS und XDR realisieren die Interaktion „Share content“ mit der IHE Transaktion „Provide and Register Document Set-b [ITI-41]“:

Lrtp akteure transaktionen xds xdr.png

Lrtp akteure transaktionen xds xdr.png

[Abbildung 5] Akteure und Transaktionen (konkret für XDS und XDR)

Bei allen oben genannten Transaktionen ist der Inhalt des übertragenen Dokuments (Content) identisch und gemäss Kapitel ‎#CDA Struktur aufgebaut. Für eine genaue Beschreibung der Akteure, Transaktionen und Inhalte verweisen wir auf die IHE Dokumentation[14], Kapitel „3.32 Distribute Document Set on Media“ resp. „3.41 Provide and Register Document Set-b“, da die eigentliche Übermittlung / Speicherung (Share Content) nicht Bestandteil der vorliegenden Spezifikation ist.

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 .

CDA Struktur

Das CDA Dokument baut auf vorbestehenden Spezifikationen auf und muss demzufolge die notwendige Konformität zu folgenden Templates aufweisen.

[Tabelle 2] Spezifikationen und Templates für CDA Struktur

Spezifikation templateId
Sharing Laboratory Reports (XD-LAB) Con-tent Module 1.3.6.1.4.1.19376.1.3.3
CDA-CH 2.16.756.5.30.1.1.1.1
Laborbefunde im Transplantationsprozess V1 2.16.756.5.30.1.1.1.1.3.4.1


Vorstehende Vorgaben erzeugen folgende Vorgaben für die Dokumentenstruktur (CDA-Header):

Lrtp modell cda header.png

Lrtp modell cda header.png

[Abbildung 6] Modell CDA-Header

Die eigentlichen, medizinischen Inhalte werden im CDA-Body nach folgender Struktur dokumentiert:

Lrtp modell cda body.png

Lrtp modell cda body.png

[Abbildung 7] Modell CDA-Body


[Tabelle 3] Regel zum CDA Body

Regel Beschreibung Quelle/Referenz
<CDA-CH-LRTP-DOC> Keines der Kapitel (CDA Body Section) ist zwingend. Mindestens eines davon muss aber in jedem CDA-CH-LRTP Dokument vorhanden sein.
CDA-CH-LRTP

Allgmeine CDA Regeln

Unabhängig davon, ob es sich um Elemente aus dem CDA Header oder dem CDA Body handelt, gilt folgende Regel in Ergänzung zu [CDA-CH][1] und [CDA-CH-II][2]:

[Tabelle 4] Allgemeine CDA Regeln

Regel Beschreibung Quelle/Referenz
<CH-TZON> Zeitangaben SOLLEN mit der Angabe der Zeitzone erfolgen. Dies gilt nicht für Zeitangaben, die sich auf das Datum beschränken. Die Angabe der Zeitzone in der Schweiz erfolgt während der Sommerzeit mit UTC +2 Stunden und in der Winterzeit mit +1 Stunde.

Beispiel Sommerzeit: <effectiveTime value="201207162100+0200"/>
Beispiel Winterzeit: <effectiveTime value="201211240907+0100"/>

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 .

CDA Header

CDA RealmCode

Keine Versionen mit Status draft, active, review oder pending.

CDA TypeId

Keine Versionen mit Status draft, active, review oder pending.

CDA Document Id

Keine Versionen mit Status draft, active, review oder pending.

CDA Document Title

Keine Versionen mit Status draft, active, review oder pending.

CDA Document Language Code

Keine Versionen mit Status draft, active, review oder pending.

CDA SetId VersionNumber

Keine Versionen mit Status draft, active, review oder pending.

CDA recordTarget (lrtp)

Id2.16.756.5.30.1.127.10.2.29Effective Date valid from 2016‑07‑02
StatusKyellow.png DraftVersion Label
NameCDARecordTargetlrtpDisplay NameCDA recordTarget (lrtp)
Description
(de-CH) Erforderliche Patientenstammdaten sind Name, Vorname, Geburtsdatum, Geschlecht
Die Spender- resp. Empfänger-ID (der sogenannte SOAS-Code) MUSS beim Patienten folgendermassen angegeben werden:
root=2.16.756.5.30.1.129.1.1.1 extension: SOAS-ID
Andere Werte dürfen nicht angegeben werden, z.B. Wohnsitz. Diese Werte MÜSSEN mit nullFlavor='MSK' deklariert werden.
ClassificationCDA Header Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 2 templates, Uses 0 templates
Used by as NameVersion
2.16.756.5.30.1.127.10.1.3IncludeKyellow.png Laborbefund Transplantationsprozesss2017‑08‑14
2.16.756.5.30.1.127.10.1.3IncludeKvalidblue.png Laborbefund Transplantationsprozesss2016‑07‑02
RelationshipSpecialization: template 2.16.840.1.113883.10.12.101 (2005‑09‑07)
Example
Example
<recordTarget>
  <patientRole>
    <id extension="123.95.332.115" root="2.16.756.5.31"/>    <id extension="012/08.111111" root="2.16.756.5.30.999999.1"/>    <!-- SOAS ID -->
    <id extension="DD-2012-9999" root="2.16.756.5.30.1.129.1.1.1"/>    <addr nullFlavor="MSK"/>    <telecom nullFlavor="MSK"/>    <patient>
      <name>
        <given>Franz Leichenspender</given>        <family>Muster</family>      </name>
      <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>      <birthTime value="19950127"/>    </patient>
  </patientRole>
</recordTarget>
ItemDTCardConfDescriptionLabel
hl7:recordTarget
1 … 1R(CDA…rtp)
Treetree.png@typeCode
cs0 … 1FRCT
Treetree.png@context​Control​Code
cs0 … 1FOP
Treetree.pnghl7:patientRole
1 … 1R(CDA…rtp)
Treeblank.pngTreetree.png@classCode
cs0 … 1FPAT
Treeblank.pngTreetree.pnghl7:id
II0 … *R(CDA…rtp)
Treeblank.pngTreeblank.png where [not(@root='2.16.756.5.30.1.129.1.1.1')]
Treeblank.pngTreetree.pnghl7:id
II1 … 1M(CDA…rtp)
Treeblank.pngTreeblank.png where [@root='2.16.756.5.30.1.129.1.1.1']
Treeblank.pngTreeblank.pngTreetree.png@root
1 … 1F2.16.756.5.30.1.129.1.1.1
Treeblank.pngTreeblank.pngTreetree.png@extension
1 … 1R
(de-CH) SOAS-ID
Treeblank.pngTreetree.pnghl7:patient
0 … 1(CDA…rtp)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1R(CDA…rtp)
Treeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CE1 … 1R(CDA…rtp)
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.1 AdministrativeGender (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS1 … 1R(CDA…rtp)

CDA author

Keine Versionen mit Status draft, active, review oder pending.

CDA Data Enterer

Id2.16.756.5.30.1.1.10.2.7Effective Date valid from 2017‑03‑09 15:12:38

There are versions of templates with this id:
  • cdach_header_DataEnterer as of 2017‑03‑09 15:12:38
  • CDAdataEnterer as of 2009‑01‑27
StatusKyellow.png DraftVersion Label2017
Namecdach_header_DataEntererDisplay NameData Enterer
Description
Information about the person that entered information in this CDA document. It SHALL be declared, when data recorded in this document has been entered by a person other than the author but only when this is relevant for some reason. All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST reference this template.
ContextParent nodes of template element with id 2.16.756.5.30.1.1.10.2.7
ClassificationCDA Header Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 3 templates, Uses 1 template
Used by as NameVersion
2.16.756.5.30.1.1.10.9.36IncludeKyellow.png CDA-CH v2.0 Header Template Compilation (2017)2017‑11‑09 11:38:30
2.16.756.5.30.1.1.10.1.12Link.pngKyellow.png CDA-CH v2.0 - nonXMLBody (2017)2017‑11‑09 11:30:07
2.16.756.5.30.1.1.10.1.9Link.pngKyellow.png CDA-CH v2.0 - structuredBody (2017)2017‑03‑28 23:43:12
Uses as NameVersion
2.16.756.5.30.1.1.10.9.12ContainmentKyellow.png Assigned Entity Compilation with id (2017)DYNAMIC
RelationshipSpecialization: template 2.16.840.1.113883.10.12.103 (2005‑09‑07)
Version: template 2.16.756.5.30.1.1.10.2.7 (2009‑01‑27)
Example
Example
<dataEnterer>
  <templateId root="2.16.756.5.30.1.1.10.2.7"/>  <time value="201709122029+0200"/>  <assignedEntity>
    <id root="2.999" extension="0812763"/>    <assignedPerson>
      <name>
        <given>Jean</given>        <family>Dupont</family>      </name>
    </assignedPerson>
  </assignedEntity>
</dataEnterer>
ItemDTCardConfDescriptionLabel
hl7:dataEnterer
0 … 1Information about the person that entered information in this CDA document. It SHALL be declared, when data recorded in this document has been entered by a person other than the author but only when this is relevant for some reason.(cda...rer)
Treetree.pnghl7:templateId
II1 … 1M(cda...rer)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.7
Treetree.pnghl7:time
TS.CH.TZ0 … 1Timestamp of the data input.(cda...rer)
Treetree.pnghl7:assignedEntity
1 … 1RContains 2.16.756.5.30.1.1.10.9.12 Assigned Entity Compilation with id (DYNAMIC)(cda...rer)

CDA custodian

Id2.16.756.5.30.1.1.10.2.3Effective Date valid from 2017‑10‑13 09:00:36

There are versions of templates with this id:
  • cdach_header_Custodian as of 2017‑10‑13 09:00:36
  • CDAcustodian as of 2017‑10‑13 08:59:41
  • CDAcustodian as of 2017‑10‑13 08:58:58
  • CDAcustodian as of 2017‑10‑13 08:58:27
  • CDAcustodian as of 2009‑01‑27
StatusKyellow.png DraftVersion Label2017
Namecdach_header_CustodianDisplay NameCustodian
Description
The organization in whose name this CDA document has been created (corresponds to the sender of a letter). All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST use this template by either reference or specialisation.
ClassificationCDA Header Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 3 templates, Uses 1 template
Used by as NameVersion
2.16.756.5.30.1.1.10.9.36IncludeKyellow.png CDA-CH v2.0 Header Template Compilation (2017)2017‑11‑09 11:38:30
2.16.756.5.30.1.1.10.1.12Link.pngKyellow.png CDA-CH v2.0 - nonXMLBody (2017)2017‑11‑09 11:30:07
2.16.756.5.30.1.1.10.1.9Link.pngKyellow.png CDA-CH v2.0 - structuredBody (2017)2017‑03‑28 23:43:12
Uses as NameVersion
2.16.756.5.30.1.1.10.9.35ContainmentKyellow.png Address Information Compilation - eCH-0010 (2017)DYNAMIC
RelationshipSpecialization: template 2.16.840.1.113883.10.12.104 (2005‑09‑07)
Example
Example
<custodian>
  <assignedCustodian>
    <representedCustodianOrganization>
      <id extension="7601234567890" root="2.51.1.3"/>      <name>Gruppenpraxis CH</name>      <telecom value="tel:+41.32.234.55.66" use="WP"/>      <addr use="WP">
        <streetName>Doktorgasse</streetName>        <houseNumber>2</houseNumber>        <city>Musterhausen</city>        <postalCode>8888</postalCode>        <country>CH</country>      </addr>
    </representedCustodianOrganization>
  </assignedCustodian>
</custodian>
ItemDTCardConfDescriptionLabel
hl7:custodian
1 … 1RThe organization in whose name this CDA document has been created (corresponds to the sender of a letter).(cda...ian)
Treetree.pnghl7:assignedCustodian
1 … 1R(cda...ian)
Treeblank.pngTreetree.pnghl7:represented​Custodian​Organization
1 … 1R(cda...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *MThe custodian's id.(cda...ian)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1RThe id itself. It MUST be unique within the issuing system.
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1RThe OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED.
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1RThe custodian's name.(cda...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … 1The custodian's means of communication (phone, eMail, ...).(cda...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1The custodian's address(es).
Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC)
(cda...ian)

CDA informationRecipient

Id2.16.756.5.30.1.1.10.2.4Effective Date valid from 2017‑09‑08 20:20:58

There are versions of templates with this id:
  • cdach_header_InformationRecipient as of 2017‑09‑08 20:20:58
  • CDAinformationRecipient as of 2009‑01‑27
StatusKyellow.png DraftVersion Label2017
Namecdach_header_InformationRecipientDisplay NameRecipient - informationRecipient
Description
A recipient of this CDA document (corresponds to the addressee of a letter - person or organization). All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST use this template by either reference or specialisation.
ClassificationCDA Header Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 3 templates, Uses 3 templates
Used by as NameVersion
2.16.756.5.30.1.1.10.9.36IncludeKyellow.png CDA-CH v2.0 Header Template Compilation (2017)2017‑11‑09 11:38:30
2.16.756.5.30.1.1.10.1.12Link.pngKyellow.png CDA-CH v2.0 - nonXMLBody (2017)2017‑11‑09 11:30:07
2.16.756.5.30.1.1.10.1.9Link.pngKyellow.png CDA-CH v2.0 - structuredBody (2017)2017‑03‑28 23:43:12
Uses as NameVersion
2.16.756.5.30.1.1.10.9.35ContainmentKyellow.png Address Information Compilation - eCH-0010 (2017)DYNAMIC
2.16.756.5.30.1.1.10.9.34ContainmentKyellow.png Person Name Information Compilation - eCH-0011 (2017)DYNAMIC
2.16.756.5.30.1.1.10.9.24ContainmentKyellow.png Organization Compilation with name (2017)DYNAMIC
RelationshipVersion: template 2.16.756.5.30.1.1.10.2.4 (2009‑01‑27)
Specialization: template 2.16.840.1.113883.10.12.105 (2005‑09‑07)
Example
Primary Recipient
<informationRecipient typeCode="PRCP">
  <intendedRecipient>
    <informationRecipient>
      <name>Kurhaus Blumenalp, Zentrum für orthopädische Rehabilitation, Aerztliche Leitung</name>    </informationRecipient>
    <receivedOrganization>
      <addr use="WP">
        <postalCode>9876</postalCode>        <city>Blumenalp</city>        <country>CH</country>      </addr>
    </receivedOrganization>
  </intendedRecipient>
</informationRecipient>
Example
Other Recipient
<informationRecipient typeCode="TRC">
  <intendedRecipient>
    <informationRecipient>
      <name>Gruppenpraxis CH, Dr. med. Allzeit Bereit, FMH Allgemeine Medizin</name>    </informationRecipient>
    <receivedOrganization>
      <addr use="WP">
        <streetName>Doktorgasse</streetName>        <houseNumber>2</houseNumber>        <postalCode>8888</postalCode>        <city>Musterhausen</city>        <country>CH</country>      </addr>
    </receivedOrganization>
  </intendedRecipient>
</informationRecipient>
ItemDTCardConfDescriptionLabel
hl7:information​Recipient
1 … *R 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...ent)
Treetree.png@typeCode
cs1 … 1R The main recipient of the document is indicated by typeCode 'PRCP' (primary recipient).
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)
Treetree.pnghl7:intended​Recipient
1 … 1R(cda...ent)
Treeblank.pngTreetree.pnghl7:id
II0 … *RThe recipient's identification(s).(cda...ent)
Treeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1RThe id itself. It MUST be unique within the issuing system.
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1RThe OID of the system that issued the id. OIDs of code systems, which are published in a public OID registry are REQUIRED. Others are NOT ALLOWED.
Treeblank.pngTreetree.pnghl7:addr
AD0 … *The recipient's address(es).
Contains 2.16.756.5.30.1.1.10.9.35 Address Information Compilation - eCH-0010 (DYNAMIC)
(cda...ent)
Treeblank.pngTreetree.pnghl7:telecom
TEL0 … *The recipient's means of communication (phone, eMail, ...).(cda...ent)
Treeblank.pngTreetree.pnghl7:information​Recipient
0 … 1The addressee person.
Contains 2.16.756.5.30.1.1.10.9.34 Person Name Information Compilation - eCH-0011 (DYNAMIC)
(cda...ent)
Treeblank.pngTreetree.pnghl7:received​Organization
0 … 1The addressee organization.
Contains 2.16.756.5.30.1.1.10.9.24 Organization Compilation with name (DYNAMIC)
(cda...ent)

CDA legealAuthenticator

Id2.16.756.5.30.1.1.10.2.5Effective Date valid from 2017‑09‑12 19:55:51

There are versions of templates with this id:
  • cdach_header_LegalAuthenticator as of 2017‑09‑12 19:55:51
  • CDAlegalAuthenticator as of 2009‑01‑27
StatusKyellow.png DraftVersion Label2017
Namecdach_header_LegalAuthenticatorDisplay NameLegal Authenticator
Description
Information about the legal authenticator of a CDA document. A legal authenticator MUST be a person. All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST use this template by either reference or specialisation.
ClassificationCDA Header Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 3 templates, Uses 1 template
Used by as NameVersion
2.16.756.5.30.1.1.10.9.36IncludeKyellow.png CDA-CH v2.0 Header Template Compilation (2017)2017‑11‑09 11:38:30
2.16.756.5.30.1.1.10.1.12Link.pngKyellow.png CDA-CH v2.0 - nonXMLBody (2017)2017‑11‑09 11:30:07
2.16.756.5.30.1.1.10.1.9Link.pngKyellow.png CDA-CH v2.0 - structuredBody (2017)2017‑03‑28 23:43:12
Uses as NameVersion
2.16.756.5.30.1.1.10.9.12ContainmentKyellow.png Assigned Entity Compilation with id (2017)DYNAMIC
RelationshipVersion: template 2.16.756.5.30.1.1.10.2.5 (2009‑01‑27)
Specialization: template 2.16.840.1.113883.10.12.106 (2005‑09‑07)
Example
Example
<legalAuthenticator>
  <time value="201711101453+0100"/>  <signatureCode code="S"/>  <assignedEntity>
    <id nullFlavor="NI"/>    <assignedPerson>
      <name>Hausarzt</name>    </assignedPerson>
  </assignedEntity>
</legalAuthenticator>
Example
Example
<legalAuthenticator>
  <time value="20150604"/>  <signatureCode code="S"/>  <assignedEntity>
    <id root="2.51.1.3" extension="7601234567890"/>    <assignedPerson>
      <name>
        <given>Allzeit</given>        <family>Bereit</family>        <prefix>Dr. med.</prefix>      </name>
    </assignedPerson>
    <representedOrganization>
      <id root="2.51.1.3" extension="7608888888888"/>      <name>Gruppenpraxis CH</name>      <telecom value="tel:+41.32.234.55.66" use="WP"/>      <telecom value="fax:+41.32.234.55.67" use="WP"/>      <telecom value="mailto:bereit@gruppenpraxis.ch" use="WP"/>      <telecom value="http:www.gruppenpraxis.ch" use="WP"/>      <addr use="WP">
        <streetName>Doktorgasse</streetName>        <houseNumber>2</houseNumber>        <city>Musterhausen</city>        <postalCode>8888</postalCode>        <country>CH</country>      </addr>
    </representedOrganization>
  </assignedEntity>
</legalAuthenticator>
ItemDTCardConfDescriptionLabel
hl7:legalAuthenticator
0 … 1Information about the legal authenticator of a CDA document. A legal authenticator MUST be a person.(cda...tor)
Treetree.pnghl7:time
TS.CH.TZ1 … 1RTimestamp of the signature.(cda...tor)
Treetree.pnghl7:signatureCode
CS1 … 1R(cda...tor)
Treeblank.pngTreetree.png@code
cs1 … 1FS
Treeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.1.11.10282
Treeblank.pngTreetree.png@codeSystemName
st1 … 1FParticipationSignature
Treeblank.pngTreetree.png@displayName
st1 … 1Fsigned
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC)
Treetree.pnghl7:assignedEntity
1 … 1RContains 2.16.756.5.30.1.1.10.9.12 Assigned Entity Compilation with id (DYNAMIC)(cda...tor)

CDA Authenticator

Id2.16.756.5.30.1.1.10.2.6Effective Date valid from 2017‑03‑28 21:11:46

There are versions of templates with this id:
  • cdach_header_Authenticator as of 2017‑03‑28 21:11:46
  • CDA_CH_AUTE as of 2009‑01‑27
StatusKyellow.png DraftVersion Label2017
Namecdach_header_AuthenticatorDisplay NameAuthenticator
Description
Information about an authenticator of a CDA document. An authenticator MUST be a person. All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST use this template by either reference or specialisation.
ClassificationCDA Header Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 3 templates, Uses 1 template
Used by as NameVersion
2.16.756.5.30.1.1.10.9.36IncludeKyellow.png CDA-CH v2.0 Header Template Compilation (2017)2017‑11‑09 11:38:30
2.16.756.5.30.1.1.10.1.12Link.pngKyellow.png CDA-CH v2.0 - nonXMLBody (2017)2017‑11‑09 11:30:07
2.16.756.5.30.1.1.10.1.9Link.pngKyellow.png CDA-CH v2.0 - structuredBody (2017)2017‑03‑28 23:43:12
Uses as NameVersion
2.16.756.5.30.1.1.10.9.12ContainmentKyellow.png Assigned Entity Compilation with id (2017)DYNAMIC
RelationshipVersion: template 2.16.756.5.30.1.1.10.2.6 (2009‑01‑27)
Specialization: template 2.16.840.1.113883.10.12.107 (2005‑09‑07)
Example
Example
<authenticator>
  <time value="20071205"/>  <signatureCode code="S"/>  <assignedEntity>
    <id extension="7604444444444" root="2.51.1.3"/>    <assignedPerson>
      <name>
        <prefix>Dr. med.</prefix>        <given>Freddy</given>        <family>Fango</family>        <suffix>Ärztlicher Leiter</suffix>      </name>
    </assignedPerson>
  </assignedEntity>
</authenticator>
ItemDTCardConfDescriptionLabel
hl7:authenticator
0 … *Information about an authenticator of a CDA document. An authenticator MUST be a person.(cda...tor)
Treetree.pnghl7:time
TS.CH.TZ1 … 1RTimestamp of the signature.(cda...tor)
Treetree.pnghl7:signatureCode
CS1 … 1R(cda...tor)
Treeblank.pngTreetree.png@code
cs1 … 1FS
Treeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.1.11.10282
Treeblank.pngTreetree.png@codeSystemName
st1 … 1FParticipationSignature
Treeblank.pngTreetree.png@displayName
st1 … 1Fsigned
 CONF
The value of @code shall be drawn from value set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC)
Treetree.pnghl7:assignedEntity
1 … 1RContains 2.16.756.5.30.1.1.10.9.12 Assigned Entity Compilation with id (DYNAMIC)(cda...tor)

CDA Ordering Provider

Id1.3.6.1.4.1.19376.1.3.3.1.6
ref
(from repository: XDLAB-)
Effective Date valid from 2008‑08‑08
StatusKgreen.png ActiveVersion Label2017
NameOrderingProviderDisplay NameOrdering Provider
Description
ClinicalDocument/participant(s) MAY be present. When present, this element SHALL be in accordance with the HL7 CDA R2 standard with a time element and further constrained by this specification to require the presence of name, addr and telecom.
In particular, when the ordering provider of the order (or group of orders) fulfilled by this laboratory report is present in the CDA, it SHALL be documented as a participant with the attribute typeCode valued “REF” (referrer). Additionally, the ordering provider SHALL have the following:
  • <templateId root="1.3.6.1.4.1.19376.1.3.3.1.6"/> - The templateId element identifies this participant as an ordering physician. The templateId SHALL have root="1.3.6.1.4.1.19376.1.3.3.1.6".

See also IHE PCC Wiki Content
ContextParent nodes of template element with id 1.3.6.1.4.1.19376.1.3.3.1.6
ClassificationCDA Header Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 2 templates, Uses 0 templates
Used by as NameVersion
2.16.756.5.30.1.127.10.1.3IncludeKyellow.png Laborbefund Transplantationsprozesss2017‑08‑14
2.16.756.5.30.1.127.10.1.3IncludeKvalidblue.png Laborbefund Transplantationsprozesss2016‑07‑02
RelationshipSpecialization: template 2.16.840.1.113883.10.12.108 (2005‑09‑07)
Example
Ordering Provider Example
<participant typeCode="REF">
  <time value="20080123211000.007-0500"/>  <associatedEntity>
    <id extension="1" root="1.3.6.1.4.1.19376.1.3.4"/>    <addr>
      <streetAddressLine>21 North Ave</streetAddressLine>      <city>Burlington</city>    </addr>
    <telecom value="tel:(999)555-1212" use="DIR"/>    <associatedPerson>
      <name>
        <given>Good</given>        <family>Orderer</family>      </name>
    </associatedPerson>
    <scopingOrganization>
      <id extension="rm83747" root="1.3.6.1.4.1.19376.1.3.4"/>      <name>Hospital</name>      <telecom nullFlavor="UNK"/>      <addr nullFlavor="UNK"/>    </scopingOrganization>
  </associatedEntity>
</participant>
Example
Referral Ordering Physician Example
<participant typeCode="REF">
  <templateId root="1.3.6.1.4.1.19376.1.3.3.1.6"/>  <time>
    <low value="20071104055700.0000-0500"/>    <high value="20071104131600.0000-0500"/>  </time>
  <associatedEntity classCode="PROV">
    <id extension="90573" root="1.3.6.1.4.1.19376.1.3.4"/>    <addr nullFlavor="UNK"/>    <telecom nullFlavor="UNK"/>    <associatedPerson>
      <name>
        <family>Patel</family>        <given>Kiran</given>        <prefix>Dr.</prefix>      </name>
    </associatedPerson>
    <scopingOrganization>
      <id extension="rm83747" root="1.3.6.1.4.1.19376.1.3.4"/>      <name>Hospital</name>      <telecom nullFlavor="UNK"/>      <addr nullFlavor="UNK"/>    </scopingOrganization>
  </associatedEntity>
</participant>
ItemDTCardConfDescriptionLabel
hl7:participant
Referral Ordering Physician(Ord…der)
Treetree.png@typeCode
cs1 … 1FREF
Treetree.pnghl7:templateId
II1 … 1(Ord…der)
Treeblank.pngTreetree.png@root
uid1 … 1F1.3.6.1.4.1.19376.1.3.3.1.6
Treetree.pnghl7:time
IVL_TS1 … 1RThis element represents the date and time the order was placed. Time MAY be present.(Ord…der)
Treetree.pnghl7:associated​Entity
1 … 1(Ord…der)
Treeblank.pngTreetree.pnghl7:addr
AD1 … *RThe address of this person (referral ordering physician) SHALL be present.(Ord…der)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT1 … *RThe telecom of this person (referral ordering physician) SHALL be present.(Ord…der)
 Schematron assertroleKred.png error 
 testnot(hl7:assigned​Person) or hl7:assigned​Person/hl7:name 
 MessageThe <name> sub-element SHALL be present when <assignedPerson> present. 
Treeblank.pngTreetree.pnghl7:associated​Person
0 … 1R(Ord…der)
Treeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1(Ord…der)

CDA Order reference

Id2.16.756.5.30.1.1.10.2.16Effective Date valid from 2017‑03‑09 16:30:05

There are versions of templates with this id:
  • cdach_header_OrderReference as of 2017‑03‑09 16:30:05
  • CDA_CH_ORDR as of 2016‑05‑18
StatusKyellow.png DraftVersion Label2017
Namecdach_header_OrderReferenceDisplay NameOrder Reference - inFulfillmentOf
Description
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. All CDA-CH V2 derivatives, i.e. Swiss exchange formats MUST reference this template.
ContextParent nodes of template element with id 2.16.756.5.30.1.1.10.2.16
ClassificationCDA Header Level Template
Open/ClosedClosed (only defined elements are allowed)
Used by / Uses
Used by 0 transactions and 3 templates, Uses 0 templates
Used by as NameVersion
2.16.756.5.30.1.1.10.9.36IncludeKyellow.png CDA-CH v2.0 Header Template Compilation (2017)2017‑11‑09 11:38:30
2.16.756.5.30.1.1.10.1.12Link.pngKyellow.png CDA-CH v2.0 - nonXMLBody (2017)2017‑11‑09 11:30:07
2.16.756.5.30.1.1.10.1.9Link.pngKyellow.png CDA-CH v2.0 - structuredBody (2017)2017‑03‑28 23:43:12
RelationshipSpecialization: template 2.16.840.1.113883.10.12.109 (2005‑09‑07)
Version: template 2.16.756.5.30.1.1.10.2.16 (2016‑05‑18)
Example
Order reference on a CDA-CH V2 (2017) document
<inFulfillmentOf>
  <templateId root="2.16.756.5.30.1.1.10.2.16"/>  <order>
    <id root="9F44AE66-D70B-46DA-89AD-82A51C7A11C6"/>  </order>
</inFulfillmentOf>
Example
Order reference to an order created by an ERP system
<inFulfillmentOf>
  <templateId root="2.16.756.5.30.1.1.10.2.16"/>  <order>
    <id root="2.999" extension="AU-20170021987"/>  </order>
</inFulfillmentOf>
ItemDTCardConfDescriptionLabel
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...nce)
Treetree.pnghl7:templateId
II1 … 1M(cda...nce)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.1.10.2.16
Treetree.pnghl7:order
1 … 1R(cda...nce)
Treeblank.pngTreetree.pnghl7:id
II1 … *ROrder number.(cda...nce)
Treeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 MUST be declared when @root is an OID and it MUST then contain the same value as the order itself (order id).
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1REither the same GUID (order id) or the same OID (order issuing system) as the order itself.

CDA relatedDocument

Keine Versionen mit Status draft, active, review oder pending.

CDA Authorization

Keine Versionen mit Status draft, active, review oder pending.

CDA componentOf

Keine Versionen mit Status draft, active, review oder pending.

CDA Body

Der CDA Body wird gemäss [IHE PCC TF-2][15] und [IHE LAB TF-3][16] strukturiert, wobei gemäss CDA-CH Regel <CH-BDY1> die Reihenfolge der Einträge verbindlich ist. Sollte für die für Menschen lesbare Darstellung eine andere Reihenfolge gewünscht sein, kann das durch Anwendung entsprechender Stylesheets durch den Anwender in seiner eigenen Ver-antwortung umgesetzt werden. Sämtliche Angaben erfolgen codiert im CDA Body Level 3. Der für CDA Body Level 1 geforderte Freitext SOLL nach Möglichkeit automatisch aus den strukturierten Informationen generiert 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 .

Blutgruppe

Modell

Lrtp Blutgruppe.png
Lrtp Blutgruppe.png

[Abbildung 8]Modell Blood group – Blutgruppe

Section Level Template

Id2.16.756.5.30.1.127.10.3.11Effective Date valid from 2016‑07‑02
StatusKyellow.png DraftVersion Label
NameBlutgruppesectionDisplay NameBlutgruppe Section
Description
(de-CH) Dieses Element enthält die Daten zur Blutgruppe.
ContextParent nodes of template element with id 2.16.756.5.30.1.127.10.3.11
ClassificationCDA Section Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 2 templates, Uses 1 template
Used by as NameVersion
2.16.756.5.30.1.127.10.1.3ContainmentKyellow.png Laborbefund Transplantationsprozesss2017‑08‑14
2.16.756.5.30.1.127.10.1.3ContainmentKvalidblue.png Laborbefund Transplantationsprozesss2016‑07‑02
Uses as NameVersion
2.16.756.5.30.1.127.10.4.29ContainmentKyellow.png BlutgruppeDYNAMIC
RelationshipSpecialization: template 2.16.840.1.113883.10.12.201 (2005‑09‑07)
Adaptation: template 1.3.6.1.4.1.19376.1.3.3.2.1 (2008‑08‑08)
Example
Example
<section>
  <templateId root="2.16.756.5.30.1.127.10.3.11"/>  <templateId root="2.16.756.5.30.1.1.1.1.3.4.1" extension="CDA-CH.LRTP.Body.StudiesSummaryL2"/>  <code code="30954-2" displayName="Relevant diagnostic tests/laboratory data" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <title>Blutgruppe</title>  <text>
    <content ID="BG00001">Blood group A Rh(D) positive</content>    <content>Date and time: 24.08.2013</content>    <table>
      <tbody>
        <tr>
          <th>Comments:</th>        </tr>
        <tr>
          <td>
            <list>
              <item ID="BG00002"> Lorem ipsum dolor sit amet, consectetur adipiscing elit </item>              <item ID="BG00003">
                 Etiam libero turpis                <br/>                 bibendum nec dolor et                <br/>                 vehicula eleifend ante               </item>
            </list>
          </td>
        </tr>
      </tbody>
    </table>
  </text>
  <entry>
    <!-- ... -->
  </entry>
</section>
ItemDTCardConfDescriptionLabel
hl7:section
(Blu…ion)
Treetree.pnghl7:templateId
II1 … 1M(Blu…ion)
Treeblank.pngTreetree.png@root
1 … 1F2.16.756.5.30.1.127.10.3.11
Treetree.pnghl7:templateId
II1 … 1M(Blu…ion)
Treeblank.pngTreetree.png@root
1 … 1F2.16.756.5.30.1.1.1.1.3.4.1
Treeblank.pngTreetree.png@extension
1 … 1FCDA-CH.LRTP.Body.StudiesSummaryL2
Treetree.pnghl7:code
CE1 … 1M(Blu…ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F30954-2
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1
Treetree.pnghl7:title
ST1 … 1M(Blu…ion)
 CONF
element content shall be "Blutgruppe"
-or-
element content shall be "Groupe sanguin"
-or-
element content shall be "Gruppo sanguigno"
-or-
element content shall be "Blood Group"
Treetree.pnghl7:text
SD.TEXT1 … 1M(Blu…ion)
Treetree.pnghl7:entry
1 … *RContains 2.16.756.5.30.1.127.10.4.29 Blutgruppe (DYNAMIC)(Blu…ion)
Treeblank.png where [hl7:observation [hl7:code [(@code='882-1' and @codeSystem='2.16.840.1.113883.6.1')]]]
Treeblank.pngTreetree.png@typeCode
1 … 1FDRIV
Treeblank.pngTreetree.png@context​Conduction​Ind
bl0 … 1 

Spezifikation CDA Body Level 3 – Blutgruppe Entry

Id2.16.756.5.30.1.127.10.4.29Effective Date valid from 2016‑07‑02
StatusKyellow.png DraftVersion Label
NameBlutgruppeDisplay NameBlutgruppe
Description
(de-CH) Blutgruppe in strukturierter Form
ContextParent nodes of template element with id 2.16.756.5.30.1.127.10.4.29
ClassificationCDA Entry Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 3 templates, Uses 1 template
Used by as NameVersion
2.16.756.5.30.1.127.10.3.11ContainmentKyellow.png Blutgruppe Section2016‑07‑02
2.16.756.5.30.1.127.10.1.3Link.pngKyellow.png Laborbefund Transplantationsprozesss2017‑08‑14
2.16.756.5.30.1.127.10.1.3Link.pngKvalidblue.png Laborbefund Transplantationsprozesss2016‑07‑02
Uses as NameVersion
1.3.6.1.4.1.19376.1.5.3.1.4.2ContainmentKgreen.png IHE Comment Entry (2014)DYNAMIC
RelationshipSpecialization: template 2.16.840.1.113883.10.12.303 (2005‑09‑07)
Adaptation: template 1.3.6.1.4.1.19376.1.5.3.1.4.13 (DYNAMIC)
Adaptation: template 1.3.6.1.4.1.19376.1.5.3.1.4.13.6 (DYNAMIC)
Example
Example
<observation classCode="OBS" moodCode="EVN">
  <templateId root="2.16.756.5.30.1.127.10.4.29"/>  <templateId root="2.16.756.5.30.1.1.1.1.3.4.1" extension="CDA-CH.LRTP.Body.StudiesSummaryL3.Bloodgroup"/>  <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>  <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13.6"/>  <templateId root="2.16.840.1.113883.10.20.1.31"/>  <id root="2.16.756.5.30.1.109.3.1" extension="6E9DD4C7-7401-46D8-A9CC-02421F750569"/>  <code code="882-1" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="ABO+RH GROUP"/>  <text>
    <reference value="BG00001"/>  </text>
  <statusCode code="completed"/>  <effectiveTime value="20130824"/>  <value xsi:type="CE" code="278149003" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Blood group A Rh(D) positive"/>  <entryRelationship typeCode="SUBJ" inversionInd="true">
    <act classCode="ACT" moodCode="EVN">
      <templateId root="2.16.840.1.113883.10.20.1.40"/>      <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.2"/>      <code code="48767-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Annotation comment"/>      <text>
        <reference value="BG00002"/>      </text>
      <statusCode code="completed"/>    </act>
  </entryRelationship>
</observation>
ItemDTCardConfDescriptionLabel
hl7:observation
(Blu…ppe)
Treetree.png@classCode
1 … 1FOBS
Treetree.png@moodCode
1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1M(Blu…ppe)
Treeblank.pngTreetree.png@root
1 … 1F2.16.756.5.30.1.127.10.4.29
Treetree.pnghl7:templateId
II1 … 1M(Blu…ppe)
Treeblank.pngTreetree.png@root
1 … 1F2.16.756.5.30.1.1.1.1.3.4.1
Treeblank.pngTreetree.png@extension
1 … 1FCDA-CH.LRTP.Body.StudiesSummaryL3.Bloodgroup
Treetree.pnghl7:templateId
II1 … 1M(Blu…ppe)
Treeblank.pngTreetree.png@root
1 … 1F1.3.6.1.4.1.19376.1.5.3.1.4.13
Treetree.pnghl7:templateId
II1 … 1M(Blu…ppe)
Treeblank.pngTreetree.png@root
1 … 1F1.3.6.1.4.1.19376.1.5.3.1.4.13.6
Treetree.pnghl7:templateId
II1 … 1M(Blu…ppe)
Treeblank.pngTreetree.png@root
1 … 1F2.16.840.1.113883.10.20.1.31
Treetree.pnghl7:id
II1 … *M(Blu…ppe)
Treetree.pnghl7:code
CD1 … 1M(Blu…ppe)
Treeblank.pngTreetree.png@code
CONF1 … 1F882-1
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1
 Example<code code="882-1" displayName="ABO+RH GROUP" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
Treetree.pnghl7:text
ED1 … 1M
(de-CH) Die Referenz auf den entsprechenden Text im menschlich lesbaren Teil muss mittels Referenz auf content[@ID] angegeben werden: reference[@value='#xxx'].
(Blu…ppe)
Treeblank.pngTreetree.pnghl7:reference
TEL1 … 1M(Blu…ppe)
Treeblank.pngTreeblank.pngTreetree.png@value
1 … 1R
(de-CH) #bloodgr-{generierteID}, z.B.: #cr-1
Treetree.pnghl7:statusCode
CS1 … 1M(Blu…ppe)
Treeblank.pngTreetree.png@code
CONF1 … 1Fcompleted
Treetree.pnghl7:effectiveTime
TS.CH.TZ0 … 1R
(de-CH) Datum des Blutgruppentests
(Blu…ppe)
Treetree.pnghl7:value
CE1 … 1
(de-CH) Bezeichnung der Blutgruppe
(Blu…ppe)
 CONF
The value of @code shall be drawn from value set 1.3.6.1.4.1.12559.11.10.1.3.1.42.20 epSOSBloodGroup (DYNAMIC)
Treetree.pnghl7:author
1 … 1M(Blu…ppe)
Treeblank.pngTreetree.png@typeCode
cs0 … 1FAUT
Treeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
Treeblank.pngTreetree.pnghl7:time
TS.CH.TZ0 … 1R
(de-CH) Datum der Eintragung
(Blu…ppe)
Treeblank.pngTreetree.pnghl7:assignedAuthor
1 … 1R(Blu…ppe)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1M(Blu…ppe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
1 … 1F1.3.88
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
1 … 1R
(de-CH) GLN der eintragenden Person
Treetree.pnghl7:entryRelationship
0 … 1R
(de-CH) Allfällige Bemerkungen

Contains 1.3.6.1.4.1.19376.1.5.3.1.4.2 IHE Comment Entry (DYNAMIC)
(Blu…ppe)
Treeblank.png where [hl7:act [hl7:code [(@code='48767-8' and @codeSystem='2.16.840.1.113883.6.1')]]]
Treeblank.pngTreetree.png@typeCode
1 … 1FCOMP
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 .

Vitalzeichen

Modell

Lrtp Vitalzeichen.png
Lrtp Vitalzeichen.png

[Abbildung 9]Modell Coded Vital Signs – Vitalzeichen

Section Level Template

Id2.16.756.5.30.1.127.10.3.13Effective Date valid from 2017‑08‑14
StatusKyellow.png DraftVersion Label2017
NameCodedVitalSignsSectionlrtpDisplay NameCoded Vital Signs Section (lrtp)
Description
see languages de-CH, fr-CH or it-CH for description
ClassificationCDA Section Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 1 template, Uses 1 template
Used by as NameVersion
2.16.756.5.30.1.127.10.1.3ContainmentKyellow.png Laborbefund Transplantationsprozesss2017‑08‑14
Uses as NameVersion
2.16.756.5.30.1.127.10.4.36ContainmentKyellow.png Vital Signs Organizer Entry (lrtp) (2017)DYNAMIC
RelationshipSpecialization: template 2.16.756.5.30.1.1.10.3.4 (2017‑03‑28 22:53:28)
Specialization: template 2.16.840.1.113883.10.12.201 (2005‑09‑07)
Example
Example
<component>
  <section>
    <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.25"/>    <templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2"/>    <id root="2.16.756.5.30.1.1.1.1.3.1.1" extension="0D42D3DB-67BB-43AD-99DE-10D248040821"/>    <code code="8716-3" displayName="VITAL SIGNS" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>    <text>
      <content ID="o1"> Vitalzeichen: - Grösse: 178 cm </content>    </text>
    <entry>
      <!-- .. -->
    </entry>
  </section>
</component>
ItemDTCardConfDescriptionLabel
hl7:section
(Cod…rtp)
Treetree.pnghl7:templateId
II1 … 1M(Cod…rtp)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.10.20.1.16
Treetree.pnghl7:templateId
II1 … 1R(Cod…rtp)
Treeblank.pngTreetree.png@root
uid1 … 1F1.3.6.1.4.1.19376.1.5.3.1.3.25
Treetree.pnghl7:templateId
II1 … 1R(Cod…rtp)
Treeblank.pngTreetree.png@root
uid1 … 1F1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2
Treetree.pnghl7:code
CE1 … 1R(Cod…rtp)
Treeblank.pngTreetree.png@code
CONF1 … 1F8716-3
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1
Treeblank.pngTreetree.png@codeSystemName
1 … 1FLOINC
Treeblank.pngTreetree.png@displayName
1 … 1FVITAL SIGNS
Treetree.pnghl7:title
ST0 … 1(Cod…rtp)
 CONF
element content shall be "Vitalzeichen"
-or-
element content shall be "Vital Signs"
-or-
element content shall be "Signes vitaux"
-or-
element content shall be "Segni vitali"
Treetree.pnghl7:text
SD.TEXT1 … 1M(Cod…rtp)
Treetree.pnghl7:entry
0 … *Contains 2.16.756.5.30.1.127.10.4.36 Vital Signs Organizer Entry (lrtp) (DYNAMIC)(Cod…rtp)
Treeblank.png where [hl7:organizer [hl7:code [(@code='46680005' and @codeSystem='2.16.840.1.113883.6.96') or @nullFlavor]]]

Spezifikation CDA Body Level 3 – Vital Signs Organizer Entry

Id2.16.756.5.30.1.127.10.4.36Effective Date valid from 2017‑08‑14
StatusKyellow.png DraftVersion Label2017
NameVitalSignsOrganizerEntryDisplay NameVital Signs Organizer Entry (lrtp)
Descriptionsee languages de-CH, fr-CH or it-CH for description
ClassificationCDA Entry Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 2 templates, Uses 1 template
Used by as NameVersion
2.16.756.5.30.1.127.10.3.13ContainmentKyellow.png Coded Vital Signs Section (lrtp) (2017)2017‑08‑14
2.16.756.5.30.1.127.10.1.3Link.pngKyellow.png Laborbefund Transplantationsprozesss2017‑08‑14
Uses as NameVersion
2.16.756.5.30.1.127.10.4.37ContainmentKyellow.png Vital Signs Observation (lrtp) (2017)DYNAMIC
RelationshipSpecialization: template 2.16.756.5.30.1.1.10.4.20 (2017‑03‑28 22:50:52)
Specialization: template 2.16.840.1.113883.10.12.305 (2005‑09‑07)
ItemDTCardConfDescriptionLabel
hl7:organizer
(Vit…try)
Treetree.png@classCode
cs1 … 1FCLUSTER
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1M(Vit…try)
Treeblank.pngTreetree.png@root
uid1 … 1F1.3.6.1.4.1.19376.1.5.3.1.4.13.1
Treetree.pnghl7:templateId
II1 … 1M(Vit…try)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.10.20.1.32
Treetree.pnghl7:templateId
II1 … 1M(Vit…try)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.10.20.1.35
Treetree.pnghl7:id
II0 … *(Vit…try)
Treetree.pnghl7:code
CE1 … 1R(Vit…try)
Treeblank.pngTreetree.png@code
CONF1 … 1F46680005
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.96 (SNOMED Clinical Terms)
Treeblank.pngTreetree.png@codeSystemName
1 … 1FSNOMED CT
Treeblank.pngTreetree.png@displayName
1 … 1FVITAL SIGNS
Treetree.pnghl7:statusCode
CS1 … 1M(Vit…try)
Treeblank.pngTreetree.png@code
CONF1 … 1Fcompleted
Treetree.pnghl7:effectiveTime
IVL_TS.CH.TZ1 … 1R(Vit…try)
Treetree.pnghl7:component
0 … *Contains 2.16.756.5.30.1.127.10.4.37 Vital Signs Observation (lrtp) (DYNAMIC)(Vit…try)
Treeblank.png where [hl7:observation [hl7:code [concat(@code,@codeSystem)=doc('include/voc-2.16.756.5.30.1.1.11.5-DYNAMIC.xml')//valueSet [1]/conceptList/concept/concat(@code,@codeSystem) or @nullFlavor]]]
Treeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreetree.png@context​Conduction​Ind
bl0 … 1 
Treeblank.pngTreetree.pnghl7:sequenceNumber
INT0 … 1(Vit…try)
Treeblank.pngTreetree.pnghl7:seperatableInd
BL0 … 1(Vit…try)
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 .

Laborbefund

Section Level Template

Id2.16.756.5.30.1.127.10.3.12Effective Date valid from 2016‑07‑02
StatusKyellow.png DraftVersion Label
NameLaborbefundsectionlrtpDisplay NameLaborbefund Section (lrtp)
Description
Laboratory Specialty Section
ContextParent nodes of template element with id 2.16.756.5.30.1.127.10.3.12
ClassificationCDA Section Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 2 templates, Uses 1 template
Used by as NameVersion
2.16.756.5.30.1.127.10.1.3ContainmentKyellow.png Laborbefund Transplantationsprozesss2017‑08‑14
2.16.756.5.30.1.127.10.1.3ContainmentKvalidblue.png Laborbefund Transplantationsprozesss2016‑07‑02
Uses as NameVersion
2.16.756.5.30.1.127.10.4.30ContainmentKyellow.png Befundgruppe (lrtp)DYNAMIC
RelationshipSpecialization: template 2.16.840.1.113883.10.12.201 (2005‑09‑07)
Adaptation: template 1.3.6.1.4.1.19376.1.3.3.2.1 (2008‑08‑08)
Example
Example
<section>
  <templateId root="2.16.756.5.30.1.127.10.3.12"/>  <!-- IHE XD-LAB: Laboratory Speciality Section -->
  <templateId root="1.3.6.1.4.1.19376.1.3.3.2.1"/>  <code code="18724-5" codeSystem="2.16.840.1.113883.6.1" displayName="HLA studies"/>  <title>Laborbefund</title>  <text>
    Befundgruppe: 18724-5 - HLA studies    <br/>     Zeitpunkt der Feststellungen: 15.01.2014 10:37    <br/>    <br/>     HLA Typisierung:     <table>
      <tbody>
        <tr>
          <th>Beobachtung</th>          <th>Resultat</th>          <th>Interpretation</th>          <th>Code</th>          <th>Codesystem</th>          <th>Autor</th>          <th>Kommentar</th>        </tr>
        <tr>
          <td>A2 HLA-Antigene</td>          <td>
            <content ID="l21">+</content>          </td>
          <td>N</td>          <td>A2</td>          <td>HLA</td>          <td>7608888888888</td>          <td/>        </tr>
      </tbody>
    </table>
  </text>
  <entry typeCode="DRIV">
    <!-- IHE XD-LAB: Laboratory Report Data Processing Entry -->
    <templateId root="1.3.6.1.4.1.19376.1.3.1"/>    <!-- .. -->
  </entry>
</section>
ItemDTCardConfDescriptionLabel
hl7:section
(Lab…rtp)
Treetree.pnghl7:templateId
II1 … 1M(Lab…rtp)
Treeblank.pngTreetree.png@root
1 … 1F2.16.756.5.30.1.127.10.3.12
Treetree.pnghl7:templateId
II1 … 1M(Lab…rtp)
Treeblank.pngTreetree.png@root
1 … 1F1.3.6.1.4.1.19376.1.3.3.2.1
Treetree.pnghl7:id
II0 … *R(Lab…rtp)
Treetree.pnghl7:code
CE1 … 1M
(de-CH) Es MUSS ein Code aus der Befundgruppen-Klassifikation im zugehörigen Value Set verwendet werden.
(Lab…rtp)
 CONF
The value of @code shall be drawn from value set 2.16.756.5.30.1.129.1.1.7 Laborbefundgruppe (DYNAMIC)
Treetree.pnghl7:title
ST1 … 1M(Lab…rtp)
 CONF
element content shall be "Laborbefund"
-or-
element content shall be "Rapport de laboratoire"
-or-
element content shall be "Rapporto di laboratorio"
-or-
element content shall be "Laboratory Specialty Section"
Treetree.pnghl7:text
SD.TEXT1 … 1M(Lab…rtp)
Treetree.pnghl7:entry
1 … *RContains 2.16.756.5.30.1.127.10.4.30 Befundgruppe (lrtp) (DYNAMIC)(Lab…rtp)
Treeblank.pngTreetree.png@typeCode
1 … 1FDRIV
Treeblank.pngTreetree.png@context​Conduction​Ind
bl0 … 1 

Befundgruppe

Id2.16.756.5.30.1.127.10.4.30Effective Date valid from 2016‑07‑20
StatusKyellow.png DraftVersion Label
NameBefundgruppelrtpDisplay NameBefundgruppe (lrtp)
Description
Laboratory Report Data Processing Entry
ClassificationCDA Entry Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 3 templates, Uses 1 template
Used by as NameVersion
2.16.756.5.30.1.127.10.3.12ContainmentKyellow.png Laborbefund Section (lrtp)2016‑07‑02
2.16.756.5.30.1.127.10.1.3Link.pngKyellow.png Laborbefund Transplantationsprozesss2017‑08‑14
2.16.756.5.30.1.127.10.1.3Link.pngKvalidblue.png Laborbefund Transplantationsprozesss2016‑07‑02
Uses as NameVersion
2.16.756.5.30.1.127.10.4.31ContainmentKyellow.png Resultatgruppe (lrtp)DYNAMIC
RelationshipSpecialization: template 2.16.840.1.113883.10.12.301 (2005‑09‑07)
Specialization: template 1.3.6.1.4.1.19376.1.3.1 (2008‑08‑08)
Adaptation: template 2.16.756.5.30.1.1.10.4.4 (2016‑05‑27)
Example
Example
<templateId root="1.3.6.1.4.1.19376.1.3.1"/><act classCode="ACT" moodCode="EVN">
  <templateId root="2.16.756.5.30.1.127.10.4.30"/>  <code code="18724-5" codeSystem="2.16.840.1.113883.6.1" displayName="HLA studies"/>  <statusCode code="completed"/>  <entryRelationship typeCode="COMP">
    <!-- ... -->
  </entryRelationship>
</act>
ItemDTCardConfDescriptionLabel
hl7:templateId
II1 … 1M(Bef…rtp)
Treetree.png@root
1 … 1F1.3.6.1.4.1.19376.1.3.1
hl7:act
(Bef…rtp)
Treetree.png@classCode
1 … 1FACT
Treetree.png@moodCode
1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1M(Bef…rtp)
Treeblank.pngTreetree.png@root
1 … 1F2.16.756.5.30.1.127.10.4.30
Treetree.pnghl7:code
CE1 … 1M
(de-CH) Es MUSS ein Code aus der Befundgruppen-Klassifikation im zugehörigen Value Set verwendet werden.
(Bef…rtp)
 CONF
The value of @code shall be drawn from value set 2.16.756.5.30.1.129.1.1.7 Laborbefundgruppe (DYNAMIC)
Treetree.pnghl7:statusCode
CS1 … 1M
(de-CH) Die gemäss IHE XD-LAB zugelassenen Codes „active“ und „aborted“ sind für Laborbefunde im Transplantationsprozess in der Schweiz nicht zugelassen. Die Meldung soll erst dann erfolgen, wenn die Untersuchung abgeschlossen und endgültig ist.
(Bef…rtp)
Treeblank.pngTreetree.png@code
CONF1 … 1Fcompleted
Treetree.pnghl7:entryRelationship
0 … *R
(de-CH) Container der eigentlichen Laborresultate

Contains 2.16.756.5.30.1.127.10.4.31 Resultatgruppe (lrtp) (DYNAMIC)
(Bef…rtp)
Treeblank.pngTreetree.png@typeCode
1 … 1FCOMP

Probenentnahme

Id2.16.756.5.30.1.127.10.4.34Effective Date valid from 2017‑08‑01
StatusKyellow.png DraftVersion Label
NameSpecimenCollectionDisplay NameProbenentnahme
Description
(de-CH) Eine Probenuntersuchung KANN Angaben zur Probe enthalten. Laborbefunde in der Schweiz im Transplantationsbereich MÜSSEN eine Angabe zum Entnahmedatum enthalten.
ContextParent nodes of template element with id 2.16.756.5.30.1.127.10.4.34
ClassificationCDA Entry Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 5 templates, Uses 2 templates
Used by as NameVersion
2.16.756.5.30.1.127.10.4.31ContainmentKyellow.png Resultatgruppe (lrtp)2016‑07‑20
2.16.756.5.30.1.127.10.4.30Link.pngKyellow.png Befundgruppe (lrtp)2016‑07‑20
2.16.756.5.30.1.127.10.3.12Link.pngKyellow.png Laborbefund Section (lrtp)2016‑07‑02
2.16.756.5.30.1.127.10.1.3Link.pngKyellow.png Laborbefund Transplantationsprozesss2017‑08‑14
2.16.756.5.30.1.127.10.1.3Link.pngKvalidblue.png Laborbefund Transplantationsprozesss2016‑07‑02
Uses as NameVersion
2.16.840.1.113883.10.12.313ContainmentKgreen.png CDA PlayingEntityDYNAMIC
1.3.6.1.4.1.19376.1.3.1.3ContainmentKgreen.png Specimen Received (2017)DYNAMIC
RelationshipSpecialization: template 1.3.6.1.4.1.19376.1.3.1.2 (2008‑08‑08)
Specialization: template 2.16.840.1.113883.10.12.301 (2005‑09‑07)
ItemDTCardConfDescriptionLabel
hl7:procedure
(Spe…ion)
Treetree.png@classCode
cs1 … 1FPROC
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1M(Spe…ion)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.756.5.30.1.127.10.4.34
Treetree.pnghl7:templateId
II1 … 1M(Spe…ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.3.6.1.4.1.19376.1.3.1.2
Treetree.pnghl7:code
CD0 … 1RSpecimen Collection(Spe…ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F33882-2
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1
Treetree.pnghl7:effectiveTime
IVL_TS1 … 1RDate and time of specimen collection(Spe…ion)
Treetree.pnghl7:target​Site​Code
0 … 1(Spe…ion)
Treetree.pnghl7:performer
0 … 1(Spe…ion)
Treetree.pnghl7:participant
1 … 1R
(de-CH) Laborinterne Probennummer. Für SOAS ist dies nicht relevant. Das id element kann mit einem nullFlavor versendet werden.
(Spe…ion)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FPRD
 Example<participant typeCode="PRD">
  <participantRole classCode="SPEC">
    <id nullFlavor="NA"/>    <playingEntity>
      <code code="LOINC" codeSystem="2.16.756.5.30.2.1.1.10"/>    </playingEntity>
  </participantRole>
</participant>
Treeblank.pngTreetree.pnghl7:participantRole
1 … 1M(Spe…ion)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FSPEC
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1R(Spe…ion)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:playingEntity
1 … 1RContains 2.16.840.1.113883.10.12.313 CDA PlayingEntity (DYNAMIC)(Spe…ion)
Treetree.pnghl7:entryRelationship
NP
(de-CH) Wird in SOAS nicht verwendet

Contains 1.3.6.1.4.1.19376.1.3.1.3 Specimen Received (DYNAMIC)
(Spe…ion)
Treeblank.png where [hl7:act [hl7:code [(@code='SPRECEIVE' and @codeSystem='1.3.5.1.4.1.19376.1.5.3.2') or @nullFlavor]]]

Resultatgruppe

Id2.16.756.5.30.1.127.10.4.31Effective Date valid from 2016‑07‑20
StatusKyellow.png DraftVersion Label
NameResultatgruppelrtpDisplay NameResultatgruppe (lrtp)
Description
Laboratory Battery Organizer
ContextParent nodes of template element with id 2.16.756.5.30.1.127.10.4.31
ClassificationCDA Entry Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 4 templates, Uses 3 templates
Used by as NameVersion
2.16.756.5.30.1.127.10.4.30ContainmentKyellow.png Befundgruppe (lrtp)2016‑07‑20
2.16.756.5.30.1.127.10.3.12Link.pngKyellow.png Laborbefund Section (lrtp)2016‑07‑02
2.16.756.5.30.1.127.10.1.3Link.pngKyellow.png Laborbefund Transplantationsprozesss2017‑08‑14
2.16.756.5.30.1.127.10.1.3Link.pngKvalidblue.png Laborbefund Transplantationsprozesss2016‑07‑02
Uses as NameVersion
1.3.6.1.4.1.19376.1.3.10.9.17IncludeKgreen.png Author with Name, Addr, Telecom (2017)DYNAMIC
2.16.756.5.30.1.127.10.4.32ContainmentKyellow.png Laborresultat (lrtp)DYNAMIC
2.16.756.5.30.1.127.10.4.34ContainmentKyellow.png ProbenentnahmeDYNAMIC
RelationshipSpecialization: template 2.16.840.1.113883.10.12.305 (2005‑09‑07)
Specialization: template 1.3.6.1.4.1.19376.1.3.1.4 (2008‑08‑08)
Example
Example
<organizer classCode="BATTERY" moodCode="EVN">
  <templateId root="2.16.756.5.30.1.127.10.4.31"/>  <templateId root="1.3.6.1.4.1.19376.1.3.1.4"/>  <statusCode code="completed"/>  <author typeCode="AUT">
    <time value="201401151037"/>    <assignedAuthor>
      <id extension="7608888888888" root="1.3.88"/>    </assignedAuthor>
  </author>
  <component typeCode="COMP">
    <!-- ... -->
  </component>
</organizer>
ItemDTCardConfDescriptionLabel
hl7:organizer
(Res…rtp)
Treetree.pnghl7:templateId
II1 … 1M(Res…rtp)
Treeblank.pngTreetree.png@root
1 … 1F2.16.756.5.30.1.127.10.4.31
Treetree.pnghl7:templateId
II1 … 1M(Res…rtp)
Treeblank.pngTreetree.png@root
1 … 1F1.3.6.1.4.1.19376.1.3.1.4
Treetree.pnghl7:statusCode
CS1 … 1M
(de-CH) Der gemäss IHE XD-LAB zugelassene Code „aborted“ ist für Laborbefunde im Transplantationsprozess in der Schweiz nicht zugelassen. Die Meldung soll erst dann erfolgen, wenn die Untersuchung abgeschlossen und endgültig ist.
(Res…rtp)
Treeblank.pngTreetree.png@code
CONF1 … 1Fcompleted
Treetree.pnghl7:effectiveTime
TS.CH.TZ1 … 1RTime of results on this battery(Res…rtp)
Treetree.pnghl7:author
1 … 1R
DE-DE.png Autor des Eintrags (Person oder System)
(Res…rtp)
Included from 1.3.6.1.4.1.19376.1.3.10.9.17 Author with Name, Addr, Telecom (DYNAMIC)
Treeblank.pngTreetree.png@typeCode
cs0 … 1FAUT
Treeblank.pngTreetree.pnghl7:time
TS1 … 1R

The author/time element carries the date&time the entry was produced.

(Res…rtp)
Treeblank.pngTreetree.pnghl7:assignedAuthor
1 … 1R(Res…rtp)
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *R

In accordance with CDA R2.

(Res…rtp)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … *R

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.

(Res…rtp)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL1 … *R

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.

(Res…rtp)
Choice0 … 1Elements to choose from:
  • hl7:assigned​Person containing template 1.3.6.1.4.1.19376.1.3.10.9.18 PlayingEntity or person with Name (DYNAMIC)
  • hl7:assigned​Authoring​Device containing template 1.3.6.1.4.1.19376.1.3.10.9.19 Laboratory Device (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.


Contains 1.3.6.1.4.1.19376.1.3.10.9.18 PlayingEntity or person with Name (DYNAMIC)
(Res…rtp)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Authoring​Device
Contains 1.3.6.1.4.1.19376.1.3.10.9.19 Laboratory Device (DYNAMIC)(Res…rtp)
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
0 … 1

All persons (including the patient) and organizations mentioned in the document SHALL provide elements name, addr and telecom.


Contains 1.3.6.1.4.1.19376.1.3.10.9.13 Organization with Name, Addr, Telecom (DYNAMIC)
(Res…rtp)
Treetree.pnghl7:component
0 … *R
(de-CH) Der Laboratory Battery Organizer enthält mindestens eine Laboratory Observation.

Contains 2.16.756.5.30.1.127.10.4.32 Laborresultat (lrtp) (DYNAMIC)
(Res…rtp)
Treeblank.png where [hl7:observation [hl7:code [@codeSystem=doc('include/voc-2.16.756.5.30.1.129.1.1.3-DYNAMIC.xml')//valueSet [1]/completeCodeSystem/@codeSystem or @nullFlavor=doc('include/voc-2.16.756.5.30.1.129.1.1.3-DYNAMIC.xml')//valueSet [1]/conceptList/exception/@code or concat(@code,@codeSystem)=doc('include/voc-2.16.756.5.30.1.127.11.21-DYNAMIC.xml')//valueSet [1]/conceptList/concept/concat(@code,@codeSystem)]]]
Treeblank.pngTreetree.png@typeCode
0 … 1FCOMP
Treetree.pnghl7:component
0 … *R
(de-CH) Probenentnahme.

Contains 2.16.756.5.30.1.127.10.4.34 Probenentnahme (DYNAMIC)
(Res…rtp)
Treeblank.pngTreetree.png@typeCode
0 … 1FCOMP

SOAS Info

Id2.16.756.5.30.1.127.10.4.33Effective Date valid from 2016‑07‑20
StatusKyellow.png DraftVersion Label
NameSOASInfoDisplay NameSOAS Info
Description
(de-CH) Diese Beobachtung dient dazu, SOAS-spezifische Informationen zu einem HLA-Wert zu deklarieren.
Für jeden HLA-Antikörper MUSS sowohl Center specific Avoid als auch Previous TX angegeben werden.
Prev-Tx=true bedeutet, dass der betreffende HLA-Antikörper aufgrund einer früheren Transplantation gebildet wurde.
Center specific Avoid=true bedeutet, dass aufgrund des betreffende HLA-Antikörpers von einer Transplantation abgesehen werden soll, auch wenn sein MFI-Wert noch im akzeptablen Bereich liegt.
ContextParent nodes of template element with id 2.16.756.5.30.1.127.10.4.33
ClassificationCDA Entry Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 0 transactions and 6 templates, Uses 0 templates
Used by as NameVersion
2.16.756.5.30.1.127.10.4.32ContainmentKyellow.png Laborresultat (lrtp)2016‑07‑20
2.16.756.5.30.1.127.10.4.31Link.pngKyellow.png Resultatgruppe (lrtp)2016‑07‑20
2.16.756.5.30.1.127.10.4.30Link.pngKyellow.png Befundgruppe (lrtp)2016‑07‑20
2.16.756.5.30.1.127.10.3.12Link.pngKyellow.png Laborbefund Section (lrtp)2016‑07‑02
2.16.756.5.30.1.127.10.1.3Link.pngKyellow.png Laborbefund Transplantationsprozesss2017‑08‑14
2.16.756.5.30.1.127.10.1.3Link.pngKvalidblue.png Laborbefund Transplantationsprozesss2016‑07‑02
RelationshipSpecialization: template 2.16.840.1.113883.10.12.303 (2005‑09‑07)
Specialization: template 1.3.6.1.4.1.19376.1.3.1.6 (2008‑08‑08)
Example
Example
<observation classCode="OBS" moodCode="EVN">
  <templateId root="2.16.756.5.30.1.127.10.4.33"/>  <templateId root="2.16.756.5.30.1.1.1.1.3.4.1" extension="CDA-CH.LRTP.SOASInfo"/>  <code code="001" displayName="Center specific avoid" codeSystem="2.16.756.5.30.1.129.1.1.2"/>  <statusCode code="completed"/>  <value xsi:type="BL" value="false"/></observation>
ItemDTCardConfDescriptionLabel
hl7:observation
(SOA…nfo)
Treetree.png@classCode
1 … 1FOBS
Treetree.png@moodCode
1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1M(SOA…nfo)
Treeblank.pngTreetree.png@root
1 … 1F2.16.756.5.30.1.127.10.4.33
Treetree.pnghl7:templateId
II1 … 1M(SOA…nfo)
Treeblank.pngTreetree.png@root
1 … 1F2.16.756.5.30.1.1.1.1.3.4.1
Treeblank.pngTreetree.png@extension
1 … 1FCDA-CH.LRTP.SOASInfo
Treetree.pnghl7:code
CE1 … 1M(SOA…nfo)
 CONF
The value of @code shall be drawn from value set 2.16.756.5.30.1.127.11.19 SOASInfo (DYNAMIC)
Treetree.pnghl7:statusCode
CS1 … 1M(SOA…nfo)
Treeblank.pngTreetree.png@code
CONF1 … 1Fcompleted
Treetree.pnghl7:value
BL1 … 1R
(de-CH) Für Center specific Avoid sind nur false und true zulässig; bei Previous TX kann der Wert unbekannt sein (=nullFlavor).
(SOA…nfo)
Treeblank.pngTreetree.png@xsi:type
1 … 1FBL
 Schematron assertroleKred.png error 
 testnot(@nullFlavor) or hl7:code[@code='002'] 
 MessageNur bei Previous TX (code 002) kann der Wert unbekannt (nullFlavor) sein 

Codes und Wertebereiche

CDA Body Level 2 Section Codes

[Tabelle 5] Wertebereich für CDA Body Level 2 Section Codes

Id2.16.756.5.30.1.127.11.5Effective Date valid from 2015‑12‑18
StatusKgreen.png FinalVersion Label
NamecdachvacdsectioncodesDisplay Namecdachvacd CDA Body Level 2 Section Codes
Source Code System
2.16.840.1.113883.6.1
Level/ TypeCodeDisplay NameCode System
0‑L
11369-6
History of Immunizations
2.16.840.1.113883.6.1
0‑L
11450-4
Problem List
2.16.840.1.113883.6.1
0‑L
11348-0
History of past Illness
2.16.840.1.113883.6.1
0‑L
48765-2
Allergies, Adverse Reactions, Alerts
2.16.840.1.113883.6.1
0‑L
30954-2
Relevant diagnostic tests/laboratory data
2.16.840.1.113883.6.1
0‑L
18727-8
Serology Studies
2.16.840.1.113883.6.1
0‑L
10162-6
History of Pregnancies
2.16.840.1.113883.6.1
0‑L
18776-5
Treatment Plan
2.16.840.1.113883.6.1

Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code.

Geltungsbereich des Befundes

([TRANSV], Kapitel 1; OID: 2.16.756.5.30.1.129.1.1.4) Dieses Subset ist für den vorliegenden Implementierungsleitfaden abschliessend. Andere Codes sind NICHT ERLAUBT.

[Tabelle 6] Wertebereich für "Geltungsbereich des Befundes"

Id2.16.756.5.30.1.127.11.20Effective Date valid from 2016‑07‑02
StatusKgreen.png FinalVersion Label
NameGeltungsbereichdesBefundesDisplay NameGeltungsbereich des Befundes
Source Code System
2.16.756.5.30.1.129.1.1.4
Level/ TypeCodeDisplay NameCode System
0‑L
DDON
Leichenspender
2.16.756.5.30.1.129.1.1.4
0‑L
LDON
Lebendspender
2.16.756.5.30.1.129.1.1.4
0‑L
RECIP
Empfänger
2.16.756.5.30.1.129.1.1.4

Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code.

Laborbefundgruppe

Die Startkonfiguration des Value Sets ist offiziell ab dem 1.1.2014 erhältlich (OID 2.16.756.5.30.1.129.1.1.7.201401). Für produktive Meldungen muss das zum Zeitpunkt der Meldung jeweils gültige Value Set verwendet werden. Diese wird vom BAG, Sektion Transplantation und Fortpflanzungsmedizin publiziert. Siehe auch Kapitel #‎Verantwortlichkeiten.

[Tabelle 7] Wertebereich Valueset Laborbefundgruppe

Id2.16.756.5.30.1.129.1.1.7Effective Date valid from 2016‑07‑02
StatusKgreen.png FinalVersion Label
NameLaborbefundgruppeDisplay NameLaborbefundgruppe
Source Code System
2.16.840.1.113883.6.1
Level/ TypeCodeDisplay NameCode System
0‑L
18717-9
Blood bank studies
2.16.840.1.113883.6.1
0‑L
18719-5
Chemistry studies
2.16.840.1.113883.6.1
0‑L
18720-3
Coagulation studies
2.16.840.1.113883.6.1
0‑L
18723-7
Hematology studies
2.16.840.1.113883.6.1
0‑L
18724-5
HLA studies
2.16.840.1.113883.6.1
0‑L
18725-2
Microbiology studies
2.16.840.1.113883.6.1
0‑L
18727-8
Serology studies
2.16.840.1.113883.6.1
0‑L
18729-4
Urinalysis studies
2.16.840.1.113883.6.1
0‑L
18767-4
Blood gas studies
2.16.840.1.113883.6.1
0‑L
18768-2
Cell counts+Differential studies
2.16.840.1.113883.6.1

Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code.

Bezeichnung der Blutgruppe

Dieses Subset aus SNOMED CT (OID: 2.16.840.1.113883.6.96) ist für den vorliegenden Implementierungsleitfaden abschliessend. Andere Codes sind NICHT ERLAUBT.

[Tabelle 8] Wertebereich Valueset Blutgruppe

Id1.3.6.1.4.1.12559.11.10.1.3.1.42.20
ref
(from repository: epsos-)
Effective Date valid from 2013‑06‑03
StatusKyellow.png DraftVersion LabelJuly 2009
NameepSOSBloodGroupDisplay NameepSOSBloodGroup
DescriptionThe Value Set is used to code the value of patient's blood group + Rh
Source Code System
2.16.840.1.113883.6.96
Level/ TypeCodeDisplay NameCode System
0‑L
112144000
Blood group A
2.16.840.1.113883.6.96
0‑L
278152006
Blood group A Rh(D) negative
2.16.840.1.113883.6.96
0‑L
278149003
Blood group A Rh(D) positive
2.16.840.1.113883.6.96
0‑L
165743006
Blood group AB
2.16.840.1.113883.6.96
0‑L
278154007
Blood group AB Rh(D) negative
2.16.840.1.113883.6.96
0‑L
278151004
Blood group AB Rh(D) positive
2.16.840.1.113883.6.96
0‑L
112149005
Blood group B
2.16.840.1.113883.6.96
0‑L
278153001
Blood group B Rh(D) negative
2.16.840.1.113883.6.96
0‑L
278150003
Blood group B Rh(D) positive
2.16.840.1.113883.6.96
0‑L
58460004
Blood group O
2.16.840.1.113883.6.96
0‑L
278148006
Blood group O Rh(D) negative
2.16.840.1.113883.6.96
0‑L
278147001
Blood group O Rh(D) positive
2.16.840.1.113883.6.96

Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code.

Liste der Vitalzeichen

Die Startkonfiguration des Value Sets ist offiziell ab dem 1.1.2014 erhältlich (OID 2.16.756.5.30.1.129.1.1.5.201401). Für produktive Meldungen muss das zum Zeitpunkt der Meldung jeweils gültige Value Set verwendet werden. Diese wird vom BAG, Sektion Transplantation und Fortpflanzungsmedizin publiziert. Siehe auch Kapitel #Verantwortlichkeiten.

[Tabelle 9] Wertebereich für Vitalzeichen

Id2.16.756.5.30.1.129.1.1.5Effective Date valid from 2016‑07‑02
StatusKgreen.png FinalVersion Label
NameListederVitalzeichenDisplay NameListe der Vitalzeichen
Description
(de-CH) Codesystem: LOINC (OID: 2.16.840.1.113883.6.1)
Value-Set: CDA-CH-LRTP vitalSignList (OID: 2.16.756.5.30.1.129.1.1.5; resp. die darunter liegende gültige Fassung des Value Sets)
Die Startkonfiguration des Value Sets ist offiziell ab dem 1.1.2014 erhältlich (OID 2.16.756.5.30.1.129.1.1.5.201401). Für produktive Meldungen muss das zum Zeitpunkt der Meldung jeweils gültige Value Set verwendet werden. Diese wird vom BAG, Sektion Transplantation und Fortpflanzungsmedizin publiziert.
Source Code System
2.16.840.1.113883.6.1
Level/ TypeCodeDisplay NameCode System
0‑L
8302-2
Body height
2.16.840.1.113883.6.1
0‑L
3141-9
Body weight Measured
2.16.840.1.113883.6.1
0‑L
8867-4
Heart rate
2.16.840.1.113883.6.1
0‑L
8480-6
Systolic blood pressure
2.16.840.1.113883.6.1
0‑L
8462-4
Diastolic blood pressure
2.16.840.1.113883.6.1
0‑L
8310-5
Body temperature
2.16.840.1.113883.6.1

Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code.

Beurteilung von Resultaten

Das folgende Subset ist für den vorliegenden Implementierungsleitfaden abschliessend. Andere Codes sind NICHT ERLAUBT.

[Tabelle 10] Beurteilung von Resultaten

Id2.16.840.1.113883.1.11.10206
ref
(from repository: ad2bbr-)
Effective Date valid from 2014‑03‑26
StatusKgreen.png FinalVersion LabelDEFN=UV=VO=1360-20160323
NameObservationInterpretationNormalityDisplay NameObservationInterpretationNormality
Description

History description 2014-03-26: Lock all vaue sets untouched since 2014-03-26 to trackingId 2014T1_2014_03_26

description:

Interpretation of normality or degree of abnormality (including critical or "alert" level). Concepts in this category are mutually exclusive, i.e., at most one is allowed.

Source Code System
2.16.840.1.113883.5.83
Level/ TypeCodeDisplay NameCode System
1‑S
A
Abnormal
2.16.840.1.113883.5.83
2‑S
AA
Critical abnormal
2.16.840.1.113883.5.83
3‑L
HH
Critical high
2.16.840.1.113883.5.83
3‑L
LL
Critical low
2.16.840.1.113883.5.83
2‑S
H
High
2.16.840.1.113883.5.83
3‑S
H>
Significantly high
2.16.840.1.113883.5.83
4‑L
HH
Critical high
2.16.840.1.113883.5.83
3‑S
HU
Significantly high
2.16.840.1.113883.5.83
4‑L
HH
Critical high
2.16.840.1.113883.5.83
2‑S
L
Low
2.16.840.1.113883.5.83
3‑S
L<
Significantly low
2.16.840.1.113883.5.83
4‑L
LL
Critical low
2.16.840.1.113883.5.83
3‑S
LU
Significantly low
2.16.840.1.113883.5.83
4‑L
LL
Critical low
2.16.840.1.113883.5.83
1‑L
N
Normal
2.16.840.1.113883.5.83

Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code.

Liste der Laborbeobachtungen

Die Startkonfiguration des Value Sets ist offiziell ab dem 1.1.2014 erhältlich (OID 2.16.756.5.30.1.129.1.1.3.201401). Für produktive Meldungen muss das zum Zeitpunkt der Meldung jeweils gültige Value Set verwendet werden. Diese wird vom BAG, Sektion Transplantation und Fortpflanzungsmedizin publiziert. Siehe auch Kapitel ‎#Verantwortlichkeiten.

[Tabelle 11] Wertebereich für Laborbeobachtungen

Id2.16.756.5.30.1.129.1.1.3Effective Date valid from 2015‑12‑18
StatusKgreen.png FinalVersion Label
NameLaborbeobachtungenDisplay NameLaborbeobachtungen
Description
(de-CH) Codesystem: LOINC (OID: 2.16.840.1.113883.6.1)
Value-Set: CDA-CH-LRTP labObsList (OID: 2.16.756.5.30.1.129.1.1.3; resp. die darunter liegende gültige Fassung des Value Sets)
Die Startkonfiguration des Value Sets ist offiziell ab dem 1.1.2014 erhältlich (OID 2.16.756.5.30.1.129.1.1.3.201401). Für produktive Meldungen muss das zum Zeitpunkt der Meldung jeweils gültige Value Set verwendet werden. Diese wird vom BAG, Sektion Transplantation und Fortpflanzungsmedizin publiziert.
A valid code from the code system:
Code System NameCode System IdCode System Version
 LOINC2.16.840.1.113883.6.1
Or one of the following:
2 Source Code Systems
2.16.840.1.113883.6.1
2.16.840.1.113883.5.1008
Level/ TypeCodeCode System

0‑L
UNK
unknown
2.16.840.1.113883.5.1008
Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code.

Sonderfälle bei fehlenden Angaben(NullFlavor)

Dieses Subset ist für die vorliegende Spezifikation abschliessend. Andere Codes sind NICHT ERLAUBT.

[Tabelle 12] Wertebereich für "fehlende Angaben (nullFlavor)"

Id2.16.756.5.30.1.127.11.10Effective Date valid from 2017‑06‑12 14:27:43
StatusKyellow.png DraftVersion Label
NameSonderfaellebeifehlendenangabenDisplay NameSpecial case missing Information (nullFlavor)
Source Code System
2.16.840.1.113883.5.1008
Level/ TypeCodeDisplay NameCode System
0‑L
ASKU
asked but unknown
2.16.840.1.113883.5.1008
0‑L
MSK
masked
2.16.840.1.113883.5.1008
0‑L
NA
not applicable
2.16.840.1.113883.5.1008
0‑L
NASK
not asked
2.16.840.1.113883.5.1008
0‑L
NAV
temporarily unavailable
2.16.840.1.113883.5.1008
0‑L
OTH
other
2.16.840.1.113883.5.1008
0‑L
UNK
unknown
2.16.840.1.113883.5.1008

Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code.

Validierung, Technologien und Tools

Tutorial zu IHE Integrationsprofilen

IHE Laboratory (LAB) Technical Framework

Sharing Laboratory Reports (XD-LAB)

Abkuerzungen und Glossar

Anmerkungen

  1. HL7 Interoperability Work Group. Coming To Terms - Scoping Interoperability for Health Care. 2007; Available from: http://www.hln.com/assets/pdf/Coming-to-Terms-February-2007.pdf
  2. OASIS/ebXML Registry Information Model v3.0
  3. OASIS/ebXML Registry Services Specifications v3.0
  4. SOA P Message Transmission Optimization Mechanism, http://www.w3.org/TR/soap12-mtom/
  5. XML-binary Optimized Packaging http://www.w3.org/TR/2005/REC-xop10-20050125/
  6. Siehe [IHE ITI TF-2x], Appendix V für Details

Referenzierte Dokumente

  1. 1,0 1,1 1,2 CDA-CH: SPEZIFIKATION ZUM ELEKTRONISCHEN AUSTAUSCH VON MEDIZINISCHEN DOKUMENTEN IN DER SCHWEIZ Basierend auf der HL7 Clinical Document Architecture (CDA), Release 2, Etappe 1, Version 1.2 (genehmigt) 27. Januar 2009, http://www.hl7.ch/fileadmin/ungeschuetzte_dateien/files_tc/CDA-CH_de_V1.2.pdf
  2. 2,0 2,1 2,2 CDA-CH-II: SPEZIFIKATION ZUM ERSTELLEN VON VORLAGEN FÜR DIE HEALTH LEVEL 7 CLINICAL DOCUMENT ARCHITECTURE Basierend auf der HL7 Clinical Document Architecture (CDA), Release 2, Etappe 2, Version 1.2 (genehmigt) 27. Januar 2011, http://www.hl7.ch/fileadmin/ungeschuetzte_dateien/files_tc/CDA-CH-II_de_V1.2a.pdf
  3. eHealth Suisse - Empfehlungen I "Standards und Architektur", verabschiedet am 19. März 2009, http://goo.gl/EjZ2G,
  4. eHealth Suisse - Empfehlungen II "Standards und Architektur", verabschiedet am 21. Oktober 2010, http://goo.gl/2KloM
  5. eHealth Suisse - Empfehlungen III "Standards und Architektur", verabschiedet am 27. Oktober 2011, http://goo.gl/hMevI
  6. eHealth Suisse - Empfehlungen IV "Standards und Architektur", verabschiedet am 17. Januar 2013, http://goo.gl/0OBQD
  7. eHealth Suisse - Empfehlungen V "Standards und Architektur", verabschiedet am 28. August 2014, http://goo.gl/wRzD0v
  8. eHealth Schweiz - OID-Konzept für das Schweizerische Gesundheitswesen, 24. März 2010, http://goo.gl/x534f
  9. eHealth Suisse - Empfehlungen I "Semantik und Metadaten", verabschiedet am 17. Januar 2013, http://goo.gl/S6nnz
  10. IHE IT Infrastructure Technical Framework Volume 2x (ITI TF-2x), Volume 2 Appendices,Revision 11.0 – Final Text, September 23, 2014,http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2x.pdf
  11. Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente Zur Anwendung im österreichischen Gesundheitswesen Version: 2.05 vom 17.03.2015, [1.2.40.0.34.7.1.5], http://www.elga.gv.at/fileadmin/user_upload/uploads/download_Papers/Harmonisierungsarbeit/150326_upload/HL7_Implementa-tion_Guide_for_CDA_R2_-_Allgemeiner_Implementierungsleitfaden_fuer_ELGA_CDA_Dokumente_V2.05.pdf
  12. IHE Patient 5 Care Coordination (PCC) Technical Framework Volume 2 (PCC TF-2), Transactions and Content Modules Revision 10.0 - Final Text - 4. November 2014, http://www.ihe.net/uploadedFi-les/Documents/PCC/IHE_PCC_TF_Vol2.pdf
  13. IHE LAB TF-1, Kp. 9.1.4 Reports systematically shared by a private or hospital lab, S. 86
  14. IHE IT Infrastructure (ITI) Technical Framework, Volume 2b (ITI TF-2b), Transactions Part B – Sections 3.29 – 3.51, Revision 9.0 – 31. August 2012, http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Vol2b.pdf
  15. IHE Patient Care Coordination (PCC) Technical Framework Volume 2 (PCC TF-2) Transactions and Content Profiles, Revision 7.0 - 9. September 2011, http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_Rev7-0_Vol_2_2011-09-09.pdf
  16. IHE Laboratory (LAB) Technical Framework, Volume 3 (LAB TF-3), Content Revision 4.0 – Final Text – October 2, 2012, http://www.ihe.net/Technical_Framework/upload/IHE_LAB_TF_Vol3.pdf

Abbildungen

  1. Bezug zu anderen Standards und Leitfäden – Referenzpyramide
  2. Schematische Darstellung des Transfers von Spender- und Empfängerdaten
  3. Communication vs. Content
  4. Akteure gemäss IHE LAB TF-1
  5. Akteure und Transaktionen (konkret für XDS und XDR)
  6. Modell CDA-Header
  7. Modell CDA-Body
  8. Modell Blood group – Blutgruppe
  9. Modell Coded Vital Signs – Vitalzeichen
  10. XD-LAB Akteure und Transaktionen

Tabellen

  1. Notationen in diesem Dokument
  2. Spezifikationen und Templates für CDA Struktur
  3. Regel zum CDA Body
  4. Allgemeine CDA Regeln
  5. Wertebereich für CDA Body Level 2 Section Codes
  6. Wertebereich für „Geltungsbereich des Befundes“
  7. Wertebereich Valueset Laborbefundgruppe
  8. Wertebereich Valueset Blutgruppe
  9. Wertebereich für Vitalzeichen
  10. Beurteilung von Resultaten
  11. Wertebereich für Laborbeobachtungen
  12. Wertebereich für „fehlende Angaben (nullFlavor)“
  13. Abkürzungen und Glossar