Version 3.0.0

Die Veröffentlichung des Updates des einheitlichen onkologischen Basisdatensatzes im Bundesanzeiger wurde genutzt, um auf Basis der bisherigen Erfahrungen das XML-Schema weiter für die Übermittlung und Entgegennahme von Meldungen zu optimieren. Mit Veröffentlichung der Version 3.0.0 trägt die Schnittstelle den neuen Namen „oBDS-Schnittstelle“; vorher war sie unter der Bezeichnung „ADT-GEKID-Schnittstelle“ bekannt. Die wesentlichen Veränderungen sind im Folgenden beschrieben:

Allgemeine Struktur

Begriffsdefinition

Die Bezeichnung Dokumenttyp wird als Sammelbegriff für die unterschiedlichen Typen von Inhalten verwendet, die zu den Meldeanlässen übermittelt werden. Ein Dokument ist eine konkrete Instanz eines Dokumenttyps.

Nur ein Dokument pro Meldung

Die Verarbeitung von Meldungen mit mehreren Inhalten ist in vieler Hinsicht problematisch. Daher gilt ab Schema 3.0.0: Eine Meldung (Element Meldung unter Element Patient) kann nur noch ein Dokument beinhalten. Es ist nicht mehr möglich, in einer einzigen Meldung z.B. zwei OPs und drei Verläufe zu übermitteln.  Es besteht somit ein klarer Bezug zwischen Meldeanlass und erwartetem Inhalt. Pflichtfelder lassen sich auf diese Art und Weise technisch deutlich besser umzusetzen.

Neuer Dokumenttyp Pathologie

Dies ist ein spezieller Dokumenttyp für Meldungen von pathologischen Befunden, der nun unabhängig von der Struktur von Diagnosemeldungen Elemente und Pflichtfelder, z.B. Einsender, definiert. Ein Pathologiebefund ist rein inhaltlich nicht mit einer Diagnosemeldung gleichzusetzen. Die bisherige Lösung war ein Notbehelf. Pathologiebefunde besitzen darüber hinaus spezielle Angaben, die in klinischen Diagnosemeldungen nicht verlangt werden und in der neuen Version explizit gefordert werden.

Tumorzuordnung Pflicht

Die Tumorzuordnung beschreibt den Primärtumor und ist immer anzugeben, auch bei Meldungstyp Diagnose und Pathologie. Redundante Felder wurden aus den Diagnosedaten (über die vormals auch Pathologiemeldungen übermittelt wurden) entfernt. Für Fälle, in denen Pathologen möglicherweise Schwierigkeiten haben, die ICD und das Diagnosedatum genau zu bestimmen, werden im Umsetzungsleitfaden Hilfestellungen formuliert. So kann z.B. bei unbekanntem Primärtumor ein entsprechend ungenauer Diagnose-Code angegeben werden. Außerdem wurde die Tumorzuordnung optional um einen Morphologiecode erweitert.

Trennung von Verlauf und Tod

Tod ist nicht mehr Teil des Dokuments Verlauf, sondern ist ein eigenständiges Dokument auf derselben Ebene wie Diagnose, OP, Verlauf, … Die Trennung von Tod und Verlauf ermöglicht es, Pflichtfelder für Verlauf zu definieren, die bei Tod nicht relevant sind und umgekehrt.

Datumsangaben

Datumsangaben werden technisch einheitlich mit XML-Standarddatentypen umgesetzt. Ungenaue Datumsangaben werden als Schätzdatum umgesetzt. Es ist immer ein vollständiges Datum anzugeben, inklusive der Information, ob das Datum exakt ist, der Tag geschätzt ist, Tag und Monat geschätzt sind oder das Datum vollständig geschätzt ist. Je nach Feld sind nur bestimmte Schätzebenen erlaubt. Beispielsweise kann bei einem Feld mindestens die Monatsangabe exakt verlangt werden. Die Ausprägung „Vollständig geschätzt“ oder „Monat geschätzt“ steht dann nicht zur Auswahl.

In den letzten 2.x.x Schemata werden Datumsangaben in nicht einheitlichen Typen eingesetzt, die textbasierten Typen im deutschen Format sowie in neueren Modulen die XML-Standardtypen im ISO-Format. Dies muss vereinheitlicht werden.

