Grundlagen für das Lifecyclemanagement

Grundlagen

DEMIS unterscheidet aus konzeptioneller Sicht zwischen Meldevorgängen, Meldungen und Fällen. Diese Unterscheidung ist insbesondere mit Blick auf das Meldungslifecyclemanagement und die in diesem Zusammenhang genutzten Identifier von besonderem Interesse.

Fall

Ein Fall ist in Bezug auf die epidemiologische Überwachung von Infektionskrankheiten die Grundlage der Arbeitsorganisation in den Gesundheitsämtern. Ein Fall repräsentiert dabei primär eine bestimmte Erkrankung oder den Nachweis eines bestimmten Krankheitserregers in Bezug auf eine betroffene Person. Erfolgt der Nachweis von zwei verschiedenen meldepflichtigen Erregern in einer Probe, werden mehrere Fälle zu der betroffenen Person angelegt, einer pro Erreger. Fälle werden in Auszügen nicht-namentlich an die zuständigen Landesstellen und von dort an das RKI übermittelt. Ob ein Fall übermittlungspflichtig ist, entscheiden die vom RKI herausgegebenen Falldefinitionen. In diesem Zusammenhang ist jedoch zu berücksichtigen, dass diese Falldefinitionen NICHT die Kriterien für die Meldung an das Gesundheitsamt festlegen. Sie richten sich deshalb explizit NICHT an klinisch oder labordiagnostisch tätige Ärztinnen und Ärzte.Die Quelle, der zu einem Fall erfassten Angaben, bilden - neben eigenen Ermittlungen des jeweiligen Gesundheitsamtes - zu einem bedeutenden Teil auch die an das Gesundheitsamt gesendeten Meldungen und jeweils zugehörigen Ergänzungen/Korrekturen. Dabei ist zu berücksichtigen, dass häufig auch mehrere Meldungen (Labor + Arzt, Primärlabor + Sekundärlabor, Labor und Gemeinschaftseinrichtung etc.) den benötigten Input für einen einzelnen Fall liefern können. Diese Meldungen können sich u.U. auch aufeinander beziehen. Auf Grundlage der aus Meldungen übernommenen und ggf. selbst ermittelten Informationen kann die Software im Gesundheitsamt die Übermittlungspflichtigkeit eines Falles ermitteln

Meldevorgang

Ein Meldevorgang (MV) ist die Nachricht eines Melders (z.B. eines Labors oder Krankenhauses) an die DEMIS Infrastruktur. Er entspricht im Prinzip dem alten Labormeldeformular. Es gibt den initialen Meldevorgang (MV1), der ergänzt oder korrigiert werden kann, mittels weiterer Meldevorgänge (MV2, MV3,...). Es wird dann immer eine neue Nachricht des Melders an die DEMIS Infrastruktur gesendet. Damit beziehen sich unterschiedliche aber zusammengehörige Meldevorgänge grundsätzlich auf die gleiche logische Meldung. Meldevorgänge werden über DEMIS an die jeweils zuständigen Gesundheitsämter vermittelt und in den dortigen Fachverfahren verarbeitet. Im Ergebnis wird der Meldevorgang bzw. die darüber kommunizierte Meldung einem neuen oder ggf. auch einem bestehenden Fall zugeordnet.Meldevorgänge werden innerhalb des DEMIS-Informationsmodells als profilierte FHIR-Bundle-Ressourcen (vgl. z.B. Erregernachweismeldevorgang oder Erkrankungsmeldevorgang) abgebildet und sind mit einem eindeutigen Identifier, der Meldevorgangs-Id (NotificationBundleId), versehen, welcher durch das DEMIS Backend gesetzt bzw. überschrieben wird. Jeder Meldevorgang hat somit einen individuellen Identifier, der ihn eineindeutig identifiziert und als Ende-zu-Ende-Referenz zwischen Sender und Empfänger genutzt werden kann. Da die Meldevorgangs-Id (NotificationBundleId) durch das DEMIS-Backend gesetzt wird, erhält der Melder sie als Bestandteil der Melde-Response (strukturiert und als Bestandteil der PDF-Quittung) zurück geliefert.

