Statisches Modell

Aus Hl7wiki
(Teildokument von Übermittlung onkologischer Daten)
Wechseln zu: Navigation, Suche
(Participant: Empfänger (informationRecipient))
K
 
(142 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
{{DocumentPart}}
 
{{DocumentPart}}
  
=Statisches Modell (Grundlagen)=
+
=Statisches Modell=
  
 
==Einleitung==
 
==Einleitung==
Zeile 196: Zeile 196:
 
Dieses Attribut bestimmt, ob der übergeordnete Kontext übernommen wird oder nicht.
 
Dieses Attribut bestimmt, ob der übergeordnete Kontext übernommen wird oder nicht.
  
===Handhabung von Negationen===
+
==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.
 
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===
+
==Handhabung von Korrekturen und Folgemeldungen==
????????
 
  
=Statisches Modell (Details)=
+
{{FAQBox|
 +
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.
  
==Dokumentenstruktur==
+
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.
Im CDA-Header wird 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
 
|-
 
| bgcolor="ffdddd"|typeID||II||- konstant -||1..1
 
|-
 
| bgcolor="ffdddd"|templateID||II||Template ID für das ganze Dokument||1..1
 
|-
 
| bgcolor="ffdddd"|id||II||Dokumenten-ID||1..1
 
|-
 
| bgcolor="ffdddd"|code||CE||Dokumententyp||1..1
 
|-
 
| bgcolor="ffdddd"|title||ST||Titel des Dokuments||0..1
 
|-
 
| bgcolor="ffdddd"|effectiveTime||TS||Erstellungsdatum des Dokuments||1..1
 
|-
 
| bgcolor="ffdddd"|confidentialityCode||CE||Vertraulichkeitsgrad||1..1
 
|-
 
| bgcolor="ffdddd"|languageCode||CS||Sprache des Dokuments||1..1
 
|-
 
| bgcolor="ffdddd"|setID||II||Set-Kennung||0..1
 
|-
 
| bgcolor="ffdddd"|versionNumber||INT||Versionsnummer||0..1
 
|-
 
| bgcolor="ffdddd"|copyTime||TS||- nicht verwendet -||0..0
 
  
|- bgcolor="ccccFF"
 
|'''Participations'''||||||
 
|-
 
| bgcolor="ccccFF"|recordTarget||||Patient||1..1
 
|-
 
| bgcolor="ccccFF"|author|| ||Autor (hier: nur das meldende Softwaresystem)||1..1
 
|-
 
| bgcolor="ccccFF"|dataEnterer|| ||Datentypist: med. Dokumentar(in)||0..1
 
|-
 
| bgcolor="ccccFF"|informant|| ||Informationsquelle, Melder im Sinne der Krebsregister-Terminologie (Arzt und/oder Organisation)||1..*
 
|-
 
| bgcolor="ccccFF"|custodian|| ||Absender (Organisation). Kann identisch mit dem Melder sein oder z.B. ein regionales Tumorregister, das Daten an das Landeskrebsregister weiterleitet.||1..1
 
|-
 
| bgcolor="ccccFF"|informationRecipient||||Empfänger: klinisches oder epidemiologisches Krebsregister||1..1
 
|-
 
| bgcolor="ccccFF"|legalAuthenticator|| ||- nicht verwendet -||0..0
 
|-
 
| bgcolor="ccccFF"|authenticator|| ||- nicht verwendet -||0..0
 
|-
 
| bgcolor="ccccFF"|participant||||diverse Teilnehmer, d.h. Person bzw. Organisation, <br>z.B. Krankenversicherung||0..*
 
|- bgcolor="ffdddd"
 
| bgcolor="ffdddd"|'''Act Relationship'''|| || ||
 
|-
 
| bgcolor="ffdddd"|inFullfillmentOf|| || ||0..0
 
|-
 
| bgcolor="ffdddd"|documentationOf|| || ||0..0
 
|-
 
| bgcolor="ffdddd"|relatedDocuments|| ||Verweis auf frühere Versionen ||0..1
 
|-
 
| bgcolor="ffdddd"|authorization|| || ||0..0
 
|-
 
| bgcolor="ffdddd"|componentOf|| || ||0..0
 
|-
 
| bgcolor="ffdddd"|component|| || ||0..0
 
|-
 
|}
 
Tabelle 4: Dokumentenstruktur (-bestandteile)
 
  
 
==Meldeanlässe und Inhalte==
 
==Meldeanlässe und Inhalte==
Zeile 366: Zeile 300:
  
 
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)
 
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:
 
 
{| class="hl7table"
 
!Dokumententyp!!Beschreibung!!Dok.-Template-ID
 
|-
 
|Diagnose-Meldung||Meldung bei Feststellung eines Tumors oder bei Abschluss der primären Tumordiagnostik||1.2.276.0.76.3.1.131.1.10.1.1
 
|-
 
|Therapie-Meldung||Meldung nach Beginn oder Beendigung der Therapie||1.2.276.0.76.3.1.131.1.10.1.2
 
|-
 
|Verlaufs-Meldung||Meldung zum Verlauf/Nachbeobachtung, z.B. Nachsorge||1.2.276.0.76.3.1.131.1.10.1.3
 
|-
 
|Abschluss-Meldung||Meldung zum Abschluss der Erkrankung (z.B. Tod des Patienten oder Lost to Follow Up)||1.2.276.0.76.3.1.131.1.10.1.4
 
|}
 
Tabelle 6: Dokumententyp
 
 
 
{| 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
 
|-
 
|ergänzende Patientendaten||O||0..1||O||0..1||O||0..1||O||0..1||1.2.276.0.76.3.1.131.1.10.2.11
 
|-
 
|Meldebegründungsdaten||R||1..1||R||1..1||R||1..1||R||1..1||1.2.276.0.76.3.1.131.1.10.2.1
 
|-
 
|Erkrankungsdaten||R||1..1||R||1..1||R||1..1||R||1..1||1.2.276.0.76.3.1.131.1.10.2.2
 
|-
 
|Diagnostik||R||1..1|||||||||||||||1.2.276.0.76.3.1.131.1.10.2.3
 
|-
 
|Phänomendaten: Primär||R||1..1||||||||||||||1.2.276.0.76.3.1.131.1.10.2.6
 
|-
 
|Phänomendaten: Metastasen||O||0..*||||||O||0..*||||||1.2.276.0.76.3.1.131.1.10.2.6
 
|-
 
|Operation||||||R||0..*||||||||||1.2.276.0.76.3.1.131.1.10.2.7
 
|-
 
|Strahlentherapie||||||R||0..*||||||||||1.2.276.0.76.3.1.131.1.10.2.7
 
|-
 
|systemische Therapie||||||R||0..*||||||||||1.2.276.0.76.3.1.131.1.10.2.7
 
|-
 
|Medikation||||||O||0..*||||||||||vgl. Arztbrief 2012<br>TODO
 
|-
 
|Status (Nachsorge und andere Follow-Up)||||||||||R||1..1||R||1..1||1.2.276.0.76.3.1.131.1.10.2.8
 
|-
 
|Studiendaten||O||0..*||O||0..*||O||0..*||||||1.2.276.0.76.3.1.131.1.10.2.10
 
|-
 
|Abschlussdaten||||||||||||||R||1..1||1.2.276.0.76.3.1.131.1.10.2.9
 
|-
 
|Therapieplanung||||||O||0..1||O||0..1||||||TODO
 
|-
 
|}
 
Tabelle 4: Dokumenttypen mit Zuordnung der Sektionen
 
 
 
{{AlertBox|
 
Bei der Therapie muss einer der folgende Abschnitte vorhanden sein:
 
*Operation
 
*Strahlentherapie
 
*systemische Therapie
 
 
Dies muss dann über Schematron gesichert werden!
 
}}
 
 
==Korrekturmeldung==
 
{{FAQBox|
 
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==
 
Der Header enthält alle relevanten Metadaten. Nachfolgend der allgemeine Aufbau:
 
 
{| class="hl7table"
 
!Abschnitt!!Kard.!!Klasse!!Referenz auf Abschnitt
 
|-
 
|'''Header'''|| || ||
 
|-
 
|Metadaten|| || ||
 
|-
 
|Autor (Melder)|| || ||
 
|-
 
|Unterzeichner|| || ||
 
|-
 
|Patient|| || ||
 
|-
 
|Empfänger|| || ||
 
|-
 
|Participant|| || ||
 
|-
 
| &nbsp; || ||Versicherung||
 
|-
 
|'''Body'''|| || ||
 
|-
 
|Sektionen s.u. || || ||
 
|}
 
 
===Metadaten===
 
 
Zuerst die Metadaten:
 
 
[[file:Cdaonk_dokheader.gif|ID des Patienten]]
 
 
Abbildung 15a: Header des Dokuments
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
|-
 
|1
 
|bgcolor="ff8888"|act
 
|elm
 
|ClinicalDocument
 
|Dokument
 
|
 
|1..1
 
|M
 
 
|-
 
|2
 
|bgcolor="ff8888"|act
 
|elm
 
|realmCode
 
|
 
|CS
 
|1..1
 
|M
 
|fix
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@code
 
|"DE"
 
|
 
|1..1
 
|M
 
|fix
 
 
|-
 
|2
 
|bgcolor="ff8888"|act
 
|elm
 
|typeID
 
|
 
|II
 
|1..1
 
|M
 
|fix, identifiziert dieses Dokument als CDA-Dokument
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@root
 
|"2.16.840.1.113883.1.3"
 
|
 
|1..1
 
|M
 
|fix
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@extension
 
|"POCD_HD000040"
 
|
 
|1..1
 
|M
 
|fix
 
 
|-
 
|2
 
|bgcolor="ff8888"|act
 
|elm
 
|templateId
 
|Strukturidentifikation des Dokuments
 
|II
 
|1..1
 
|M
 
|Hier wird die Strukturbeschreibung des Dokumentes festgehalten.
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@root
 
|OID des Dokument-Templates
 
|
 
|1..1
 
|M
 
|
 
 
|-
 
|2
 
|bgcolor="ff8888"|act
 
|elm
 
|Id
 
|Identifikation einer Instanz des Dokuments
 
|II
 
|1..1
 
|M
 
|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 für Dokument-Instanzen
 
|
 
|1..1
 
|M
 
|OID des sendenden System, um Dokument-Instanzen eindeutig zu identifizieren
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@extension
 
|ID der Instanz des Dokuments im sendenden System
 
|
 
|1..1
 
|M
 
|
 
 
|-
 
|2
 
|bgcolor="ff8888"|act
 
|elm
 
|code
 
|Dokument-Art
 
|CE CWE
 
|1..1
 
|M
 
|fix, Value Set 1.2.276.0.76.3.1.131.1.11.1
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@code
 
|"x-physician-cancer-rep"
 
|
 
|1..1
 
|M
 
|fix vgl. IHE PCC Vol.2 Abschnitt 6.3.1.A.2
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@codeSystem
 
|"2.16.840.1.113883.6.1"
 
|
 
|1..1
 
|M
 
|fix
 
 
|-
 
|2
 
|bgcolor="ff8888"|act
 
|elm
 
|title
 
|Titel des Dokuments
 
|ST
 
|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
 
|der eigentliche Zeitpunkt
 
|
 
|1..1
 
|M
 
|
 
 
|-
 
|2
 
|bgcolor="ff8888"|act
 
|elm
 
|confidentialityCode
 
|Vertraulichkeit des Dokumentes
 
|CE CWE
 
|1..1
 
|M
 
|fix, Value Set 1.2.276.0.76.3.1.131.1.11.2
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@code
 
|"N"
 
|
 
|1..1
 
|M
 
|fix
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@codeSystem
 
|"2.16.840.1.113883.5.25"
 
|
 
|1..1
 
|M
 
|fix
 
 
|-
 
|2
 
|bgcolor="ff8888"|act
 
|elm
 
|languageCode
 
|Sprache des Dokumentes
 
|CS CNE
 
|0..1
 
|opt.
 
|fix
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@code
 
|"de-DE"
 
|
 
|1..1
 
|opt.
 
|fix
 
 
|-
 
|2
 
|bgcolor="ff8888"|act
 
|elm
 
|setId
 
|Setkennung
 
|II
 
|1..1
 
|M
 
|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 (vgl. versionNumber).
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@root
 
|OID für Dokument-Sets
 
|
 
|1..1
 
|M
 
|OID des sendenden Systems, um das Dokument-Set (Dokument versionsübergreifend) eindeutig zu identifizieren
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@extension
 
|ID des Dokument-Sets im sendenden System
 
|
 
|1..1
 
|M
 
|
 
 
|-
 
|2
 
|bgcolor="ff8888"|act
 
|elm
 
|versionNumber
 
|Versionsnummer
 
|INT
 
|1..1
 
|M
 
|Eine fortlaufende Nummer zur Versionierung des Dokumentes.
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|att
 
|@value
 
|Versionsnummer
 
|INT
 
|1..1
 
|
 
|Zusammen mit der Setkennung regelt dieses Element die Versionierung der Dokumente.
 
 
|-
 
|2
 
|bgcolor="ffaaaa"| rel
 
| elm
 
| relatedDocument
 
|
 
|
 
| 0..1
 
|
 
|
 
 
|-
 
|3
 
|bgcolor="ffaaaa"|rel
 
|att
 
|@typeCode
 
|"RPLC"
 
|
 
|1..1
 
|M
 
|fix
 
 
|-
 
|3
 
|bgcolor="ff8888"| act
 
| elm
 
| parentDocument
 
| Vorgänger-Dokument
 
|
 
| 1..1
 
| required
 
| Referenz auf ein Vorgänger-Dokument
 
 
|-
 
|4
 
|bgcolor="ff8888"| act
 
| elm
 
| id
 
| ID des Vorgänger-Dokuments
 
| II
 
| 1..1
 
| required
 
|
 
 
|-
 
|5
 
|bgcolor="ff8888"|act
 
|att
 
|@root
 
|OID für Dokument-Instanzen
 
|
 
|1..1
 
|M
 
|OID des sendenden System, um Dokument-Instanzen eindeutig zu identifizieren
 
 
|-
 
|5
 
|bgcolor="ff8888"|act
 
|att
 
|@extension
 
|ID der Instanz des Dokuments im sendenden System
 
|
 
|1..1
 
|M
 
|
 
|}
 
 
{| class="hl7table"
 
|-
 
!Code!!Codesystem!!Codesystem Name!!Bedeutung
 
|-
 
|34806-0||2.16.840.1.113883.6.1||LOINC||Oncology Note
 
|-
 
|x-physician-cancer-rep||2.16.840.1.113883.6.1||LOINC||Report to Cancer Registries
 
|}
 
Tabelle: Dokument-Arten (Value Set OID: 1.2.276.0.76.3.1.131.1.11.1)
 
 
{| class="hl7table"
 
|-
 
!Code!!Codesystem!!Codesystem Name!!Bedeutung
 
|-
 
|N||2.16.840.1.113883.5.25||HL7 Confidentiality Code||normal
 
|}
 
Tabelle: Vertraulichkeit (Value Set OID: 1.2.276.0.76.3.1.131.1.11.2)
 
 
<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"/>
 
<setId extension="a_set_id" root="OID"/>
 
<versionNumber value="1"/>
 
<recordTarget>
 
...
 
</recordTarget>
 
<author>
 
...
 
</author>
 
<author>
 
...
 
</author>
 
<dataEnterer>
 
...
 
</dataEnterer>
 
<informant>
 
...
 
</informant>
 
<custodian>
 
...
 
</custodian>
 
<informationRecipient>
 
...
 
</informationRecipient>
 
<participant>
 
...
 
</participant>
 
<relatedDocument typeCode="RPLC">
 
<parentDocument>
 
<id extension="xyy" root="OID"/>
 
</parentDocument>
 
</relatedDocument>
 
 
...
 
 
</ClinicalDocument>
 
</syntaxhighlight>
 
 
===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 oder andere Dokumente (beispielsweise auch Informationen im KIS-System des Krankenhauses), aus denen ein medizinischer Dokumentar die Informationen in ein System eingibt, das dann die Meldung an das Krebsregister versendet:
 
 
{| class="hl7table"
 
|-
 
!Beteiligter!!Abbildung in CDA!!Conf.
 
|-
 
|Arzt und/oder Krankenhaus, in der dieser beschäftigt ist (Melder in der Krebsregister-Terminologie)||informant||M
 
|-
 
|medizinischer Dokumentar im Krankenhaus||dataEnterer||O
 
|-
 
|System (Tumordokumentationssystem) im Krankenhaus||author (authoringDevice)||M
 
|-
 
|Organisation (Krankenhaus), die das System betreibt||custodian||M
 
|-
 
|Krebsregister||informationRecipient||O
 
|}
 
 
Im praktischen Einsatz sind für diese Variante i.d.R. die Angaben in informant.representedOrganization und custodian.representedCustodianOrganization inhaltlich gleich.
 
 
====Variante 2====
 
Ein regionales Krebsregister erstellt auf Basis der von Ärzten bzw. Krankenhäusern eingegangenen Meldungen eine neue Meldung an das Landeskrebsregister:
 
 
{| class="hl7table"
 
|-
 
!Beteiligter!!Abbildung in CDA!!Conf.
 
|-
 
|Arzt und/oder Organisation, der ursprünglichen Meldung (ggf. mehrere)||informant||M
 
|-
 
|medizinischer Dokumentar im regionalen Krebsregister||dataEnterer||O
 
|-
 
|System (Tumordokumentationssystem) im regionalen Krebsregister||author (authoringDevice)||M
 
|-
 
|Organisation (regionales Krebsregister), die das System betreibt||custodian||M
 
|-
 
|Landeskrebsregister||informationRecipient||O
 
|}
 
 
===Participant: Patient (recordTarget)===
 
 
 
[[file:Cdaonk_patient.gif|ID des Patienten]]
 
 
Abbildung 15: Identifikation des Patienten
 
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
|-
 
|0
 
|bgcolor="ff8888"|act
 
|elm
 
|ClinicalDocument
 
|Dokument
 
|
 
|1..1
 
|M
 
 
|-
 
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
| recordTarget
 
| Patient
 
|
 
| 1..1
 
| M
 
|
 
 
|-
 
| 2
 
|bgcolor="ccffff"| part
 
| att
 
| typeCode
 
| "RCT"
 
| CS CNE
 
| 1..1
 
| M
 
| fix
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
| patientRole
 
| Patient
 
|
 
| 1..1
 
| M
 
|
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| att
 
| classCode
 
| "PAT"
 
| CS CNE
 
| 1..1
 
| M
 
| fix
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| elm
 
| id
 
| Patient-ID
 
| II
 
| 1..*
 
| M
 
| Identifiziert eindeutig den Patienten
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| att
 
| @root
 
| OID für Patienten
 
|
 
| 1..1
 
| M
 
| OID des sendenden System, um Patienten eindeutig zu identifizieren
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| att
 
| @extension
 
| ID des Patienten im sendenden System
 
|
 
| 1..1
 
| M
 
|
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| elm
 
| addr
 
| Adresse
 
| AD
 
| 0..*
 
|
 
| Es soll immer eine Adresse übertragen werden. Bei anonymisierten bzw. pseudonymisierten Patienten kann dies auf eine Postleitzahl oder Bundesland reduziert werden.
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| elm
 
| streetname
 
| Strasse
 
| ST
 
| 0..1
 
| M
 
|
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| elm
 
| houseNumber
 
| Hausnummer
 
| ST
 
| 0..1
 
|
 
|
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| elm
 
| postalCode
 
| Postleitzahl
 
| ST
 
| 0..1
 
| M
 
| PLZ ohne Länderkennzeichen
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| elm
 
| city
 
| Wohnort
 
| ST
 
| 0..1
 
| M
 
|
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| elm
 
| country
 
| Land
 
| ST
 
| 0..1
 
| M
 
|
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| elm
 
| telecom
 
| Kontaktinformationen
 
| TEL
 
| 0..*
 
| M
 
| nicht verwendet
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
| patient
 
| Patient (Personendaten)
 
|
 
| 0..1
 
| optional
 
|
 
 
|-
 
| 5
 
|bgcolor="88ff88"| ent
 
| att
 
| classCode
 
| "PSN"
 
| CS CNE
 
| 1..1
 
| M
 
| fix
 
 
|-
 
| 5
 
|bgcolor="88ff88"| ent
 
| att
 
| determinerCode
 
| "INSTANCE"
 
| CS CNE
 
| 1..1
 
| M
 
| fix
 
 
|-
 
|5
 
|bgcolor="88ff88"|ent
 
| elm
 
| name
 
| Name des Patienten
 
| 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|
 
TODO: 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.<br>
 
Ebenso ist die Abbildung der pseudonymisierten Daten noch zu spezifizieren.
 
}}
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| prefix
 
