| 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 ü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
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
Gibt es eine allgemeine Konvention zu fehlenden Werten?
Simple Types zur Bechreibung 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: Freitext30)
Pflichtfelder
Wertebereiche
Versionen
Basis des Schemas: oBDS 3.0.0 (Stand Ende 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 verschiedenen branches)
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 BDS 2021 verpflichtend für den Austausch der Länder
das Schema berücksichtigt daher ausschließlich den neuen Standard oBDS 2021
Versionierungen der Datensätze
im Schema ist das zusätzliche Attribut “Schema_Version_Development“ vorgesehen (optional)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/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
Versionssfortschritte Versionsfortschritte und Release-Notes werden hier veröffentlicht
...
Inhalt
· Alle Fälle mit Diagnosejahr <= 2019
· Angaben zu Diagnose, Therapie (J/N) und ggf. Tod
· Merkmalsliste siehe Anlage
| View file | ||
|---|---|---|
|
Variante 1: Lieferung nach altem Epi-Format
Vorteile
· Für bisherige Epi-Register ohne Zusatzaufwand machbar
Nachteile
· Für GKR-Länder neu zu implementierendes Exportformat
· Zwei separate und nicht zu verknüpfende Datenbestände beim ZfKD
Variante 2: Lieferung nach neuem ZfKD-XML-Schema
Vorteile
· Nur ein Exportformat
· Ein Gesamtdatenbestand beim ZfKD, allerdings vor 2020 viele Merkmale fehlend.
Nachteile
· Therapieangaben mit Ausprägungen J/N im XML-Schema nicht vorgesehen. Da vermutlich in einigen Epi-Registern die Therapieangaben nicht genauer vorliegen und somit nicht ersatzweise z.B. das Datum eingetragen werden kann, müssten solche Felder noch ergänzt werden.
· Manche Ausprägungen der Epi-Daten entsprechen nicht dem Basisdatensatz (z.B. Diagnosesicherung DCO).
Variante 3: Jedes Register liefert entweder altes Epi-Format oder Daten im neuen Schema
Vorteile
· Kein Zusatzaufwand für alle Register, GKR-Länder dürften über detaillierte Therapieangaben auch für Altfälle verfügen und damit das neue Schema gut füllen können.
Nachteile
· Erstellung eines Konverters EPI -> ZfKD-XML notwendig.
· Therapieangaben liegen im ZfKD in unterschiedlicher Qualität vor (Reduzierung auf J/N notwendig?).
...
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