Die textbasierten Typen lassen technisch ungültige Datumsangeben zu. Dies liegt zum einen an den erlaubten unvollständigen Angaben (z.B. 00.00.2010) und zum anderen daran, dass der Texttyp keine Schaltjahre berücksichtigen kann.

In Datenbanken können textbasierte Datumsangaben nicht sinnvoll verwendet werden, da damit weder gerechnet noch korrekt sortiert werden kann. Daher setzen auch heute schon die Registeranwendungen die Angaben in echte Datumsangaben und eine Präzisionsangabe um.

Die Umsetzung als Schätzangabe ist außerdem inhaltlich mächtiger, da sie dem Melder erlaubt, eine genauere zeitliche Eingrenzung zu machen (05. Mai, Tag geschätzt), als durch Weglassung möglich ist (Mai). Eine Normierung von Schätzangaben zur Auswertungszwecken z.B. auf 15. des Monats, bzw. 01.07. des Jahres ist im Register weiterhin möglich.

Datentypen für Freitext und ID-Felder

Die Datentypen für zahlreiche Freitextfelder und ID-Felder wurden geschärft. Es wurden flächendeckend Längenbeschränkungen eingeführt. Es werden, wo angebracht, Datentypen verwendet, die keine Zeilenumbrüche, doppelte Leerzeichen, Tabulatoren etc. zulassen (xs:token). Wo angebracht, werden die Datentypen der String.Latin 1.2 (DIN SPEC 91379), bzw. davon abgeleitete Typen verwendet. (Siehe https://www.xoev.de/string_latin-4813). Dies erlaubt es z.B. die in UTF-8 enthaltenen arabischen oder asiatischen Schriftzeichen grundsätzlich auszuschließen und für bestimmte Felder die zulässigen Zeichen spezifisch einzugrenzen.

Beispiel:

• Datentyp A für Namen natürlicher Personen
• Datentyp B für Orts und Straßennamen
• Datentyp E für alle Zeichen des String.Latin
  

Meldung

Meldeanlass

Der Meldeanlass ergibt sich nun aus dem jeweils befüllten Dokumenttyp (Diagnose, OP, Verlauf, …) und wird nur noch bei den Dokumenttypen gefordert, bei denen eine Unterscheidung notwendig ist:

• Verlauf
  • statusmeldung
  • statusaenderung
• Strahlentherapie und Systemische Therapie
  • behandlungsbeginn
  • behandlungsende
• Tumorkonferenz
  • diagnose
  • behandlungsbeginn
  • behandlungsende
  • statusmeldung
  • statusaenderung
    

Patient

Frühere Namen

Abweichung zur Formulierung im Basisdatensatz: Alle früheren Namen ggf. durch „;“ getrennt. Bereits in 2.x.x Version des Schemas wurde das folgendermaßen umgesetzt: Es gibt eine Menge Frühere Namen, in der Frühere Namen einzeln angegeben werden können. Eine Trennung durch „;“ ist daher nicht vorgesehen und wäre ein technischer Rückschritt.

Versichertendaten

Angaben zur Versicherung werden detaillierter modelliert. Im Schema wird zwischen drei grundlegenden Fällen unterschieden, die jeweils eigene Merkmale und Pflichtfelder aufweisen:

1. Der Patient ist GKV versichert (Versichertendaten_GKV). Hier ist die Angabe des Institutionskennzeichens der Krankenkasse sowie der unveränderliche Teil der Krankenversichertennummer verpflichtend anzugeben.
2. Der Patient ist bei einer dem Melder bekannten PKV versichert (Versichertendaten_PKV). Hier ist das Institutionskennzeichen der privaten Krankenversicherung verpflichtend anzugeben. Die PKV Versichertennummer kann optional angegeben werden. Für Beihilfeberechtigte kann außerdem der jeweilige Beihilfeträger angegeben werden.
3. Sonstige Angaben zur Krankenversicherung (Versichertendaten_Sonstige). Fällt der Patient in keine der obigen Kategorien oder sind die Versichertenangaben unvollständig, ist das Institutionskennzeichen oder, wenn nicht verfügbar, ein entsprechender Ersatzcode verpflichtend anzugeben. Zusätzlich können optional folgende Informationen übermittelt werden: Krankenkassennummer, KrankenkassenName, Versichertennummer.

Die Angaben zu GKV und PKV Versicherten können strenger geprüft werden. Im PKV Feld wurde bisher eventuell das Anmerkungsfeld missbraucht, wenn der Melder die IK-Nummer der privaten Krankenkassen nicht kennt und nur den Namen des Unternehmens übermittelt. Ersatzangaben sind nun klar von gültigen Angaben getrennt und die gültigen Ersatzcodes sind nun Teil des Schemas.

Histologie

Die Histologie ist in Diagnose (vormals auch für Pathologiemeldung genutzt) nicht mehr als Ganzes wiederholbar, sondern nur noch der Morphologie-Code (maximal fünf Mal). Bei Tumoren, in denen unterschiedliche histologische Typen vorkommen, müssen daher die übrigen Angaben wie z.B. die Lymphknoten oder Einsendenummer nicht wiederholt werden und es können keine Widersprüche auftreten.

Nebenwirkungen und Komplikationen

Allgemein

Hier wurden strukturelle Änderungen vorgenommen, die unsinnige Kombinationen wie zum Beispiel mehrere Angaben von „N“ und expliziten Nebenwirkungen bzw. Komplikationen verhindern, indem bei Nebenwirkungen eine Aufteilung in die Angabe eines „Grad_maximal2_oder_unbekannt“ (mit den Codes K 1 2 U) und Menge_Nebenwirkung vorgenommen wurde. Damit kann eine Gradangabe bei Grad >= 3 als Pflichtfeld definiert werden. Analog wurde bei OP-Komplikationen verfahren (Komplikation_nein_oder_unbekannt oder Menge_Komplikation).

OP Komplikationen

Fehlende Komplikationen können jetzt nach ICD10 aufgelistet werden. In der ICD-10 ist das Kapitel T80-T88 speziell dafür vorgesehen: „Komplikationen bei chirurgischen Eingriffen und medizinischer Behandlung, anderenorts nicht klassifiziert“. Dabei werden einleitend einige Exklusiva aus anderen Codebereichen aufgeführt. 

Strahlentherapie

Die Inhalte der Dokumentation werden nach Applikationsarten getrennt, da nicht alle Ausprägungen bei allen Applikationsarten sinnvoll/notwendig sind. Dazu bestehen auch weitere Einschränkungsmöglichkeiten z.B. nach der Dosiseinheit. Die Auswahlliste der Applikationsart wird also als CHOICE implementiert, bei der Zusatzangaben zur Applikationsart als Extra-Elemente definiert sind.

Residualstatus (Systemische und Strahlentherapie)

Der Residualstatus wurde aus der Definition entfernt. Er war in der Version 1 aufgenommen worden, um die Möglichkeit zu schaffen, auch bei diesen Therapieformen eine Erfolgsbeurteilung abgeben zu können, wurde aber aus verschiedenen Gründen praktisch kaum genutzt.

Die Erfolgsbeurteilung ist meist erst mit einigem Abstand zum Therapieende möglich und das Re-Staging wird nicht notwendigerweise durch den Therapeuten vorgenommen. Daher ist zur Übermittlung des Therapieergebnisses nach definitiven systemischen und/oder Strahlen-Therapien nunmehr eine separate Verlaufsmeldung vorgesehen. Diese Verlaufsmeldung nach definitiver Therapie stellt unabhängig vom konkreten Therapieerfolg eine Information im Sinne von „therapierelevante Änderung des Erkrankungsstatus dar und sollte als „statusaenderung“ übermittelt werden.

Bei neoadjuvanten Therapien mit anschließender OP und adjuvanten Therapien nach R0-Resektionen ist keine Verlaufsmeldung erforderlich, da die Erfolgsbeurteilung in diesen Fällen in Form des Residualstatus mit der OP-Meldung übermittelt wird.

Abweichungen vom Basisdatensatz

Um Rückfragen wegen Auffälligkeiten vorzubeugen, werden hier Abweichungen genannt, in denen die XML-Spezifikation vom Basisdatensatz abweicht. Bei den genetischen Varianten ist abweichend vom Bundesanzeiger auch immer eine Datumsangabe möglich.

Diagnosesicherung

Der Basisdatensatz enthält nicht die Ausprägung 9=unbekannt, das kann aber im Ausnahmefall inhaltlich der Fall sein.

Grading

Der Basisdatensatz enthält die Ausprägung 5 für das Grading. Diese Ausprägung 5 wurde entfernt. Die Ausprägung 5 beruht auf einem Missverständnis. Die 5 ist vorgesehen für eine Gruppierung nach WHO, aber ist keine Grading Angabe. (TNM Seite 247).

Tumor_Histologiedatum

Abweichung vom Basisdatensatz: „Es kann in Ausnahmefällen ein monatsgenaues oder jahrgenaues Datum übermittelt werden mit Angabe der Genauigkeit“. Da Schätzangaben in Ausnahmefällen möglich sein sollen, muss hier grundsätzlich mit einem Datentyp gearbeitet werden, der dies erlaubt. 

TNM-Präfixe

Abweichung vom Basisdatensatz: Die Ausprägung „u“ (Ultraschall) für Präfixe ist nicht mehr aufgeführt, wird aber im Schema beibehalten. Die Ausprägung ist eine gültige Angabe für Präfixe (gilt für alle TNM Angaben), TNM-Supplement, 5th Edition, p 25

TNM-UICC-Stadium

Abweichung vom Basisdatensatz: keine Restriktion im Basisdatensatz (Freitext). Im Schema wird hier eine Enumeration verwendet.

Pathologie-Einsenderinformation

Abweichung der Einsenderinformation vom Basisdatensatz: Differenzierte Merkmale (Name, Straße …). Hier wurde eine wählbare Option zwischen differenzierter und einfacher Angabe als Adresszeile 1 bis 4 umgesetzt. Viele Pathologiesysteme haben noch keine Möglichkeit zur differenzierten Angabe von Einsenderinformationen, sondern lediglich einige Freitextfelder für die Adresse. Grundsätzlich wird allerdings weiterhin eine strukturierte Angabe angestrebt und die einfache Angabemöglichkeit kann in zukünftigen Versionen wegfallen.

Strahlentherapie

Zielgebiet: Laut Basisdatensatz ist nur die neue Schlüsselversion zulässig. Hier wurde auch die alte Schlüsselversion als zulässig umgesetzt, allerdings mit verpflichtender Versionsangabe. Es war angesichts der unterschiedlichen Zahl der Systeme und der erforderlichen Schulung nicht vorstellbar, wie eine Umstellung zu einem definierten Zeitpunkt praktiziert werden soll. Für eine Übergangsphase werden alte und neue Codes verwendet und müssen  gemeldet werden. Diese können sogar innerhalb eines Datenpakets gemischt vorkommen. Es ist aber allein an der Ausprägung nicht erkennbar, ob es sich um eine neue oder alte Codierung handelt. Das Mapping zwischen altem und neuem Schlüssel ist nicht verlustfrei möglich. Bedeutungen von Codes haben sich verändert, d.h. wenn ein Primärsystem eine neue Schemaversion schickt, aber noch alte Zielgebietsschlüssel verwendet, kann es zu Fehlinterpretationen kommen. Daher muss die Version der Codierung explizit genannt werden. Eine Umschlüsselung auf eine neue Version, sofern sie möglich ist, kann dann immer noch zentral im Register erfolgen. In späteren Versionen soll die alte Version nicht mehr erlaubt sein, weil dann die erforderliche Übergangsphase abgeschlossen ist.

SYST_Beginn_Datum

Abweichung vom Basisdatensatz: Exaktes Datum ist anzugeben. Tag und Monat als Schätzangabe sind dennoch zugelassen. Da die Angabe ein Pflichtfeld sein soll, aber bei Behandlungsende der Beginn nur vage bekannt sein kann (z.B. bei Hormontherapie), kann die Tagesgenauigkeit nicht durchgesetzt werden. Aus technischen Gründen kann das im Schema leider nur generell definiert und Behandlungsbeginn und Behandlungsende unterschiedlich eingeschränkt werden. Bei Behandlungsbeginn wird in der Praxis ein genaues Datum erwartet.

Modul Allgemein - Zusätzliche Kontakte

Abweichung vom Basisdatensatz: Dort wird eine Kontaktliste mit Art (Sozialdienst, Psychoonkologische Beratung), Status (J/N) und Datum genannt. Die Kontakte werden explizit als einzelne Elemente mit einfacher Kardinalität und nicht als Liste modelliert. Mit der im Basisdatensatz vorgeschlagenen Formulierung wäre es möglich, den gleichen Kontakttyp mehrfach zu übermitteln, auch in widersprüchlicher Form, z.B. mit „N“ und nochmals mit Datum, was nicht erwünscht ist.

Download