Statisches Modell

Aus Hl7wiki
(Teildokument von Übermittlung onkologischer Daten)
Wechseln zu: Navigation, Suche
(Diagnosen (Todesursache))
(Teile verschoben)
Zeile 1: Zeile 1:
 
{{DocumentPart}}
 
{{DocumentPart}}
  
<!--
+
=Statisches Modell (Grundlagen)=
  
    Implementierungsleitfaden "Leitfaden onkologische Versorgung"
+
==Einleitung==
 +
Dieser Leitfaden setzt auf dem VHitG-Arztbrief auf. Daher werden auch die dortigen Spezifikationen übernommen.
 +
Die nachfolgende Tabelle gibt Aufschluss über die in einer Meldung enthaltenen Daten. Die Umsetzung in Form von Abschnitten erfolgt anhand des Analysemodells. Die Spalte „Klasse" referenziert auf die Information in dem Modell. Die letzte Spalte reflektiert in dem Modell dann die Beziehungen der Klassen untereinander.
  
-->
+
Dabei kann eine Klasse sowohl aus inhaltlichen als auch nur aus Referenzzwecken übermittelt werden. Wird zum Beispiel eine Erkrankung erstmalig gemeldet, so wird diese Klasse als Inhalt übermittelt. In folgenden Meldungen wird die Erkrankung nur noch als Referenz zur korrekten Herstellung von Bezügen übermittelt. Ein weiterer zu bedenkender Fall wäre eine Korrektur . Über einen noch zu definierenden Mechanismus (Zeitstempel? Extra Attribut?) sollte das empfangende System in der Lage sein, diese Anlässe auseinanderzuhalten.
{{Infobox Dokument
 
|Title    Übermittlung von onkologischen Daten mittels HL7 Clinical Document Architecture Rel. 2 für das deutsche Gesundheitswesen
 
|Short    = Onkologieleitfaden
 
|Namespace = cdaonk
 
|Type      = Implementierungsleitfaden
 
|Version  = 10
 
|Submitted = .
 
|Date      = 31. Oktober 2012
 
|Copyright = 2012
 
|Status    = Entwurf
 
|Period    = Entwurf
 
|OID      = n.n.
 
|Realm    = Deutschland
 
}}
 
  
 +
[[file:Cdaonk_gesamtuebersicht.gif|Gesamtübersicht]]
  
{|
+
Abbildung 11: vereinfachte Gesamtübersicht
| [[file:Logo-hl7.jpg|100px|HL7-Logo]] ||HL7-Benutzergruppe in Deutschland e. V.
 
|}
 
  
 +
==Grundsätzliche Anforderungen an die Dokumentstruktur==
 +
Dokumente setzen sich grundsätzlich aus folgenden Komponenten zusammen:
 +
# dem eigentlichen Inhalt
 +
# der Kontextinformation
 +
Die Kontextinformation soll der korrekten Handhabung des Inhalts dienen. Korrekte Handhabung beinhaltet
 +
# Die Zuordnung zum Patienten, zur Erkrankung und ggf. der gegenwärtigen therapeutischen Situation
 +
# Die Übermittlung von Meldebegründungen, die Aussagen zur weiteren Nutzbarkeit von Daten erlauben
 +
Im Grundsatz ist davon auszugehen, dass zum Patient die Personen identifizierenden Daten übermittelt werden. Dies ist insbesondere anzunehmen, wenn der Datenfluss der Betreuung folgt und natürlich wenn es die Meldebegründungen entsprechend vorsehen. Die Personenidentifikation kann um Zusatzidentifikatoren zum Aufbau und zur Nutzung eines Master-Patient-Index (MPI) erweitert werden, um den Abgleich (Record Linkage) schneller und sicherer zu machen. Bei bestimmten Empfängern ist eine Pseudo¬nymisierung, unter Umständen im Sinne einer Kontrollnummernbildung, erforderlich. Diese kann sowohl bereits bei Absendung der Daten erfolgen als auch erst in einer Vertrauensstelle. Dabei kann es erforderlich werden, dass Teile der Daten kryptographisch geschützt werden (Beispiel Krebsregister Baden-Württemberg).
  
Copyright © 2012: HL7 Benutzergruppe in Deutschland e.V.
+
==Beispiel für groben Aufbau==
  
HL7-Benutzergruppe in Deutschland e.V.<br>
+
<syntaxhighlight lang="xml">
Geschäftsstelle Köln<br>
+
<?xml version="1.0" encoding="UTF-8" ?>
An der Schanz 1<br>
+
<ClinicalDocument>
50735 Köln
 
  
 +
  <!-- CDA Header -->
 +
  ... siehe Beschreibung CDA R2 Header
  
'''Implementierungsleitfaden'''
+
  <!-- CDA Body -->
'''Übermittlung von onkologischen Daten an Krebsregister mittels HL7 CDA R2'''
+
  <component>
vorgelegt von:
+
      <structuredBody>
 +
      ... siehe Beschreibung CDA R2 Body
 +
      </structuredBody>
 +
  </component>
  
{|
+
</ClinicalDocument>
| [[file:Logo-Dkg.jpg|150px|Logo DKG]] ||Deutsche Krebsgesellschaft <br> Berlin<br><br><br>
+
</syntaxhighlight>
  
|-
+
Nachfolgend ein Beispiel, in dem der Header ausführlicher dargestellt ist:
|  [[file:Logo-Uni-giessen.gif|150px|Logo Uni Giessen]] ||  '''GTDS''' <br> Uniklinik / GTDS <br> Gießen<br><br><br>
 
  
|-
+
<syntaxhighlight lang="xml">
| [[file:Logo-Agfa.jpg|150px|Logo Agfa]] ||Agfa HealthCare GmbH <br> Bonn<br><br><br>
+
<?xml version="1.0" encoding"UTF-8" ?>
 
+
<?xml-stylesheet type="text/xsl" href="?????.xsl"?>
|-
+
<ClinicalDocument
| [[file:Logo-Gkd.jpg|150px|Logo GKD]] ||GKD Gesellschaft für klinische Dienstleistungen Düsseldorf mbH <br> Düsseldorf<br><br><br>
+
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 
+
  xmlns="urn:hl7-org:v3">
|-
+
  <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
| [[file:Logo-Ixserv.jpg|150px|Logo ixserv]] ||ix.mid <br> Köln<br><br><br>
+
  <templateId root="1.2.276.0.76.3.5.7">
 
+
  <id extension="60467049" root="1.2.276.0.58"/>
|-
+
  <code code="???????" codeSystem="2.16.840.1.113883.6.1"
| [[file:Logo-Megapharm.jpg|150px|Logo megapharm]] ||megaPharm<br><br><br><br>
+
        displayName="???????"/>
 +
  <title>Meldung an klinisches Krebsregister</title>
 +
  <effectiveTime value="20060924"/>
 +
  <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
 +
  <languageCode code="de"/>
 +
  <setId extension="D1" root="2.16.840.1.113883.3.933"/>
 +
  <versionNumber value="1"/>
 +
  ...
  
|-
+
  <!-- CDA -->
| [[file:Logo-Zytoservice.jpg|150px|HL7-Logo zytoservice]] ||Zytoservice Deutschland GmbH <br> Hennef<br><br><br>
+
  <component>
 +
    <structuredBody>
 +
      <!-- Meldebegründung -->
 +
      <component>
 +
        <section>
 +
          <templateId root="1.2.276.0.76.3.1.131.1.10.????"/>
 +
          ...
 +
          <!-- Referenz auf Participant -->
 +
        </section>
 +
    </component>
  
|-
+
    ...
| [[file:Logo-Alcedis.jpg|150px|Logo Alcedis]] ||Alcedis GmbH <br> Gießen<br><br><br>
 
  
|-
+
    <!-- Erkrankungsdaten -->
|}
+
    <component>
 +
        <section>
 +
          <templateId root="1.2.276.0.76.3.1.131.1.10.?????"/>
 +
          ...
 +
          <!-- Referenz auf Phänomendaten -->
 +
        </section>
 +
      </component>
  
und der Projektgruppe „onkologische Datenübermittlung" der Deutschen Krebsgesellschaft
+
    </structuredBody>
 +
  </component>
 +
</ClinicalDocument>
 +
</syntaxhighlight>
  
 +
==Identifikation von Informationseinheiten==
  
zur Abstimmung durch:
+
===Mechanismen===
 +
Ein Informationsobjekt kann grundsätzlich über zwei Mechanismen identifiziert werden
  
Mitglieder der HL7-Benutzergruppe e.V.
+
# über ein „neutrale" Identifikationsmerkmal (automatisch vergebene, eindeutige ID)
 +
# über unveränderliche Eigenschaften des Informationsobjektes, die eine eindeutige Identifikation ermöglichen
  
Ansprechpartner:
+
Während die erste Möglichkeit keine Aussage über das Objekt selbst erlaubt, ist die zweite Möglichkeit unter Umständen nicht gegeben. So können bspw. weder bei Patienten die Namen noch bei Tumoren die Diagnose zur Identifikation herangezogen werden.
  
Dr. Frank Oemig, Agfa HealthCare GmbH (Bonn)
+
Natürlich reicht eine ID alleine nicht aus, um ein Objekt (z.B. eine Erkrankung) zu beschreiben, ermöglicht aber die Übermittlung von Beziehungen und damit die Zuordnung von Korrektur¬informationen.
  
 +
===Zeitstempel der Information===
 +
Zeitstempel informieren das Zielsystem über den Zeitpunkt der Entstehung oder Veränderung der Daten. Hierdurch kann das Zielsystem Entscheidungen über notwendige Bearbeitungsschritte treffen (Beispiel siehe unten).
 +
Die in den einzelnen Klassen enthaltenen Zeitangaben beziehen sich aber auf die Information selbst und nicht den Zeitpunkt der Veränderung. Eine solche Information müsste im Attribut participant@Time zu der Rolle Author ausgedrückt werden. Diese optionale Information wird nicht immer verfügbar sein.
 +
Daher sind grundsätzlich alle Informationen auf Aktualität zu überprüfen und dann ggf. zu korrigieren.
  
==Dokumentenhistorie==
+
Beispiel Organzentrumssystem (OZ) - Klinisches Krebsregister (KKR)
  
 
{| class="hl7table"
 
{| class="hl7table"
!Version!!Stand!!Bearbeiter!!Beschreibung!!Dok.-OID
+
!Übermittlung OZ => KKR!!Aktion im KKR
 
|-
 
|-
|01||22.10.10||FO||Draft||n.a.
+
|18.3.2010: (Patient) Erkrankung-ID 3456 / Diagnose-ID 456, Diagnosedatum 1.3.2010 / Diagnosecode  C50.9 / Seite rechts||Kennt Erkrankung-ID 3456 noch nicht, legt eigene Erkrankung an kennt Diagnose noch nicht, wird ebenfalls angelegt merkt sich Referenz Erkrankung-ID
 
|-
 
|-
|02||04.11.10||FO||Erweiterung||n.a.
+
|25.3.2010: (Patient) Erkrankung-ID 3456 / Diagnose-ID 456, Diagnosedatum 1.3.2010 /  Diagnosecode  C50.4 / Seite rechts||Kennt Erkrankung-ID 3456 bereits, legt ''keine neue'' Erkrankung an, kennt Diagnose bereits, korrigiert Diagnosecode
 
|-
 
|-
|03||05.11.10||BS||Erweiterung||n.a.
+
|1.4.2010: (Patient) Erkrankung-ID 3456 / Diagnose-Id 456, Diagnosedatum 1.3.2010 /  Diagnosecode C50.4 / Seite rechts Operation brusterhaltend am 27.3.2010, Operation/Prozedur-ID 3478237 ||Kennt Erkrankung-ID 3456 bereits, macht ''keine Korrektur der Erkrankungsdaten'' verarbeitet Information zu Operation und ordnet sie der korrekten Erkrankung zu
 
|-
 
|-
|04||11.11.10||FO||Einarbeitung erste Kommentare||n.a.
+
|8.4.2010: (Patient) Erkrankung-ID 3456 / Diagnose-ID 456, Diagnosedatum 1.3.2010 / Diagnosecode  C50.4 / Seite rechts Operation Brusterhaltend am 27.3.2010, Operation/Prozedur-ID 3478237 Phänomen Wundheilungsstörung 2.4.2010, Phänomen-ID 574547||Kennt Erkrankung-ID 3456 und Prozedur-ID 3478237 bereits, macht ''keine Korrektur''
|-
+
verarbeitet Information zur Wund¬heilungs¬störung und ordnet sie der korrekten Operation zu, speichert sich Phänomen-ID
|05||12.11.10||FO||weitere Überarbeitung||n.a.
 
|-
 
|06||20.01.11||FO||weitere Überarbeitung||n.a.
 
|-
 
|07||27.01.11||FO||weitere Überarbeitung||n.a.
 
|-
 
|08||21.03.11||FO||weitere Überarbeitung||n.a.
 
|-
 
|09||09.07.11||FO||Umstrukturierung, OIDs, Layout||n.a.
 
|-
 
|10||02.05.12||FO||Wiki||n.a.
 
 
|-
 
|-
 
|}
 
|}
  
==Editor==
 
  
* Dr. Frank Oemig, Agfa HealthCare GmbH (Bonn)
+
==Referenzen auf andere Informationseinheiten==
 +
Die Meldung verwendet interne Referenzen gemäß des Analysemodells. Die Funktionsweise soll hier kurz erläutert werden.
  
 +
[[file:Cdaonbk_referenzen.gif|Referenzen]]
 +
 +
Abbildung 12: Handhabung von Referenzen auf Aktivitäten
  
==Autoren==
+
Über eine Entry-Relationship wird eine Beziehung zu einer anderen Instanz ausgedrückt. Im obigen Beispiel verweist ein Detail einer Maßnahme (Beobachtung) auf eine andere Beobachtung. Welche das konkret ist, kann aus der ID entnommen werden. Im obigen Beispiel verweist die Beobachtung mit der ID=1 (unten) auf die Beobachtung mit den Detailinformationen (oben).
  
* Dr. Frank Oemig, Agfa HealthCare GmbH, Bonn (FO)
+
An dieser Stelle sei darauf hingewiesen, dass eine ID sich normalerweise aus zwei Teilen zusammensetzt. Das ist die eigentliche ID, die dann auch alphanumerisch sein kann, sowie eine root-Angabe, die dann auf das ausgebende System sowie die Art der ID verweist. Letzteres wird durch eine OID realisiert. Näheres dazu regelt die FAQ \[DIMDI, FAQ OID\].
* Esther Amenda, ix.mid, Köln (EA)
 
  
 +
Je nach Spezifikation können für Instanzen auch mehrere IDs vergeben werden.
  
==Mit Beiträgen von==
+
==Referenzen auf Beteiligte==
 +
Die Handhabung der Referenzen auf die Beteiligten erfolgt gemäß nachfolgendem Schema:
  
* Dr. Udo Altmann, GTDS und Forum Klinischer Krebsregister, Gießen (UA)
+
[[file:Cdaonk_referenzen_person.gif|Referenzen auf Personen]]
* Esther Amenda, ix.mid, Köln (EA)
+
* Silke Fontein, megapharm (SF)
+
Abbildung 13: Handhabung von Referenzen auf Personen
* Stefan Lang, Alcedis GmbH (SL)
 
* Matthias Schmitz, Agfa HealthCare, Bonn (MS)
 
* Dr. Bernd Schütze, Univ.-Kl., Düsseldorf (BS)
 
* Claas Thiele, Zytoservice Deutschland GmbH, Hennef (CT)
 
  
 +
Im Bereich des Clinical Statement Patterns besteht die Möglichkeit, Informationen über Personen einzubinden. Grundsätzlich können hier von einer Aktivität mehrere Verweise (Participations) auf Rollen eingebunden werden. Die Rollen können wiederum weitere Details über Verweise auf Personen bzw. Organisationen realisieren. Hierbei müssen aber keine weiteren Details übermittelt werden. Dieser Mechanismus erlaubt somit, beim ersten Vorkommen alle Details zu den Entities zu übermitteln und bei allen anderen bei den Rollen aufzuhören.
 +
Der contextControlCode bestimmt, ob diese Information dem übergeordneten Bereich (Header oder einer anderen hierarchisch übergeordneten Struktur) entspricht. Berichtet z.B. jemand über die Maßnahme eines Dritten, so kann hier dieser Dritte berichtet werden.
 +
Grundlage ist hierbei die Nutzung entsprechender Identifikatoren. Nachfolgende Abbildung verdeutlicht dies:
  
Folgende Organisationen beteiligen sich aktiv an der Diskussion und der Arbeitsgruppe:
+
[[file:Cdaonk_referenzen_id.gif|Referenzen ID]]
* Deutsche Krebsgesellschaft e.V.
+
* Deutsche Onkologie Centrum Holding GmbH (DOC)
+
Abbildung 14: Beispiel für die Nutzung von Identifikatoren zwecks Referenzierung
* Gesellschaft der epidemiologischen Krebsregister in Deutschland e.V. (GEKID)
 
* Gießener Tumordokumentationssystem (GTDS)
 
* Arbeitsgemeinschaft Deutscher Tumorzentren e.V. (ADT)
 
* Agfa Healthcare GmbH, Bonn
 
* GKD Gesellschaft für klinische Dienstleistungen Düsseldorf mbH
 
* ix.mid, Köln
 
* megapharm GmbH
 
* Zytoservice, Hennef
 
  
 +
Durch die Wiederholung der ID (hier: „1") wird deutlich, dass bei der zweiten Aktivität (id=B) dieselbe Person („Meier") eingebunden ist wie in der ersten Aktivität (id=A).
 +
Hierbei spielt es keine Rolle, welche Beziehung die beiden Aktivitäten zueinander haben.
 +
'''''@typeCode Beteiligung
 +
CD CWE \[0..1\]'''''
 +
Der typeCode der Participation bestimmt hierbei, um welche Art der Beteiligung es sich handelt.
  
'''Autoren und Copyright-Hinweis, Nutzungshinweise'''
+
{| class="hl7table"
 
+
!Lvl!!Code!!Bedeutung!!Erläuterung
==Nachnutzungs- bzw. Veröffentlichungsansprüche==
+
|-
Das vorliegende Dokument wurde von der Projektgruppe „onkologische Datenübermittlung" in Kooperation mit der HL7-Benutzergruppe e.V. entwickelt. Die Nachnutzungs- bzw. Veröffentlichungsansprüche sind nicht beschränkt.
+
|1||PRF||performer||Ausführender
 
 
 
 
Der Inhalt dieser Spezifikation ist öffentlich.
 
 
 
Zu beachten ist, dass Teile dieses Dokuments auf dem HL7-Standard CDA beruhen, für die © Health Level Seven, International gilt.
 
Näheres unter [http://www.h7.de hl7.de] und [http://www.hl7.org hl7.org].
 
 
 
Die Erweiterung oder Ablehnung der Spezifikation, ganz oder in Teilen, ist dem Vorstand der Benutzergruppe und den Editoren/Autoren schriftlich anzuzeigen.
 
 
 
 
 
Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifkationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
 
 
 
==Disclaimer==
 
 
 
Obwohl diese Publikation mit größter Sorgfalt erstellt wurde, kann weder die HL7-Benutzergruppe in Deutschland e.V. noch die an der Erstellung beteiligten Firmen keinerlei Haftung für direkten oder indirekten Schaden übernehmen, die durch den Inhalt dieser Spezifikation entstehen könnten.
 
 
 
 
 
Des Weiteren werden nach Abschluss des Abstimmungsverfahrens den diversen Tabellen noch ihre endgültige OID zugewiesen.
 
 
 
=Einleitung=
 
 
 
==Hintergrundinformationen==
 
Im Sommer 2008 traf sich eine kleine Arbeitsgruppe (DOC, ADT, Agfa, Siemens, megapharm, alcedis) bei der DOC Holding in Düsseldorf, um die Optimierung der Datenübertragung in der onkologischen Versorgung zu besprechen. Hintergrund ist die in jedem Bundesland unterschiedliche Spezifikation der epidemiologischen Krebs¬register sowie die verschiedenen Anforderungen der Daten¬übermittlung an klinische Krebsregister und Dienstleister aus der Qualitätssicherung, die zu Problemen und hohen Aufwendungen bei der Implementierung führen. Eine weitere Fragestellung ist die Vereinfachung der Datenübermittlung in der onkologischen Forschung.
 
 
 
===Projekthistorie===
 
Die Historie dieses Projektes ist im Anhang aufgeführt.
 
 
 
===Scope===
 
Ziel soll es sein, eine modellbasierte Grundlage zu schaffen, um die DatenŸbertragung innerhalb der Onkologie auf einen Standard abzubilden.
 
Daten werden auf verschiedenen Ebenen gesammelt und kommuniziert. Die klinische Betreuung erfolgt noch weitestgehend gestützt auf Papier- oder unstrukturierten elektronischen Dokumenten. In strukturierter Form werden Daten jedoch in der Qualitätssicherung, den klinischen und epidemiologischen Krebsregistern sowie den Organzentren benötigt. Es existiert eine Reihe von Spezifikationen – teilweise bedingt durch gesetzliche Vorgaben auf Landes- und Bundesebene  , die einen unterschiedlichen organisatorischen Kontext besitzen und bei ähnlichen Inhalten nicht unbedingt deckungsgleich sind. Praktisch führt dies zu Mehrfachdokumentation und / oder aufwendigen technischen Systemen.
 
 
 
[[file:Cdaonk_akt_situation.jpg|aktuelle Situation]]
 
 
 
Abbildung 1: gegenwärtige Situation
 
 
 
 
 
Die vorhergehende Abbildung verdeutlicht die gegenwärtige Situation. Demnach gilt es folgende Spezifikationen abzubilden/abzulösen:
 
* Gemeinsamer onkologischer Basisdatensatz (ADT, GeKiD, DKG, KoQK, CCC Forum) auf Basis von XML
 
* Schnittstellen KKR / EKR (GeKiD)
 
* ONkeyLINE
 
* Datensatz Onkologie
 
* Spezielle Programme: BQS, DMP Mamma, QS / Benchmarking, ..
 
 
 
Als Grundproblem dieser Spezifikationen kann festgehalten werden, dass Prozesse und Rahmenbedingungen nicht ausreichend beachtet bzw. definiert worden sind: Anlass und Frequenz für Informationsfluss (Meldung), sinnvolle Teilmengen/Optionalitäten, lokale Besonderheiten (z.B. Landesgesetze), Verschlüsselung, technischer Transport, Verar¬beitungs¬status, Rückmeldung.
 
 
 
Als Idealfall ist anzustreben, dass jeder an der Behandlung beteiligte seinen inhaltlichen Anteil am Standard einmalig dokumentiert und dabei allenfalls Zusatzinformationen hinterlegt (wie die Zuordnung zu einer bestimmten Erkrankung oder therapeutischen Situation), die es erlauben, diese Informationen in übergeordnetem Kontext (Register, QS, nachbetreuende Behandler) korrekt einzuordnen.
 
 
 
Dieser Leitfaden zielt darauf ab, geeignete Dokumentenstrukturen für die einzelnen Meldungen auf Basis von Komponenten (Content Modules) zu spezifizieren, die die genannten Anforderungen abbilden können.
 
 
 
===Basisdokumente===
 
Dieses Dokument versucht die in den nachfolgenden Dokumenten aufgeführten Anforderungen umzusetzen:
 
* VHitG-Arztbrief (OID ???????)
 
** Header-Information
 
** Darstellung von Ärzten, Adressen, Namen, ..
 
** Grundlagen von Diagnosen und Prozeduren
 
* Diagnoseleitfaden (OID ??????)
 
** verfeinerte Diagnose-Information, ICD-O, TNM
 
* Liste der bisherigen Spezifikationen:
 
** XML-/CSV-Datensatz des Kooperationsverbundes Qualitätssicherung durch Klinische Krebsregister (KoQK) bzw. der Arbeitsgemeinschaft Deutscher Tumorzentren e.V. (ADT)
 
** XML-/CSV-Datensatz der Gesellschaft der epidemiologischen Krebsregister in Deutschland e.V. (GEKID)
 
** CSV-Datensatz des Instituts für angewandte Qualitätsförderung und Forschung im Gesundheitswesen GmbH (AQUA)
 
** XML-Datensätze der Deutsche Onkologie Centrum Holding GmbH
 
* Liste der noch nicht berücksichtigten Spezifikationen:
 
** CSV-Datensatz des GEKID-Datensatzes der Bundesgeschäftsstelle Qualitäts¬sicherung gGmbH (BQS)
 
** CSV-Datensatz der Gesellschaft für Pädiatrische Onkologie und Häma¬tologie (GPOH)
 
** BDT-Datensatz des Zentralinstituts für Kassenärztliche Versorgung (ZI)
 
** XML-Datensatz der Kassenärztlichen Bundesvereinigung (KBV)
 
** CDA2-Datensatz der Ärztekammer Westfalen-Lippe in Kooperation mit der Bundesgeschäftsstelle Qualitätssicherung gGmbH (BQS)
 
** XML-Datensatz der Arbeitsgruppe Tumordatenschnittstellen Niedersachsen
 
 
 
 
 
{{AlertBox|Wenn die Spezifikationen unverändert aus dem VHitG-Arztbrief übernommen werden, werden diese nicht noch einmal wiederholt. Auch existiert dann kein weiterer Hinweis darauf, um dieses Dokument so klein wie möglich zu halten. Notwendige Ergänzungen werden jedoch aufgeführt.}}
 
 
 
 
 
 
 
====Aufbau====
 
Nach dieser Einleitung werden die abzuhandelnden Szenarien beschrieben. Danach erfolgt eine Erläuterung des Analysemodells, das anhand der bisherigen Datensatzbeschreibungen und der dahinter liegenden medizinischen Informationen erarbeitet wurde. Daran schließen sich das dynamische Modell sowie das statische Modell mit der Definition der CDA-Strukturen (Header + Body) an.
 
Im Anhang befinden sich Referenzen, eine offene Punkteliste, Verzeichnisse etc.
 
 
 
====HL7 und Referenz-Modelle====
 
Wie später noch weiter ausgeführt hat die Gruppe entschieden, die Umsetzung auf Basis von HL7 CDA zu realisieren. Daher sind die Basisspezifikationen des VHitG-Arztbriefes sowie des Diagnoseleitfadens relevant. Für hilfreiche Erläuterungen sei auf die entsprechenden Dokumente verwiesen.
 
 
 
===Konzept und Begründung===
 
Hier folgt das Konzept mit der dazu passenden Begründung des Leitfadens. Inhalt sollten der Zweck, die beteiligten Organisationen, ihre Rollen bei der Erstellung des Leitfadens und der Fokus des Dokuments sein.
 
 
 
====Zweck====
 
Dieser Leitfaden soll primär die Erst- und Folgemeldungen an die klin. und epid. Krebs¬register spezifizieren.
 
 
 
====Fokus====
 
Dieser Leitfaden konzentriert sich auf die Umsetzung des Analysemodells (s.u.) in HL7 V3 CDA R2.
 
 
 
=Szenarien=
 
 
 
==Beispielfälle zum Ablauf von Diagnostik und Therapie==
 
 
 
===Kolorektales Karzinom===
 
Die nachfolgende Tabelle analysiert die Abläufe am Beispiel eines kolorektalen Karzinoms:
 
 
 
{| class="hl7table"
 
!'''Zeitachse'''!!'''Aktion / Ergebnis / Ereignis''' (mögliche Spezialfälle)!!'''Akteur'''!!'''Entstehende Daten''' ''(kursiv Daten außerhalb Basisdaten)'' !! '''Mögliche Empfänger''' (weitere siehe auch Anmerkungen am Tabellenende) !! '''Abstraktes Ereignis'''
 
Nach dem Muster Grundereignis (– Subspezifikationen)
 
 
|-
 
|-
|15.01.09 ||Koloskopie im Rahmen von Früherkennung<br>Feststellen eines malignitätsverdächtigen Polypen im Colon descendens, Entnahme einer Biopsie||Niedergelassener Internist||''Qualitätsmerkmal vollständige Koloskopie und Polypektomie''|| ||Prätherapeutische Diagnostik – klinische Diagnosesicherung
+
|2||PPRF||primary performer||1. Ausführender
 
|-
 
|-
|18.01.09||Eintreffen des Patho¬befundes Adenokarzinom, Infiltration Muscularis propria, Besprechen mit Patienten und Einweisung ins Krankenhaus||Niedergelassener Internist / Pathologe||Diagnosedatum (Def. beachten!)<br> Histologie<br>Lokalisation<br>Erfassungsanlaß||KH / Darmzentrum<br>Klin. Register<br>Epid. Register||Prätherapeutische Diagnostik – Pathologie
+
|2||SPRF||secondary performer||2. Ausführender
 
|-
 
|-
|25.01.09||Aufnahme Röntgenthorax und CT-Abdomen ohne Hinweis auf Metastasen||Chirurgische Abteilung||Klinischer TNM||Darmzentrum<br> Klin. Register<br>Epid. Register||Prätherapeutische Diagnostik – klinisches Staging
+
|||VRF||verifier||Verifizierender
 
|-
 
|-
|26.01.09||(prä op Konferenz, z.B. Lebermetastase)||Alle potentiell beteiligten Disziplinen / ambulant oder stationär||Entscheidung im ''Freitext'' bzw. Vorgesehene Therapien<br>(Basisdatensatz hat kein Konferenzmodul)||Darmzentrum (Klin. Register)<br>(Beteiligte an Therapie)||Therapieplanung - prätherapeutisch
+
|||ENT||data entry person||Datentypist
 
|-
 
|-
|27.01.09||Hemikolektomie||Chirurgische Abteilung||OPS (vor allem 5-... )<br> OP-Datum (Zusätze wie TME, …)||Darmzentrum <br>Klin. Register (Epid. Register)||Operative Therapie – Tumorresektion - Primärtumor (kann mehrfach vorkommen  bei Nachresektionen oder wegen unterschiedlicher OP-Bereiche wie Lymphknoten oder Metastasen)
+
|||CON||consultant||Berater
 
|-
 
|-
|30.01.09||Pathobefund:  pT2pN1 G2 L0 V0 <br> UICC III, Adenokarzinom, R0 (lokal radikal operiert)||Chirurgische Abteilung  / Pathologe||postoperativer TNM <br>Tumorfreiheit||Darmzentrum<br> Klin. Register<br>Epid. Register||Pathologisches Staging
+
|||DIS||discharger||Entlassender
 
|-
 
|-
|31.01.09||Tumorkonferenz<br>Empfehlung: Adjuvante Radiochemotherapie||Inter¬disziplinär<br> (Chirurg, Onkologe klin. und niedergelassen, Strahlentherapeut, ggf. Gyn, Uro, …)||(Vorgesehene Therapien) <br> (ggf. Zuweisung eines Nachsorgeplans)||Darmzentrum<br>(Klin. Register)<br> (((Epi.Register??)))<br>(Beteiligte an Therapie und Nachsorge)||Therapieplanung – postoperativ / im weiteren Sinne posttherapeutisch
+
|||REF||referrer||Überweiser
 
|-
 
|-
|02.02.09||Schmerzen, Darmanastomoseninsuffizienz, konservativ behandelt||Chirurgische Abteilung||Komplikation||Darmzentrum<br>Klin. Register||Unerwünschte Therapiefolge
+
|||ADM||admitter||Aufnehmender
- Komplikation, kurzfristige oder langfristige Nebenwirkung
 
 
|-
 
|-
| ||(Revisionsop)|| || || ||Operative Therapie –  nicht resezierend
+
|||ATT||attender||Beisitzer
 
|-
 
|-
|01.03.09||Beginn der Radiochemotherapie||Externe Strahlentherapie (ambulante Durchführung)||Beginn Strahlentherapie<br>Art<br>Zielgebiet<br>Intention<br>Beginn Chemo<br> Protokoll||Darmzentrum<br> Klin. Register||Einleitung einer längerdauernden Therapie – Strahlentherapie und Chemotherapie
+
|||AUTHEN||authenticator||
 
 
 
|-
 
|-
|15.04.09||Ende der Strahlentherapie||Externe Strahlentherapie (ambulante Durchführung), zubereitender Apotheker||Ende Strahlentherapie<br> Ende Status<br> Dosis<br> Ende Chemo<br> Ende Status<br> Dosierung||Darmzentrum<br> Klin. Register||Beendigung einer längerdauernden Therapie – Strahlentherapie und Chemotherapie
+
|||LA||legal authenticator||Unterzeichnender
 
|-
 
|-
|15.05.09||Strahlentherapienachsorge<br> Leichte Hautrötung||Externe Strahlentherapie ||Nebenwirkung||(Darmzentrum)<br> Klin. Register||Therapiebezogene Nachsorge – ohne / mit gleichzeitiger Feststellung eines Therapieerfolges
+
|||AUT||author||Autor
 
|-
 
|-
|31.07.09||Tumornachsorge: Beschwerdefreiheit, kein Anhalt für Rezidiv||Niedergelassener Arzt||Verlaufsdaten => Tumorfreiheit||Darmzentrum\* <br> Klin. Register||Follow-up - Tumornachsorge
+
|||RCT||record target||Akte
|-
 
|||(Schmerzen, Verwachsungen)||Niedergelassener Arzt||''(Verlaufsdaten => Folgeerkrankungen sind nicht mehr in aktuellem Basisdatensatz enthalten)''||Darmzentrum\* <br> Klin. Register||''Follow-up - Folgeerkrankung des Tumors oder der Tumortherapie <br> möglicherweise Zielereignis bei bestimmten Fragestellungen''
 
|-
 
|31.10.09||Tumornachsorge, metastasenverdächtiger Rundherd in der Leber||Niedergelassener Arzt||Verlaufsdaten => Metastasenlok.||Darmzentrum\* <br> Klin. Register||Follow-up - Rezidiv / Progress
 
|-
 
|7.11.09||Resektion der Lebermetastase||Chirurgische Abteilung||OPS<br> OP-Datum||Darmzentrum<br> Klin. Register<br> ||Operative Therapie – Tumorresektion –Rezidiv
 
|-
 
|10.11.09||Pathobefund: Metastase eines Adenoca. Im Gesunden reseziert||Chirurgische Abteilung  / Pathologe||Tumorfreiheit||Darmzentrum<br> Klin. Register||Follow-up - Therapieerfolg
 
|-
 
|12.11.09||Tumorkonferenz<br> Empfehlung: Adjuvante Chemotherapie||Interdisziplinär||(Vorgesehene Therapien)||||Therapieplanung – postoperativ / im weiteren Sinne posttherapeutisch
 
|-
 
|01.12.09||Einleitung Chemotherapie||Onkologische Abteilung, zubereitender, Apotheker ||Beginn Chemo Intention<br> Protokoll||Darmzentrum<br> Klin. Register||Einleitung einer längerdauernden Therapie – Strahlentherapie und Chemotherapie
 
|-
 
|15.01.10||2. Zyklus||Niedergelassener Onkologe, zubereitender Apotheker||||||
 
|-
 
|…||… ||…||…||…||…
 
|-
 
|15.07.10||Aufnahme Second-Line-Studie||Niedergelassener Onkologe, zuberei-tender Apotheker||''Aufnahme in Studie''<br> Beginn Chemo<br> Intention<br> Protokoll<br> Studienname / Studiennummer||Darmzentrum<br> Klin. Register||Einleitung einer längerdauernden Therapie – Strahlentherapie und Chemotherapie
 
 
 
|-
 
|15.01.11||Tod im Krankenhaus an genereller Metastasierung||Medizinische Abteilung||Sterbedatum Krebs/Tod Relation<br> (Leichenschauschein)||Darmzentrum\* <br> Klin. Register\*\* Epi. Register||Tod
 
|-
 
|16.01.11||Autopsie||Pathologie||Krebs/Tod Relation||Darmzentrum\* Klin. Register\*\* Epi. Register||"Follow-up" - Autopsie
 
 
|-
 
|-
 
|}
 
|}
Tabelle 1: Beispielszenario kolorektales Karzinom
+
Tabelle 3: Vocabulary Domain für die Beteiligung
  
\*ggf. Organzentrum aus KKR
+
'''''@contextControlCode Kontext übernehmen
\*\*ggf. KKR aus EKR
+
BL'''''
 +
Dieses Attribut bestimmt, ob der übergeordnete Kontext übernommen wird oder nicht.
  
Darmzentrum steht exemplarisch für Organkrebszentrum. Das Organkrebszentrum kann seine Dokumentation unter Umständen auch weitgehend in einem klinischen Register abbilden.
+
===Handhabung von Negationen===
 +
HL7 V3 stellt hierzu Mechanismen (Negation-Indikator und Null-Flavor) zur Verfügung, die hier jetzt nicht in aller Tiefe erklärt werden können. Deshalb sei hier auf die entsprechenden Materialien verwiesen.
  
'''Anmerkungen:'''
+
??????????
  
Unklar ist, auf welcher Ebene ein QS Empfänger ist. Zum Teil werden umfassende Daten über den gesamten Behandlungsprozess benötigt. Denkbar wäre eine Ausleitung auf Ebene des jeweiligen Akteurs oder je nachdem auf Ebene der klinischen Register bzw. Organzentren.
+
===Handhabung von Korrekturen und Folgemeldungen===
 +
????????
  
Generell sind die genannten Informationen in der Regel auch Bestandteil der ärztlichen Kommunikation, die zur Zeit nicht strukturiert und meist papierbezogen erfolgt. Es stellt sich daher die Frage der Unterstützung des Informationsflusses außerhalb der o.g. Dokumentationssysteme (Organkrebszentrum, klin. und epid. Register). So könnten sie auch als CDA-Dokumente oder in diesen integriert übermittelt werden und Bestandteil der jeweiligen Akte werden, was in diesem Fall auch relevant für Architektur<sup> </sup> der beteiligten Anwendungssysteme ist.
+
=Statisches Modell (Details)=
  
Follow-up steht für jegliche Art von Verlaufsinformation. Es kann sich um ein geplantes Follow-up im Sinne einer gezielten Nachsorge bei Tumorfreiheit oder Über¬wachungs¬maßnahme bei fortbestehender Erkrankung handeln oder um ein spontanes Ereignis, das den Patienten zum Arzt geführt hat oder das als Nebenbefund bei einer anderen Erkrankung festgestellt wurde (z.B. Lungenmetastase bei Röntgenuntersuchung im Rahmen einer Lungen¬entzündung). Je nach Befund werden ggf. weitere Details erforderlich (z.B. Angabe des Orts der Metastase bei Metastasierung).
+
==Dokumentenstruktur==
 
+
Im CDA-Header werden auf diverse Details verwiesen, deren Verwendung hier kurz aufgeführt wird:
===Rezidiv eines Mammakarzinoms===
 
Dieser Fall dient exemplarisch der Abbildung des Ablaufs bei Quereinsteigern (Fällen, die nicht komplett seit Diagnosestellung in den beteiligten Systemen geführt wurden). Es werden keine neuen Ereignisse abstrahiert.
 
  
 
{| class="hl7table"
 
{| class="hl7table"
!Zeitachse!!Aktion / Ergebnis / Ereignis!!Akteur!!Daten
+
!Element (Sequenz)!!Datentyp!!Bedeutung!!Kard.
 +
|- bgcolor="ffdddd"
 +
|'''ClinicalDocument Klasse'''||||||
 
|-
 
|-
|15.01.09 ||Lokal tastbarer Tumor in Restbrust bei <br>Z.n. Mammaca Januar 2008, behandelt in Brustzentrum A||Niedergelassener Gynäkologe||
+
| bgcolor="ffdddd"|realmCode||CS||eingesetzter Bereich||1..1
 
|-
 
|-
|18.01.09||Ambulante Stanzbiopsie<br>Bestätigung des Verdachts auf Lokalrezidiv durch Pathologen||Brustzentrum B Pathologe||''Anamnestisch'' Diagnosedatum<br>
+
| bgcolor="ffdddd"|typeID||II||- konstant -||1..1
Histologie<br>
 
Lokalisation<br>
 
Primärtherapie<br>
 
''Aktuell''<br>
 
Verlaufsdaten<br>
 
=> Lokalrezidiv
 
 
|-
 
|-
|25.01.09||Mastektomie ||Gynäkologische Abteilung||OPS OP-Datum
+
| bgcolor="ffdddd"|templateID||II||Template ID für das ganze Dokument||0..1
 
|-
 
|-
|27.01.09||Pathobefund rT2N0Mo||Chirurgische Abteilung||postoperativer rTNM Tumorfreiheit
+
| bgcolor="ffdddd"|id||II||Dokumenten-ID||1..1
 
|-
 
|-
|||(weiter vergleichbar Fall 1) ….||||
+
| bgcolor="ffdddd"|code||CE||Dokumententyp||1..1
 
|-
 
|-
|}
+
| bgcolor="ffdddd"|title||ST||Titel des Dokuments||0..1
Tabelle 2: Beispielszenario Rezidiv eines Mammakarzinoms
 
 
 
Wesentlich an diesem Fall ist, dass eine umfangreiche Nacherfassung erfolgen muss.
 
 
 
==Steuerung==
 
Hier geht es um Beispiele von Frage – Anforderung / Antwort – Ergebnismitteilung. Diese sind (auf Papier) gängige Praxis in klinischen Krebsregistern.
 
 
 
1.) Abfrage eines bestimmten geplanten Ereignisses (Nachsorge, Durchführung einer Therapie,…) mit Rückantwort
 
 
 
2.) Abfrage des aktuellsten Follow-up Ergebnisses / letzter Information zum Patienten
 
 
 
==Abbildung Systeme / Akteure==
 
 
 
{| class="hl7table"
 
 
|-
 
|-
!System!!Akteur
+
| bgcolor="ffdddd"|effectiveTime||TS||Erstellungsdatum des Dokuments||1..1
 
|-
 
|-
|PVS||Niedergelassene Haus- und Fachärzte
+
| bgcolor="ffdddd"|confidentialityCode||CE||Vertraulichkeitsgrad||1..1
 
|-
 
|-
|ADT\* / KAS||Fachabteilung: Chirurgie, Onkologie, …
+
| bgcolor="ffdddd"|languageCode||CS||Sprache des Dokuments||1..1
 
|-
 
|-
|OP-System||Chirurg
+
| bgcolor="ffdddd"|setID||II||Set-Kennung||0..1
 
|-
 
|-
|Pathologiesystem||Pathologe
+
| bgcolor="ffdddd"|versionNumber||INT||Versionsnummer||0..1
 
|-
 
|-
|Strahlentherapiesystem||Strahlentherapeut
+
| bgcolor="ffdddd"|copyTime||TS||- nicht verwenden -||0..0
 +
 
 +
|- bgcolor="ccccFF"
 +
|'''Participations'''||||||
 
|-
 
|-
|Chemotherapieplanungssystem / Apothekensystem||Onkologe
+
| bgcolor="ccccFF"|recordTarget||||Patient||1..1
 
|-
 
|-
|Organkrebszentrum / Spezialanwendung Tumorkonferenzsystem||Interdisziplinär / Intersektoral, bei Organkrebszentren oft eine Fach¬abteilung federführend
+
| bgcolor="ccccFF"|author||||Autor (Melder) inkl. Org.||1..1
 
|-
 
|-
|Klin. Register||dto.
+
| bgcolor="ccccFF"|dataEnterer||||Datentypist||0..1
 
|-
 
|-
|Epid. Register||dto.
+
| bgcolor="ccccFF"|informant||||||
 
|-
 
|-
|QS / AQUA / DOC||dto.
+
| bgcolor="ccccFF"|custodian||||||
 
|-
 
|-
|Weitere Systeme mit möglicherweise wenig betroffenen Fällen
+
| bgcolor="ccccFF"|informationRecipient||||Empfänger: klin./epidem. Krebsregister||1..1
 
|-
 
|-
|Laborsystem <br>(Tumormarker und andere Spezialbefunde)||(potenzielle fast alle)
+
| bgcolor="ccccFF"|legalAuthenticator||||unterzeichnender Arzt||1..1
Systeme von Studienzentren||Prüfärzte (aus fast allen Fächern)
 
|}
 
 
 
\*Admission-Discharge-Transfer
 
 
 
==Meldung 1==
 
 
 
{| class="hl7table"
 
!Datum!!!!
 
 
|-
 
|-
|15.1.09||Koloskopie||Prozedur
+
| bgcolor="ccccFF"|authenticator||||||
 
|-
 
|-
|||C18.6 V||Verdachtsdiagnose
+
| bgcolor="ccccFF"|participant||||diverse Teilnehmer, d.h. Person bzw. Organisation||0..*
 +
|- bgcolor="ffdddd"
 +
| bgcolor="ffdddd"|'''Act Relationship'''||||||
 
|-
 
|-
|||Polypektomie||Prozedur
+
| bgcolor="ffdddd"|inFullfillmentOf||||||
 
|-
 
|-
|18.1.09||C18.6 G||Ergebnis dazu
+
| bgcolor="ffdddd"|documentationOf||||||
 
|-
 
|-
|25.1.09||Röntgen Thorax||
+
| bgcolor="ffdddd"|relatedDocuments||||||
 
|-
 
|-
|||CT Abdomen||
+
| bgcolor="ffdddd"|authorization||||||
 
|-
 
|-
|||cT2 N0 M0||Turmorformel
+
| bgcolor="ffdddd"|componentOf||||||
 
|-
 
|-
|27.1.09||Hemikolektomie offen||Prozedur
+
| bgcolor="ffdddd"|component||||||
|-
 
|||5-455.61||
 
|-
 
|30.1.09||pT2 pN1 G2 L0 V0 R0 (lokal radial operiert)||Tumorformel
 
|-
 
|||M8140/3 Adenokarzinom ohne nähere Angaben||
 
|-
 
|31.1.09||pT2 cT2 pN1 cN0 cM0 G2 C0 V0 R0 (lokal)||Zusammenfassende Beurteilung
 
 
|-
 
|-
 
|}
 
|}
 +
Tabelle 4: Dokumentenstruktur (-bestandteile)
  
 +
==Meldeanlässe und Inhalte==
 +
Grundsätze:
 +
* Eine Meldung sollte dann ausgelöst werden, wenn eine Betreuungsepisode beendet und alle zu verantwortenden Informationen verfügbar sind.
 +
* Grundsätzlich werden nur die Inhalte übermittelt, die mit eigenen diagnostischen oder therapeutischen Maßnahmen zusammenhängen. Davon sollte nur abge¬wichen werden, wenn andernfalls Lücken in der Erfassung auftreten würden.
  
===Struktur der Meldung===
+
Beispiel:
 +
Grundsätzlich ist eine chirurgische Abteilung verantwortlich für die Darstellung der operativen Therapie, des Therapieerfolgs und der Komplikationen. Informationen über eine außerhäusige Diagnosestellung müssten nur insofern übermittelt werden, dass das empfangende System in der Lage ist, die Therapie korrekt einem Tumor zuzuordnen. Wenn bekannt ist, dass dies aus irgendeinem Grund regelhaft nicht funktioniert oder vereinbart wurde, dass diese Informationen im Rahmen der operativen Therapie übermittelt werden sollen, hat die chirurgische Abteilung diese Eingabe zu verantworten.
 +
 
 +
Nachfolgend eine Liste der Meldeanlässe:
  
 
{| class="hl7table"
 
{| class="hl7table"
!Sektionen!!ID!!!!!!Krebsreg.
 
 
|-
 
|-
|Erkrankung||||ICD||||X
+
!Code !! Anlass !! Details
 
|-
 
|-
|Diagnoseanlass||||||||X
+
|
|-
+
|Diagnose
|Diagnose 1||D1||||C18.6 G||
+
|
|-
+
* Feststellen einer bösartigen Diagnose
|Tumorformel 1||T1||||cT2 N0 M0||
+
** Diagnosedatum, Tumorlokalisation, Histologie, Metastasierung
|-
+
** ggf. klinischer TNM oder anderes Stagingsystem
|Maßnahme 1||M1||Diagnostik||||
+
* Abschluss der erweiterten Diagnostik, ggf. Therapieplanung / Tumorkonferenz
 +
** klinischer TNM oder anderes Stagingsystem
 +
 
 
|-
 
|-
|Maßnahme 2||M2||Dto.||||
+
|
 +
|Operative Therapie
 +
|
 +
* Durchführen der Maßnahme
 +
** Datum, OPS-Codes, OP-Bereich
 +
** OP-Resultat (pTNM, R-Klassifikation)
 +
** Komplikationen während des stationären Aufenthalts
 +
* operative Nachschau
 +
** 30-Tage Morbidität (Komplikationen) (/Mortalität)
 +
 
 
|-
 
|-
|Maßnahme 3||M3||Dto.||||
+
|
 +
|Strahlentherapie
 +
|
 +
* Einleiten der Strahlentherapie
 +
** Beginn, Zielgebiete / Bestrahlungsbereich, Intention, Stellung im Gesamtplan
 +
* Beenden der Strahlentherapie
 +
** Endedatum und -status, Dosis, Nebenwirkungen
 +
* Nachschau der Strahlentherapie
 +
** Therapieerfolg
 +
** Kurzfristige und langfristige Nebenwirkungen
 +
 
 
|-
 
|-
|Maßnahme 4||M4||Dto.||||
+
|
 +
|Systemische Therapie
 +
|
 +
* Einleiten der systemischen Therapie
 +
** Beginn, Art, Protokoll, Intention, Stellung im Gesamtplan
 +
* Beenden der systemischen Therapie
 +
** Endedatum und -status, ggf. Dosierungen, Nebenwirkungen
 +
 
 
|-
 
|-
|Maßnahme 5||M5||OP||||
+
|
 +
|Verlauf
 +
|
 +
* Datum, Tumorstatus, Metastasierung
 +
 
 
|-
 
|-
|Tumorformel 2||T2||||pT2 pN1 G2 L0 V0 R0 (lokal radial operiert)||
+
|
|-
+
|Life-Status (Meldeamt)
|Diagnose 2||||ICD-O||M8140/3||X
+
|
|-
+
* Datum "lebt" oder Sterbedatum
|Tumorformel 3||T3||Zusammenfassende Beurteilung T1 + T2||pT2 cT2 pN1 cN0 cM0 G2 C0 V0 R0 (lokal)||X
+
* ggf. aktuelle Adresse bzw. Wegzugdatum
 +
 
 +
 
 
|-
 
|-
 +
|
 +
|Sterbemeldung (Gesundheitsamt, Epid. Register)
 +
|
 +
* Sterbedatum, Todesursachen
 +
* Ggf. Krebs-Tod-Relation
 
|}
 
|}
  
Alle Sektionen verweisen auf die Erkrankung.
+
Die Meldeanlässe und Inhalte können je nach Umfang und Länge des überschauten Zeitraum und ggf. dem vorgesehenen Empfänger kombiniert werden. Dies betrifft insbesondere auch den Abgleich von Tumordokumentationssystemen unterschiedlicher Stufen (z.B. Spezialsystemen in Organzentren und regionalen Krebsregistern)
  
=Domänen-Analyse Modell=
+
==Dokumenttypen==
 +
Nachfolgende Tabelle regelt, welche Abschnitte die verschiedenen Dokumenttypen zu den jweweiligen Meldeanlässen enthalten, jeweils mit Optionalität und Kardinalität:
  
==Vorgehensweise==
+
Die Template-ID ist ein technischer Identifikator für die Inhalte in diesem Dokument, während der Dokumententyp ein Code aus einem Vokabular darstellt. Zwischen beiden existiert folgende Korrelation:
Von der Vorgehensweise lässt sich das Projekt wie folgt zusammenfassen:
 
* Analyse der bestehenden Datensatzbeschreibungen
 
* Zusammenfassung in ein Modell auf Basis von UML: DAM
 
* Ergänzung des Basis-Modells um entitätsspezifische Details
 
* Festlegung des dynamischen Verhaltens
 
* Abbildung der einzelnen Klassen aus dem Modell auf Abschnitte innerhalb mit Angabe von Verknüpfungen
 
* Festlegung der Vokabularien und Value Sets
 
  
==Erläuterung==
+
{| class="hl7table"
Nachfolgend ist das Domänen-Analyse-Modell (DAM) abgebildet:
+
!Dokumententyp!!Beschreibung!!Deok.-Template-ID
 +
|-
 +
|Diagnose-Meldung|| ||1.2.276.0.76.3.1.131.1.10.1.1
 +
|-
 +
|Therapie-Meldung|| ||1.2.276.0.76.3.1.131.1.10.1.2
 +
|-
 +
|Verlaufs-Meldung|| ||1.2.276.0.76.3.1.131.1.10.1.3
 +
|-
 +
|Abschluss-Meldung|| ||1.2.276.0.76.3.1.131.1.10.1.4
 +
|}
 +
Tabelle 6: Dokumententyp
  
[[file:Cdaonk_dam.gif|DAM]]
 
  
Abbildung 2: DAM
+
{| class="hl7table"
 
+
!!!colspan=2|Diagnose!!colspan=2|Therapie!!colspan=2|Verlauf!!colspan=2|Abschluss!!
Die einzelnen Bereiche daraus werden nachfolgend eingehender erläutert.
+
|-
 
+
!Sektion||Opt.||Kard.||Opt.||Kard.||Opt.||Kard.||Opt.||Kard.||Template ID
===Patient===
+
|-
Die Klasse Patient enthält die aktuellen Angaben zum Patienten. Die Inzidenz¬adresse einer Erkrankung ist in der Klassen Erkrankung zu finden. Die Kostenträgerinformation wird z.B. durch einige klinische Register zur Abrechnung von Fallpauschalen benötigt.
+
|Nationalität||||||||||||||||||TODO
 
+
|-
===Organisation===
+
|Meldebegründungsdaten||R||1..1||R||1..1||R||1..1||R||1..1||TODO
Organisation umfasst im weiteren Sinn jegliche Einheit, die in einem direkten Verhältnis zum Patienten steht oder verantwortlich für spezielle Maßnahmen ist. Im Konkreten sind hier beispielsweise Angaben zum Betreuungskontext eines Patienten möglich, also z.B. Krankenhausabteilungen oder Praxen.
+
|-
 
+
|Erkrankungsdaten||R||1..1||R||1..1||R||1..1||R||1..1||TODO
===Beteiligter===
+
|-
Beteiligte bezieht sich auf direkt an einer Prozedur Beteiligte. Diese müssen von der Organisation getrennt werden (viele Auswertungen verlangen z.B. direkt Operateure wie im Basisdatensatz).  
+
|Diagnostik||R||1..1|||||||||||||||TODO
 
+
|-
[[file:Cdaonk_dam_patient.jpg|Patient,..]]
+
|Phänomendaten: Primär||R||1..1||||||||||||||TODO
 
+
|-
Abbildung 3: DAM: Patient, Organisation, Beteiligte
+
|Phänomendaten: Metastasen||O||0..*||||||O||0..*||||||TODO
 
+
|-
===Meldebegründung===
+
|Operation||||||R||0..*||||||||||TODO
+
|-
[[file:Cdaonk_dam_meldebegruendung.jpg|Meldebegruendung]]
+
|Strahlentherapie||||||R||0..*||||||||||TODO
 
+
|-
Abbildung 4: DAM: Meldebegründung
+
|systemische Therapie||||||R||0..*||||||||||TODO
 
+
|-
Dort werden alle Angaben abgelegt, die sich im Kontext von Übermittlung von Daten auf Informations- oder Einwilligungsstatus beziehen. Diese Angaben werden von epidemiologischen Krebsregistern je nach Bundesland vorgegeben. Klinische Krebsregister werden in der Regel eine Einwilligung benötigen. Es ist zu erwarten, dass hierdurch eine Reihe weiterer Zwecke (Forschung, Qualitätssicherung, ...) abzubilden sind, die sich evtl. auch nur auf spezifische Ereignisse oder Bereiche beziehen. Die Meldebegründung hat einen rechtlichen Hintergrund und darf nicht mit dem Anlass einer Meldung verwechselt werden (z.B. Erst-, Folge-, Korrekturmeldung etc.).
+
|Medikation||||||||||||||||||vgl. Arztbrief 2012
 
+
|-
===Erkrankungen===
+
|Status (Nachsorge und andere Follow-Up)||||||||||R||1..1||R||1..1||TODO
 
+
|-
[[file:Cdaonk_dam_erkrankung.jpg|DAM Erkrankung]]
+
|Studiendaten||O||0..*||O||0..*||O||0..*||||||TODO
 +
|-
 +
|Abschlussdaten||||||||||||||R||1..*||TODO
 +
|-
 +
|Planung||||||||||O||||O||||TODO
 +
|-
 +
|}
 +
Tabelle 4: Dokumenttypen mit Zuordnung der Sektionen
  
Abbildung 5: DAM: Erkrankung
+
{{FAQBox|
 +
Was ist hiermit
 +
*Life-Status
 +
*Sterbemeldung
 +
}}
  
Dies ist die Klasse für zentrale Daten für beliebige Erkrankungen. Von zentraler Bedeutung sind natürlich Tumorerkrankungen. Durch die Umsetzung des Modells muss sichergestellt werden, dass für jede Tumorerkrankung genau eine Instanz (=ein Eintrag) existiert. Davon unterschieden werden Phänomene, die je nach Art der Erkrankung unterschiedlich sind und die weitere Details enthalten. Für Tumorerkrankungen sind das beispielsweise Primärtumor und Metastasierungen.
+
{{FAQBox|
Nicht-Tumorerkrankungen sind nicht Bestandteil des Basisdatensatzes und in diesem Kontext nicht verpflichtend. Dennoch können sie beispielsweise Therapieentscheidungen beeinflussen und werden in einigen Registern mitgeführt. Bei diesen Erkrankungen sind ggf. einige Attribute nicht verpflichtend.
+
Bei der Therapie muss einer der folgende Abschnitte vorhanden sein:
 +
*Operation
 +
*Strahlentherapie
 +
*systemische Therapie
 +
}}
  
===Phänomen===
+
==Korrekturmeldung==
 +
{{AlertBox|
 +
Anm.: Eine Korrekturmeldung ist kein eigener Dokumenttyp, sondern wird als Korrektur einer entsprechenden Meldung gehandhabt. Damit muss das empfangende System bereits erhaltene Daten korrigieren, weil sich an den vorherigen Informationen etwas als falsch herausgestellt hat.
 +
Eine Differenzierung zwischen Folge- und Korrekturmeldung ist nicht immer klar möglich. Aus diesem Grund wird nicht differentiell übermittelt, sondern immer das komplette Dokument. Innerhalb des kompletten Dokumentes kann dann über Identifikatoren erfolgen.
 +
}}
  
[[file:Cdaonk_dam_phaenomen.jpg|DAM Phaenomen]]
+
==Header==
 +
Der Header enthält alle relevanten Metadaten. Nachfolgend der allgemeine Aufbau:
  
Abbildung 6: DAM: Phänomen
+
{| class="hl7table"
 
+
!Abschnitt!!Kard.!!Klasse!!Referenz auf Abschnitt
Phänomene sind direkte oder indirekte Erscheinungsformen der Tumorerkrankung. Direkte Phänomene (Primärtumor, auch in Sinne von Systemerkrankung, und Metastasen) sind prinzipiell nachweisbar über Tumorzellen, indirekte sind Erkrankungs- oder Therapiefolgen.  
+
|-
Allen Phänomenen ist ein Beginn (Diagnosezeitpunkt) und eine dem Phänomentyp adäquate Codierung gemeinsam. Phänomene können enden und sofern es sich um ein direktes Phänomen handelt, ggf. danach rezidivieren. Darüber hinaus gibt es eine Rezidivierung der Erkrankung an sich, wenn nach kompletter Tumorfreiheit ein direktes Phänomen neu oder wieder auftritt (Primärtumorrezidiv, Rezidiv einer Metastase, Auftreten einer neuen Metastase). Eine Sonderform des Rezidivs ist ein Tumormarker-Rezidiv, das sich zumindest anfänglich jeglichen direkten Nachweises eines Phänomens entzieht. Unter pragmatischen Aspekten der Dokumentation werden unter Umständen prinzipiell auch einzeln nachweisbare Phänomene zusammengefasst:
+
|'''Header'''|| || ||
* Mehrere Primärtumor in einem Organ (z.B. mehrere Basaliome, mehrere Darmtumore, mehrere Mammatumore in einer Brust, ...)
+
|-
* Generalisierte Metastasierung statt Auflistung aller Metastasenlokalisationen
+
|Metadaten|| || ||
* Multiple Metastasen in einem Organ werden nicht einzeln notiert
+
|-
Über direkte Phänomene wird letztendlich die Tumorerkrankung diagnostisch gesichert, weshalb sie über Ergebnisse in Verbindung mit (diagnostischen) Prozeduren steht
+
|Autor (Melder)|| || ||
Das Phänomen Primärtumor mit dem Tumorsitz existiert genau einmal pro Erkrankung. Dies gilt im übertragenen Sinne von Primärerkrankung auch für Systemerkrankungen.
+
|-
Metastasen können bereits bei Diagnose einer Tumorerkrankung vorliegen oder im Verlauf auftreten. In einem bestimmten Prozentsatz gehen sie der Entdeckung eines Primärtumors voraus, oder der Primärtumor wird nie entdeckt, weil er von selbst verschwunden ist oder eine intensive Diagnostik nicht indiziert ist. Außerdem kann es bei Vorliegen mehrerer Tumorerkrankungen unmöglich sein, die Metastase genau einer dieser Erkrankungen zuzuordnen. Daher können Metastasen (und somit Phänomene), mehreren Erkrankungen zugeordnet sein, im Extremfall allen (Tumor-)Erkrankungen.
+
|Unterzeichner|| || ||
Indirekte Phänomene sind:
+
|-
* Folgeerkrankungen der Tumorerkrankung an sich (Anämie, Kachexie, Schmerzen, bisher nicht Bestandteil der Dokumentation)
+
|Patient|| || ||
* Folgeerkrankungen und Folgezustände der Therapie, die zumindest teilweise zwangsläufig auftreten (enthalten in der Vorversion des Basisdatensatzes und ggf. noch gängige Praxis in Registern) und die von akuten oder chronischen Nebenwirkungen sowie OP-Komplikationen abzugrenzen sind
+
|-
* Akute und chronische Nebenwirkungen von Strahlen oder Chemotherapie (internationale Standards wären CTC, RTOG und WHO), in Basisdatensatz enthalten und teilweise für Zertifizierungen wichtig
+
|Empfänger|| || ||
* OP-Komplikationen, in Basisdatensatz enthalten, teilweise organspezifische Besonderheiten für Zertifizierungen
+
|-
Über Phanomen2Phänomen können folgende Assoziationen zwischen Phänomenen bestehen.
+
|Participant|| || ||
* ist Rezidiv von:
+
|-
** Primärtumor: drückt aus, wenn ein Rezidiv an der Stelle des Primärtumors auftritt
+
| &nbsp; || ||Versicherung||
** Metastase: wenn eine Metastase an einem Ort wieder auftritt, von dem sie vorher entfernt wurde (oder wurden wenn es sich um mehrere handelt, die nicht einzeln gewertet wurden)
+
|-
* ist Metastase von:
+
|'''Body'''|| || ||
** Primärtumor: ''(eigentlich ist das schon durch die Beziehung zur Erkrankung klar, bzw. nicht klar wenn nicht zuordenbar bei mehreren Erkrankungen)''
+
|-
 
+
|Sektionen s.u. || || ||
===Prozedur (mit Unterklassen Therapie und Untersuchung)===
 
 
[[file:Cdaonk_dam_prozedur.jpg|DAM Prozedur]]
 
 
 
Abbildung 7: DAM: Prozedur
 
 
 
Therapien und/oder Untersuchungen lassen sich in der Realität manchmal nicht trennen.
 
Bezeichnet jegliche Maßnahmen am Patienten. Prozeduren können diagnostisch (im Sinne von Untersuchungen) und / oder therapeutisch sein. Die unterschiedlichen Aspekte drücken sich durch die Unterklassen Therapie und Untersuchung aus. Außerdem können sich Prozeduren aus mehreren Teilen zusammensetzen. Auf sehr hoher Ebene korrelieren sie teilweise mit den Dokumenten des Basisdatensatzes, wobei die eigentlichen Inhalte weitgehend in anderen Klassen wie Ergebnis, Erkrankung und Phänomen stehen.
 
* Diagnosedaten: Der Prozess der Diagnosestellung an sich
 
* Verlaufsdaten: Verlaufsdaten sind aus Sicht des Basisdatensatzes Statuserhebungen zu bestimmten Anlässen wie Therapieabschlüssen, Nachsorgen, Untersuchungen wegen Beschwerden etc. Eine entsprechende Differenzierung findet sich in der Unterklasse Untersuchung.
 
* Operative Therapie, Strahlentherapie und systemische Therapie (oder Kombinationen aus diesen): Diese setzen sich je nach Therapietyp wiederum aus z.B. Einzelprozeduren (z.B. im Sinne von OPS-Ziffern), unterschiedlichen Zielgebieten oder Zyklen etc. zusammen. Die Modellierung erfolgt über entsprechende Unterklassen.
 
* Life-Status / Abschlussdaten
 
* Autopsiedaten sind inhaltlich weitgehend mit Verlaufsaussagen deckend.
 
Aus praktischer Sicht wird häufig eine Fragmentierung dieser Dokumente erfolgen, die sich aus der Zeitachse und ggf. unterschiedliche Akteure ergibt, siehe Präsentation „Dokumentationsfragmente des Basisdatensatzes". Es ist anzustreben, dass jeder Akteur aus Gründen der Datensparsamkeit lediglich seinen Anteil an der Gesamtdokumentation berichtet.
 
Das Konzept „vorgesehene Maßnahme" des Basisdatensatzes wird über den Durch¬führungsstatus umgesetzt. Hier ist eine potentielle Erweiterung der vertieften Dokumentation für Zertifizierungen denkbar, bei der zum Beispiel Prozessqualitäten auch die Planung z.B. im Rahmen von Tumorkonferenzen berücksichtigen, siehe die letzten beiden Seiten „Vorschlag für ein erweitertes Modell der Therapiedokumentation" im Dokument „Basisdokumentation Handbuch V2a.doc"
 
Therapien sind Aussagen zu Intention und gegenseitiger Stellung sowie der planmäßigen Durchführung eigen. Diese können auch durch die explizite Assoziation „Prozedur behandelt Phänomen" ausgedrückt werden. Da Therapien wiederum indirekte Phänomene auslösen können, kann die Assoziation „Prozedur2Phänomen" auch die Qualität löst aus besitzen.
 
 
 
===Operative Therapie===
 
Ist bereits weitgehend durch die allgemeinen Felder von Prozedur beschrieben. Eine extra Unterklasse ist dennoch sinnvoll, da z.B. der OP-Schlüssel in einigen Fällen nicht alle Informationsbedürfnisse im Rahmen von Qualitätssicherung abdeckt.
 
Eine Operative Therapie kann sich aus mehreren Operationen (in der Regel OP-Tage) zusammensetzen. Auf der Ebene der Operationen sind die Beziehungen zu den Beteiligten (=Operateure), die OP-Ergebnisse (aus diagnostischer Sicht und aus Erfolgssicht in Klasse Ergebnis), sowie die ggf. ausgelösten OP-Folgen (insbesondere Komplikationen) durch Phänomene ausgedrückt.
 
 
 
===Strahlentherapie===
 
Eine Strahlentherapie ist definiert durch ein Zielgebiet, das über eine bestimmte Applikationsart mit einer gewissen Dosis und evtl. einer Boost-Dosis bestrahlt wird ''(wobei sich ein Boost wohl immer auf eine Teilregion bezieht – müsste die dann nicht explizit als Boost-Zielgebiet gefasst werden?)''. Eine Strahlenbehandlung kann sich dabei ggf. aus mehreren (auch gleichzeitigen) Therapien (Zielgebieten) zusammensetzen. Die Strahlentherapie kann sich aus mehreren Einzelbestrahlungen zusammensetzen und korreliert hier mit einer einzelnen Dosis. Die Einzelbestrahlung ist nicht Bestandteil des ADT-Datensatzes. Denkbare Anwendung wäre im Rahmen von Studien, in denen Kapazitäten für eine derart detaillierte Erfassung vorhanden sind oder die Annahme von Daten aus einem Bestrahlungssystem. ''(ist das so? Ich frage mich, ob die Information Boost dann dort drin steckt. Kennt sich da jemand aus? Andernfalls wäre es nicht doch besser, das erst mal wegzulassen?). ''
 
 
 
===Systemtherapie===
 
Ein Zyklus ist ein logischer, ggf. wiederholbarer  Teil einer systemischen Behandlung. Die Zyklus-Kennung entspricht in diesem Fall der Zyklusnummer, die aber nicht notwendigerweise numerisch ist, da Therapien eben nicht notwendigerweise wiederholt werden oder ggf. unterzyklisch geplant werden. Letzteres ist insbesondere in einer Kommunikation mit Apothekensystemen zu bedenken und führt insbesondere auch zur Assoziation „wird beeinflusst durch" von Zyklus und Ergebnis (z.B. Körpergröße, Gewicht, Kreatinin, Leukozyten, …).
 
 
 
Die Einzelgabe ist dann die konkrete Klasse für die Medikamentengabe. Unterstellt man, dass hinter einem Protokoll ein Musterverabreichungsplan steht, gehen aus der Gesamtbetrachtung aller Einzelgaben Unterbrechungen und Dosisreduktionen oder –eskalationen hervor. Zusätzlich kann es erforderlich, sein, Modifikationen, d.h. zu begründen, wie es im Basisdatensatz gefordert wird.
 
Die Dauergabe könnte zwar theoretisch ebenfalls über Einzeldosen abgebildet werden, ist aber, da eher durch den Patienten eingenommen, nicht ohne weiteres kontrollierbar, weshalb eine gesonderte Klasse gebildet wurde, die zum Beispiel häufig für Hormontherapien Anwendung finden dürfte.
 
Das gröbere Modell des Basisdatensatzes wird in der auf dem Bogen „Systemische Therapie" dargestellten Form für nicht praktikabel gehalten, da eine Reihe aktueller Protokolle darüber nicht darstellbar ist. Inhaltlich entspricht es diesem jedoch. In der Praxis wir eine derart genaue Dokumentation jedoch nur bei Integration mit Planungssystemen für machbar gehalten.
 
 
 
{|AlertBox|Es gibt für Deutschland zumindest kein kostengünstiges, allgemein akzeptiertes Klassifikationssystem für Medikation- und Chemotherapieprotokolle.
 
'''Wünschenswert wäre ein zentrales „Register" für Definitionsdaten von Therapieprotokollen. Ohne ein solches Register wird es m.E. notwendig sein das Modell um die Definitionsdaten zu erweitern, d.h. unter Umständen die Therapieprotokolldefinition jeweils mit zu übertragen.'''
 
 
|}
 
|}
  
 +
===Metadaten===
  
===Ergebnis===
+
Zuerst die Metadaten:
  
[[file:Cdaonk_dam_erkrankung.jpg|DAM Ergebnis]]  
+
[[file:Cdaonk_dokheader.gif|ID des Patienten]]
  
Abbildung 8: DAM: Ergebnis
+
Abbildung 15a: Header des Dokuments
  
Die Klasse Ergebnis ist der Container sowohl für direkte Untersuchungsergebnisse als auch deren Zusammenfassung zu einer Beurteilung/Bewertung.
+
{| class="hl7table"
Direkte Untersuchungsergebnisse und Beurteilungen/Bewertungen sind sauber auseinanderzuhalten. Während Untersuchungsergebnisse möglicherweise über Schnittstellen aus anderen Systemen über¬tragen werden können und die zwangsläufig begrenzte Sicht eines Einzelbefunders repräsentieren, müssen mehrere Untersuchungsergebnisse häufig zusammenfassend bewertet werden, um daraus beispielsweise eine Therapieindikation abzuleiten. So sieht der Pathologe nur das, was er an Präparat und Begleitinformation bekommt, der behandelnde Arzt kennt aber den ganzen Patienten und muss im Falle von pT und pN den klinisch erhobene M-Status ergänzen. Eine formal vollständige Histologie aus einer Biopsie hat eine andere Aussagekraft als die aus einem Resektionspräparat.
+
! Lvl
 +
! RIM
 +
! AE
 +
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
  
 +
|-
 +
|1
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|ClinicalDocument
 +
|Dokument
 +
|
 +
|1..1
 +
|M
  
Untersuchungsergebnisse können sich aus Einzelteilen zusammensetzen. So enthält eine TNM-Formel die einzelnen Kategorien zu T, N und M und deren Präfixe etc.. Durch konkrete Instanziierungsregeln ist zu gewährleisten, dass z.B. innerhalb einer TNM-Formel jede Kategorie (T, N, M, ...) bzw. jeder Zusatz (Datum, y-Symbol, Certainty-Faktor, ...)  höchstens einmal vorkommt. Vergleichbares gilt für andere strukturierte Angaben wie histologische Befunde oder ein Ann Arbor Klassifikation.
+
|-
Beurteilungen und Bewertungen reflektieren eher das, was Register benötigen, während direkte Untersuchungsergebnisse für weitergehende Analysen im Rahmen von QM oder Studien benötigt werden und möglicherweise näher an Quelldaten in anderen Systemen sind.
+
|2
 
+
|bgcolor="ff8888"|act
=Dynamisches Modell=
+
|elm
 +
|realmCode
 +
|"DE"
 +
|ST
 +
|1..1
 +
|M
 +
|fix
  
==Grundsatzfrage==
+
|-
Die Übersetzung des DAMs in ein dynamisches Modell bietet grundsätzlich zwei Möglichkeiten:
+
|2
# Erarbeitung eines Modells zur Nachrichtenübertragung (D-MIM) mit Ableitung von entsprechenden Transaktionen
+
|bgcolor="ff8888"|act
# Übertragung in ein äquivalentes Dokumentenformat (CDA)
+
|elm
 +
|typeID
 +
|
 +
|ST
 +
|1..1
 +
|M
 +
|fix
  
Die bisherigen Meldungen beruhen auf dem Austausch von Dokumenten (=Meldungen). Daher bietet es sich an, CDA (Clinical Document Architcture) als Grundlage zu nehmen und dafür entsprechende Abschnitte (Templates) zu definieren.
+
|-
 +
|3
 +
|bgcolor="ff8888"|act
 +
|att
 +
|@root
 +
|2.16.840.1.113883.1.3
 +
|ST
 +
|1..1
 +
|M
 +
|fix
  
==Interaktionsdiagramm==
+
|-
 +
|3
 +
|bgcolor="ff8888"|act
 +
|att
 +
|@extension
 +
|POCD_HD000040
 +
|ST
 +
|1..1
 +
|M
 +
|Diese Kennung ist fix und identifiziert dieses Dokument als CDA-Dokument.
  
[[file:Cdaonk_Interaktion1.gif|Interaktionsdiagramm]]
+
|-
 
+
|2
Abbildung 9: Interaktionsdiagramm
+
|bgcolor="ff8888"|act
 
+
|elm
Die Daten, die an die epidemiologischen Krebsregister geschickt werden, bedürfen weder einer Anonymisierung noch einer Pseudonymisierung. Sollte aber eine Pseudonymisierung erforderlich sein, so wird eine Vertrauensstelle benötigt, die die Daten entsprechend überarbeitet. Im Prinzip spielt diese Vertrauensstelle dann beide Rollen gleichzeitig, wobei aus dem erhaltenen Dokument eine überarbeitete Fassung erstellt wird (TRANSFORM), die dann an den entsprechenden Empfänger weitergereicht wird.
+
|templateId
 +
|Strukturidentifikation des Dokuments
 +
|II
 +
|1..1
 +
|M
 +
|In diesem Element wird die Strukturbeschreibung des Dokumentes festgehalten.
  
[[file:Cdaonk_Interaktion2.gif|Interaktionsdiagramm mit Pseudonymisierung]]
+
|-
+
|3
Abbildung 10: Interaktionsdiagramm mit Pseudonymisierung
+
|bgcolor="ff8888"|act
 +
|att
 +
|@root
 +
|OID des Templates
 +
|
 +
|1..1
 +
|M
 +
|
  
==Vertrauensstelle==
+
|-
Die Gesetze zum Datenschutz in den jeweiligen Bundesländern regeln individuell, wann eine Anonymisierung bzw. Pseudonymisierung der Daten vorzunehmen ist. In einem Bundesland dürfen die Daten nur vom erhebenden Arztbearbeitet werden, in einem anderen nur im Krankenhaus, wieder in einem anderen Bundesland nur bei Einhaltung der ärztlichen Schweigepflicht. usw.
+
|2
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|Id
 +
|Identifikation einer Instanz des Dokuments
 +
|II
 +
|1..1
 +
|M
 +
|Dieses Element identifiziert eindeutig eine Instanz eines Dokuments, d.h.jede Version eines Dokumentes hat eine neue ID.<br>
 +
(vgl. SetId)
  
Die Vertrauensstelle hat nun die Aufgabe, die Anonymisierung sowie Pseudonymisierung der Daten/Dokumente sicherzustellen. Alle die Person direkt identifizierenden Daten sind aus dem Dokument zu entfernen und ggf. durch geeignete Platzhalter zu ersetzen.
+
|-
 +
|3
 +
|bgcolor="ff8888"|act
 +
|att
 +
|@root
 +
|OID
 +
|
 +
|1..1
 +
|M
 +
|Hier muss die OID eingesetzt werden, die das sendende System benutzt, um die Dokumente eindeutig zu identifizieren.
  
{|AlertBox|IHE ITI überlegt derzeit, ein Profil zur Pseudonymisierung zu erstellen.
+
|-
|}
+
|3
 
+
|bgcolor="ff8888"|act
=Statisches Modell (Grundlagen)=
+
|att
 +
|@extension
 +
|eigentliche ID
 +
|ST
 +
|1..1
 +
|M
 +
|
  
==Einleitung==
+
|-
Dieser Leitfaden setzt auf dem VHitG-Arztbrief auf. Daher werden auch die dortigen Spezifikationen übernommen.
+
|2
Die nachfolgende Tabelle gibt Aufschluss über die in einer Meldung enthaltenen Daten. Die Umsetzung in Form von Abschnitten erfolgt anhand des Analysemodells. Die Spalte „Klasse" referenziert auf die Information in dem Modell. Die letzte Spalte reflektiert in dem Modell dann die Beziehungen der Klassen untereinander.
+
|bgcolor="ff8888"|act
 +
|elm
 +
|code
 +
|Dokumenttyp
 +
|CE CWE
 +
|1..1
 +
|M
 +
|s.u.
  
Dabei kann eine Klasse sowohl aus inhaltlichen als auch nur aus Referenzzwecken übermittelt werden. Wird zum Beispiel eine Erkrankung erstmalig gemeldet, so wird diese Klasse als Inhalt übermittelt. In folgenden Meldungen wird die Erkrankung nur noch als Referenz zur korrekten Herstellung von Bezügen übermittelt. Ein weiterer zu bedenkender Fall wäre eine Korrektur . Über einen noch zu definierenden Mechanismus (Zeitstempel? Extra Attribut?) sollte das empfangende System in der Lage sein, diese Anlässe auseinanderzuhalten.
+
|-
 +
|3
 +
|bgcolor="ff8888"|act
 +
|att
 +
|@code
 +
|Dokumenttyp
 +
|"x-physician-cancer-reg"
 +
|1..1
 +
|M
 +
|s.u. und vgl. IHE PCC Vol.2 Abschnitt 6.3.1.A.2
  
[[file:Cdaonk_gesamtuebersicht.gif|Gesamtübersicht]]
+
|-
 +
|3
 +
|bgcolor="ff8888"|act
 +
|att
 +
|@codeSystem
 +
|Dokumenttyp
 +
|"2.16.840.1.113883.6.1"
 +
|1..1
 +
|M
 +
|s.u.
  
Abbildung 11: vereinfachte Gesamtübersicht
+
|-
 
+
|2
==Grundsätzliche Anforderungen an die Dokumentstruktur==
+
|bgcolor="ff8888"|act
Dokumente setzen sich grundsätzlich aus folgenden Komponenten zusammen:
+
|elm
# dem eigentlichen Inhalt
+
|title
# der Kontextinformation
+
|Titel des Dokuments
Die Kontextinformation soll der korrekten Handhabung des Inhalts dienen. Korrekte Handhabung beinhaltet
+
|ST
# Die Zuordnung zum Patienten, zur Erkrankung und ggf. der gegenwärtigen therapeutischen Situation
+
|0..1
# Die Übermittlung von Meldebegründungen, die Aussagen zur weiteren Nutzbarkeit von Daten erlauben
+
|M
Im Grundsatz ist davon auszugehen, dass zum Patient die Personen identifizierenden Daten übermittelt werden. Dies ist insbesondere anzunehmen, wenn der Datenfluss der Betreuung folgt und natürlich wenn es die Meldebegründungen entsprechend vorsehen. Die Personenidentifikation kann um Zusatzidentifikatoren zum Aufbau und zur Nutzung eines Master-Patient-Index (MPI) erweitert werden, um den Abgleich (Record Linkage) schneller und sicherer zu machen. Bei bestimmten Empfängern ist eine Pseudo¬nymisierung, unter Umständen im Sinne einer Kontrollnummernbildung, erforderlich. Diese kann sowohl bereits bei Absendung der Daten erfolgen als auch erst in einer Vertrauensstelle. Dabei kann es erforderlich werden, dass Teile der Daten kryptographisch geschützt werden (Beispiel Krebsregister Baden-Württemberg).
+
|Der Titel des Dokuments ergibt sich aus dem Dokumenttyp bzw. Dokumententemplate.<br>
 +
Beispiel "Diagnosemeldung"
  
==Beispiel für groben Aufbau==
+
|-
 +
|2
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|effectiveTime
 +
|Erstellungszeitpunkt des Dokuments
 +
|TS
 +
|1..1
 +
|M
 +
|
  
<syntaxhighlight lang="xml">
+
|-
<?xml version="1.0" encoding="UTF-8" ?>
+
|3
<ClinicalDocument>
+
|bgcolor="ff8888"|act
 +
|att
 +
|@value
 +
|eigentlicher Zeitpunkt
 +
|TS
 +
|1..1
 +
|M
 +
|
  
  <!-- CDA Header -->
+
|-
  ... siehe Beschreibung CDA R2 Header
+
|2
 
+
|bgcolor="ff8888"|act
  <!-- CDA Body -->
+
|elm
  <component>
+
|confidentialityCode
      <structuredBody>
+
|Vertaulichkeit des Dokumentes
      ... siehe Beschreibung CDA R2 Body
+
|CE CWE
      </structuredBody>
+
|1..1
  </component>
+
|M
 +
|
  
</ClinicalDocument>
+
|-
</syntaxhighlight>
+
|3
 +
|bgcolor="ff8888"|act
 +
|att
 +
|@code
 +
|Code für die Vertaulichkeit
 +
|CE CWE
 +
|1..1
 +
|M
 +
|"N", s.u.
  
Nachfolgend ein Beispiel, in dem der Header ausführlicher dargestellt ist:
+
|-
 +
|3
 +
|bgcolor="ff8888"|act
 +
|att
 +
|@codeSystem
 +
|Codesystem für die Vertaulichkeit
 +
|
 +
|1..1
 +
|M
 +
|fix: "2.16.840.1.113883.5.25"
  
<syntaxhighlight lang="xml">
+
|-
<?xml version="1.0" encoding"UTF-8" ?>
+
|2
<?xml-stylesheet type="text/xsl" href="?????.xsl"?>
+
|bgcolor="ff8888"|act
<ClinicalDocument
+
|elm
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+
|languageCode
  xmlns="urn:hl7-org:v3">
+
|Sprache des Dokumentes
  <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
+
|CS CNE
  <templateId root="1.2.276.0.76.3.5.7">
+
|0..1
  <id extension="60467049" root="1.2.276.0.58"/>
+
|opt.
  <code code="???????" codeSystem="2.16.840.1.113883.6.1"
+
|
        displayName="???????"/>
 
  <title>Meldung an klinisches Krebsregister</title>
 
  <effectiveTime value="20060924"/>
 
  <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
 
  <languageCode code="de"/>
 
  <setId extension="D1" root="2.16.840.1.113883.3.933"/>
 
  <versionNumber value="1"/>
 
  ...
 
  
  <!-- CDA -->
+
|-
  <component>
+
|2
    <structuredBody>
+
|bgcolor="ff8888"|act
      <!-- Meldebegründung -->
+
|elm
      <component>
+
|setId
        <section>
+
|Setkennung
          <templateId root="1.2.276.0.76.3.1.131.1.10.????"/>
+
|II
          ...
+
|0..1
          <!-- Referenz auf Participant -->
+
|
        </section>
+
|Dieses Element legt fest, zu welcher „Menge" das Dokument gehört. Es hält also die verschiedenen Versionen (Instanzen, vgl .Id) zusammen.
    </component>
+
Logische Kennung des Dokuments, die über die Versionen hinweg konstant bleibt. Eine Korrektur ergibt sich aus einer höheren Versionsnummer.
  
    ...
+
|-
 
+
|3
    <!-- Erkrankungsdaten -->
+
|bgcolor="ff8888"|act
    <component>
+
|att
        <section>
+
|@root
          <templateId root="1.2.276.0.76.3.1.131.1.10.?????"/>
+
|OID
          ...
+
|
          <!-- Referenz auf Phänomendaten -->
+
|1..1
        </section>
+
|M
      </component>
+
|Hier muss die OID eingesetzt werden, die das sendende System benutzt, um das Dokument-Set eindeutig zu identifizieren.
  
    </structuredBody>
+
|-
  </component>
+
|3
</ClinicalDocument>
+
|bgcolor="ff8888"|act
</syntaxhighlight>
+
|att
 +
|@extension
 +
|eigentliche ID
 +
|ST
 +
|1..1
 +
|M
 +
|
  
==Identifikation von Informationseinheiten==
+
|-
 +
|2
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|versionNumber
 +
|Versionsnummer
 +
|INT
 +
|1..1
 +
|M
 +
|Eine fortlaufende Nummer zur Versionierung des Dokumentes.
  
===Mechanismen===
+
|-
Ein Informationsobjekt kann grundsätzlich über zwei Mechanismen identifiziert werden
+
|3
 +
|bgcolor="ff8888"|act
 +
|att
 +
|@value
 +
|Versionsnummer
 +
|INT
 +
|1..1
 +
|
 +
|Zusammen mit der Setkennung regelt dieses Element die Versionierung der Dokumente.
  
# über ein „neutrale" Identifikationsmerkmal (automatisch vergebene, eindeutige ID)
+
|-
# über unveränderliche Eigenschaften des Informationsobjektes, die eine eindeutige Identifikation ermöglichen
+
| 2
 +
|bgcolor="ffaaaa"| rel
 +
| elm
 +
| relatedDocument
 +
|
 +
|
 +
| 0..1
 +
|
 +
|
  
Während die erste Möglichkeit keine Aussage über das Objekt selbst erlaubt, ist die zweite Möglichkeit unter Umständen nicht gegeben. So können bspw. weder bei Patienten die Namen noch bei Tumoren die Diagnose zur Identifikation herangezogen werden.
+
|-
 +
| 3
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| parentDocument
 +
| ParentDocument
 +
|
 +
| 1..1
 +
| required
 +
|
  
Natürlich reicht eine ID alleine nicht aus, um ein Objekt (z.B. eine Erkrankung) zu beschreiben, ermöglicht aber die Übermittlung von Beziehungen und damit die Zuordnung von Korrektur¬informationen.  
+
|-
 +
| 4
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| id
 +
| ID des Document
 +
|
 +
| 1..1
 +
| required
 +
|
  
===Zeitstempel der Information===
+
|}
Zeitstempel informieren das Zielsystem über den Zeitpunkt der Entstehung oder Veränderung der Daten. Hierdurch kann das Zielsystem Entscheidungen über notwendige Bearbeitungsschritte treffen (Beispiel siehe unten).
 
Die in den einzelnen Klassen enthaltenen Zeitangaben beziehen sich aber auf die Information selbst und nicht den Zeitpunkt der Veränderung. Eine solche Information müsste im Attribut participant@Time zu der Rolle Author ausgedrückt werden. Diese optionale Information wird nicht immer verfügbar sein.
 
Daher sind grundsätzlich alle Informationen auf Aktualität zu überprüfen und dann ggf. zu korrigieren.
 
 
 
Beispiel Organzentrumssystem (OZ) - Klinisches Krebsregister (KKR)
 
  
 
{| class="hl7table"
 
{| class="hl7table"
!Übermittlung OZ => KKR!!Aktion im KKR
 
 
|-
 
|-
|18.3.2010: (Patient) Erkrankung-ID 3456 / Diagnose-ID 456, Diagnosedatum 1.3.2010 / Diagnosecode  C50.9 / Seite rechts||Kennt Erkrankung-ID 3456 noch nicht, legt eigene Erkrankung an kennt Diagnose noch nicht, wird ebenfalls angelegt merkt sich Referenz Erkrankung-ID
+
!Code!!Beschreibung
 
|-
 
|-
|25.3.2010: (Patient) Erkrankung-ID 3456 / Diagnose-ID 456, Diagnosedatum 1.3.2010 /  Diagnosecode  C50.4 / Seite rechts||Kennt Erkrankung-ID 3456 bereits, legt ''keine neue'' Erkrankung an, kennt Diagnose bereits, korrigiert Diagnosecode
+
|34806-0||Oncology Note
 
|-
 
|-
|1.4.2010: (Patient) Erkrankung-ID 3456 / Diagnose-Id 456, Diagnosedatum 1.3.2010 /  Diagnosecode C50.4 / Seite rechts Operation brusterhaltend am 27.3.2010, Operation/Prozedur-ID 3478237 ||Kennt Erkrankung-ID 3456 bereits, macht ''keine Korrektur der Erkrankungsdaten'' verarbeitet Information zu Operation und ordnet sie der korrekten Erkrankung zu
+
|x-physician-cancer-rep||Report to Cancer Registries
 +
|}
 +
Tabelle: Dokumenttyp
 +
 
 +
{| class="hl7table"
 
|-
 
|-
|8.4.2010: (Patient) Erkrankung-ID 3456 / Diagnose-ID 456, Diagnosedatum 1.3.2010 / Diagnosecode  C50.4 / Seite rechts Operation Brusterhaltend am 27.3.2010, Operation/Prozedur-ID 3478237 Phänomen Wundheilungsstörung 2.4.2010, Phänomen-ID 574547||Kennt Erkrankung-ID 3456 und Prozedur-ID 3478237 bereits, macht ''keine Korrektur''
+
!Code!!Beschreibung
verarbeitet Information zur Wund¬heilungs¬störung und ordnet sie der korrekten Operation zu, speichert sich Phänomen-ID
 
 
|-
 
|-
 +
|N||normal
 
|}
 
|}
 +
Tabelle: Vertraulichkeit (OID: 2.16.840.1.113883.5.25)
  
 +
<syntaxhighlight lang="xml">
 +
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd">
 +
<realmCode code="DE"/>
 +
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
 +
<templateId root="1.2.276.0.76.3.1.131.1.10.1.1"/>
 +
<id extension="xyz" root="OID"/>
 +
<code code="x-physician-cancer-rep" codeSystem="2.16.840.1.113883.6.1" displayName="report to cancer registry"/>
 +
<title>Diagnosemeldung</title>
 +
<effectiveTime value="20120407130000+0500"/>
 +
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
 +
<languageCode code="de-DE"/>
  
==Referenzen auf andere Informationseinheiten==
+
...
Die Meldung verwendet interne Referenzen gemäß des Analysemodells. Die Funktionsweise soll hier kurz erläutert werden.
 
  
[[file:Cdaonbk_referenzen.gif|Referenzen]]
+
</ClinicalDocument>
+
</syntaxhighlight>
Abbildung 12: Handhabung von Referenzen auf Aktivitäten
 
  
Über eine Entry-Relationship wird eine Beziehung zu einer anderen Instanz ausgedrückt. Im obigen Beispiel verweist ein Detail einer Maßnahme (Beobachtung) auf eine andere Beobachtung. Welche das konkret ist, kann aus der ID entnommen werden. Im obigen Beispiel verweist die Beobachtung mit der ID=1 (unten) auf die Beobachtung mit den Detailinformationen (oben).
+
===Participants: Einleitung===
  
An dieser Stelle sei darauf hingewiesen, dass eine ID sich normalerweise aus zwei Teilen zusammensetzt. Das ist die eigentliche ID, die dann auch alphanumerisch sein kann, sowie eine root-Angabe, die dann auf das ausgebende System sowie die Art der ID verweist. Letzteres wird durch eine OID realisiert. Näheres dazu regelt die FAQ \[DIMDI, FAQ OID\].
+
An der Erstellung eines Dokumentes sind mehrere Personen bzw. Organisationen und Systeme beteiligt. Dies soll hier einmal kurz erläutert werden, damit die anschließende Detaildarstellung verständlicher wird. Dies wird in Form verschiedener Situationen gemacht:
  
Je nach Spezifikation können für Instanzen auch mehrere IDs vergeben werden.
+
====Variante 1====
 +
Der Arzt erstellt einen Arztbrief, aus dem ein med.Dokumentar die Informationen in ein System eingibt, das dann die Meldung abschickt:
  
==Referenzen auf Beteiligte==
+
*Arzt = informant
Die Handhabung der Referenzen auf die Beteiligten erfolgt gemäß nachfolgendem Schema:
+
*med.Dokumentar = dataEnterer (optional)
 +
*System/Tumordokumentationssystem = authoringDevice
 +
*System betreibende Organisation = Custodian
 +
*Tumorregister = informationRecipient (optional)
 +
 
 +
====Variante 2====
 +
Ein regionales Register erstellt auf Basis der eingegangenen Meldungen eine neue Meldung an das Landeskrebsregister:
 +
 
 +
*Arzt der ursprüngl. Meldung (jetzt ggf. mehrere) = informant
 +
*med.Dokumentar im reg. Reg. = dataEnterer (optional)
 +
*Tumordokumentationssystem = authoringDevice
 +
*System betreibende Organisation (regionale Register) = Custodian
 +
*Landeskrebsregister = informationRecipient (optional)
 +
 
 +
 
 +
===Participant: Patient (recordTarget)===
  
[[file:Cdaonk_referenzen_person.gif|Referenzen auf Personen]]
 
 
Abbildung 13: Handhabung von Referenzen auf Personen
 
  
Im Bereich des Clinical Statement Patterns besteht die Möglichkeit, Informationen über Personen einzubinden. Grundsätzlich können hier von einer Aktivität mehrere Verweise (Participations) auf Rollen eingebunden werden. Die Rollen können wiederum weitere Details über Verweise auf Personen bzw. Organisationen realisieren. Hierbei müssen aber keine weiteren Details übermittelt werden. Dieser Mechanismus erlaubt somit, beim ersten Vorkommen alle Details zu den Entities zu übermitteln und bei allen anderen bei den Rollen aufzuhören.
+
[[file:Cdaonk_patient.gif|ID des Patienten]]
Der contextControlCode bestimmt, ob diese Information dem übergeordneten Bereich (Header oder einer anderen hierarchisch übergeordneten Struktur) entspricht. Berichtet z.B. jemand über die Maßnahme eines Dritten, so kann hier dieser Dritte berichtet werden.
 
Grundlage ist hierbei die Nutzung entsprechender Identifikatoren. Nachfolgende Abbildung verdeutlicht dies:
 
  
[[file:Cdaonk_referenzen_id.gif|Referenzen ID]]
+
Abbildung 15: Identifikation des Patienten
 
Abbildung 14: Beispiel für die Nutzung von Identifikatoren zwecks Referenzierung
 
  
Durch die Wiederholung der ID (hier: „1") wird deutlich, dass bei der zweiten Aktivität (id=B) dieselbe Person („Meier") eingebunden ist wie in der ersten Aktivität (id=A).
 
Hierbei spielt es keine Rolle, welche Beziehung die beiden Aktivitäten zueinander haben.
 
'''''@typeCode Beteiligung
 
CD CWE \[0..1\]'''''
 
Der typeCode der Participation bestimmt hierbei, um welche Art der Beteiligung es sich handelt.
 
  
 
{| class="hl7table"
 
{| class="hl7table"
!Lvl!!Code!!Bedeutung!!Erläuterung
+
! Lvl
 +
! RIM
 +
! AE
 +
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
 +
 
 +
 
 
|-
 
|-
|1||PRF||performer||Ausführender
+
|0
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|ClinicalDocument
 +
|Dokument
 +
|
 +
|1..1
 +
|M
 +
 
 
|-
 
|-
|2||PPRF||primary performer||1. Ausführender
+
| 1
 +
|bgcolor="ccffff"| part
 +
| elm
 +
| recordTarget
 +
| Patient
 +
|
 +
| 1..1
 +
| M
 +
| Patient
 +
 
 
|-
 
|-
|2||SPRF||secondary performer||2. Ausführender
+
| 2
 +
|bgcolor="ccffff"| part
 +
| att
 +
| typeCode
 +
| "RCT"
 +
| CS CNE
 +
| 1..1
 +
| M
 +
| fix
 +
 
 
|-
 
|-
|||VRF||verifier||Verifizierender
+
| 2
 +
|bgcolor="ffff88"| role
 +
| elm
 +
| patientRole
 +
|  
 +
|  
 +
| 1..1
 +
| M
 +
|
 +
 
 
|-
 
|-
|||ENT||data entry person||Datentypist
+
| 3
 +
|bgcolor="ffff88"| role
 +
| att
 +
| classCode
 +
| "PAT"
 +
| CS CNE
 +
| 1..1
 +
| M
 +
| fix
 +
 
 
|-
 
|-
|||CON||consultant||Berater
+
| 3
|-
+
|bgcolor="ffff88"| role
|||DIS||discharger||Entlassender
+
| elm
 +
| id
 +
| Patient-ID: nicht verwendet
 +
| SET<II>
 +
| 1..*
 +
| M
 +
|  
 +
 
 
|-
 
|-
|||REF||referrer||Überweiser
+
| 4
 +
|bgcolor="ffff88"| role
 +
| att
 +
| @root
 +
| OID
 +
|  
 +
| 1..1
 +
| M
 +
| Das ist die OID des sendenden Systems für Patienten.
 +
 
 
|-
 
|-
|||ADM||admitter||Aufnehmender
+
| 4
 +
|bgcolor="ffff88"| role
 +
| att
 +
| @extension
 +
| die eigentliche ID
 +
| ST
 +
| 1..1
 +
| M
 +
|
 +
 
 
|-
 
|-
|||ATT||attender||Beisitzer
+
| 3
 +
|bgcolor="ffff88"| role
 +
| elm
 +
| addr
 +
| Adresse
 +
| SET<AD>
 +
| 0..*
 +
|
 +
|
 +
 
 +
{{AlertBox|
 +
Es sollte immer eine Adresse übertragen werden. Bei anonymisierten bzw. pseudonymisierten Patienten kann dies auf eine Postleitzahl oder Bundesland reduziert werden.
 +
}}
 +
 
 
|-
 
|-
|||AUTHEN||authenticator||
+
| 4
 +
|bgcolor="ffff88"| role
 +
| att
 +
| @streetname
 +
| Strasse
 +
|  
 +
| 0..1
 +
| M
 +
|
 +
 
 
|-
 
|-
|||LA||legal authenticator||Unterzeichnender
+
| 4
 +
|bgcolor="ffff88"| role
 +
| att
 +
| @houseNumber
 +
| Hausnummer
 +
|  
 +
| 0..1
 +
|
 +
|
 +
 
 
|-
 
|-
|||AUT||author||Autor
+
| 4
 +
|bgcolor="ffff88"| role
 +
| att
 +
| @postalCode
 +
| Postleitzahl
 +
|  
 +
| 0..1
 +
| M
 +
| PLZ ohne Länderkennzeichen
 +
 
 
|-
 
|-
|||RCT||record target||Akte
+
| 4
 +
|bgcolor="ffff88"| role
 +
| att
 +
| @city
 +
| Wohnort
 +
|  
 +
| 0..1
 +
| M
 +
|
 +
 
 
|-
 
|-
|}
+
| 4
Tabelle 3: Vocabulary Domain für die Beteiligung
+
|bgcolor="ffff88"| role
 +
| att
 +
| @country
 +
| Land
 +
|
 +
| 0..1
 +
| M
 +
|
  
'''''@contextControlCode Kontext übernehmen
+
|-
BL'''''
+
| 3
Dieses Attribut bestimmt, ob der übergeordnete Kontext übernommen wird oder nicht.
+
|bgcolor="ffff88"| role
 +
| elm
 +
| telecom
 +
| Kontaktinformationen
 +
| SET<TEL>
 +
| 0..*
 +
| M
 +
|
  
===Handhabung von Negationen===
+
|-
HL7 V3 stellt hierzu Mechanismen (Negation-Indikator und Null-Flavor) zur Verfügung, die hier jetzt nicht in aller Tiefe erklärt werden können. Deshalb sei hier auf die entsprechenden Materialien verwiesen.
+
|4
 
+
|bgcolor="88ff88"|ent
??????????
+
| elm
 +
| patient
 +
| Patient
 +
|
 +
| 0..1
 +
| optional
 +
|
  
===Handhabung von Korrekturen und Folgemeldungen===
 
????????
 
 
=Statisches Modell (Details)=
 
 
==Dokumentenstruktur==
 
Im CDA-Header werden auf diverse Details verwiesen, deren Verwendung hier kurz aufgeführt wird:
 
 
{| class="hl7table"
 
!Element (Sequenz)!!Datentyp!!Bedeutung!!Kard.
 
|- bgcolor="ffdddd"
 
|'''ClinicalDocument Klasse'''||||||
 
 
|-
 
|-
| bgcolor="ffdddd"|realmCode||CS||eingesetzter Bereich||1..1
+
|5
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| name
 +
| Name des
 +
| SET<PN>
 +
| 0..*
 +
| optional
 +
|Folgende Pseudonyme werden vorgesehen:
 +
# Umkehrbar eindeutige Pseudonyme (Angabe von Identifikator + Quellsystem), z.B. Identifikation über Nachsorgepass Bayern, Identifikation im Tumorzentrum Xy, Identifikation in Organzentrumssystem Xyz => OID mit Extension!
 +
# „Stochastische Pseudonyme" (Kontrollnummern)
 +
Bestimmte Attribute wie Namen oder Geburtsdatum sind dann optional, die dann in ganz definierten Kommunikationskontexten durch Kontrollnummern ersetzt werden.
 +
Die Identifikatoren unter 1. wären in jedem Fall sinnvoll für das automatisierte Record Linkage im Zielsystem, wenn es hier nicht geht, dann woanders
 +
 
 +
{{AlertBox|
 +
Anonymisierung bzw. Pseudonymisierung der ID, des Namens, Adresse etc.<br>
 +
Es ist zu klären, welche Informationen neben den klassischen wie „Name", „Geburtsdatum" und „Adresse" pseudonymisiert werden müssen.
 +
}}
 +
 
 
|-
 
|-
| bgcolor="ffdddd"|typeID||II||- konstant -||1..1
+
|6
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| prefix
 +
| Anrede
 +
| ST
 +
| 0..1
 +
| optional
 +
| Anrede: Herr, Frau, ..
 +
 
 
|-
 
|-
| bgcolor="ffdddd"|templateID||II||Template ID für das ganze Dokument||0..1
+
|6
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| prefix
 +
| Titel
 +
| ST
 +
| 0..1
 +
| optional
 +
| akademischer Titel
 +
 
 
|-
 
|-
| bgcolor="ffdddd"|id||II||Dokumenten-ID||1..1
+
|7
|-
+
|bgcolor="88ff88"|ent
| bgcolor="ffdddd"|code||CE||Dokumententyp||1..1
+
| att
 +
| @qualifier
 +
| "AC"
 +
| ST
 +
| 0..1
 +
| optional
 +
| Qualifier für akademischen Titel
 +
 
 
|-
 
|-
| bgcolor="ffdddd"|title||ST||Titel des Dokuments||0..1
+
|6
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| given
 +
| Vorname
 +
| ST
 +
| 0..*
 +
| optional
 +
| Vornamen
 +
 
 
|-
 
|-
| bgcolor="ffdddd"|effectiveTime||TS||Erstellungsdatum des Dokuments||1..1
+
|6
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| familiy
 +
| Familienname
 +
| ST
 +
| 0..*
 +
| optional
 +
| Familienname
 +
 
 
|-
 
|-
| bgcolor="ffdddd"|confidentialityCode||CE||Vertraulichkeitsgrad||1..1
+
|6
|-
+
|bgcolor="88ff88"|ent
| bgcolor="ffdddd"|languageCode||CS||Sprache des Dokuments||1..1
+
| elm
|-
+
| familiy
| bgcolor="ffdddd"|setID||II||Set-Kennung||0..1
+
| Geburtsname
|-
+
| ST
| bgcolor="ffdddd"|versionNumber||INT||Versionsnummer||0..1
+
| 0..*
|-
+
| optional
| bgcolor="ffdddd"|copyTime||TS||- nicht verwenden -||0..0
+
|  
  
|- bgcolor="ccccFF"
 
|'''Participations'''||||||
 
 
|-
 
|-
| bgcolor="ccccFF"|recordTarget||||Patient||1..1
+
|7
 +
|bgcolor="88ff88"|ent
 +
| att
 +
| @qualifier
 +
| "BR"
 +
| ST
 +
| 0..1
 +
| optional
 +
| Qualifier für Geburtsname
 +
 
 
|-
 
|-
| bgcolor="ccccFF"|author||||Autor (Melder) inkl. Org.||1..1
+
|5
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| administrativeGenderCode
 +
| Geschlecht
 +
| CE CWE
 +
| 0..1
 +
| optional
 +
|Mit diesem Attribut wird das Geschlecht des Patienten übertragen.
 +
 
 
|-
 
|-
| bgcolor="ccccFF"|dataEnterer||||Datentypist||0..1
+
|6
 +
|bgcolor="88ff88"|ent
 +
| att
 +
| @code
 +
| Code für das Geschlecht
 +
|  
 +
| 0..1
 +
| optional
 +
|
 +
 
 
|-
 
|-
| bgcolor="ccccFF"|informant||||||
+
|6
 +
|bgcolor="88ff88"|ent
 +
| att
 +
| @codeSystem
 +
| Codesystem für das Geschlecht
 +
|  
 +
| 0..1
 +
| optional
 +
| "2.16.840.1.113883.5.1"
 +
 
 
|-
 
|-
| bgcolor="ccccFF"|custodian||||||
+
|5
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| birthTime
 +
| Geburtsdatum
 +
| TS
 +
| 0..1
 +
| optional
 +
|
 +
 
 
|-
 
|-
| bgcolor="ccccFF"|informationRecipient||||Empfänger: klin./epidem. Krebsregister||1..1
+
|6
|-
+
|bgcolor="88ff88"|ent
| bgcolor="ccccFF"|legalAuthenticator||||unterzeichnender Arzt||1..1
+
| att
|-
+
| @value
| bgcolor="ccccFF"|authenticator||||||
+
| Zeitpunkt
|-
+
| TS
| bgcolor="ccccFF"|participant||||diverse Teilnehmer, d.h. Person bzw. Organisation||0..*
+
| 0..1
|- bgcolor="ffdddd"
+
|
| bgcolor="ffdddd"|'''Act Relationship'''||||||
+
| tagesgenau
|-
 
| bgcolor="ffdddd"|inFullfillmentOf||||||
 
|-
 
| bgcolor="ffdddd"|documentationOf||||||
 
|-
 
| bgcolor="ffdddd"|relatedDocuments||||||
 
|-
 
| bgcolor="ffdddd"|authorization||||||
 
|-
 
| bgcolor="ffdddd"|componentOf||||||
 
|-
 
| bgcolor="ffdddd"|component||||||
 
|-
 
|}
 
Tabelle 4: Dokumentenstruktur (-bestandteile)
 
  
==Meldeanlässe und Inhalte==
 
Grundsätze:
 
* Eine Meldung sollte dann ausgelöst werden, wenn eine Betreuungsepisode beendet und alle zu verantwortenden Informationen verfügbar sind.
 
* Grundsätzlich werden nur die Inhalte übermittelt, die mit eigenen diagnostischen oder therapeutischen Maßnahmen zusammenhängen. Davon sollte nur abge¬wichen werden, wenn andernfalls Lücken in der Erfassung auftreten würden.
 
  
Beispiel:
+
|-
Grundsätzlich ist eine chirurgische Abteilung verantwortlich für die Darstellung der operativen Therapie, des Therapieerfolgs und der Komplikationen. Informationen über eine außerhäusige Diagnosestellung müssten nur insofern übermittelt werden, dass das empfangende System in der Lage ist, die Therapie korrekt einem Tumor zuzuordnen. Wenn bekannt ist, dass dies aus irgendeinem Grund regelhaft nicht funktioniert oder vereinbart wurde, dass diese Informationen im Rahmen der operativen Therapie übermittelt werden sollen, hat die chirurgische Abteilung diese Eingabe zu verantworten.
+
|4
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| providerOrganisation
 +
| Krankenhaus
 +
|
 +
| 0..1
 +
|
 +
|derzeit nicht notwendig
 +
 
 +
|}
 +
 
 +
<syntaxhighlight lang="XML">
 +
<recordTarget>
 +
...
 +
</recordTarget>
 +
</syntaxhighlight>
 +
 
 +
===Participant: Melder (author)===
 +
 
 +
[[file:Cdaonk_melder.gif|Melder]]
 +
 
 +
Abbildung 16: Melder
  
Nachfolgend eine Liste der Meldeanlässe:
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 +
! Lvl
 +
! RIM
 +
! AE
 +
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
 +
 
|-
 
|-
!Code !! Anlass !! Details
+
|0
|-
+
|bgcolor="ff8888"|act
 +
|elm
 +
|ClinicalDocument
 +
|
 +
|
 +
|
 
|
 
|
|Diagnose
 
 
|
 
|
* Feststellen einer bösartigen Diagnose
 
** Diagnosedatum, Tumorlokalisation, Histologie, Metastasierung
 
** ggf. klinischer TNM oder anderes Stagingsystem
 
* Abschluss der erweiterten Diagnostik, ggf. Therapieplanung / Tumorkonferenz
 
** klinischer TNM oder anderes Stagingsystem
 
  
 
|-
 
|-
|
+
| 1
|Operative Therapie
+
|bgcolor="ccffff"| part
|
+
| elm
* Durchführen der Maßnahme
+
| author
** Datum, OPS-Codes, OP-Bereich
+
| Autor
** OP-Resultat (pTNM, R-Klassifikation)
+
|
** Komplikationen während des stationären Aufenthalts
+
| 1..1
* operative Nachschau
+
| M
** 30-Tage Morbidität (Komplikationen) (/Mortalität)
+
| Melder
  
 
|-
 
|-
|
+
| 2
|Strahlentherapie
+
|bgcolor="ccffff"| part
|
+
| att
* Einleiten der Strahlentherapie
+
| @typeCode
** Beginn, Zielgebiete / Bestrahlungsbereich, Intention, Stellung im Gesamtplan
+
| "AUT"
* Beenden der Strahlentherapie
+
| CD CNE
** Endedatum und -status, Dosis, Nebenwirkungen
+
| 1..1
* Nachschau der Strahlentherapie
+
| M
** Therapieerfolg
+
|
** Kurzfristige und langfristige Nebenwirkungen
 
  
 
|-
 
|-
|
+
| 2
|Systemische Therapie
+
|bgcolor="ccffff"| part
|
+
| elm
* Einleiten der systemischen Therapie
+
| time
** Beginn, Art, Protokoll, Intention, Stellung im Gesamtplan
+
| Zeitpunkt der Erstellung des Dokuments
* Beenden der systemischen Therapie
+
| TS
** Endedatum und -status, ggf. Dosierungen, Nebenwirkungen
+
| 1..1
 +
| M
 +
|
  
 
|-
 
|-
|
+
| 3
|Verlauf
+
|bgcolor="ccffff"| part
|
+
| att
* Datum, Tumorstatus, Metastasierung
+
| @value
 +
| Zeitpunkt der Erstellung des Dokuments
 +
| TS
 +
| 1..1
 +
| M
 +
|
  
 
|-
 
|-
|
+
| 2
|Life-Status (Meldeamt)
+
|bgcolor="ffff88"| role
|
+
| elm
* Datum "lebt" oder Sterbedatum
+
| assignedAuthor
* ggf. aktuelle Adresse bzw. Wegzugdatum
+
| Melder
 
+
|
 +
| 1..1
 +
| M
 +
| Informationen über den Melder
  
 
|-
 
|-
|
+
| 3
|Sterbemeldung (Gesundheitsamt, Epid. Register)
+
|bgcolor="ffff88"| role
|
+
| att
* Sterbedatum, Todesursachen
+
| @classCode
* Ggf. Krebs-Tod-Relation
+
| "ASSIGNED"
|}
+
|
 +
| 1..1
 +
| M
 +
|  
  
Die Meldeanlässe und Inhalte können je nach Umfang und Länge des überschauten Zeitraum und ggf. dem vorgesehenen Empfänger kombiniert werden. Dies betrifft insbesondere auch den Abgleich von Tumordokumentationssystemen unterschiedlicher Stufen (z.B. Spezialsystemen in Organzentren und regionalen Krebsregistern)
+
|-
 +
| 3
 +
|bgcolor="ffff88"| role
 +
| elm
 +
| id
 +
| Melder-ID der Person/System
 +
| SET<II>
 +
| 1..1
 +
| M
 +
| Grundsätzlich kann über eine Wiederholung auch mehrere IDs untergebracht werden, deren Semantik sich dann aus der zugeordneten OID ergibt.<br>
 +
Die ID kommt hier hin, wenn es sich beim Melder um ein System oder eine Person handelt.
  
==Dokumenttypen==
+
|-
Nachfolgende Tabelle regelt, welche Abschnitte die verschiedenen Dokumenttypen zu den jweweiligen Meldeanlässen enthalten, jeweils mit Optionalität und Kardinalität:
+
| 4
 +
|bgcolor="ffff88"| role
 +
| att
 +
| @extension
 +
| eigentliche Identifikationsnummer
 +
| ST
 +
| 1..1
 +
| M
 +
|An dieser Stelle wird die ID des Melders untergebracht.
  
Die Template-ID ist ein technischer Identifikator für die Inhalte in diesem Dokument, während der Dokumententyp ein Code aus einem Vokabular darstellt. Zwischen beiden existiert folgende Korrelation:
+
|-
 +
| 4
 +
|bgcolor="ffff88"| role
 +
| att
 +
| @root
 +
| OID zur ID  
 +
| ST
 +
| 1..1
 +
| M
 +
|Hier kommt die dazugehörige OID hin.
  
{| class="hl7table"
 
!Dokumententyp!!Beschreibung!!Deok.-Template-ID
 
 
|-
 
|-
|Diagnose-Meldung|| ||1.2.276.0.76.3.1.131.1.10.1.1
+
|3
|-
+
|bgcolor="88ff88"|ent
|Therapie-Meldung|| ||1.2.276.0.76.3.1.131.1.10.1.2
+
| elm
 +
| assigendPerson
 +
|  
 +
|  
 +
| 0..1
 +
|
 +
|Wenn es sich bei dem Melder um eine Person handelt, so ist diese hier anzugeben.
 +
 
 
|-
 
|-
|Verlaufs-Meldung|| ||1.2.276.0.76.3.1.131.1.10.1.3
+
|4
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| name
 +
| Name des Melders
 +
| SET<PN>
 +
| 0..*
 +
|
 +
|
 +
 
 
|-
 
|-
|Abschluss-Meldung|| ||1.2.276.0.76.3.1.131.1.10.1.4
+
|3
|}
+
|bgcolor="88ff88"|ent
Tabelle 6: Dokumententyp
+
| elm
 +
| AuthoringDevice
 +
|  
 +
|  
 +
| 0..1
 +
|  
 +
|
  
 +
|-
 +
|3
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| representedOrganisation
 +
|
 +
|
 +
| 0..1
 +
|
 +
|meldende Einrichtung, falls es sich bei dem Melder um eine Organisation handelt oder Informationen über das Krankenhaus übermittelt werden sollen.
  
{| class="hl7table"
 
!!!colspan=2|Diagnose!!colspan=2|Therapie!!colspan=2|Verlauf!!colspan=2|Abschluss!!
 
 
|-
 
|-
!Sektion||Opt.||Kard.||Opt.||Kard.||Opt.||Kard.||Opt.||Kard.||Template ID
+
| 4
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| id
 +
| Melder-ID der Einrichtung
 +
| SET<II>
 +
| 0..1
 +
| M
 +
| Hier kommt die ID der Organisation hin, wenn der Melder eine Organisation ist,
 +
 
 
|-
 
|-
|Nationalität||||||||||||||||||TODO
+
| 5
 +
|bgcolor="88ff88"|ent
 +
| att
 +
| @extension
 +
| eigentliche Identifikationsnummer
 +
| ST
 +
| 1..1
 +
| M
 +
|Melder im Sinne des KRBW ist die durchführende Einrichtung, d.h. doch der (originale) Provider der Daten. Es handelt um eine Organisation(seinheit); eigentlich um die Kombination Organisation und Instanz des Dokumentssystems.
 +
 
 +
 
 
|-
 
|-
|Meldebegründungsdaten||R||1..1||R||1..1||R||1..1||R||1..1||TODO
+
| 5
 +
|bgcolor="88ff88"|ent
 +
| att
 +
| @root
 +
| OID zur ID
 +
| ST
 +
| 1..1
 +
| M
 +
|Hier kommt die dazugehörige OID desjenigen hin, der die ID vergeben hat.
 +
 
 
|-
 
|-
|Erkrankungsdaten||R||1..1||R||1..1||R||1..1||R||1..1||TODO
+
|4
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| name
 +
| Name der Org./Einrichtung
 +
| SET<ON>
 +
| 0..1
 +
|  
 +
|
 +
 
 
|-
 
|-
|Diagnostik||R||1..1|||||||||||||||TODO
+
|4
|-
+
|bgcolor="88ff88"|ent
|Phänomendaten: Primär||R||1..1||||||||||||||TODO
+
| elm
|-
+
| telecom
|Phänomendaten: Metastasen||O||0..*||||||O||0..*||||||TODO
+
| Kontaktinformation der Org./Einrichtung
|-
+
| SET<TEL>
|Operation||||||R||0..*||||||||||TODO
+
| 0..1
|-
+
|  
|Strahlentherapie||||||R||0..*||||||||||TODO
+
|
|-
+
 
|systemische Therapie||||||R||0..*||||||||||TODO
+
 
|-
+
 
|Medikation||||||||||||||||||vgl. Arztbrief 2012
 
|-
 
|Status (Nachsorge und andere Follow-Up)||||||||||R||1..1||R||1..1||TODO
 
|-
 
|Studiendaten||O||0..*||O||0..*||O||0..*||||||TODO
 
|-
 
|Abschlussdaten||||||||||||||R||1..*||TODO
 
|-
 
|Planung||||||||||O||||O||||TODO
 
 
|-
 
|-
 +
|4
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| addr
 +
| Adresse der Org./Einrichtung
 +
| SET<AD>
 +
| 0..1
 +
|
 +
|
 +
 
|}
 
|}
Tabelle 4: Dokumenttypen mit Zuordnung der Sektionen
 
  
{{FAQBox|
 
Was ist hiermit
 
*Life-Status
 
*Sterbemeldung
 
}}
 
  
{{FAQBox|
+
<syntaxhighlight lang="xml">
Bei der Therapie muss einer der folgende Abschnitte vorhanden sein:
+
<author>
*Operation
+
<time value="2000040714"/>
*Strahlentherapie
+
<assignedAuthor>
*systemische Therapie
+
<id extension="KP00017" root="2.16.840.1.113883.19.5"/>
}}
+
<assignedPerson>
 +
<name>
 +
<prefix>Dr.</prefix>
 +
<family>Dolin</family>
 +
<given>Robert</given>
 +
</name>
 +
</assignedPerson>
 +
<representedOrganization>
 +
<id root="2.16.840.1.113883.19.5"/>
 +
</representedOrganization>
 +
</assignedAuthor>
 +
</author>
 +
</syntaxhighlight>
 +
 
  
==Korrekturmeldung==
+
===Participant: med. Dokumentar (dataEnterer)===
{{AlertBox|
 
Anm.: Eine Korrekturmeldung ist kein eigener Dokumenttyp, sondern wird als Korrektur einer entsprechenden Meldung gehandhabt. Damit muss das empfangende System bereits erhaltene Daten korrigieren, weil sich an den vorherigen Informationen etwas als falsch herausgestellt hat.
 
Eine Differenzierung zwischen Folge- und Korrekturmeldung ist nicht immer klar möglich. Aus diesem Grund wird nicht differentiell übermittelt, sondern immer das komplette Dokument. Innerhalb des kompletten Dokumentes kann dann über Identifikatoren erfolgen.
 
}}
 
  
==Header==
+
Diese Information gibt an, wer die Information in das System eingegeben hat. Üblicherweise ist das dann der medizinische Dokumentar. Dieser Abschnitt ist optional.
Der Header enthält alle relevanten Metadaten. Nachfolgend der allgemeine Aufbau:
 
  
 
{| class="hl7table"
 
{| class="hl7table"
!Abschnitt!!Kard.!!Klasse!!Referenz auf Abschnitt
+
! Lvl
 +
! RIM
 +
! AE
 +
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
 +
 
 +
 
 
|-
 
|-
|'''Header'''|| || ||
+
|1
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|Metadaten|| || ||
+
| 2
 +
|bgcolor="ffaaaa"| rel
 +
| elm
 +
|  
 +
|  
 +
|  
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|Autor (Melder)|| || ||
+
| 1
 +
|bgcolor="ccffff"| part
 +
| elm
 +
| Participant
 +
| Versicherung
 +
| 0..*
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|Unterzeichner|| || ||
+
| 2
 +
|bgcolor="ffff88"| role
 +
| elm
 +
|  
 +
|  
 +
|  
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|Patient|| || ||
+
|4
|-
+
|bgcolor="88ff88"|ent
|Empfänger|| || ||
+
| elm
|-
+
|  
|Participant|| || ||
+
|  
|-
+
|  
| &nbsp; || ||Versicherung||
+
|  
|-
+
|  
|'''Body'''|| || ||
+
|
|-
+
 
|Sektionen s.u. || || ||
 
 
|}
 
|}
  
===Metadaten===
 
  
Zuerst die Metadaten:
+
???
 +
 
 +
===Participant: Melder (informant)===
 +
Melder im Sinne des Worgebrauchs durch die Register.
 +
 
 +
===Participant: Absender (custodian)===
 +
 
 +
Wer hat das Dokument abgeschickt. Das ist üblicherweise entweder das Krankenhaus oder das Tumorzentrum.
 +
 
 +
Normalerweise wird das über die Transportinformation gelöst. Wenn das aber persistent mit Bestandteil des Dokumentes sein soll, dann ist der Custodian der beste Platz, weil der "Verwalter" des Dokumentes dann auch am ehesten der  "Absender" ist.
  
[[file:Cdaonk_dokheader.gif|ID des Patienten]]
 
  
Abbildung 15a: Header des Dokuments
+
[[file:Cdaonk_custodian.gif|Absender]]
 +
 +
Abbildung 17: Identifikation des Absender
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 1.075: Zeile 1.583:
  
 
|-
 
|-
|1
+
|0
 
|bgcolor="ff8888"|act
 
|bgcolor="ff8888"|act
 
|elm
 
|elm
 
|ClinicalDocument
 
|ClinicalDocument
|Dokument
 
 
|
 
|
|1..1
+
|
|M
+
|
 +
|
 +
|
  
 
|-
 
|-
|2
+
| 1
|bgcolor="ff8888"|act
+
|bgcolor="ccffff"| part
|elm
+
| elm
|realmCode
+
| custodian
|"DE"
+
| Absender
|ST
+
|  
|1..1
+
| 1..1
|M
+
| M
|fix
+
| Wer hat das Dokument abgeschickt.
  
 
|-
 
|-
|2
+
| 2
|bgcolor="ff8888"|act
+
|bgcolor="ccffff"| part
|elm
+
| att
|typeID
+
| typeCode
|
+
| "CST"
|ST
+
| CD CNE
|1..1
+
| 1..1
|M
+
| M
|fix
+
|  
  
 
|-
 
|-
|3
+
| 2
|bgcolor="ff8888"|act
+
|bgcolor="ffff88"| role
|att
+
| elm
|@root
+
| assignedCustodian
|2.16.840.1.113883.1.3
+
|  
|ST
+
|  
|1..1
+
| 1..1
|M
+
| M
|fix
+
|
  
 
|-
 
|-
|3
+
| 3
|bgcolor="ff8888"|act
+
|bgcolor="ffff88"| role
|att
+
| att
|@extension
+
| classCode
|POCD_HD000040
+
| "ASSIGNED"
|ST
+
|  
|1..1
+
| 1..1
|M
+
| M
|Diese Kennung ist fix und identifiziert dieses Dokument als CDA-Dokument.
+
|  
 +
 
  
|-
 
|2
 
|bgcolor="ff8888"|act
 
|elm
 
|templateId
 
|Strukturidentifikation des Dokuments
 
|II
 
|1..1
 
|M
 
|In diesem Element wird die Strukturbeschreibung des Dokumentes festgehalten.
 
  
 
|-
 
|-
|3
+
|4
|bgcolor="ff8888"|act
+
|bgcolor="88ff88"|ent
|att
+
| elm
|@root
+
| representedCustodianOrganisation
|OID des Templates
+
| verwaltende/absendede Organisation
|
+
|  
|1..1
+
| 0..1
|M
+
|  
 
|
 
|
  
 
|-
 
|-
|2
+
|5
|bgcolor="ff8888"|act
+
|bgcolor="88ff88"|ent
|elm
+
| elm
|Id
+
| id
|Identifikation einer Instanz des Dokuments
+
| Identifikation der Organisation
|II
+
| SET<II>
|1..1
+
| 1..*
|M
+
| M
|Dieses Element identifiziert eindeutig eine Instanz eines Dokuments, d.h.jede Version eines Dokumentes hat eine neue ID.<br>
 
(vgl. SetId)
 
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@root
 
|OID
 
 
|
 
|
|1..1
 
|M
 
|Hier muss die OID eingesetzt werden, die das sendende System benutzt, um die Dokumente eindeutig zu identifizieren.
 
  
 
|-
 
|-
|3
+
|6
|bgcolor="ff8888"|act
+
|bgcolor="88ff88"|ent
|att
+
| att
|@extension
+
| @extension
|eigentliche ID
+
| eigentliche ID der Organisation
|ST
+
| ST
|1..1
+
| 1..1
|M
+
| M
 
|
 
|
  
 
|-
 
|-
|2
+
|6
|bgcolor="ff8888"|act
+
|bgcolor="88ff88"|ent
|elm
+
| att
|code
+
| @root
|Dokumenttyp
+
| OID der Organisation
|CE CWE
+
| ST
|1..1
+
| 1..1
|M
+
| M
|s.u.
+
|
  
 
|-
 
|-
|3
+
|5
|bgcolor="ff8888"|act
+
|bgcolor="88ff88"|ent
|att
+
| elm
|@code
+
| name
|Dokumenttyp
+
| Name der Organisation
|"x-physician-cancer-reg"
+
| ON
|1..1
+
| 0..1
|M
+
|  
|s.u. und vgl. IHE PCC Vol.2 Abschnitt 6.3.1.A.2
+
|
  
 
|-
 
|-
|3
+
|5
|bgcolor="ff8888"|act
+
|bgcolor="88ff88"|ent
|att
+
| elm
|@codeSystem
+
| telecom
|Dokumenttyp
+
| Kontaktinformation der Organisation
|"2.16.840.1.113883.6.1"
+
| TEL
|1..1
+
| 0..1
|M
+
|  
|s.u.
+
|
  
 
|-
 
|-
|2
+
|5
|bgcolor="ff8888"|act
+
|bgcolor="88ff88"|ent
|elm
+
| elm
|title
+
| addr
|Titel des Dokuments
+
| Adresse der Organisation
|ST
+
| AD
|0..1
+
| 0..1
|M
+
|  
|Der Titel des Dokuments ergibt sich aus dem Dokumenttyp bzw. Dokumententemplate.<br>
 
Beispiel "Diagnosemeldung"
 
 
 
|-
 
|2
 
|bgcolor="ff8888"|act
 
|elm
 
|effectiveTime
 
|Erstellungszeitpunkt des Dokuments
 
|TS
 
|1..1
 
|M
 
 
|
 
|
  
|-
+
|}
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@value
 
|eigentlicher Zeitpunkt
 
|TS
 
|1..1
 
|M
 
|
 
  
|-
+
<syntaxhighlight lang="xml">
|2
+
<custodian>
|bgcolor="ff8888"|act
+
<assignedCustodian>
 +
<representedCustodianOrganization>
 +
<id root="2.16.840.1.113883.19.5"/>
 +
<name>Good Health Clinic</name>
 +
</representedCustodianOrganization>
 +
</assignedCustodian>
 +
</custodian>
 +
</syntaxhighlight>
 +
 
 +
===Participant: Empfänger (informationRecipient)===
 +
Als Empfänger kommen hier sowohl die Krebsregister als auch Praxen und Krankenhäuser in Frage.
 +
 
 +
 
 +
In dem Attribut „informationRecipient" wird angegeben, an welches Krebsregister oder Praxis/Krankenhaus die Daten übermittelt werden. Hier wird die „scoping" Entität „Organisation" (gestrichelte Linie) genutzt.
 +
 
 +
[[file:Cdaonk_empfaenger.gif|ID des Empfängers]]
 +
 +
Abbildung 17: Identifikation des Empfängers
 +
 
 +
{| class="hl7table"
 +
! Lvl
 +
! RIM
 +
! AE
 +
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
 +
 
 +
|-
 +
|0
 +
|bgcolor="ff8888"|act
 
|elm
 
|elm
|confidentialityCode
+
|ClinicalDocument
|Vertaulichkeit des Dokumentes
+
|
|CE CWE
+
|
|1..1
+
|
|M
+
|
 
|
 
|
  
 
|-
 
|-
|3
+
| 1
|bgcolor="ff8888"|act
+
|bgcolor="ccffff"| part
|att
+
| elm
|@code
+
| informationRecipient
|Code für die Vertaulichkeit
+
| Empfänger
|CE CWE
+
|  
|1..1
+
| 0..*
|M
+
| optional
|"N", s.u.
+
|  
  
 
|-
 
|-
|3
+
| 2
|bgcolor="ff8888"|act
+
|bgcolor="ccffff"| part
|att
+
| att
|@codeSystem
+
| typeCode
|Codesystem für die Vertaulichkeit
+
| ""
|
+
| CD CNE
|1..1
+
| 1..1
|M
+
| M
|fix: "2.16.840.1.113883.5.25"
+
|  
  
 
|-
 
|-
|2
+
| 2
|bgcolor="ff8888"|act
+
|bgcolor="ffff88"| role
|elm
+
| elm
|languageCode
+
| IntendedRecipient
|Sprache des Dokumentes
+
|  
|CS CNE
+
|  
|0..1
+
| 0..*
|opt.
+
| M
|
+
|
  
 
|-
 
|-
|2
+
| 3
|bgcolor="ff8888"|act
+
|bgcolor="ffff88"| role
|elm
+
| att
|setId
+
| classCode
|Setkennung
+
|
|II
+
|  
|0..1
+
| 1..1
|
+
| M
|Dieses Element legt fest, zu welcher „Menge" das Dokument gehört. Es hält also die verschiedenen Versionen (Instanzen, vgl .Id) zusammen.
+
|  
Logische Kennung des Dokuments, die über die Versionen hinweg konstant bleibt. Eine Korrektur ergibt sich aus einer höheren Versionsnummer.
 
  
 
|-
 
|-
|3
+
| 3
|bgcolor="ff8888"|act
+
|bgcolor="ffff88"| role
|att
+
| att
|@root
+
| id
|OID
+
| Register-ID
|
+
| SET<II>
|1..1
+
| 0..*
|M
+
| M
|Hier muss die OID eingesetzt werden, die das sendende System benutzt, um das Dokument-Set eindeutig zu identifizieren.
+
|  
  
 
|-
 
|-
|3
+
|4
|bgcolor="ff8888"|act
+
|bgcolor="88ff88"|ent
|att
+
| elm
|@extension
+
| informationRecipient
|eigentliche ID
+
|  
|ST
+
|  
|1..1
+
| 0..1
|M
+
| optional
 
|
 
|
  
|-
 
|2
 
|bgcolor="ff8888"|act
 
|elm
 
|versionNumber
 
|Versionsnummer
 
|INT
 
|1..1
 
|M
 
|Eine fortlaufende Nummer zur Versionierung des Dokumentes.
 
  
 
|-
 
|-
|3
+
|5
|bgcolor="ff8888"|act
+
|bgcolor="88ff88"|ent
|att
 
|@value
 
|Versionsnummer
 
|INT
 
|1..1
 
|
 
|Zusammen mit der Setkennung regelt dieses Element die Versionierung der Dokumente.
 
 
 
|-
 
| 2
 
|bgcolor="ffaaaa"| rel
 
 
| elm
 
| elm
| relatedDocument
+
| Person
 
|  
 
|  
 
|  
 
|  
 
| 0..1
 
| 0..1
|  
+
| optional
 
|
 
|
  
 
|-
 
|-
| 3
+
|6
|bgcolor="ff8888"| act
+
|bgcolor="88ff88"|ent
 
| elm
 
| elm
| parentDocument
+
| name
| ParentDocument
+
| Name der Person
 +
| SET<PN>
 +
| 0..*
 +
| optional
 +
|
 +
 
 +
|-
 +
|4
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| receivedOrganisation
 
|  
 
|  
| 1..1
 
| required
 
 
|  
 
|  
 +
| 0..1
 +
| optional
 +
|
 +
  
 
|-
 
|-
| 4
+
|5
|bgcolor="ff8888"| act
+
|bgcolor="88ff88"|ent
 
| elm
 
| elm
| id
+
| Organisation
| ID des Document
 
 
|  
 
|  
| 1..1
 
| required
 
 
|  
 
|  
 +
| 0..1
 +
| optional
 +
|
  
 +
|-
 +
|6
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| name
 +
| Name der Organisation
 +
| SET<ON>
 +
| 0..*
 +
| optional
 +
|
 
|}
 
|}
 +
 +
 +
===Participant: Versicherung (participant)===
  
 
{| class="hl7table"
 
{| class="hl7table"
|-
+
! Lvl
!Code!!Beschreibung
+
! RIM
|-
+
! AE
|34806-0||Oncology Note
+
! Name
|-
+
! Desc
|x-physician-cancer-rep||Report to Cancer Registries
+
! DT
|}
+
! Kard
Tabelle: Dokumenttyp
+
! Conf
 +
! Beschreibung
 +
 
  
{| class="hl7table"
 
 
|-
 
|-
!Code!!Beschreibung
+
|1
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|N||normal
+
| 2
|}
+
|bgcolor="ffaaaa"| rel
Tabelle: Vertraulichkeit (OID: 2.16.840.1.113883.5.25)
+
| elm
 +
|
 +
|  
 +
|  
 +
|  
 +
|
 +
|
  
<syntaxhighlight lang="xml">
+
|-
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd">
+
| 1
<realmCode code="DE"/>
+
|bgcolor="ccffff"| part
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
+
| elm
<templateId root="1.2.276.0.76.3.1.131.1.10.1.1"/>
+
| Participant
<id extension="xyz" root="OID"/>
+
| Versicherung
<code code="x-physician-cancer-rep" codeSystem="2.16.840.1.113883.6.1" displayName="report to cancer registry"/>
+
| 0..*
<title>Diagnosemeldung</title>
+
|
<effectiveTime value="20120407130000+0500"/>
+
|
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
+
|
<languageCode code="de-DE"/>
 
  
...
+
|-
 +
| 2
 +
|bgcolor="ffff88"| role
 +
| elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
  
</ClinicalDocument>
+
|-
</syntaxhighlight>
+
|4
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
  
===Participants: Einleitung===
+
|}
  
An der Erstellung eines Dokumentes sind mehrere Personen bzw. Organisationen und Systeme beteiligt. Dies soll hier einmal kurz erläutert werden, damit die anschließende Detaildarstellung verständlicher wird. Dies wird in Form verschiedener Situationen gemacht:
 
  
====Variante 1====
+
???
Der Arzt erstellt einen Arztbrief, aus dem ein med.Dokumentar die Informationen in ein System eingibt, das dann die Meldung abschickt:
 
  
*Arzt = informant
+
==Allgemeiner Aufbau des Body==
*med.Dokumentar = dataEnterer (optional)
+
An dieser Stelle sei auf den VHitG-Arztbrief verwiesen.
*System/Tumordokumentationssystem = authoringDevice
 
*System betreibende Organisation = Custodian
 
*Tumorregister = informationRecipient (optional)
 
 
 
====Variante 2====
 
Ein regionales Register erstellt auf Basis der eingegangenen Meldungen eine neue Meldung an das Landeskrebsregister:
 
 
 
*Arzt der ursprüngl. Meldung (jetzt ggf. mehrere) = informant
 
*med.Dokumentar im reg. Reg. = dataEnterer (optional)
 
*Tumordokumentationssystem = authoringDevice
 
*System betreibende Organisation (regionale Register) = Custodian
 
*Landeskrebsregister = informationRecipient (optional)
 
 
 
 
 
===Participant: Patient (recordTarget)===
 
 
 
 
 
[[file:Cdaonk_patient.gif|ID des Patienten]]
 
 
 
Abbildung 15: Identifikation des Patienten
 
  
 +
Abschnitt entspricht Component,
 +
Klasse entspricht Section.
  
 
{| class="hl7table"
 
{| class="hl7table"
! Lvl
+
!Abschnitt!!Kard.!!Klasse!!Referenz auf Abschnitt
! RIM
+
|-
! AE
+
|Header||||||
! Name
+
|-
! Desc
+
|s.o.||||||
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
 
 
 
|-
 
|-
|0
+
|Body||||||
|bgcolor="ff8888"|act
 
|elm
 
|ClinicalDocument
 
|Dokument
 
|
 
|1..1
 
|M
 
 
 
 
|-
 
|-
| 1
+
|'''Meldebegründungdaten'''||0..1||||
|bgcolor="ccffff"| part
+
|-
| elm
+
|||||Meldebegründung||Participant
| recordTarget
+
|-
| Patient
+
|'''Diagnostik'''||0..*||||
|  
 
| 1..1
 
| M
 
| Patient
 
 
 
 
|-
 
|-
| 2
+
|||||Untersuchung||
|bgcolor="ccffff"| part
 
| att
 
| typeCode
 
| "RCT"
 
| CS CNE
 
| 1..1
 
| M
 
| fix
 
 
 
 
|-
 
|-
| 2
+
|||||Ergebnis||
|bgcolor="ffff88"| role
 
| elm
 
| patientRole
 
|  
 
|  
 
| 1..1
 
| M
 
|
 
 
 
 
|-
 
|-
| 3
+
|||||||Phänomen
|bgcolor="ffff88"| role
 
| att
 
| classCode
 
| "PAT"
 
| CS CNE
 
| 1..1
 
| M
 
| fix
 
 
 
 
|-
 
|-
| 3
+
|||||||Erkrankungsdaten
|bgcolor="ffff88"| role
 
| elm
 
| id
 
| Patient-ID: nicht verwendet
 
| SET<II>
 
| 1..*
 
| M
 
|
 
 
 
 
|-
 
|-
| 4
+
|||||Beteiligter||Participant
|bgcolor="ffff88"| role
 
| att
 
| @root
 
| OID
 
|  
 
| 1..1
 
| M
 
| Das ist die OID des sendenden Systems für Patienten.
 
 
 
 
|-
 
|-
| 4
+
|'''Erkrankungsdaten'''||0..*||||
|bgcolor="ffff88"| role
 
| att
 
| @extension
 
| die eigentliche ID
 
| ST
 
| 1..1
 
| M
 
|  
 
 
 
 
|-
 
|-
| 3
+
|||||||Meldebegründungdaten
|bgcolor="ffff88"| role
 
| elm
 
| addr
 
| Adresse
 
| SET<AD>
 
| 0..*
 
|
 
|
 
 
 
{{AlertBox|
 
Es sollte immer eine Adresse übertragen werden. Bei anonymisierten bzw. pseudonymisierten Patienten kann dies auf eine Postleitzahl oder Bundesland reduziert werden.
 
}}
 
 
 
 
|-
 
|-
| 4
+
|||||Erkrankung||
|bgcolor="ffff88"| role
+
|-
| att
+
|||||||Phänomendaten
| @streetname
 
| Strasse
 
|  
 
| 0..1
 
| M
 
|
 
 
 
 
|-
 
|-
| 4
+
|'''Phänomendaten'''||0..*||||
|bgcolor="ffff88"| role
 
| att
 
| @houseNumber
 
| Hausnummer
 
|
 
| 0..1
 
|  
 
|
 
 
 
 
|-
 
|-
| 4
+
|||||Phänomen||
|bgcolor="ffff88"| role
 
| att
 
| @postalCode
 
| Postleitzahl
 
|  
 
| 0..1
 
| M
 
| PLZ ohne Länderkennzeichen
 
 
 
 
|-
 
|-
| 4
+
|'''Operation'''||0..*||||
|bgcolor="ffff88"| role
 
| att
 
| @city
 
| Wohnort
 
|
 
| 0..1
 
| M
 
|  
 
 
 
 
|-
 
|-
| 4
+
|||||Beteiligter||Participant
|bgcolor="ffff88"| role
+
|-
| att
+
|||||Operative Therapie||
| @country
+
|-
| Land
+
|||||||Erkrankungsdaten
|  
+
|-
| 0..1
+
|||||||Phänomendaten
| M
+
|-
|  
+
|'''Bestrahlung'''||0..*||||
 
 
 
|-
 
|-
| 3
+
|||||Beteiligter||Participant
|bgcolor="ffff88"| role
 
| elm
 
| telecom
 
| Kontaktinformationen
 
| SET<TEL>
 
| 0..*
 
| M
 
|
 
 
 
 
|-
 
|-
|4
+
|||||Strahlentherapie||
|bgcolor="88ff88"|ent
 
| elm
 
| patient
 
| Patient
 
|  
 
| 0..1
 
| optional
 
|
 
 
 
 
|-
 
|-
|5
+
|||||||Erkrankungsdaten
|bgcolor="88ff88"|ent
+
|-
| elm
+
|||||||Phänomendaten
| name
 
| Name des
 
| SET<PN>
 
| 0..*
 
| optional
 
|Folgende Pseudonyme werden vorgesehen:
 
# Umkehrbar eindeutige Pseudonyme (Angabe von Identifikator + Quellsystem), z.B. Identifikation über Nachsorgepass Bayern, Identifikation im Tumorzentrum Xy, Identifikation in Organzentrumssystem Xyz => OID mit Extension!
 
# „Stochastische Pseudonyme" (Kontrollnummern)
 
Bestimmte Attribute wie Namen oder Geburtsdatum sind dann optional, die dann in ganz definierten Kommunikationskontexten durch Kontrollnummern ersetzt werden.
 
Die Identifikatoren unter 1. wären in jedem Fall sinnvoll für das automatisierte Record Linkage im Zielsystem, wenn es hier nicht geht, dann woanders
 
 
 
{{AlertBox|
 
Anonymisierung bzw. Pseudonymisierung der ID, des Namens, Adresse etc.<br>
 
Es ist zu klären, welche Informationen neben den klassischen wie „Name", „Geburtsdatum" und „Adresse" pseudonymisiert werden müssen.
 
}}
 
 
 
 
|-
 
|-
|6
+
|||||Einzelbestrahlung||
|bgcolor="88ff88"|ent
 
| elm
 
| prefix
 
| Anrede
 
| ST
 
| 0..1
 
| optional
 
| Anrede: Herr, Frau, ..
 
 
 
 
|-
 
|-
|6
+
|'''Medikamentendaten'''||0..*||||
|bgcolor="88ff88"|ent
 
| elm
 
| prefix
 
| Titel
 
| ST
 
| 0..1
 
| optional
 
| akademischer Titel
 
 
 
 
|-
 
|-
|7
+
|||||Einzelgabe||
|bgcolor="88ff88"|ent
 
| att
 
| @qualifier
 
| "AC"
 
| ST
 
| 0..1
 
| optional
 
| Qualifier für akademischen Titel
 
 
 
 
|-
 
|-
|6
+
|||||Dauergabe||
|bgcolor="88ff88"|ent
+
|-
| elm
+
|'''Systemisch'''||0..*||||
| given
 
| Vorname
 
| ST
 
| 0..*
 
| optional
 
| Vornamen
 
 
 
 
|-
 
|-
|6
+
|||||Beteiligter||Participant
|bgcolor="88ff88"|ent
 
| elm
 
| familiy
 
| Familienname
 
| ST
 
| 0..*
 
| optional
 
| Familienname
 
 
 
 
|-
 
|-
|6
+
|||||Systemtherapie||
|bgcolor="88ff88"|ent
 
| elm
 
| familiy
 
| Geburtsname
 
| ST
 
| 0..*
 
| optional
 
|
 
 
 
 
|-
 
|-
|7
+
|||||||Erkrankungsdaten
|bgcolor="88ff88"|ent
 
| att
 
| @qualifier
 
| "BR"
 
| ST
 
| 0..1
 
| optional
 
| Qualifier für Geburtsname
 
 
 
 
|-
 
|-
|5
+
|||||||Phänomendaten
|bgcolor="88ff88"|ent
+
|-
| elm
+
|||||Zyklus||
| administrativeGenderCode
 
| Geschlecht
 
| CE CWE
 
| 0..1
 
| optional
 
|Mit diesem Attribut wird das Geschlecht des Patienten übertragen.
 
 
 
 
|-
 
|-
|6
+
|||||Zyklustag||
|bgcolor="88ff88"|ent
 
| att
 
| @code
 
| Code für das Geschlecht
 
|  
 
| 0..1
 
| optional
 
|
 
 
 
 
|-
 
|-
|6
+
|||||||Medikamentendaten
|bgcolor="88ff88"|ent
 
| att
 
| @codeSystem
 
| Codesystem für das Geschlecht
 
|  
 
| 0..1
 
| optional
 
| "2.16.840.1.113883.5.1"
 
 
 
 
|-
 
|-
|5
+
|'''Status (Nachsorge und anderes Follow-up)'''||0..*||||
|bgcolor="88ff88"|ent
 
| elm
 
| birthTime
 
| Geburtsdatum
 
| TS
 
| 0..1
 
| optional
 
|
 
 
 
 
|-
 
|-
|6
+
|||||Prozedur||
|bgcolor="88ff88"|ent
 
| att
 
| @value
 
| Zeitpunkt
 
| TS
 
| 0..1
 
|
 
| tagesgenau
 
 
 
 
 
 
|-
 
|-
|4
+
|||||Ergebnis||
|bgcolor="88ff88"|ent
 
| elm
 
| providerOrganisation
 
| Krankenhaus
 
|  
 
| 0..1
 
|
 
|derzeit nicht notwendig
 
 
 
|}
 
 
 
<syntaxhighlight lang="XML">
 
<recordTarget>
 
...
 
</recordTarget>
 
</syntaxhighlight>
 
 
 
===Participant: Melder (author)===
 
 
 
[[file:Cdaonk_melder.gif|Melder]]
 
 
 
Abbildung 16: Melder
 
 
 
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
 
|-
 
|-
|0
+
|||||||Erkrankungsdaten
|bgcolor="ff8888"|act
+
|-
|elm
+
|||||||Phänomendaten
|ClinicalDocument
 
|
 
|
 
|
 
|
 
|
 
 
 
 
|-
 
|-
| 1
+
|'''Studiendaten'''||0..*||||
|bgcolor="ccffff"| part
 
| elm
 
| author
 
| Autor
 
|
 
| 1..1
 
| M
 
| Melder
 
 
 
 
|-
 
|-
| 2
+
|||||Studie||
|bgcolor="ccffff"| part
 
| att
 
| @typeCode
 
| "AUT"
 
| CD CNE
 
| 1..1
 
| M
 
|
 
 
 
 
|-
 
|-
| 2
+
|||||||Erkrankungsdaten
|bgcolor="ccffff"| part
 
| elm
 
| time
 
| Zeitpunkt der Erstellung des Dokuments
 
| TS
 
| 1..1
 
| M
 
|
 
 
 
 
|-
 
|-
| 3
+
|'''Abschlussdaten'''||0..*||||
|bgcolor="ccffff"| part
+
|-
| att
+
|||||Prozedur||
| @value
 
| Zeitpunkt der Erstellung des Dokuments
 
| TS
 
| 1..1
 
| M
 
|  
 
 
 
 
|-
 
|-
| 2
+
|||||Ergebnis||
|bgcolor="ffff88"| role
 
| elm
 
| assignedAuthor
 
| Melder
 
|  
 
| 1..1
 
| M
 
| Informationen über den Melder
 
 
 
 
|-
 
|-
| 3
+
|||||||Erkrankungsdaten
|bgcolor="ffff88"| role
 
| att
 
| @classCode
 
| "ASSIGNED"
 
|  
 
| 1..1
 
| M
 
|
 
 
 
 
|-
 
|-
| 3
+
|'''Planung'''||0..*||||
|bgcolor="ffff88"| role
 
| elm
 
| id
 
| Melder-ID der Person/System
 
| SET<II>
 
| 1..1
 
| M
 
| Grundsätzlich kann über eine Wiederholung auch mehrere IDs untergebracht werden, deren Semantik sich dann aus der zugeordneten OID ergibt.<br>
 
Die ID kommt hier hin, wenn es sich beim Melder um ein System oder eine Person handelt.
 
 
 
 
|-
 
|-
| 4
+
|||||Prozedur||
|bgcolor="ffff88"| role
+
|-
| att
+
|||||Ergebnis||
| @extension
 
| eigentliche Identifikationsnummer
 
| ST
 
| 1..1
 
| M
 
|An dieser Stelle wird die ID des Melders untergebracht.
 
 
 
 
|-
 
|-
| 4
+
|||||||Erkrankungsdaten
|bgcolor="ffff88"| role
 
| att
 
| @root
 
| OID zur ID
 
| ST
 
| 1..1
 
| M
 
|Hier kommt die dazugehörige OID hin.
 
 
 
 
|-
 
|-
|3
+
|||||||Phänomendaten
|bgcolor="88ff88"|ent
 
| elm
 
| assigendPerson
 
|  
 
|  
 
| 0..1
 
|
 
|Wenn es sich bei dem Melder um eine Person handelt, so ist diese hier anzugeben.
 
 
 
 
|-
 
|-
|4
+
|||||||Operation
|bgcolor="88ff88"|ent
 
| elm
 
| name
 
| Name des Melders
 
| SET<PN>
 
| 0..*
 
|
 
|
 
 
 
 
|-
 
|-
|3
+
|||||||Bestrahlung
|bgcolor="88ff88"|ent
+
|-
| elm
+
|||||||Systemisch
| AuthoringDevice
+
|-
|  
+
|||||||Status (Nachsorge und anderes Follow-up)
|  
 
| 0..1
 
|  
 
|
 
 
 
 
|-
 
|-
|3
+
|||||||Studiendaten
|bgcolor="88ff88"|ent
 
| elm
 
| representedOrganisation
 
|  
 
|  
 
| 0..1
 
|
 
|meldende Einrichtung, falls es sich bei dem Melder um eine Organisation handelt oder Informationen über das Krankenhaus übermittelt werden sollen.
 
 
 
 
|-
 
|-
| 4
+
|||||||Diagnostik
|bgcolor="88ff88"|ent
 
| elm
 
| id
 
| Melder-ID der Einrichtung
 
| SET<II>
 
| 0..1
 
| M
 
| Hier kommt die ID der Organisation hin, wenn der Melder eine Organisation ist,
 
 
 
 
|-
 
|-
| 5
+
|}
|bgcolor="88ff88"|ent
+
Tabelle 8: Dokument-Inhalte
| att
+
TODO Abschnitte: Section bekommen eine Template-ID. Die iwird im Rahmenb des OID-Konzepts vergeben: 1.2.276.0.76.3.1.10.? (Deutsche Krebsgesellschaft e.V. …131=DKG, 1=Version des OID-Konzeptes, 10=Template)
| @extension
+
Template Level: Documenmt/Section/Entry
| eigentliche Identifikationsnummer
 
| ST
 
| 1..1
 
| M
 
|Melder im Sinne des KRBW ist die durchführende Einrichtung, d.h. doch der (originale) Provider der Daten. Es handelt um eine Organisation(seinheit); eigentlich um die Kombination Organisation und Instanz des Dokumentssystems.
 
  
  
|-
+
===graphische Übersicht===
| 5
 
|bgcolor="88ff88"|ent
 
| att
 
| @root
 
| OID zur ID
 
| ST
 
| 1..1
 
| M
 
|Hier kommt die dazugehörige OID desjenigen hin, der die ID vergeben hat.
 
  
|-
+
[[file:Cdaonk_abschnittsuebersicht.gif|Abschnittsübersicht]]
|4
+
|bgcolor="88ff88"|ent
+
Abbildung 18: Abschnittsübersicht
| elm
 
| name
 
| Name der Org./Einrichtung
 
| SET<ON>
 
| 0..1
 
|
 
|
 
  
|-
+
==Abschnitte==
|4
+
Nachfolgend werden die einzelnen Abschnitte im Detail erläutert.
|bgcolor="88ff88"|ent
 
| elm
 
| telecom
 
| Kontaktinformation der Org./Einrichtung
 
| SET<TEL>
 
| 0..1
 
|
 
|
 
  
 +
===Nationalität===
  
  
 +
{| class="hl7table"
 +
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 +
|-
 +
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird die Nationalität des Patienten übermittelt.
 
|-
 
|-
|4
+
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
|bgcolor="88ff88"|ent
+
|-
| elm
+
| ???? || O ||
| addr
+
|}
| Adresse der Org./Einrichtung
 
| SET<AD>
 
| 0..1
 
|  
 
|
 
  
|}
+
Value Set: 1.3.6.1.4.1.12559.11.10.1.3.1.42.4
  
 +
Value Set Name: VS11_epSOSCountry
  
<syntaxhighlight lang="xml">
+
Code System: ISO-3166-1
<author>
 
<time value="2000040714"/>
 
<assignedAuthor>
 
<id extension="KP00017" root="2.16.840.1.113883.19.5"/>
 
<assignedPerson>
 
<name>
 
<prefix>Dr.</prefix>
 
<family>Dolin</family>
 
<given>Robert</given>
 
</name>
 
</assignedPerson>
 
<representedOrganization>
 
<id root="2.16.840.1.113883.19.5"/>
 
</representedOrganization>
 
</assignedAuthor>
 
</author>
 
</syntaxhighlight>
 
  
 +
{{AlertBox|
 +
Modelliert man das über eine Sektion "Nationalität" oder als Teil einer allgemeineren Sektion "zusätzliche Patientendaten".<br> TODO!!!
 +
}}
  
===Participant: med. Dokumentar (dataEnterer)===
+
===Sterbedatum===
  
Diese Information gibt an, wer die Information in das System eingegeben hat. Üblicherweise ist das dann der medizinische Dokumentar. Dieser Abschnitt ist optional.
 
  
 
{| class="hl7table"
 
{| class="hl7table"
! Lvl
+
|bgcolor="ddddff"|Template ID|| colspan=2 | IHE PCC Health Status 1.3.6.1.4.1.19376.1.5.3.1.4.1.2
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
 
 
 
|-
 
|-
|1
+
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird der Gesundheitszustand des Patienten übermittelt.
|bgcolor="ff8888"|act
+
|-
|elm
+
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
|
 
|
 
|
 
|
 
|
 
|
 
 
 
 
|-
 
|-
| 2
+
| 11323-3 || O || Health Status
|bgcolor="ffaaaa"| rel
+
|}
| elm
 
|  
 
|  
 
|
 
|
 
|  
 
|
 
  
|-
+
Das Sterbedatum ist dann eine konkrete Beobachtung darin.
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
| Participant
 
| Versicherung
 
| 0..*
 
|
 
|
 
|
 
  
|-
+
Die folgenden Snomed CT Codes (vgl. IHE PCC Vol.2 6.3.4.5.8) stehen zur Verfügung:
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
  
 +
{| class="hl7table"
 
|-
 
|-
|4
+
!Code !!Description
|bgcolor="88ff88"|ent
+
|-
| elm
+
|81323004 ||Alive and well
|  
+
|-
|  
+
|313386006 ||In remission
|  
+
|-
|  
+
|162467007 ||Symptom free
|  
+
|-
|
+
|161901003 ||Chronically ill
 
+
|-
 +
|271593001 ||Severely ill
 +
|-
 +
|21134002 ||Disabled
 +
|-
 +
|161045001 ||Severely disabled
 +
|-
 +
|419099009 ||Deceased
 
|}
 
|}
  
  
???
+
<syntaxhighlight lang="xml">
 +
<entry>
 +
<observation classCode='OBS' moodCode='EVN'>
 +
  <entryRelationship typeCode='REFR' inversionInd='false'>
 +
    <observation classCode='OBS' moodCode='EVN'>
 +
      <templateId root='2.16.840.1.113883.10.20.1.51'/>
 +
      <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.1.2'/>
 +
      <code code='11323-3' displayName='Health Status'
 +
            codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC' />
 +
      <text><reference value='#hstatus-2'/></text>
 +
      <statusCode code='completed'/>
 +
      <value xsi:type='CE' code=' ' codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT'/>
 +
    </observation>
 +
  </entryRelationship>
 +
  </observation>
 +
</entry>
 +
</syntaxhighlight>
  
===Participant: Melder (informant)===
+
===Meldebegründungsdaten===
Melder im Sinne des Worgebrauchs durch die Register.
 
  
===Participant: Absender (custodian)===
+
{| class="hl7table"
 +
|bgcolor="ddddff"|Template ID|| colspan=2 |1.2.276.0.76.3.1.131.1.10.2.1
 +
|-
 +
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird die Begründung für die Meldung übermittelt.
 +
|-
 +
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 +
|-
 +
| ???? || O ||
 +
|}
  
Wer hat das Dokument abgeschickt. Das ist üblicherweise entweder das Krankenhaus oder das Tumorzentrum.
+
Eine Meldebegründung gibt den rechtlichen Kontext der Meldung wider. Dies unterscheidet sich von Bundesland zu Bundesland. In Ländern mit Meldepflicht muss der Patient in der Regel informiert werden. Ausnahmen gibt es ggf. wenn der Patient verstorben ist oder ihm eine Mitteilung nicht zugemutet werden kann (oder bei Meldungen von Pathologen). Bei Meldepflicht gibt es grundsätzlich ein Widerspruchsrecht. Bei Meldrecht muss der Patient zustimmen. Weitere Variationen bestehen im Einverständnis zur Nutzung der Daten für weitergehende Forschung. An dieser Stelle sollte auch die Zustimmung zur Meldung ans klinische Krebsregister berücksichtigt werden. Diese kann ggf. zukünftig auch nach unterschiedlichen Nutzungszwecken unterschieden werden.
  
Normalerweise wird das über die Transportinformation gelöst. Wenn das aber persistent mit Bestandteil des Dokumentes sein soll, dann ist der Custodian der beste Platz, weil der "Verwalter" des Dokumentes dann auch am ehesten der  "Absender" ist.
+
[[file:Cdaonk_meldebegruendung.gif|Meldebegründugn]]
  
 +
Abbildung 19: Observation für die Meldebegründung
  
[[file:Cdaonk_custodian.gif|Absender]]
 
 
Abbildung 17: Identifikation des Absender
 
  
 
{| class="hl7table"
 
{| class="hl7table"
Zeile 2.180: Zeile 2.217:
 
! Conf
 
! Conf
 
! Beschreibung  
 
! Beschreibung  
 
|-
 
|0
 
|bgcolor="ff8888"|act
 
|elm
 
|ClinicalDocument
 
|
 
|
 
|
 
|
 
|
 
  
 
|-
 
|-
 
| 1
 
| 1
|bgcolor="ccffff"| part
+
|bgcolor="ff8888"| act
 
| elm
 
| elm
| custodian
+
| section
| Absender
+
|  
 
|  
 
|  
 
| 1..1
 
| 1..1
| M
+
| required
| Wer hat das Dokument abgeschickt.
+
|  
  
 
|-
 
|-
 
| 2
 
| 2
|bgcolor="ccffff"| part
+
|bgcolor="ff8888"| act
 
| att
 
| att
| typeCode
+
| @classCode
| "CST"
+
| "DOCSECT"
 
| CD CNE
 
| CD CNE
 
| 1..1
 
| 1..1
| M
+
| required
 +
|
 +
 
 +
|-
 +
| 2
 +
|bgcolor="ff8888"| act
 +
| att
 +
| @moodCode
 +
| "EVN"
 +
| CD CNE
 +
| 1..1
 +
| required
 
|  
 
|  
  
 
|-
 
|-
 
| 2
 
| 2
|bgcolor="ffff88"| role
+
|bgcolor="ff8888"| act
 
| elm
 
| elm
| assignedCustodian
+
| templateID
|  
+
| OID für Meldebegründungsabschnitt
 +
| ST
 +
| 1..1
 +
| required
 
|  
 
|  
| 1..1
 
| M
 
 
  
 
|-
 
|-
 
| 3
 
| 3
|bgcolor="ffff88"| role
+
|bgcolor="ff8888"| act
 
| att
 
| att
| classCode
+
| @root
| "ASSIGNED"  
+
| "1.2.276.0.76.3.1.131.1.10.2.1"
|  
+
| ST
 
| 1..1
 
| 1..1
| M
+
| required
 
|  
 
|  
 
 
  
 
|-
 
|-
|4
+
| 2
|bgcolor="88ff88"|ent
+
|bgcolor="ff8888"| act
 
| elm
 
| elm
| representedCustodianOrganisation
+
| code
| verwaltende/absendede Organisation
+
| Code für Meldebegründungsabschnitt
 +
| CD CNE
 +
| 1..1
 +
| required
 
|  
 
|  
| 0..1
 
|
 
|
 
  
 
|-
 
|-
|5
+
| 2
|bgcolor="88ff88"|ent
+
|bgcolor="ff8888"| act
 
| elm
 
| elm
| id
+
| title
| Identifikation der Organisation
+
| Titel des Abschnitts
| SET<II>
+
| ST
| 1..*
+
| 1..1
| M
+
| required
|
+
| fix "Meldebegründung"
  
 
|-
 
|-
|6
+
| 2
|bgcolor="88ff88"|ent
+
|bgcolor="ff8888"| act
| att
+
| elm
| @extension
+
| text
| eigentliche ID der Organisation
+
| Text für die Meldebegründung
 
| ST
 
| ST
 
| 1..1
 
| 1..1
| M
+
| required
|
+
|  
  
 
|-
 
|-
|6
+
| 2
|bgcolor="88ff88"|ent
+
|bgcolor="ffaaaa"| rel
| att
+
| elm
| @root
+
| entry
| OID der Organisation
+
|  
| ST
+
|  
 
| 1..1
 
| 1..1
| M
+
| required
 
|
 
|
  
 
|-
 
|-
|5
+
| 3
|bgcolor="88ff88"|ent
+
|bgcolor="ff8888"| act
 
| elm
 
| elm
| name
+
| observation
| Name der Organisation
+
|  
| ON
+
|  
| 0..1
+
| 1..1
 +
| required
 
|  
 
|  
|
 
  
 
|-
 
|-
|5
+
| 4
|bgcolor="88ff88"|ent
+
|bgcolor="ff8888"| act
| elm
+
| att
| telecom
+
| @classCode
| Kontaktinformation der Organisation
+
| "OBS"
| TEL
+
| CD CNE
| 0..1
+
| 1..1
|  
+
| required
|
+
| fix
 +
 
 +
|-
 +
| 4
 +
|bgcolor="ff8888"| act
 +
| att
 +
| @moodCode
 +
| "EVN"
 +
| CD CNE
 +
| 1..1
 +
| required
 +
| fix
  
 
|-
 
|-
|5
+
| 4
|bgcolor="88ff88"|ent
+
|bgcolor="ff8888"| act
 
| elm
 
| elm
| addr
+
| code
| Adresse der Organisation
+
| Es handelt sich um eine Meldebegründung
| AD
+
| CD CNE
| 0..1
+
| 1..1
 +
| required
 
|  
 
|  
|
 
  
|}
+
|-
 +
| 4
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| value
 +
| Meldebegründung
 +
| CD CNE
 +
| 1..1
 +
| required
 +
| Wie wird die Meldebegründung tatsächlich begründet. Hier ist ein Code aus 1.2.276.0.76.3.1.131.1.5.1  zu verwenden.
  
<syntaxhighlight lang="xml">
 
<custodian>
 
<assignedCustodian>
 
<representedCustodianOrganization>
 
<id root="2.16.840.1.113883.19.5"/>
 
<name>Good Health Clinic</name>
 
</representedCustodianOrganization>
 
</assignedCustodian>
 
</custodian>
 
</syntaxhighlight>
 
  
===Participant: Empfänger (informationRecipient)===
+
|-
Als Empfänger kommen hier sowohl die Krebsregister als auch Praxen und Krankenhäuser in Frage.
+
| 4
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| effectiveTime
 +
| Zeitpunkt der Meldebegründung
 +
| TS
 +
| 1..1
 +
| required
 +
| Das Datum, an dem der Patient unterrichtet wurde oder er unterschrieben hat.
  
 
+
|-
In dem Attribut „informationRecipient" wird angegeben, an welches Krebsregister oder Praxis/Krankenhaus die Daten übermittelt werden. Hier wird die „scoping" Entität „Organisation" (gestrichelte Linie) genutzt.
+
| 4
 
 
[[file:Cdaonk_empfaenger.gif|ID des Empfängers]]
 
 
Abbildung 17: Identifikation des Empfängers
 
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
|-
 
|0
 
|bgcolor="ff8888"|act
 
|elm
 
|ClinicalDocument
 
|
 
|
 
|
 
|
 
|
 
 
 
|-
 
| 1
 
 
|bgcolor="ccffff"| part
 
|bgcolor="ccffff"| part
 
| elm
 
| elm
| informationRecipient
 
| Empfänger
 
 
|  
 
|  
| 0..*
+
|
 +
|
 +
| 0..1
 
| optional
 
| optional
 
|  
 
|  
  
 
|-
 
|-
| 2
+
| 5
 
|bgcolor="ccffff"| part
 
|bgcolor="ccffff"| part
 
| att
 
| att
| typeCode
+
| @typeCode
| ""
+
| "AUTH"
 
| CD CNE
 
| CD CNE
| 1..1
+
| 0..1
| M
+
| optional
|  
+
| fix
  
 
|-
 
|-
| 2
+
| 5
 
|bgcolor="ffff88"| role
 
|bgcolor="ffff88"| role
 
| elm
 
| elm
| IntendedRecipient
+
| author
 
|  
 
|  
|
 
| 0..*
 
| M
 
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| att
 
| classCode
 
 
 
|  
 
|  
 
| 1..1
 
| 1..1
| M
+
| required
|  
+
| Diese Section sollte ein Autor Element enthalten, wenn der Autor dieser Section von dem in höheren Ebenen des Dokuments verschieden ist.
 +
  
 
|-
 
|-
| 3
+
| 6
|bgcolor="ffff88"| role
 
| att
 
| id
 
| Register-ID
 
| SET<II>
 
| 0..*
 
| M
 
|
 
 
 
|-
 
|4
 
 
|bgcolor="88ff88"|ent
 
|bgcolor="88ff88"|ent
 
| elm
 
| elm
| informationRecipient
+
| Person
|
 
 
|  
 
|  
 +
| Arzt
 
| 0..1
 
| 0..1
 
| optional
 
| optional
|
+
| Wer hat die Meldebegründung unterschrieben.
 
 
  
 
|-
 
|-
|5
+
| 7
 
|bgcolor="88ff88"|ent
 
|bgcolor="88ff88"|ent
 
| elm
 
| elm
| Person
+
| name|  
|  
+
| Name
|  
 
 
| 0..1
 
| 0..1
 
| optional
 
| optional
|
+
| Name des Meldenden
  
|-
+
|}
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| name
 
| Name der Person
 
| SET<PN>
 
| 0..*
 
| optional
 
|
 
  
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
| receivedOrganisation
 
|
 
|
 
| 0..1
 
| optional
 
|
 
  
 +
Wie lautet die eigentliche Meldebründung, die im Kontext der Meldung an bestimmte KR z.B. aus Abrechnungsgründen übertragen werden soll:
  
 +
{| class="hl7table"
 +
!Lvl!!Code!!Bedeutung!!Erläuterung
 +
|-
 +
|1||||Patient ist informiert||
 +
|-
 +
|2||E||Einwilligung||Die Einwilligung des Patienten liegt vor
 
|-
 
|-
|5
+
|2||W||Widerspruch zu Kontaktaufnahme||Patient(in) ist informiert und hat Kontaktaufnahme widersprochen
|bgcolor="88ff88"|ent
+
|-
| elm
+
|2||I||Information||Patientin / Patient wurde informiert und hat nicht widersprochen
| Organisation
+
|-
|  
+
|2||||Widerspruch zur Übermittlung||Der Patient hat einer Über¬mittlung seiner Daten widersprochen, so dass die Daten nicht übermittelt werden.
|  
+
|-
| 0..1
+
|1||A||Ausnahme||Patientenunterrichtung entfallen wegen möglicher gesundheitlicher Nachteile
| optional
+
|-
|
+
|1||V||Verstorben||
 
+
|-
 +
|1||D||Meldung von diagnostisch tätigen Ärzten ohne unmittelbaren Patientenkontakt||
 
|-
 
|-
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| name
 
| Name der Organisation
 
| SET<ON>
 
| 0..*
 
| optional
 
|
 
 
|}
 
|}
 +
Tabelle 9: Codesystem für die Meldebegründung (Zustimmung), OID: 1.2.276.0.76.3.1.131.1.5.1
  
 +
{{AlertBox|
 +
Bei nachträglichem Widerspruch sind die vorher übermittelten Daten wieder zu löschen.
 +
}}
  
===Participant: Versicherung (participant)===
+
Die genauen Formulierungen sind von Bundesland zu Bundesland verschieden. Die vorhergehende Tabelle deckt aber alle Erfordernisse ab, so dass spezifische Teilmengen für die einzelnen Bundesländer über ValueSets realisiert werden können/müssen. Die für die einzelnen Bundesländer gültigen Werte sind nachfolgend definiert:
  
 
{| class="hl7table"
 
{| class="hl7table"
! Lvl
+
!Code, Land!!E!!A!!I!!V!!D!!W!!ValueSet OID
! RIM
+
|-
! AE
+
|Baden Württemberg||-||-||-||-||-||-||
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
 
 
 
|-
 
|-
|1
+
|Bayern, Saarland||||X||X||||X||||TODO
|bgcolor="ff8888"|act
 
|elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
 
 
|-
 
|-
| 2
+
|Berlin||-||-||-||-||-||-||
|bgcolor="ffaaaa"| rel
+
|-
| elm
+
|Brandenburg||-||-||-||-||-||-||
|  
+
|-
|  
+
|Bremen||||X||X||X||X||||TODO
|  
+
|-
|  
+
|Hamburg, Niedersachsen||X||X||||X||||||TODO
|  
+
|-
|
+
|Hessen, Rheinland Pfalz||-||-||-||-||-||-||
 
+
|-
 +
|Mecklenburg-Vorpommern||-||-||-||-||-||-||
 
|-
 
|-
| 1
+
|Nordrhein-Westfalen||||||X||||||X||TODO
|bgcolor="ccffff"| part
 
| elm
 
| Participant
 
| Versicherung
 
| 0..*
 
|  
 
|  
 
|  
 
 
 
 
|-
 
|-
| 2
+
|Sachsen-Anhalt||-||-||-||-||-||-||TODO
|bgcolor="ffff88"| role
+
|-
| elm
+
|Sachsen||-||-||-||-||-||-||
|  
+
|-
|  
+
|Thüringen||-||-||-||-||-||-||
|  
 
|  
 
|  
 
|
 
 
 
 
|-
 
|-
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
 
|}
 
|}
 +
Tabelle 10: bundeslandspezifische ValueSets für die Meldebegründung; bei Bundesländern, welche diese Meldebegründungen nicht entgegennehmen, wurde ein "&#091;-&#093;" vergeben, OID: n.n.
  
 +
Wenn zwei Bundesländer dieselben Wertemengen vorgeben, so wird dafür dieselbe Value Set OID verwendet.
  
???
+
====Qualifier – Zustimmung für KKR====
 
+
In einem Qualifier kann angegeben werden, ob die Daten auch an das zuständige klinische bzw. epidemiologische Krebsregister übermittelt werden dürfen oder nicht.
==Allgemeiner Aufbau des Body==
 
An dieser Stelle sei auf den VHitG-Arztbrief verwiesen.
 
 
 
Abschnitt entspricht Component,
 
Klasse entspricht Section.
 
  
 
{| class="hl7table"
 
{| class="hl7table"
!Abschnitt!!Kard.!!Klasse!!Referenz auf Abschnitt
+
!Code!!Bedeutung!!Erläuterung
 
|-
 
|-
|Header||||||
+
|EKR||||
 
|-
 
|-
|s.o.||||||
+
|KKR||||
 
|-
 
|-
|Body||||||
+
|QS||||
 
|-
 
|-
|'''Meldebegründungdaten'''||0..1||||
+
|}
|-
+
 
|||||Meldebegründung||Participant
+
Tabelle 11: Vocabulary Domain für die Zustimmung wohin
|-
+
 
|'''Diagnostik'''||0..*||||
+
Anm.: Diese Tabelle muss ggf. weiter ergänzt werden bzw. bundeslandspezifisch festgelegt werden.
|-
+
 
|||||Untersuchung||
+
 
|-
+
====Beispiel====
|||||Ergebnis||
+
 
|-
+
Das 1. Beispiel muss in dem zweiten Beispiel aufgehen, d.h. soll verschwinden:
|||||||Phänomen
+
 
|-
+
<syntaxhighlight lang="xml">
|||||||Erkrankungsdaten
+
<!-- Meldebegründung -->
|-
+
<observation classCode="OBS" moodCode="EVN" negationInd="false">
|||||Beteiligter||Participant
+
    <code codeSystem="2.16.840.1.113883.5.4"
|-
+
          code="ASSERTION" />
|'''Erkrankungsdaten'''||0..*||||
+
    <statusCode code="completed" />
|-
+
    <!-- Datum der Meldebegründung -->
|||||||Meldebegründungdaten
+
    <effectiveTime value="201011051500" />
|-
+
    <!-- Typ der Meldebegründung -->
|||||Erkrankung||
+
    <value xsi:type="CD"
|-
+
          code="E"
|||||||Phänomendaten
+
          codeSystem="????"
|-
+
          codeSystemName="????"
|'''Phänomendaten'''||0..*||||
+
          displayName="Einwilligung">
|-
+
 
|||||Phänomen||
+
      <!-- Zustimmung zur Meldebegründung -->
|-
+
      <qualifier>
|'''Operation'''||0..*||||
+
        <name codeSystem="1.2.276.0.76...."
|-
+
              codeSystemName="?????" <!-- Tabelle der Zustimmungen -->
|||||Beteiligter||Participant
+
              code="KKR" <!—- EKR\|KKR ... -->
|-
+
              displayName="Zustimmung"/>
|||||Operative Therapie||
+
        <value codeSystem="????"
|-
+
              codeSystemName="Zustimmung zur Weiterleitung"
|||||||Erkrankungsdaten
+
              code="Y"
|-
+
              displayName="ja"/>
|||||||Phänomendaten
+
      </qualifier>
|-
+
 
|'''Bestrahlung'''||0..*||||
+
    </value>
|-
+
</observation>
|||||Beteiligter||Participant
+
</syntaxhighlight>
|-
+
 
|||||Strahlentherapie||
+
 
|-
+
 
|||||||Erkrankungsdaten
+
<syntaxhighlight lang="xml">
|-
+
<section>
|||||||Phänomendaten
+
  <templateId root="1.2.276.0.76.3.1.131.1.10.2.1"/>
|-
+
  <code code=" ?????" codeSystem="2.16.840.1.113883.6.1"
|||||Einzelbestrahlung||
+
        codeSystemName="LOINC"/>
|-
+
  <title>Meldebegründung</title>
|'''Medikamentendaten'''||0..*||||
+
  <text>Der Patient hat in die Meldung eingewilligt.</text>
|-
+
 
|||||Einzelgabe||
+
  <entry>
|-
+
 
|||||Dauergabe||
+
      <!-- Meldebegründung mit Datum -->
|-
+
      <observation classCode="OBS" moodCode="EVN">
|'''Systemisch'''||0..*||||
+
        <id>3473847/01</id> <!-- optionale ID für Referenzzwecke -->
|-
+
        <!-- Wo würde dargestellt, wo die Meldebegründung erstellt wurde,
|||||Beteiligter||Participant
+
                Referenz auf Participant -->
|-
+
        <code code="gekidMeldebegruendung" codeSystem="1.2.276.0.76.3.1.131.1.5.1"
|||||Systemtherapie||
+
            codeSystemName="DKG-Labels" displayName="Meldebegründung"/>
|-
+
        <statusCode code="completed"/>
|||||||Erkrankungsdaten
+
        <effectiveTime>
|-
+
            <low value="20101022"/>
|||||||Phänomendaten
+
        </effectiveTime>
|-
+
        <value xsi:type="CD"
|||||Zyklus||
+
                code="E" displayName="Meldung an EKR-BW "
|-
+
                codeSystem="1.2.276.0.76.3.1.131.1.5.2"
|||||Zyklustag||
+
                codeSystemName="Meldebegruendung"/>
|-
+
        </value>
|||||||Medikamentendaten
+
      </observation>
|-
+
 
|'''Status (Nachsorge und anderes Follow-up)'''||0..*||||
+
      <!-- Kodierung der Zustimmung -->
|-
+
      <observation classCode="OBS" moodCode="EVN">
|||||Prozedur||
+
      <code code="?????" codeSystem="??????"
|-
+
            codeSystemName="LOINC" displayName="Zustimmung"/>
|||||Ergebnis||
+
        <statusCode code="completed"/>
|-
+
        <value xsi:type="CD"
|||||||Erkrankungsdaten
+
                code="????" displayName="?????"
 +
                codeSystem="?????"
 +
                codeSystemName="?????"/>
 +
        </value>
 +
      </observation>
 +
 
 +
      <!-- Kodierung der Information -->
 +
      <observation classCode="OBS" moodCode="EVN">
 +
      <code code="?????" codeSystem="??????"
 +
            codeSystemName="LOINC" displayName="Information über Meldung"/>
 +
        <statusCode code="completed"/>
 +
        <value xsi:type="CD"
 +
                code="????" displayName="?????"
 +
                codeSystem="?????"
 +
                codeSystemName="?????"/>
 +
        </value>
 +
      </observation>
 +
 
 +
      <!-- Kodierung des Widerspruchs -->
 +
      <observation classCode="OBS" moodCode="EVN">
 +
      <code code="?????" codeSystem="??????"
 +
            codeSystemName="LOINC" displayName="Widerspruch gegen Meldung"/>
 +
        <statusCode code="completed"/>
 +
        <value xsi:type="CD"
 +
                code="????" displayName="?????"
 +
                codeSystem="?????"
 +
                codeSystemName="?????"/>
 +
        </value>
 +
      </observation>
 +
 
 +
  </entry>
 +
</section>
 +
</syntaxhighlight>
 +
 
 +
====Schematron====
 +
 
 +
Hier müssen noch die Schematronregeln zur Prüfung des Inhaltes hin....
 +
 
 +
===Diagnosen===
 +
 
 +
{| class="hl7table"
 +
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|-
|||||||Phänomendaten
+
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird die Diagnosen zum Patienten übermittelt.
 
|-
 
|-
|'''Studiendaten'''||0..*||||
+
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|-
 
|-
|||||Studie||
+
| ???? || O ||
|-
+
|}
|||||||Erkrankungsdaten
+
 
|-
+
Die Diagnose umfasst folgende Punkte, die über separate Observations ausgedrückt werden:
|'''Abschlussdaten'''||0..*||||
 
|-
 
|||||Prozedur||
 
|-
 
|||||Ergebnis||
 
|-
 
|||||||Erkrankungsdaten
 
|-
 
|'''Planung'''||0..*||||
 
|-
 
|||||Prozedur||
 
|-
 
|||||Ergebnis||
 
|-
 
|||||||Erkrankungsdaten
 
|-
 
|||||||Phänomendaten
 
|-
 
|||||||Operation
 
|-
 
|||||||Bestrahlung
 
|-
 
|||||||Systemisch
 
|-
 
|||||||Status (Nachsorge und anderes Follow-up)
 
|-
 
|||||||Studiendaten
 
|-
 
|||||||Diagnostik
 
|-
 
|}
 
Tabelle 8: Dokument-Inhalte
 
TODO Abschnitte: Section bekommen eine Template-ID. Die iwird im Rahmenb des OID-Konzepts vergeben: 1.2.276.0.76.3.1.10.? (Deutsche Krebsgesellschaft e.V. …131=DKG, 1=Version des OID-Konzeptes, 10=Template)
 
Template Level: Documenmt/Section/Entry
 
  
 +
[[file:Cdaonk_diagnosen.gif|Diagnosen]]
 +
 +
Abbildung 20: Section ->Diagnose
  
===graphische Übersicht===
+
{{AlertBox|
 +
An dieser Stelle sei darauf verwiesen, dass hier das Komponentenmodell für die Tumordiagnosen aus dem Diagnoseleitfaden eingesetzt wird.
 +
}}
  
[[file:Cdaonk_abschnittsuebersicht.gif|Abschnittsübersicht]]
 
 
Abbildung 18: Abschnittsübersicht
 
  
==Abschnitte==
+
{| class="hl7table"
Nachfolgend werden die einzelnen Abschnitte im Detail erläutert.
+
! Lvl
 +
! RIM
 +
! AE
 +
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
  
===Nationalität===
 
  
 +
|-
 +
|1
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
  
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
 
|-
 
|-
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird die Nationalität des Patienten übermittelt.
+
| 2
 +
|bgcolor="ffaaaa"| rel
 +
| elm
 +
|
 +
|
 +
|
 +
|  
 +
|  
 +
|
 +
 
 
|-
 
|-
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
+
| 1
 +
|bgcolor="ccffff"| part
 +
| elm
 +
|  
 +
|
 +
|  
 +
|  
 +
|  
 +
|  
 +
 
 
|-
 
|-
| ???? || O ||
+
| 2
|}
+
|bgcolor="ffff88"| role
 +
| elm
 +
|  
 +
|  
 +
|
 +
|
 +
|  
 +
|
  
Value Set: 1.3.6.1.4.1.12559.11.10.1.3.1.42.4
+
|-
 +
|4
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
  
Value Set Name: VS11_epSOSCountry
+
|}
  
Code System: ISO-3166-1
 
  
{{AlertBox|
 
Modelliert man das über eine Sektion "Nationalität" oder als Teil einer allgemeineren Sektion "zusätzliche Patientendaten".<br> TODO!!!
 
}}
 
  
===Sterbedatum===
+
TODO Abgleich Klassifikationsliste KRBW (Altmann)
  
 +
Anlaß der Diagnosestellung
  
{| class="hl7table"
+
{|class="hl7table"
|bgcolor="ddddff"|Template ID|| colspan=2 | IHE PCC Health Status 1.3.6.1.4.1.19376.1.5.3.1.4.1.2
 
 
|-
 
|-
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird der Gesundheitszustand des Patienten übermittelt.
+
!Code
 +
!Beschreibung
 
|-
 
|-
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
+
|E || Eigenuntersuchung (Selbstuntersuchung)
 
|-
 
|-
| 11323-3 || O || Health Status
+
|F || gesetzl. Früherkennung
|}
 
 
 
Das Sterbedatum ist dann eine konkrete Beobachtung darin.
 
 
 
Die folgenden Snomed CT Codes (vgl. IHE PCC Vol.2 6.3.4.5.8) stehen zur Verfügung:
 
 
 
{| class="hl7table"
 
 
|-
 
|-
!Code !!Description
+
|V || nicht gesetzl Vorsorge
 +
|-
 +
|C || Screening
 +
|-
 +
|A || Anamnese
 +
|-
 +
|N || Nachsorge
 +
|-
 +
|T || Tumorsymptomatik
 
|-
 
|-
|81323004 ||Alive and well
+
|U || Unbekannt
 +
|}
 +
 
 +
Art der Diagnosesicherung
 +
 
 +
{|class="hl7table"
 
|-
 
|-
|313386006 ||In remission
+
!Code
 +
!Beschreibung
 
|-
 
|-
|162467007 ||Symptom free
+
|1 || klinisch ohne spez. Diagnostik
 
|-
 
|-
|161901003 ||Chronically ill
+
|2 || klinische Diagnostik
 
|-
 
|-
|271593001 ||Severely ill
+
|4 || spez. Tumormaker
 
|-
 
|-
|21134002 ||Disabled
+
|5 || Zytologie
 
|-
 
|-
|161045001 ||Severely disabled
+
|6 || Histologie Metastase
 
|-
 
|-
|419099009 ||Deceased
+
|7 || Histologie Primärtumor
 
|}
 
|}
  
 +
[[file:Cdaonk_diagnostik.gif|Diagnostik]]
 +
 +
Abbildung 21: Diagnostik
  
<syntaxhighlight lang="xml">
+
=> Abschnitt Verlaufsbeurteilung
<entry>
+
 
<observation classCode='OBS' moodCode='EVN'>
+
{| class="hl7table"
  <entryRelationship typeCode='REFR' inversionInd='false'>
+
!Code!!Bedeutung!!Erläuterung
    <observation classCode='OBS' moodCode='EVN'>
+
|-
      <templateId root='2.16.840.1.113883.10.20.1.51'/>
+
|K||keine Fernmetastasen nachweisbar||
      <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.1.2'/>
+
|-
      <code code='11323-3' displayName='Health Status'
+
|E||Fernmetastasen vor Ersttherapie||
            codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC' />
+
|-
      <text><reference value='#hstatus-2'/></text>
+
|M||verbliebene Fernmetastasen||
      <statusCode code='completed'/>
+
|-
      <value xsi:type='CE' code=' ' codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT'/>
+
|R||neu aufgetretene Fernmetastasen (Rezidiv)||
    </observation>
+
|-
  </entryRelationship>
+
|B||neue und verbliebene Fernmetastasen||
  </observation>
 
</entry>
 
</syntaxhighlight>
 
 
 
===Meldebegründungsdaten===
 
 
 
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 |1.2.276.0.76.3.1.131.1.10.2.1
 
 
|-
 
|-
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird die Begründung für die Meldung übermittelt.
+
|F||fraglicher Befund||
 
|-
 
|-
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
+
|X||unbekannt||
 
|-
 
|-
| ???? || O ||
 
 
|}
 
|}
 +
Tabelle 12: Vocabulary Domain für Art der Fernmetastasen (Kap 3.11.3.1)
  
Eine Meldebegründung gibt den rechtlichen Kontext der Meldung wider. Dies unterscheidet sich von Bundesland zu Bundesland. In Ländern mit Meldepflicht muss der Patient in der Regel informiert werden. Ausnahmen gibt es ggf. wenn der Patient verstorben ist oder ihm eine Mitteilung nicht zugemutet werden kann (oder bei Meldungen von Pathologen). Bei Meldepflicht gibt es grundsätzlich ein Widerspruchsrecht. Bei Meldrecht muss der Patient zustimmen. Weitere Variationen bestehen im Einverständnis zur Nutzung der Daten für weitergehende Forschung. An dieser Stelle sollte auch die Zustimmung zur Meldung ans klinische Krebsregister berücksichtigt werden. Diese kann ggf. zukünftig auch nach unterschiedlichen Nutzungszwecken unterschieden werden.
 
 
[[file:Cdaonk_meldebegruendung.gif|Meldebegründugn]]
 
 
Abbildung 19: Observation für die Meldebegründung
 
  
 +
=> Phänomendaten
  
 
{| class="hl7table"
 
{| class="hl7table"
! Lvl
+
!Code!!Bedeutung!!Erläuterung
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
 
|-
 
|-
| 1
+
|PUL||Lunge||
|bgcolor="ff8888"| act
+
|-
| elm
+
|OSS||Knochen||
| section
 
|  
 
|  
 
| 1..1
 
| required
 
|  
 
 
 
 
|-
 
|-
| 2
+
|HEP||Leber||
|bgcolor="ff8888"| act
 
| att
 
| @classCode
 
| "DOCSECT"
 
| CD CNE
 
| 1..1
 
| required
 
|
 
 
 
 
|-
 
|-
| 2
+
|BRA||Hirn||
|bgcolor="ff8888"| act
 
| att
 
| @moodCode
 
| "EVN"
 
| CD CNE
 
| 1..1
 
| required
 
|
 
 
 
 
|-
 
|-
| 2
+
|LYM||Lymphknoten||
|bgcolor="ff8888"| act
 
| elm
 
| templateID
 
| OID für Meldebegründungsabschnitt
 
| ST
 
| 1..1
 
| required
 
|
 
 
 
 
|-
 
|-
| 3
+
|MAR||Knochenmark||
|bgcolor="ff8888"| act
+
|-
| att
+
|PLE||Pleura||
| @root
 
| "1.2.276.0.76.3.1.131.1.10.2.1"
 
| ST
 
| 1..1
 
| required
 
|  
 
 
 
 
|-
 
|-
| 2
+
|PER||Peritoneum||
|bgcolor="ff8888"| act
 
| elm
 
| code
 
| Code für Meldebegründungsabschnitt
 
| CD CNE
 
| 1..1
 
| required
 
|
 
 
 
 
|-
 
|-
| 2
+
|ADR||Nebennieren||
|bgcolor="ff8888"| act
 
| elm
 
| title
 
| Titel des Abschnitts
 
| ST
 
| 1..1
 
| required
 
| fix "Meldebegründung"
 
 
 
 
|-
 
|-
| 2
+
|SKI||Haut||
|bgcolor="ff8888"| act
 
| elm
 
| text
 
| Text für die Meldebegründung
 
| ST
 
| 1..1
 
| required
 
|
 
 
 
 
|-
 
|-
| 2
+
|SPL||Milz||
|bgcolor="ffaaaa"| rel
+
|-
| elm
+
|GEN||Generalisierte Metastasierung||
| entry
 
|  
 
|  
 
| 1..1
 
| required
 
|
 
 
 
 
|-
 
|-
| 3
+
|OTH||andere Organe||
|bgcolor="ff8888"| act
 
| elm
 
| observation
 
|
 
|
 
| 1..1
 
| required
 
|
 
 
 
 
|-
 
|-
| 4
+
|}
|bgcolor="ff8888"| act
+
Tabelle 13: Vocabulary Domain für das Organlokalisation für Fernmetastasen (Kap. 2.15.2 u. 3.11.3.2)
| att
 
| @classCode
 
| "OBS"
 
| CD CNE
 
| 1..1
 
| required
 
| fix
 
  
|-
+
=> Abschnitt Verlaufsbeurteilung
| 4
 
|bgcolor="ff8888"| act
 
| att
 
| @moodCode
 
| "EVN"
 
| CD CNE
 
| 1..1
 
| required
 
| fix
 
  
 +
{| class="hl7table"
 +
!Code!!Bedeutung!!Erläuterung
 
|-
 
|-
| 4
+
|K||kein Tumor nachweisbar||
|bgcolor="ff8888"| act
+
|-
| elm
+
|E||Primärtumor vor Ersttherapie||
| code
+
|-
| Es handelt sich um eine Meldebegründung
+
|T||Tumorreste ( Residualtumor )||
| CD CNE
+
|-
| 1..1
+
|R||LokalRezidiv||
| required
+
|-
|  
+
|F||fraglicher Befund||
 
+
|-
 +
|X||Unbekannt||
 
|-
 
|-
| 4
+
|}
|bgcolor="ff8888"| act
+
Tabelle 14: Vocabulary Domain für Primäturmor (Kap. 3.11.1)
| elm
 
| value
 
| Meldebegründung
 
| CD CNE
 
| 1..1
 
| required
 
| Wie wird die Meldebegründung tatsächlich begründet. Hier ist ein Code aus 1.2.276.0.76.3.1.131.1.5.1  zu verwenden.
 
  
 +
=> Abschnitt Verlaufsbeurteilung
  
 +
{| class="hl7table"
 +
!Code!!Bedeutung!!Erläuterung
 
|-
 
|-
| 4
+
|K||keine regionären Lymphknotenmetastasen||
|bgcolor="ff8888"| act
 
| elm
 
| effectiveTime
 
| Zeitpunkt der Meldebegründung
 
| TS
 
| 1..1
 
| required
 
| Das Datum, an dem der Patient unterrichtet wurde oder er unterschrieben hat.
 
 
 
 
|-
 
|-
| 4
+
|E||Lymphknotenmetastase(n) vor der Ersttherapie||
|bgcolor="ccffff"| part
+
|-
| elm
+
|T||ResidualTumor in regionären Lymphknoten||
|  
+
|-
|  
+
|R||Lymphknotenrezidiv / neu aufgetretene Lymphknotenmetastasen||
|  
+
|-
| 0..1
+
|B||verbliebene und neue Lymphknotenmetastasen / LK-Rezidiv||
| optional
+
|-
|  
+
|F||fraglicher Befund||
 
 
 
|-
 
|-
| 5
+
|X||Unbekannt||
|bgcolor="ccffff"| part
 
| att
 
| @typeCode
 
| "AUTH"
 
| CD CNE
 
| 0..1
 
| optional
 
| fix
 
 
 
 
|-
 
|-
| 5
+
|}
|bgcolor="ffff88"| role
+
Tabelle 15: Vocabulary Domain für regionäre Lymphknotenmetastasen (Kap.3.11.2)
| elm
 
| author
 
|
 
|
 
| 1..1
 
| required
 
| Diese Section sollte ein Autor Element enthalten, wenn der Autor dieser Section von dem in höheren Ebenen des Dokuments verschieden ist.
 
 
  
 +
{| class="hl7table"
 +
!Code!!Bedeutung!!Erläuterung
 
|-
 
|-
| 6
+
|L||Lokoregionär||
|bgcolor="88ff88"|ent
+
|-
| elm
+
|F||Fernmetastase(n)||
| Person
+
|-
|  
+
|B||Beides (Lokoregionär und Fernmetastase(n))||
| Arzt
+
|-
| 0..1
+
|X||Unbekannt||
| optional
 
| Wer hat die Meldebegründung unterschrieben.
 
 
 
 
|-
 
|-
| 7
 
|bgcolor="88ff88"|ent
 
| elm
 
| name|
 
| Name
 
| 0..1
 
| optional
 
| Name des Meldenden
 
 
 
|}
 
|}
 +
Tabelle 16: Vocabulary Domain für Residualtumor (Kap.4.2.2)
  
 
+
====Anlass der Diagnosestellung====
Wie lautet die eigentliche Meldebründung, die im Kontext der Meldung an bestimmte KR z.B. aus Abrechnungsgründen übertragen werden soll:
+
als Qualifier ????
  
 
{| class="hl7table"
 
{| class="hl7table"
!Lvl!!Code!!Bedeutung!!Erläuterung
+
!Code!!Bedeutung!!Erläuterung
 
|-
 
|-
|1||||Patient ist informiert||
+
|E||Eigenuntersuchung (Selbstuntersuchung)||
 
|-
 
|-
|2||E||Einwilligung||Die Einwilligung des Patienten liegt vor
+
|F||Gesetz. Früherkennung||
 
|-
 
|-
|2||W||Widerspruch zu Kontaktaufnahme||Patient(in) ist informiert und hat Kontaktaufnahme widersprochen
+
|V||Nicht gesetzl. Vorsorge||
 
|-
 
|-
|2||I||Information||Patientin / Patient wurde informiert und hat nicht widersprochen
+
|C||Screening||
 
|-
 
|-
|2||||Widerspruch zur Übermittlung||Der Patient hat einer Über¬mittlung seiner Daten widersprochen, so dass die Daten nicht übermittelt werden.
+
|A||Anamnese||
 
|-
 
|-
|1||A||Ausnahme||Patientenunterrichtung entfallen wegen möglicher gesundheitlicher Nachteile
+
|N||Nachsorge||
|-
 
|1||V||Verstorben||
 
|-
 
|1||D||Meldung von diagnostisch tätigen Ärzten ohne unmittelbaren Patientenkontakt||
 
 
|-
 
|-
 
|}
 
|}
Tabelle 9: Codesystem für die Meldebegründung (Zustimmung), OID: 1.2.276.0.76.3.1.131.1.5.1
+
Tabelle 17: Vocabulary Domain für Diagnoseanlass
  
{{AlertBox|
+
====Diagnosesicherung====
Bei nachträglichem Widerspruch sind die vorher übermittelten Daten wieder zu löschen.
+
Wie ist die Diagnose gesichert worden?
}}
 
 
 
Die genauen Formulierungen sind von Bundesland zu Bundesland verschieden. Die vorhergehende Tabelle deckt aber alle Erfordernisse ab, so dass spezifische Teilmengen für die einzelnen Bundesländer über ValueSets realisiert werden können/müssen. Die für die einzelnen Bundesländer gültigen Werte sind nachfolgend definiert:
 
  
 
{| class="hl7table"
 
{| class="hl7table"
!Code, Land!!E!!A!!I!!V!!D!!W!!ValueSet OID
+
!Code!!Bedeutung!!Erläuterung
 
|-
 
|-
|Baden Württemberg||-||-||-||-||-||-||
+
|1||Klinische spez. Diagnostik||
 
|-
 
|-
|Bayern, Saarland||||X||X||||X||||TODO
+
|2||Klinische Diagnostik||
 
|-
 
|-
|Berlin||-||-||-||-||-||-||
+
|4||Spez. Tumormarker||
 
|-
 
|-
|Brandenburg||-||-||-||-||-||-||
+
|5||Zytologie||
 
|-
 
|-
|Bremen||||X||X||X||X||||TODO
+
|6||Histologie Metastase||
 
|-
 
|-
|Hamburg, Niedersachsen||X||X||||X||||||TODO
+
|7||Histologie Primärtumor||
|-
 
|Hessen, Rheinland Pfalz||-||-||-||-||-||-||
 
|-
 
|Mecklenburg-Vorpommern||-||-||-||-||-||-||
 
|-
 
|Nordrhein-Westfalen||||||X||||||X||TODO
 
|-
 
|Sachsen-Anhalt||-||-||-||-||-||-||TODO
 
|-
 
|Sachsen||-||-||-||-||-||-||
 
|-
 
|Thüringen||-||-||-||-||-||-||
 
 
|-
 
|-
 
|}
 
|}
Tabelle 10: bundeslandspezifische ValueSets für die Meldebegründung; bei Bundesländern, welche diese Meldebegründungen nicht entgegennehmen, wurde ein "&#091;-&#093;" vergeben, OID: n.n.
+
Tabelle 18: Vocabulary Domain für Diagnosesicherung
 +
 
  
Wenn zwei Bundesländer dieselben Wertemengen vorgeben, so wird dafür dieselbe Value Set OID verwendet.
 
  
====Qualifier – Zustimmung für KKR====
+
====Tabellen für TNM aus dem Diagnoseleitfaden====
In einem Qualifier kann angegeben werden, ob die Daten auch an das zuständige klinische bzw. epidemiologische Krebsregister übermittelt werden dürfen oder nicht.
+
Die nachfolgenden Tabellen sind implizit schon im Diagnoseleitfaden enthalten und können deshalb hier entfallen!
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Code!!Bedeutung!!Erläuterung
 
!Code!!Bedeutung!!Erläuterung
 
|-
 
|-
|EKR||||
+
|R0||R0 (kein Residualtumor)||
 
|-
 
|-
|KKR||||
+
|R1||R1 (mikroskopischer Residualtumor)||
 
|-
 
|-
|QS||||
+
|R2||R2||
 +
|-
 +
|R2a||R2a (makr.Residualtumor, mikr. nicht bestätigt)||
 +
|-
 +
|R2b||R2b (makr.Residualtumor, mikroskop. bestätigt)||
 +
|-
 +
|RX||RX (Vorhandensein von Residualtumor kann n. beurteilt werden)||
 
|-
 
|-
 
|}
 
|}
 +
Tabelle 19: Vocabulary Domain für TNM R-Klassifikation (Kap.4.2.1)
 +
 +
=> Phänomen und Erkrankungsdaten, Spezifikation Diagnoseleitfaden
  
Tabelle 11: Vocabulary Domain für die Zustimmung wohin
 
  
Anm.: Diese Tabelle muss ggf. weiter ergänzt werden bzw. bundeslandspezifisch festgelegt werden.
+
====Referenzen====
 +
* Phänomen => über entryRelationship/observation
 +
* Erkankungsdaten => über entryRelationship/observation
 +
* Participant => über participation
  
 +
===Todesursache===
  
====Beispiel====
+
{| class="hl7table"
 +
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 +
|-
 +
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werden die Informationen zur Todesursache übermittelt.
 +
|-
 +
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 +
|-
 +
| ???? || O ||
 +
|}
  
Das 1. Beispiel muss in dem zweiten Beispiel aufgehen, d.h. soll verschwinden:
+
Die Übermittlung der Todesursache wird über eine separate Observation ausgedrückt, die aber in demselben Abschnitt (Section) untergebracht wird:
  
<syntaxhighlight lang="xml">
+
#[[file:Cdaonk_diagnostik2.gif|Diagnostik]]
<!-- Meldebegründung -->
+
<observation classCode="OBS" moodCode="EVN" negationInd="false">
+
Abbildung 22: Diagnostik
    <code codeSystem="2.16.840.1.113883.5.4"
 
          code="ASSERTION" />
 
    <statusCode code="completed" />
 
    <!-- Datum der Meldebegründung -->
 
    <effectiveTime value="201011051500" />
 
    <!-- Typ der Meldebegründung -->
 
    <value xsi:type="CD"
 
          code="E"
 
          codeSystem="????"
 
          codeSystemName="????"
 
          displayName="Einwilligung">
 
  
      <!-- Zustimmung zur Meldebegründung -->
+
{| class="hl7table"
      <qualifier>
+
! Lvl
        <name codeSystem="1.2.276.0.76...."  
+
! RIM
              codeSystemName="?????" <!-- Tabelle der Zustimmungen -->
+
! AE
              code="KKR" <!—- EKR\|KKR ... -->
+
! Name
              displayName="Zustimmung"/>
+
! Desc
        <value codeSystem="????"
+
! DT
              codeSystemName="Zustimmung zur Weiterleitung"
+
! Kard
              code="Y"
+
! Conf
              displayName="ja"/>
+
! Beschreibung
      </qualifier>
 
  
    </value>
 
</observation>
 
</syntaxhighlight>
 
  
 +
|-
 +
|1
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|Section
 +
|
 +
|
 +
|0..1
 +
|
 +
|Dieser Abschnitt übermittelt Informationen über die Todesursache.
  
 +
|-
 +
|2
 +
|bgcolor="ff8888"|act
 +
|att
 +
|@code
 +
|
 +
|CD CWE
 +
|1..1
 +
|M
 +
|Dieser Code besagt, dass dieser Abschnitt über die Todesursache berichtet.
  
<syntaxhighlight lang="xml">
+
|-
<section>
+
| 2
  <templateId root="1.2.276.0.76.3.1.131.1.10.2.1"/>
+
|bgcolor="ffaaaa"| rel
  <code code=" ?????" codeSystem="2.16.840.1.113883.6.1"
+
| elm
        codeSystemName="LOINC"/>
+
| Entry
  <title>Meldebegründung</title>
+
|
  <text>Der Patient hat in die Meldung eingewilligt.</text>
+
|
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|3
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|Observation
 +
|Tod
 +
|
 +
|
 +
|
 +
|
  
  <entry>
+
|-
 +
|4
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|Observation
 +
|Tod durch Tumor
 +
|
 +
|1..1
 +
|M
 +
|
  
      <!-- Meldebegründung mit Datum -->
+
|-
      <observation classCode="OBS" moodCode="EVN">
+
|5
        <id>3473847/01</id> <!-- optionale ID für Referenzzwecke -->
+
|bgcolor="ff8888"|act
        <!-- Wo würde dargestellt, wo die Meldebegründung erstellt wurde,
+
|att
                Referenz auf Participant -->
+
|@code
        <code code="gekidMeldebegruendung" codeSystem="1.2.276.0.76.3.1.131.1.5.1"
+
|Tod durch Tumor
            codeSystemName="DKG-Labels" displayName="Meldebegründung"/>
+
|CD CWE
        <statusCode code="completed"/>
+
|1..1
        <effectiveTime>
+
|M
            <low value="20101022"/>
+
|Dieses Attribut drückt aus, dass diese Beobachtung Aufschluss über die Todesursache gibt.
        </effectiveTime>
 
        <value xsi:type="CD"
 
                code="E" displayName="Meldung an EKR-BW "
 
                codeSystem="1.2.276.0.76.3.1.131.1.5.2"
 
                codeSystemName="Meldebegruendung"/>
 
        </value>
 
      </observation>
 
  
      <!-- Kodierung der Zustimmung -->
+
|-
      <observation classCode="OBS" moodCode="EVN">
+
|5
      <code code="?????" codeSystem="??????"
+
|bgcolor="ff8888"|act
            codeSystemName="LOINC" displayName="Zustimmung"/>
+
|att
        <statusCode code="completed"/>
+
|@value
        <value xsi:type="CD"
+
|Tod durch Tumor
                code="????" displayName="?????"
+
|CD CWE
                codeSystem="?????"
+
|1..1
                codeSystemName="?????"/>
+
|M
        </value>
+
|Hier wird die Information (Code) zur Todesursache eingetragen: s.u. Codesystem zur Todesursache.
      </observation>
 
  
      <!-- Kodierung der Information -->
+
|-
      <observation classCode="OBS" moodCode="EVN">
+
|5
      <code code="?????" codeSystem="??????"
+
|bgcolor="ff8888"|act
            codeSystemName="LOINC" displayName="Information über Meldung"/>
+
|att
        <statusCode code="completed"/>
+
|@negationInd
        <value xsi:type="CD"
+
|Negation
                code="????" displayName="?????"
+
|BL
                codeSystem="?????"
+
|0..1
                codeSystemName="?????"/>
+
|
        </value>
+
|Wenn gesetzt drückt dieses Attribut aus, dass der Tumor nicht tumorbedingt ist/war.
      </observation>
 
  
      <!-- Kodierung des Widerspruchs -->
+
|-
      <observation classCode="OBS" moodCode="EVN">
+
| 4
      <code code="?????" codeSystem="??????"
+
|bgcolor="ffaaaa"| rel
            codeSystemName="LOINC" displayName="Widerspruch gegen Meldung"/>
+
| elm
        <statusCode code="completed"/>
+
| Entry
        <value xsi:type="CD"
+
|
                code="????" displayName="?????"
+
|
                codeSystem="?????"
+
|
                codeSystemName="?????"/>
+
|
        </value>
+
|
      </observation>
 
 
 
  </entry>
 
</section>
 
</syntaxhighlight>
 
 
 
====Schematron====
 
  
Hier müssen noch die Schematronregeln zur Prüfung des Inhaltes hin....
 
 
===Diagnosen===
 
 
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
 
|-
 
|-
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird die Diagnosen zum Patienten übermittelt.
+
|5
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|Observation
 +
|Beruf
 +
|
 +
|
 +
|
 +
|Spezialfall einiger EKR (z.B. GKR Gemeinsames Krebsregister, längster letzter Beruf, Dauer) => spätere Ausbauphase. Wird als Freitext und ggf. nach speziellem Berufe¬schlüssel übermittelt.
 +
 
 
|-
 
|-
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
+
|6
 +
|bgcolor="ff8888"|act
 +
|att
 +
|@code
 +
|Tod durch Beruf
 +
|CD CWE
 +
|1..1
 +
|M
 +
|Dieses Attribut drückt aus, dass diese Beobachtung angibt, ob der Tod ursächlich durch die Berufsausübung veranlasst ist.
 +
 
 
|-
 
|-
| ???? || O ||
+
|6
|}
+
|bgcolor="ff8888"|act
 +
|att
 +
|@value
 +
|Tod durch Beruf
 +
|BL
 +
|1..1
 +
|
 +
|Ein boolescher Wert gibt an, ob der Krebs durch die Berufsausübung (Kap. 1.8.5) entstanden ist.
 +
Wenn diese Aussage nicht gesichert (Verdacht) ist, dann wird dies über einen entsprechenden qualifier zum Ausdruck gebracht. Wenn nicht klar ist, ob die Berufsausübung ursächlich für den Krebs ist, dann ist dies durch einen nullFlavor auszudrücken.
  
Die Diagnose umfasst folgende Punkte, die über separate Observations ausgedrückt werden:
 
  
[[file:Cdaonk_diagnosen.gif|Diagnosen]]
+
|-
+
|6
Abbildung 20: Section ->Diagnose
+
|bgcolor="ff8888"|act
 +
|att
 +
|@negationInd
 +
|Negation
 +
|BL
 +
|0..1
 +
|
 +
|Wenn gesetzt drückt dieses Attribut aus, dass der Tumor nicht berufsbedingt ist/war.
  
{{AlertBox|
+
|}
An dieser Stelle sei darauf verwiesen, dass hier das Komponentenmodell für die Tumordiagnosen aus dem Diagnoseleitfaden eingesetzt wird.  
+
 
}}
+
 
 +
{| class="hl7table"
 +
!Lvl!!Code!!Bedeutung!!Erläuterung
 +
|-
 +
|1||J||Tod tumorbedingt, keine nähere Angabe||
 +
|-
 +
|2||T||Tod tumorbedingt durch das Tumorleiden, keine nähere Angabe||
 +
|-
 +
|2||P||Tod tumorbedingt durch Progression des primären Tumorgeschehens||
 +
|-
 +
|2||L||Tod tumorbedingt durch lokoregionäres Rezidiv||
 +
|-
 +
|2||M||Tod tumorbedingt durch Fernmetastasierung||
 +
|-
 +
|2||B||Tod tumorbedingt durch Behandlungskomplikation||
 +
|-
 +
|1||E||Entscheidung nicht möglich||
 +
|-
 +
|1||nullFlavor="NI" ||„unbekannt" wird über einen nullFlavor zum Ausdruck gebracht.||
 +
|}
 +
Tabelle 20: Vocabulary Domain für Todesursache (Kap 7.5)<br>
 +
(OID: ????)
 +
 
 +
===Erkrankungsdaten===
 +
 
 +
 
 +
{| class="hl7table"
 +
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 +
|-
 +
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werden die Daten zur Erkankung übermittelt.
 +
|-
 +
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 +
|-
 +
| ???? || O ||
 +
|}
 +
 
 +
[[file:Cdaonk_erkrankungsdaten.gif|Erkrankungsdaten]]
 +
 +
Abbildung ??: Erkrankungsdaten
  
  
Zeile 3.325: Zeile 3.251:
  
  
TODO Abgleich Klassifikationsliste KRBW (Altmann)
+
????????
  
Anlaß der Diagnosestellung
+
{{AlertBox|Erkrankungsdaten = Observation}}
  
{|class="hl7table"
+
ID<br>
|-
+
Adresse Erkrankungszeitpunkt<br>
!Code
+
<br>
!Beschreibung
+
Diagnosetext<br>
|-
+
Diagnosedatum<br>
|E || Eigenuntersuchung (Selbstuntersuchung)
+
Code+System<br>
|-
+
Diagnosecode<br>
|F || gesetzl. Früherkennung
+
Diagnosesicherheit<br>
|-
+
Diagnoseanlass
|V || nicht gesetzl Vorsorge
 
|-
 
|C || Screening
 
|-
 
|A || Anamnese
 
|-
 
|N || Nachsorge
 
|-
 
|T || Tumorsymptomatik
 
|-
 
|U || Unbekannt
 
|}
 
  
Art der Diagnosesicherung
 
  
{|class="hl7table"
+
<syntaxhighlight lang="xml">
|-
+
<!-- Erkrankung -->
!Code
+
  <observation classCode="OBS" moodCode="EVN" >
!Beschreibung
+
    <!—- Siehe identifikatoren -->
|-
+
    <!-- Jede Tumorerkrankung bekommt eine eigene, über die Zeit konstante ID, s.o. -->
|1 || klinisch ohne spez. Diagnostik
+
    <id root="<OID-des Senders>" extension="4711-0815-123">
|-
+
    <code code="?DX?" codeSystem="2.16.840.1.113883.3.7.1.?"
|2 || klinische Diagnostik
+
      codeSystemName="LOINC" displayName="?Primärerkrankung"/>
|-
+
    <statusCode code="completed"/>
|4 || spez. Tumormaker
+
    <effectiveTime>
 +
      <low value="20110112"/>
 +
    </effectiveTime>
 +
    <value xsi:type="CD" code="C50.1" codeSystem="1.2.276.0.76.5.311"
 +
      codeSystemName="ICD10gm2011">
 +
<originalText>Mammakarzinom</originalText>
 +
<qualifier>
 +
  <name code="8" codeSystem="2.16.840.1.113883.3.7.1"
 +
    displayName="Diagnosesicherheit"/>
 +
  <value code="G" codeSystem="2.16.840.1.113883.3.7.1.8"
 +
    displayName="Gesichert"/>
 +
</qualifier>
 +
<qualifier>
 +
  <name code="?" codeSystem="?siehe Anhang 1.?"
 +
displayName = "Diagnoseanlass"/>
 +
  <value code="V" codeSystem = "?Diagnoseanlass?"
 +
displayName = "Vorsorge"/>
 +
</qualifier>
 +
    </value>
 +
  </observation>
 +
</syntaxhighlight>
 +
 
 +
===Phänomendaten===
 +
 
 +
 
 +
{| class="hl7table"
 +
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|-
|5 || Zytologie
+
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werdne die Daten zum Phänomen übermittelt.
 
|-
 
|-
|6 || Histologie Metastase
+
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|-
 
|-
|7 || Histologie Primärtumor
+
| ???? || O ||
 
|}
 
|}
  
[[file:Cdaonk_diagnostik.gif|Diagnostik]]
+
[[file:Cdaonk_phaenomendaten.gif|Phänomendaten]]
 
   
 
   
Abbildung 21: Diagnostik
+
Abbildung ??: Phänomendaten
 
 
=> Abschnitt Verlaufsbeurteilung
 
  
 
{| class="hl7table"
 
{| class="hl7table"
!Code!!Bedeutung!!Erläuterung
+
! Lvl
|-
+
! RIM
|K||keine Fernmetastasen nachweisbar||
+
! AE
|-
+
! Name
|E||Fernmetastasen vor Ersttherapie||
+
! Desc
|-
+
! DT
|M||verbliebene Fernmetastasen||
+
! Kard
|-
+
! Conf
|R||neu aufgetretene Fernmetastasen (Rezidiv)||
+
! Beschreibung
|-
 
|B||neue und verbliebene Fernmetastasen||
 
|-
 
|F||fraglicher Befund||
 
|-
 
|X||unbekannt||
 
|-
 
|}
 
Tabelle 12: Vocabulary Domain für Art der Fernmetastasen (Kap 3.11.3.1)
 
  
  
=> Phänomendaten
+
|-
 +
|1
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
  
{| class="hl7table"
 
!Code!!Bedeutung!!Erläuterung
 
 
|-
 
|-
|PUL||Lunge||
+
| 2
 +
|bgcolor="ffaaaa"| rel
 +
| elm
 +
|  
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|OSS||Knochen||
+
| 1
|-
+
|bgcolor="ccffff"| part
|HEP||Leber||
+
| elm
 +
|  
 +
|  
 +
|  
 +
|  
 +
|  
 +
|  
 +
 
 
|-
 
|-
|BRA||Hirn||
+
| 2
|-
+
|bgcolor="ffff88"| role
|LYM||Lymphknoten||
+
| elm
|-
+
|  
|MAR||Knochenmark||
+
|  
|-
+
|  
|PLE||Pleura||
+
|  
|-
+
|  
|PER||Peritoneum||
+
|
|-
 
|ADR||Nebennieren||
 
|-
 
|SKI||Haut||
 
|-
 
|SPL||Milz||
 
|-
 
|GEN||Generalisierte Metastasierung||
 
|-
 
|OTH||andere Organe||
 
|-
 
|}
 
Tabelle 13: Vocabulary Domain für das Organlokalisation für Fernmetastasen (Kap. 2.15.2 u. 3.11.3.2)
 
 
 
=> Abschnitt Verlaufsbeurteilung
 
  
{| class="hl7table"
 
!Code!!Bedeutung!!Erläuterung
 
|-
 
|K||kein Tumor nachweisbar||
 
|-
 
|E||Primärtumor vor Ersttherapie||
 
|-
 
|T||Tumorreste ( Residualtumor )||
 
|-
 
|R||LokalRezidiv||
 
|-
 
|F||fraglicher Befund||
 
|-
 
|X||Unbekannt||
 
 
|-
 
|-
 +
|4
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
|}
 
|}
Tabelle 14: Vocabulary Domain für Primäturmor (Kap. 3.11.1)
 
  
=> Abschnitt Verlaufsbeurteilung
 
  
{| class="hl7table"
 
!Code!!Bedeutung!!Erläuterung
 
|-
 
|K||keine regionären Lymphknotenmetastasen||
 
|-
 
|E||Lymphknotenmetastase(n) vor der Ersttherapie||
 
|-
 
|T||ResidualTumor in regionären Lymphknoten||
 
|-
 
|R||Lymphknotenrezidiv / neu aufgetretene Lymphknotenmetastasen||
 
|-
 
|B||verbliebene und neue Lymphknotenmetastasen / LK-Rezidiv||
 
|-
 
|F||fraglicher Befund||
 
|-
 
|X||Unbekannt||
 
|-
 
|}
 
Tabelle 15: Vocabulary Domain für regionäre Lymphknotenmetastasen (Kap.3.11.2)
 
  
{| class="hl7table"
+
{{AlertBox|
!Code!!Bedeutung!!Erläuterung
+
Phaenomendaten &eq; Observation
|-
+
}}
|L||Lokoregionär||
+
 
|-
+
 
|F||Fernmetastase(n)||
+
====Phänomen Primärtumor====
|-
+
Codierung nach Lokalisationsschlüssel oder alternativ ICD-O-3 Topographie.
|B||Beides (Lokoregionär und Fernmetastase(n))||
+
 
|-
+
Todo: Beispiel Unterschiede ICD-ICD-0. Beispiel Unterschied Topographie Lokalisations¬schlüssels.
|X||Unbekannt||
+
 
|-
+
OIDs für die Schlüsselsysteme
|}
+
Seitenangabe als Qualifier gemäß Qualifier für ICD im Diagnoseleitfaden
Tabelle 16: Vocabulary Domain für Residualtumor (Kap.4.2.2)
+
Zu klären kostenlose Verwendbarkeit der SNOMED Einträge für Seitenangabe, ansonsten eigene Liste
 +
 
 +
 
 +
====Phänomen Fernmetastase====
 +
 
 +
Codierung nach Dreisteller laut TNM, Lokalisationsschlüssel oder ICD-O-3 Topographie
 +
 
 +
OIDs für die Schlüsselsysteme
 +
 
 +
 
 +
====Phänomen Komplikation: das Attribut - code====
 +
 
 +
{{AttDesc
 +
| ae = att
 +
| rim = act
 +
| name = @code
 +
| desc = Ziel der Intention
 +
| dt = CD CWE
 +
| card = 0..1
 +
| conf = required
 +
}}
 +
 
  
====Anlass der Diagnosestellung====
 
als Qualifier ????
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Code!!Bedeutung!!Erläuterung
 
!Code!!Bedeutung!!Erläuterung
 
|-
 
|-
|E||Eigenuntersuchung (Selbstuntersuchung)||
+
|ABD||Abszeß in einem Drainagekanal||
 
|-
 
|-
|F||Gesetz. Früherkennung||
+
|ABS||Abszeß, intraabdominaler oder intrathorakaler (z.B. Leberabszeß, subphrenischer Abszeß)||
 
|-
 
|-
|V||Nicht gesetzl. Vorsorge||
+
|AEE||Anastomoseninsuffizienz einer Enterostomie||
 
|-
 
|-
|C||Screening||
+
|AEP||Alkoholentzugspsychose||
 
|-
 
|-
|A||Anamnese||
+
|ALR||Allergische Reaktion ohne Schocksymptomatik||
 
|-
 
|-
|N||Nachsorge||
+
|ANI||Akute Niereninsuffizienz||
 
|-
 
|-
|}
+
|ANS||Anaphylaktischer Schock||
Tabelle 17: Vocabulary Domain für Diagnoseanlass
 
 
 
====Diagnosesicherung====
 
Wie ist die Diagnose gesichert worden?
 
 
 
{| class="hl7table"
 
!Code!!Bedeutung!!Erläuterung
 
 
|-
 
|-
|1||Klinische spez. Diagnostik||
+
|API||Apoplektischer Insult||
 
|-
 
|-
|2||Klinische Diagnostik||
+
|ASF||Abszeß, subfaszialer||
 
|-
 
|-
|4||Spez. Tumormarker||
+
|BIF||Biliäre Fistel||
 
|-
 
|-
|5||Zytologie||
+
|BOE||Bolusverlegung eines Endotubus||
 
|-
 
|-
|6||Histologie Metastase||
+
|BOG||Blutung, obere gastrointestinale (z.B "Streßulkus")||
 
|-
 
|-
|7||Histologie Primärtumor||
+
|BSI||Bronchusstumpfinsuffizienz||
 
|-
 
|-
|}
+
|CHI||Cholangitis||
Tabelle 18: Vocabulary Domain für Diagnosesicherung
 
 
 
 
 
 
 
====Tabellen für TNM aus dem Diagnoseleitfaden====
 
Die nachfolgenden Tabellen sind implizit schon im Diagnoseleitfaden enthalten und können deshalb hier entfallen!
 
 
 
{| class="hl7table"
 
!Code!!Bedeutung!!Erläuterung
 
 
|-
 
|-
|R0||R0 (kein Residualtumor)||
+
|DAI||Darmanastomoseninsuffizienz||
 
|-
 
|-
|R1||R1 (mikroskopischer Residualtumor)||
+
|DEP||Drogenentzugspsychose||
 
|-
 
|-
|R2||R2||
+
|DIC||Disseminierte intravasale Koagulopathie||
 
|-
 
|-
|R2a||R2a (makr.Residualtumor, mikr. nicht bestätigt)||
+
|DLU||Druck- und Lagerungsschäden, z.B. Dekubitalulzera||
 
|-
 
|-
|R2b||R2b (makr.Residualtumor, mikroskop. bestätigt)||
+
|DPS||Darmpassagestörungen (z.B. protrahierte Atonie, Subileus, Ileus)||
 
|-
 
|-
|RX||RX (Vorhandensein von Residualtumor kann n. beurteilt werden)||
+
|DSI||Duodenalstumpfinsuffizienz||
 
|-
 
|-
|}
+
|ENF||Enterale Fistel||
Tabelle 19: Vocabulary Domain für TNM R-Klassifikation (Kap.4.2.1)
 
 
 
=> Phänomen und Erkrankungsdaten, Spezifikation Diagnoseleitfaden
 
 
 
 
 
====Referenzen====
 
* Phänomen => über entryRelationship/observation
 
* Erkankungsdaten => über entryRelationship/observation
 
* Participant => über participation
 
 
 
===Todesursache===
 
 
 
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
 
|-
 
|-
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werden die Informationen zur Todesursache übermittelt.
+
|GER||Gerinnungsstörung||
 
|-
 
|-
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
+
|HAE||Hämorrhagischer Schock||
 
|-
 
|-
| ???? || O ||
+
|HEM||Hämatemesis||
|}
 
 
 
Die Übermittlung der Todesursache wird über eine separate Observation ausgedrückt, die aber in demselben Abschnitt (Section) untergebracht wird:
 
 
 
#[[file:Cdaonk_diagnostik2.gif|Diagnostik]]
 
 
Abbildung 22: Diagnostik
 
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
 
 
 
|-
 
|-
|1
+
|HFI||Harnfistel||
|bgcolor="ff8888"|act
+
|-
|elm
+
|HNA||Hirnnervenausfälle||
|Section
 
|
 
|
 
|0..1
 
|
 
|Dieser Abschnitt übermittelt Informationen über die Todesursache.
 
 
 
 
|-
 
|-
|2
+
|HNK||Hautnekrose im Operationsbereich||
|bgcolor="ff8888"|act
 
|att
 
|@code
 
|
 
|CD CWE
 
|1..1
 
|M
 
|Dieser Code besagt, dass dieser Abschnitt über die Todesursache berichtet.
 
 
 
 
|-
 
|-
| 2
+
|HOP||Hirnorganisches Psychosyndrom (z.B. "Durchgangssyndrom")||
|bgcolor="ffaaaa"| rel
 
| elm
 
| Entry
 
|
 
|
 
|
 
|
 
|
 
 
 
 
|-
 
|-
|3
+
|HRS||Herzrhythmusstörungen||
|bgcolor="ff8888"|act
 
|elm
 
|Observation
 
|Tod
 
|
 
|
 
|
 
|
 
 
 
 
|-
 
|-
|4
+
|HUR||Hämaturie||
|bgcolor="ff8888"|act
+
|-
|elm
+
|HYB||Hyperbilirubinämie||
|Observation
 
|Tod durch Tumor
 
|
 
|1..1
 
|M
 
|
 
 
 
 
|-
 
|-
|5
+
|HYF||Hypopharynxfistel||
|bgcolor="ff8888"|act
 
|att
 
|@code
 
|Tod durch Tumor
 
|CD CWE
 
|1..1
 
|M
 
|Dieses Attribut drückt aus, dass diese Beobachtung Aufschluss über die Todesursache gibt.
 
 
 
 
|-
 
|-
|5
+
|HZI||Herzinsuffizienz||
|bgcolor="ff8888"|act
 
|att
 
|@value
 
|Tod durch Tumor
 
|CD CWE
 
|1..1
 
|M
 
|Hier wird die Information (Code) zur Todesursache eingetragen: s.u. Codesystem zur Todesursache.
 
 
 
 
|-
 
|-
|5
+
|IFV||Ileofemorale Venenthrombose||
|bgcolor="ff8888"|act
 
|att
 
|@negationInd
 
|Negation
 
|BL
 
|0..1
 
|
 
|Wenn gesetzt drückt dieses Attribut aus, dass der Tumor nicht tumorbedingt ist/war.
 
 
 
 
|-
 
|-
| 4
+
|KAS||Kardiogener Schock||
|bgcolor="ffaaaa"| rel
+
|-
| elm
+
|KDS||Kurzdarmsyndrom||
| Entry
 
|  
 
|  
 
|  
 
|  
 
|
 
 
 
 
|-
 
|-
|5
+
|KES||Komplikationen einer Stomaanlage||
|bgcolor="ff8888"|act
 
|elm
 
|Observation
 
|Beruf
 
|
 
|
 
|
 
|Spezialfall einiger EKR (z.B. GKR Gemeinsames Krebsregister, längster letzter Beruf, Dauer) => spätere Ausbauphase. Wird als Freitext und ggf. nach speziellem Berufe¬schlüssel übermittelt.
 
 
 
 
|-
 
|-
|6
+
|KIM||Komplikation eines Implantates (Gefäßprothese, Totalendoprothese, Katheter), z.B. Dislokation||
|bgcolor="ff8888"|act
 
|att
 
|@code
 
|Tod durch Beruf
 
|CD CWE
 
|1..1
 
|M
 
|Dieses Attribut drückt aus, dass diese Beobachtung angibt, ob der Tod ursächlich durch die Berufsausübung veranlasst ist.
 
 
 
 
|-
 
|-
|6
+
|KRA||Krampfanfall||
|bgcolor="ff8888"|act
 
|att
 
|@value
 
|Tod durch Beruf
 
|BL
 
|1..1
 
|
 
|Ein boolescher Wert gibt an, ob der Krebs durch die Berufsausübung (Kap. 1.8.5) entstanden ist.
 
Wenn diese Aussage nicht gesichert (Verdacht) ist, dann wird dies über einen entsprechenden qualifier zum Ausdruck gebracht. Wenn nicht klar ist, ob die Berufsausübung ursächlich für den Krebs ist, dann ist dies durch einen nullFlavor auszudrücken.
 
 
 
 
 
 
|-
 
|-
|6
+
|LEV||Leberversagen||
|bgcolor="ff8888"|act
+
|-
|att
+
|LOE||Lungenödem||
|@negationInd
 
|Negation
 
|BL
 
|0..1
 
|
 
|Wenn gesetzt drückt dieses Attribut aus, dass der Tumor nicht berufsbedingt ist/war.
 
 
 
|}
 
 
 
 
 
{| class="hl7table"
 
!Lvl!!Code!!Bedeutung!!Erläuterung
 
 
|-
 
|-
|1||J||Tod tumorbedingt, keine nähere Angabe||
+
|LYE||Lymphozele||
 
|-
 
|-
|2||T||Tod tumorbedingt durch das Tumorleiden, keine nähere Angabe||
+
|LYF||Lymphfistel||
 
|-
 
|-
|2||P||Tod tumorbedingt durch Progression des primären Tumorgeschehens||
+
|MAT||Mesenterialarterien- oder -venenthrombose||
 
|-
 
|-
|2||L||Tod tumorbedingt durch lokoregionäres Rezidiv||
+
|MED||Mediastinitis||
 
|-
 
|-
|2||M||Tod tumorbedingt durch Fernmetastasierung||
+
|MES||Magenentleerungsstörung||
 
|-
 
|-
|2||B||Tod tumorbedingt durch Behandlungskomplikation||
+
|MIL||Mechanischer Ileus||
 
|-
 
|-
|1||E||Entscheidung nicht möglich||
+
|MYI||Myokardinfarkt||
 
|-
 
|-
|1||nullFlavor="NI" ||„unbekannt" wird über einen nullFlavor zum Ausdruck gebracht.||
+
|NAB||Nachblutung, nicht revisionsbedürftig, anderweitig nicht erwähnt||
|}
 
Tabelle 20: Vocabulary Domain für Todesursache (Kap 7.5)<br>
 
(OID: ????)
 
 
 
===Erkrankungsdaten===
 
 
 
 
 
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
 
|-
 
|-
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werden die Daten zur Erkankung übermittelt.
+
|NIN||Nahtinsuffizienz, anderweitig nicht erwähnt||
 
|-
 
|-
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
+
|OES||Ösophagitis||
 
|-
 
|-
| ???? || O ||
+
|OSM||Osteitis, Osteomyelitis||
|}
+
|-
 
+
|PAB||Peranale Blutung||
[[file:Cdaonk_erkrankungsdaten.gif|Erkrankungsdaten]]
+
|-
+
|PAE||Pulmonalarterienembolie||
Abbildung ??: Erkrankungsdaten
 
 
 
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
 
 
 
|-
 
|-
|1
+
|PAF||Pankreasfistel||
|bgcolor="ff8888"|act
 
|elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
 
 
|-
 
|-
| 2
+
|PAV||Peripherer arterieller Verschluß (Embolie, Thrombose)||
|bgcolor="ffaaaa"| rel
 
| elm
 
|  
 
|
 
|
 
|
 
|
 
|
 
 
 
 
|-
 
|-
| 1
+
|PDA||Protrahierte Darmatonie (paralytischer Ileus)||
|bgcolor="ccffff"| part
+
|-
| elm
+
|PER||Peritonitis||
|  
+
|-
|  
+
|PEY||Pleuraempyem||
|  
+
|-
|  
+
|PIT||Pankreatitis||
|  
+
|-
|  
+
|PLB||Platzbauch||
 
+
|-
 +
|PLE||Pleuraerguß||
 +
|-
 +
|PMN||Pneumonie||
 +
|-
 +
|PNT||Pneumothorax||
 
|-
 
|-
| 2
+
|PPA||Periphere Parese||
|bgcolor="ffff88"| role
 
| elm
 
|  
 
|
 
|
 
|
 
|
 
|
 
 
 
 
|-
 
|-
|4
+
|RIN||Respiratorische Insuffizienz||
|bgcolor="88ff88"|ent
+
|-
| elm
+
|RNB||Nachblutung, revisionsbedürftig, anderweitig nicht erwähnt||
|  
+
|-
|  
+
|RPA||Rekurrensparese||
|  
+
|-
|  
+
|SES||Septischer Schock||
|  
+
|-
|
+
|SFH||Störungen des Flüssigkeits-, Elektrolyt- und Säurebasenhaushaltes||
 
+
|-
|}
+
|SKI||Septische Komplikation eines Implantates||
 
+
|-
 
+
|SON||sonstige Komplikationen||
 
+
|-
????????
+
|STK||Stomakomplikation (z.B. Blutung, Nekrose, Stenose)||
 +
|-
 +
|TIA||TIA (transitorische ischämische Attacke) oder RIND (reversibles ischämisches neurologisches Defizit)||
 +
|-
 +
|TRZ||Transfusionszwischenfall||
 +
|-
 +
|TZP||Thrombozytopenie||
 +
|-
 +
|WSS||Wundheilungsstörung, subkutane||
 +
|-
 +
|WSSnr||Wundheilungsstörung, subkutane, nicht revisionsbedürftig||
 +
|-
 +
|WSSr||Wundheilungsstörung, subkutane, revisionsbedürftig||
 +
|-
 +
|WUH||Wundhämatom (konservativ therapiert)||
 +
|-
 +
|}
 +
Tabelle 21: Vocabulary Domain für Phänomen Codes
  
{{AlertBox|Erkrankungsdaten = Observation}}
 
  
ID<br>
+
Qualifier für Revisionsbedürftigkeit
Adresse Erkrankungszeitpunkt<br>
 
<br>
 
Diagnosetext<br>
 
Diagnosedatum<br>
 
Code+System<br>
 
Diagnosecode<br>
 
Diagnosesicherheit<br>
 
Diagnoseanlass
 
  
 +
Die Festlegung, wie Revisionsbedürftigkeit festzustellen ist, erfolgt im jeweiligen Kontext und wird z.B. durch ONKOZERT-Kriterien festgelegt.
  
<syntaxhighlight lang="xml">
+
{| class="hl7table"
<!-- Erkrankung -->
+
!Code!!Bedeutung!!Erläuterung
  <observation classCode="OBS" moodCode="EVN" >
+
|-
    <!—- Siehe identifikatoren -->
+
|J||Ja, revisionsbedürftig||
    <!-- Jede Tumorerkrankung bekommt eine eigene, über die Zeit konstante ID, s.o. -->
+
|-
    <id root="<OID-des Senders>" extension="4711-0815-123">
+
|N||Nein, nicht revisionsbedürftig||
    <code code="?DX?" codeSystem="2.16.840.1.113883.3.7.1.?"
+
|-
      codeSystemName="LOINC" displayName="?Primärerkrankung"/>
+
|U||Unbekannt||
    <statusCode code="completed"/>
+
|-
    <effectiveTime>
+
|}
      <low value="20110112"/>
+
Tabelle 22: Vocabulary Domain für Qualifier zu Phänomenen
    </effectiveTime>
 
    <value xsi:type="CD" code="C50.1" codeSystem="1.2.276.0.76.5.311"
 
      codeSystemName="ICD10gm2011">
 
<originalText>Mammakarzinom</originalText>
 
<qualifier>
 
  <name code="8" codeSystem="2.16.840.1.113883.3.7.1"
 
    displayName="Diagnosesicherheit"/>
 
  <value code="G" codeSystem="2.16.840.1.113883.3.7.1.8"
 
    displayName="Gesichert"/>
 
</qualifier>
 
<qualifier>
 
  <name code="?" codeSystem="?siehe Anhang 1.?"
 
displayName = "Diagnoseanlass"/>
 
  <value code="V" codeSystem = "?Diagnoseanlass?"
 
displayName = "Vorsorge"/>
 
</qualifier>
 
    </value>
 
  </observation>
 
</syntaxhighlight>
 
  
===Phänomendaten===
+
===Operation (operative Therapie) ===
  
  
 
{| class="hl7table"
 
{| class="hl7table"
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
+
|bgcolor="ddddff"|Template ID|| colspan=2 | 1.2.276.0.76.3.1.131.1.10.2.7 ????
 
|-
 
|-
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werdne die Daten zum Phänomen übermittelt.
+
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werden die Daten über die Operation übermittelt.
 
|-
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
Zeile 3.909: Zeile 3.617:
 
|}
 
|}
  
[[file:Cdaonk_phaenomendaten.gif|Phänomendaten]]
 
 
Abbildung ??: Phänomendaten
 
  
{| class="hl7table"
+
Die Operation ist ein Eingriff zu therapeutischen (Beispiel: Ablation der Mamma) oder diagnostischen (Beispiel: Stanzbiopsie) Zwecken. Neben den durchgeführten Prozeduren sind hier auch die Intention der Therapie, die durchführenden Personen (Operateure) sowie die ggf. aufgetretenen Komplikationen von Bedeutung.
! Lvl
+
 
! RIM
+
Eine operative Therapie kann aus mehreren Operationen bestehen. Hierbei wird für jede Operation ein Entry in der Section „Operative Therapie“ generiert.
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
  
  
|-
+
[[file:Cdaonk_operation.gif|Operation]]
|1
+
|bgcolor="ff8888"|act
+
Abbildung 23: Operation
|elm
 
|
 
|
 
|
 
|
 
|
 
|
 
  
|-
+
<syntaxhighlight lang="xml">
| 2
+
<component>
|bgcolor="ffaaaa"| rel
+
<section>
| elm
+
<templateId root="1.2.276.0.76.3.1.131.1.10.2.7"/>
|
+
<code code="" codesystem="" />
|
+
<title>Operative Therapie</title>
|
+
<text>
|
+
Brusterhaltende Exzision der Mamma links am 31.03.2011, kurativ.<br>
|
+
Operateur: Dr. med. Max Meier PhD<br>
|
+
Partielle (brusterhaltende) Exzision der Mamma<br>
 
+
Sentinel-Lymphonodektomie mit Radionuklidmarkierung<br>
|-
+
Komplikationen sind aufgetreten:<br>
| 1
+
<ul>
|bgcolor="ccffff"| part
+
<il>subkutane Wundheilungsstörung, nicht revisionsbedürftig</il>
| elm
+
</ul>
|
+
</text>
|
+
<entry typeCode="DRIV">
|
+
<procedure classCode="PROC" moodCode="EVN">
|
+
<templateID root="??????"/>
|
+
<id extension="op12345"
|
+
root="1.2.276.0.76.3.1.131.1.4.3.9999.9999.999911"/>
 
+
<code code="OP" displayName="Operation"
|-
+
codeSystem="1.2.276.0.76.3.1.131.1.5.14">
| 2
+
<qualifier>
|bgcolor="ffff88"| role
+
<name code="IntentionOfTherapy"
| elm
+
codeSystem="1.2.276.0.76.3.1.131.1.5.1"/>
|
+
<value xsi:type="CD" code="K"
|
+
codeSystem="1.2.276.0.76.3.1.131.1.5.18"/>
|
+
</qualifier>
|
+
</code>
|
+
<statusCode code="completed"/>
|
+
<effectiveTime value="20110331"/>
 
+
<performer typeCode="PRF">
|-
+
<assignedEntity>
|4
+
<id extension="54321"
|bgcolor="88ff88"|ent
+
root="1.2.276.0.76.3.1.131.1.4.3.9999.9999.999905"/>
| elm
+
<assignedPerson>
|
+
<name>
|
+
<prefix qualifier="AC">Dr. med.</prefix>
|
+
<given>Max</given>
|
+
<family>Meier</family>
|
+
<suffix qualifier="AC">PhD</suffix>
|
+
</name>
 
+
</assignedPerson>
|}
+
</assignedEntity>
 
+
</performer>
 
+
<entryRelationship typeCode="COMP">
 
+
<procedure classCode="PROC" moodCode="EVN">
{{AlertBox|
+
<code code="5-870.60" codeSystem="1.2.276.0.76.5.410"/>
Phaenomendaten &eq; Observation
+
</procedure>
}}
+
</entryRelationship>
 
+
<entryRelationship typeCode="COMP">
 
+
<procedure classCode="PROC" moodCode="EVN">
====Phänomen Primärtumor====
+
<code code="5-401.11" codeSystem="1.2.276.0.76.5.410"/>
Codierung nach Lokalisationsschlüssel oder alternativ ICD-O-3 Topographie.
+
</procedure>
 
+
</entryRelationship>
Todo: Beispiel Unterschiede ICD-ICD-0. Beispiel Unterschied Topographie Lokalisations¬schlüssels.
+
<entryRelationship typeCode="SPRT">
 +
<observation classCode="OBS" moodCode="EVN">
 +
<code code="116224001" codeSystem="2.16.840.1.113883.6.96"/>
 +
<value xsi:type="BL" value="true"/>
 +
</observation>
 +
</entryRelationship>
 +
<entryRelationship typeCode="SPRT">
 +
<observation classCode="OBS" moodCode="EVN">
 +
<code code="116224001" codeSystem="2.16.840.1.113883.6.96"/>
 +
<value xsi:type="CD" code="WSSnr"
 +
codeSystem="1.2.276.0.76.3.1.131.1.5.15">
 +
<originalText>
 +
subkutane Wundheilungsstörung,
 +
nicht revisionsbedürftig
 +
</originalText>
 +
</value>
 +
</observation>
 +
</entryRelationship>
 +
</procedure>
 +
</entry>
 +
</section>
 +
</component>
 +
</syntaxhighlight>
  
OIDs für die Schlüsselsysteme
 
Seitenangabe als Qualifier gemäß Qualifier für ICD im Diagnoseleitfaden
 
Zu klären kostenlose Verwendbarkeit der SNOMED Einträge für Seitenangabe, ansonsten eigene Liste
 
  
 +
{| class="hl7table"
 +
! Lvl
 +
! RIM
 +
! AE
 +
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
  
====Phänomen Fernmetastase====
+
|-
 +
| 0
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| section
 +
|
 +
|
 +
| 1..1
 +
| required
 +
| Dieses Element enthält den Text.
  
Codierung nach Dreisteller laut TNM, Lokalisationsschlüssel oder ICD-O-3 Topographie
+
|-
 +
| 1
 +
|bgcolor="ff8888"| act
 +
| att
 +
| @classCode
 +
| "DOCSECT"
 +
| ST
 +
| 1..1
 +
| required
 +
|
  
OIDs für die Schlüsselsysteme
+
|-
 +
| 1
 +
|bgcolor="ff8888"| act
 +
| att
 +
| @moodCode
 +
| "EVN"
 +
| ST
 +
| 1..1
 +
| required
 +
|
  
 +
|-
 +
| 1
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| code
 +
| Code
 +
| ST
 +
| 1..1
 +
| required
 +
| Dieser Code definiert den Inhalt des Abschnittes.
  
====Phänomen Komplikation: das Attribut - code====
+
|-
 +
| 1
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| title
 +
| title
 +
| ST
 +
| 1..1
 +
| required
 +
| Dieses Element gibt die Überschrift des Abschnittes an.
  
{{AttDesc
+
|-
| ae = att
+
| 1
| rim = act
+
|bgcolor="ff8888"|act
| name = @code
+
| elm
| desc = Ziel der Intention
+
| text
| dt = CD CWE
+
| text
| card = 0..1
+
| ST
| conf = required
+
| 1..1
}}
+
| required
 +
| Dieses Element enthält den Text.
 +
Hier werden alle strukturiert enthaltenen Daten der Section als Freitext übermittelt. Für Operationen ist zusätzlich die Übermittlung zusätzlicher unstrukturierter Informationen zulässig.
  
  
 +
|-
 +
| 1
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| procedure
 +
|
 +
|
 +
| 1..1
 +
| required
 +
| Dieses Element repräsentiert die gesamte (einzelne) Operation.
  
{| class="hl7table"
 
!Code!!Bedeutung!!Erläuterung
 
 
|-
 
|-
|ABD||Abszeß in einem Drainagekanal||
+
|2
 +
|bgcolor="ff8888"| act
 +
| att
 +
| procedure@classCode
 +
| classCode <= PROC
 +
 +
| 1..1
 +
|
 +
|
 +
 
 
|-
 
|-
|ABS||Abszeß, intraabdominaler oder intrathorakaler (z.B. Leberabszeß, subphrenischer Abszeß)||
+
|2
|-
+
|bgcolor="ff8888"| act
|AEE||Anastomoseninsuffizienz einer Enterostomie||
+
| att
|-
+
| @moodCode
|AEP||Alkoholentzugspsychose||
+
| <= x_DocumentProcedureMood
 +
|
 +
| 1..1
 +
|
 +
|
 +
 
 
|-
 
|-
|ALR||Allergische Reaktion ohne Schocksymptomatik||
+
|2
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| id
 +
| Identifikation der Operation
 +
| SET<II>
 +
| 1..*
 +
| required
 +
|Über dieses Element wird die Operation eindeutig identifiziert. Somit ist dieses Element required. Die Kombination der Attribute root und extension identifiziert die Operation systemübergreifend eindeutig.
 +
 
 
|-
 
|-
|ANI||Akute Niereninsuffizienz||
+
|3
 +
|bgcolor="ff8888"| act
 +
| att
 +
| @root
 +
| Root-OID
 +
| ST
 +
| 1..1
 +
| required
 +
|Dieses Attribut ist ein eindeutiger Identifikator für Operationen innerhalb eines bestimmten sendenden Systems.
 +
 
 +
 
 
|-
 
|-
|ANS||Anaphylaktischer Schock||
+
|3
 +
|bgcolor="ff8888"| act
 +
| att
 +
| @extension
 +
|
 +
| ST
 +
| 1..1
 +
| required
 +
|Dieses Attribut ist innerhalb des sendenden Systems ein eindeutiger Identifikator für die Operation.
 +
 
 +
 
 
|-
 
|-
|API||Apoplektischer Insult||
+
|3
|-
+
|bgcolor="ff8888"| act
|ASF||Abszeß, subfaszialer||
+
| elm
 +
| code
 +
| durchgeführte Operation
 +
| CD CWE
 +
| 0..1
 +
| optional
 +
|
 +
 
 
|-
 
|-
|BIF||Biliäre Fistel||
+
|3
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| text
 +
| Freitext
 +
| ED
 +
| 0..1
 +
| optional
 +
|
 +
 
 
|-
 
|-
|BOE||Bolusverlegung eines Endotubus||
+
|3
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| statusCode
 +
| <= completed
 +
| ST
 +
| 1..1
 +
| required
 +
|Über dieses Attribut wird der Status angegeben, in dem der beschriebene Act sich befindet. Ein Act kann z.B. den Status „new", „active" oder „cancelled" besitzen. Die Beobachtung einer Operation wird mit der Dokumentation als abgeschlossene Handlung betrachtet. Somit wird für das Attribut ''statusCode'' der feste Wert „completed" vorgegeben.
 +
 
 
|-
 
|-
|BOG||Blutung, obere gastrointestinale (z.B "Streßulkus")||
+
|3
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| effectiveTime
 +
| Durchführungszeitraum
 +
| IVL<TS>
 +
| 0..1
 +
| optional
 +
|Dieses Element gibt den Durchführungszeitraum der Therapie an. Benötigt wird Tagesgenauigkeit, bei einer Operation werden daher nicht Beginn und Ende angegeben, sondern das Datum im value-Attribut übermittelt.
 +
 
 
|-
 
|-
|BSI||Bronchusstumpfinsuffizienz||
+
|3
|-
+
|bgcolor="ffbbbb"| rel
|CHI||Cholangitis||
+
| elm
 +
| entryRelationship
 +
| Intention
 +
|  
 +
| 0..1
 +
| optional
 +
|Ziel der Operation.
 +
 
 
|-
 
|-
|DAI||Darmanastomoseninsuffizienz||
+
|4
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| Observation
 +
| Intention
 +
|
 +
| 0..1
 +
| optional
 +
|Ziel der Operation.
 +
 
 
|-
 
|-
|DEP||Drogenentzugspsychose||
+
|5
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| code
 +
| Ziel der Intention
 +
| CD CWE
 +
| 0..1
 +
|
 +
|Diese Klasse im Intent Mood drückt das Ziel aus.
 +
 
 
|-
 
|-
|DIC||Disseminierte intravasale Koagulopathie||
+
| 5
 +
|bgcolor="ff8888"| act
 +
| att
 +
| value
 +
| Ziel der Intention
 +
| CD CWE
 +
| 0..1
 +
|
 +
|
 +
 
 
|-
 
|-
|DLU||Druck- und Lagerungsschäden, z.B. Dekubitalulzera||
+
|3
|-
+
|bgcolor="ffbbbb"| rel
|DPS||Darmpassagestörungen (z.B. protrahierte Atonie, Subileus, Ileus)||
+
| elm
|-
+
| entryRelationship
|DSI||Duodenalstumpfinsuffizienz||
+
| Komplikation
 +
|  
 +
| 0..1
 +
| optional
 +
|
 +
 
 
|-
 
|-
|ENF||Enterale Fistel||
+
|4
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| Observation
 +
| Komplikation
 +
|
 +
| 0..1
 +
| optional
 +
|Oft reicht in Bezug auf Komplikationen die einfache Information aus, ob diese aufgetreten sind. Dies wird als observation innerhalb einer entryRelationship übermittelt.
 +
 
 
|-
 
|-
|GER||Gerinnungsstörung||
+
|5
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| code
 +
| Komplikation
 +
|
 +
| 0..1
 +
| optional
 +
|Der code für diese Observation ist fix. Es wird der entsprechende SNOMED-CT-Code verwendet.
 +
 
 
|-
 
|-
|HAE||Hämorrhagischer Schock||
+
|5
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| value
 +
|
 +
|
 +
| 0..1
 +
| optional
 +
|Die Information, ob Komplikationen aufgetreten sind, wird als boolscher Wert übermittelt. Ist diese Information nicht bekannt, kann dies als nullFlavor="UNK" übermittelt werden.
 +
 
 +
 
 +
 
 
|-
 
|-
|HEM||Hämatemesis||
+
|3
|-
+
|bgcolor="ffbbbb"| rel
|HFI||Harnfistel||
+
| elm
 +
| entryRelationship
 +
| Bestandteil
 +
|  
 +
| 0..1
 +
| optional
 +
|einzelne Prozedur
 +
 
 
|-
 
|-
|HNA||Hirnnervenausfälle||
+
|4
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| Procedure
 +
| Einzelprozeduren
 +
|
 +
| 0..1
 +
| optional
 +
|Eine Operation besteht häufig aus mehreren Einzelprozeduren. Jede Einzelprozedur wird als procedure in einer entryRelationship übermittelt. Beliebig viele entryRelationships sind zulässig.
 +
 
 
|-
 
|-
|HNK||Hautnekrose im Operationsbereich||
+
|5
 +
|bgcolor="ff8888"| act
 +
| elm
 +
| code
 +
|
 +
|
 +
| 0..1
 +
| optional
 +
|Im code-Element werden die durchführten Einzelprozeduren übermittelt. Im Rahmen dieses Leitfadens wird der Operationen- und Prozedurenschlüssel (OPS) verwendet. Zulässig sind alle Fassungen von OPS.
 +
 
 
|-
 
|-
|HOP||Hirnorganisches Psychosyndrom (z.B. "Durchgangssyndrom")||
+
|3
 +
|bgcolor="ccffff"| part
 +
| elm
 +
| performer
 +
| performer
 +
|
 +
| 0..1
 +
| optional
 +
|Hier werden die Angaben zu Operateur(en) übermittelt. Die Übermittlung mehrerer Operateure ist zulässig.
 +
 
 +
 
 +
 
 
|-
 
|-
|HRS||Herzrhythmusstörungen||
+
|4
|-
+
|bgcolor="ffff88"| role
|HUR||Hämaturie||
+
| elm
 +
| AssignedEntity
 +
|  
 +
|  
 +
| 0..1
 +
| optional
 +
|ausführender Arzt
 +
 
 
|-
 
|-
|HYB||Hyperbilirubinämie||
+
|5
 +
|bgcolor="ffff88"| role
 +
| elm
 +
| AssignedEntity.role
 +
|
 +
|
 +
| 0..1
 +
| optional
 +
|Über dieses Element wird der Operateur eindeutig identifiziert. Somit ist dieses Element required. Die Kombination der Attribute root und extension identifiziert den Operateur systemübergreifend eindeutig.
 +
 
 +
 
 
|-
 
|-
|HYF||Hypopharynxfistel||
+
|5
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| Person
 +
|
 +
|
 +
| 0..1
 +
| optional
 +
|Arzt
 +
 
 
|-
 
|-
|HZI||Herzinsuffizienz||
+
|6
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| name
 +
|
 +
| PN
 +
| 0..1
 +
| optional
 +
|Name des Operateurs
 +
 
 
|-
 
|-
|IFV||Ileofemorale Venenthrombose||
+
|3
|-
+
|bgcolor="ccffff"| part
|KAS||Kardiogener Schock||
+
| elm
 +
| participant
 +
| Teilnehmer
 +
|  
 +
| 0..1
 +
| optional
 +
|ausführender Arzt
 +
 
 
|-
 
|-
|KDS||Kurzdarmsyndrom||
+
|4
 +
|bgcolor="ffff88"| role
 +
| elm
 +
| ParticipantRole
 +
|
 +
|
 +
| 0..1
 +
| optional
 +
|sonstiger Teilnehmer
 +
 
 
|-
 
|-
|KES||Komplikationen einer Stomaanlage||
+
|5
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
| Person
 +
|
 +
|
 +
| 0..1
 +
| optional
 +
|Teilnehmer
 +
 
 +
|}
 +
 
 +
 
 +
{| class="hl7table"
 +
!Lvl!!Code!!Bedeutung!!Erläuterung
 
|-
 
|-
|KIM||Komplikation eines Implantates (Gefäßprothese, Totalendoprothese, Katheter), z.B. Dislokation||
+
|1||OP||Operation||1), 2), 3), 4),bei Operativer Therapie Fixwert
 
|-
 
|-
|KRA||Krampfanfall||
+
|1||RAD||Strahlentherapie||1), 2), 3)
 
|-
 
|-
|LEV||Leberversagen||
+
|2||RAD-B||Brachytherapie||4) ADT-Basisdatensatz unter¬scheidet hier in den Strahlen¬therapiedaten endokavitär und interstitiell
 
|-
 
|-
|LOE||Lungenödem||
+
|2||RAD-T||Teletherapie||4)
 
|-
 
|-
|LYE||Lymphozele||
+
|2||RAD-S||sonstige Strahlentherapie||4)
 
|-
 
|-
|LYF||Lymphfistel||
+
|1||NUK||||
 
|-
 
|-
|MAT||Mesenterialarterien- oder -venenthrombose||
+
|2||NUK-J||Radiojodtherapie||4)
 
|-
 
|-
|MED||Mediastinitis||
+
|2||NUK-O||offene Radionuklide||4)
 
|-
 
|-
|MES||Magenentleerungsstörung||
+
|2||NUK-S||sonstige Nuklearmedizinische Therapie||4)
 
|-
 
|-
|MIL||Mechanischer Ileus||
+
|1||CHE||Chemotherapie||1), 2), 3)
 
|-
 
|-
|MYI||Myokardinfarkt||
+
|1||HOR||Hormontherapie / Antihormonelle Therapie||1), 2), 3)
 
|-
 
|-
|NAB||Nachblutung, nicht revisionsbedürftig, anderweitig nicht erwähnt||
+
|1||||||
 
|-
 
|-
|NIN||Nahtinsuffizienz, anderweitig nicht erwähnt||
+
|2||KNTR||Knochenmarktransplantation||1), 2)
 
|-
 
|-
|OES||Ösophagitis||
+
|2||STAMM||Stammzelltransplantation||2)
 
|-
 
|-
|OSM||Osteitis, Osteomyelitis||
+
|3||STAMM-L||Autologe Stammzelltransplantation||4)
 
|-
 
|-
|PAB||Peranale Blutung||
+
|3||STAMM-G||Sonstige Stammzelltransplantation||4)
 
|-
 
|-
|PAE||Pulmonalarterienembolie||
+
|3||STAMM-S||Allogene Stammzelltransplantation||4)
 
|-
 
|-
|PAF||Pankreasfistel||
+
|1||IMM||Antikörper / Immuntherapie||1), 2), 3)
 
|-
 
|-
|PAV||Peripherer arterieller Verschluß (Embolie, Thrombose)||
+
|1||SCHM||Schmerztherapie||2)
 
|-
 
|-
|PDA||Protrahierte Darmatonie (paralytischer Ileus)||
+
|1||PSY||Psychoonkologie||2)
 
|-
 
|-
|PER||Peritonitis||
+
|1||SM||Sonstige Medikamentöse Therapie||4)
 
|-
 
|-
|PEY||Pleuraempyem||
+
|1||WS||Wait and see / Active surveillance||4) Wait and see und Active Surveillance sind eigentlich deutlich verschieden und müssen in Prostata¬karzinom¬zentren unterschieden werden
 
|-
 
|-
|PIT||Pankreatitis||
+
|1||ATH<br>nullFlavour=OTH||Sonstige / andere Therapie||1), 2), 3)
 
|-
 
|-
|PLB||Platzbauch||
+
|2||ATH-HY||Hyperthermie||4)
 
|-
 
|-
|PLE||Pleuraerguß||
+
|}
|-
+
Tabelle 23: Codesystem für Operationen
|PMN||Pneumonie||
+
 
|-
+
# GeKiD-Mindestdatensatz
|PNT||Pneumothorax||
+
# ADT Basisdatensatz „Verlaufsdaten" (HOR wurde dort vergessen, Hormontherapie ist aber auf dem Bogen)
 +
# GKR (Gemeinsames Krebsregister)
 +
# KRBW (Krebsregister Baden-Württemberg)
 +
 
 +
Problematisch ist:
 +
# die unterschiedliche Tiefe , z.B.  RAD allgemein vs. Differenzierung in unterschiedliche Subformen der Strahlen- und nuklearmedizinischen Therapie
 +
# mangelnde Abbildung neuer medikamentöser  (Zytokine, Signal-Transduktions-Inhibitoren, …) und bestimmter Untergruppen supportiver Therapie (z.B. Bisphosphonate)
 +
# mangelnde Abbildung kombinierter Therapien, und damit die Diskussion prä- und post-koordinierter Ansatz .
 +
KRBW: post-koordinierter Ansatz durch eine Kennzeichnung zusammengehöriger Therapien (MULTIMODALE_THERAPIE).
 +
 
 +
 
 +
{| class="hl7table"
 +
!Code!!Bedeutung!!Erläuterung
 
|-
 
|-
|PPA||Periphere Parese||
+
|A||Abgelehnt ||
 
|-
 
|-
|RIN||Respiratorische Insuffizienz||
+
|V||vorgesehen ||
 
|-
 
|-
|RNB||Nachblutung, revisionsbedürftig, anderweitig nicht erwähnt||
+
|T||Terminiert||
 
|-
 
|-
|RPA||Rekurrensparese||
+
|B||Begonnen||
 
|-
 
|-
|SES||Septischer Schock||
+
|R||regulär beendet||
 
|-
 
|-
|SFH||Störungen des Flüssigkeits-, Elektrolyt- und Säurebasenhaushaltes||
+
|||vorzeitig beendet||
 
|-
 
|-
|SKI||Septische Komplikation eines Implantates||
+
|}
 +
Tabelle 25: Codesystem für die Qualifier zu den Operationen
 +
 
 +
 
 +
 
 +
{| class="hl7table"
 +
!Lvl!!Code!!Bedeutung!!Erläuterung!!
 
|-
 
|-
|SON||sonstige Komplikationen||
+
|1||N||Nein||1) (in der Wirklichkeit verbirgt sich hier eine große Zahl unterschiedlicher Negationen, die durchaus im Rahmen von Organzentren relevant sein können)||???
 
|-
 
|-
|STK||Stomakomplikation (z.B. Blutung, Nekrose, Stenose)||
+
|2||N-A||abgelehnt ||3)||rejected
 
|-
 
|-
|TIA||TIA (transitorische ischämische Attacke) oder RIND (reversibles ischämisches neurologisches Defizit)||
+
|1||V||vorgesehen ||2), 4)||statusCode=ActStatusNew
 
|-
 
|-
|TRZ||Transfusionszwischenfall||
+
|2||V-T||terminiert ||4)||moodCode=APT (Mood)???
 
|-
 
|-
|TZP||Thrombozytopenie||
+
|1||J||Ja||1), 2)||statusCode=ActStatusNormal???
 
|-
 
|-
|WSS||Wundheilungsstörung, subkutane||
+
|2||J-B||begonnen ||4) (implizit aus leerem „Ende-Datum")||statusCode=ActStatusActive
 
|-
 
|-
|WSSnr||Wundheilungsstörung, subkutane, nicht revisionsbedürftig||
+
|2||J-E||regulär beendet ||3)||statusCode=ActStatusCompleted
 
|-
 
|-
|WSSr||Wundheilungsstörung, subkutane, revisionsbedürftig||
+
|2||J-A||vorzeitig beendet||3), 5) (Abbruch wegen Nebenwirkungen)||statusCode=ActStatusAborted
|-
 
|WUH||Wundhämatom (konservativ therapiert)||
 
 
|-
 
|-
 +
|1||U||Unbekannt||1)||nullFlavor=UNK
 
|}
 
|}
Tabelle 21: Vocabulary Domain für Phänomen Codes
+
Tabelle 26: Codesystem für Operation statusCode
  
 +
# GeKiD / GKR
 +
# ADT- Basisdatensatz „Verlaufsdaten" (nur implizit)
 +
# Information auf ADT- Basisdatensatz Systemisch und Strahlentherapie
 +
# Information teilweise relevant für Kennzahlenberechnung in Organzentren
 +
# KRBW
  
Qualifier für Revisionsbedürftigkeit
 
 
Die Festlegung, wie Revisionsbedürftigkeit festzustellen ist, erfolgt im jeweiligen Kontext und wird z.B. durch ONKOZERT-Kriterien festgelegt.
 
  
 
{| class="hl7table"
 
{| class="hl7table"
 
!Code!!Bedeutung!!Erläuterung
 
!Code!!Bedeutung!!Erläuterung
 
|-
 
|-
|J||Ja, revisionsbedürftig||
+
|K||kurativ||
 +
|-
 +
|P||palliativ||
 
|-
 
|-
|N||Nein, nicht revisionsbedürftig||
+
|D||diagnostisch||nur bei Operationen
 
|-
 
|-
|U||Unbekannt||
+
|U||unbekannt bzw. nicht anwendbar / sonstige Therapie|| besser nullFlavor
 
|-
 
|-
 
|}
 
|}
Tabelle 22: Vocabulary Domain für Qualifier zu Phänomenen
+
Tabelle 27: Codesystem für Operation code
 +
 
 +
{{AlertBox|
 +
Diese Tabelle passt nicht zur Intention!
 +
}}
  
===Operation (operative Therapie) ===
 
  
 +
Stellung der Therapie im Gesamtkonzept
  
 
{| class="hl7table"
 
{| class="hl7table"
|bgcolor="ddddff"|Template ID|| colspan=2 | 1.2.276.0.76.3.1.131.1.10.2.7 ????
+
!Code!!Bedeutung!!Erläuterung
 +
|-
 +
|N||neoadjuvant||
 +
|-
 +
|I||intraoperativ||(neuer Code, November 2010)
 
|-
 
|-
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werden die Daten über die Operation übermittelt.
+
|A||adjuvant||
 
|-
 
|-
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
+
|U||unbekannt bzw. nicht anwendbar / sonstige Therapie|| besser als nullFlavor
 
|-
 
|-
| ???? || O ||
 
 
|}
 
|}
 +
Tabelle 28: Codesysstem für Operation code
  
 +
{{AlertBox|
 +
Diese Tabelle passt nicht dazu!
 +
}}
  
Die Operation ist ein Eingriff zu therapeutischen (Beispiel: Ablation der Mamma) oder diagnostischen (Beispiel: Stanzbiopsie) Zwecken. Neben den durchgeführten Prozeduren sind hier auch die Intention der Therapie, die durchführenden Personen (Operateure) sowie die ggf. aufgetretenen Komplikationen von Bedeutung.
+
===Bestrahlung ===
  
Eine operative Therapie kann aus mehreren Operationen bestehen. Hierbei wird für jede Operation ein Entry in der Section „Operative Therapie“ generiert.
 
  
 +
{| class="hl7table"
 +
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 +
|-
 +
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werden die Bestrahlungsdaten übermittelt.
 +
|-
 +
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 +
|-
 +
| ???? || O ||
 +
|}
 +
 +
{{AlertBox|
 +
Maßnahmen &equal; Procedure
 +
Als Ergebnis oder als Maßnahme?
 +
}}
 +
 +
Die Bestrahlung an sich ist eine Prozedur. Allerdings bestehen Beziehungen zu Phänomenen, die als Beobachtung kommuniziert werden.
  
[[file:Cdaonk_operation.gif|Operation]]
+
[[file:Cdaonk_bestrahlung.gif|Bestrahlung]]
 
   
 
   
Abbildung 23: Operation
+
Abbildung 24: Bestrahlung
 +
 
 +
{| class="hl7table"
 +
! Lvl
 +
! RIM
 +
! AE
 +
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
 +
 
  
<syntaxhighlight lang="xml">
+
|-
<component>
+
|1
<section>
+
|bgcolor="ff8888"|act
<templateId root="1.2.276.0.76.3.1.131.1.10.2.7"/>
+
|elm
<code code="" codesystem="" />
+
|
<title>Operative Therapie</title>
+
|
<text>
+
|
Brusterhaltende Exzision der Mamma links am 31.03.2011, kurativ.<br>
+
|
Operateur: Dr. med. Max Meier PhD<br>
+
|
Partielle (brusterhaltende) Exzision der Mamma<br>
+
|
Sentinel-Lymphonodektomie mit Radionuklidmarkierung<br>
+
 
Komplikationen sind aufgetreten:<br>
+
|-
<ul>
+
| 2
<il>subkutane Wundheilungsstörung, nicht revisionsbedürftig</il>
+
|bgcolor="ffaaaa"| rel
</ul>
+
| elm
</text>
+
|
<entry typeCode="DRIV">
+
|
<procedure classCode="PROC" moodCode="EVN">
+
|
<templateID root="??????"/>
+
|
<id extension="op12345"
+
|
root="1.2.276.0.76.3.1.131.1.4.3.9999.9999.999911"/>
+
|
<code code="OP" displayName="Operation"
+
 
codeSystem="1.2.276.0.76.3.1.131.1.5.14">
+
|-
<qualifier>
+
| 1
<name code="IntentionOfTherapy"
+
|bgcolor="ccffff"| part
codeSystem="1.2.276.0.76.3.1.131.1.5.1"/>
+
| elm
<value xsi:type="CD" code="K"  
+
|
codeSystem="1.2.276.0.76.3.1.131.1.5.18"/>
+
|
</qualifier>
+
|
</code>
+
|
<statusCode code="completed"/>
+
|
<effectiveTime value="20110331"/>
+
|
<performer typeCode="PRF">
+
 
<assignedEntity>
+
|-
<id extension="54321"
+
| 2
root="1.2.276.0.76.3.1.131.1.4.3.9999.9999.999905"/>
+
|bgcolor="ffff88"| role
<assignedPerson>
+
| elm
<name>
+
|
<prefix qualifier="AC">Dr. med.</prefix>
+
|
<given>Max</given>
+
|
<family>Meier</family>
+
|
<suffix qualifier="AC">PhD</suffix>
+
|
</name>
+
|
</assignedPerson>
+
 
</assignedEntity>
+
|-
</performer>
+
|4
<entryRelationship typeCode="COMP">
+
|bgcolor="88ff88"|ent
<procedure classCode="PROC" moodCode="EVN">
+
| elm
<code code="5-870.60" codeSystem="1.2.276.0.76.5.410"/>
+
|
</procedure>
+
|
</entryRelationship>
+
|
<entryRelationship typeCode="COMP">
+
|
<procedure classCode="PROC" moodCode="EVN">
+
|
<code code="5-401.11" codeSystem="1.2.276.0.76.5.410"/>
+
|
</procedure>
+
 
</entryRelationship>
+
|}
<entryRelationship typeCode="SPRT">
+
 
<observation classCode="OBS" moodCode="EVN">
+
 
<code code="116224001" codeSystem="2.16.840.1.113883.6.96"/>
+
 
<value xsi:type="BL" value="true"/>
+
<syntaxhighlight lang="xml">
</observation>
+
  <component>
</entryRelationship>
+
    <observation classCode="OBS" moodCode="EVN">
<entryRelationship typeCode="SPRT">
+
      <templateId root="2.16.840.1.113883.10.20.5.2.5.1"/>
<observation classCode="OBS" moodCode="EVN">
+
      <code codeSystem="2.16.840.1.113883.6.1"|
<code code="116224001" codeSystem="2.16.840.1.113883.6.96"/>
+
            codeSystemName="LOINC" code="41852-5"
<value xsi:type="CD" code="WSSnr"  
+
            displayName="Microorganism identified"/>
codeSystem="1.2.276.0.76.3.1.131.1.5.15">
+
      <value xsi:type="CD"
<originalText>
+
            codeSystem="2.16.840.1.113883.6.96"
subkutane Wundheilungsstörung,
+
            codeSystemName="SNOMED"
nicht revisionsbedürftig
+
            code="116197008"
</originalText>
+
            displayName="Staphylococcus, coagulase negative (organism)"/>
</value>
+
    </observation>
</observation>
+
  </component>
</entryRelationship>
 
</procedure>
 
</entry>
 
</section>
 
</component>
 
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
 +
===Medikamentendaten ===
  
  
 
{| class="hl7table"
 
{| class="hl7table"
! Lvl
+
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
! RIM  
+
|-
 +
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird die Daten zur Medikation übermittelt.
 +
|-
 +
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 +
|-
 +
| ???? || O ||
 +
|}
 +
 
 +
 
 +
[[file:Cdaonk_medikation2.gif|Medikation]]
 +
 +
Abbildung 26: Medikation (gemäß IHE PCC)
 +
 
 +
{{AlertBox|
 +
Substance Administration
 +
Hinweis auf VHitG Addendum Medikation sowie epSOS!!!
 +
}}
 +
 
 +
{| class="hl7table"
 +
! Lvl
 +
! RIM  
 
! AE  
 
! AE  
 
! Name
 
! Name
Zeile 4.317: Zeile 4.415:
 
! Conf
 
! Conf
 
! Beschreibung  
 
! Beschreibung  
 +
  
 
|-
 
|-
| 0
+
|1
|bgcolor="ff8888"| act
+
|bgcolor="ff8888"|act
| elm
+
|elm
| section
+
|
 +
|
 +
|
 +
|
 +
|
 
|
 
|
|
 
| 1..1
 
| required
 
| Dieses Element enthält den Text.
 
  
 
|-
 
|-
| 1
+
| 2
|bgcolor="ff8888"| act
+
|bgcolor="ffaaaa"| rel
| att
+
| elm
| @classCode
+
|  
| "DOCSECT"
+
|  
| ST
+
|  
| 1..1
+
|  
| required
 
 
|  
 
|  
 +
|
  
 
|-
 
|-
 
| 1
 
| 1
|bgcolor="ff8888"| act
+
|bgcolor="ccffff"| part
| att
+
| elm
| @moodCode
+
|  
| "EVN"
+
|  
| ST
+
|  
| 1..1
+
|  
| required
+
|  
 
|  
 
|  
  
 
|-
 
|-
| 1
+
| 2
|bgcolor="ff8888"| act
+
|bgcolor="ffff88"| role
 
| elm
 
| elm
| code
+
|  
| Code
+
|  
| ST
+
|  
| 1..1
+
|  
| required
+
|  
| Dieser Code definiert den Inhalt des Abschnittes.
+
|
  
 
|-
 
|-
| 1
+
|4
|bgcolor="ff8888"| act
+
|bgcolor="88ff88"|ent
 
| elm
 
| elm
| title
 
| title
 
| ST
 
| 1..1
 
| required
 
| Dieses Element gibt die Überschrift des Abschnittes an.
 
 
|-
 
| 1
 
|bgcolor="ff8888"|act
 
| elm
 
| text
 
| text
 
| ST
 
| 1..1
 
| required
 
| Dieses Element enthält den Text.
 
Hier werden alle strukturiert enthaltenen Daten der Section als Freitext übermittelt. Für Operationen ist zusätzlich die Übermittlung zusätzlicher unstrukturierter Informationen zulässig.
 
 
 
|-
 
| 1
 
|bgcolor="ff8888"| act
 
| elm
 
| procedure
 
 
|  
 
|  
 
|  
 
|  
| 1..1
+
|  
| required
+
|  
| Dieses Element repräsentiert die gesamte (einzelne) Operation.
 
 
 
|-
 
|2
 
|bgcolor="ff8888"| act
 
| att
 
| procedure@classCode
 
| classCode <= PROC
 
 
| 1..1
 
 
|  
 
|  
 
|
 
|
  
|-
+
|}
|2
+
 
|bgcolor="ff8888"| act
 
| att
 
| @moodCode
 
| <= x_DocumentProcedureMood
 
 
| 1..1
 
|
 
|
 
  
|-
 
|2
 
|bgcolor="ff8888"| act
 
| elm
 
| id
 
| Identifikation der Operation
 
| SET<II>
 
| 1..*
 
| required
 
|Über dieses Element wird die Operation eindeutig identifiziert. Somit ist dieses Element required. Die Kombination der Attribute root und extension identifiziert die Operation systemübergreifend eindeutig.
 
  
|-
+
Aus dem VHitG-Arztbrief:
|3
+
<syntaxhighlight lang="xml">
|bgcolor="ff8888"| act
+
<substanceAdministration moodCode="EVN" classCode="SBADM" negationInd="true">
| att
+
  <templateId root="2.16.840.1.113883.10.20.5.6.42"/>
| @root
+
| Root-OID
+
  <consumable>
| ST
+
      <manufacturedProduct classCode="MANU">
| 1..1
+
          <manufacturedMaterial classCode="MMAT">
| required
+
          <code code="8611"
|Dieses Attribut ist ein eindeutiger Identifikator für Operationen innerhalb eines bestimmten sendenden Systems.
+
                codeSystem="2.16.840.1.113883.6.88"
 +
                codeSystemName="RxNorm"
 +
                displayName="Povidone iodine"/>
 +
          </manufacturedMaterial>
 +
      </manufacturedProduct>
 +
  </consumable>
 +
 +
</substanceAdministration>
 +
</syntaxhighlight>
  
  
|-
+
Aus IHE PCC TF 2:6.1.4.16.2
|3
+
<syntaxhighlight lang="xml">
|bgcolor="ff8888"| act
+
<substanceAdministration classCode="SBADM" moodCode="INT\|EVN">
| att
+
  <templateId root="2.16.840.1.113883.10.20.1.24"/>
| @extension
+
  <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>
|
+
  <templateId root=""/>
| ST
+
  <id root=\’\’ extension=\’\’/>
| 1..1
+
  <code code=\’\’ codeSystem=\’\’ displayName=\’\’ codeSystemName=\’\’/>
| required
+
  <text><reference value=\’\#med-1\’/></text>
|Dieses Attribut ist innerhalb des sendenden Systems ein eindeutiger Identifikator für die Operation.
+
  <statusCode code=\’completed\’/>
 
+
  <effectiveTime xsi:type=\’IVL_TS\’>
 
+
    <low value=\’\’/>
|-
+
    <high value=\’\’/>
|3
+
  </effectiveTime>
|bgcolor="ff8888"| act
+
  <effectiveTime operator=\’A\’ xsi:type=\’TS\|PIVL_TS\|EIVL_TS\|PIVL_PPD_TS\|SXPR_TS\’>
| elm
+
    :
| code
+
  </effectiveTime>
| durchgeführte Operation
+
  <routeCode code=\’\’ codeSystem=\’\’ displayName=\’\’ codeSystemName=\’\’/>
| CD CWE
+
  <doseQuantity value=\’\’ unit=\’\’/>
| 0..1
+
  <approachSiteCode code=\’\’ codeSystem=\’\’ displayName=\’\’ codeSystemName=\’\’/>
| optional
+
  <rateQuantity value=\’\’ unit=\’\’/>
|
+
  <consumable>
 
+
    :
|-
+
    .
|3
+
  </consumable>
|bgcolor="ff8888"| act
+
  <!-- 0..\* entries describing the components -->
| elm
+
  <entryRelationship typeCode=\’COMP\’ >
| text
+
    <sequenceNumber value=\’\’/>
| Freitext
+
  </entryRelationship>
| ED
+
  <!-- An optional entry relationship that indicates the the reason for use -->
| 0..1
+
  <entryRelationship typeCode=\’RSON\’>
| optional
+
    <act classCode=\’ACT\’ moodCode=\’EVN\’>
|
+
      <templateId root=\’1.3.6.1.4.1.19376.1.5.3.1.4.4.1\’/>
 +
      <id root=\’\’ extension=\’\’/>
 +
    </act>
 +
  </entryRelationship>
 +
  <!-- An optional entry relationship that provides prescription activity -->
 +
  <entryRelationship typeCode=\’REFR\’>
 +
    <templateId root=\’1.3.6.1.4.1.19376.1.5.3.1.4.7.3\’/>
 +
    :
 +
    .
 +
  </entryRelationship>
 +
  <precondition>
 +
    <criterion>
 +
      <text><reference value=\’\’></text>
 +
    </criterion>
 +
  </precondition>
 +
</substanceAdministation>
 +
</syntaxhighlight>
 +
 
 +
===systemisch(e Therapie)===
 +
 
  
 +
{| class="hl7table"
 +
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 +
|-
 +
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird die Daten zur systemischen Therapie übermittelt.
 
|-
 
|-
|3
+
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
|bgcolor="ff8888"| act
 
| elm
 
| statusCode
 
| <= completed
 
| ST
 
| 1..1
 
| required
 
|Über dieses Attribut wird der Status angegeben, in dem der beschriebene Act sich befindet. Ein Act kann z.B. den Status „new", „active" oder „cancelled" besitzen. Die Beobachtung einer Operation wird mit der Dokumentation als abgeschlossene Handlung betrachtet. Somit wird für das Attribut ''statusCode'' der feste Wert „completed" vorgegeben.
 
 
 
 
|-
 
|-
|3
+
| ???? || O ||
|bgcolor="ff8888"| act
+
|}
| elm
+
 
| effectiveTime
+
{{AlertBox|
| Durchführungszeitraum
+
systemisch - Procedure
| IVL<TS>
+
}}
| 0..1
+
 
| optional
+
{| class="hl7table"
|Dieses Element gibt den Durchführungszeitraum der Therapie an. Benötigt wird Tagesgenauigkeit, bei einer Operation werden daher nicht Beginn und Ende angegeben, sondern das Datum im value-Attribut übermittelt.
+
! Lvl
 +
! RIM
 +
! AE
 +
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
 +
 
  
 
|-
 
|-
|3
+
|1
|bgcolor="ffbbbb"| rel
+
|bgcolor="ff8888"|act
| elm
+
|elm
| entryRelationship
+
|
| Intention
+
|
|  
+
|
| 0..1
+
|
| optional
+
|
|Ziel der Operation.
+
|
  
 
|-
 
|-
|4
+
| 2
|bgcolor="ff8888"| act
+
|bgcolor="ffaaaa"| rel
 
| elm
 
| elm
| Observation
 
| Intention
 
 
|  
 
|  
| 0..1
+
|  
| optional
+
|  
|Ziel der Operation.
+
|  
 +
|
 +
|
  
 
|-
 
|-
|5
+
| 1
|bgcolor="ff8888"| act
+
|bgcolor="ccffff"| part
 
| elm
 
| elm
| code
 
| Ziel der Intention
 
| CD CWE
 
| 0..1
 
 
|  
 
|  
|Diese Klasse im Intent Mood drückt das Ziel aus.
 
 
|-
 
| 5
 
|bgcolor="ff8888"| act
 
| att
 
| value
 
| Ziel der Intention
 
| CD CWE
 
| 0..1
 
 
|  
 
|  
|
+
|
 +
|
 +
|
 +
|  
  
 
|-
 
|-
|3
+
| 2
|bgcolor="ffbbbb"| rel
+
|bgcolor="ffff88"| role
 
| elm
 
| elm
| entryRelationship
 
| Komplikation
 
 
|  
 
|  
| 0..1
+
|  
| optional
+
|  
 +
|
 +
|
 
|
 
|
  
 
|-
 
|-
 
|4
 
|4
|bgcolor="ff8888"| act
+
|bgcolor="88ff88"|ent
 
| elm
 
| elm
| Observation
 
| Komplikation
 
 
|  
 
|  
| 0..1
 
| optional
 
|Oft reicht in Bezug auf Komplikationen die einfache Information aus, ob diese aufgetreten sind. Dies wird als observation innerhalb einer entryRelationship übermittelt.
 
 
|-
 
|5
 
|bgcolor="ff8888"| act
 
| elm
 
| code
 
| Komplikation
 
 
|  
 
|  
| 0..1
 
| optional
 
|Der code für diese Observation ist fix. Es wird der entsprechende SNOMED-CT-Code verwendet.
 
 
|-
 
|5
 
|bgcolor="ff8888"| act
 
| elm
 
| value
 
 
|  
 
|  
 
|  
 
|  
| 0..1
+
|  
| optional
+
|
|Die Information, ob Komplikationen aufgetreten sind, wird als boolscher Wert übermittelt. Ist diese Information nicht bekannt, kann dies als nullFlavor="UNK" übermittelt werden.
+
 
 +
|}
  
 +
===Status (Nachsorge und andere Follow-Up)===
  
  
 +
{| class="hl7table"
 +
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 +
|-
 +
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird der Status zur Nachsorge und andere Follow-Ups übermittelt.
 
|-
 
|-
|3
+
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
|bgcolor="ffbbbb"| rel
 
| elm
 
| entryRelationship
 
| Bestandteil
 
|  
 
| 0..1
 
| optional
 
|einzelne Prozedur
 
 
 
 
|-
 
|-
|4
+
| ???? || O ||
|bgcolor="ff8888"| act
+
|}
| elm
+
 
| Procedure
+
{{AlertBox|
| Einzelprozeduren
+
???
|  
+
}}
| 0..1
+
 
| optional
+
{| class="hl7table"
|Eine Operation besteht häufig aus mehreren Einzelprozeduren. Jede Einzelprozedur wird als procedure in einer entryRelationship übermittelt. Beliebig viele entryRelationships sind zulässig.
+
! Lvl
 +
! RIM
 +
! AE
 +
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
 +
 
 +
 
 +
|-
 +
|1
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
  
 
|-
 
|-
|5
+
| 2
|bgcolor="ff8888"| act
+
|bgcolor="ffaaaa"| rel
 
| elm
 
| elm
| code
 
 
|  
 
|  
 
|  
 
|  
| 0..1
+
|  
| optional
+
|  
|Im code-Element werden die durchführten Einzelprozeduren übermittelt. Im Rahmen dieses Leitfadens wird der Operationen- und Prozedurenschlüssel (OPS) verwendet. Zulässig sind alle Fassungen von OPS.
+
|  
 +
|
  
 
|-
 
|-
|3
+
| 1
 
|bgcolor="ccffff"| part
 
|bgcolor="ccffff"| part
 
| elm
 
| elm
| performer
 
| performer
 
 
|  
 
|  
| 0..1
+
|  
| optional
+
|  
|Hier werden die Angaben zu Operateur(en) übermittelt. Die Übermittlung mehrerer Operateure ist zulässig.
+
|  
 
+
|
 
+
|
  
 
|-
 
|-
|4
+
| 2
 
|bgcolor="ffff88"| role
 
|bgcolor="ffff88"| role
 
| elm
 
| elm
| AssignedEntity
 
 
|  
 
|  
 
|  
 
|  
| 0..1
 
| optional
 
|ausführender Arzt
 
 
|-
 
|5
 
|bgcolor="ffff88"| role
 
| elm
 
| AssignedEntity.role
 
 
|  
 
|  
 
|  
 
|  
| 0..1
+
|  
| optional
+
|
|Über dieses Element wird der Operateur eindeutig identifiziert. Somit ist dieses Element required. Die Kombination der Attribute root und extension identifiziert den Operateur systemübergreifend eindeutig.
 
 
 
  
 
|-
 
|-
|5
+
|4
 
|bgcolor="88ff88"|ent
 
|bgcolor="88ff88"|ent
 
| elm
 
| elm
| Person
 
 
|  
 
|  
 
|  
 
|  
| 0..1
+
|  
| optional
+
|  
|Arzt
+
|  
 +
|
 +
 
 +
|}
 +
 
 +
===Studiendaten===
 +
 
  
 +
{| class="hl7table"
 +
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|-
|6
+
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werdne Studiendaten übermittelt.
|bgcolor="88ff88"|ent
 
| elm
 
| name
 
|
 
| PN
 
| 0..1
 
| optional
 
|Name des Operateurs
 
 
 
 
|-
 
|-
|3
+
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
|bgcolor="ccffff"| part
 
| elm
 
| participant
 
| Teilnehmer
 
|  
 
| 0..1
 
| optional
 
|ausführender Arzt
 
 
 
 
|-
 
|-
|4
+
| ???? || O || &nbsp;
|bgcolor="ffff88"| role
 
| elm
 
| ParticipantRole
 
|
 
|
 
| 0..1
 
| optional
 
|sonstiger Teilnehmer
 
 
 
|-
 
|5
 
|bgcolor="88ff88"|ent
 
| elm
 
| Person
 
|
 
|
 
| 0..1
 
| optional
 
|Teilnehmer
 
 
 
 
|}
 
|}
  
 +
{{AlertBox|
 +
Observation
 +
}}
  
 
{| class="hl7table"
 
{| class="hl7table"
!Lvl!!Code!!Bedeutung!!Erläuterung
+
! Lvl
 +
! RIM
 +
! AE
 +
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
 +
 
 +
 
 
|-
 
|-
|1||OP||Operation||1), 2), 3), 4),bei Operativer Therapie Fixwert
+
|1
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|1||RAD||Strahlentherapie||1), 2), 3)
+
| 2
 +
|bgcolor="ffaaaa"| rel
 +
| elm
 +
|  
 +
|  
 +
|  
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|2||RAD-B||Brachytherapie||4) ADT-Basisdatensatz unter¬scheidet hier in den Strahlen¬therapiedaten endokavitär und interstitiell
+
| 1
 +
|bgcolor="ccffff"| part
 +
| elm
 +
|  
 +
|  
 +
|  
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|2||RAD-T||Teletherapie||4)
+
| 2
 +
|bgcolor="ffff88"| role
 +
| elm
 +
|  
 +
|  
 +
|  
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|2||RAD-S||sonstige Strahlentherapie||4)
+
|4
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
 +
|}
 +
 
 +
===Abschlussdaten===
 +
 
 +
 
 +
{| class="hl7table"
 +
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|-
|1||NUK||||
+
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird die Abschlussdaten übermittelt.
 
|-
 
|-
|2||NUK-J||Radiojodtherapie||4)
+
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|-
 
|-
|2||NUK-O||offene Radionuklide||4)
+
| ???? || O || &nbsp;
|-
+
|}
|2||NUK-S||sonstige Nuklearmedizinische Therapie||4)
+
 
|-
+
{{AlertBox|
|1||CHE||Chemotherapie||1), 2), 3)
+
Observation
|-
+
}}
|1||HOR||Hormontherapie / Antihormonelle Therapie||1), 2), 3)
+
 
|-
+
{| class="hl7table"
|1||||||
+
! Lvl
 +
! RIM
 +
! AE
 +
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
 +
 
 +
 
 
|-
 
|-
|2||KNTR||Knochenmarktransplantation||1), 2)
+
|1
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|2||STAMM||Stammzelltransplantation||2)
+
| 2
 +
|bgcolor="ffaaaa"| rel
 +
| elm
 +
|  
 +
|  
 +
|  
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|3||STAMM-L||Autologe Stammzelltransplantation||4)
+
| 1
 +
|bgcolor="ccffff"| part
 +
| elm
 +
|  
 +
|  
 +
|  
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|3||STAMM-G||Sonstige Stammzelltransplantation||4)
+
| 2
|-
+
|bgcolor="ffff88"| role
|3||STAMM-S||Allogene Stammzelltransplantation||4)
+
| elm
|-
+
|  
|1||IMM||Antikörper / Immuntherapie||1), 2), 3)
+
|  
|-
+
|  
|1||SCHM||Schmerztherapie||2)
+
|  
|-
+
|  
|1||PSY||Psychoonkologie||2)
+
|
|-
+
 
|1||SM||Sonstige Medikamentöse Therapie||4)
 
|-
 
|1||WS||Wait and see / Active surveillance||4) Wait and see und Active Surveillance sind eigentlich deutlich verschieden und müssen in Prostata¬karzinom¬zentren unterschieden werden
 
|-
 
|1||ATH<br>nullFlavour=OTH||Sonstige / andere Therapie||1), 2), 3)
 
|-
 
|2||ATH-HY||Hyperthermie||4)
 
 
|-
 
|-
 +
|4
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
|}
 
|}
Tabelle 23: Codesystem für Operationen
 
  
# GeKiD-Mindestdatensatz
+
===Planung===
# ADT Basisdatensatz „Verlaufsdaten" (HOR wurde dort vergessen, Hormontherapie ist aber auf dem Bogen)
+
[[file:Cdaonk_planung.gif|Planungsdaten]]
# GKR (Gemeinsames Krebsregister)
+
# KRBW (Krebsregister Baden-Württemberg)
+
Abbildung ??: Planungsdaten
 +
 
 +
??????
  
Problematisch ist:
+
{| class="hl7table"
# die unterschiedliche Tiefe , z.B.  RAD allgemein vs. Differenzierung in unterschiedliche Subformen der Strahlen- und nuklearmedizinischen Therapie
+
! Lvl
# mangelnde Abbildung neuer medikamentöser  (Zytokine, Signal-Transduktions-Inhibitoren, …) und bestimmter Untergruppen supportiver Therapie (z.B. Bisphosphonate)
+
! RIM
# mangelnde Abbildung kombinierter Therapien, und damit die Diskussion prä- und post-koordinierter Ansatz .
+
! AE
KRBW: post-koordinierter Ansatz durch eine Kennzeichnung zusammengehöriger Therapien (MULTIMODALE_THERAPIE).
+
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
  
  
{| class="hl7table"
 
!Code!!Bedeutung!!Erläuterung
 
 
|-
 
|-
|A||Abgelehnt ||
+
|1
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|V||vorgesehen ||
+
| 2
 +
|bgcolor="ffaaaa"| rel
 +
| elm
 +
|  
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|T||Terminiert||
+
| 1
|-
+
|bgcolor="ccffff"| part
|B||Begonnen||
+
| elm
|-
+
|  
|R||regulär beendet||
+
|  
|-
+
|  
|||vorzeitig beendet||
+
|  
 +
|  
 +
|  
 +
 
 +
|-
 +
| 2
 +
|bgcolor="ffff88"| role
 +
| elm
 +
|  
 +
|  
 +
|  
 +
|  
 +
|  
 +
|
 +
 
 
|-
 
|-
 +
|4
 +
|bgcolor="88ff88"|ent
 +
| elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
|}
 
|}
Tabelle 25: Codesystem für die Qualifier zu den Operationen
 
  
 +
===Ann Arbor (Score)===
  
  
 
{| class="hl7table"
 
{| class="hl7table"
!Lvl!!Code!!Bedeutung!!Erläuterung!!
+
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|-
|1||N||Nein||1) (in der Wirklichkeit verbirgt sich hier eine große Zahl unterschiedlicher Negationen, die durchaus im Rahmen von Organzentren relevant sein können)||???
+
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird der Ann Arbor Score übermittelt.<br> Hier ist zu beachten, dass es bereits Modelle zur Übermittlung von Scores gibt, die wiederverwendet werden können.
 
|-
 
|-
|2||N-A||abgelehnt ||3)||rejected
+
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|-
 
|-
|1||V||vorgesehen ||2), 4)||statusCode=ActStatusNew
+
| ???? || O ||
|-
+
|}
|2||V-T||terminiert ||4)||moodCode=APT (Mood)???
+
 
|-
+
[[file:Cdaonk_ann_arbor.gif|Ann Arbor Score]]
|1||J||Ja||1), 2)||statusCode=ActStatusNormal???
+
|-
+
Abbildung ??: Ann Arbor Score
|2||J-B||begonnen ||4) (implizit aus leerem „Ende-Datum")||statusCode=ActStatusActive
 
|-
 
|2||J-E||regulär beendet ||3)||statusCode=ActStatusCompleted
 
|-
 
|2||J-A||vorzeitig beendet||3), 5) (Abbruch wegen Nebenwirkungen)||statusCode=ActStatusAborted
 
|-
 
|1||U||Unbekannt||1)||nullFlavor=UNK
 
|}
 
Tabelle 26: Codesystem für Operation statusCode
 
 
 
# GeKiD / GKR
 
# ADT- Basisdatensatz „Verlaufsdaten" (nur implizit)
 
# Information auf ADT- Basisdatensatz Systemisch und Strahlentherapie
 
# Information teilweise relevant für Kennzahlenberechnung in Organzentren
 
# KRBW
 
  
 
+
??????
{| class="hl7table"
 
!Code!!Bedeutung!!Erläuterung
 
|-
 
|K||kurativ||
 
|-
 
|P||palliativ||
 
|-
 
|D||diagnostisch||nur bei Operationen
 
|-
 
|U||unbekannt bzw. nicht anwendbar / sonstige Therapie|| besser nullFlavor
 
|-
 
|}
 
Tabelle 27: Codesystem für Operation code
 
  
 
{{AlertBox|
 
{{AlertBox|
Diese Tabelle passt nicht zur Intention!
+
offizielles Score-Modell verwenden
 
}}
 
}}
  
  
Stellung der Therapie im Gesamtkonzept
+
{| class="hl7table"
 +
! Lvl
 +
! RIM
 +
! AE
 +
! Name
 +
! Desc
 +
! DT
 +
! Kard
 +
! Conf
 +
! Beschreibung
  
{| class="hl7table"
 
!Code!!Bedeutung!!Erläuterung
 
 
|-
 
|-
|N||neoadjuvant||
+
|1
 +
|bgcolor="ff8888"|act
 +
|elm
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|I||intraoperativ||(neuer Code, November 2010)
+
| 2
 +
|bgcolor="ffaaaa"| rel
 +
| elm
 +
|  
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|A||adjuvant||
+
| 1
 +
|bgcolor="ccffff"| part
 +
| elm
 +
|  
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|U||unbekannt bzw. nicht anwendbar / sonstige Therapie|| besser als nullFlavor
+
| 2
 +
|bgcolor="ffff88"| role
 +
| elm
 +
|  
 +
|
 +
|
 +
|
 +
|
 +
|
 +
 
 
|-
 
|-
|}
+
|4
Tabelle 28: Codesysstem für Operation code
+
|bgcolor="88ff88"|ent
 
+
| elm
{{AlertBox|
+
|  
Diese Tabelle passt nicht dazu!
+
|  
}}
 
 
 
===Bestrahlung ===
 
 
 
 
 
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werden die Bestrahlungsdaten übermittelt.
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|-
 
| ???? || O ||
 
|}
 
 
 
{{AlertBox|
 
Maßnahmen &equal; Procedure
 
Als Ergebnis oder als Maßnahme?
 
}}
 
 
 
Die Bestrahlung an sich ist eine Prozedur. Allerdings bestehen Beziehungen zu Phänomenen, die als Beobachtung kommuniziert werden.
 
 
 
[[file:Cdaonk_bestrahlung.gif|Bestrahlung]]
 
 
Abbildung 24: Bestrahlung
 
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
 
 
|-
 
|1
 
|bgcolor="ff8888"|act
 
|elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
 
|-
 
| 2
 
|bgcolor="ffaaaa"| rel
 
| elm
 
|  
 
|  
 
 
|  
 
|  
 
|  
 
|  
 
|  
 
|  
 
|
 
|
 
|-
 
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|}
 
 
 
 
<syntaxhighlight lang="xml">
 
  <component>
 
    <observation classCode="OBS" moodCode="EVN">
 
      <templateId root="2.16.840.1.113883.10.20.5.2.5.1"/>
 
      <code  codeSystem="2.16.840.1.113883.6.1"|
 
            codeSystemName="LOINC" code="41852-5"
 
            displayName="Microorganism identified"/>
 
      <value xsi:type="CD"
 
            codeSystem="2.16.840.1.113883.6.96"
 
            codeSystemName="SNOMED"
 
            code="116197008"
 
            displayName="Staphylococcus, coagulase negative (organism)"/>
 
    </observation>
 
  </component>
 
</syntaxhighlight>
 
 
===Medikamentendaten ===
 
 
 
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird die Daten zur Medikation übermittelt.
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|-
 
| ???? || O ||
 
|}
 
 
 
[[file:Cdaonk_medikation2.gif|Medikation]]
 
 
Abbildung 26: Medikation (gemäß IHE PCC)
 
 
{{AlertBox|
 
Substance Administration
 
Hinweis auf VHitG Addendum Medikation sowie epSOS!!!
 
}}
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
|-
 
|1
 
|bgcolor="ff8888"|act
 
|elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffaaaa"| rel
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|}
 
 
 
 
Aus dem VHitG-Arztbrief:
 
<syntaxhighlight lang="xml">
 
<substanceAdministration moodCode="EVN" classCode="SBADM" negationInd="true">
 
  <templateId root="2.16.840.1.113883.10.20.5.6.42"/>
 
 
  <consumable>
 
      <manufacturedProduct classCode="MANU">
 
          <manufacturedMaterial classCode="MMAT">
 
          <code code="8611"
 
                codeSystem="2.16.840.1.113883.6.88"
 
                codeSystemName="RxNorm"
 
                displayName="Povidone iodine"/>
 
          </manufacturedMaterial>
 
      </manufacturedProduct>
 
  </consumable>
 
 
</substanceAdministration>
 
</syntaxhighlight>
 
 
 
Aus IHE PCC TF 2:6.1.4.16.2
 
<syntaxhighlight lang="xml">
 
<substanceAdministration classCode="SBADM" moodCode="INT\|EVN">
 
  <templateId root="2.16.840.1.113883.10.20.1.24"/>
 
  <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>
 
  <templateId root=""/>
 
  <id root=\’\’ extension=\’\’/>
 
  <code code=\’\’ codeSystem=\’\’ displayName=\’\’ codeSystemName=\’\’/>
 
  <text><reference value=\’\#med-1\’/></text>
 
  <statusCode code=\’completed\’/>
 
  <effectiveTime xsi:type=\’IVL_TS\’>
 
    <low value=\’\’/>
 
    <high value=\’\’/>
 
  </effectiveTime>
 
  <effectiveTime operator=\’A\’ xsi:type=\’TS\|PIVL_TS\|EIVL_TS\|PIVL_PPD_TS\|SXPR_TS\’>
 
    :
 
  </effectiveTime>
 
  <routeCode code=\’\’ codeSystem=\’\’ displayName=\’\’ codeSystemName=\’\’/>
 
  <doseQuantity value=\’\’ unit=\’\’/>
 
  <approachSiteCode code=\’\’ codeSystem=\’\’ displayName=\’\’ codeSystemName=\’\’/>
 
  <rateQuantity value=\’\’ unit=\’\’/>
 
  <consumable>
 
    :
 
    .
 
  </consumable>
 
  <!-- 0..\* entries describing the components -->
 
  <entryRelationship typeCode=\’COMP\’ >
 
    <sequenceNumber value=\’\’/>
 
  </entryRelationship>
 
  <!-- An optional entry relationship that indicates the the reason for use -->
 
  <entryRelationship typeCode=\’RSON\’>
 
    <act classCode=\’ACT\’ moodCode=\’EVN\’>
 
      <templateId root=\’1.3.6.1.4.1.19376.1.5.3.1.4.4.1\’/>
 
      <id root=\’\’ extension=\’\’/>
 
    </act>
 
  </entryRelationship>
 
  <!-- An optional entry relationship that provides prescription activity -->
 
  <entryRelationship typeCode=\’REFR\’>
 
    <templateId root=\’1.3.6.1.4.1.19376.1.5.3.1.4.7.3\’/>
 
    :
 
    .
 
  </entryRelationship>
 
  <precondition>
 
    <criterion>
 
      <text><reference value=\’\’></text>
 
    </criterion>
 
  </precondition>
 
</substanceAdministation>
 
</syntaxhighlight>
 
 
===systemisch(e Therapie)===
 
 
 
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird die Daten zur systemischen Therapie übermittelt.
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|-
 
| ???? || O ||
 
|}
 
 
{{AlertBox|
 
systemisch - Procedure
 
}}
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
|-
 
|1
 
|bgcolor="ff8888"|act
 
|elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffaaaa"| rel
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|}
 
 
===Status (Nachsorge und andere Follow-Up)===
 
 
 
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird der Status zur Nachsorge und andere Follow-Ups übermittelt.
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|-
 
| ???? || O ||
 
|}
 
 
{{AlertBox|
 
???
 
}}
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
|-
 
|1
 
|bgcolor="ff8888"|act
 
|elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffaaaa"| rel
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|}
 
 
===Studiendaten===
 
 
 
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werdne Studiendaten übermittelt.
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|-
 
| ???? || O || &nbsp;
 
|}
 
 
{{AlertBox|
 
Observation
 
}}
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
|-
 
|1
 
|bgcolor="ff8888"|act
 
|elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffaaaa"| rel
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|}
 
 
===Abschlussdaten===
 
 
 
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird die Abschlussdaten übermittelt.
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|-
 
| ???? || O || &nbsp;
 
|}
 
 
{{AlertBox|
 
Observation
 
}}
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
|-
 
|1
 
|bgcolor="ff8888"|act
 
|elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffaaaa"| rel
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|}
 
 
===Planung===
 
[[file:Cdaonk_planung.gif|Planungsdaten]]
 
 
Abbildung ??: Planungsdaten
 
 
??????
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
|-
 
|1
 
|bgcolor="ff8888"|act
 
|elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffaaaa"| rel
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|}
 
 
===Ann Arbor (Score)===
 
 
 
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt wird der Ann Arbor Score übermittelt.<br> Hier ist zu beachten, dass es bereits Modelle zur Übermittlung von Scores gibt, die wiederverwendet werden können.
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|-
 
| ???? || O ||
 
|}
 
 
[[file:Cdaonk_ann_arbor.gif|Ann Arbor Score]]
 
 
Abbildung ??: Ann Arbor Score
 
 
??????
 
 
{{AlertBox|
 
offizielles Score-Modell verwenden
 
}}
 
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
|-
 
|1
 
|bgcolor="ff8888"|act
 
|elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffaaaa"| rel
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|}
 
 
=Anhang A: Diverses=
 
 
==Offene Punkte==
 
* vollständige Umsetzung
 
* Festlegung der Vokabularien
 
* Festlegung zur Übertragung (Transport) der Dokumente
 
* Validierung: BQS, Schemas, Schematron, etc.
 
* Signatur
 
* Anonymisierung bzw. Pseudonymisierung (vgl. neue IHE-Profile)
 
* Abgleich mit IHE QRPH-ca (public reporting to cancer registries)
 
 
==Referenzen/Literatur==
 
 
{| class="hl7table"
 
!Kürzel!!Inhalt
 
|-
 
|DIMDI, Alpha_Id||Alpha-ID - Die Identifikationsnummer
 
[http://www.dimdi.de/static/de/ehealth/alpha-id/index.htm-http://www.dimdi.de/static/de/ehealth/alpha-id/index.htm http://www.dimdi.de/static/de/ehealth/alpha-id/index.htm-http://www.dimdi.de/static/de/ehealth/alpha-id/index.htm]
 
|-
 
|DIMDI, Verschl||Anleitung zur Verschlüsselung
 
[http://www.dimdi.de/static/de/klassi/diagnosen/icd10/icdsgbv20.htm http://www.dimdi.de/static/de/klassi/diagnosen/icd10/icdsgbv20.htm]
 
|-
 
|DIMDI, FAQ OID||hilfreiche Antworten auf häufig auftretende Fragen zu OIDs.
 
|-
 
|DIMDI, Basis||Basiswissen Codieren, DIMDI 2004
 
|-
 
|HL7 Datentypen||HL7 Version 3 Datentypen und CMETs für das Deutsche Gesundheitswesen, www.hl7.de (Publikationen)
 
|-
 
|CDAr2Arztbrief||Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen, Version 1.50 vom 12.05.2006, herausgegeben vom VHitG, HL7 Deutschland und der Arbeitsgemeinschaft Sciphox, www.hl7.de (Publikationen)
 
|-
 
|Wiley, 2009||TNM Classification of Malignant Tumours, 7<sup>th</sup> Edition
 
Editors: Sobin L, Gospodaarowicz M, Wittekind C
 
Wiley-Blackwell, ISBN: 978-1-4443-3241-4, Dez. 2009
 
|-
 
|Louis, 2007||Louis et al. (2007) The 2007 WHO Classification of Tumours of the Central
 
Nervous System. Acta Neuropathol 114(2):97–110
 
|-
 
|}
 
Tabelle 29: Referenzen/Literatur
 
 
==Glossar==
 
 
{| class="hl7table"
 
!Abkürzung!!Bedeutung
 
|-
 
|ADT||Arbeitsgemeinschaft Deutscher Tumorzentren e.V.
 
|-
 
|AQUA||Institut für angewandte Qualitätsförderung und Forschung im Gesund¬heitswesen GmbH
 
|-
 
|NCT||Nationales Centrum für Tumorerkrankungen Heidelberg
 
|-
 
|DKG||Deutsche Krebsgesellschaft e. V.
 
|-
 
|DOC||Deutsche Onkologie Centrum Holding GmbH
 
|-
 
|DokuData||DokuData Dokumentations- und Informationssysteme GmbH
 
|-
 
|GEKID||Gesellschaft der epidemiologischen Krebsregister in Deutschland e.V.
 
|-
 
|GTDS||Gießener Tumordokumentationssystem
 
|-
 
|HL7||HL7 Benutzergruppe in Deutschland e.V.
 
|-
 
|ID||Information und Dokumentation im Gesundheitswesen GmbH & Co. KGa
 
|-
 
|IHE||IHE Deutschland e. V.
 
|-
 
|VHitG||Verband der Hersteller von IT-Lösungen für das Gesundheitswesen, e.V.
 
|-
 
|}
 
Tabelle 30: Glossar
 
 
==Detaillierte Änderungshistorie==
 
 
{| class="hl7table"
 
!Version!!Änderungen gegenüber Vorversion!!Kapitel/Seitenzahl
 
|-
 
|01||Initialfassung mit grundlegender Struktur||Alle
 
|-
 
|02||weitere Ausarbeitungen||Alle
 
|-
 
|03||weitere Ausarbeitungen||alle
 
|-
 
|04||Einarbeitung der Kommentare von UA, BS, SF, CT||alle
 
|-
 
|05||weitere Ausarbeitung||alle
 
|-
 
|06||weitere Ausarbeitung||alle
 
|-
 
|07||weitere Ausarbeitung||alle
 
|-
 
|08||Überarbeitung gemäßt Beispiel||alle
 
|-
 
|}
 
Tabelle 31: Änderungshistorie
 
 
=Anhang B: Verzeichnisse=
 
 
[[Cdaonk:OID-Konzept|OID-Konzept der dt. Krebsgesellschaft]]
 
 
==OIDs für Codesysteme==
 
 
Die OIDs für [[Kodesysteme]] selbst sind auf einer separaten Seite zu finden. Hier werden erstmal die Semantik-Identifier aufgelistet:
 
 
 
{| class="hl7table"
 
|-
 
! Code
 
! Bedeutung (Kurztext)
 
! Kommentar
 
 
|-
 
| gekidMeldebegruendung
 
| GEKID Meldebegründung
 
 
|-
 
| gekidDiagnosesicherung
 
| GEKID Diagnosesicherung
 
 
|-
 
| gekidDiagnoseanlass
 
| GEKID Diagnoseanlass
 
 
|-
 
| gekidGrobstadium
 
| GEKID Grobstadium
 
 
|-
 
| fruehereChemotherapie
 
| Hat eine frühere Chemotherapie stattgefunden?
 
| Ja/nein
 
 
|-
 
| fruehereStrahlentherapie
 
| Hat eine frühere Strahlentherapie stattgefunden?
 
| Ja/nein
 
 
|-
 
| tnmT
 
| TNM: T
 
| Diagnoseleitfaden
 
 
|-
 
| tnmN
 
| TNM: N
 
| Diagnoseleitfaden
 
 
|-
 
| tnmM
 
| TNM: M
 
| Diagnoseleitfaden
 
 
|-
 
| tnmS
 
| TNM: S
 
| Diagnoseleitfaden
 
 
|-
 
| tnmL
 
| TNM: L
 
| Diagnoseleitfaden
 
 
|-
 
| tnmV
 
| TNM: V
 
| Diagnoseleitfaden
 
 
|-
 
| tnmPn
 
| TNM: Pn
 
| Diagnoseleitfaden
 
 
|-
 
| tnmStage
 
| TNM: UICC-Stadium
 
| Diagnoseleitfaden
 
 
|-
 
| tnmCp
 
| TNM: c oder p (klinisch oder pathologisch)
 
| Diagnoseleitfaden
 
 
|-
 
| tnmASymbol
 
| TNM: a-Symbol
 
| Diagnoseleitfaden
 
 
|-
 
| tnmRSymbol
 
| TNM: r-Symbol
 
| Diagnoseleitfaden
 
 
|-
 
| tnmYSymbol
 
| TNM: y-Symbol
 
| Diagnoseleitfaden
 
 
|-
 
| tnmCFactor
 
| TNM: C-Faktor
 
| Diagnoseleitfaden
 
 
|-
 
| tnmMSymbol
 
| TNM: m-Symbol
 
| Diagnoseleitfaden
 
 
|-
 
| tnmSn
 
| TNM: Sentinel Node
 
| Diagnoseleitfaden
 
 
|-
 
| tnmI
 
| TNM: i
 
| Diagnoseleitfaden
 
 
|-
 
| tnmMol
 
| TNM: mol
 
| Diagnoseleitfaden
 
 
|-
 
| tnmR
 
| TNM: R
 
| Diagnoseleitfaden
 
 
|-
 
| tnmRDomain
 
| TNM: Gültigkeitsbereich der R-Klassifikation (lokal, gesamt)
 
 
|-
 
| tnmRLocation
 
| TNM: Lokalisation des Residualtumors
 
| SnomedCT
 
 
|-
 
| SentinelNodesExamined
 
| Anzahl untersuchter Sentinel-Lymphknoten
 
| kein Kodesystem
 
 
|-
 
| SentinelNodesPositive
 
| Anzahl befallener Sentinel-Lymphknoten
 
| kein Kodesystem
 
 
|-
 
| Breslow
 
| Breslow-Level (Tumordicke nach Breslow bei Hauttumoren)
 
|Score
 
 
|-
 
| BreslowMM
 
| Tumordicke nach Breslow in mm
 
| kein Kodesystem
 
 
|-
 
| Enneking
 
| Chirurgisches Staging nach Enneking 1986 (Weichteil-Sarkom)
 
| Score
 
 
|-
 
| FIGO
 
| FIGO-Klassifikation (gynäkologische Tumoren)
 
| Score
 
 
|-
 
| Holoye
 
| Holoye (Bronchialkarzinom)
 
 
|-
 
| IGCCCG
 
| IGCCCG-Prognose (Hodentumoren)
 
 
|-
 
| Indiana
 
| Indiana-Klassifikation (metastasierte Hodentumoren)
 
 
|-
 
| INSS
 
| INSS-Stadium (Neuroblastom)
 
 
|-
 
| Lugano
 
| Lugano-Klassifikation (Hodentumoren)
 
 
|-
 
| Marburger
 
| Marburger Klassifikation (kleinzelliges Bronchialkarzinom)
 
 
|-
 
| WHOBrain
 
| WHO-Stadium (Gehirntumoren)
 
 
|-
 
| AnnArborStage
 
| Ann Arbor Stadium (Hodgkin und Non-Hodgkin Lymphome)
 
| Score
 
 
|-
 
| AnnArborBSymptoms
 
| Ann Arbor B-Symptome (Hodgkin und Non-Hodgkin Lymphome)
 
| Teil von Score
 
 
|-
 
| AnnArborExtranodal
 
| Ann Arbor extranodaler Befall (Hodgkin und Non-Hodgkin Lymphome)
 
| Teil von Score
 
 
|-
 
| Binet
 
| Binet-Stadium (lymphatische Leukämien)
 
| Score
 
 
|-
 
| DurieSalmon
 
| Stadium nach Durie und Salmon (multiple Myelome)
 
| Score
 
 
|-
 
| FAB
 
| FAB-Klassifikation akuter myeloischer Leukämien
 
 
|-
 
| Jansen
 
| Stadium nach Jansen und Hermans (Haarzellleukämie)
 
| Score
 
 
|-
 
| PhasenCML
 
| Phasen für chronisch myeloische Leukämie (CML)
 
 
|-
 
| Philadelphia
 
| Philadelphia-Chromosom (CML)
 
 
|-
 
| Radaszkiewicz
 
| Stadium für Magenlymphome nach Radaszkiewicz
 
 
|-
 
| RAI
 
| RAI-Stadium (CLL)
 
| Score
 
 
|-
 
| Robson
 
| Stadium nach Robson (Nierenzellkarzinom)
 
| Score
 
 
|-
 
| Murphy
 
| Stadium nach Murphy (kindliches und jugendliches NHL)
 
| Score
 
 
|-
 
| Kernohan
 
| Kernohan-Klassifikation (Astrozytom)
 
 
|-
 
| NWTS
 
| NWTS-Klassifikation (Wilms-Tumor, Nephroblastom)
 
 
|-
 
| Dukes
 
| Dukes-Klassifikation (kolorektale Karzinome)
 
 
|-
 
| VALG
 
| VALG-Stadium (kleinzellige Bronchialkarzinome)
 
 
|-
 
| RiskC58
 
| Risikokategorien bei trophoblastären Schwangerschaftstumoren (C58)
 
 
|-
 
| Bismuth
 
| Klassifikation der zentralen Gallengangskarzinome  nach Bismuth und Corlette (1975)
 
 
|-
 
| Borrmann
 
| Borrmann-Klassifikation (Magenkarzinom)
 
 
|-
 
| Fuhrman
 
| Kerngrad nach Fuhrman (Nierenzellkarzinom)
 
 
|-
 
| Hannover
 
| Hannover-Klassifikation der Akustikusneurinome
 
 
|-
 
| Helpap
 
| Grading nach Helpap (Prostatakarzinom)
 
 
|-
 
| Siewert
 
| Siewert-Einteilung (Kardiakarzinom)
 
 
|-
 
| VanNuysIndex
 
| Van Nuys Prognoseindex (Mammakarzinom, DCIS)
 
 
|-
 
| SiteOfPrimaryTumor
 
| Lokalisation des Primärtumors
 
| Scnomed CT
 
 
|-
 
| SiteOfDistantMetastasis
 
| Lokalisation der Fernmetastase
 
| Snomed CT
 
 
|-
 
| HistologieEinsendenummer
 
| Einsendernummer des Histologiebefundes
 
 
|-
 
| TypeOfEncounter
 
| Art des Aufenthalts
 
 
|-
 
| ReasonOfEncounter
 
| Grund des Aufenthalts / der Untersuchung
 
 
|-
 
| RemissionState
 
| Remissionsstatus
 
 
|-
 
| RemissionStateUnknownReason
 
| Grund für unbekannten Remissionsstatus
 
 
|-
 
| PrimarySiteStatus
 
| Status des Primärtumors
 
 
|-
 
| RegionalStatus
 
| Status der regionären Lymphknoten
 
 
|-
 
| DistantMetastasisStatus
 
| Status der Fernmetastasen
 
 
|-
 
| Clark
 
| Clark-Level (Hauttumoren)
 
 
|-
 
| TypeOfRadiationTherapy
 
| Applikationsart der Strahlentherapie
 
 
|-
 
| TotalDoseOfRadiationTherapy
 
| Strahlentherapie: Gesamtdosis
 
 
|-
 
| FractionDoseOfRadiationTherapy
 
| Strahlentherapie: Einzeldosis
 
 
|-
 
| IntentionOfTherapy
 
| Therapieintention
 
 
|-
 
| FinalStatusOfTherapy
 
| Beendigungsstatus der Therapie
 
 
|-
 
| Toxicity
 
| Nebenwirkung
 
 
|-
 
| ToxicityGrade
 
| Nebenwirkungsgrad
 
 
|-
 
| TherapyRegime
 
| Therapieschema
 
 
|-
 
| NumberOfPlannedTherapyCycles
 
| Anzahl geplanter Therapiezyklen
 
 
|-
 
| NumberOfAppliedTherapyCycles
 
| Anzahl durchgeführter Therapiezyklen
 
 
|-
 
| DoseReduction
 
| Dosisreduktion
 
  
 
|}
 
|}
 
Für die einzelnen Scores sind die entsprechenden Codes zu erruieren.
 
 
==OIDs für ValueSets==
 
 
 
==OIDs für Templates==
 
 
 
==Abbildungverzeichnis==
 
 
 
==Tabellenverzeichnis==
 
 
 
==Index==
 

Version vom 6. November 2012, 09:04 Uhr

Dieses Material ist Teil des Leitfadens Übermittlung onkologischer Daten.
  • 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 .

Inhaltsverzeichnis

Statisches Modell (Grundlagen)

Einleitung

Dieser Leitfaden setzt auf dem VHitG-Arztbrief auf. Daher werden auch die dortigen Spezifikationen übernommen. Die nachfolgende Tabelle gibt Aufschluss über die in einer Meldung enthaltenen Daten. Die Umsetzung in Form von Abschnitten erfolgt anhand des Analysemodells. Die Spalte „Klasse" referenziert auf die Information in dem Modell. Die letzte Spalte reflektiert in dem Modell dann die Beziehungen der Klassen untereinander.

Dabei kann eine Klasse sowohl aus inhaltlichen als auch nur aus Referenzzwecken übermittelt werden. Wird zum Beispiel eine Erkrankung erstmalig gemeldet, so wird diese Klasse als Inhalt übermittelt. In folgenden Meldungen wird die Erkrankung nur noch als Referenz zur korrekten Herstellung von Bezügen übermittelt. Ein weiterer zu bedenkender Fall wäre eine Korrektur . Über einen noch zu definierenden Mechanismus (Zeitstempel? Extra Attribut?) sollte das empfangende System in der Lage sein, diese Anlässe auseinanderzuhalten.

Gesamtübersicht

Abbildung 11: vereinfachte Gesamtübersicht

Grundsätzliche Anforderungen an die Dokumentstruktur

Dokumente setzen sich grundsätzlich aus folgenden Komponenten zusammen:

  1. dem eigentlichen Inhalt
  2. der Kontextinformation

Die Kontextinformation soll der korrekten Handhabung des Inhalts dienen. Korrekte Handhabung beinhaltet

  1. Die Zuordnung zum Patienten, zur Erkrankung und ggf. der gegenwärtigen therapeutischen Situation
  2. Die Übermittlung von Meldebegründungen, die Aussagen zur weiteren Nutzbarkeit von Daten erlauben

Im Grundsatz ist davon auszugehen, dass zum Patient die Personen identifizierenden Daten übermittelt werden. Dies ist insbesondere anzunehmen, wenn der Datenfluss der Betreuung folgt und natürlich wenn es die Meldebegründungen entsprechend vorsehen. Die Personenidentifikation kann um Zusatzidentifikatoren zum Aufbau und zur Nutzung eines Master-Patient-Index (MPI) erweitert werden, um den Abgleich (Record Linkage) schneller und sicherer zu machen. Bei bestimmten Empfängern ist eine Pseudo¬nymisierung, unter Umständen im Sinne einer Kontrollnummernbildung, erforderlich. Diese kann sowohl bereits bei Absendung der Daten erfolgen als auch erst in einer Vertrauensstelle. Dabei kann es erforderlich werden, dass Teile der Daten kryptographisch geschützt werden (Beispiel Krebsregister Baden-Württemberg).

Beispiel für groben Aufbau

 <?xml version="1.0" encoding="UTF-8" ?>
 <ClinicalDocument>

   <!-- CDA Header -->
   ... siehe Beschreibung CDA R2 Header

   <!-- CDA Body -->
   <component>
      <structuredBody>
      ... siehe Beschreibung CDA R2 Body
      </structuredBody>
   </component>

 </ClinicalDocument>

Nachfolgend ein Beispiel, in dem der Header ausführlicher dargestellt ist:

 <?xml version="1.0" encoding"UTF-8" ?>
 <?xml-stylesheet type="text/xsl" href="?????.xsl"?>
 <ClinicalDocument
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="urn:hl7-org:v3">
  <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
  <templateId root="1.2.276.0.76.3.5.7">
  <id extension="60467049" root="1.2.276.0.58"/>
  <code code="???????" codeSystem="2.16.840.1.113883.6.1"
        displayName="???????"/>
  <title>Meldung an klinisches Krebsregister</title>
  <effectiveTime value="20060924"/>
  <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
  <languageCode code="de"/>
  <setId extension="D1" root="2.16.840.1.113883.3.933"/>
  <versionNumber value="1"/>
  ...

  <!-- CDA -->
  <component>
    <structuredBody>
      <!-- Meldebegründung -->
      <component>
        <section>
          <templateId root="1.2.276.0.76.3.1.131.1.10.????"/>
          ...
          <!-- Referenz auf Participant -->
        </section>
    </component>

    ...

    <!-- Erkrankungsdaten -->
    <component>
        <section>
          <templateId root="1.2.276.0.76.3.1.131.1.10.?????"/>
          ...
          <!-- Referenz auf Phänomendaten -->
        </section>
      </component>

    </structuredBody>
  </component>
 </ClinicalDocument>

Identifikation von Informationseinheiten

Mechanismen

Ein Informationsobjekt kann grundsätzlich über zwei Mechanismen identifiziert werden

  1. über ein „neutrale" Identifikationsmerkmal (automatisch vergebene, eindeutige ID)
  2. über unveränderliche Eigenschaften des Informationsobjektes, die eine eindeutige Identifikation ermöglichen

Während die erste Möglichkeit keine Aussage über das Objekt selbst erlaubt, ist die zweite Möglichkeit unter Umständen nicht gegeben. So können bspw. weder bei Patienten die Namen noch bei Tumoren die Diagnose zur Identifikation herangezogen werden.

Natürlich reicht eine ID alleine nicht aus, um ein Objekt (z.B. eine Erkrankung) zu beschreiben, ermöglicht aber die Übermittlung von Beziehungen und damit die Zuordnung von Korrektur¬informationen.

Zeitstempel der Information

Zeitstempel informieren das Zielsystem über den Zeitpunkt der Entstehung oder Veränderung der Daten. Hierdurch kann das Zielsystem Entscheidungen über notwendige Bearbeitungsschritte treffen (Beispiel siehe unten). Die in den einzelnen Klassen enthaltenen Zeitangaben beziehen sich aber auf die Information selbst und nicht den Zeitpunkt der Veränderung. Eine solche Information müsste im Attribut participant@Time zu der Rolle Author ausgedrückt werden. Diese optionale Information wird nicht immer verfügbar sein. Daher sind grundsätzlich alle Informationen auf Aktualität zu überprüfen und dann ggf. zu korrigieren.

Beispiel Organzentrumssystem (OZ) - Klinisches Krebsregister (KKR)

Übermittlung OZ => KKR Aktion im KKR
18.3.2010: (Patient) Erkrankung-ID 3456 / Diagnose-ID 456, Diagnosedatum 1.3.2010 / Diagnosecode C50.9 / Seite rechts Kennt Erkrankung-ID 3456 noch nicht, legt eigene Erkrankung an kennt Diagnose noch nicht, wird ebenfalls angelegt merkt sich Referenz Erkrankung-ID
25.3.2010: (Patient) Erkrankung-ID 3456 / Diagnose-ID 456, Diagnosedatum 1.3.2010 / Diagnosecode C50.4 / Seite rechts Kennt Erkrankung-ID 3456 bereits, legt keine neue Erkrankung an, kennt Diagnose bereits, korrigiert Diagnosecode
1.4.2010: (Patient) Erkrankung-ID 3456 / Diagnose-Id 456, Diagnosedatum 1.3.2010 / Diagnosecode C50.4 / Seite rechts Operation brusterhaltend am 27.3.2010, Operation/Prozedur-ID 3478237 Kennt Erkrankung-ID 3456 bereits, macht keine Korrektur der Erkrankungsdaten verarbeitet Information zu Operation und ordnet sie der korrekten Erkrankung zu
8.4.2010: (Patient) Erkrankung-ID 3456 / Diagnose-ID 456, Diagnosedatum 1.3.2010 / Diagnosecode C50.4 / Seite rechts Operation Brusterhaltend am 27.3.2010, Operation/Prozedur-ID 3478237 Phänomen Wundheilungsstörung 2.4.2010, Phänomen-ID 574547 Kennt Erkrankung-ID 3456 und Prozedur-ID 3478237 bereits, macht keine Korrektur

verarbeitet Information zur Wund¬heilungs¬störung und ordnet sie der korrekten Operation zu, speichert sich Phänomen-ID


Referenzen auf andere Informationseinheiten

Die Meldung verwendet interne Referenzen gemäß des Analysemodells. Die Funktionsweise soll hier kurz erläutert werden.

Referenzen

Abbildung 12: Handhabung von Referenzen auf Aktivitäten

Über eine Entry-Relationship wird eine Beziehung zu einer anderen Instanz ausgedrückt. Im obigen Beispiel verweist ein Detail einer Maßnahme (Beobachtung) auf eine andere Beobachtung. Welche das konkret ist, kann aus der ID entnommen werden. Im obigen Beispiel verweist die Beobachtung mit der ID=1 (unten) auf die Beobachtung mit den Detailinformationen (oben).

An dieser Stelle sei darauf hingewiesen, dass eine ID sich normalerweise aus zwei Teilen zusammensetzt. Das ist die eigentliche ID, die dann auch alphanumerisch sein kann, sowie eine root-Angabe, die dann auf das ausgebende System sowie die Art der ID verweist. Letzteres wird durch eine OID realisiert. Näheres dazu regelt die FAQ \[DIMDI, FAQ OID\].

Je nach Spezifikation können für Instanzen auch mehrere IDs vergeben werden.

Referenzen auf Beteiligte

Die Handhabung der Referenzen auf die Beteiligten erfolgt gemäß nachfolgendem Schema:

Referenzen auf Personen

Abbildung 13: Handhabung von Referenzen auf Personen

Im Bereich des Clinical Statement Patterns besteht die Möglichkeit, Informationen über Personen einzubinden. Grundsätzlich können hier von einer Aktivität mehrere Verweise (Participations) auf Rollen eingebunden werden. Die Rollen können wiederum weitere Details über Verweise auf Personen bzw. Organisationen realisieren. Hierbei müssen aber keine weiteren Details übermittelt werden. Dieser Mechanismus erlaubt somit, beim ersten Vorkommen alle Details zu den Entities zu übermitteln und bei allen anderen bei den Rollen aufzuhören. Der contextControlCode bestimmt, ob diese Information dem übergeordneten Bereich (Header oder einer anderen hierarchisch übergeordneten Struktur) entspricht. Berichtet z.B. jemand über die Maßnahme eines Dritten, so kann hier dieser Dritte berichtet werden. Grundlage ist hierbei die Nutzung entsprechender Identifikatoren. Nachfolgende Abbildung verdeutlicht dies:

Referenzen ID

Abbildung 14: Beispiel für die Nutzung von Identifikatoren zwecks Referenzierung

Durch die Wiederholung der ID (hier: „1") wird deutlich, dass bei der zweiten Aktivität (id=B) dieselbe Person („Meier") eingebunden ist wie in der ersten Aktivität (id=A). Hierbei spielt es keine Rolle, welche Beziehung die beiden Aktivitäten zueinander haben. @typeCode Beteiligung CD CWE \[0..1\] Der typeCode der Participation bestimmt hierbei, um welche Art der Beteiligung es sich handelt.

Lvl Code Bedeutung Erläuterung
1 PRF performer Ausführender
2 PPRF primary performer 1. Ausführender
2 SPRF secondary performer 2. Ausführender
VRF verifier Verifizierender
ENT data entry person Datentypist
CON consultant Berater
DIS discharger Entlassender
REF referrer Überweiser
ADM admitter Aufnehmender
ATT attender Beisitzer
AUTHEN authenticator
LA legal authenticator Unterzeichnender
AUT author Autor
RCT record target Akte

Tabelle 3: Vocabulary Domain für die Beteiligung

@contextControlCode Kontext übernehmen BL Dieses Attribut bestimmt, ob der übergeordnete Kontext übernommen wird oder nicht.

Handhabung von Negationen

HL7 V3 stellt hierzu Mechanismen (Negation-Indikator und Null-Flavor) zur Verfügung, die hier jetzt nicht in aller Tiefe erklärt werden können. Deshalb sei hier auf die entsprechenden Materialien verwiesen.

??????????

Handhabung von Korrekturen und Folgemeldungen

????????

Statisches Modell (Details)

Dokumentenstruktur

Im CDA-Header werden auf diverse Details verwiesen, deren Verwendung hier kurz aufgeführt wird:

Element (Sequenz) Datentyp Bedeutung Kard.
ClinicalDocument Klasse
realmCode CS eingesetzter Bereich 1..1
typeID II - konstant - 1..1
templateID II Template ID für das ganze Dokument 0..1
id II Dokumenten-ID 1..1
code CE Dokumententyp 1..1
title ST Titel des Dokuments 0..1
effectiveTime TS Erstellungsdatum des Dokuments 1..1
confidentialityCode CE Vertraulichkeitsgrad 1..1
languageCode CS Sprache des Dokuments 1..1
setID II Set-Kennung 0..1
versionNumber INT Versionsnummer 0..1
copyTime TS - nicht verwenden - 0..0
Participations
recordTarget Patient 1..1
author Autor (Melder) inkl. Org. 1..1
dataEnterer Datentypist 0..1
informant
custodian
informationRecipient Empfänger: klin./epidem. Krebsregister 1..1
legalAuthenticator unterzeichnender Arzt 1..1
authenticator
participant diverse Teilnehmer, d.h. Person bzw. Organisation 0..*
Act Relationship
inFullfillmentOf
documentationOf
relatedDocuments
authorization
componentOf
component

Tabelle 4: Dokumentenstruktur (-bestandteile)

Meldeanlässe und Inhalte

Grundsätze:

  • Eine Meldung sollte dann ausgelöst werden, wenn eine Betreuungsepisode beendet und alle zu verantwortenden Informationen verfügbar sind.
  • Grundsätzlich werden nur die Inhalte übermittelt, die mit eigenen diagnostischen oder therapeutischen Maßnahmen zusammenhängen. Davon sollte nur abge¬wichen werden, wenn andernfalls Lücken in der Erfassung auftreten würden.

Beispiel: Grundsätzlich ist eine chirurgische Abteilung verantwortlich für die Darstellung der operativen Therapie, des Therapieerfolgs und der Komplikationen. Informationen über eine außerhäusige Diagnosestellung müssten nur insofern übermittelt werden, dass das empfangende System in der Lage ist, die Therapie korrekt einem Tumor zuzuordnen. Wenn bekannt ist, dass dies aus irgendeinem Grund regelhaft nicht funktioniert oder vereinbart wurde, dass diese Informationen im Rahmen der operativen Therapie übermittelt werden sollen, hat die chirurgische Abteilung diese Eingabe zu verantworten.

Nachfolgend eine Liste der Meldeanlässe:

Code Anlass Details
Diagnose
  • Feststellen einer bösartigen Diagnose
    • Diagnosedatum, Tumorlokalisation, Histologie, Metastasierung
    • ggf. klinischer TNM oder anderes Stagingsystem
  • Abschluss der erweiterten Diagnostik, ggf. Therapieplanung / Tumorkonferenz
    • klinischer TNM oder anderes Stagingsystem
Operative Therapie
  • Durchführen der Maßnahme
    • Datum, OPS-Codes, OP-Bereich
    • OP-Resultat (pTNM, R-Klassifikation)
    • Komplikationen während des stationären Aufenthalts
  • operative Nachschau
    • 30-Tage Morbidität (Komplikationen) (/Mortalität)
Strahlentherapie
  • Einleiten der Strahlentherapie
    • Beginn, Zielgebiete / Bestrahlungsbereich, Intention, Stellung im Gesamtplan
  • Beenden der Strahlentherapie
    • Endedatum und -status, Dosis, Nebenwirkungen
  • Nachschau der Strahlentherapie
    • Therapieerfolg
    • Kurzfristige und langfristige Nebenwirkungen
Systemische Therapie
  • Einleiten der systemischen Therapie
    • Beginn, Art, Protokoll, Intention, Stellung im Gesamtplan
  • Beenden der systemischen Therapie
    • Endedatum und -status, ggf. Dosierungen, Nebenwirkungen
Verlauf
  • Datum, Tumorstatus, Metastasierung
Life-Status (Meldeamt)
  • Datum "lebt" oder Sterbedatum
  • ggf. aktuelle Adresse bzw. Wegzugdatum


Sterbemeldung (Gesundheitsamt, Epid. Register)
  • Sterbedatum, Todesursachen
  • Ggf. Krebs-Tod-Relation

Die Meldeanlässe und Inhalte können je nach Umfang und Länge des überschauten Zeitraum und ggf. dem vorgesehenen Empfänger kombiniert werden. Dies betrifft insbesondere auch den Abgleich von Tumordokumentationssystemen unterschiedlicher Stufen (z.B. Spezialsystemen in Organzentren und regionalen Krebsregistern)

Dokumenttypen

Nachfolgende Tabelle regelt, welche Abschnitte die verschiedenen Dokumenttypen zu den jweweiligen Meldeanlässen enthalten, jeweils mit Optionalität und Kardinalität:

Die Template-ID ist ein technischer Identifikator für die Inhalte in diesem Dokument, während der Dokumententyp ein Code aus einem Vokabular darstellt. Zwischen beiden existiert folgende Korrelation:

Dokumententyp Beschreibung Deok.-Template-ID
Diagnose-Meldung 1.2.276.0.76.3.1.131.1.10.1.1
Therapie-Meldung 1.2.276.0.76.3.1.131.1.10.1.2
Verlaufs-Meldung 1.2.276.0.76.3.1.131.1.10.1.3
Abschluss-Meldung 1.2.276.0.76.3.1.131.1.10.1.4

Tabelle 6: Dokumententyp


Diagnose Therapie Verlauf Abschluss
Sektion Opt. Kard. Opt. Kard. Opt. Kard. Opt. Kard. Template ID
Nationalität TODO
Meldebegründungsdaten R 1..1 R 1..1 R 1..1 R 1..1 TODO
Erkrankungsdaten R 1..1 R 1..1 R 1..1 R 1..1 TODO
Diagnostik R 1..1 TODO
Phänomendaten: Primär R 1..1 TODO
Phänomendaten: Metastasen O 0..* O 0..* TODO
Operation R 0..* TODO
Strahlentherapie R 0..* TODO
systemische Therapie R 0..* TODO
Medikation vgl. Arztbrief 2012
Status (Nachsorge und andere Follow-Up) R 1..1 R 1..1 TODO
Studiendaten O 0..* O 0..* O 0..* TODO
Abschlussdaten R 1..* TODO
Planung O O TODO

Tabelle 4: Dokumenttypen mit Zuordnung der Sektionen

Korrekturmeldung

Header

Der Header enthält alle relevanten Metadaten. Nachfolgend der allgemeine Aufbau:

Abschnitt Kard. Klasse Referenz auf Abschnitt
Header
Metadaten
Autor (Melder)
Unterzeichner
Patient
Empfänger
Participant
  Versicherung
Body
Sektionen s.u.

Metadaten

Zuerst die Metadaten:

ID des Patienten

Abbildung 15a: Header des Dokuments

Lvl RIM AE Name Desc DT Kard Conf Beschreibung
1 act elm ClinicalDocument Dokument 1..1 M
2 act elm realmCode "DE" ST 1..1 M fix
2 act elm typeID ST 1..1 M fix
3 act att @root 2.16.840.1.113883.1.3 ST 1..1 M fix
3 act att @extension POCD_HD000040 ST 1..1 M Diese Kennung ist fix und identifiziert dieses Dokument als CDA-Dokument.
2 act elm templateId Strukturidentifikation des Dokuments II 1..1 M In diesem Element wird die Strukturbeschreibung des Dokumentes festgehalten.
3 act att @root OID des Templates 1..1 M
2 act elm Id Identifikation einer Instanz des Dokuments II 1..1 M Dieses Element identifiziert eindeutig eine Instanz eines Dokuments, d.h.jede Version eines Dokumentes hat eine neue ID.

(vgl. SetId)

3 act att @root OID 1..1 M Hier muss die OID eingesetzt werden, die das sendende System benutzt, um die Dokumente eindeutig zu identifizieren.
3 act att @extension eigentliche ID ST 1..1 M
2 act elm code Dokumenttyp CE CWE 1..1 M s.u.
3 act att @code Dokumenttyp "x-physician-cancer-reg" 1..1 M s.u. und vgl. IHE PCC Vol.2 Abschnitt 6.3.1.A.2
3 act att @codeSystem Dokumenttyp "2.16.840.1.113883.6.1" 1..1 M s.u.
2 act elm title Titel des Dokuments ST 0..1 M Der Titel des Dokuments ergibt sich aus dem Dokumenttyp bzw. Dokumententemplate.

Beispiel "Diagnosemeldung"

2 act elm effectiveTime Erstellungszeitpunkt des Dokuments TS 1..1 M
3 act att @value eigentlicher Zeitpunkt TS 1..1 M
2 act elm confidentialityCode Vertaulichkeit des Dokumentes CE CWE 1..1 M
3 act att @code Code für die Vertaulichkeit CE CWE 1..1 M "N", s.u.
3 act att @codeSystem Codesystem für die Vertaulichkeit 1..1 M fix: "2.16.840.1.113883.5.25"
2 act elm languageCode Sprache des Dokumentes CS CNE 0..1 opt.
2 act elm setId Setkennung II 0..1 Dieses Element legt fest, zu welcher „Menge" das Dokument gehört. Es hält also die verschiedenen Versionen (Instanzen, vgl .Id) zusammen.

Logische Kennung des Dokuments, die über die Versionen hinweg konstant bleibt. Eine Korrektur ergibt sich aus einer höheren Versionsnummer.

3 act att @root OID 1..1 M Hier muss die OID eingesetzt werden, die das sendende System benutzt, um das Dokument-Set eindeutig zu identifizieren.
3 act att @extension eigentliche ID ST 1..1 M
2 act elm versionNumber Versionsnummer INT 1..1 M Eine fortlaufende Nummer zur Versionierung des Dokumentes.
3 act att @value Versionsnummer INT 1..1 Zusammen mit der Setkennung regelt dieses Element die Versionierung der Dokumente.
2 rel elm relatedDocument 0..1
3 act elm parentDocument ParentDocument 1..1 required
4 act elm id ID des Document 1..1 required
Code Beschreibung
34806-0 Oncology Note
x-physician-cancer-rep Report to Cancer Registries

Tabelle: Dokumenttyp

Code Beschreibung
N normal

Tabelle: Vertraulichkeit (OID: 2.16.840.1.113883.5.25)

<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd">
	<realmCode code="DE"/>
	<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
	<templateId root="1.2.276.0.76.3.1.131.1.10.1.1"/>
	<id extension="xyz" root="OID"/>
	<code code="x-physician-cancer-rep" codeSystem="2.16.840.1.113883.6.1" displayName="report to cancer registry"/>
	<title>Diagnosemeldung</title>
	<effectiveTime value="20120407130000+0500"/>
	<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
	<languageCode code="de-DE"/>

	...

</ClinicalDocument>

Participants: Einleitung

An der Erstellung eines Dokumentes sind mehrere Personen bzw. Organisationen und Systeme beteiligt. Dies soll hier einmal kurz erläutert werden, damit die anschließende Detaildarstellung verständlicher wird. Dies wird in Form verschiedener Situationen gemacht:

Variante 1

Der Arzt erstellt einen Arztbrief, aus dem ein med.Dokumentar die Informationen in ein System eingibt, das dann die Meldung abschickt:

  • Arzt = informant
  • med.Dokumentar = dataEnterer (optional)
  • System/Tumordokumentationssystem = authoringDevice
  • System betreibende Organisation = Custodian
  • Tumorregister = informationRecipient (optional)

Variante 2

Ein regionales Register erstellt auf Basis der eingegangenen Meldungen eine neue Meldung an das Landeskrebsregister:

  • Arzt der ursprüngl. Meldung (jetzt ggf. mehrere) = informant
  • med.Dokumentar im reg. Reg. = dataEnterer (optional)
  • Tumordokumentationssystem = authoringDevice
  • System betreibende Organisation (regionale Register) = Custodian
  • Landeskrebsregister = informationRecipient (optional)


Participant: Patient (recordTarget)

ID des Patienten

Abbildung 15: Identifikation des Patienten


Lvl RIM AE Name Desc DT Kard Conf Beschreibung


0 act elm ClinicalDocument Dokument 1..1 M
1 part elm recordTarget Patient 1..1 M Patient
2 part att typeCode "RCT" CS CNE 1..1 M fix
2 role elm patientRole 1..1 M
3 role att classCode "PAT" CS CNE 1..1 M fix
3 role elm id Patient-ID: nicht verwendet SET<II> 1..* M
4 role att @root OID 1..1 M Das ist die OID des sendenden Systems für Patienten.
4 role att @extension die eigentliche ID ST 1..1 M
3 role elm addr Adresse SET<AD> 0..*
4 role att @streetname Strasse 0..1 M
4 role att @houseNumber Hausnummer 0..1
4 role att @postalCode Postleitzahl 0..1 M PLZ ohne Länderkennzeichen
4 role att @city Wohnort 0..1 M
4 role att @country Land 0..1 M
3 role elm telecom Kontaktinformationen SET<TEL> 0..* M
4 ent elm patient Patient 0..1 optional
5 ent elm name Name des SET<PN> 0..* optional Folgende Pseudonyme werden vorgesehen:
  1. Umkehrbar eindeutige Pseudonyme (Angabe von Identifikator + Quellsystem), z.B. Identifikation über Nachsorgepass Bayern, Identifikation im Tumorzentrum Xy, Identifikation in Organzentrumssystem Xyz => OID mit Extension!
  2. „Stochastische Pseudonyme" (Kontrollnummern)

Bestimmte Attribute wie Namen oder Geburtsdatum sind dann optional, die dann in ganz definierten Kommunikationskontexten durch Kontrollnummern ersetzt werden. Die Identifikatoren unter 1. wären in jedem Fall sinnvoll für das automatisierte Record Linkage im Zielsystem, wenn es hier nicht geht, dann woanders

6 ent elm prefix Anrede ST 0..1 optional Anrede: Herr, Frau, ..
6 ent elm prefix Titel ST 0..1 optional akademischer Titel
7 ent att @qualifier "AC" ST 0..1 optional Qualifier für akademischen Titel
6 ent elm given Vorname ST 0..* optional Vornamen
6 ent elm familiy Familienname ST 0..* optional Familienname
6 ent elm familiy Geburtsname ST 0..* optional
7 ent att @qualifier "BR" ST 0..1 optional Qualifier für Geburtsname
5 ent elm administrativeGenderCode Geschlecht CE CWE 0..1 optional Mit diesem Attribut wird das Geschlecht des Patienten übertragen.
6 ent att @code Code für das Geschlecht 0..1 optional
6 ent att @codeSystem Codesystem für das Geschlecht 0..1 optional "2.16.840.1.113883.5.1"
5 ent elm birthTime Geburtsdatum TS 0..1 optional
6 ent att @value Zeitpunkt TS 0..1 tagesgenau


4 ent elm providerOrganisation Krankenhaus 0..1 derzeit nicht notwendig
<recordTarget>
...
</recordTarget>

Participant: Melder (author)

Melder

Abbildung 16: Melder


Lvl RIM AE Name Desc DT Kard Conf Beschreibung
0 act elm ClinicalDocument
1 part elm author Autor 1..1 M Melder
2 part att @typeCode "AUT" CD CNE 1..1 M
2 part elm time Zeitpunkt der Erstellung des Dokuments TS 1..1 M
3 part att @value Zeitpunkt der Erstellung des Dokuments TS 1..1 M
2 role elm assignedAuthor Melder 1..1 M Informationen über den Melder
3 role att @classCode "ASSIGNED" 1..1 M
3 role elm id Melder-ID der Person/System SET<II> 1..1 M Grundsätzlich kann über eine Wiederholung auch mehrere IDs untergebracht werden, deren Semantik sich dann aus der zugeordneten OID ergibt.

Die ID kommt hier hin, wenn es sich beim Melder um ein System oder eine Person handelt.

4 role att @extension eigentliche Identifikationsnummer ST 1..1 M An dieser Stelle wird die ID des Melders untergebracht.
4 role att @root OID zur ID ST 1..1 M Hier kommt die dazugehörige OID hin.
3 ent elm assigendPerson 0..1 Wenn es sich bei dem Melder um eine Person handelt, so ist diese hier anzugeben.
4 ent elm name Name des Melders SET<PN> 0..*
3 ent elm AuthoringDevice 0..1
3 ent elm representedOrganisation 0..1 meldende Einrichtung, falls es sich bei dem Melder um eine Organisation handelt oder Informationen über das Krankenhaus übermittelt werden sollen.
4 ent elm id Melder-ID der Einrichtung SET<II> 0..1 M Hier kommt die ID der Organisation hin, wenn der Melder eine Organisation ist,
5 ent att @extension eigentliche Identifikationsnummer ST 1..1 M Melder im Sinne des KRBW ist die durchführende Einrichtung, d.h. doch der (originale) Provider der Daten. Es handelt um eine Organisation(seinheit); eigentlich um die Kombination Organisation und Instanz des Dokumentssystems.


5 ent att @root OID zur ID ST 1..1 M Hier kommt die dazugehörige OID desjenigen hin, der die ID vergeben hat.
4 ent elm name Name der Org./Einrichtung SET<ON> 0..1
4 ent elm telecom Kontaktinformation der Org./Einrichtung SET<TEL> 0..1


4 ent elm addr Adresse der Org./Einrichtung SET<AD> 0..1


<author>
	<time value="2000040714"/>
	<assignedAuthor>
		<id extension="KP00017" root="2.16.840.1.113883.19.5"/>
		<assignedPerson>
			<name>
				<prefix>Dr.</prefix>
				<family>Dolin</family>
				<given>Robert</given>
			</name>
		</assignedPerson>
		<representedOrganization>
			<id root="2.16.840.1.113883.19.5"/>
		</representedOrganization>
	</assignedAuthor>
</author>


Participant: med. Dokumentar (dataEnterer)

Diese Information gibt an, wer die Information in das System eingegeben hat. Üblicherweise ist das dann der medizinische Dokumentar. Dieser Abschnitt ist optional.

Lvl RIM AE Name Desc DT Kard Conf Beschreibung


1 act elm
2 rel elm
1 part elm Participant Versicherung 0..*
2 role elm
4 ent elm


???

Participant: Melder (informant)

Melder im Sinne des Worgebrauchs durch die Register.

Participant: Absender (custodian)

Wer hat das Dokument abgeschickt. Das ist üblicherweise entweder das Krankenhaus oder das Tumorzentrum.

Normalerweise wird das über die Transportinformation gelöst. Wenn das aber persistent mit Bestandteil des Dokumentes sein soll, dann ist der Custodian der beste Platz, weil der "Verwalter" des Dokumentes dann auch am ehesten der "Absender" ist.


Absender

Abbildung 17: Identifikation des Absender

Lvl RIM AE Name Desc DT Kard Conf Beschreibung
0 act elm ClinicalDocument
1 part elm custodian Absender 1..1 M Wer hat das Dokument abgeschickt.
2 part att typeCode "CST" CD CNE 1..1 M
2 role elm assignedCustodian 1..1 M
3 role att classCode "ASSIGNED" 1..1 M


4 ent elm representedCustodianOrganisation verwaltende/absendede Organisation 0..1
5 ent elm id Identifikation der Organisation SET<II> 1..* M
6 ent att @extension eigentliche ID der Organisation ST 1..1 M
6 ent att @root OID der Organisation ST 1..1 M
5 ent elm name Name der Organisation ON 0..1
5 ent elm telecom Kontaktinformation der Organisation TEL 0..1
5 ent elm addr Adresse der Organisation AD 0..1
<custodian>
	<assignedCustodian>
		<representedCustodianOrganization>
			<id root="2.16.840.1.113883.19.5"/>
			<name>Good Health Clinic</name>
		</representedCustodianOrganization>
	</assignedCustodian>
</custodian>

Participant: Empfänger (informationRecipient)

Als Empfänger kommen hier sowohl die Krebsregister als auch Praxen und Krankenhäuser in Frage.


In dem Attribut „informationRecipient" wird angegeben, an welches Krebsregister oder Praxis/Krankenhaus die Daten übermittelt werden. Hier wird die „scoping" Entität „Organisation" (gestrichelte Linie) genutzt.

ID des Empfängers

Abbildung 17: Identifikation des Empfängers

Lvl RIM AE Name Desc DT Kard Conf Beschreibung
0 act elm ClinicalDocument
1 part elm informationRecipient Empfänger 0..* optional
2 part att typeCode "" CD CNE 1..1 M
2 role elm IntendedRecipient 0..* M
3 role att classCode 1..1 M
3 role att id Register-ID SET<II> 0..* M
4 ent elm informationRecipient 0..1 optional


5 ent elm Person 0..1 optional
6 ent elm name Name der Person SET<PN> 0..* optional
4 ent elm receivedOrganisation 0..1 optional


5 ent elm Organisation 0..1 optional
6 ent elm name Name der Organisation SET<ON> 0..* optional


Participant: Versicherung (participant)

Lvl RIM AE Name Desc DT Kard Conf Beschreibung


1 act elm
2 rel elm
1 part elm Participant Versicherung 0..*
2 role elm
4 ent elm


???

Allgemeiner Aufbau des Body

An dieser Stelle sei auf den VHitG-Arztbrief verwiesen.

Abschnitt entspricht Component, Klasse entspricht Section.

Abschnitt Kard. Klasse Referenz auf Abschnitt
Header
s.o.
Body
Meldebegründungdaten 0..1
Meldebegründung Participant
Diagnostik 0..*
Untersuchung
Ergebnis
Phänomen
Erkrankungsdaten
Beteiligter Participant
Erkrankungsdaten 0..*
Meldebegründungdaten
Erkrankung
Phänomendaten
Phänomendaten 0..*
Phänomen
Operation 0..*
Beteiligter Participant
Operative Therapie
Erkrankungsdaten
Phänomendaten
Bestrahlung 0..*
Beteiligter Participant
Strahlentherapie
Erkrankungsdaten
Phänomendaten
Einzelbestrahlung
Medikamentendaten 0..*
Einzelgabe
Dauergabe
Systemisch 0..*
Beteiligter Participant
Systemtherapie
Erkrankungsdaten
Phänomendaten
Zyklus
Zyklustag
Medikamentendaten
Status (Nachsorge und anderes Follow-up) 0..*
Prozedur
Ergebnis
Erkrankungsdaten
Phänomendaten
Studiendaten 0..*
Studie
Erkrankungsdaten
Abschlussdaten 0..*
Prozedur
Ergebnis
Erkrankungsdaten
Planung 0..*
Prozedur
Ergebnis
Erkrankungsdaten
Phänomendaten
Operation
Bestrahlung
Systemisch
Status (Nachsorge und anderes Follow-up)
Studiendaten
Diagnostik

Tabelle 8: Dokument-Inhalte TODO Abschnitte: Section bekommen eine Template-ID. Die iwird im Rahmenb des OID-Konzepts vergeben: 1.2.276.0.76.3.1.10.? (Deutsche Krebsgesellschaft e.V. …131=DKG, 1=Version des OID-Konzeptes, 10=Template) Template Level: Documenmt/Section/Entry


graphische Übersicht

Abschnittsübersicht

Abbildung 18: Abschnittsübersicht

Abschnitte

Nachfolgend werden die einzelnen Abschnitte im Detail erläutert.

Nationalität

Template ID <OID für das Template>
General Description In diesem Abschnitt wird die Nationalität des Patienten übermittelt.
LOINC Code Opt. Description
???? O

Value Set: 1.3.6.1.4.1.12559.11.10.1.3.1.42.4

Value Set Name: VS11_epSOSCountry

Code System: ISO-3166-1

Sterbedatum

Template ID IHE PCC Health Status 1.3.6.1.4.1.19376.1.5.3.1.4.1.2
General Description In diesem Abschnitt wird der Gesundheitszustand des Patienten übermittelt.
LOINC Code Opt. Description
11323-3 O Health Status

Das Sterbedatum ist dann eine konkrete Beobachtung darin.

Die folgenden Snomed CT Codes (vgl. IHE PCC Vol.2 6.3.4.5.8) stehen zur Verfügung:

Code Description
81323004 Alive and well
313386006 In remission
162467007 Symptom free
161901003 Chronically ill
271593001 Severely ill
21134002 Disabled
161045001 Severely disabled
419099009 Deceased


<entry>
 <observation classCode='OBS' moodCode='EVN'>
  <entryRelationship typeCode='REFR' inversionInd='false'>
    <observation classCode='OBS' moodCode='EVN'>
      <templateId root='2.16.840.1.113883.10.20.1.51'/>
      <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.1.2'/>
      <code code='11323-3' displayName='Health Status'
            codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC' />
      <text><reference value='#hstatus-2'/></text>
      <statusCode code='completed'/>
      <value xsi:type='CE' code=' ' codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT'/>
    </observation>
  </entryRelationship>
  </observation>
</entry>

Meldebegründungsdaten

Template ID 1.2.276.0.76.3.1.131.1.10.2.1
General Description In diesem Abschnitt wird die Begründung für die Meldung übermittelt.
LOINC Code Opt. Description
???? O

Eine Meldebegründung gibt den rechtlichen Kontext der Meldung wider. Dies unterscheidet sich von Bundesland zu Bundesland. In Ländern mit Meldepflicht muss der Patient in der Regel informiert werden. Ausnahmen gibt es ggf. wenn der Patient verstorben ist oder ihm eine Mitteilung nicht zugemutet werden kann (oder bei Meldungen von Pathologen). Bei Meldepflicht gibt es grundsätzlich ein Widerspruchsrecht. Bei Meldrecht muss der Patient zustimmen. Weitere Variationen bestehen im Einverständnis zur Nutzung der Daten für weitergehende Forschung. An dieser Stelle sollte auch die Zustimmung zur Meldung ans klinische Krebsregister berücksichtigt werden. Diese kann ggf. zukünftig auch nach unterschiedlichen Nutzungszwecken unterschieden werden.

Meldebegründugn

Abbildung 19: Observation für die Meldebegründung


Lvl RIM AE Name Desc DT Kard Conf Beschreibung
1 act elm section 1..1 required
2 act att @classCode "DOCSECT" CD CNE 1..1 required
2 act att @moodCode "EVN" CD CNE 1..1 required
2 act elm templateID OID für Meldebegründungsabschnitt ST 1..1 required
3 act att @root "1.2.276.0.76.3.1.131.1.10.2.1" ST 1..1 required
2 act elm code Code für Meldebegründungsabschnitt CD CNE 1..1 required
2 act elm title Titel des Abschnitts ST 1..1 required fix "Meldebegründung"
2 act elm text Text für die Meldebegründung ST 1..1 required
2 rel elm entry 1..1 required
3 act elm observation 1..1 required
4 act att @classCode "OBS" CD CNE 1..1 required fix
4 act att @moodCode "EVN" CD CNE 1..1 required fix
4 act elm code Es handelt sich um eine Meldebegründung CD CNE 1..1 required
4 act elm value Meldebegründung CD CNE 1..1 required Wie wird die Meldebegründung tatsächlich begründet. Hier ist ein Code aus 1.2.276.0.76.3.1.131.1.5.1 zu verwenden.


4 act elm effectiveTime Zeitpunkt der Meldebegründung TS 1..1 required Das Datum, an dem der Patient unterrichtet wurde oder er unterschrieben hat.
4 part elm 0..1 optional
5 part att @typeCode "AUTH" CD CNE 0..1 optional fix
5 role elm author 1..1 required Diese Section sollte ein Autor Element enthalten, wenn der Autor dieser Section von dem in höheren Ebenen des Dokuments verschieden ist.


6 ent elm Person Arzt 0..1 optional Wer hat die Meldebegründung unterschrieben.
7 ent elm Name 0..1 optional Name des Meldenden


Wie lautet die eigentliche Meldebründung, die im Kontext der Meldung an bestimmte KR z.B. aus Abrechnungsgründen übertragen werden soll:

Lvl Code Bedeutung Erläuterung
1 Patient ist informiert
2 E Einwilligung Die Einwilligung des Patienten liegt vor
2 W Widerspruch zu Kontaktaufnahme Patient(in) ist informiert und hat Kontaktaufnahme widersprochen
2 I Information Patientin / Patient wurde informiert und hat nicht widersprochen
2 Widerspruch zur Übermittlung Der Patient hat einer Über¬mittlung seiner Daten widersprochen, so dass die Daten nicht übermittelt werden.
1 A Ausnahme Patientenunterrichtung entfallen wegen möglicher gesundheitlicher Nachteile
1 V Verstorben
1 D Meldung von diagnostisch tätigen Ärzten ohne unmittelbaren Patientenkontakt

Tabelle 9: Codesystem für die Meldebegründung (Zustimmung), OID: 1.2.276.0.76.3.1.131.1.5.1

Die genauen Formulierungen sind von Bundesland zu Bundesland verschieden. Die vorhergehende Tabelle deckt aber alle Erfordernisse ab, so dass spezifische Teilmengen für die einzelnen Bundesländer über ValueSets realisiert werden können/müssen. Die für die einzelnen Bundesländer gültigen Werte sind nachfolgend definiert:

Code, Land E A I V D W ValueSet OID
Baden Württemberg - - - - - -
Bayern, Saarland X X X TODO
Berlin - - - - - -
Brandenburg - - - - - -
Bremen X X X X TODO
Hamburg, Niedersachsen X X X TODO
Hessen, Rheinland Pfalz - - - - - -
Mecklenburg-Vorpommern - - - - - -
Nordrhein-Westfalen X X TODO
Sachsen-Anhalt - - - - - - TODO
Sachsen - - - - - -
Thüringen - - - - - -

Tabelle 10: bundeslandspezifische ValueSets für die Meldebegründung; bei Bundesländern, welche diese Meldebegründungen nicht entgegennehmen, wurde ein "[-]" vergeben, OID: n.n.

Wenn zwei Bundesländer dieselben Wertemengen vorgeben, so wird dafür dieselbe Value Set OID verwendet.

Qualifier – Zustimmung für KKR

In einem Qualifier kann angegeben werden, ob die Daten auch an das zuständige klinische bzw. epidemiologische Krebsregister übermittelt werden dürfen oder nicht.

Code Bedeutung Erläuterung
EKR
KKR
QS

Tabelle 11: Vocabulary Domain für die Zustimmung wohin

Anm.: Diese Tabelle muss ggf. weiter ergänzt werden bzw. bundeslandspezifisch festgelegt werden.


Beispiel

Das 1. Beispiel muss in dem zweiten Beispiel aufgehen, d.h. soll verschwinden:

<!-- Meldebegründung -->
<observation classCode="OBS" moodCode="EVN" negationInd="false">
    <code codeSystem="2.16.840.1.113883.5.4" 
          code="ASSERTION" />
    <statusCode code="completed" />
    <!-- Datum der Meldebegründung -->
    <effectiveTime value="201011051500" />
    <!-- Typ der Meldebegründung -->
    <value xsi:type="CD"
           code="E"
           codeSystem="????"
           codeSystemName="????"
           displayName="Einwilligung">

      <!-- Zustimmung zur Meldebegründung -->
      <qualifier>
        <name codeSystem="1.2.276.0.76...." 
              codeSystemName="?????" <!-- Tabelle der Zustimmungen -->
              code="KKR" <!—- EKR\|KKR ... -->
              displayName="Zustimmung"/> 
        <value codeSystem="????" 
               codeSystemName="Zustimmung zur Weiterleitung" 
               code="Y" 
               displayName="ja"/>
      </qualifier>

    </value>
</observation>


<section>
   <templateId root="1.2.276.0.76.3.1.131.1.10.2.1"/>
   <code code=" ?????" codeSystem="2.16.840.1.113883.6.1"
         codeSystemName="LOINC"/>
   <title>Meldebegründung</title>
   <text>Der Patient hat in die Meldung eingewilligt.</text>

   <entry>

      <!-- Meldebegründung mit Datum -->
      <observation classCode="OBS" moodCode="EVN">
        <id>3473847/01</id> <!-- optionale ID für Referenzzwecke -->
        <!-- Wo würde dargestellt, wo die Meldebegründung erstellt wurde, 
                 Referenz auf Participant -->
        <code code="gekidMeldebegruendung" codeSystem="1.2.276.0.76.3.1.131.1.5.1"
            codeSystemName="DKG-Labels" displayName="Meldebegründung"/>
        <statusCode code="completed"/>
        <effectiveTime>
            <low value="20101022"/>
        </effectiveTime>
        <value xsi:type="CD" 
                code="E" displayName="Meldung an EKR-BW "
                codeSystem="1.2.276.0.76.3.1.131.1.5.2"
                codeSystemName="Meldebegruendung"/>
         </value>
      </observation>

      <!-- Kodierung der Zustimmung -->
      <observation classCode="OBS" moodCode="EVN">
      <code code="?????" codeSystem="??????"
            codeSystemName="LOINC" displayName="Zustimmung"/>
         <statusCode code="completed"/>
         <value xsi:type="CD" 
                code="????" displayName="?????"
                codeSystem="?????"
                codeSystemName="?????"/>
         </value>
      </observation>

      <!-- Kodierung der Information -->
      <observation classCode="OBS" moodCode="EVN">
      <code code="?????" codeSystem="??????"
            codeSystemName="LOINC" displayName="Information über Meldung"/>
         <statusCode code="completed"/>
         <value xsi:type="CD" 
                code="????" displayName="?????"
                codeSystem="?????"
                codeSystemName="?????"/>
         </value>
      </observation>

      <!-- Kodierung des Widerspruchs -->
      <observation classCode="OBS" moodCode="EVN">
      <code code="?????" codeSystem="??????"
            codeSystemName="LOINC" displayName="Widerspruch gegen Meldung"/>
         <statusCode code="completed"/>
         <value xsi:type="CD" 
                code="????" displayName="?????"
                codeSystem="?????"
                codeSystemName="?????"/>
         </value>
      </observation>

   </entry>
</section>

Schematron

Hier müssen noch die Schematronregeln zur Prüfung des Inhaltes hin....

Diagnosen

Template ID <OID für das Template>
General Description In diesem Abschnitt wird die Diagnosen zum Patienten übermittelt.
LOINC Code Opt. Description
???? O

Die Diagnose umfasst folgende Punkte, die über separate Observations ausgedrückt werden:

Diagnosen

Abbildung 20: Section ->Diagnose


Lvl RIM AE Name Desc DT Kard Conf Beschreibung


1 act elm
2 rel elm
1 part elm
2 role elm
4 ent elm


TODO Abgleich Klassifikationsliste KRBW (Altmann)

Anlaß der Diagnosestellung

Code Beschreibung
E Eigenuntersuchung (Selbstuntersuchung)
F gesetzl. Früherkennung
V nicht gesetzl Vorsorge
C Screening
A Anamnese
N Nachsorge
T Tumorsymptomatik
U Unbekannt

Art der Diagnosesicherung

Code Beschreibung
1 klinisch ohne spez. Diagnostik
2 klinische Diagnostik
4 spez. Tumormaker
5 Zytologie
6 Histologie Metastase
7 Histologie Primärtumor

Diagnostik

Abbildung 21: Diagnostik

=> Abschnitt Verlaufsbeurteilung

Code Bedeutung Erläuterung
K keine Fernmetastasen nachweisbar
E Fernmetastasen vor Ersttherapie
M verbliebene Fernmetastasen
R neu aufgetretene Fernmetastasen (Rezidiv)
B neue und verbliebene Fernmetastasen
F fraglicher Befund
X unbekannt

Tabelle 12: Vocabulary Domain für Art der Fernmetastasen (Kap 3.11.3.1)


=> Phänomendaten

Code Bedeutung Erläuterung
PUL Lunge
OSS Knochen
HEP Leber
BRA Hirn
LYM Lymphknoten
MAR Knochenmark
PLE Pleura
PER Peritoneum
ADR Nebennieren
SKI Haut
SPL Milz
GEN Generalisierte Metastasierung
OTH andere Organe

Tabelle 13: Vocabulary Domain für das Organlokalisation für Fernmetastasen (Kap. 2.15.2 u. 3.11.3.2)

=> Abschnitt Verlaufsbeurteilung

Code Bedeutung Erläuterung
K kein Tumor nachweisbar
E Primärtumor vor Ersttherapie
T Tumorreste ( Residualtumor )
R LokalRezidiv
F fraglicher Befund
X Unbekannt

Tabelle 14: Vocabulary Domain für Primäturmor (Kap. 3.11.1)

=> Abschnitt Verlaufsbeurteilung

Code Bedeutung Erläuterung
K keine regionären Lymphknotenmetastasen
E Lymphknotenmetastase(n) vor der Ersttherapie
T ResidualTumor in regionären Lymphknoten
R Lymphknotenrezidiv / neu aufgetretene Lymphknotenmetastasen
B verbliebene und neue Lymphknotenmetastasen / LK-Rezidiv
F fraglicher Befund
X Unbekannt

Tabelle 15: Vocabulary Domain für regionäre Lymphknotenmetastasen (Kap.3.11.2)

Code Bedeutung Erläuterung
L Lokoregionär
F Fernmetastase(n)
B Beides (Lokoregionär und Fernmetastase(n))
X Unbekannt

Tabelle 16: Vocabulary Domain für Residualtumor (Kap.4.2.2)

Anlass der Diagnosestellung

als Qualifier ????

Code Bedeutung Erläuterung
E Eigenuntersuchung (Selbstuntersuchung)
F Gesetz. Früherkennung
V Nicht gesetzl. Vorsorge
C Screening
A Anamnese
N Nachsorge

Tabelle 17: Vocabulary Domain für Diagnoseanlass

Diagnosesicherung

Wie ist die Diagnose gesichert worden?

Code Bedeutung Erläuterung
1 Klinische spez. Diagnostik
2 Klinische Diagnostik
4 Spez. Tumormarker
5 Zytologie
6 Histologie Metastase
7 Histologie Primärtumor

Tabelle 18: Vocabulary Domain für Diagnosesicherung


Tabellen für TNM aus dem Diagnoseleitfaden

Die nachfolgenden Tabellen sind implizit schon im Diagnoseleitfaden enthalten und können deshalb hier entfallen!

Code Bedeutung Erläuterung
R0 R0 (kein Residualtumor)
R1 R1 (mikroskopischer Residualtumor)
R2 R2
R2a R2a (makr.Residualtumor, mikr. nicht bestätigt)
R2b R2b (makr.Residualtumor, mikroskop. bestätigt)
RX RX (Vorhandensein von Residualtumor kann n. beurteilt werden)

Tabelle 19: Vocabulary Domain für TNM R-Klassifikation (Kap.4.2.1)

=> Phänomen und Erkrankungsdaten, Spezifikation Diagnoseleitfaden


Referenzen

  • Phänomen => über entryRelationship/observation
  • Erkankungsdaten => über entryRelationship/observation
  • Participant => über participation

Todesursache

Template ID <OID für das Template>
General Description In diesem Abschnitt werden die Informationen zur Todesursache übermittelt.
LOINC Code Opt. Description
???? O

Die Übermittlung der Todesursache wird über eine separate Observation ausgedrückt, die aber in demselben Abschnitt (Section) untergebracht wird:

  1. Diagnostik

Abbildung 22: Diagnostik

Lvl RIM AE Name Desc DT Kard Conf Beschreibung


1 act elm Section 0..1 Dieser Abschnitt übermittelt Informationen über die Todesursache.
2 act att @code CD CWE 1..1 M Dieser Code besagt, dass dieser Abschnitt über die Todesursache berichtet.
2 rel elm Entry
3 act elm Observation Tod
4 act elm Observation Tod durch Tumor 1..1 M
5 act att @code Tod durch Tumor CD CWE 1..1 M Dieses Attribut drückt aus, dass diese Beobachtung Aufschluss über die Todesursache gibt.
5 act att @value Tod durch Tumor CD CWE 1..1 M Hier wird die Information (Code) zur Todesursache eingetragen: s.u. Codesystem zur Todesursache.
5 act att @negationInd Negation BL 0..1 Wenn gesetzt drückt dieses Attribut aus, dass der Tumor nicht tumorbedingt ist/war.
4 rel elm Entry
5 act elm Observation Beruf Spezialfall einiger EKR (z.B. GKR Gemeinsames Krebsregister, längster letzter Beruf, Dauer) => spätere Ausbauphase. Wird als Freitext und ggf. nach speziellem Berufe¬schlüssel übermittelt.
6 act att @code Tod durch Beruf CD CWE 1..1 M Dieses Attribut drückt aus, dass diese Beobachtung angibt, ob der Tod ursächlich durch die Berufsausübung veranlasst ist.
6 act att @value Tod durch Beruf BL 1..1 Ein boolescher Wert gibt an, ob der Krebs durch die Berufsausübung (Kap. 1.8.5) entstanden ist.

Wenn diese Aussage nicht gesichert (Verdacht) ist, dann wird dies über einen entsprechenden qualifier zum Ausdruck gebracht. Wenn nicht klar ist, ob die Berufsausübung ursächlich für den Krebs ist, dann ist dies durch einen nullFlavor auszudrücken.


6 act att @negationInd Negation BL 0..1 Wenn gesetzt drückt dieses Attribut aus, dass der Tumor nicht berufsbedingt ist/war.


Lvl Code Bedeutung Erläuterung
1 J Tod tumorbedingt, keine nähere Angabe
2 T Tod tumorbedingt durch das Tumorleiden, keine nähere Angabe
2 P Tod tumorbedingt durch Progression des primären Tumorgeschehens
2 L Tod tumorbedingt durch lokoregionäres Rezidiv
2 M Tod tumorbedingt durch Fernmetastasierung
2 B Tod tumorbedingt durch Behandlungskomplikation
1 E Entscheidung nicht möglich
1 nullFlavor="NI" „unbekannt" wird über einen nullFlavor zum Ausdruck gebracht.

Tabelle 20: Vocabulary Domain für Todesursache (Kap 7.5)
(OID: ????)

Erkrankungsdaten

Template ID <OID für das Template>
General Description In diesem Abschnitt werden die Daten zur Erkankung übermittelt.
LOINC Code Opt. Description
???? O

Erkrankungsdaten

Abbildung ??: Erkrankungsdaten


Lvl RIM AE Name Desc DT Kard Conf Beschreibung


1 act elm
2 rel elm
1 part elm
2 role elm
4 ent elm


????????

ID
Adresse Erkrankungszeitpunkt

Diagnosetext
Diagnosedatum
Code+System
Diagnosecode
Diagnosesicherheit
Diagnoseanlass


 <!-- Erkrankung -->
  <observation classCode="OBS" moodCode="EVN" >
    <!—- Siehe identifikatoren -->
    <!-- Jede Tumorerkrankung bekommt eine eigene, über die Zeit konstante ID, s.o. -->
    <id root="<OID-des Senders>" extension="4711-0815-123"> 
    <code code="?DX?" codeSystem="2.16.840.1.113883.3.7.1.?"
      codeSystemName="LOINC" displayName="?Primärerkrankung"/>
    <statusCode code="completed"/>
    <effectiveTime>
	      <low value="20110112"/> 
	    </effectiveTime>
	    <value xsi:type="CD" code="C50.1" codeSystem="1.2.276.0.76.5.311"
	       codeSystemName="ICD10gm2011">
		<originalText>Mammakarzinom</originalText>
		<qualifier>
		  <name code="8" codeSystem="2.16.840.1.113883.3.7.1"
		    displayName="Diagnosesicherheit"/>
		  <value code="G" codeSystem="2.16.840.1.113883.3.7.1.8"
		    displayName="Gesichert"/>
		</qualifier>
		<qualifier>
		  <name code="?" codeSystem="?siehe Anhang 1.?" 
 displayName = "Diagnoseanlass"/>
		  <value code="V" codeSystem = "?Diagnoseanlass?" 
 displayName = "Vorsorge"/>
		</qualifier>
 	    </value>
	  </observation>

Phänomendaten

Template ID <OID für das Template>
General Description In diesem Abschnitt werdne die Daten zum Phänomen übermittelt.
LOINC Code Opt. Description
???? O

Phänomendaten

Abbildung ??: Phänomendaten

Lvl RIM AE Name Desc DT Kard Conf Beschreibung


1 act elm
2 rel elm
1 part elm
2 role elm
4 ent elm



Phänomen Primärtumor

Codierung nach Lokalisationsschlüssel oder alternativ ICD-O-3 Topographie.

Todo: Beispiel Unterschiede ICD-ICD-0. Beispiel Unterschied Topographie Lokalisations¬schlüssels.

OIDs für die Schlüsselsysteme Seitenangabe als Qualifier gemäß Qualifier für ICD im Diagnoseleitfaden Zu klären kostenlose Verwendbarkeit der SNOMED Einträge für Seitenangabe, ansonsten eigene Liste


Phänomen Fernmetastase

Codierung nach Dreisteller laut TNM, Lokalisationsschlüssel oder ICD-O-3 Topographie

OIDs für die Schlüsselsysteme


Phänomen Komplikation: das Attribut - code

@ Attribut DT Card Conf Beschreibung
@code CD CWE 0..1 required Ziel der Intention



Code Bedeutung Erläuterung
ABD Abszeß in einem Drainagekanal
ABS Abszeß, intraabdominaler oder intrathorakaler (z.B. Leberabszeß, subphrenischer Abszeß)
AEE Anastomoseninsuffizienz einer Enterostomie
AEP Alkoholentzugspsychose
ALR Allergische Reaktion ohne Schocksymptomatik
ANI Akute Niereninsuffizienz
ANS Anaphylaktischer Schock
API Apoplektischer Insult
ASF Abszeß, subfaszialer
BIF Biliäre Fistel
BOE Bolusverlegung eines Endotubus
BOG Blutung, obere gastrointestinale (z.B "Streßulkus")
BSI Bronchusstumpfinsuffizienz
CHI Cholangitis
DAI Darmanastomoseninsuffizienz
DEP Drogenentzugspsychose
DIC Disseminierte intravasale Koagulopathie
DLU Druck- und Lagerungsschäden, z.B. Dekubitalulzera
DPS Darmpassagestörungen (z.B. protrahierte Atonie, Subileus, Ileus)
DSI Duodenalstumpfinsuffizienz
ENF Enterale Fistel
GER Gerinnungsstörung
HAE Hämorrhagischer Schock
HEM Hämatemesis
HFI Harnfistel
HNA Hirnnervenausfälle
HNK Hautnekrose im Operationsbereich
HOP Hirnorganisches Psychosyndrom (z.B. "Durchgangssyndrom")
HRS Herzrhythmusstörungen
HUR Hämaturie
HYB Hyperbilirubinämie
HYF Hypopharynxfistel
HZI Herzinsuffizienz
IFV Ileofemorale Venenthrombose
KAS Kardiogener Schock
KDS Kurzdarmsyndrom
KES Komplikationen einer Stomaanlage
KIM Komplikation eines Implantates (Gefäßprothese, Totalendoprothese, Katheter), z.B. Dislokation
KRA Krampfanfall
LEV Leberversagen
LOE Lungenödem
LYE Lymphozele
LYF Lymphfistel
MAT Mesenterialarterien- oder -venenthrombose
MED Mediastinitis
MES Magenentleerungsstörung
MIL Mechanischer Ileus
MYI Myokardinfarkt
NAB Nachblutung, nicht revisionsbedürftig, anderweitig nicht erwähnt
NIN Nahtinsuffizienz, anderweitig nicht erwähnt
OES Ösophagitis
OSM Osteitis, Osteomyelitis
PAB Peranale Blutung
PAE Pulmonalarterienembolie
PAF Pankreasfistel
PAV Peripherer arterieller Verschluß (Embolie, Thrombose)
PDA Protrahierte Darmatonie (paralytischer Ileus)
PER Peritonitis
PEY Pleuraempyem
PIT Pankreatitis
PLB Platzbauch
PLE Pleuraerguß
PMN Pneumonie
PNT Pneumothorax
PPA Periphere Parese
RIN Respiratorische Insuffizienz
RNB Nachblutung, revisionsbedürftig, anderweitig nicht erwähnt
RPA Rekurrensparese
SES Septischer Schock
SFH Störungen des Flüssigkeits-, Elektrolyt- und Säurebasenhaushaltes
SKI Septische Komplikation eines Implantates
SON sonstige Komplikationen
STK Stomakomplikation (z.B. Blutung, Nekrose, Stenose)
TIA TIA (transitorische ischämische Attacke) oder RIND (reversibles ischämisches neurologisches Defizit)
TRZ Transfusionszwischenfall
TZP Thrombozytopenie
WSS Wundheilungsstörung, subkutane
WSSnr Wundheilungsstörung, subkutane, nicht revisionsbedürftig
WSSr Wundheilungsstörung, subkutane, revisionsbedürftig
WUH Wundhämatom (konservativ therapiert)

Tabelle 21: Vocabulary Domain für Phänomen Codes


Qualifier für Revisionsbedürftigkeit

Die Festlegung, wie Revisionsbedürftigkeit festzustellen ist, erfolgt im jeweiligen Kontext und wird z.B. durch ONKOZERT-Kriterien festgelegt.

Code Bedeutung Erläuterung
J Ja, revisionsbedürftig
N Nein, nicht revisionsbedürftig
U Unbekannt

Tabelle 22: Vocabulary Domain für Qualifier zu Phänomenen

Operation (operative Therapie)

Template ID 1.2.276.0.76.3.1.131.1.10.2.7 ????
General Description In diesem Abschnitt werden die Daten über die Operation übermittelt.
LOINC Code Opt. Description
???? O


Die Operation ist ein Eingriff zu therapeutischen (Beispiel: Ablation der Mamma) oder diagnostischen (Beispiel: Stanzbiopsie) Zwecken. Neben den durchgeführten Prozeduren sind hier auch die Intention der Therapie, die durchführenden Personen (Operateure) sowie die ggf. aufgetretenen Komplikationen von Bedeutung.

Eine operative Therapie kann aus mehreren Operationen bestehen. Hierbei wird für jede Operation ein Entry in der Section „Operative Therapie“ generiert.


Operation

Abbildung 23: Operation

<component>
	<section>
		<templateId root="1.2.276.0.76.3.1.131.1.10.2.7"/>
		<code code="" codesystem="" />
		<title>Operative Therapie</title>
		<text>
			Brusterhaltende Exzision der Mamma links am 31.03.2011, kurativ.<br>
			Operateur: Dr. med. Max Meier PhD<br>
			Partielle (brusterhaltende) Exzision der Mamma<br>
			Sentinel-Lymphonodektomie mit Radionuklidmarkierung<br>
			Komplikationen sind aufgetreten:<br>
			<ul>
			<il>subkutane Wundheilungsstörung, nicht revisionsbedürftig</il>
			</ul>
		</text>
		<entry typeCode="DRIV">
			<procedure classCode="PROC" moodCode="EVN">
				<templateID root="??????"/>
				<id extension="op12345" 
					root="1.2.276.0.76.3.1.131.1.4.3.9999.9999.999911"/>
				<code code="OP" displayName="Operation"
							codeSystem="1.2.276.0.76.3.1.131.1.5.14">
					<qualifier>
						<name code="IntentionOfTherapy" 
								codeSystem="1.2.276.0.76.3.1.131.1.5.1"/>
						<value xsi:type="CD" code="K" 
								codeSystem="1.2.276.0.76.3.1.131.1.5.18"/>
					</qualifier>
				</code>
				<statusCode code="completed"/>
				<effectiveTime value="20110331"/>
				<performer typeCode="PRF">
					<assignedEntity>
						<id extension="54321" 
							root="1.2.276.0.76.3.1.131.1.4.3.9999.9999.999905"/>
						<assignedPerson>
							<name>
								<prefix qualifier="AC">Dr. med.</prefix>
								<given>Max</given>
								<family>Meier</family>
								<suffix qualifier="AC">PhD</suffix>
							</name>
						</assignedPerson>
					</assignedEntity>
				</performer>
				<entryRelationship typeCode="COMP">
					<procedure classCode="PROC" moodCode="EVN">
						<code code="5-870.60" codeSystem="1.2.276.0.76.5.410"/>
					</procedure>
				</entryRelationship>
				<entryRelationship typeCode="COMP">
					<procedure classCode="PROC" moodCode="EVN">
						<code code="5-401.11" codeSystem="1.2.276.0.76.5.410"/>
					</procedure>
				</entryRelationship>
				<entryRelationship typeCode="SPRT">
					<observation classCode="OBS" moodCode="EVN">
						<code code="116224001" codeSystem="2.16.840.1.113883.6.96"/>
						<value xsi:type="BL" value="true"/>
					</observation>
				</entryRelationship>
				<entryRelationship typeCode="SPRT">
					<observation classCode="OBS" moodCode="EVN">
						<code code="116224001" codeSystem="2.16.840.1.113883.6.96"/>
						<value xsi:type="CD" code="WSSnr" 
							codeSystem="1.2.276.0.76.3.1.131.1.5.15">
							<originalText>
								subkutane Wundheilungsstörung, 
								nicht revisionsbedürftig
							</originalText>
						</value>
					</observation>
				</entryRelationship>
			</procedure>
		</entry>
	</section>
</component>


Lvl RIM AE Name Desc DT Kard Conf Beschreibung
0 act elm section 1..1 required Dieses Element enthält den Text.
1 act att @classCode "DOCSECT" ST 1..1 required
1 act att @moodCode "EVN" ST 1..1 required
1 act elm code Code ST 1..1 required Dieser Code definiert den Inhalt des Abschnittes.
1 act elm title title ST 1..1 required Dieses Element gibt die Überschrift des Abschnittes an.
1 act elm text text ST 1..1 required Dieses Element enthält den Text.

Hier werden alle strukturiert enthaltenen Daten der Section als Freitext übermittelt. Für Operationen ist zusätzlich die Übermittlung zusätzlicher unstrukturierter Informationen zulässig.


1 act elm procedure 1..1 required Dieses Element repräsentiert die gesamte (einzelne) Operation.
2 act att procedure@classCode classCode <= PROC 1..1
2 act att @moodCode <= x_DocumentProcedureMood 1..1
2 act elm id Identifikation der Operation SET<II> 1..* required Über dieses Element wird die Operation eindeutig identifiziert. Somit ist dieses Element required. Die Kombination der Attribute root und extension identifiziert die Operation systemübergreifend eindeutig.
3 act att @root Root-OID ST 1..1 required Dieses Attribut ist ein eindeutiger Identifikator für Operationen innerhalb eines bestimmten sendenden Systems.


3 act att @extension ST 1..1 required Dieses Attribut ist innerhalb des sendenden Systems ein eindeutiger Identifikator für die Operation.


3 act elm code durchgeführte Operation CD CWE 0..1 optional
3 act elm text Freitext ED 0..1 optional
3 act elm statusCode <= completed ST 1..1 required Über dieses Attribut wird der Status angegeben, in dem der beschriebene Act sich befindet. Ein Act kann z.B. den Status „new", „active" oder „cancelled" besitzen. Die Beobachtung einer Operation wird mit der Dokumentation als abgeschlossene Handlung betrachtet. Somit wird für das Attribut statusCode der feste Wert „completed" vorgegeben.
3 act elm effectiveTime Durchführungszeitraum IVL<TS> 0..1 optional Dieses Element gibt den Durchführungszeitraum der Therapie an. Benötigt wird Tagesgenauigkeit, bei einer Operation werden daher nicht Beginn und Ende angegeben, sondern das Datum im value-Attribut übermittelt.
3 rel elm entryRelationship Intention 0..1 optional Ziel der Operation.
4 act elm Observation Intention 0..1 optional Ziel der Operation.
5 act elm code Ziel der Intention CD CWE 0..1 Diese Klasse im Intent Mood drückt das Ziel aus.
5 act att value Ziel der Intention CD CWE 0..1
3 rel elm entryRelationship Komplikation 0..1 optional
4 act elm Observation Komplikation 0..1 optional Oft reicht in Bezug auf Komplikationen die einfache Information aus, ob diese aufgetreten sind. Dies wird als observation innerhalb einer entryRelationship übermittelt.
5 act elm code Komplikation 0..1 optional Der code für diese Observation ist fix. Es wird der entsprechende SNOMED-CT-Code verwendet.
5 act elm value 0..1 optional Die Information, ob Komplikationen aufgetreten sind, wird als boolscher Wert übermittelt. Ist diese Information nicht bekannt, kann dies als nullFlavor="UNK" übermittelt werden.


3 rel elm entryRelationship Bestandteil 0..1 optional einzelne Prozedur
4 act elm Procedure Einzelprozeduren 0..1 optional Eine Operation besteht häufig aus mehreren Einzelprozeduren. Jede Einzelprozedur wird als procedure in einer entryRelationship übermittelt. Beliebig viele entryRelationships sind zulässig.
5 act elm code 0..1 optional Im code-Element werden die durchführten Einzelprozeduren übermittelt. Im Rahmen dieses Leitfadens wird der Operationen- und Prozedurenschlüssel (OPS) verwendet. Zulässig sind alle Fassungen von OPS.
3 part elm performer performer 0..1 optional Hier werden die Angaben zu Operateur(en) übermittelt. Die Übermittlung mehrerer Operateure ist zulässig.


4 role elm AssignedEntity 0..1 optional ausführender Arzt
5 role elm AssignedEntity.role 0..1 optional Über dieses Element wird der Operateur eindeutig identifiziert. Somit ist dieses Element required. Die Kombination der Attribute root und extension identifiziert den Operateur systemübergreifend eindeutig.


5 ent elm Person 0..1 optional Arzt
6 ent elm name PN 0..1 optional Name des Operateurs
3 part elm participant Teilnehmer 0..1 optional ausführender Arzt
4 role elm ParticipantRole 0..1 optional sonstiger Teilnehmer
5 ent elm Person 0..1 optional Teilnehmer


Lvl Code Bedeutung Erläuterung
1 OP Operation 1), 2), 3), 4),bei Operativer Therapie Fixwert
1 RAD Strahlentherapie 1), 2), 3)
2 RAD-B Brachytherapie 4) ADT-Basisdatensatz unter¬scheidet hier in den Strahlen¬therapiedaten endokavitär und interstitiell
2 RAD-T Teletherapie 4)
2 RAD-S sonstige Strahlentherapie 4)
1 NUK
2 NUK-J Radiojodtherapie 4)
2 NUK-O offene Radionuklide 4)
2 NUK-S sonstige Nuklearmedizinische Therapie 4)
1 CHE Chemotherapie 1), 2), 3)
1 HOR Hormontherapie / Antihormonelle Therapie 1), 2), 3)
1
2 KNTR Knochenmarktransplantation 1), 2)
2 STAMM Stammzelltransplantation 2)
3 STAMM-L Autologe Stammzelltransplantation 4)
3 STAMM-G Sonstige Stammzelltransplantation 4)
3 STAMM-S Allogene Stammzelltransplantation 4)
1 IMM Antikörper / Immuntherapie 1), 2), 3)
1 SCHM Schmerztherapie 2)
1 PSY Psychoonkologie 2)
1 SM Sonstige Medikamentöse Therapie 4)
1 WS Wait and see / Active surveillance 4) Wait and see und Active Surveillance sind eigentlich deutlich verschieden und müssen in Prostata¬karzinom¬zentren unterschieden werden
1 ATH
nullFlavour=OTH
Sonstige / andere Therapie 1), 2), 3)
2 ATH-HY Hyperthermie 4)

Tabelle 23: Codesystem für Operationen

  1. GeKiD-Mindestdatensatz
  2. ADT Basisdatensatz „Verlaufsdaten" (HOR wurde dort vergessen, Hormontherapie ist aber auf dem Bogen)
  3. GKR (Gemeinsames Krebsregister)
  4. KRBW (Krebsregister Baden-Württemberg)

Problematisch ist:

  1. die unterschiedliche Tiefe , z.B. RAD allgemein vs. Differenzierung in unterschiedliche Subformen der Strahlen- und nuklearmedizinischen Therapie
  2. mangelnde Abbildung neuer medikamentöser (Zytokine, Signal-Transduktions-Inhibitoren, …) und bestimmter Untergruppen supportiver Therapie (z.B. Bisphosphonate)
  3. mangelnde Abbildung kombinierter Therapien, und damit die Diskussion prä- und post-koordinierter Ansatz .

KRBW: post-koordinierter Ansatz durch eine Kennzeichnung zusammengehöriger Therapien (MULTIMODALE_THERAPIE).


Code Bedeutung Erläuterung
A Abgelehnt
V vorgesehen
T Terminiert
B Begonnen
R regulär beendet
vorzeitig beendet

Tabelle 25: Codesystem für die Qualifier zu den Operationen


Lvl Code Bedeutung Erläuterung
1 N Nein 1) (in der Wirklichkeit verbirgt sich hier eine große Zahl unterschiedlicher Negationen, die durchaus im Rahmen von Organzentren relevant sein können) ???
2 N-A abgelehnt 3) rejected
1 V vorgesehen 2), 4) statusCode=ActStatusNew
2 V-T terminiert 4) moodCode=APT (Mood)???
1 J Ja 1), 2) statusCode=ActStatusNormal???
2 J-B begonnen 4) (implizit aus leerem „Ende-Datum") statusCode=ActStatusActive
2 J-E regulär beendet 3) statusCode=ActStatusCompleted
2 J-A vorzeitig beendet 3), 5) (Abbruch wegen Nebenwirkungen) statusCode=ActStatusAborted
1 U Unbekannt 1) nullFlavor=UNK

Tabelle 26: Codesystem für Operation statusCode

  1. GeKiD / GKR
  2. ADT- Basisdatensatz „Verlaufsdaten" (nur implizit)
  3. Information auf ADT- Basisdatensatz Systemisch und Strahlentherapie
  4. Information teilweise relevant für Kennzahlenberechnung in Organzentren
  5. KRBW


Code Bedeutung Erläuterung
K kurativ
P palliativ
D diagnostisch nur bei Operationen
U unbekannt bzw. nicht anwendbar / sonstige Therapie besser nullFlavor

Tabelle 27: Codesystem für Operation code


Stellung der Therapie im Gesamtkonzept

Code Bedeutung Erläuterung
N neoadjuvant
I intraoperativ (neuer Code, November 2010)
A adjuvant
U unbekannt bzw. nicht anwendbar / sonstige Therapie besser als nullFlavor

Tabelle 28: Codesysstem für Operation code

Bestrahlung

Template ID <OID für das Template>
General Description In diesem Abschnitt werden die Bestrahlungsdaten übermittelt.
LOINC Code Opt. Description
???? O

Die Bestrahlung an sich ist eine Prozedur. Allerdings bestehen Beziehungen zu Phänomenen, die als Beobachtung kommuniziert werden.

Bestrahlung

Abbildung 24: Bestrahlung

Lvl RIM AE Name Desc DT Kard Conf Beschreibung


1 act elm
2 rel elm
1 part elm
2 role elm
4 ent elm


  <component>
    <observation classCode="OBS" moodCode="EVN">
      <templateId root="2.16.840.1.113883.10.20.5.2.5.1"/>
      <code  codeSystem="2.16.840.1.113883.6.1"|
             codeSystemName="LOINC" code="41852-5"
             displayName="Microorganism identified"/>
      <value xsi:type="CD"
             codeSystem="2.16.840.1.113883.6.96"
             codeSystemName="SNOMED"
             code="116197008"
             displayName="Staphylococcus, coagulase negative (organism)"/>
    </observation>
  </component>

Medikamentendaten

Template ID <OID für das Template>
General Description In diesem Abschnitt wird die Daten zur Medikation übermittelt.
LOINC Code Opt. Description
???? O


Medikation

Abbildung 26: Medikation (gemäß IHE PCC)

Lvl RIM AE Name Desc DT Kard Conf Beschreibung


1 act elm
2 rel elm
1 part elm
2 role elm
4 ent elm


Aus dem VHitG-Arztbrief:

 <substanceAdministration moodCode="EVN" classCode="SBADM" negationInd="true">
  <templateId root="2.16.840.1.113883.10.20.5.6.42"/>
 
  <consumable>
      <manufacturedProduct classCode="MANU">
          <manufacturedMaterial classCode="MMAT">
          <code code="8611"
                codeSystem="2.16.840.1.113883.6.88"
                codeSystemName="RxNorm"
                displayName="Povidone iodine"/>
          </manufacturedMaterial>
      </manufacturedProduct>
  </consumable>
 
 </substanceAdministration>


Aus IHE PCC TF 2:6.1.4.16.2

 <substanceAdministration classCode="SBADM" moodCode="INT\|EVN">
  <templateId root="2.16.840.1.113883.10.20.1.24"/>
  <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>
  <templateId root=""/>
  <id root=\’\’ extension=\’\’/>
  <code code=\’\’ codeSystem=\’\’ displayName=\’\’ codeSystemName=\’\’/>
  <text><reference value=\’\#med-1\’/></text>
  <statusCode code=\’completed\’/>
  <effectiveTime xsi:type=\’IVL_TS\’>
    <low value=\’\’/>
    <high value=\’\’/>
  </effectiveTime>
  <effectiveTime operator=\’A\’ xsi:type=\’TS\|PIVL_TS\|EIVL_TS\|PIVL_PPD_TS\|SXPR_TS\’>
    :
  </effectiveTime>
  <routeCode code=\’\’ codeSystem=\’\’ displayName=\’\’ codeSystemName=\’\’/>
  <doseQuantity value=\’\’ unit=\’\’/>
  <approachSiteCode code=\’\’ codeSystem=\’\’ displayName=\’\’ codeSystemName=\’\’/>
  <rateQuantity value=\’\’ unit=\’\’/>
  <consumable>
    :
    .
  </consumable>
  <!-- 0..\* entries describing the components -->
  <entryRelationship typeCode=\’COMP\’ >
    <sequenceNumber value=\’\’/>
  </entryRelationship>
  <!-- An optional entry relationship that indicates the the reason for use -->
  <entryRelationship typeCode=\’RSON\’>
    <act classCode=\’ACT\’ moodCode=\’EVN\’>
      <templateId root=\’1.3.6.1.4.1.19376.1.5.3.1.4.4.1\’/>
      <id root=\’\’ extension=\’\’/>
    </act>
  </entryRelationship>
  <!-- An optional entry relationship that provides prescription activity -->
  <entryRelationship typeCode=\’REFR\’>
    <templateId root=\’1.3.6.1.4.1.19376.1.5.3.1.4.7.3\’/>
    :
    .
  </entryRelationship>
  <precondition>
    <criterion>
      <text><reference value=\’\’></text>
    </criterion>
  </precondition>
 </substanceAdministation>

systemisch(e Therapie)

Template ID <OID für das Template>
General Description In diesem Abschnitt wird die Daten zur systemischen Therapie übermittelt.
LOINC Code Opt. Description
???? O
Lvl RIM AE Name Desc DT Kard Conf Beschreibung


1 act elm
2 rel elm
1 part elm
2 role elm
4 ent elm

Status (Nachsorge und andere Follow-Up)

Template ID <OID für das Template>
General Description In diesem Abschnitt wird der Status zur Nachsorge und andere Follow-Ups übermittelt.
LOINC Code Opt. Description
???? O
Lvl RIM AE Name Desc DT Kard Conf Beschreibung


1 act elm
2 rel elm
1 part elm
2 role elm
4 ent elm

Studiendaten

Template ID <OID für das Template>
General Description In diesem Abschnitt werdne Studiendaten übermittelt.
LOINC Code Opt. Description
???? O  
Lvl RIM AE Name Desc DT Kard Conf Beschreibung


1 act elm
2 rel elm
1 part elm
2 role elm
4 ent elm

Abschlussdaten

Template ID <OID für das Template>
General Description In diesem Abschnitt wird die Abschlussdaten übermittelt.
LOINC Code Opt. Description
???? O  
Lvl RIM AE Name Desc DT Kard Conf Beschreibung


1 act elm
2 rel elm
1 part elm
2 role elm
4 ent elm

Planung

Planungsdaten

Abbildung ??: Planungsdaten

??????

Lvl RIM AE Name Desc DT Kard Conf Beschreibung


1 act elm
2 rel elm
1 part elm
2 role elm
4 ent elm

Ann Arbor (Score)

Template ID <OID für das Template>
General Description In diesem Abschnitt wird der Ann Arbor Score übermittelt.
Hier ist zu beachten, dass es bereits Modelle zur Übermittlung von Scores gibt, die wiederverwendet werden können.
LOINC Code Opt. Description
???? O

Ann Arbor Score

Abbildung ??: Ann Arbor Score

??????


Lvl RIM AE Name Desc DT Kard Conf Beschreibung
1 act elm
2 rel elm
1 part elm
2 role elm
4 ent elm