Inhalt | ||||||
---|---|---|---|---|---|---|
|
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 übermitteltStü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
generell: wie umgehen mit RKI Änderungen an oBDS Objekten
...
Ü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ändert
Beispiel: der OP_Typ 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: 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/3145745 )
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
merge
zwischen verschiedenenbranches
)
Konflikte oBDS 2014 / 2021
derzeit besteht eine Übergangsphase zwischen oBDS 2014 und oBDS 2021 (Implementierung noch nicht abgeschlossen)
Annahme: zum Zeitpunkt der Inbetriebnahme des ZfKD-Lieferdatensatzes ist gemäß Planung oBDS 2021 verpflichtend für den Austausch der Länder
das Schema berücksichtigt daher ausschließlich den neuen Standard oBDS 2021 (Stand Ende 2022-Q1)
Versionierungen der Datensätze
im Schema ist das zusätzliche Attribut “Schema_Version_Development“ vorgesehen (optional)/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 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|MFreitext255
: 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