| Anrede
 
| ST
 
| 0..1
 
| optional
 
| z.B. Herr, Frau, ...
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| prefix
 
| akademischer Titel
 
| ST
 
| 0..1
 
| optional
 
|
 
 
|-
 
|7
 
|bgcolor="88ff88"|ent
 
| att
 
| @qualifier
 
| "AC"
 
|
 
| 1..1
 
| optional
 
| fix (Qualifier für akademischen Titel)
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| given
 
| Vorname
 
| ST
 
| 0..*
 
| optional
 
|
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| family
 
| aktueller Familienname
 
| ST
 
| 0..*
 
| optional
 
|
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| family
 
| Geburtsname
 
| ST
 
| 0..*
 
| optional
 
|
 
 
|-
 
|7
 
|bgcolor="88ff88"|ent
 
| att
 
| @qualifier
 
| "BR"
 
|
 
| 1..1
 
| optional
 
| fix (Qualifier für Geburtsname)
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| family
 
| früherer Familienname (Adoption)
 
| ST
 
| 0..*
 
| optional
 
|
 
 
|-
 
|7
 
|bgcolor="88ff88"|ent
 
| att
 
| @qualifier
 
| "AD"
 
|
 
| 1..1
 
| optional
 
| fix (Qualifier für Adoptionsname)
 
 
|-
 
