Ressourcenmodell für Meldungen gemäß § 7 Abs. 3 IfSG

Auf dieser Seite werden ausschließlich die technischen Aspekte der Erregernachweismeldung nach § 7 Abs. 3 IfSG beschrieben, die die fachlichen Ressourcen dieses Paketes betreffen. Für Informationen zur Verwendung der Basismeldeinhalte (rki.demis.common) im Rahmen dieser Meldepflicht, schauen Sie sie im entsprechenden Leitfaden nach. Für allgemeine (nicht-technische) Informationen zur Umsetzung dieser Meldepflicht, schauen Sie auf der DEMIS-Wissensdatenbank.

Zur Meldung von Erregernachweisen laut § 7 IfSG wird ein Erregernachweismeldevorgang an DEMIS übergeben. Ein vollständiger Erregernachweimeldevorgang besteht aus Ressourcen der DEMIS-Erregernachweismeldung (rki.demis.laboratory) und der DEMIS-Basismeldeinhalte (rki.demis.common). Er muss die Erregernachweismeldung mit dem Laborbericht, den Erregernachweisen und der Probe enthalten, ergänzt um die Angaben zum Melder, Angaben zur betroffenen Person und Angaben zum Einsender aus den DEMIS-Basisinhalten. Der Erregernachweimeldevorgang entspricht dem folgenden Modell:

Abweichungen des Ressourcenmodells § 7 Abs. 3 IfSG

Die Basismeldeinhalte werden für diese Meldepflicht so benutzt, wie bei der Meldepflicht nach nach § 7 Abs. 1 IfSG. Das Ressourcenmodell für dieses Paket wird ausführlich beschrieben und Grundlagen und Überblick → Ressourcenmodell für Meldungen gemäß § 7 Abs. 1 IfSG. Unterschiede ergeben sich lediglich aus den spezifischen Ressourcen. Wir haben die entscheidenden Unterschiede hier tabellarisch aufgeführt. Alle Details zur Profilierung finden Sie direkt in den erwähnten Profilen.

Ressource	Verwendung bei Meldungen nach § 7 Abs. 1 IfSG	Verwendung bei Meldungen nach § 7 Abs. 3 IfSG	Kommentar
Bundle	NotificationBundleLaboratory Enthält eine composition.NotificationLaboratory	NotificationBundleLaboratoryNonNominal Enthält eine composition.NotificationLaboratoryNonNominal	Fachliche Constraints bleiben gleich. Die Abweichungen im meta.profile und in der eingebundenen Composition gewähren lediglich eine saubere Unterscheidung der Meldekategorien für die abweichende Verarbeitung im Backend.
Composition	NotificationLaboratory Enthält den LaboratoryReport	NotificationLaboratoryNonNominal Enthält den LaboratoryReportNonNominal	Fachliche Constraints bleiben gleich. Die Abweichungen im meta.profile und in dem eingebundenen DiagnosticReport gewähren lediglich eine saubere Unterscheidung der Meldekategorien für die abweichende Verarbeitung im Backend.
DiagnosticReport	LaborytoryReport, bzw. davon abgeleitete Profile Beispiel: LaboratoryReportCVDP code.coding: NotifcationCategory code.coding.system: NotifcationCategory code.coding.code: cvdp	LaborytoryReportNonNominal, bzw. davon abgeleitete Profile Beispiel: LaboratoryReportCHTP code.coding: NotifcationCategoryNonNominal code.coding.system: NotifcationCategory code.coding.code: chtp	Die sechs Meldetatbestände nach § 7 Abs. 3 IfSG sind zu Validierungszwecken in ein eigenes ValueSet ausgelagert, aber sie stammen aus dem selben CodeSystem. Somit ändert sich in den abzusetzenden Meldungen an dieser Stelle de facto nicht mehr, als zwischen namentlichen Meldetatbeständen, da nur das CodeSystem in abgesetzte Meldungen geschrieben werden muss.

Die weiteren Ressourcen, die für dieses Paket spezifisch sind (Observation und Specimen), werden von den selben Oberprofilen abgeleitet um die Erregerspezifischen Inhalte abzubilden. Beispielmeldungen für die sechs Meldekategorien nach § 7 Abs. 3 IfSG finden Sie in der DEMIS-Wissensdatenbank.

Verknüpfung von Meldevorgängen und Meldungen mit der Meldungs-ID

Neben dem Pseudonym (Nähere Informationen siehe Leitfaden der Basismeldeinhalte (rki.demis.common) unter Ergänzende Hinweise → Nichtnamentliche Meldungen nach § 7 Abs. 3 IfSG) spielt die Meldungs-ID eine zentrale Rolle bei der Zusammenführung von nichtnamentlichen Meldungen am RKI. Ihr Einsatz wird in den Grundlagen für das Lifecyclemanagement ausgiebig beschrieben, zu finden im Leitfaden der Basismeldeinhalte (rki.demis.common) unter Grundlagen und Überblick → Grundlagen für das Lifecyclemanagement der verschiedenen Meldepflichten.

Die Übereinstimmung der Meldungs-ID bei verschiedenen Meldevorgängen wird am RKI benutzt, um diese automatisiert und eindeutig zusammen zu führen und Fehler durch Abweichungen des Pseudonyms zu vermeiden. Erst wenn dies nicht gelingt, wird der Abgleich der Pseudonyme zur Zusammenführung genutzt. Die Angabe der Meldungs-ID ist daher essentiell für diese Meldepflicht! Das erhöht die Chancen für eine saubere Zuordnung der nichtnamentlichen Meldevorgänge am RKI, da das Pseudonym anfällig für menschliche Fehler ist.

Wie eigene Meldevorgänge untereinander verknüpft werden und wie eigene Meldevorgänge mit Meldungen anderer Melder verknüpft werden (z.B. Labor + Arzt, Primärlabor + Sekundärlabor), ist detailliert im Leitfaden der Basismeldeinhalte (rki.demis.common) an oben genannter Stelle zu finden im Abschnitt "Verweis auf Meldungen anderer Melder". Wie die Meldungs-ID an andere Melder weitergegeben werden kann ist auf der selben Seite im Abschnitt "Weitergabe der Meldungs-ID" beschrieben.

Die Szenarien des Lifecyclemanagements der Erkrankungsmeldung gelten darüber hinaus so, wie auch bei namentlichen Erkrankungsmeldungen nach nach § 7 Abs. 1 IfSG. Die Szenarien 2A und 2B beschreiben die oben genannten Anwendungsbereiche.

Entsprechend folgendem Beispiel muss der Erregernachweismeldevorgang in dem Eingabeparameter ProcessNotificationRequestParameters an die Verarbeitungs-Operation übermittelt werden: