Version vom 6. November 2012, 10:33 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 (Grundlagen)

Einleitung

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

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

Abbildung 11: vereinfachte Gesamtübersicht

Grundsätzliche Anforderungen an die Dokumentstruktur

Dokumente setzen sich grundsätzlich aus folgenden Komponenten zusammen:

dem eigentlichen Inhalt
der Kontextinformation

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

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

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

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

über ein „neutrale" Identifikationsmerkmal (automatisch vergebene, eindeutige ID)
ü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.

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:

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:

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

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

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

Tabelle 3: Vocabulary Domain für die Beteiligung

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

Handhabung von Negationen

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

??????????

Handhabung von Korrekturen und Folgemeldungen

????????

Statisches Modell (Details)

Dokumentenstruktur

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

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

Tabelle 4: Dokumentenstruktur (-bestandteile)

Meldeanlässe und Inhalte

Grundsätze:

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

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

Nachfolgend eine Liste der Meldeanlässe:

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

Dokumenttypen

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

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

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

Tabelle 6: Dokumententyp

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

Tabelle 4: Dokumenttypen mit Zuordnung der Sektionen

Bei der Therapie muss einer der folgende Abschnitte vorhanden sein:

Operation
Strahlentherapie
systemische Therapie

Dies muss dann über Schematron gesichert werden!

Korrekturmeldung

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:

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

Metadaten

Zuerst die Metadaten:

Abbildung 15a: Header des Dokuments

Lvl	RIM	AE	Name	Desc	DT	Kard	Conf	Beschreibung
1	act	elm	ClinicalDocument	Dokument		1..1	M
2	act	elm	realmCode	"DE"	ST	1..1	M	fix
2	act	elm	typeID		ST	1..1	M	fix
3	act	att	@root	2.16.840.1.113883.1.3	ST	1..1	M	fix
3	act	att	@extension	POCD_HD000040	ST	1..1	M	Diese Kennung ist fix und identifiziert dieses Dokument als CDA-Dokument.
2	act	elm	templateId	Strukturidentifikation des Dokuments	II	1..1	M	In diesem Element wird die Strukturbeschreibung des Dokumentes festgehalten.
3	act	att	@root	OID des Templates		1..1	M
2	act	elm	Id	Identifikation einer Instanz des Dokuments	II	1..1	M	Dieses Element identifiziert eindeutig eine Instanz eines Dokuments, d.h.jede Version eines Dokumentes hat eine neue ID. (vgl. SetId)
3	act	att	@root	OID		1..1	M	Hier muss die OID eingesetzt werden, die das sendende System benutzt, um die Dokumente eindeutig zu identifizieren.
3	act	att	@extension	eigentliche ID	ST	1..1	M
2	act	elm	code	Dokumenttyp	CE CWE	1..1	M	s.u.
3	act	att	@code	Dokumenttyp	"x-physician-cancer-reg"	1..1	M	s.u. und vgl. IHE PCC Vol.2 Abschnitt 6.3.1.A.2
3	act	att	@codeSystem	Dokumenttyp	"2.16.840.1.113883.6.1"	1..1	M	s.u.
2	act	elm	title	Titel des Dokuments	ST	0..1	M	Der Titel des Dokuments ergibt sich aus dem Dokumenttyp bzw. Dokumententemplate. Beispiel "Diagnosemeldung"
2	act	elm	effectiveTime	Erstellungszeitpunkt des Dokuments	TS	1..1	M
3	act	att	@value	eigentlicher Zeitpunkt	TS	1..1	M
2	act	elm	confidentialityCode	Vertaulichkeit des Dokumentes	CE CWE	1..1	M
3	act	att	@code	Code für die Vertaulichkeit	CE CWE	1..1	M	"N", s.u.
3	act	att	@codeSystem	Codesystem für die Vertaulichkeit		1..1	M	fix: "2.16.840.1.113883.5.25"
2	act	elm	languageCode	Sprache des Dokumentes	CS CNE	0..1	opt.
2	act	elm	setId	Setkennung	II	0..1		Dieses Element legt fest, zu welcher „Menge" das Dokument gehört. Es hält also die verschiedenen Versionen (Instanzen, vgl .Id) zusammen. Logische Kennung des Dokuments, die über die Versionen hinweg konstant bleibt. Eine Korrektur ergibt sich aus einer höheren Versionsnummer.
3	act	att	@root	OID		1..1	M	Hier muss die OID eingesetzt werden, die das sendende System benutzt, um das Dokument-Set eindeutig zu identifizieren.
3	act	att	@extension	eigentliche ID	ST	1..1	M
2	act	elm	versionNumber	Versionsnummer	INT	1..1	M	Eine fortlaufende Nummer zur Versionierung des Dokumentes.
3	act	att	@value	Versionsnummer	INT	1..1		Zusammen mit der Setkennung regelt dieses Element die Versionierung der Dokumente.
2	rel	elm	relatedDocument			0..1
3	act	elm	parentDocument	ParentDocument		1..1	required
4	act	elm	id	ID des Document		1..1	required