|5
 
|bgcolor="88ff88"|ent
 
| elm
 
| administrativeGenderCode
 
| Geschlecht
 
| CE CWE
 
| 0..1
 
| optional
 
| Codesystem 2.16.840.1.113883.5.1
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| att
 
| @code
 
| Code für das Geschlecht
 
|
 
| 1..1
 
| optional
 
|
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| att
 
| @codeSystem
 
| "2.16.840.1.113883.5.1"
 
|
 
| 1..1
 
| optional
 
| fix
 
 
|-
 
|5
 
|bgcolor="88ff88"|ent
 
| elm
 
| birthTime
 
| Geburtsdatum
 
| TS
 
| 0..1
 
| optional
 
|
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| att
 
| @value
 
| Zeitpunkt der Geburt
 
|
 
| 1..1
 
|
 
| tagesgenau
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
| providerOrganisation
 
| Krankenhaus
 
|
 
| 0..1
 
|
 
|nicht verwendet
 
 
|}
 
 
{| class="hl7table"
 
|-
 
!Code!!Bedeutung
 
|-
 
|F||weiblich
 
|-
 
|M||männlich
 
|-
 
|UN||undifferenziert, z.B. Hermaphrodit
 
|}
 
Tabelle: Geschlecht (Codesystem OID: 2.16.840.1.113883.5.1)
 
 
<syntaxhighlight lang="XML">
 
