Erregernachweismeldung (nichtnamentlich)

https://demis.rki.de/fhir/StructureDefinition/NotificationLaboratoryNotByName

Die Erregernachweismeldung (nichtnamentlich) definiert die Meldeinhalte, die von Laboren in der nichtnamentlichen Meldung gemäß §7 Absatz 4 übermittelt werden müssen.

Zur Übermittlung von Befunddaten soll in der Erregernachweismeldung (nichtnamentlich) der dem Meldetatbestand entsprechende Laborbericht referenziert werden.

Bildung und Anwendung des Identifiers der Meldung (Meldungs-Id) [Auszug aus den Grundlagen des Meldungs-Lifecyclemanagements]:

  • 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) 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. Ä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 (NotificationId) als Composition.identifier:

    <Composition xmlns="http://hl7.org/fhir">
...
<identifier>
    <system value="https://demis.rki.de/fhir/NamingSystem/NotificationId"/>
    <value value="c13cd356-f147-5901-859d-31e6b2772465"/>
</identifier>
...
</Composition>

    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 (s.u.), in denen verschiedene Melder (z.B. Primärlabor + Sekundärlabor), 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 auf eine Meldung M1 eines anderen Melders zu verweisen. 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.

    Verweise auf Meldungen anderer Melder, die sich auf den selben Fall beziehen:

    <Composition xmlns="http://hl7.org/fhir">
...
<relatesTo>
    <code value="appends"/>
    <targetReference>
    <type value="Composition"/>
    <identifier>
        <system value="https://demis.rki.de/fhir/NamingSystem/NotificationId"/>
        <value value="c13cd356-f147-5901-859d-31e6b2772465"/>
    </identifier>
    </targetReference>
</relatesTo>
...
</Composition>

    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.

    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.

profileS1..1Fixed Value
contained..0
codingS1..1Pattern
codingS1..1Pattern
referenceS1..
author
valueI
codingS1..1Pattern
referenceS1..
sectionsee (section)