Repräsentation der Meldevorgangs-Id

Repräsentation der Meldevorgangs-Id (NotificationBundleId) als Bundle.identifier: Wichtig: Da der Meldevorgangs-Id (NotificationBundleId) eine überaus wichtige Rolle im System zufällt und ihre Eindeutigkeit zwingend gewährleistet sein muss, wird der durch das meldende System gesetzte Identifier durch das DEMIS-Backend überschrieben! Der neu gesetzte Identifier wird als Bestandteil der Response-Nachricht dem sendenden System bekannt gegeben. Er soll zu Kommunikationzwecken zwischen Melder und Empfänger einsehbar abgelegt werden. Obwohl der Identifier durch das DEMIS-Backend gesetzt wird, muss das sendende System dennoch einen entsprechenden Wert generieren und übermitteln. Die Ursache hierfür liegt in den Basisanforderungen des zugrundeliegenden FHIR-Standards begründet, der für FHIR-Dokumente das Setzen eines entsprechenden Identifiers verpflichtend vorsieht.Bildungsvorschrift für die Meldevorgangs-Id:

• Als system MUSS "https://demis.rki.de/fhir/NamingSystem/NotificationBundleId" verwendet werden.
• Als value MUSS für jede Nachricht (Meldevorgang) eine neue Random-UUID (v4) gemäß RFC4122 gebildet werden.

Meldung

Eine Meldung (M) enthält meldepflichtige Informationen zu einem konkreten Fall (z.B. Erregernachweis CVDP für Person ABC durch Labor XYZ). Meldungen werden grundsätzlich eingebettet in Meldevorgängen (s.o.) transportiert. Eine logisch zusammengehörige Meldung (z.B. Initialmeldung + Ergänzungsmeldung, Initialmeldung + Korrekturmeldung) kann sich dabei über mehrere Meldevorgänge verteilen: Aus fachlicher Sicht wäre dann die Ergänzungsmeldung sozusagen eine neue Version der Initialmeldung.Meldungen werden innerhalb des DEMIS-Informationsmodells als profilierte FHIR-Composition-Ressourcen (vgl. z.B. Erregernachweismeldung oder Erkrankungsmeldung) abgebildet. Meldungen können eindeutig über die sogenannte Meldungs-Id (NotificationId) identifiziert werden, welche durch den Melder nach einem definierten Schema (s.u.) generiert werden muss. Ergänzungsmeldungen, Korrekturmeldungen usw. müssen jeweils die Meldungs-Id (NotificationId) der Initialmeldung tragen, um eine Zusammenführung der Inhalte in den verarbeitenden Fachverfahren im Gesundheitsamt zu ermöglichen. Dabei muss jedoch berücksichtigt werden, dass Meldungen verschiedener Melder (Primärlabor, Sekundärlabor) niemals die gleiche Meldungs-Id (NotificationId) tragen dürfen, auch wenn sie sich auf den gleichen Fall beziehen. Für diese Zwecke wir eine Verweis auf die Meldungs-Id der Initialmeldung gemacht (Abschnitt Verweis auf Meldungen anderer Melder, s.u.) Ähnlich wie die Meldevorgangs-Id wird auch die Meldungs-Id als Bestandteil der PDF-Quittung an den Melder zurück geliefert.

Repräsentation der Meldungs-Id

Repräsentation der Meldungs-Id (NotificationId) als Composition.identifier: Hinweis: Sämtliche durch ein Primärlabor gesendeten Ergänzungs- und/oder Korrekturmeldungen zu einem Fall tragen grundsätzlich dieselbe Meldungs-Id (NotifciationId) wie die Initialmeldung. Sie wird in allen Fällen über das Element Composition.identifier dargestellt. Gesonderte Regelungen gelten für den Fall, dass ein Sekundärlabor sich auf die Meldung des jeweiligen Primärlabors beziehen und diese ggf. ergänzen möchte (vgl. "Verweis auf Meldungen anderer Melder").Bildungsvorschrift für die Meldungs-Id