<recordTarget typeCode="RCT">
 
<patientRole classCode="PAT">
 
<id extension="12345678" root="1.2.276.0.76.3.1.131.1.4.3.9999.9999.999902"/>
 
<addr>
 
<streetName>Musterweg</streetName>
 
<houseNumber>10a</houseNumber>
 
<country>DE</country>
 
<postalCode>12345</postalCode>
 
<city>Musterstadt</city>
 
</addr>
 
<patient classCode="PSN" determinerCode="INSTANCE">
 
<name>
 
<prefix>Frau</prefix>
 
<prefix qualifier="AC">Dr. h.c.</prefix>
 
<given>Maria</given>
 
<family>Mustermann</family>
 
<family qualifier="BR">Musterfrau</family>
 
<family qualifier="AD">Musterfamilie</family>
 
</name>
 
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>
 
<birthTime value="19500619"/>
 
</patient>
 
</patientRole>
 
</recordTarget>
 
</syntaxhighlight>
 
 
===Participant: Sendendes System (author)===
 
 
[[file:Cdaonk_melder.gif|sendendes System]]
 
 
Abbildung 16: Sendendes System (TODO: nur authoringDevice ist relevant)
 
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
|-
 
|0
 
|bgcolor="ff8888"|act
 
|elm
 
|ClinicalDocument
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
| author
 
| Autor (hier: nur das sendende System)
 
|
 
| 1..1
 
| M
 
|
 
 
|-
 
| 2
 
|bgcolor="ccffff"| part
 
| att
 
| @typeCode
 
| "AUT"
 
| CS CNE
 
| 1..1
 
| M
 
| fix
 
 
|-
 
| 2
 
|bgcolor="ccffff"| part
 
| elm
 
| time
 
| Zeitpunkt der Erstellung des Dokuments
 
| TS
 
| 1..1
 
| M
 
|
 
 
|-
 
| 3
 
|bgcolor="ccffff"| part
 
| att
 
| @value
 
| der eigentliche Zeitpunkt
 
|
 
| 1..1
 
| M
 
|
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
| assignedAuthor
 
| Sendendes System
 
|
 
| 1..1
 
| M
 
| Informationen über das sendende System
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| att
 
| @classCode
 
| "ASSIGNED"
 
|
 
| 1..1
 
| M
 
| fix
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| elm
 
| id
 
| ID des sendenden Systems
 
| II
 
| 1..1
 
| M
 
|
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| att
 
| @extension
 
| eigentliche Identifikationsnummer des sendenden Systems
 
|
 
| 1..1
 
| M
 
|
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| att
 
| @root
 
| OID für Software-Instanzen
 
|
 
| 1..1
 
| M
 
|OID, um Instanzen von Softwaresystemen eindeutig zu identifizieren. Vergeben beispielsweise durch den Softwarehersteller.
 
 
|-
 
|3
 
|bgcolor="88ff88"|ent
 
| elm
 
| assignedAuthoringDevice
 
|
 
|
 
| 1..1
 
| M
 
|
 
 
|-
 
| 4
 
|bgcolor="88ff88"|ent
 
| att
 
| @classCode
 
| "DEV"
 
|
 
| 1..1
 
| M
 
| fix
 
 
|-
 
| 4
 
|bgcolor="88ff88"|ent
 
| att
 
| @determinerCode
 
| "INSTANCE"
 
|
 
| 1..1
 
| M
 
| fix
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
| softwareName
 
| Name der Software(-Instanz)
 
| ST
 
| 1..1
 
| M
 
|
 
 
|}
 
 
 
<syntaxhighlight lang="xml">
 
<author typeCode="AUT">
 
<time value="20120825"/>
 
<assignedAuthor classCode="ASSIGNED">
 
<id extension="eine_id_des_sendenden_systems" root="1.2.276.0.76.3.1.131.1.4.4.9999.4.999941"/>
 
<assignedAuthoringDevice classCode="DEV" determinerCode="INSTANCE">
 
<softwareName>DerHersteller DieSoftware V. 3.2.1 im KKH Musterstadt</softwareName>
 
</assignedAuthoringDevice>
 
</assignedAuthor>
 
</author>
 
</syntaxhighlight>
 
 
===Participant: medizinischer Dokumentar (dataEnterer)===
 
 
Diese Information gibt an, wer die Information in das System eingegeben hat. Üblicherweise ist dies der medizinische Dokumentar. Dieser Abschnitt ist optional.
 
 
{{AlertBox|
 
TODO: Hier fehlt das Diagramm
 
}}
 
 
Abbildung 16a: medizinischer Dokumentar
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
|-
 
|0
 
|bgcolor="ff8888"|act
 
|elm
 
|ClinicalDocument
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
| dataEnterer
 
| Medizinischer Dokumentar
 
|
 
| 0..1
 
| optional
 
|
 
 
|-
 
| 2
 
|bgcolor="ccffff"| part
 
| att
 
| typeCode
 
| "ENT"
 
|
 
| 1..1
 
| optional
 
| fix
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
| assignedEntity
 
|
 
|
 
| 1..1
 
| M
 
|
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| att
 
| classCode
 
| "ASSIGNED"
 
|
 
| 1..1
 
| M
 
| fix
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| elm
 
| id
 
| Identifikator des Dokumentars
 
| II
 
| 1..1
 
| M
 
| fix
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| att
 
| @extension
 
| Identifikation des Dokumentars im sendenden System
 
|
 
| 1..1
 
| M
 
|
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| att
 
| @root
 
| OID für Dokumentare
 
|
 
| 1..1
 
| M
 
| OID des sendenden Systems, um das Dokumentare eindeutig zu identifizieren
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
| assignedPerson
 
| Dokumentar
 
|
 
| 1..1
 
| M
 
|
 
 
|-
 
|5
 
|bgcolor="88ff88"|ent
 
| elm
 
| name
 
| Name des Dokumentars
 
|
 
| 0..1
 
| optional
 
|
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| prefix
 
| Anrede
 
| ST
 
| 0..1
 
| optional
 
| z.B. Herr, Frau, ...
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| prefix
 
