Kerndatensatz Senologie - Local Development build (v0.9.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

oBDS / Krebsregister

oBDS-Meldungstransformation

Überblick

Die Krebsregistermeldung nach dem Onkologischen Basisdatensatz (oBDS) ist eine zentrale Meldepflicht zertifizierter Brustzentren. Ziel dieser Transformation ist die automatische Ableitung von oBDS-konformen XML-Meldungen aus klinischen FHIR-Daten, die auf den Senologie-Profilen dieses IGs basieren.

• Qüllformat: FHIR Bundle mit Senologie-Profilen (dieser IG)
• Zielformat: oBDS XML, Schema-Version v3.0.5
• Methode: FHIR StructureMaps (FML) mit oBDS Logical Model als Zielstruktur
• Ausführung: Matchbox als lokale ETL-Strecke

Architektur

Die Transformation erfolgt in mehreren Schritten: Die klinischen FHIR-Ressourcen werden über StructureMaps (FHIR Mapping Language) auf ein oBDS Logical Model abgebildet. Matchbox serialisiert das Logical Model anschließend als oBDS-konformes XML.

┌─────────────────────────────┐
│  FHIR Bundle                │
│  (Senologie-Profile)        │
└──────────┬──────────────────┘
           │
           ▼
┌─────────────────────────────┐
│  StructureMap (FML)         │
│  pro Meldungstyp            │
└──────────┬──────────────────┘
           │
           ▼
┌─────────────────────────────┐
│  oBDS Logical Model         │
│  (FHIR StructureDefinition) │
└──────────┬──────────────────┘
           │
           ▼
┌─────────────────────────────┐
│  Matchbox $transform        │
│  → oBDS XML (v3.0.5)       │
└─────────────────────────────┘

Mapping-Übersicht pro Meldungstyp

Jede oBDS-Meldung entspricht einem klinischen Ereignis (Diagnose, Therapie, Verlauf, Tod). Die folgende Tabelle zeigt die Zuordnung der Senologie-FHIR-Profile zu den oBDS-Meldungstypen und den zugehörigen StructureMaps.

Jeder Meldungstyp wird von einer eigenen StructureMap abgebildet. Die Tumorzuordnung (<Tumorzuordnung>) mit ICD-10-GM, Diagnosedatum, Seitenlokalisation und ICD-O-3-Morphologie ist allen Meldungstypen gemeinsam und wird aus Senologie_Diagnose_Maligne abgeleitet.

Modul Mamma

Der oBDS enthält ein mammaspezifisches Modul (<Modul_Mamma>), das bei Diagnose- und Verlaufsmeldungen übermittelt wird. Die folgenden Felder werden aus den Senologie-Observations abgeleitet:

Die Werte P (positiv), N (negativ) und U (unbekannt) entsprechen dem oBDS-Schlüssel und werden aus den codierten FHIR-Observations mit SNOMED-CT-Kodierung übersetzt.

Code-Übersetzung

Die Senologie-Profile verwenden SNOMED CT als primäres Kodiersystem. Der oBDS erwartet eigene Schlüssel und Kodiersysteme. Die Übersetzung erfolgt über ConceptMaps, wobei die MII-Onkologie-Profile bereits viele relevante ConceptMaps bereitstellen.

Für die Medikamenten-Übersetzung stehen bereits ConceptMaps in diesem IG bereit (siehe Terminologie: Medikation). Die übrigen Übersetzungen nutzen ConceptMaps aus dem MII Onkologie-Modul.

Datenverfügbarkeit und offene Lücken

Nicht alle oBDS-Pflichtfelder können vollständig aus den Senologie-Profilen abgeleitet werden. Für eine korrekte Krebsregistermeldung müssen zusätzliche Datenqüllen eingebunden werden.

Handlungsoptionen

1. CTCAE-Nebenwirkungen — Über das bestehende MII Onko Profil mii-pr-onko-nebenwirkung-adverse-event (AdverseEvent) abbildbar. CTCAE-Art, Grad und CTCAE-Version sind als MS-Elemente definiert. Die suspectEntity-Referenz verknüpft die Nebenwirkung mit der verursachenden Therapie. Kein eigenes Senologie-Profil nötig.

2. ICD-O-Topographie — Wird aus der BodyStructure (Tumorlokalisation) abgeleitet: SNOMED-Quadrant → ICD-O-3 C50.x via ConceptMap. Seitenlokalisation separat. Die ConceptMap SNOMED → ICD-O-3 deckt alle 7 Quadranten ab, mit Fallback auf C50.9.

3. ECOG-Leistungszustand — Über das bestehende MII Onko Profil (mii-pr-onko-allgemeiner-leistungszustand-ecog) abbildbar. Muss im Brustzentrum bei Diagnose und Verlauf dokumentiert und als Observation im Bundle mitgeliefert werden. Testdaten für Verlaufs-ECOG liegen für Fall 1, 2 und 9 vor.

4. Mamma-spezifische Modulfelder (QI-3, Drahtmarkierung, Tumorgröße) — Die Felder PräopDrahtmarkierung, IntraopPraeparatkontrolle (QI-3), TumorgroesseInvasiv und TumorgroesseDCIS sind im Logical Model ergänzt. Die Drahtmarkierung wird aus der OP-Planung (ServiceRequest-Extension preOpMarkierung) übernommen; die QI-3-Präparatkontrolle aus Specimen.processing.procedure; Tumorgröße aus der Pathologie (LOINC 33728-7).

5. Genexpressionstests — Oncotype DX, MammaPrint, Prosigna etc. werden als <Weitere_Klassifikation> (oBDS Menge_Weitere_Klassifikation) exportiert. Mapping aus Senologie_Genexpressionstest (RiskAssessment): method.coding.display → Name, occurrenceDateTime → Datum, prediction.qualitativeRisk → Stadium.

6. Administrative Daten über ETL — Absender, Melder, Bankdaten, Meldebegründung kommen aus dem KIS bzw. der Krankenhausverwaltung und werden in der ETL-Strecke ergänzt, in Abstimmung mit der GB IT.

Empfehlung: Die verbleibenden Lücken (Testdaten-ycTNM/ypTNM, Frühere Tumorerkrankungen, Sozialdienstkontakt) sind konzeptionell gelöst, benötigen aber Testdaten-Ergänzung bzw. Entscheidung im Zuge der Ballotierung (siehe OF-13, OF-14).

Testdaten-Referenz

Als Referenz für die oBDS-Struktur dient der Testdatensatz der Plattform §65c (Testpatient Mamma).

Testpatientin: Michaela Musterfrau, geb. 15.10.1950

• Diagnose: C50.4 rechte Brust (oberer äußerer Quadrant), invasives duktales Karzinom (ICD-O-3: 8500/3), Grading G2
• Staging: cT1c cN0 cM0, UICC IA
• Therapie: 2 Operationen (Sentinel-LNE + Axilladissektion), Chemotherapie (Cisplatin), Hormontherapie (Anastrozol), Strahlentherapie (58,8 Gy)
• Verlauf: Rezidiv mit Fernmetastasen (Leber, Lunge), rT1c rN1 rM1, UICC IV
• Tod: 27.11.2021, tumorbedingt

Der Testdatensatz enthält 10 Meldungen (1 Diagnose, 2 Operationen, 2 Systemtherapien, 1 Strahlentherapie, 2 Tumorkonferenzen, 1 Verlauf, 1 Tod) und deckt damit alle relevanten Meldungstypen ab.

Hinweis: Die Testdaten verwenden oBDS-Schema v3.0.1. Die Zielversion dieser Transformation ist v3.0.5. Unterschiede zwischen den Versionen (insbesondere neü Pflichtfelder und erweiterte Module) müssen bei der StructureMap-Entwicklung berücksichtigt werden.

Ausführung

Die Transformation wird über einen Matchbox-Docker-Container als lokale ETL-Strecke ausgeführt.

Setup:

docker run -d -p 8080:8080 eu.gcr.io/fhir-ch/matchbox:latest

Transformation:

POST http://localhost:8080/fhir/StructureMap/$transform
Content-Type: application/fhir+json

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "source",
      "resource": { /* FHIR Bundle mit Senologie-Ressourcen */ }
    },
    {
      "name": "source",
      "valüUri": "https://www.senologie.org/fhir/StructureMap/SenologieToObdsDiagnose"
    }
  ]
}

Das Ergebnis ist eine Instanz des oBDS Logical Models, die als XML serialisiert und an das Krebsregister übermittelt werden kann.

Perspektive: Langfristig ist eine Umstellung der Krebsregister auf FHIR-basierte Meldungen wahrscheinlich. Die StructureMap-basierte Architektur ermöglicht einen fließenden Übergang: Sobald Krebsregister FHIR-Bundles akzeptieren, entfällt der XML-Serialisierungsschritt, und die Transformation reduziert sich auf ein Profil-Mapping.

Validierung der Transformationsergebnisse

Die Transformation wurde mit Matchbox $transform gegen das Fall-1-Bundle (Erika Neumann) getestet. Anschließend wurde der Output gegen das oBDS Logical Model validiert.

Die folgenden Pflichtfelder des oBDS Logical Models werden durch die StructureMaps nicht befüllt und müssen durch das lokale KIS oder die ETL-Strecke ergänzt werden. Dies betrifft insbesondere administrative Daten und Felder, die im Brustzentrum derzeit nicht strukturiert dokumentiert werden.

Erfolgreich befüllte Felder (Auswahl):

• Tumorzuordnung: ICD-10-GM C50.4, Diagnosedatum
• Diagnose: Freitext, Diagnosesicherung, ECOG-Leistungszustand (0), Genexpressionstest (Oncotype DX)
• OP: Intention (K), Datum, OPS-Codes (5-870.a1, 5-401.11), Residualstatus R0
• Strahlentherapie: Beginn/Ende, Applikationsart, Zielgebiet
• Tumorkonferenz: Datum, Therapieempfehlungen (SNOMED-Codes)