Statisches Modell
Foemig (Diskussion | Beiträge) K (Layout) |
Foemig (Diskussion | Beiträge) K (Layout) |
||
Zeile 2.437: | Zeile 2.437: | ||
Abbildung 23: Operation | Abbildung 23: Operation | ||
− | + | <syntaxhighlight lang="xml"> | |
<component> | <component> | ||
<section> | <section> | ||
Zeile 2.462: | Zeile 2.462: | ||
</section> | </section> | ||
</component> | </component> | ||
− | + | </syntaxhighlight> | |
Version vom 30. März 2012, 17:07 Uhr
Dieses Material ist Teil des Leitfadens Übermittlung onkologischer Daten.
|
HL7-Benutzergruppe in Deutschland e. V. |
Übermittlung von onkologischen Daten mittels
HL7 Clinical Document Architecture Rel. 2
für das deutsche Gesundheitswesen
Implementierungsleitfaden
Version | 09 |
Status: | in Arbeit |
Stand: | 29. Juli 2011 |
Realm: | Deutschland |
Dokumenten-OID: | n.a. |
Copyright © 2011: HL7 Benutzergruppe in Deutschland e.V.
HL7-Benutzergruppe in Deutschland e.V. Geschäftsstelle Köln An der Schanz 1 50735 Köln
Implementierungsleitfaden Übermittlung von onkologischen Daten an Krebs¬register mittels HL7 CDA R2 vorgelegt von:
Deutsche Krebsgesellschaft Berlin | |
Logo Uni Giessen | GTDS Uniklinik / GTDS Gießen |
Agfa HealthCare GmbH Bonn | |
GKD Gesellschaft für klinische Dienstleistungen Düsseldorf mbH Düsseldorf | |
ix.mid Köln | |
megaPharm | |
Zytoservice Deutschland GmbH Hennef | |
Alcedis GmbH Gießen |
und der Projektgruppe „onkologische Datenübermittlung" der Deutschen Krebsgesellschaft
zur Abstimmung durch:
Mitglieder der HL7-Benutzergruppe e.V.
Ansprechpartner:
Dr. Frank Oemig, Agfa HealthCare GmbH (Bonn)
Dokumentinformation
Inhaltsverzeichnis
- 1 Dokumentenhistorie
- 2 Editor
- 3 Autoren
- 4 Mit Beiträgen von
- 5 Nachnutzungs- bzw. Veröffentlichungsansprüche
- 6 Disclaimer
- 7 Einleitung
- 8 Szenarien
- 9 Domänen-Analyse Modell
- 10 Dynamisches Modell
- 11 Statisches Modell (Grundlagen)
- 12 Statisches Modell (Details)
- 12.1 Dokumentenstruktur
- 12.2 Meldeanlässe und Inhalte
- 12.3 Dokumenttypen
- 12.4 Header
- 12.4.1 Type ID
- 12.4.2 TemplateID
- 12.4.3 Identifikation des Dokuments
- 12.4.4 Typisierung des Dokuments
- 12.4.5 Titel
- 12.4.6 Setkennung
- 12.4.7 Versionsnummer
- 12.4.8 Participant: Patient (recordTarget)
- 12.4.9 Participant: Melder (author)
- 12.4.10 Participant: Unterzeichner (legalAuthenticator)
- 12.4.11 Participant: Absender (custodian)
- 12.4.12 Participant: Empfänger (informationRecipient)
- 12.4.13 Participant: Unterzeichner (legalAuthenticator)
- 12.4.14 Participant: Versicherung (participant)
- 12.5 69. Allgemeiner Aufbau des Body
- 12.6 Abschnitte
- 12.6.1 Nationalität
- 12.6.2 Meldebegründungsdaten
- 12.6.3 Diagnosen
- 12.6.4 Diagnosen (Todesursache)
- 12.6.5 Erkrankungsdaten
- 12.6.6 Phänomendaten
- 12.6.7 Operation
- 12.6.7.1 Das Attribut - classCode
- 12.6.7.2 Das Attribut - moodCode
- 12.6.7.3 Das Attribut - id
- 12.6.7.4 Das Attribut - code
- 12.6.7.5 Das Attribut - text
- 12.6.7.6 Das Attribut- statusCode
- 12.6.7.7 Das Attribut - effectiveTime
- 12.6.7.8 Das Klasse Observation (Operation)
- 12.6.7.9 Das Attribut - code
- 12.6.7.10 Das Attribut - code
- 12.6.8 Bestrahlung
- 12.6.9 Medikamentendaten
- 12.6.10 systemisch (e Therapie)
- 12.6.11 Status (Nachsorge und andere Follow-Up)
- 12.6.12 Studiendaten
- 12.6.13 Abschlussdaten
- 12.6.14 Planung
- 13 Anhang A: Diverses
- 14 Anhang B: Verzeichnisse
Dokumentenhistorie
Version | Stand | Bearbeiter | Beschreibung | Dok.-OID |
01 | 22.10.10 | FO | Draft | n.a. |
02 | 04.11.10 | FO | Erweiterung | n.a. |
03 | 05.11.10 | BS | Erweiterung | n.a. |
04 | 11.11.10 | FO | Einarbeitung erste Kommentare | n.a. |
05 | 12.11.10 | FO | weitere Überarbeitung | n.a. |
06 | 20.01.11 | FO | weitere Überarbeitung | n.a. |
07 | 27.01.11 | FO | weitere Überarbeitung | n.a. |
08 | 21.03.11 | FO | weitere Überarbeitung | n.a. |
09 | 09.07.11 | FO | Umstrukturierung, OIDs, Layout | n.a. |
10 | 18.03.12 | FO | Wiki | n.a. |
Editor
Dr. Frank Oemig, Agfa HealthCare GmbH (Bonn)
Autoren
- Dr. Frank Oemig, Agfa HealthCare GmbH, Bonn (FO)
- Esther Amenda, ix.mid, Köln (EA)
Mit Beiträgen von
- Dr. Udo Altmann, GTDS und Forum Klinischer Krebsregister, Gießen (UA)
- Esther Amenda, ix.mid, Köln (EA)
- Silke Fontein, megapharm (SF)
- Stefan Lang, Alcedis GmbH (SL)
- Matthias Schmitz, Agfa HealthCare, Bonn (MS)
- Dr. Bernd Schütze, Univ.-Kl., Düsseldorf (BS)
- Claas Thiele, Zytoservice Deutschland GmbH, Hennef (CT)
Folgende Organisationen beteiligen sich aktiv an der Diskussion und der Arbeitsgruppe:
- Deutsche Krebsgesellschaft e.V.
- Deutsche Onkologie Centrum Holding GmbH (DOC)
- Gesellschaft der epidemiologischen Krebsregister in Deutschland e.V. (GEKID)
- Gießener Tumordokumentationssystem (GTDS)
- Arbeitsgemeinschaft Deutscher Tumorzentren e.V. (ADT)
- Agfa Healthcare GmbH, Bonn
- GKD Gesellschaft für klinische Dienstleistungen Düsseldorf mbH
- ix.mid, Köln
- megapharm GmbH
- Zytoservice, Hennef
Autoren und Copyright-Hinweis, Nutzungs¬hinweise
Nachnutzungs- bzw. Veröffentlichungsansprüche
Das vorliegende Dokument wurde von der Projektgruppe „onkologische Datenübermittlung" in Kooperation mit der HL7-Benutzergruppe e.V. entwickelt. Die Nachnutzungs- bzw. Veröffentlichungs¬ansprüche sind nicht beschränkt.
Der Inhalt dieser Spezifikation ist öffentlich.
Zu beachten ist, dass Teile dieses Dokuments auf dem HL7-Standard CDA beruhen, für die © Health Level Seven, International gilt. Näheres unter [1] und [2].
Die Erweiterung oder Ablehnung der Spezifikation, ganz oder in Teilen, ist dem Vorstand der Benutzergruppe und den Editoren/Autoren schriftlich anzuzeigen.
Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifkationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
Disclaimer
Obwohl diese Publikation mit größter Sorgfalt erstellt wurde, kann weder die HL7-Benutzergruppe in Deutschland e.V. noch die an der Erstellung beteiligten Firmen keinerlei Haftung für direkten oder indirekten Schaden übernehmen, die durch den Inhalt dieser Spezifikation entstehen könnten.
Des Weiteren werden nach Abschluss des Abstimmungsverfahrens den diversen Tabellen noch ihre endgültige OID zugewiesen.
Inhaltsverzeichnis
Einleitung
Hintergrundinformationen
Im Sommer 2008 traf sich eine kleine Arbeitsgruppe (DOC, ADT, Agfa, Siemens, megapharm, alcedis) bei der DOC Holding in Düsseldorf, um die Optimierung der Datenübertragung in der onkologischen Versorgung zu besprechen. Hintergrund ist die in jedem Bundesland unterschiedliche Spezifikation der epidemiologischen Krebs¬register sowie die verschiedenen Anforderungen der Daten¬übermittlung an klinische Krebsregister und Dienstleister aus der Qualitätssicherung, die zu Problemen und hohen Aufwendungen bei der Implementierung führen. Eine weitere Fragestellung ist die Vereinfachung der Datenübermittlung in der onkologischen Forschung.
Projekthistorie
Die Historie dieses Projektes ist im Anhang aufgeführt.
Scope
Ziel soll es sein, eine modellbasierte Grundlage zu schaffen, um die Daten¬übertragung innerhalb der Onkologie auf einen Standard abzubilden. Daten werden auf verschiedenen Ebenen gesammelt und kommuniziert. Die klinische Betreuung erfolgt noch weitestgehend gestützt auf Papier- oder unstrukturierten elektronischen Dokumenten. In strukturierter Form werden Daten jedoch in der Qualitätssicherung, den klinischen und epidemiologischen Krebsregistern sowie den Organzentren benötigt. Es existiert eine Reihe von Spezifikationen – teilweise bedingt durch gesetzliche Vorgaben auf Landes- und Bundesebene , die einen unterschiedlichen organisatorischen Kontext besitzen und bei ähnlichen Inhalten nicht unbedingt deckungsgleich sind. Praktisch führt dies zu Mehrfachdokumentation und / oder aufwendigen technischen Systemen.
Abbildung 1: gegenwärtige Situation
Die vorhergehende Abbildung verdeutlicht die gegenwärtige Situation. Demnach gilt es folgende Spezifikationen abzubilden/abzulösen:
- Gemeinsamer onkologischer Basisdatensatz (ADT, GeKiD, DKG, KoQK, CCC Forum) auf Basis von XML
- Schnittstellen KKR / EKR (GeKiD)
- ONkeyLINE
- Datensatz Onkologie
- Spezielle Programme: BQS, DMP Mamma, QS / Benchmarking, ..
Als Grundproblem dieser Spezifikationen kann festgehalten werden, dass Prozesse und Rahmenbedingungen nicht ausreichend beachtet bzw. definiert worden sind: Anlass und Frequenz für Informationsfluss (Meldung), sinnvolle Teilmengen/Optionalitäten, lokale Besonderheiten (z.B. Landesgesetze), Verschlüsselung, technischer Transport, Verar¬beitungs¬status, Rückmeldung.
Als Idealfall ist anzustreben, dass jeder an der Behandlung beteiligte seinen inhaltlichen Anteil am Standard einmalig dokumentiert und dabei allenfalls Zusatzinformationen hinterlegt (wie die Zuordnung zu einer bestimmten Erkrankung oder therapeutischen Situation), die es erlauben, diese Informationen in übergeordnetem Kontext (Register, QS, nachbetreuende Behandler) korrekt einzuordnen.
Dieser Leitfaden zielt darauf ab, geeignete Dokumentenstrukturen für die einzelnen Meldungen auf Basis von Komponenten (Content Modules) zu spezifizieren, die die genannten Anforderungen abbilden können.
Basisdokumente
Dieses Dokument versucht die in den nachfolgenden Dokumenten aufgeführten Anforderungen umzusetzen:
- VHitG-Arztbrief (OID ???????)
- Header-Information
- Darstellung von Ärzten, Adressen, Namen, ..
- Grundlagen von Diagnosen und Prozeduren
- Diagnoseleitfaden (OID ??????)
- verfeinerte Diagnose-Information, ICD-O, TNM
- Liste der bisherigen Spezifikationen:
- XML-/CSV-Datensatz des Kooperationsverbundes Qualitätssicherung durch Klinische Krebsregister (KoQK) bzw. der Arbeitsgemeinschaft Deutscher Tumorzentren e.V. (ADT)
- XML-/CSV-Datensatz der Gesellschaft der epidemiologischen Krebsregister in Deutschland e.V. (GEKID)
- CSV-Datensatz des Instituts für angewandte Qualitätsförderung und Forschung im Gesundheitswesen GmbH (AQUA)
- XML-Datensätze der Deutsche Onkologie Centrum Holding GmbH
- Liste der noch nicht berücksichtigten Spezifikationen:
- CSV-Datensatz des GEKID-Datensatzes der Bundesgeschäftsstelle Qualitäts¬sicherung gGmbH (BQS)
- CSV-Datensatz der Gesellschaft für Pädiatrische Onkologie und Häma¬tologie (GPOH)
- BDT-Datensatz des Zentralinstituts für Kassenärztliche Versorgung (ZI)
- XML-Datensatz der Kassenärztlichen Bundesvereinigung (KBV)
- CDA2-Datensatz der Ärztekammer Westfalen-Lippe in Kooperation mit der Bundesgeschäftsstelle Qualitätssicherung gGmbH (BQS)
- XML-Datensatz der Arbeitsgruppe Tumordatenschnittstellen Niedersachsen
Aufbau
Nach dieser Einleitung werden die abzuhandelnden Szenarien beschrieben. Danach erfolgt eine Erläuterung des Analysemodells, das anhand der bisherigen Datensatzbeschreibungen und der dahinter liegenden medizinischen Informationen erarbeitet wurde. Daran schließen sich das dynamische Modell sowie das statische Modell mit der Definition der CDA-Strukturen (Header + Body) an. Im Anhang befinden sich Referenzen, eine offene Punkteliste, Verzeichnisse etc.
HL7 und Referenz-Modelle
Wie später noch weiter ausgeführt hat die Gruppe entschieden, die Umsetzung auf Basis von HL7 CDA zu realisieren. Daher sind die Basisspezifikationen des VHitG-Arztbriefes sowie des Diagnoseleitfadens relevant. Für hilfreiche Erläuterungen sei auf die entsprechenden Dokumente verwiesen.
Konzept und Begründung
Hier folgt das Konzept mit der dazu passenden Begründung des Leitfadens. Inhalt sollten der Zweck, die beteiligten Organisationen, ihre Rollen bei der Erstellung des Leitfadens und der Fokus des Dokuments sein.
Zweck
Dieser Leitfaden soll primär die Erst- und Folgemeldungen an die klin. und epid. Krebs¬register spezifizieren.
Fokus
Dieser Leitfaden konzentriert sich auf die Umsetzung des Analysemodells (s.u.) in HL7 V3 CDA R2.
Szenarien
Beispielfälle zum Ablauf von Diagnostik und Therapie
Kolorektales Karzinom
Die nachfolgende Tabelle analysiert die Abläufe am Beispiel eines kolorektalen Karzinoms:
Zeitachse | Aktion / Ergebnis / Ereignis (mögliche Spezialfälle) | Akteur | Entstehende Daten (kursiv Daten außerhalb Basisdaten) | Mögliche Empfänger (weitere siehe auch Anmerkungen am Tabellenende) | Abstraktes Ereignis
Nach dem Muster Grundereignis (– Subspezifikationen) |
---|---|---|---|---|---|
15.01.09 | Koloskopie im Rahmen von Früherkennung Feststellen eines malignitätsverdächtigen Polypen im Colon descendens, Entnahme einer Biopsie |
Niedergelassener Internist | Qualitätsmerkmal vollständige Koloskopie und Polypektomie | Prätherapeutische Diagnostik – klinische Diagnosesicherung | |
18.01.09 | Eintreffen des Patho¬befundes Adenokarzinom, Infiltration Muscularis propria, Besprechen mit Patienten und Einweisung ins Krankenhaus | Niedergelassener Internist / Pathologe | Diagnosedatum (Def. beachten!) Histologie Lokalisation Erfassungsanlaß |
KH / Darmzentrum Klin. Register Epid. Register |
Prätherapeutische Diagnostik – Pathologie |
25.01.09 | Aufnahme Röntgenthorax und CT-Abdomen ohne Hinweis auf Metastasen | Chirurgische Abteilung | Klinischer TNM | Darmzentrum Klin. Register Epid. Register |
Prätherapeutische Diagnostik – klinisches Staging |
26.01.09 | (prä op Konferenz, z.B. Lebermetastase) | Alle potentiell beteiligten Disziplinen / ambulant oder stationär | Entscheidung im Freitext bzw. Vorgesehene Therapien (Basisdatensatz hat kein Konferenzmodul) |
Darmzentrum (Klin. Register) (Beteiligte an Therapie) |
Therapieplanung - prätherapeutisch |
27.01.09 | Hemikolektomie | Chirurgische Abteilung | OPS (vor allem 5-... ) OP-Datum (Zusätze wie TME, …) |
Darmzentrum Klin. Register (Epid. Register) |
Operative Therapie – Tumorresektion - Primärtumor (kann mehrfach vorkommen bei Nachresektionen oder wegen unterschiedlicher OP-Bereiche wie Lymphknoten oder Metastasen) |
30.01.09 | Pathobefund: pT2pN1 G2 L0 V0 UICC III, Adenokarzinom, R0 (lokal radikal operiert) |
Chirurgische Abteilung / Pathologe | postoperativer TNM Tumorfreiheit |
Darmzentrum Klin. Register Epid. Register |
Pathologisches Staging |
31.01.09 | Tumorkonferenz Empfehlung: Adjuvante Radiochemotherapie |
Inter¬disziplinär (Chirurg, Onkologe klin. und niedergelassen, Strahlentherapeut, ggf. Gyn, Uro, …) |
(Vorgesehene Therapien) (ggf. Zuweisung eines Nachsorgeplans) |
Darmzentrum (Klin. Register) (((Epi.Register??))) (Beteiligte an Therapie und Nachsorge) |
Therapieplanung – postoperativ / im weiteren Sinne posttherapeutisch |
02.02.09 | Schmerzen, Darmanastomoseninsuffizienz, konservativ behandelt | Chirurgische Abteilung | Komplikation | Darmzentrum Klin. Register |
Unerwünschte Therapiefolge
- Komplikation, kurzfristige oder langfristige Nebenwirkung |
(Revisionsop) | Operative Therapie – nicht resezierend | ||||
01.03.09 | Beginn der Radiochemotherapie | Externe Strahlentherapie (ambulante Durchführung) | Beginn Strahlentherapie Art Zielgebiet Intention Beginn Chemo Protokoll |
Darmzentrum Klin. Register |
Einleitung einer längerdauernden Therapie – Strahlentherapie und Chemotherapie |
15.04.09 | Ende der Strahlentherapie | Externe Strahlentherapie (ambulante Durchführung), zubereitender Apotheker | Ende Strahlentherapie Ende Status Dosis Ende Chemo Ende Status Dosierung |
Darmzentrum Klin. Register |
Beendigung einer längerdauernden Therapie – Strahlentherapie und Chemotherapie |
15.05.09 | Strahlentherapienachsorge Leichte Hautrötung |
Externe Strahlentherapie | Nebenwirkung | (Darmzentrum) Klin. Register |
Therapiebezogene Nachsorge – ohne / mit gleichzeitiger Feststellung eines Therapieerfolges |
31.07.09 | Tumornachsorge: Beschwerdefreiheit, kein Anhalt für Rezidiv | Niedergelassener Arzt | Verlaufsdaten => Tumorfreiheit | Darmzentrum\* Klin. Register |
Follow-up - Tumornachsorge |
(Schmerzen, Verwachsungen) | Niedergelassener Arzt | (Verlaufsdaten => Folgeerkrankungen sind nicht mehr in aktuellem Basisdatensatz enthalten) | Darmzentrum\* Klin. Register |
Follow-up - Folgeerkrankung des Tumors oder der Tumortherapie möglicherweise Zielereignis bei bestimmten Fragestellungen | |
31.10.09 | Tumornachsorge, metastasenverdächtiger Rundherd in der Leber | Niedergelassener Arzt | Verlaufsdaten => Metastasenlok. | Darmzentrum\* Klin. Register |
Follow-up - Rezidiv / Progress |
7.11.09 | Resektion der Lebermetastase | Chirurgische Abteilung | OPS OP-Datum |
Darmzentrum Klin. Register |
Operative Therapie – Tumorresektion –Rezidiv |
10.11.09 | Pathobefund: Metastase eines Adenoca. Im Gesunden reseziert | Chirurgische Abteilung / Pathologe | Tumorfreiheit | Darmzentrum Klin. Register |
Follow-up - Therapieerfolg |
12.11.09 | Tumorkonferenz Empfehlung: Adjuvante Chemotherapie |
Interdisziplinär | (Vorgesehene Therapien) | Therapieplanung – postoperativ / im weiteren Sinne posttherapeutisch | |
01.12.09 | Einleitung Chemotherapie | Onkologische Abteilung, zubereitender, Apotheker | Beginn Chemo Intention Protokoll |
Darmzentrum Klin. Register |
Einleitung einer längerdauernden Therapie – Strahlentherapie und Chemotherapie |
15.01.10 | 2. Zyklus | Niedergelassener Onkologe, zubereitender Apotheker | |||
… | … | … | … | … | … |
15.07.10 | Aufnahme Second-Line-Studie | Niedergelassener Onkologe, zuberei-tender Apotheker | Aufnahme in Studie Beginn Chemo Intention Protokoll Studienname / Studiennummer |
Darmzentrum Klin. Register |
Einleitung einer längerdauernden Therapie – Strahlentherapie und Chemotherapie |
15.01.11 | Tod im Krankenhaus an genereller Metastasierung | Medizinische Abteilung | Sterbedatum Krebs/Tod Relation (Leichenschauschein) |
Darmzentrum\* Klin. Register\*\* Epi. Register |
Tod |
16.01.11 | Autopsie | Pathologie | Krebs/Tod Relation | Darmzentrum\* Klin. Register\*\* Epi. Register | "Follow-up" - Autopsie |
Tabelle 1: Beispielszenario kolorektales Karzinom
\*ggf. Organzentrum aus KKR \*\*ggf. KKR aus EKR
Darmzentrum steht exemplarisch für Organkrebszentrum. Das Organkrebszentrum kann seine Dokumentation unter Umständen auch weitgehend in einem klinischen Register abbilden.
Anmerkungen:
Unklar ist, auf welcher Ebene ein QS Empfänger ist. Zum Teil werden umfassende Daten über den gesamten Behandlungsprozess benötigt. Denkbar wäre eine Ausleitung auf Ebene des jeweiligen Akteurs oder je nachdem auf Ebene der klinischen Register bzw. Organzentren.
Generell sind die genannten Informationen in der Regel auch Bestandteil der ärztlichen Kommunikation, die zur Zeit nicht strukturiert und meist papierbezogen erfolgt. Es stellt sich daher die Frage der Unterstützung des Informationsflusses außerhalb der o.g. Dokumentationssysteme (Organkrebszentrum, klin. und epid. Register). So könnten sie auch als CDA-Dokumente oder in diesen integriert übermittelt werden und Bestandteil der jeweiligen Akte werden, was in diesem Fall auch relevant für Architektur der beteiligten Anwendungssysteme ist.
Follow-up steht für jegliche Art von Verlaufsinformation. Es kann sich um ein geplantes Follow-up im Sinne einer gezielten Nachsorge bei Tumorfreiheit oder Über¬wachungs¬maßnahme bei fortbestehender Erkrankung handeln oder um ein spontanes Ereignis, das den Patienten zum Arzt geführt hat oder das als Nebenbefund bei einer anderen Erkrankung festgestellt wurde (z.B. Lungenmetastase bei Röntgenuntersuchung im Rahmen einer Lungen¬entzündung). Je nach Befund werden ggf. weitere Details erforderlich (z.B. Angabe des Orts der Metastase bei Metastasierung).
Rezidiv eines Mammakarzinoms
Dieser Fall dient exemplarisch der Abbildung des Ablaufs bei Quereinsteigern (Fällen, die nicht komplett seit Diagnosestellung in den beteiligten Systemen geführt wurden). Es werden keine neuen Ereignisse abstrahiert.
Zeitachse | Aktion / Ergebnis / Ereignis | Akteur | Daten |
---|---|---|---|
15.01.09 | Lokal tastbarer Tumor in Restbrust bei Z.n. Mammaca Januar 2008, behandelt in Brustzentrum A |
Niedergelassener Gynäkologe | |
18.01.09 | Ambulante Stanzbiopsie Bestätigung des Verdachts auf Lokalrezidiv durch Pathologen |
Brustzentrum B Pathologe | Anamnestisch Diagnosedatum Histologie |
25.01.09 | Mastektomie | Gynäkologische Abteilung | OPS OP-Datum |
27.01.09 | Pathobefund rT2N0Mo | Chirurgische Abteilung | postoperativer rTNM Tumorfreiheit |
(weiter vergleichbar Fall 1) …. |
Tabelle 2: Beispielszenario Rezidiv eines Mammakarzinoms
Wesentlich an diesem Fall ist, dass eine umfangreiche Nacherfassung erfolgen muss.
Steuerung
Hier geht es um Beispiele von Frage – Anforderung / Antwort – Ergebnismitteilung. Diese sind (auf Papier) gängige Praxis in klinischen Krebsregistern.
1.) Abfrage eines bestimmten geplanten Ereignisses (Nachsorge, Durchführung einer Therapie,…) mit Rückantwort
2.) Abfrage des aktuellsten Follow-up Ergebnisses / letzter Information zum Patienten
Abbildung Systeme / Akteure
System | Akteur |
---|---|
PVS | Niedergelassene Haus- und Fachärzte |
ADT\* / KAS | Fachabteilung: Chirurgie, Onkologie, … |
OP-System | Chirurg |
Pathologiesystem | Pathologe |
Strahlentherapiesystem | Strahlentherapeut |
Chemotherapieplanungssystem / Apothekensystem | Onkologe |
Organkrebszentrum / Spezialanwendung Tumorkonferenzsystem | Interdisziplinär / Intersektoral, bei Organkrebszentren oft eine Fach¬abteilung federführend |
Klin. Register | dto. |
Epid. Register | dto. |
QS / AQUA / DOC | dto. |
Weitere Systeme mit möglicherweise wenig betroffenen Fällen | |
Laborsystem (Tumormarker und andere Spezialbefunde) |
(potenzielle fast alle)
Systeme von Studienzentren||Prüfärzte (aus fast allen Fächern) |
\*Admission-Discharge-Transfer
Meldung 1
Datum | ||
---|---|---|
15.1.09 | Koloskopie | Prozedur |
C18.6 V | Verdachtsdiagnose | |
Polypektomie | Prozedur | |
18.1.09 | C18.6 G | Ergebnis dazu |
25.1.09 | Röntgen Thorax | |
CT Abdomen | ||
cT2 N0 M0 | Turmorformel | |
27.1.09 | Hemikolektomie offen | Prozedur |
5-455.61 | ||
30.1.09 | pT2 pN1 G2 L0 V0 R0 (lokal radial operiert) | Tumorformel |
M8140/3 Adenokarzinom ohne nähere Angaben | ||
31.1.09 | pT2 cT2 pN1 cN0 cM0 G2 C0 V0 R0 (lokal) | Zusammenfassende Beurteilung |
18. Struktur der Meldung
Sektionen | ID | Krebsreg. | ||
---|---|---|---|---|
Erkrankung | ICD | X | ||
Diagnoseanlass | X | |||
Diagnose 1 | D1 | C18.6 G | ||
Tumorformel 1 | T1 | cT2 N0 M0 | ||
Maßnahme 1 | M1 | Diagnostik | ||
Maßnahme 2 | M2 | Dto. | ||
Maßnahme 3 | M3 | Dto. | ||
Maßnahme 4 | M4 | Dto. | ||
Maßnahme 5 | M5 | OP | ||
Tumorformel 2 | T2 | pT2 pN1 G2 L0 V0 R0 (lokal radial operiert) | ||
Diagnose 2 | ICD-O | M8140/3 | X | |
Tumorformel 3 | T3 | Zusammenfassende Beurteilung T1 + T2 | pT2 cT2 pN1 cN0 cM0 G2 C0 V0 R0 (lokal) | X |
Alle Sektionen verweisen auf die Erkrankung.
Domänen-Analyse Modell
Vorgehensweise
Von der Vorgehensweise lässt sich das Projekt wie folgt zusammenfassen:
- Analyse der bestehenden Datensatzbeschreibungen
- Zusammenfassung in ein Modell auf Basis von UML: DAM
- Ergänzung des Basis-Modells um entitätsspezifische Details
- Festlegung des dynamischen Verhaltens
- Abbildung der einzelnen Klassen aus dem Modell auf Abschnitte innerhalb mit Angabe von Verknüpfungen
- Festlegung der Vokabularien und Value Sets
Erläuterung
Nachfolgend ist das Domänen-Analyse-Modell (DAM) abgebildet:
Abbildung 2: DAM
Patient
Die Klasse Patient enthält die aktuellen Angaben zum Patienten. Die Inzidenz¬adresse einer Erkrankung ist in der Klassen Erkrankung zu finden. Die Kostenträgerinformation wird z.B. durch einige klinische Register zur Abrechnung von Fallpauschalen benötigt.
Organisation
Organisation umfasst im weiteren Sinn jegliche Einheit, die in einem direkten Verhältnis zum Patienten steht oder verantwortlich für spezielle Ma߬nahmen ist. Im Konkreten sind hier beispielsweise Angaben zum Betreu¬ungs¬kontext eines Patienten möglich, also z.B. Krankenhausabteilungen oder Praxen.
Beteiligter
Beteiligte bezieht sich auf direkt an einer Prozedur Beteiligte. Diese müssen von der Organisation getrennt werden (viele Auswertungen verlangen z.B. direkt Operateure wie im Basisdatensatz).
Abbildung 3: DAM: Patient, Organisation, Beteiligte
Meldebegründung
Abbildung 4: DAM: Meldebegründung
Dort werden alle Angaben abgelegt, die sich im Kontext von Übermittlung von Daten auf Informations- oder Einwilligungsstatus beziehen. Diese Angaben werden von epide¬miologischen Krebsregistern je nach Bundesland vorgegeben. Klinische Krebsregister werden in der Regel eine Einwilligung benötigen. Es ist zu erwarten, dass hierdurch eine Reihe weiterer Zwecke (Forschung, Qualitätssicherung, …) abzubilden sind, die sich evtl. auch nur auf spezifische Ereignisse oder Bereiche beziehen. Die Meldebegründung hat einen rechtlichen Hintergrund und darf nicht mit dem Anlass einer Meldung verwechselt werden (z.B. Erst-, Folge-, Korrekturmeldung etc.).
Erkrankungen
Dies ist die Klasse für zentrale Daten für beliebige Erkrankungen. Von zentraler Bedeutung sind natürlich Tumor¬erkrankungen. Durch die Umsetzung des Modells muss sichergestellt werden, dass für jede Tumor¬erkrankung genau eine Instanz (=ein Eintrag) existiert. Davon unter¬schieden werden Phänomene, die je nach Art der Erkrankung unter¬schiedlich sind und die weitere Details enthalten. Für Tumor¬erkrankungen sind das beispiels¬weise Primär¬tumor und Metas¬tasierungen. Nicht-Tumorerkrankungen sind nicht Bestandteil des Basis¬daten¬satzes und in diesem Kontext nicht verpflichtend. Den¬noch können sie beispielsweise Therapie¬entscheidungen beein¬flussen und werden in einigen Registern mitgeführt. Bei diesen Erkrankungen sind ggf. einige Attribute nicht ver¬pflichtend.
Abbildung 5: DAM: Erkrankung
Phänomen
Abbildung 6: DAM: Phänomen
Phänomene sind direkte oder indirekte Erscheinungsformen der Tumorerkrankung. Direkte Phänomene (Primärtumor, auch in Sinne von Systemerkrankung, und Metastasen) sind prinzipiell nachweisbar über Tumorzellen, indirekte sind Erkrankungs- oder Therapiefolgen. Allen Phänomenen ist ein Beginn (Diagnosezeitpunkt) und eine dem Phänomentyp adäquate Codierung gemeinsam. Phänomene können enden und sofern es sich um ein direktes Phänomen handelt, ggf. danach rezidivieren. Darüber hinaus gibt es eine Rezidivierung der Erkrankung an sich, wenn nach kompletter Tumorfreiheit ein direktes Phänomen neu oder wieder auftritt (Primärtumorrezidiv, Rezidiv einer Metastase, Auftreten einer neuen Metastase). Eine Sonderform des Rezidivs ist ein Tumormarker-Rezidiv, das sich zumindest anfänglich jeglichen direkten Nachweises eines Phänomens entzieht. Unter pragmatischen Aspekten der Dokumentation werden unter Umständen prinzipiell auch einzeln nachweisbare Phänomene zusammengefasst:
- Mehrere Primärtumor in einem Organ (z.B. mehrere Basaliome, mehrere Darmtumore, mehrere Mammatumore in einer Brust, …)
- Generalisierte Metastasierung statt Auflistung aller Metastasenlokalisationen
- Multiple Metastasen in einem Organ werden nicht einzeln notiert
Über direkte Phänomene wird letztendlich die Tumorerkrankung diagnostisch gesichert, weshalb sie über Ergebnisse in Verbindung mit (diagnostischen) Prozeduren steht Das Phänomen Primärtumor mit dem Tumorsitz existiert genau einmal pro Erkrankung. Dies gilt im übertragenen Sinne von Primärerkrankung auch für Systemerkrankungen. Metastasen können bereits bei Diagnose einer Tumorerkrankung vorliegen oder im Verlauf auftreten. In einem bestimmten Prozentsatz gehen sie der Entdeckung eines Primärtumors voraus, oder der Primärtumor wird nie entdeckt, weil er von selbst verschwunden ist oder eine intensive Diagnostik nicht indiziert ist. Außerdem kann es bei Vorliegen mehrerer Tumorerkrankungen unmöglich sein, die Metastase genau einer dieser Erkrankungen zuzuordnen. Daher können Metastasen (und somit Phänomene), mehreren Erkrankungen zugeordnet sein, im Extremfall allen (Tumor-)Erkrankungen. Indirekte Phänomene sind:
- Folgeerkrankungen der Tumorerkrankung an sich (Anämie, Kachexie, Schmerzen, bisher nicht Bestandteil der Dokumentation)
- Folgeerkrankungen und Folgezustände der Therapie, die zumindest teilweise zwangsläufig auftreten (enthalten in der Vorversion des Basisdatensatzes und ggf. noch gängige Praxis in Registern) und die von akuten oder chronischen Nebenwirkungen sowie OP-Komplikationen abzugrenzen sind
- Akute und chronische Nebenwirkungen von Strahlen oder Chemotherapie (internationale Standards wären CTC, RTOG und WHO), in Basisdatensatz enthalten und teilweise für Zertifizierungen wichtig
- OP-Komplikationen, in Basisdatensatz enthalten, teilweise organspezifische Besonderheiten für Zertifizierungen
Über Phanomen2Phänomen können folgende Assoziationen zwischen Phänomenen bestehen.
- ist Rezidiv von:
- Primärtumor: drückt aus, wenn ein Rezidiv an der Stelle des Primärtumors auftritt
- Metastase: wenn eine Metastase an einem Ort wieder auftritt, von dem sie vorher entfernt wurde (oder wurden wenn es sich um mehrere handelt, die nicht einzeln gewertet wurden)
- ist Metastase von:
- Primärtumor: (eigentlich ist das schon durch die Beziehung zur Erkrankung klar, bzw. nicht klar wenn nicht zuordenbar bei mehreren Erkrankungen)
Prozedur (mit Unterklassen Therapie und Unter¬suchung)
Abbildung 7: DAM: Prozedur
Therapien und/oder Untersuchungen lassen sich in der Realität manchmal nicht trennen. Bezeichnet jegliche Maßnahmen am Patienten. Prozeduren können diagnostisch (im Sinne von Untersuchungen) und / oder therapeutisch sein. Die unterschiedlichen Aspekte drücken sich durch die Unterklassen Therapie und Untersuchung aus. Außerdem können sich Prozeduren aus mehreren Teilen zusammensetzen. Auf sehr hoher Ebene korrelieren sie teilweise mit den Dokumenten des Basisdatensatzes, wobei die eigentlichen Inhalte weitgehend in anderen Klassen wie Ergebnis, Erkrankung und Phänomen stehen.
- Diagnosedaten: Der Prozess der Diagnosestellung an sich
- Verlaufsdaten: Verlaufsdaten sind aus Sicht des Basisdatensatzes Statuserhebungen zu bestimmten Anlässen wie Therapieabschlüssen, Nachsorgen, Untersuchungen wegen Beschwerden etc. Eine entsprechende Differenzierung findet sich in der Unterklasse Untersuchung.
- Operative Therapie, Strahlentherapie und systemische Therapie (oder Kombinationen aus diesen): Diese setzen sich je nach Therapietyp wiederum aus z.B. Einzelprozeduren (z.B. im Sinne von OPS-Ziffern), unterschiedlichen Zielgebieten oder Zyklen etc. zusammen. Die Modellierung erfolgt über entsprechende Unterklassen.
- Life-Status / Abschlussdaten
- Autopsiedaten sind inhaltlich weitgehend mit Verlaufsaussagen deckend.
Aus praktischer Sicht wird häufig eine Fragmentierung dieser Dokumente erfolgen, die sich aus der Zeitachse und ggf. unterschiedliche Akteure ergibt, siehe Präsentation „Dokumentationsfragmente des Basisdatensatzes". Es ist anzustreben, dass jeder Akteur aus Gründen der Datensparsamkeit lediglich seinen Anteil an der Gesamtdokumentation berichtet. Das Konzept „vorgesehene Maßnahme" des Basisdatensatzes wird über den Durch¬führungsstatus umgesetzt. Hier ist eine potentielle Erweiterung der vertieften Dokumentation für Zertifizierungen denkbar, bei der zum Beispiel Prozessqualitäten auch die Planung z.B. im Rahmen von Tumorkonferenzen berücksichtigen, siehe die letzten beiden Seiten „Vorschlag für ein erweitertes Modell der Therapiedokumentation" im Dokument „Basisdokumentation Handbuch V2a.doc" Therapien sind Aussagen zu Intention und gegenseitiger Stellung sowie der planmäßigen Durchführung eigen. Diese können auch durch die explizite Assoziation „Prozedur behandelt Phänomen" ausgedrückt werden. Da Therapien wiederum indirekte Phänomene auslösen können, kann die Assoziation „Prozedur2Phänomen" auch die Qualität löst aus besitzen.
Operative Therapie
Ist bereits weitgehend durch die allgemeinen Felder von Prozedur beschrieben. Eine extra Unterklasse ist dennoch sinnvoll, da z.B. der OP-Schlüssel in einigen Fällen nicht alle Informationsbedürfnisse im Rahmen von Qualitätssicherung abdeckt. Eine Operative Therapie kann sich aus mehreren Operationen (in der Regel OP-Tage) zusammensetzen. Auf der Ebene der Operationen sind die Beziehungen zu den Beteiligten (=Operateure), die OP-Ergebnisse (aus diagnostischer Sicht und aus Erfolgssicht in Klasse Ergebnis), sowie die ggf. ausgelösten OP-Folgen (insbesondere Komplikationen) durch Phänomene ausgedrückt.
Strahlentherapie
Eine Strahlentherapie ist definiert durch ein Zielgebiet, das über eine bestimmte Applikationsart mit einer gewissen Dosis und evtl. einer Boost-Dosis bestrahlt wird (wobei sich ein Boost wohl immer auf eine Teilregion bezieht – müsste die dann nicht explizit als Boost-Zielgebiet gefasst werden?). Eine Strahlenbehandlung kann sich dabei ggf. aus mehreren (auch gleichzeitigen) Therapien (Zielgebieten) zusammensetzen. Die Strahlentherapie kann sich aus mehreren Einzelbestrahlungen zusammensetzen und korreliert hier mit einer einzelnen Dosis. Die Einzelbestrahlung ist nicht Bestandteil des ADT-Datensatzes. Denkbare Anwendung wäre im Rahmen von Studien, in denen Kapazitäten für eine derart detaillierte Erfassung vorhanden sind oder die Annahme von Daten aus einem Bestrahlungssystem. (ist das so? Ich frage mich, ob die Information Boost dann dort drin steckt. Kennt sich da jemand aus? Andernfalls wäre es nicht doch besser, das erst mal wegzulassen?).
Systemtherapie
Ein Zyklus ist ein logischer, ggf. wiederholbarer Teil einer systemischen Behandlung. Die Zyklus-Kennung entspricht in diesem Fall der Zyklusnummer, die aber nicht notwendigerweise numerisch ist, da Therapien eben nicht notwendigerweise wiederholt werden oder ggf. unterzyklisch geplant werden. Letzteres ist insbesondere in einer Kommunikation mit Apothekensystemen zu bedenken und führt insbesondere auch zur Assoziation „wird beeinflusst durch" von Zyklus und Ergebnis (z.B. Körpergröße, Gewicht, Kreatinin, Leukozyten, …).
Die Einzelgabe ist dann die konkrete Klasse für die Medikamentengabe. Unterstellt man, dass hinter einem Protokoll ein Musterverabreichungsplan steht, gehen aus der Gesamtbetrachtung aller Einzelgaben Unterbrechungen und Dosisreduktionen oder –eskalationen hervor. Zusätzlich kann es erforderlich, sein, Modifikationen, d.h. zu begründen, wie es im Basisdatensatz gefordert wird. Die Dauergabe könnte zwar theoretisch ebenfalls über Einzeldosen abgebildet werden, ist aber, da eher durch den Patienten eingenommen, nicht ohne weiteres kontrollierbar, weshalb eine gesonderte Klasse gebildet wurde, die zum Beispiel häufig für Hormontherapien Anwendung finden dürfte. Das gröbere Modell des Basisdatensatzes wird in der auf dem Bogen „Systemische Therapie" dargestellten Form für nicht praktikabel gehalten, da eine Reihe aktueller Protokolle darüber nicht darstellbar ist. Inhaltlich entspricht es diesem jedoch. In der Praxis wir eine derart genaue Dokumentation jedoch nur bei Integration mit Planungssystemen für machbar gehalten.
Wünschenswert wäre ein zentrales „Register" für Definitionsdaten von Therapieprotokollen. Ohne ein solches Register wird es m.E. notwendig sein das Modell um die Definitionsdaten zu erweitern, d.h. unter Umständen die Therapieprotokolldefinition jeweils mit zu übertragen.
Ergebnis
Abbildung 8: DAM: Ergebnis
Die Klasse Ergebnis ist der Container sowohl für direkte Unter¬suchungsergebnisse als auch deren Zusammen¬fassung zu einer Beurteilung/Bewertung. Direkte Untersuchungsergebnisse und Beur¬teilungen/Bewertungen sind sauber auseinander¬zuhalten. Während Untersuchungs¬ergebnisse möglicher¬weise über Schnittstellen aus anderen Systemen über¬tragen werden können und die zwangsläufig begrenzte Sicht eines Einzelbefunders repräsentieren, müssen mehrere Untersuchungs¬ergebnisse häufig zusammen¬fassend bewertet werden, um daraus beispielsweise eine Therapieindikation abzuleiten. So sieht der Pathologe nur das, was er an Präparat und Begleit¬information bekommt, der behandelnde Arzt kennt aber den ganzen Patienten und muss im Falle von pT und pN den klinisch erhobene M-Status ergänzen. Eine formal vollständige Histologie aus einer Biopsie hat eine andere Aussagekraft als die aus einem Resektionspräparat.
Untersuchungsergebnisse können sich aus Einzelteilen zusammensetzen. So enthält eine TNM-Formel die einzelnen Kategorien zu T, N und M und deren Präfixe etc.. Durch konkrete Instanziierungsregeln ist zu gewährleisten, dass z.B. innerhalb einer TNM-Formel jede Kategorie (T, N, M, …) bzw. jeder Zusatz (Datum, y-Symbol, Certainty-Faktor, …) höchstens einmal vorkommt. Vergleichbares gilt für andere strukturierte Angaben wie histologische Befunde oder ein Ann Arbor Klassifikation.
Beurteilungen und Bewertungen reflektieren eher das, was Register benötigen, während direkte Untersuchungsergebnisse für weitergehende Analysen im Rahmen von QM oder Studien benötigt werden und möglicherweise näher an Quelldaten in anderen Systemen sind.
Dynamisches Modell
Grundsatzfrage
Die Übersetzung des DAMs in ein dynamisches Modell bietet grundsätzlich zwei Möglichkeiten:
- Erarbeitung eines Modells zur Nachrichtenübertragung (D-MIM) mit Ableitung von entsprechenden Transaktionen
- Übertragung in ein äquivalentes Dokumentenformat (CDA)
Die bisherigen Meldungen beruhen auf dem Austausch von Dokumenten (=Meldungen). Daher bietet es sich an, CDA (Clinical Document Architcture) als Grundlage zu nehmen und dafür entsprechende Abschnitte (Templates) zu definieren.
Interaktionsdiagramm
Abbildung 9: Interaktionsdiagramm
Die Daten, die an die epidemiologischen Krebsregister geschickt werden, bedürfen weder einer Anonymisierung noch einer Pseudonymisierung. Sollte aber eine Pseudonymisierung erforderlich sein, so wird eine Vertrauensstelle benötigt, die die Daten entsprechend überarbeitet. Im Prinzip spielt diese Vertrauensstelle dann beide Rollen gleichzeitig, wobei aus dem erhaltenen Dokument eine überarbeitete Fassung erstellt wird (TRANSFORM), die dann an den entsprechenden Empfänger weitergereicht wird.
Abbildung 10: Interaktionsdiagramm mit Pseudonymisierung
Vertrauensstelle
Die Gesetze zum Datenschutz in den jeweiligen Bundesländern regeln individuell, wann eine Anonymisierung bzw. Pseudonymisierung der Daten vorzunehmen ist. In einem Bundesland dürfen die Daten nur vom erhebenden Arztbearbeitet werden, in einem anderen nur im Krankenhaus, wieder in einem anderen Bundesland nur bei Einhaltung der ärztlichen Schweigepflicht. usw.
Die Vertrauensstelle hat nun die Aufgabe, die Anonymisierung sowie Pseudonymisierung der Daten/Dokumente sicherzustellen. Alle die Person direkt identifizierenden Daten sind aus dem Dokument zu entfernen und ggf. durch geeignete Platzhalter zu ersetzen.
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 Dokument¬struktur
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>
… siehe Beschreibung CDA R2 Header
<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"/>
<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"/>
...
<component> <structuredBody> <component> <section> <templateId root="1.2.276.0.76.3.1.131.1.10.????"/> ... </section> </component>
...
<component> <section> <templateId root="1.2.276.0.76.3.1.131.1.10.?????"/> ... </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 | \[0..1\] |
id | II | Dokumenten-ID | \[1..1\] |
code | CE | Dokumententyp | \[1..1\] |
title | ST | Titel des Dokuments | \[0..1\] |
effectiveTime | TS | Erstellungsdatum des Dokuments | \[1..1\] |
confidentialityCode | CE | Vertraulichkeitsgrad | \[1..1\] |
languageCode | CS | Sprache des Dokuments | \[1..1\] |
setID | II | Set-Kennung | \[0..1\] |
versionNumber | INT | Versionsnummer | \[0..1\] |
copyTime | TS | - nicht verwenden - | \[0..0\] |
Participations | |||
recordTarget | Patient | \[1..1\] | |
author | Autor (Melder) inkl. Org. | \[1..1\] | |
dataEnterer | Datentypist | \[0..1\] | |
informant | |||
custodian | |||
informationRecipient | Empfänger: klin./epidem. Krebsregister | \[1..1\] | |
legalAuthenticator | unterzeichnender Arzt | \[1..1\] | |
authenticator | |||
participant | diverse Teilnehmer, d.h. Person bzw. Organisation | \[0..\*\] | |
Act Relationship | |||
inFullfillmentOf | |||
documentationOf | |||
relatedDocuments | |||
authorization | |||
componentOf | |||
component |
Tabelle 4: Dokumentenstruktur (-bestandteile)
Meldeanlässe und Inhalte
Grundsätze:
- Eine Meldung sollte dann ausgelöst werden, wenn eine Betreuungsepisode beendet und alle zu verantwortenden Informationen verfügbar sind.
- Grundsätzlich werden nur die Inhalte übermittelt, die mit eigenen diagnostischen oder therapeutischen Maßnahmen zusammenhängen. Davon sollte nur abge¬wichen werden, wenn andernfalls Lücken in der Erfassung auftreten würden.
Beispiel: Grundsätzlich ist eine chirurgische Abteilung verantwortlich für die Darstellung der operativen Therapie, des Therapieerfolgs und der Komplikationen. Informationen über eine außerhäusige Diagnosestellung müssten nur insofern übermittelt werden, dass das empfangende System in der Lage ist, die Therapie korrekt einem Tumor zuzuordnen. Wenn bekannt ist, dass dies aus irgendeinem Grund regelhaft nicht funktioniert oder vereinbart wurde, dass diese Informationen im Rahmen der operativen Therapie übermittelt werden sollen, hat die chirurgische Abteilung diese Eingabe zu verantworten.
Nachfolgend eine Liste der Meldeanlässe:
Diagnose
- Feststellen einer bösartigen Diagnose
- Diagnosedatum, Tumorlokalisation, Histologie, Metastasierung
- ggf. klinischer TNM oder anderes Stagingsystem
- Abschluss der erweiterten Diagnostik, ggf. Therapieplanung / Tumorkonferenz
- klinischer TNM oder anderes Stagingsystem
Operative Therapie
- Durchführen der Maßnahme
- Datum, OPS-Codes, OP-Bereich
- OP-Resultat (pTNM, R-Klassifikation)
- Komplikationen während des stationären Aufenthalts
- operative Nachschau
- 30-Tage Morbidität (Komplikationen) (/Mortalität)
Strahlentherapie
- Einleiten der Strahlentherapie
- Beginn, Zielgebiete / Bestrahlungsbereich, Intention, Stellung im Gesamtplan
- Beenden der Strahlentherapie
- Endedatum und -status, Dosis, Nebenwirkungen
- Nachschau der Strahlentherapie
- Therapieerfolg
- Kurzfristige und langfristige Nebenwirkungen
Systemische Therapie
- Einleiten der systemischen Therapie
- Beginn, Art, Protokoll, Intention, Stellung im Gesamtplan
- Beenden der systemischen Therapie
- Endedatum und -status, ggf. Dosierungen, Nebenwirkungen
Verlauf
- Datum, Tumorstatus, Metastasierung
Life-Status (Meldeamt)
- Datum "lebt" oder Sterbedatum
- ggf. aktuelle Adresse bzw. Wegzugdatum
Sterbemeldung (Gesundheitsamt, Epid. Register)
- Sterbedatum, Todesursachen
- Ggf. Krebs-Tod-Relation
Die Meldeanlässe und Inhalte können je nach Umfang und Länge des überschauten Zeitraum und ggf. dem vorgesehenen Empfänger kombiniert werden. Dies betrifft insbesondere auch den Abgleich von Tumordokumentationssystemen unterschiedlicher Stufen (z.B. Spezialsystemen in Organzentren und regionalen Krebsregistern)
Dokumenttypen
Nachfolgende Tabelle regelt, welche Abschnitte die verschiedenen Dokumenttypen zu den jweweiligen Meldeanlässen enthalten, jeweils mit Optionalität und Kardinalität:
Diag | nose | oper. | Ther. | Strahlen | ther. | system. | Ther. | Verlauf | Life- | Status | Sterbe | meldung | |||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Sektion | Opt. | Kard. | Opt. | Kard. | Opt. | Kard. | Opt. | Kard. | Opt. | Kard. | Opt. | Kard. | Opt. | Kard. | Template ID |
Meldebegründungsdaten | \[1..1\] | R | \[1..1\] | R | \[1..1\] | R | \[1..1\] | R | \[1..1\] | R | \[1..1\] | R | \[1..1\] | R | |
Diagnostik | \[1..1\] | R | \[1..1\] | R | \[1..1\] | R | \[1..1\] | R | \[1..1\] | R | \[1..1\] | R | \[1..1\] | R | |
Erkrankungsdaten | O | ||||||||||||||
Phänomendaten | O | ||||||||||||||
Operation | R | 0..* | |||||||||||||
Bestrahlung | R | 0..* | |||||||||||||
Medikamentendaten | R | 0..* | |||||||||||||
systemisch | R | 0..* | |||||||||||||
Status (Nachsorge und andere Follow-Up) | |||||||||||||||
Studiendaten | |||||||||||||||
Abschlussdaten | R | 1..* | |||||||||||||
Planung |
Tabelle 5: Überblick über die Sektionen
Sektion | Melde- begrün- dung | Diag- nostik | Erkran- kungs- daten | Phänomen- daten | Operation | Bestrah- lung | Medika- menten- daten | systemisch | Status | Studien- daten | Abschluß- daten | Planung |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Template-ID | ||||||||||||
Meldeanlass | ||||||||||||
Diagnose | \[1..1\] R | |||||||||||
operative Therapie | ||||||||||||
Strahlen- therapie | ||||||||||||
systemische Therapie | ||||||||||||
Verlauf | ||||||||||||
Life-Status | ||||||||||||
Sterbe- meldung |
Die optimale Formatierung der obigen Tabelle muss noch ausgelotet werden, da sie zu breit ist!
Header
Der Header enthält alle relevanten Metadaten.
Type ID
DT | Card | Conf | Beschreibung | |||
---|---|---|---|---|---|---|
typeId | typeID |
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
root | ST | 1..1 | 2.16.840.1.113883.1.3 |
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
extension | ST | 1..1 | POCD_HD000040 |
Diese Kennung ist fix und identifiziert dieses Dokument als CDA-Dokument.
TemplateID
DT | Card | Conf | Beschreibung | |||
---|---|---|---|---|---|---|
templateID | II | 1..1 | Strukturidentifikation des Dokuments |
In diesem Element wird die Strukturbeschreibung des Dokumentes festgehalten.
Hier muss noch die Template-ID für diesen Dokumenttyp festgelegt werden, die zusätzlich zu „CDA" gelten! |
Identifikation des Dokuments
DT | Card | Conf | Beschreibung | |||
---|---|---|---|---|---|---|
ClinicalDocument | 1..1 |
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
id | II | 1..1 | Dokumentenidentifkation |
Dieses Element identifiziert eindeutig eine Instanz eines Dokuments.
Typisierung des Dokuments
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
code | CE CWE | 1..1 | Dokumenttyp |
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:
Code | Dokumententyp | Beschreibung |
---|---|---|
Erstmeldung | Die Information in diesem Dokument wird zum ersten Mal übermittelt. | |
Folgemeldung/Ergänzung | Die Information aus der Erstmeldung wird ergänzt. | |
Erstdiagnose | ||
Operation | ||
Therapieanforderung |
Tabelle 6: Dokumententyp
Anm.: Eine Korrekturmeldung ist kein eigener Dokumenttyp, sondern wird als Korrektur einer entsprechenden Meldung gehandhabt. Damit muss das empfangende System bereits erhaltene Daten korrigieren, weil sich an den vorherigen Informationen etwas als falsch herausgestellt hat. Eine Differenzierung zwischen Folge- und Korrekturmeldung ist nicht immer klar möglich. Aus diesem Grund wird nicht differentiell übermittelt, sondern immer das komplette Dokument. Innerhalb des kompletten Dokumentes kann dann über Identifikatoren erfolgen.
Titel
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
title | ST | 0..1 | TItel des Dokuments |
Der Titel des Dokuments ergibt sich aus dem Dokumenttyp bzw. Dokumententemplate.
Setkennung
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
setId | II | 1..1 | Setkennung |
Dieses Element legt fest, zu welcher „Menge" das Dokument gehört.
Logische Kennung des Dokuments, die über die Versionen hinweg konstant bleibt. Eine Korrektur ergibt sich aus einer höheren Versionsnummer.
Versionsnummer
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
versionNumber@value | INT | 1..1 | Versionsnummer |
Zusammen mit der Setkennung regelt dieses Element die Versionierung der Dokumente.
Participant: Patient (recordTarget)
PatientRole.id Patienten-ID SET<II> \[1..\*\]
DT | Card | Conf | Beschreibung | |||
---|---|---|---|---|---|---|
recordTarget | PatientRole |
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
typeCode | CS CNE | 1..1 |
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
role | SET<II> | 1..* | Patient |
Patient.id Patienten-ID II \[0..0\]
nicht verwendet – deprecated.
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
SET<PN> | 1..* | Name des Patienten |
name Name des Patienten
SET<PN> \[0..\*\]
?????
Abbildung 15: Identifikation des Patienten
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
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
administrativeGender | CE CWE | 0..1 | Geschlecht |
administrativeGender Geschlecht
CE CWE \[0..1\]
Mit diesem Attribut wird das Geschlecht des Patienten übertragen.
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
birthTime | TS | 0..1 | Geburtsdatum |
birthTime Geburtsdatum TS \[0..1\]
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
addr | SET <AD> | 0..* | Adresse |
addr Adresse
SET<AD> \[0..\*\]
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
telecom | SET <TEL> | 0..* | Kontaktinformationen |
telecom Kontaktinformationen
SET<TEL> \[0..\*\]
Participant: Melder (author)
Abbildung 16: Melder
DT | Card | Conf | Beschreibung | |||
---|---|---|---|---|---|---|
id | SET<II> | 1..* | Melder-ID |
id Melder-ID
SET<II> \[1..\*\]
An dieser Stelle wird die ID des Melders untergebracht. Dabei ist es egal, ob es sich um ein System oder eine Person handelt. Grundsätzlich kann über eine Wiederholung auch mehrere IDs untergebracht werden, deren Semantik sich dann aus der zugeordneten OID ergibt.
DT | Card | Conf | Beschreibung | |||
---|---|---|---|---|---|---|
name | SET<PN> | o..* | Name des Melders |
name Name des Melders SET<PN> \[0..\*\] ???????
Code | Beteiligter | Deutsche Bezeichnung |
---|---|---|
22025-1 | Physician: Managing | |
22026-9 | Physician: Follow-up | |
22027-7 | Physician: Primary Surgeon | |
22028-5 | Physician 3, Physician 4, ... | |
…. |
Tabelle 7: Beteiligte (LOINC 2.16.840.1.113883.6.1 )
<participant typeCode="CALLBCK">
<associatedEntity classCode="????????">
<id root="OID-for-FIN-numbers"
extension="1231231234"/>
</associatedEntity>
</participant>
Participant: Unterzeichner (legalAuthenticator)
In diesem Element wird hinterlegt, wer die Meldung unterschrieben hat.
TODO: noch zu klären, nicht dringlich (optional)
id Unterzeichner-ID SET<II> [1..*]
name Name des Unterzeichnenden SET<PN> [0..*] ???????
Participant: Absender (custodian)
Abbildung 16: Melder Wer hat das Dokument abgeschickt. ?????????????
Participant: Empfänger (informationRecipient)
Als Empfänger kommen hier sowohl die Krebsregister als auch Praxen und Krankenhäuser in Frage.
DT | Card | Conf | Beschreibung | |||
---|---|---|---|---|---|---|
informationRecipient | 0..* | Empfänger |
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
id | SET<II> | 1..* | Register-ID |
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
name | SET<ON> | 0..* | Name des Registers |
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
Participant: Unterzeichner (legalAuthenticator)
In diesem Element wird hinterlegt, wer die Meldung unterschrieben hat. TODO: noch zu klären, nicht dringlich (optional)
???????
DT | Card | Conf | Beschreibung | |||
---|---|---|---|---|---|---|
legalAuthenticator | 0..* | Unterzeichner |
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
id | SET<II> | 1..* | Unterzeichner-ID |
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
name | SET<PN> | 0..* | Name des Unterzeichnenden |
Participant: Versicherung (participant)
???
69. 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 | |||
Autor (Melder) | |||
Patient | |||
Empfänger | |||
Participant | |||
Person | |||
Organisation | |||
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
Abschnitte
Nachfolgend werden die einzelnen Abschnitte im Detail erläutert.
Nationalität
Meldebegründungsdaten
Eine Meldebegründung gibt den rechtlichen Kontext der Meldung wider. Dies unter¬scheidet 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
<observation classCode="OBS" moodCode="EVN" negationInd="false">
<templateId root="1.2.276.0.76.5.6.25"/>
<statusCode code="completed" />
<effectiveTime value="201011051500" />
<value xsi:type="CD"
code="E"
codeSystem="????"
codeSystemName="????"
displayName="Einwilligung">
<qualifier> <name codeSystem="1.2.276.0.76...." codeSystemName="?????" code="KKR" <!—- EKR\|KKR ... --> displayName="Zustimmung"/> <value codeSystem="????" codeSystemName="Zustimmung zur Weiterleitung" code="Y" displayName="ja"/> </qualifier>
</value>
</observation>
Das Attribut - code
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
value | CD CWE | 0..1 | M | Meldebegründung |
Nicht Meldebründung aber Zusatzinfo die im Kontext der Meldung an bestimmte KR z.B. aus Abrechnungsgruünden benötigt wird.
Lvl | Code | Bedeutung | Erläuterung |
---|---|---|---|
1 | Patient ist informiert | ||
2 | E | Einwilligung | Die Einwilligung des Patienten liegt vor |
2 | W | Widerspruch zu Kontakt¬aufnahme | Patient(in) ist informiert und hat Kontaktaufnahme widersprochen |
2 | I | Information | Patientin / Patient wurde infor¬miert und hat nicht widersprochen |
2 | Widerspruch zur Übermittlung | Der Patient hat einer Über¬mittlung seiner Daten wider¬sprochen, 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 unmittel¬baren Patienten¬kontakt |
Tabelle 9: Vocabulary Domain für die Meldebegründung (Zustimmung)
Bei nachträglichem Widerspruch sind die vorher übermittelten Daten wieder zu löschen. |
Die genauen Formulierungen sind von Bundesland zu Bundesland verschieden. Die Tabelle deckt aber alle Erfordernisse ab, so dass spezifische Teilmengen über ValueSets realisiert werden können/müssen.
Code | Land | E | A | V | D | W |
---|---|---|---|---|---|---|
Baden Württemberg | ||||||
Bayern | ||||||
Berlin | ||||||
Hessen | ||||||
Niedersachsen | ||||||
NRW | ||||||
Pfalz | ||||||
Saarland | ||||||
Tabelle 10: bundeslandspezifische ValueSets für die Meldebegründung
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.
Das Attribut - effectiveTime
@effectiveTime Zeitpunkt der Meldebegründung TS \[1..1\]
Das Datum an dem der Patient unterrichtet wurde oder er unterschrieben hat.
Typ
???? \[1..1\]
Beispiel
<section>
<code code=" ?????" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC"/>
<title>Meldebegründung</title>
<text>Erstmeldung</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=" ?????" codeSystem="??????"
codeSystemName="???" displayName="Meldebegründung"/>
<statusCode code="completed"/>
<effectiveTime>
<low value="20101022"/>
</effectiveTime>
<value xsi:type="CD"
code="????" displayName="Meldung an EKR-BW "
codeSystem=" ?????"
codeSystemName="?????"/>
</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>
Diagnosen
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. |
TODO Abgleich Klassifikationsliste KRBW (Altmann)
Anlaß der Diagnosestellung
E=Eigenuntersuchung (Selbstuntersuchung) F=gesetzl. Früherkennung V=nicht gesetzl Vorsorge C=Screening A=Anamnese N=Nachsorge T=Tumorsymptomatik U=Unbekannt
Art der Diagnosesicherung
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
Diagnosen (Todesursache)
Die Übermittlung der Todesursache wird über eine separate Observation ausgedrückt, die aber in demselben Abschnitt (Section) untergebracht wird:
Abbildung 22: Diagnostik
Observation (Tod)
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@code | CD CWE | 1..1 | Tod durch Tumor |
Dieses Attribut drückt aus, dass diese Beobachtung Aufschluss über die Todesursache gibt.
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@value | CD CWE | 1..1 | Tod durch Tumor |
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 |
Tabelle 20: Vocabulary Domain für Todesursache (Kap 7.5) „unbekannt" wird über einen nullFlavor zum Ausdruck gebracht.
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@negationInd | BL | 0..1 | Negation |
Wenn gesetzt drückt dieses Attribut aus, dass der Tumor nicht tumorbedingt ist/war.
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.
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@code | CD CWE | 1..1 | Tod durch Beruf |
Dieses Attribut drückt aus, dass diese Beobachtung angibt, ob der Tod ursächlich durch die Berufsausübung veranlasst ist.
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@value | BL | 1..1 | Tod durch Beruf |
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.
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@negationInd | BL | 0..1 | Negation |
Wenn gesetzt drückt dieses Attribut aus, dass der Tumor nicht berufsbedingt ist/war.
Erkrankungsdaten
????????
{{{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
{{{1}}} |
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
??????
Abbildung 23: Operation
<component>
<section>
<code />
<title> </title>
<text> </text>
<entry>
<procedure classCode="PROC" moodCode="ENV">
...
<code Code="????" codeSystem="EVN"
codeSystemName="ops2010">
<originalText>......</originalText>
<qualifier>
<name code="??"
codeSystem="2.16.840.1.113883.3.7.1.0"/>
<value code="G"
codeSystem="2.16.840.1.113883.3.7.1.??"/>
</qualifier>
</code>
<statusCode code="completed" />
<effectiveTime value="201011051015"/>
</procedure>
</entry>
</section>
</component>
Das Attribut - classCode
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@classCode | classCode <= PROC |
Das Attribut - moodCode
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@moodCode | moodCode <= x_DocumentProcedureMood |
Das Attribut - id
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@id | SET<II> | 1..* | required | Identifikation der Operation |
Über dieses Attribut wird die Operation eindeutig identifiziert. Somit ist dieses Element required.
Das Attribut - code
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@code | CD CWE | 0..1 | Identifikation der Operation |
Code | Bedeutung | Erläuterung |
---|---|---|
Chemotherapie | ||
Hormontherapie | ||
Immuntherapie | ||
Strahlentherapie | ||
Knochenmarktransplantation | ||
Medikamentengabe | ||
nullFlavour=OTH | sonstige Therapie | ????? |
Tabelle 23: Vocabulary Domain für Operationen
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 | |||
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 | Sonstige / andere Therapie | 1), 2), 3) |
2 | ATH-HY | Hyperthermie | 4) |
Tabelle 24: Vocabulary Domain für ?????
- 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: Vocabulary Domain für die Qualifier zu den Operationen
Das Attribut - text
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@text | ED | 0..1 | Freitext |
Das Attribut- statusCode
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@statusCode | statusCode <= completed |
Ü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.
Code | Bedeutung | Erläuterung | |
---|---|---|---|
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) | ??? |
N-A | abgelehnt | 3) | rejected |
V | vorgesehen | 2), 4) | statusCode=ActStatusNew |
V-T | terminiert | 4) | moodCode=APT (Mood)??? |
J | Ja | 1), 2) | statusCode=ActStatusNormal??? |
J-B | begonnen | 4) (implizit aus leerem „Ende-Datum") | statusCode=ActStatusActive |
J-E | regulär beendet | 3) | statusCode=ActStatusCompleted |
J-A | vorzeitig beendet | 3), 5) (Abbruch wegen Nebenwirkungen) | statusCode=ActStatusAborted |
U | Unbekannt | 1) | nullFlavor=UNK |
Tabelle 26: Vocabulary Domain 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
Das Attribut - effectiveTime
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@effectiveTime | IVL<TS> | 0..1 | Durchführungszeitraum |
Benötigt wird Tagesgenauigkeit, bei OP also in der Regel Ende=Beginn.
Das Klasse Observation (Operation)
Diese Klasse im Intent Mood drückt das Ziel aus.
Das Attribut - code
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@code | CD CWE | 0..1 | Ziel der Intention |
Code | Bedeutung | Erläuterung |
---|---|---|
K | kurativ | |
P | palliativ | |
D | diagnostisch | nur bei Operationen |
U | unbekannt bzw. nicht anwendbar / sonstige Therapie |
Tabelle 27: Vocabulary Domain für Operation code
???? Diese Tabelle passt nicht zur Intention!
Das Attribut - code
@ | Attribut | DT | Card | Conf | Beschreibung | |
---|---|---|---|---|---|---|
@code | CD CWE | 0..1 | Ziel der 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 |
Tabelle 28: Vocabulary Domain für Operation code
Diese Tabelle passt nicht dazu!
Bestrahlung
{{{1}}} |
Die Bestrahlung an sich ist eine Prozedur. Allerdings bestehen Beziehungen zu Phänomenen, die als Beobachtung kommuniziert werden.
Abbildung 24: Bestrahlung
<component>
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.5.2.5.1"/>
<value xsi:type="CD"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED"
code="116197008"
displayName="Staphylococcus, coagulase negative (organism)"/>
</observation>
</component>
Medikamentendaten
Abbildung 25: Medikation
Substance Administration Hinweis auf VHitG Addendum Medikation sowie epSOS!!! |
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>
Abbildung 26: Medikation (gemäß IHE PCC)
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)
{{{1}}} |
Status (Nachsorge und andere Follow-Up)
??? |
Studiendaten
Observation |
Abschlussdaten
Observation |
Planung
Anhang A: Diverses
Offene Punkte
- vollständige Umsetzung
- Festlegung der Vokabularien
- Festlegung zur Übertragung (Transport) der Dokumente
- Validierung: BQS, Schemas, Schematron, etc.
- Signatur
- Anonymisierung bzw. Pseudonymisierung (vgl. neue IHE-Profile)
- Abgleich mit IHE QRPH-ca (public reporting to cancer registries)
Referenzen/Literatur
Kürzel | Inhalt |
---|---|
\[DIMDI, Alpha_Id\] | Alpha-ID - Die Identifikationsnummer |
\[DIMDI, Verschl\] | Anleitung zur Verschlüsselung
[http://www.dimdi.de/static/de/klassi/diagnosen/icd10/ icdsgbv20.htm-http://www.dimdi.de/static/de/klassi/diagnosen/icd10/icdsgbv20.htm] |
\[DIMDI, FAQ OID\] | hilfreiche Antworten auf häufig auftretende Fragen zu OIDs. |
\[DIMDI, Basis\] | Basiswissen Codieren, DIMDI 2004 |
\[HL7 Datentypen\] | HL7 Version 3 Datentypen und CMETs für das Deutsche Gesundheitswesen, www.hl7.de (Publikationen) |
\[CDAr2Arztbrief\] | Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen, Version 1.50 vom 12.05.2006, herausgegeben vom VHitG, HL7 Deutschland und der Arbeitsgemeinschaft Sciphox, www.hl7.de (Publikationen) |
\[Wiley, 2009\] | TNM Classification of Malignant Tumours, 7th Edition
Editors: Sobin L, Gospodaarowicz M, Wittekind C Wiley-Blackwell, ISBN: 978-1-4443-3241-4, Dez. 2009 |
\[Louis, 2007\] | Louis et al. (2007) The 2007 WHO ClassiWcation of Tumours of the Central
Nervous System. Acta Neuropathol 114(2):97–110 |
Tabelle 29: Referenzen/Literatur
Glossar
Abkürzung | Bedeutung |
---|---|
ADT | Arbeitsgemeinschaft Deutscher Tumorzentren e.V. |
AQUA | Institut für angewandte Qualitätsförderung und Forschung im Gesund¬heitswesen GmbH |
NCT | Nationales Centrum für Tumorerkrankungen Heidelberg |
DKG | Deutsche Krebsgesellschaft e. V. |
DOC | Deutsche Onkologie Centrum Holding GmbH |
DokuData | DokuData Dokumentations- und Informationssysteme GmbH |
GEKID | Gesellschaft der epidemiologischen Krebsregister in Deutschland e.V. |
GTDS | Gießener Tumordokumentationssystem |
HL7 | HL7 Benutzergruppe in Deutschland e.V. |
ID | Information und Dokumentation im Gesundheitswesen GmbH & Co. KGa |
IHE | IHE Deutschland e. V. |
VHitG | Verband der Hersteller von IT-Lösungen für das Gesundheitswesen, e.V. |
Tabelle 30: Glossar
Detaillierte Änderungshistorie
Version | Änderungen gegenüber Vorversion | Kapitel/Seitenzahl |
---|---|---|
01 | Initialfassung mit grundlegender Struktur | Alle |
02 | weitere Ausarbeitungen | Alle |
03 | weitere Ausarbeitungen | alle |
04 | Einarbeitung der Kommentare von UA, BS, SF, CT | alle |
05 | weitere Ausarbeitung | alle |
06 | weitere Ausarbeitung | alle |
07 | weitere Ausarbeitung | alle |
08 | Überarbeitung gemäßt Beispiel | alle |
Tabelle 31: Änderungshistorie