| akademischer Titel
 
| ST
 
| 0..1
 
| optional
 
|
 
 
|-
 
|7
 
|bgcolor="88ff88"|ent
 
| att
 
| @qualifier
 
| "AC"
 
|
 
| 1..1
 
| optional
 
| fix (Qualifier für akademischen Titel)
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| given
 
| Vorname
 
| ST
 
| 0..1
 
| optional
 
|
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| family
 
| Nachname
 
| ST
 
| 0..1
 
| optional
 
|
 
 
|}
 
 
<syntaxhighlight lang="XML">
 
<dataEnterer typeCode="ENT">
 
<assignedEntity classCode="ASSIGNED">
 
<id extension="eine_id_des_dokumentars" root="1.2.276.0.76.3.1.131.1.4.3.9999.9999.999942"/>
 
<assignedPerson>
 
<name>
 
<prefix>Frau</prefix>
 
<prefix qualifier="AC">Dr.</prefix>
 
<given>Martha</given>
 
<family>Meier</family>
 
</name>
 
</assignedPerson>
 
</assignedEntity>
 
</dataEnterer>
 
</syntaxhighlight>
 
 
===Participant: Arzt, Melder (informant)===
 
Diese Participation gibt an, von wem die gemeldete Information stammt. Normalerweise wird die Information aus einem oder mehreren Arztbriefen entnommen. Hierüber kann angegeben werden, wer diese Arztbriefe verfasst hat. Daher kann dieser Abschnitt mehrfach vorkommen.
 
In der Terminologie der Krebsregister entspricht dies dem Melder.
 
 
{{AlertBox|
 
TODO: Hier fehlt das Diagramm
 
}}
 
 
Abbildung 16b: Arzt, Melder
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
|-
 
|0
 
|bgcolor="ff8888"|act
 
|elm
 
|ClinicalDocument
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
| informant
 
| Arzt, Melder
 
|
 
| 1..*
 
| M
 
|
 
 
|-
 
| 2
 
|bgcolor="ccffff"| part
 
| att
 
| typeCode
 
| "INF"
 
|
 
| 1..1
 
| M
 
| fix
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
| assignedEntity
 
|
 
|
 
| 1..1
 
| M
 
|
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| att
 
| classCode
 
| "ASSIGNED"
 
|
 
| 1..1
 
| M
 
| fix
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| elm
 
| id
 
| Identifikator des Melders
 
| II
 
| 1..1
 
| M
 
| fix
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| att
 
| @extension
 
| Identifikation des Melders
 
|
 
| 1..1
 
| M
 
| z.B. vom empfangenden Krebsregister vergeben
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| att
 
| @root
 
| OID für Melder
 
|
 
| 1..1
 
| M
 
| z.B. vom empfangenden Krebsregister vergeben
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| elm
 
| addr
 
| Adresse
 
| AD
 
| 0..*
 
|
 
|
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| elm
 
| streetname
 
| Strasse
 
| ST
 
| 0..1
 
| M
 
|
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| elm
 
| houseNumber
 
| Hausnummer
 
| ST
 
| 0..1
 
|
 
|
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| elm
 
| postalCode
 
| Postleitzahl
 
| ST
 
| 0..1
 
| M
 
| PLZ ohne Länderkennzeichen
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| elm
 
| city
 
| Wohnort
 
| ST
 
| 0..1
 
| M
 
|
 
 
|-
 
| 4
 
|bgcolor="ffff88"| role
 
| elm
 
| country
 
| Land
 
| ST
 
| 0..1
 
| M
 
|
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
| assignedPerson
 
| Melder (Person)
 
|
 
| 0..1
 
| optional
 
| Wird verwendet, wenn der Melder eine Person ist. Es soll immer eine Person oder/und eine Organisation enthalten sein.
 
 
|-
 
| 5
 
|bgcolor="88ff88"| ent
 
| att
 
| classCode
 
| "PSN"
 
| CS CNE
 
| 1..1
 
| optional
 
| fix
 
 
|-
 
| 5
 
|bgcolor="88ff88"| ent
 
| att
 
| determinerCode
 
| "INSTANCE"
 
| CS CNE
 
| 1..1
 
| optional
 
| fix
 
 
|-
 
|5
 
|bgcolor="88ff88"|ent
 
| elm
 
| name
 
| Name des Melders
 
| PN
 
| 0..*
 
| optional
 
|
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| prefix
 
| Anrede
 
| ST
 
| 0..1
 
| optional
 
| z.B. Herr, Frau, ...
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| prefix
 
| akademischer Titel
 
| ST
 
| 0..1
 
| optional
 
|
 
 
|-
 
|7
 
|bgcolor="88ff88"|ent
 
| att
 
| @qualifier
 
| "AC"
 
|
 
| 1..1
 
| optional
 
| fix (Qualifier für akademischen Titel)
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| given
 
| Vorname
 
| ST
 
| 0..*
 
| optional
 
|
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| family
 
| Familienname
 
| ST
 
| 0..*
 
| optional
 
|
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
| representedOrganization
 
| Melder (Organisation)
 
|
 
| 0..1
 
| optional
 
| Wird verwendet, wenn der Melder eine Organisation ist.
 
 
|-
 
| 5
 
|bgcolor="88ff88"| ent
 
| att
 
| classCode
 
| "ORG"
 
| CS CNE
 
| 1..1
 
| optional
 
| fix
 
 
|-
 
| 5
 
|bgcolor="88ff88"| ent
 
| att
 
| determinerCode
 
| "INSTANCE"
 
| CS CNE
 
| 1..1
 
| optional
 
| fix
 
 
|-
 
|5
 
|bgcolor="88ff88"|ent
 
| elm
 
| name
 
| Name der Organisation
 
| ON
 
| 0..1
 
| optional
 
|
 
 
|}
 
 
<syntaxhighlight lang="XML">
 
<informant typeCode="INF">
 
<assignedEntity classCode="ASSIGNED">
 
<id extension="eine_id_des_melders" root="1.2.276.0.76.3.1.131.1.4.4.9999.4.999901"/>
 
<addr>
 
<streetName>Kliniksweg</streetName>
 
<houseNumber>125-131</houseNumber>
 
<country>DE</country>
 
<postalCode>54321</postalCode>
 
<city>Musterhausen</city>
 
</addr>
 
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
 
<name>
 
<prefix qualifier="AC">Dr. med.</prefix>
 
<given>Thilo</given>
 
<family>Testmann</family>
 
</name>
 
</assignedPerson>
 
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
 
<name>Städtisches Klinikum Musterhausen</name>
 
</representedOrganization>
 
</assignedEntity>
 
</informant>
 
</syntaxhighlight>
 
 
===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_custodian.gif|Absender]]
 
 
Abbildung 17: Identifikation des Absenders
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
|-
 
|0
 
|bgcolor="ff8888"|act
 
|elm
 
|ClinicalDocument
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
| 1
 
|bgcolor="ccffff"| part
 
| elm
 
| custodian
 
| Absender
 
|
 
| 1..1
 
| M
 
| Wer hat das Dokument abgeschickt.
 
 
|-
 
| 2
 
|bgcolor="ccffff"| part
 
| att
 
| typeCode
 
| "CST"
 
| CS CNE
 
| 1..1
 
| M
 
|
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
| assignedCustodian
 
|
 
|
 
| 1..1
 
| M
 
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| att
 
| classCode
 
| "ASSIGNED"
 
| CS CNE
 
