Seitenvergleich

Lieferparameter

Umfang der Datenlieferung

• 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

Turnus

• Übermittlung erfolgt jährlich

Modus der Übermittlung

...

• Vorschlag siehe hier: Vorschlag Technischer Ablauf Lieferung klinischer Daten ans 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

• Bericht der Prüfbericht ist hier verfügbar

oBDS Elemente sind im ZfKD-Lieferdatensatz verändert

...

Unterschiede in gleichlautenden Elementen zwischen oBDS und oBDS-RKI

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

• 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

...

• /7143545/Allgemeine+Vereinbarungen#Konventionen-zu-fehlenden-Werten

Pflichtfelder

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

Wertebereiche

• siehe hier: https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7143545/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 Datumsanagben Datumsangaben (erlaubte erlaubter Datumsbereich 1890 - 2025)

• diese types Typen sind zum grossen Teil nicht übernommen in oBDS-RKI, es verbleiben Freitext30 sowie Freitext255, welche lediglich die erlaubte Anzahl Zeichen steuern

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)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