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

Integration der epi Daten

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

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

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