| 1..1
 
| M
 
|
 
 
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
| representedCustodianOrganisation
 
| verwaltende/absendede Organisation
 
|
 
| 1..1
 
|
 
|
 
 
|-
 
|5
 
|bgcolor="88ff88"|ent
 
| elm
 
| id
 
| Identifikation der Organisation
 
| II
 
| 1..*
 
| M
 
|
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| att
 
| @extension
 
| eigentliche ID der Organisation
 
|
 
| 1..1
 
| M
 
| In der Regel vom Datenempfänger vergeben
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| att
 
| @root
 
| OID der Organisation
 
|
 
| 1..1
 
| M
 
| In der Regel vom Datenempfänger vergeben
 
 
|-
 
|5
 
|bgcolor="88ff88"|ent
 
| elm
 
| name
 
| Name der Organisation
 
| ON
 
| 0..1
 
|
 
|
 
 
|-
 
|5
 
|bgcolor="88ff88"|ent
 
| elm
 
| telecom
 
| Kontaktinformation der Organisation
 
| TEL
 
| 0..1
 
|
 
| nicht verwendet
 
 
|-
 
| 5
 
|bgcolor="88ff88"| ent
 
| elm
 
| addr
 
| Adresse
 
| AD
 
| 0..1
 
|
 
|
 
 
|-
 
| 6
 
|bgcolor="88ff88"| ent
 
| elm
 
| streetname
 
| Strasse
 
| ST
 
| 0..1
 
|
 
|
 
 
|-
 
| 6
 
|bgcolor="88ff88"| ent
 
| elm
 
| houseNumber
 
| Hausnummer
 
| ST
 
| 0..1
 
|
 
|
 
 
|-
 
| 6
 
|bgcolor="88ff88"| ent
 
| elm
 
| postalCode
 
| Postleitzahl
 
| ST
 
| 0..1
 
|
 
| PLZ ohne Länderkennzeichen
 
 
|-
 
| 6
 
|bgcolor="88ff88"| ent
 
| elm
 
| city
 
| Wohnort
 
| ST
 
| 0..1
 
|
 
|
 
 
|-
 
| 6
 
|bgcolor="88ff88"| ent
 
| elm
 
| country
 
| Land
 
| ST
 
| 0..1
 
|
 
|
 
 
|}
 
 
<syntaxhighlight lang="xml">
 
<custodian typeCode="CST">
 
<assignedCustodian classCode="ASSIGNED">
 
<representedCustodianOrganization>
 
<id extension="eine_id_des_datenlieferanten" root="1.2.276.0.76.3.1.131.1.4.4.9999.4.999961"/>
 
<name>Regionales KKR für Süd-Ostwestfalen Nord</name>
 
<addr>
 
<streetName>Register-Allee</streetName>
 
<houseNumber>228</houseNumber>
 
<country>DE</country>
 
<postalCode>55555</postalCode>
 
<city>Krebsstadt</city>
 
</addr>
 
</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 17a: 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
 
| elm
 
| informationRecipient
 
| Empfänger
 
|
 
| 0..*
 
| optional
 
|
 
 
|-
 
| 2
 
|bgcolor="ccffff"| part
 
| att
 
| @typeCode
 
| "PRCP"
 
| CS CNE
 
| 1..1
 
| M
 
| fix
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
| IntendedRecipient
 
|
 
|
 
| 0..*
 
| M
 
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| att
 
| classCode
 
 
|
 
| 1..1
 
| M
 
|
 
 
|-
 
| 3
 
|bgcolor="ffff88"| role
 
| att
 
| id
 
| Register-ID
 
| SET<II>
 
| 0..*
 
| M
 
|
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
| informationRecipient
 
|
 
|
 
| 0..1
 
| optional
 
|
 
 
 
|-
 
|5
 
|bgcolor="88ff88"|ent
 
| elm
 
| Person
 
|
 
|
 
| 0..1
 
| optional
 
|
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| name
 
| Name der Person
 
| SET<PN>
 
| 0..*
 
| optional
 
|
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
| receivedOrganisation
 
|
 
|
 
| 0..1
 
| optional
 
|
 
 
 
|-
 
|5
 
|bgcolor="88ff88"|ent
 
| elm
 
| Organisation
 
|
 
|
 
| 0..1
 
| optional
 
|
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| name
 
| Name der Organisation
 
| SET<ON>
 
| 0..*
 
| optional
 
|
 
|}
 
 
===Participant: Versicherung (participant)===
 
 
{| 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
 
| Participant
 
| Versicherung
 
| 0..*
 
|
 
|
 
|
 
 
|-
 
| 2
 
|bgcolor="ffff88"| role
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|-
 
|4
 
|bgcolor="88ff88"|ent
 
| elm
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|}
 
 
 
???
 
 
==Allgemeiner Aufbau des Body==
 
An dieser Stelle sei auf den VHitG-Arztbrief verwiesen.
 
 
Abschnitt entspricht Component,
 