Code	Beschreibung	Codesystem
34806-0	Oncology Note	LOINC	2.16.840.1.113883.6.1"
x-physician-cancer-rep	Report to Cancer Registries	LOINC	2.16.840.1.113883.6.1"

Tabelle: Dokumenttyp (OID: 2.16.840.1.113883.6.1")

Code	Beschreibung
N	normal

Tabelle: Vertraulichkeit (OID: 2.16.840.1.113883.5.25)

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

	...

	<recordTarget>
	...
	</recordTarget>
	...


</ClinicalDocument>

Participants: Einleitung

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

Variante 1

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

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

Variante 2

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

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

Participant: Patient (recordTarget)

Abbildung 15: Identifikation des Patienten

Lvl

RIM

AE

Name

Desc

DT

Kard

Conf

Beschreibung

0

act

elm

ClinicalDocument

Dokument

1..1

M

1

part

elm

recordTarget

Patient

1..1

M

Patient

2

part

att

typeCode

"RCT"

CS CNE

1..1

M

fix

2

role

elm

patientRole

1..1

M

3

role

att

classCode

"PAT"

CS CNE

1..1

M

fix

3

role

elm

id

Patient-ID: nicht verwendet

SET<II>

1..*

M

4

role

att

@root

OID

1..1

M

Das ist die OID des sendenden Systems für Patienten.

4

role

att

@extension

die eigentliche ID

ST

1..1

M

3

role

elm

addr

Adresse

SET<AD>

0..*

Es sollte immer eine Adresse übertragen werden. Bei anonymisierten bzw. pseudonymisierten Patienten kann dies auf eine Postleitzahl oder Bundesland reduziert werden.

4

role

att

@streetname

Strasse

0..1

M

4

role

att

@houseNumber

Hausnummer

0..1

4

role

att

@postalCode

Postleitzahl

0..1

M

PLZ ohne Länderkennzeichen

4

role

att

@city

Wohnort

0..1

M

4

role

att

@country

Land

0..1

M

3

role

elm

telecom

Kontaktinformationen

SET<TEL>

0..*

M

4

ent

elm

patient

Patient

0..1

optional

5

ent

elm

name

Name des

SET<PN>

0..*

optional

Folgende Pseudonyme werden vorgesehen:

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

Anonymisierung bzw. Pseudonymisierung der ID, des Namens, Adresse etc.
Es ist zu klären, welche Informationen neben den klassischen wie „Name", „Geburtsdatum" und „Adresse" pseudonymisiert werden müssen.

6

ent

elm

prefix

Anrede

ST

0..1

optional

Anrede: Herr, Frau, ..

6

ent

elm

prefix

Titel

ST

0..1

optional

akademischer Titel

7

ent

att

@qualifier

"AC"

ST

0..1

optional

Qualifier für akademischen Titel

6

ent

elm

given

Vorname

ST

0..*

optional

Vornamen

6

ent

elm

familiy

Familienname

ST

0..*

optional

Familienname

6

ent

elm

familiy

Geburtsname

ST

0..*

optional

7

ent

att

@qualifier

"BR"

ST

0..1

optional

Qualifier für Geburtsname

5

ent

elm

administrativeGenderCode

Geschlecht

CE CWE

0..1

optional

Mit diesem Attribut wird das Geschlecht des Patienten übertragen.

6

ent

att

@code

Code für das Geschlecht

0..1

optional

6

ent

att

@codeSystem

Codesystem für das Geschlecht

0..1

optional

"2.16.840.1.113883.5.1"

5

ent

elm

birthTime

Geburtsdatum

TS

0..1

optional

6

ent

att

@value

Zeitpunkt

TS

0..1

tagesgenau

4

ent

elm

providerOrganisation

Krankenhaus

0..1

derzeit nicht notwendig

<!--- Patienten-Daten -->
<recordTarget>
  <patientRole>
    <id extension="65" root="2.16.840.1.113883.3.933"/>
    <addr>
      <streetName>Riedemannweg</streetName>
      <houseNumber></houseNumber>
      <postalCode>13627</postalCode>
      <city>Berlin</city>
    </addr>
    <patient>
      <name>
        <given>Paul</given>
        <family>Pappel</family>
      </name>
      <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>
      <birthTime value="19551217"/>
    </patient>
    <providerOrganization>
      <telecom use="WP" value="tel:(02421)27070"/>
      <telecom use="WP" value="fax:(02421)2707120"/>
      <addr>
        <streetName>Kölner Landstr.</streetName>
        <houseNumber>240</houseNumber>
        <postalCode>52351</postalCode>
        <city>Düren</city>
      </addr>
    </providerOrganization>
  </patientRole>
</recordTarget>

Participant: Melder (author)

Abbildung 16: Melder

Lvl	RIM	AE	Name	Desc	DT	Kard	Conf	Beschreibung
0	act	elm	ClinicalDocument
1	part	elm	author	Autor		1..1	M	Melder
2	part	att	@typeCode	"AUT"	CD CNE	1..1	M
2	part	elm	time	Zeitpunkt der Erstellung des Dokuments	TS	1..1	M
3	part	att	@value	Zeitpunkt der Erstellung des Dokuments	TS	1..1	M
2	role	elm	assignedAuthor	Melder		1..1	M	Informationen über den Melder
3	role	att	@classCode	"ASSIGNED"		1..1	M
3	role	elm	id	Melder-ID der Person/System	SET<II>	1..1	M	Grundsätzlich kann über eine Wiederholung auch mehrere IDs untergebracht werden, deren Semantik sich dann aus der zugeordneten OID ergibt. Die ID kommt hier hin, wenn es sich beim Melder um ein System oder eine Person handelt.
4	role	att	@extension	eigentliche Identifikationsnummer	ST	1..1	M	An dieser Stelle wird die ID des Melders untergebracht.
4	role	att	@root	OID zur ID	ST	1..1	M	Hier kommt die dazugehörige OID hin.
3	ent	elm	assigendPerson			0..1		Wenn es sich bei dem Melder um eine Person handelt, so ist diese hier anzugeben.
4	ent	elm	name	Name des Melders	SET<PN>	0..*
3	ent	elm	AuthoringDevice			0..1
3	ent	elm	representedOrganisation			0..1		meldende Einrichtung, falls es sich bei dem Melder um eine Organisation handelt oder Informationen über das Krankenhaus übermittelt werden sollen.
4	ent	elm	id	Melder-ID der Einrichtung	SET<II>	0..1	M	Hier kommt die ID der Organisation hin, wenn der Melder eine Organisation ist,
5	ent	att	@extension	eigentliche Identifikationsnummer	ST	1..1	M	Melder im Sinne des KRBW ist die durchführende Einrichtung, d.h. doch der (originale) Provider der Daten. Es handelt um eine Organisation(seinheit); eigentlich um die Kombination Organisation und Instanz des Dokumentssystems.
5	ent	att	@root	OID zur ID	ST	1..1	M	Hier kommt die dazugehörige OID desjenigen hin, der die ID vergeben hat.
4	ent	elm	name	Name der Org./Einrichtung	SET<ON>	0..1
4	ent	elm	telecom	Kontaktinformation der Org./Einrichtung	SET<TEL>	0..1
4	ent	elm	addr	Adresse der Org./Einrichtung	SET<AD>	0..1

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

Participant: med. Dokumentar (dataEnterer)

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

Lvl	RIM	AE	Name	Desc	DT
1	act	elm
2	rel	elm
1	part	elm	Participant	Versicherung	0..*
2	role	elm
4	ent	elm

???

Participant: Arzt (informant)

Diese Participation gibt an, von wem die gemeldete Information stammt. Normalerweise wird die Information aus einem oder mehreren Arztbriefen entnommen. Hierüber kann dann angegeben werden, wer diese Arztbriefe verfasst hat. Daher ist dieser Abschnitt optional und kann sogar mehrfach vorkommen.

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.

Abbildung 17: Identifikation des Absender

Lvl	RIM	AE	Name	Desc	DT	Kard	Conf	Beschreibung
0	act	elm	ClinicalDocument
1	part	elm	custodian	Absender		1..1	M	Wer hat das Dokument abgeschickt.
2	part	att	typeCode	"CST"	CD CNE	1..1	M
2	role	elm	assignedCustodian			1..1	M
3	role	att	classCode	"ASSIGNED"		1..1	M
4	ent	elm	representedCustodianOrganisation	verwaltende/absendede Organisation		0..1
5	ent	elm	id	Identifikation der Organisation	SET<II>	1..*	M
6	ent	att	@extension	eigentliche ID der Organisation	ST	1..1	M
6	ent	att	@root	OID der Organisation	ST	1..1	M
5	ent	elm	name	Name der Organisation	ON	0..1
5	ent	elm	telecom	Kontaktinformation der Organisation	TEL	0..1
5	ent	elm	addr	Adresse der Organisation	AD	0..1

<custodian>
	<assignedCustodian>
		<representedCustodianOrganization>
			<id root="2.16.840.1.113883.19.5"/>
			<name>Good Health Clinic</name>
		</representedCustodianOrganization>
	</assignedCustodian>
</custodian>

Participant: Empfänger (informationRecipient)

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

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

Abbildung 17: Identifikation des Empfängers

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

Participant: Versicherung (participant)

Lvl	RIM	AE	Name	Desc	DT
1	act	elm
2	rel	elm
1	part	elm	Participant	Versicherung	0..*
2	role	elm
4	ent	elm

???

Allgemeiner Aufbau des Body

An dieser Stelle sei auf den VHitG-Arztbrief verwiesen.

Abschnitt entspricht Component, Klasse entspricht Section.

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

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

graphische Übersicht

Abbildung 18: Abschnittsübersicht

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

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

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

Abschnitte

Nachfolgend werden die einzelnen Abschnitte im Detail erläutert.

Nationalität

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

Value Set: 1.3.6.1.4.1.12559.11.10.1.3.1.42.4

Value Set Name: VS11_epSOSCountry

Code System: ISO-3166-1

Modelliert man das über eine Sektion "Nationalität" oder als Teil einer allgemeineren Sektion "zusätzliche Patientendaten".
TODO!!!

Sterbedatum

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

Das Sterbedatum ist dann eine konkrete Beobachtung darin.

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

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

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

Meldebegründungsdaten

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

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

Abbildung 19: Observation für die Meldebegründung

Lvl	RIM	AE	Name	Desc	DT	Kard	Conf	Beschreibung
1	act	elm	section			1..1	required
2	act	att	@classCode	"DOCSECT"	CD CNE	1..1	required
2	act	att	@moodCode	"EVN"	CD CNE	1..1	required
2	act	elm	templateID	OID für Meldebegründungsabschnitt	ST	1..1	required
3	act	att	@root	"1.2.276.0.76.3.1.131.1.10.2.1"	ST	1..1	required
2	act	elm	code	Code für Meldebegründungsabschnitt	CD CNE	1..1	required
2	act	elm	title	Titel des Abschnitts	ST	1..1	required	fix "Meldebegründung"
2	act	elm	text	Text für die Meldebegründung	ST	1..1	required
2	rel	elm	entry			1..1	required
3	act	elm	observation			1..1	required
4	act	att	@classCode	"OBS"	CD CNE	1..1	required	fix
4	act	att	@moodCode	"EVN"	CD CNE	1..1	required	fix
4	act	elm	code	Es handelt sich um eine Meldebegründung	CD CNE	1..1	required
4	act	elm	value	Meldebegründung	CD CNE	1..1	required	Wie wird die Meldebegründung tatsächlich begründet. Hier ist ein Code aus 1.2.276.0.76.3.1.131.1.5.1 zu verwenden.
4	act	elm	effectiveTime	Zeitpunkt der Meldebegründung	TS	1..1	required	Das Datum, an dem der Patient unterrichtet wurde oder er unterschrieben hat.
4	part	elm				0..1	optional
5	part	att	@typeCode	"AUTH"	CD CNE	0..1	optional	fix
5	role	elm	author			1..1	required	Diese Section sollte ein Autor Element enthalten, wenn der Autor dieser Section von dem in höheren Ebenen des Dokuments verschieden ist.
6	ent	elm	Person		Arzt	0..1	optional	Wer hat die Meldebegründung unterschrieben.
7	ent	elm		Name	0..1	optional	Name des Meldenden

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

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

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

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:

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

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

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

Qualifier – Zustimmung für KKR

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

Code	Bedeutung	Erläuterung
EKR
KKR
QS

Tabelle 11: Vocabulary Domain für die Zustimmung wohin

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

Beispiel

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

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

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

    </value>
</observation>

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

   <entry>

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

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

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

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

   </entry>
</section>

Schematron

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

Diagnosen

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

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

Abbildung 20: Section ->Diagnose

An dieser Stelle sei darauf verwiesen, dass hier das Komponentenmodell für die Tumordiagnosen aus dem Diagnoseleitfaden eingesetzt wird.

Lvl	RIM	AE
1	act	elm
2	rel	elm
1	part	elm
2	role	elm
4	ent	elm

TODO Abgleich Klassifikationsliste KRBW (Altmann)

Anlaß der Diagnosestellung

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

Art der Diagnosesicherung

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

Abbildung 21: Diagnostik

=> Abschnitt Verlaufsbeurteilung

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

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

=> Phänomendaten

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

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

=> Abschnitt Verlaufsbeurteilung

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

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

=> Abschnitt Verlaufsbeurteilung

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

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

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

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

Anlass der Diagnosestellung

als Qualifier ????

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

Tabelle 17: Vocabulary Domain für Diagnoseanlass

Diagnosesicherung

Wie ist die Diagnose gesichert worden?

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

Tabelle 18: Vocabulary Domain für Diagnosesicherung

Tabellen für TNM aus dem Diagnoseleitfaden

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

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

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

=> Phänomen und Erkrankungsdaten, Spezifikation Diagnoseleitfaden

Referenzen

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

Todesursache

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

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

Abbildung 22: Diagnostik

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

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

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

Erkrankungsdaten

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

Abbildung ??: Erkrankungsdaten

Lvl	RIM	AE
1	act	elm
2	rel	elm
1	part	elm
2	role	elm
4	ent	elm

????????

{{{1}}}

ID
Adresse Erkrankungszeitpunkt

Diagnosetext
Diagnosedatum
Code+System
Diagnosecode
Diagnosesicherheit
Diagnoseanlass

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

Phänomendaten

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

Abbildung ??: Phänomendaten

Lvl	RIM	AE
1	act	elm
2	rel	elm
1	part	elm
2	role	elm
4	ent	elm

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

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

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

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

Qualifier für Revisionsbedürftigkeit

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

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

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

Operation (operative Therapie)

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

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

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

Abbildung 23: Operation

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

Lvl	RIM	AE	Name	Desc	DT	Kard	Conf	Beschreibung
0	act	elm	section			1..1	required	Dieses Element enthält den Text.
1	act	att	@classCode	"DOCSECT"	ST	1..1	required
1	act	att	@moodCode	"EVN"	ST	1..1	required
1	act	elm	code	Code	ST	1..1	required	Dieser Code definiert den Inhalt des Abschnittes.
1	act	elm	title	title	ST	1..1	required	Dieses Element gibt die Überschrift des Abschnittes an.
1	act	elm	text	text	ST	1..1	required	Dieses Element enthält den Text. Hier werden alle strukturiert enthaltenen Daten der Section als Freitext übermittelt. Für Operationen ist zusätzlich die Übermittlung zusätzlicher unstrukturierter Informationen zulässig.
1	act	elm	procedure			1..1	required	Dieses Element repräsentiert die gesamte (einzelne) Operation.
2	act	att	procedure@classCode	classCode <= PROC		1..1
2	act	att	@moodCode	<= x_DocumentProcedureMood		1..1
2	act	elm	id	Identifikation der Operation	SET<II>	1..*	required	Über dieses Element wird die Operation eindeutig identifiziert. Somit ist dieses Element required. Die Kombination der Attribute root und extension identifiziert die Operation systemübergreifend eindeutig.
3	act	att	@root	Root-OID	ST	1..1	required	Dieses Attribut ist ein eindeutiger Identifikator für Operationen innerhalb eines bestimmten sendenden Systems.
3	act	att	@extension		ST	1..1	required	Dieses Attribut ist innerhalb des sendenden Systems ein eindeutiger Identifikator für die Operation.
3	act	elm	code	durchgeführte Operation	CD CWE	0..1	optional
3	act	elm	text	Freitext	ED	0..1	optional
3	act	elm	statusCode	<= completed	ST	1..1	required	Über dieses Attribut wird der Status angegeben, in dem der beschriebene Act sich befindet. Ein Act kann z.B. den Status „new", „active" oder „cancelled" besitzen. Die Beobachtung einer Operation wird mit der Dokumentation als abgeschlossene Handlung betrachtet. Somit wird für das Attribut statusCode der feste Wert „completed" vorgegeben.
3	act	elm	effectiveTime	Durchführungszeitraum	IVL<TS>	0..1	optional	Dieses Element gibt den Durchführungszeitraum der Therapie an. Benötigt wird Tagesgenauigkeit, bei einer Operation werden daher nicht Beginn und Ende angegeben, sondern das Datum im value-Attribut übermittelt.
3	rel	elm	entryRelationship	Intention		0..1	optional	Ziel der Operation.
4	act	elm	Observation	Intention		0..1	optional	Ziel der Operation.
5	act	elm	code	Ziel der Intention	CD CWE	0..1		Diese Klasse im Intent Mood drückt das Ziel aus.
5	act	att	value	Ziel der Intention	CD CWE	0..1
3	rel	elm	entryRelationship	Komplikation		0..1	optional
4	act	elm	Observation	Komplikation		0..1	optional	Oft reicht in Bezug auf Komplikationen die einfache Information aus, ob diese aufgetreten sind. Dies wird als observation innerhalb einer entryRelationship übermittelt.
5	act	elm	code	Komplikation		0..1	optional	Der code für diese Observation ist fix. Es wird der entsprechende SNOMED-CT-Code verwendet.
5	act	elm	value			0..1	optional	Die Information, ob Komplikationen aufgetreten sind, wird als boolscher Wert übermittelt. Ist diese Information nicht bekannt, kann dies als nullFlavor="UNK" übermittelt werden.
3	rel	elm	entryRelationship	Bestandteil		0..1	optional	einzelne Prozedur
4	act	elm	Procedure	Einzelprozeduren		0..1	optional	Eine Operation besteht häufig aus mehreren Einzelprozeduren. Jede Einzelprozedur wird als procedure in einer entryRelationship übermittelt. Beliebig viele entryRelationships sind zulässig.
5	act	elm	code			0..1	optional	Im code-Element werden die durchführten Einzelprozeduren übermittelt. Im Rahmen dieses Leitfadens wird der Operationen- und Prozedurenschlüssel (OPS) verwendet. Zulässig sind alle Fassungen von OPS.
3	part	elm	performer	performer		0..1	optional	Hier werden die Angaben zu Operateur(en) übermittelt. Die Übermittlung mehrerer Operateure ist zulässig.
4	role	elm	AssignedEntity			0..1	optional	ausführender Arzt
5	role	elm	AssignedEntity.role			0..1	optional	Über dieses Element wird der Operateur eindeutig identifiziert. Somit ist dieses Element required. Die Kombination der Attribute root und extension identifiziert den Operateur systemübergreifend eindeutig.
5	ent	elm	Person			0..1	optional	Arzt
6	ent	elm	name		PN	0..1	optional	Name des Operateurs
3	part	elm	participant	Teilnehmer		0..1	optional	ausführender Arzt
4	role	elm	ParticipantRole			0..1	optional	sonstiger Teilnehmer
5	ent	elm	Person			0..1	optional	Teilnehmer

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

Tabelle 23: Codesystem für Operationen

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

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

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

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

Tabelle 26: Codesystem für Operation statusCode

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

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

Tabelle 27: Codesystem für Operation code

Diese Tabelle passt nicht zur Intention!

Stellung der Therapie im Gesamtkonzept

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

Tabelle 28: Codesysstem für Operation code

Diese Tabelle passt nicht dazu!

Bestrahlung

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

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.

Abbildung 24: Bestrahlung

Lvl	RIM	AE
1	act	elm
2	rel	elm
1	part	elm
2	role	elm
4	ent	elm

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

Medikamentendaten

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

Abbildung 26: Medikation (gemäß IHE PCC)

Substance Administration Hinweis auf VHitG Addendum Medikation sowie epSOS!!!

Lvl	RIM	AE
1	act	elm
2	rel	elm
1	part	elm
2	role	elm
4	ent	elm

Aus dem VHitG-Arztbrief:

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

Aus IHE PCC TF 2:6.1.4.16.2

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

systemisch(e Therapie)

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

systemisch - Procedure

Lvl	RIM	AE
1	act	elm
2	rel	elm
1	part	elm
2	role	elm
4	ent	elm

Status (Nachsorge und andere Follow-Up)

Template ID	<OID für das Template>
General Description	In diesem Abschnitt wird der Status zur Nachsorge und andere Follow-Ups übermittelt.
LOINC Code	Opt.	Description
????	O

???

Lvl	RIM	AE
1	act	elm
2	rel	elm
1	part	elm
2	role	elm
4	ent	elm

Studiendaten

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

Observation

Lvl	RIM	AE
1	act	elm
2	rel	elm
1	part	elm
2	role	elm
4	ent	elm

Abschlussdaten

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

Observation

Lvl	RIM	AE
1	act	elm
2	rel	elm
1	part	elm
2	role	elm
4	ent	elm

Planung

Abbildung ??: Planungsdaten

??????

Lvl	RIM	AE
1	act	elm
2	rel	elm
1	part	elm
2	role	elm
4	ent	elm

Ann Arbor (Score)

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

Abbildung ??: Ann Arbor Score

??????

offizielles Score-Modell verwenden

Lvl	RIM	AE
1	act	elm
2	rel	elm
1	part	elm
2	role	elm
4	ent	elm

@@ Zeile 422: / Zeile 422: @@
 Tabelle 4: Dokumenttypen mit Zuordnung der Sektionen
-{{FAQBox|
-Was ist hiermit
-*Life-Status
-*Sterbemeldung
-}}
-{{FAQBox|
+{{AlertBox|
 Bei der Therapie muss einer der folgende Abschnitte vorhanden sein:
 *Operation
 *Strahlentherapie
 *systemische Therapie
+Dies muss dann über Schematron gesichert werden!
 }}

Statisches Modell

Version vom 6. November 2012, 10:33 Uhr

Inhaltsverzeichnis

Statisches Modell (Grundlagen)

Einleitung

Grundsätzliche Anforderungen an die Dokumentstruktur

Beispiel für groben Aufbau

Identifikation von Informationseinheiten

Mechanismen

Zeitstempel der Information

Referenzen auf andere Informationseinheiten

Referenzen auf Beteiligte

Handhabung von Negationen

Handhabung von Korrekturen und Folgemeldungen

Statisches Modell (Details)

Dokumentenstruktur

Meldeanlässe und Inhalte

Dokumenttypen

Korrekturmeldung

Header

Metadaten

Participants: Einleitung

Variante 1

Variante 2

Participant: Patient (recordTarget)

Participant: Melder (author)

Participant: med. Dokumentar (dataEnterer)

Participant: Arzt (informant)

Participant: Absender (custodian)

Participant: Empfänger (informationRecipient)

Participant: Versicherung (participant)

Allgemeiner Aufbau des Body

graphische Übersicht

Abschnitte

Nationalität

Sterbedatum

Meldebegründungsdaten

Qualifier – Zustimmung für KKR

Beispiel

Schematron

Diagnosen

Anlass der Diagnosestellung

Diagnosesicherung

Tabellen für TNM aus dem Diagnoseleitfaden

Referenzen

Todesursache

Erkrankungsdaten

Phänomendaten

Phänomen Primärtumor

Phänomen Fernmetastase

Phänomen Komplikation: das Attribut - code

Operation (operative Therapie)

Bestrahlung

Medikamentendaten

systemisch(e Therapie)

Status (Nachsorge und andere Follow-Up)

Studiendaten

Abschlussdaten

Planung

Ann Arbor (Score)

Navigationsmenü

Suche