• Als system MUSS "https://demis.rki.de/fhir/NamingSystem/NotificationId" verwendet werden.

• Der value MUSS eine durch das System des Melders generierte UUID sein, die gemäß einer der beiden im Folgenden beschriebenen Varianten gebildet wird:

  Variante 1 - Bildung einer Random-UUID (v4) gemäß RFC4122

  Sendende Systeme KÖNNEN für die Darstellung der Meldungs-Id (NotificationId) für jeden Fall/Auftrag Random-UUIDs (v4) gemäß RFC4122 in eigener Verantwortung bilden. Um sicherzustellen, dass Ergänzungs- und Korrekturmeldungen zum entsprechenden Fall/Auftrag dieselbe Meldungs-Id (NotificationId) tragen, MÜSSEN die entsprechende Systeme intern sicherstellen, dass die generierte Id dauerhaft mit dem Fall/Auftrag assoziiert bleibt. Dies macht u.U. komplexere Anpassungen an den jeweiligen Systemen bzw. deren Datenmodell erforderlich.

  Variante 2 - Bildung einer namensbasierten UUID (v5) gemäß RFC4122 (SHA1-basiert)

  Sendende Systeme KÖNNEN für die Darstellung der Meldungs-Id (NotificationId) für jeden Fall/Auftrag namensbasierte UUIDs (v5) gemäß RFC4122 (SHA1-basiert) in eigener Verantwortung bilden. In diesem Zusammenhang MUSS durch die Implementierung sichergestellt werden, dass die in die UUID-Generierung einfließenden Parameter so gewählt werden, dass sowohl für unterschiedliche Fälle/Aufträge als auch für unterschiedliche Melder niemals dieselben UUIDs generiert werden. Folgendes Verfahren KANN in diesem Zusammenhang zum Einsatz kommen:

  • Für jedes meldende System MUSS einmalig eine individuelle Namespace UUID als Random-UUID (v4) gemäß RFC4122 gebildet werden (z.B. "db5da554-9bb0-4393-9ee3-4866cad38c1e" → Bitte diese Namespace UUID NICHT nutzen. Sie ist lediglich ein Beispiel). Die einmalig generierte Namespace UUID fließt fortan dauerhaft in die Generierung der namensbasierten UUID (v5) gemäß RFC4122 (SHA1-basiert) ein und stellt damit sicher, dass andere meldende Systeme keine identischen UUIDs bilden werden.
  • Für jedes meldende System MÜSSEN neben der Namespace UUID weitere Eingabeparameter definiert werden, die sicherstellen, dass die generierte UUID in Bezug auf den Fall/Auftrag DAUERHAFT eindeutig bleibt. Dies kann beispielsweise eine sinnvolle Konkatenierung der DEMIS Labor ID, der Jahreszahl und einer melderspezifischen Proben-/Auftragsnummer sein (z.B. "LAB12345_2021-007023"). Bei der Auswahl der jeweiligen Parameter sind insbesondere Situationen geschickt zu adressieren, in denen sich verwendete Parameter wiederholen könnten (z.B. Auftragsnummern beginnen jedes Jahr bei '00000').
  • Bildung der namensbasierte UUIDs (v5) gemäß RFC4122 (SHA1-basiert) unter Nutzung der Namespace UUID und der übrigen Eingabeparameter:
    • UUIDv5.nameUUIDFromNsAndString("db5da554-9bb0-4393-9ee3-4866cad38c1e", "LAB12345_2021-007023") → c13cd356-f147-5901-859d-31e6b2772465

Die zweite Variante hat den Vorteil, dass das meldende System die generierte UUID nicht dauerhaft mit dem Fall/Auftrag assoziieren muss, da aus den bereits verwalteten Angaben zu einem Fall/Auftrag dieselbe Meldungs-Id jederzeit neu berechnet werden kann.Wichtig!: Die Gewährleistung der Eindeutigkeit der Meldungs-Id (NotificationId) für einen konkreten Fall/Auftrag ist ESSENTIELL wichtig für die empfangenden Gesundheitsämter, da insbesondere über diesen Mechanismus eine (teil)automatisierte Zusammenführung von Initial-, Ergänzungs- und Korrekturmeldungen leicht ermöglicht werden kann. Werden dieselben Meldungs-Ids (NotificationIds) jedoch für unterschiedliche Fälle/Aufträge verwendet, kann es u.U. zu größeren Verwerfungen in den Fachverfahren der Gesundheitsämtern kommen, da potentiell nicht zusammengehörige Meldungen einander zugeordnet werden. Bitte halten Sie sich daher zwingend an die formulierten Anforderungen!

Verweis auf Meldungen anderer Melder

Es existieren Szenarien (beschrieben in den meldungsspezifischen Pakten), in denen verschiedene Melder (z.B. Primärlabor + Sekundärlabor, Arzt + Labor), Meldungen an DEMIS versenden, die sich für alle Akteure erkennbar auf den selben Fall beziehen. Um eine automatisierte Zuordenbarkeit dieser Meldungen bei den empfangenden Gesundheitsämtern sicherstellen zu können, ist es möglich, innerhalb einer Meldung M2 des zweiten Melders auf eine Meldung M1 des ersten Melders zu verweisen. Dies können zum Beispiel Meldungen aus dem Sekundärlabor mit Verweis auf Meldung aus dem Primärlabor sein oder Meldungen des Arztes mit Verweis auf Meldungen aus dem Labor. Verweise auf Meldungen anderer Melder, die sich auf den selben Fall beziehen MÜSSEN dabei im Composition.relatesTo Element der jeweiligen Ressource entsprechend des im Folgenden dargestellten Schemas eingebettet werden. Der verwendete Identifier ist dabei die Meldungs-Id (NotificationId) der Meldung auf welche verwiesen wird. Das Element Composition.relatesTo darf nicht die selbe Meldungs-Id enthalten wie das Element Composition.identifier im selben Meldevorgang, also der Identfier auf sich selbst verweisen.Verweise auf Meldungen anderer Melder, die sich auf den selben Fall beziehen: Voraussetzung für die Einbettung des entsprechenden Verweises in die Meldung ist, dass das Primärlabor dem Sekundärlabor die entsprechende Meldungs-Id im Rahmen der Auftragserteilung übermittelt hat. Wie und auf welchem Weg dies erfolgt, liegt außerhalb der Regelungshoheit von DEMIS. Denkbar ist hier beispielsweise die Übermittlung der Meldungs-Id vom Primär- zum Sekundärlabor als Bestandteil des Probenbegleitscheins. Sofern der Datenaustausch zwischen Primär- und Sekundärlabor noch nicht vollständig digitalisiert ist, sollten jedoch Mechanismen vorgesehen werden, die Sicherstellen, dass der entsprechende Identifier nicht "abgetippt" werden muss. Hier bietet sich - sofern papierbasierte Begleitscheine zum Einsatz kommen - u.U. eine Darstellung als QR-Code o.ä. an. Das DEMIS Backend stellt mit der PDF-Quittung eine zusätzliche Seite zur Verfügung, auf der die nichtnamentlichen Personendaten und die Meldungs-Id als QR Code abgebildet sind.Wichtig: Unabhängig von der Verwendung des Composition.relatesTo Elements MUSS das meldende Sekundärlabor dennoch eine eigene Meldungs-Id zum jeweiligen Fall/Auftrag erzeugen und in Composition.identifier einbetten.Die in diesem Abschnitt getroffenen Aussagen beziehen sich ausschließlich auf die Referenzierung von Meldungen ANDERER Melder. Eine Nutzung von Composition.relatesTo ist für eigene Ergänzungsmeldungen NICHT zielführend, da hier bereits die Zusammenführung der Inhalte über Composition.identifier (s.o.) erfolgt.