Klasse entspricht Section.
 
 
{| class="hl7table"
 
!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
 
  
  
Zeile 2.749: Zeile 306:
 
[[file:Cdaonk_abschnittsuebersicht.gif|Abschnittsübersicht]]
 
[[file:Cdaonk_abschnittsuebersicht.gif|Abschnittsübersicht]]
 
   
 
   
Abbildung 18: Abschnittsübersicht
+
Abbildung: Abschnittsübersicht (TODO: Diagramm muss aktualisiert werden!)
  
 
<syntaxhighlight lang="xml">
 
<syntaxhighlight lang="xml">
Zeile 2.778: Zeile 335:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
==Abschnitte==
 
Nachfolgend werden die einzelnen Abschnitte im Detail erläutert.
 
 
===Ergänzende Patientendaten===
 
 
 
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werden ergänzende Daten des Patienten übermittelt (derzeit nur die Nationalität).
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|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
+
==offene Punkte==
  
{{AlertBox|
+
{{WorkBox|
Modelliert man das über eine Sektion "Nationalität" oder als Teil einer allgemeineren Sektion "Ergänzende Patientendaten".<br> TODO!!!
+
TODO: Phänomen und Erkrankungsdaten, Spezifikation Diagnoseleitfaden - ist noch nicht ausgearbeitet<br/>
 +
Dieser Abschnitt muss weiter nach hinten.
 
}}
 
}}
  
===Sterbedatum===
 
 
 
{| 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.
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|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:
 
 
{| class="hl7table"
 
|-
 
!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
 
|}
 
 
 
<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>
 
 
===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.
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|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.
 
 
[[file:Cdaonk_meldebegruendung.gif|Meldebegründugn]]
 
 
Abbildung 19: Observation für die Meldebegründung
 
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
|-
 
| 1
 
|bgcolor="ff8888"| act
 
| elm
 
| section
 
|
 
|
 
| 1..1
 
| required
 
|
 
 
|-
 
| 2
 
|bgcolor="ff8888"| act
 
| att
 
| @classCode
 
| "DOCSECT"
 
| CD CNE
 
| 1..1
 
| required
 
|
 
 
|-
 
| 2
 
|bgcolor="ff8888"| act
 
| att
 
| @moodCode
 
| "EVN"
 
| CD CNE
 
| 1..1
 
| required
 
|
 
 
|-
 
| 2
 
|bgcolor="ff8888"| act
 
| elm
 
| templateID
 
| OID für Meldebegründungsabschnitt
 
| ST
 
| 1..1
 
| required
 
|
 
 
|-
 
| 3
 
|bgcolor="ff8888"| act
 
| att
 
| @root
 
| "1.2.276.0.76.3.1.131.1.10.2.1"
 
| ST
 
| 1..1
 
| required
 
|
 
 
|-
 
| 2
 
|bgcolor="ff8888"| act
 
| elm
 
| code
 
| Code für Meldebegründungsabschnitt
 
| CD CNE
 
| 1..1
 
| required
 
|
 
 
|-
 
| 2
 
|bgcolor="ff8888"| act
 
| elm
 
| title
 
| Titel des Abschnitts
 
| ST
 
| 1..1
 
| required
 
| fix "Meldebegründung"
 
 
|-
 
| 2
 
|bgcolor="ff8888"| act
 
| elm
 
| text
 
| Text für die Meldebegründung
 
| ST
 
| 1..1
 
| required
 
|
 
 
|-
 
| 2
 
|bgcolor="ffaaaa"| rel
 
| elm
 
| entry
 
|
 
|
 
| 1..1
 
| required
 
|
 
 
|-
 
| 3
 
|bgcolor="ff8888"| act
 
| elm
 
| observation
 
|
 
|
 
| 1..1
 
| required
 
|
 
 
|-
 
| 4
 
|bgcolor="ff8888"| act
 
| att
 
| @classCode
 
| "OBS"
 
| CD CNE
 
| 1..1
 
| required
 
| fix
 
 
|-
 
| 4
 
|bgcolor="ff8888"| act
 
| att
 
| @moodCode
 
| "EVN"
 
| CD CNE
 
| 1..1
 
| required
 
| fix
 
 
|-
 
| 4
 
|bgcolor="ff8888"| act
 
| elm
 
| code
 
| Es handelt sich um eine Meldebegründung
 
| CD CNE
 
| 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.
 
 
 
|-
 
| 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.
 
 
|-
 
| 4
 
|bgcolor="ccffff"| part
 
| elm
 
|
 
|
 
|
 
| 0..1
 
| optional
 
|
 
 
|-
 
| 5
 
|bgcolor="ccffff"| part
 
| att
 
| @typeCode
 
| "AUTH"
 
| CD CNE
 
| 0..1
 
| optional
 
| fix
 
 
|-
 
| 5
 
|bgcolor="ffff88"| 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
 
|bgcolor="88ff88"|ent
 
| elm
 
| Person
 
|
 
| Arzt
 
| 0..1
 
| optional
 
| Wer hat die Meldebegründung unterschrieben.
 
 
|-
 
| 7
 
|bgcolor="88ff88"|ent
 
| elm
 
| name|
 
| 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:
 
 
{| class="hl7table"
 
!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
 
 
{{AlertBox|
 
Bei nachträglichem Widerspruch sind die vorher übermittelten Daten wieder zu löschen.
 
}}
 
 
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"
 
!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 "&#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.
 
 
{| class="hl7table"
 
!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:
 
 
<syntaxhighlight lang="xml">
 
<!-- 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>
 
</syntaxhighlight>
 
 
 
 
<syntaxhighlight lang="xml">
 
<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>
 
</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.
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|-
 
| ???? || O ||
 
|}
 
 
Die Diagnose umfasst folgende Punkte, die über separate Observations ausgedrückt werden:
 
 
[[file:Cdaonk_diagnosen.gif|Diagnosen]]
 
 
Abbildung 20: Section ->Diagnose
 
 
{{AlertBox|
 
An dieser Stelle sei darauf verwiesen, dass hier das Komponentenmodell für die Tumordiagnosen aus dem Diagnoseleitfaden eingesetzt wird.
 
}}
 
 
 
{| 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
 
|
 
|
 
|
 
|
 
|
 
|
 
 
|}
 
 
 
 
TODO Abgleich Klassifikationsliste KRBW (Altmann)
 
 
Anlaß der Diagnosestellung
 
 
{|class="hl7table"
 
|-
 
!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
 
 
{|class="hl7table"
 
|-
 
!Code
 
!Beschreibung
 
|-
 
|1 || klinisch ohne spez. Diagnostik
 
|-
 
|2 || klinische Diagnostik
 
|-
 
|4 || spez. Tumormaker
 
|-
 
|5 || Zytologie
 
|-
 
|6 || Histologie Metastase
 
|-
 
|7 || Histologie Primärtumor
 
|}
 
 
[[file:Cdaonk_diagnostik.gif|Diagnostik]]
 
 
Abbildung 21: Diagnostik
 
 
=> Abschnitt Verlaufsbeurteilung
 
 
{| class="hl7table"
 
!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
 
 
{| class="hl7table"
 
!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
 
 
{| 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||
 
|-
 
|}
 
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"
 
!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 ????
 
 
{| class="hl7table"
 
!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?
 
 
{| class="hl7table"
 
!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!
 
 
{| class="hl7table"
 
!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
 
* Phänomen => über entryRelationship/observation
 
* Erkankungsdaten => über entryRelationship/observation
 
* Erkankungsdaten => über entryRelationship/observation
 
* Participant => über participation
 
* Participant => über participation
  
===Todesursache===
+
[[Kategorie:cdaonk|Statisches Modell]]
 
 
{| 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 ||
 
|}
 
 
 
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
 
|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.
 
 
 
|-
 
| 2
 
|bgcolor="ffaaaa"| rel
 
| elm
 
| Entry
 
|
 
|
 
|
 
|
 
|
 
 
 
|-
 
|3
 
|bgcolor="ff8888"|act
 
|elm
 
|Observation
 
|Tod
 
|
 
|
 
|
 
|
 
 
 
|-
 
|4
 
|bgcolor="ff8888"|act
 
|elm
 
|Observation
 
|Tod durch Tumor
 
|
 
|1..1
 
|M
 
|
 
 
 
|-
 
|5
 
|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
 
|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
 
|bgcolor="ff8888"|act
 
|att
 
|@negationInd
 
|Negation
 
|BL
 
|0..1
 
|
 
|Wenn gesetzt drückt dieses Attribut aus, dass der Tumor nicht tumorbedingt ist/war.
 
 
 
|-
 
| 4
 
|bgcolor="ffaaaa"| rel
 
| elm
 
| Entry
 
|
 
|
 
|
 
|
 
|
 
 
 
|-
 
|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.
 
 
 
|-
 
|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.
 
 
 
|-
 
|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.
 
 
 
 
 
|-
 
|6
 
|bgcolor="ff8888"|act
 
|att
 
|@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||
 
|-
 
|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
 
 
 
 
 
{| 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
 
|
 
|
 
|
 
|
 
|
 
|
 
 
 
|}
 
 
 
 
 
 
 
????????
 
 
 
{{AlertBox|Erkrankungsdaten = Observation}}
 
 
 
ID<br>
 
Adresse Erkrankungszeitpunkt<br>
 
<br>
 
Diagnosetext<br>
 
Diagnosedatum<br>
 
Code+System<br>
 
Diagnosecode<br>
 
Diagnosesicherheit<br>
 
Diagnoseanlass
 
 
 
 
 
<syntaxhighlight lang="xml">
 
<!-- 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>
 
</syntaxhighlight>
 
 
 
===Phänomendaten===
 
 
 
 
 
{| class="hl7table"
 
|bgcolor="ddddff"|Template ID|| colspan=2 | <OID für das Template>
 
|-
 
|bgcolor="ddddff"| General Description|| colspan=2 | In diesem Abschnitt werdne die Daten zum Phänomen übermittelt.
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|Description
 
|-
 
| ???? || O ||
 
|}
 
 
 
[[file:Cdaonk_phaenomendaten.gif|Phänomendaten]]
 
 
Abbildung ??: Phänomendaten
 
 
 
{| 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
 
|
 
|
 
|
 
|
 
|
 
|
 
 
 
|}
 
 
 
 
 
 
 
{{AlertBox|
 
Phaenomendaten &eq; Observation
 
}}
 
 
 
 
 
====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====
 
 
 
{{AttDesc
 
| ae = att
 
| rim = act
 
| name = @code
 
| desc = Ziel der Intention
 
| dt = CD CWE
 
| card = 0..1
 
| conf = required
 
}}
 
 
 
 
 
 
 
{| class="hl7table"
 
!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.
 
 
 
{| class="hl7table"
 
!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) ===
 
 
 
 
 
{| class="hl7table"
 
|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 werden die Daten über die Operation übermittelt.
 
|-
 
|bgcolor="ddddff"|LOINC Code||bgcolor="ddddff"|Opt.||bgcolor="ddddff"|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.
 
 
 
 
 
[[file:Cdaonk_operation.gif|Operation]]
 
 
Abbildung 23: Operation
 
 
 
<syntaxhighlight lang="xml">
 
<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>
 
</syntaxhighlight>
 
 
 
 
 
{| class="hl7table"
 
! Lvl
 
! RIM
 
! AE
 
! Name
 
! Desc
 
! DT
 
! Kard
 
! Conf
 
! Beschreibung
 
 
 
|-
 
| 0
 
|bgcolor="ff8888"| act
 
| elm
 
| section
 
|
 
|
 
| 1..1
 
| required
 
| Dieses Element enthält den Text.
 
 
 
|-
 
| 1
 
|bgcolor="ff8888"| act
 
| att
 
| @classCode
 
| "DOCSECT"
 
| ST
 
| 1..1
 
| required
 
|
 
 
 
|-
 
| 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.
 
 
 
|-
 
| 1
 
|bgcolor="ff8888"| act
 
| 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.
 
 
 
|-
 
|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.
 
 
 
 
 
|-
 
|3
 
|bgcolor="ff8888"| act
 
| att
 
| @extension
 
|
 
| ST
 
| 1..1
 
| required
 
|Dieses Attribut ist innerhalb des sendenden Systems ein eindeutiger Identifikator für die Operation.
 
 
 
 
 
|-
 
|3
 
|bgcolor="ff8888"| act
 
| elm
 
| code
 
| durchgeführte Operation
 
| CD CWE
 
| 0..1
 
| optional
 
|
 
 
 
|-
 
|3
 
|bgcolor="ff8888"| act
 
| elm
 
| text
 
| Freitext
 
| ED
 
| 0..1
 
| optional
 
|
 
 
 
|-
 
|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.
 
 
 
|-
 
|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.
 
 
 
|-
 
|3
 
|bgcolor="ffbbbb"| rel
 
| elm
 
| entryRelationship
 
| Intention
 
|
 
| 0..1
 
| optional
 
|Ziel der Operation.
 
 
 
|-
 
|4
 
|bgcolor="ff8888"| act
 
| elm
 
| Observation
 
| Intention
 
|
 
| 0..1
 
| optional
 
|Ziel der Operation.
 
 
 
|-
 
|5
 
|bgcolor="ff8888"| act
 
| 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
 
|bgcolor="ffbbbb"| rel
 
| elm
 
| entryRelationship
 
| Komplikation
 
|
 
| 0..1
 
| optional
 
|
 
 
 
|-
 
|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.
 
 
 
|-
 
|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.
 
 
 
 
 
 
 
|-
 
|3
 
|bgcolor="ffbbbb"| rel
 
| elm
 
| entryRelationship
 
| Bestandteil
 
|
 
| 0..1
 
| optional
 
|einzelne Prozedur
 
 
 
|-
 
|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.
 
 
 
|-
 
|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.
 
 
 
|-
 
|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.
 
 
 
 
 
 
 
|-
 
|4
 
|bgcolor="ffff88"| role
 
| 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
 
|bgcolor="88ff88"|ent
 
| elm
 
| Person
 
|
 
|
 
| 0..1
 
| optional
 
|Arzt
 
 
 
|-
 
|6
 
|bgcolor="88ff88"|ent
 
| elm
 
| name
 
|
 
| PN
 
| 0..1
 
| optional
 
|Name des Operateurs
 
 
 
|-
 
|3
 
|bgcolor="ccffff"| part
 
| elm
 
| participant
 
| Teilnehmer
 
|
 
| 0..1
 
| optional
 
|ausführender Arzt
 
 
 
|-
 
|4
 
|bgcolor="ffff88"| role
 
| elm
 
| ParticipantRole
 
|
 
|
 
| 0..1
 
| optional
 
|sonstiger Teilnehmer
 
 
 
|-
 
|5
 
|bgcolor="88ff88"|ent
 
| elm
 
| Person
 
|
 
|
 
| 0..1
 
| optional
 
|Teilnehmer
 
 
 
|}
 
 
 
 
 
{| class="hl7table"
 
!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<br>nullFlavour=OTH||Sonstige / andere Therapie||1), 2), 3)
 
|-
 
|2||ATH-HY||Hyperthermie||4)
 
|-
 
|}
 
Tabelle 23: Codesystem für Operationen
 
 
 
# GeKiD-Mindestdatensatz
 
# 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
 
|-
 
|A||Abgelehnt ||
 
|-
 
|V||vorgesehen ||
 
|-
 
|T||Terminiert||
 
|-
 
|B||Begonnen||
 
|-
 
|R||regulär beendet||
 
|-
 
|||vorzeitig beendet||
 
|-
 
|}
 
Tabelle 25: Codesystem für die Qualifier zu den Operationen
 
 
 
 
 
 
 
{| class="hl7table"
 
!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
 
 
 
# 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|
 
Diese Tabelle passt nicht zur Intention!
 
}}
 
 
 
 
 
Stellung der Therapie im Gesamtkonzept
 
 
 
{| class="hl7table"
 
!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
 
 
 
{{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
 
|
 
|
 
|
 
|
 
|
 
|
 
 
 
|}
 

Aktuelle Version vom 28. November 2013, 15:50 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 .

Statisches Modell

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


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 abgewichen 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:

Lvl Code Anlass Details
1 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 Therapie
2 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)
2 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
2 Systemische Therapie
  • Einleiten der systemischen Therapie
    • Beginn, Art, Protokoll, Intention, Stellung im Gesamtplan
  • Beenden der systemischen Therapie
    • Endedatum und -status, ggf. Dosierungen, Nebenwirkungen
1 Verlauf
  • Datum, Tumorstatus, Metastasierung
2 Life-Status (Meldeamt)
  • Datum "lebt" oder Sterbedatum
  • ggf. aktuelle Adresse bzw. Wegzugdatum


1 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)


graphische Übersicht

Abschnittsübersicht

Abbildung: Abschnittsübersicht (TODO: Diagramm muss aktualisiert werden!)

<Clinicaldocument>
  ...
  <component>
    <structuredBody>
      <!-- Erkrankungsdaten -->
      <component>
        <section>
          ...
        </section>
      </component>

      <!-- Meldebegründung -->
      <component>
        <section>
          ...
        </section>
      </component>

      ...
      <!-- weitere Abschnitte -->
      ...
    </structuredBody>
  </component>
</Clinicaldocument>


offene Punkte

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