Seitenvergleich

Lieferparameter

...

Modus der

...

• Daten werden als “Vollabzug” geliefert, d.h. sämtliche verfügbaren Daten aus allen Jahresscheiben werden in jeder Lieferung übermittelt

• damit steigt das Datenvolumen jeder Übermittlung enorm an, aber es entfällt jegliches aufwendiges Nachhalten von Änderungen in den Daten

• wurde in der epi Datenlieferung so praktiziert

Dateiformat

• Dateien werden im xml Format übermittelt

• Stückelung der Lieferung in einzelne Dateien mit definiertem maximalen Wert für Anzahl der enthaltenen Datensätze

Turnus

• Übermittlung erfolgt jährlich

Verschlüsselung der Lieferung

• für die Übermittlung die gleiche Verschlüsselungssystematik wie beim RÜD verwendet

• Schlüssel sind nur für die Übermittlung ans RKI definiert

• RKI nimmt am Verfahren teil, erhält eigenes Schlüsselmaterial

Übertragungswege /-medien

• falls nicht bereits eigene Wege im RÜD etabliert und zweckmäßiger: RKI Austausch Server kann für Transfer genutzt werden (->Transportverschlüsselung)

Syntax

Typkonstrukte

oBDS Elemente sind im ZfKD-Lieferdatensatz verändert

...

Übermittlung

• Vorschlag siehe hier: Vorschlag Technischer Ablauf Lieferung klinischer Daten zum RKI

Syntax im XML-Schema

Ergebnisbericht einer Prüfung des oBDS Schemas

• ein externer Dienstleister hat auf Auftrag hin die Schemakonsistenz geprüft in oBDS 3.0.0 (Stand August 2021)

• die Aussagen des Prüfberichtes können zum Teil auch auf oBDS-RKI übertragen werden

• der Prüfbericht ist hier verfügbar

Unterschiede in gleichlautenden Elementen zwischen oBDS und oBDS-RKI

• im oBDS-RKI sind viele Elemente aus oBDS namensgleich übernommen, allerdings sind die Strukturen im Element möglicherweise verändertBeispiel: der

• grundsätzlich ist eine bestmögliche Kompatibilität angestrebt zwischen den Schemata der oBDS Familie, allerdings sind Detailänderungen unvermeidlich, insbesondere wegen

  • gesetzlichen Beschränkungen der zu übermittelnden Informationen

  • Paradigmenwechsel Medlungsebene zu Fallebene

  • Besonderheiten der Übermittlung an das RKI wie z.B. Abstände zwischen Ereignissen in Tagen

• Bezeichnungen für Felder wurden mit wenigen Ausnahmen übernommen

Konventionen zu fehlenden Werten bei der Übermittlung

• Festlegungen dazu sind eher inhaltlicher Natur und daher hier zu finden: https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2621490 wurde so umgestaltet, dass viele Unterelemente nicht mehr enthalten sind, dafür kommen einige neue Variablen hinzu

• u.U. führt das zu Problemen in der Implementierung

Konvention zu fehlenden Werten

Simple Types zur Beschreibung von Textinhalten sind ohne Änderung aus oBDS übernommen

• Vermutung: die Anforderungen an die technische Beschaffenheit von Textfeldern (z.B. ASCII Zeichensatz) gelten sowohl im oBDS als auch im ZfKD-Lieferdatensatz (Bsp: /7143545/Allgemeine+Vereinbarungen#Konventionen-zu-fehlenden-Werten

Pflichtfelder

• siehe hier: https://plattform65c.atlassian.net/wiki/spaces/P6/pages/3145745, 7143545/Allgemeine+Vereinbarungen#Pflichtfelder

Wertebereiche

• siehe hier: https://plattform65c.atlassian.net/wiki/spaces/P6/pages/23923237143545/Weitere+Klassifikation?focusedCommentId=2621834#%C3%9Cbersicht-Felder )

Pflichtfelder

Wertebereiche

Versionen

Basis des Schemas: oBDS 3.0.0 (Stand Ende 2022-Q1)

• Schema des ZfKD-Lieferdatensatzes ist über mehrere Monate hinweg entstanden, Weiterentwicklungen im oBDS in dieser Zeit sind bislang nicht berücksichtigt

• u.U. wäre also zu prüfen, ob im Schema nun Konflikte bestehen durch im oBDS bereits überholte Artefakte

• unklar ist derzeit, wie im einzelnen die Weiterentwicklung des ZfKD-Lieferdatensatzes parallel zum oBDS erfolgen kann (als mergezwischen verschiedenen branches)

Konflikte oBDS Versionen

Versionierungen der Datensätze

• im Schema ist das zusätzliche Attribut “Schema_Version_Development“ vorgesehen (optional)Allgemeine+Vereinbarungen#Wertebereiche

Simple Types zur Beschreibung von Textinhalten

• im oBDS sind diverse simple types hinterlegt zur Deklaration von Wertebereichen von Texten (erlaubte ASCII Zeichen) und Datumsangaben (erlaubter Datumsbereich 1890 - 2025)

• diese Typen sind nicht übernommen in oBDS-RKI, da bei dieser Übermittlung die maschinelle Validierung von Daten verschiedenster Meldestellen keine Rolle spielt

• es verbleiben Typen zur Steuerung der erlaubten Zeichenzahl in Feldern, die keine Einschränkungen durch Kodierungen aufweisen

  • Freitext30: z.B. bei Angaben zu T|N|M

  • Freitext255: z.B. bei Angaben zu Substanz/Bezeichnung

Versionen des XML-Schemas

• zur Festlegungen zu alten und neuen oBDS Versionen siehe hier: https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7143545/Allgemeine+Vereinbarungen#%C3%9Cberleitung-oBDS-2014-zu-2021

• im Schema ist das Attribut “Schema_Version“ für die Versionierung des Datensatzes vorgesehen

  • die ersten 3 Bestandteile (Major.Minor.Revision) entsprechen der oBDS Version, auf der das Schema basiert

  • Bestandteil 4 (Build) ist eine Versionsnummer zur Anzeige der Weiterentwicklung des Schemas selbst

  • Versionsfortschritte und Release-Notes werden hier veröffentlicht

...

• die Weiterentwicklung von oBDS-RKI soll parallel zu oBDS erfolgen

• so müssen für oBDS-RKI relevante Strukturänderungen in einer neuen Version des oBDS auch nachgezogen werden, was sich dann in einer entsprechenden Basisversion des oBDS-RKI widerspiegelt