Im Rahmen der Kommentarauflösung wurde umfangreich über die Kompatibilität zu nationalen und internationalen FHIR-Entwicklungen diskutiert. Dabei wurde deutlich, dass Aufgrund der unterschiedlichen Anforderungen an die Profile von z.B. DEMIS, ARS, mioLaborbefund, ISIK und HL7 HealthReport eine durchgehende Einheitlichkeit der Profilierung nicht möglich ist. So gibt z.B. das Infektionsschutzgesetz (IfSG) die zu meldenden Variablen eindeutig vor und verbietet implizit die Meldung von anderen Informationen. Die Erregernachweismeldung stellt keine Befundung an einen Arzt dar und bildet daher andere Inhalte ab. Ein weiteres Beispiel ist der Patientenbezug, der je nach System notwendig, erwünscht oder verboten ist. Im Sinne der Datensparsamkeit ist eine Gesetzesänderung zu Gunsten weiterer, fachlich unnötiger Angaben nur zu Zwecken der Einheitlichkeit der Profilierung nicht sinnvoll.
Im Rahmen der Diskussion wurde deutlich, dass eine einheitliche Semantik entscheidend für die Kompatibilität ist, um widersprüchliche oder zusätzliche Programmierungen zu verhindern und damit Aufwand und Kosten gering zu halten. Bezeichnungen von z.B. Organisationstypen (z.B.ISIK) oder die Semantik zur Abbildung von Erregernachweisen mittels LOINC und SNOMED CT muss für alle Anwendungen im deutschen Raum einheitlich bzw. nachnutzbar sein. Wir haben daher bei der Auflösung der Kommentare und der nachfolgenden Profilanpassung berücksichtigt, dass DEMIS-Profile inkl. Profile weiterer angebundener Surveillance-Systeme wie z.B. ARS, datensparsam sind und unnötige Angaben gestrichen. Die Semantik von LOINC und SNOMED CT für die mikrobiologischen Ergebnisse wird in Kooperation mit mio42 und MII erarbeitet. Wir streben an, dass mit den bestehenden Codes die zu meldenden Inhalte vollständig übermittelt werden können. Das Ziel ist, dass Hersteller von Informationssystemen vorliegende Daten einmalig auf die FHIR Kodiersysteme und Terminologien mappen und damit alle in Deutschland zur Anwendung kommenden FHIR-Profile fehlerfrei befüllen können.
In Konsequenz bedeutet das für unsere Profilierung, dass wir strikte Referenzen und constraints auf meta.profile erhalten und für das jeweilige System nicht benötigte Angaben streichen. Wenn eine Instanz unserem Profil genügt kann unsere Canonical auch in Meta.profile aufgenommen werden. Das DEMIS laboratoryPackage liegt somit mit einer spezifische FHIR-Profilierung vor, die als individuelle Schnittstellen zu entwickeln ist, aber abwärtskompatibel zum MIO Laborbefund sein soll.
Eine Ausnahme stellte das DEMIS commonPackage dar. Dieses wird innerhalb der verschiedenen DEMIS-Surveillance Systeme als Basis-Paket verwendet. Um hier eine größere Flexibilität zu erhalten, sind hier Angaben, die für die Meldungen nach §§ 6 und 7 IfSG nicht benötigt, aber auch nicht verboten werden müssen nicht gestrichen worden.
| Profil/Ressourcen | Änderung | Eingegangener Kommentar | Begründung/Kommentar | |
|---|---|---|---|---|
| Erregernachweismeldung (Composition) | Composition: Referenz auf DiagnosticReport fehlt identifier in DEMIS verpflichtend, in MIO Labor nicht vorgesehen und in HL7 EU nicht angepasst (offen) type.coding: vorgegebenes Pattern abweichend von HL7 EU und MIO Labor Angleichung der Sections and HL7 EU wäre zu überdenken | Der Composition.identifier ist die ID der Meldung, mit der alle zusammenhängenden Meldevorgänge (Bundles) zusammengeführt werden können. Eine Meldung nach § 7 IfSG kann auch mehreren Meldevprgängen bestehen. Dies sind z.B. Untersuchungsergebnisse die über mehrere Tage ermittelt werden und jeweils innerhalb von 24h entsprechend der Meldepflicht, gemeldet werden. Es handelt sich bei der Erregernachweismeldung nicht um einen vollständigen Laborbefund, sondern um eine Meldung nach §7 IfSG. Daher verwenden wir für Composition.type.coding den LOINC "code": "34782-3", "display": "Infectious disease Note" | ||
Composition.category | gestrichen | BREAKING | In DEMIS verpflichtende category mit Pattern auf LOINC Code, in HL7 EU auf studyType und specialty spezifiziert, in MIO Labor nicht vorgesehen | Anpassung zum mioLaborbefund |
| Meldetatbestand (NotificationCategory) | Änderung der status-Angabe im Codesystem NotificationCategory zu: <property> <code value="inactive" /> <valueBoolean value="false" /> | properties: Für die Abbildung des Nutzungsstatus gibt es bereits von FHIR eine im Core definierte property | ||
| LaboratoryReport (DiagnosticReport) | DiagnosticReport: Referenz auf Composition fehlt category wurde ausgeschlossen → bitte HL7 EU category nachziehen performer wurde ausgeschlossen → in MIO Labor verpflichtend, in HL7 EU offen specimen wurde ausgeschlossen → Das soll nicht gemacht werden, specimen sollen wie in HL7 EU und MIO Labor bitte auch in DiagnosticReport gesammelt aufgeführt werden, optionales Feld conclusionCode ist in DEMIS verpflichtend, in MIO Laborbefund nicht vorgesehen und in HL7 EU nicht angepasst (offen) presentedForm in DEMIS ausgeschlossen: bitte zulassen, in MIO Laborbefund von Laborexperten gefordert für PDF-Anhang des GesamtbefundesDurch diverse Streichungen von Elementen (0..0) ist die Kompatibilität zu ISiK, MII, MIO Laborbefung u.ä. nicht gegeben | Wie im Vorwort zur Kommentarauflösung geschrieben, werden im IfSG die zu meldenden Variablen eindeutig vorgegeben und damit implizit die Meldung von anderen Informationen verboten. Wir müssen daher bestimmte Angaben in den Ressourcen ausschließen. Wir werden daher durchgehend in der Erregernachweismeldung nur benötigte Angaben zulassen. Dies schließt auf den Ausschluss von Anhängen ein, da hier nicht meldepflichtige Informationen übermittelt werden könnten. | ||
DiagnosticReport.conclusionCode | Slice auf conclusion.code 1...1 Unordered, Closed, by coding.system(Value) | Auszug aus den Best Practices von HL7 Deutschland e.V.: Die Begrenzung der maximalen Kardinalität von Elementen sollte vermieden werden. Constraints auf wiederholbaren Elementen sollten durch ein offenes Slicing definiert und spezifiziert werden. | Auch hier steht die gesetzliche Anwendung im Vordergrund. der DiagnosticReport.conclusion.code bildet in der Erregernachweismeldung den Gesamtbefund ab, also das Ergebnis liegt ein meldepflichtiger Tatbestand vor oder nicht. Die Öffnung zum jetzigen Zeitpunkt für weitere Angaben könnte zu Verwirrung bei den Empfängern führen. Wir haben aber ein slicing eingeführt, um offen für Weiterentwicklung zu sein. | |
| DiagnosticReport.code.coding.display | DiagnosticReport.code.coding.display auf 0..1 | code.coding.system und .code sind Fixed Values, der .display hat eine Min-Kardinalität von 1. Sollte in dem Fall dann nicht der Einfachheit halber der display auch fixed vorgegeben sein | ||
| DiagnosticReport.basedOn.identifier | https://demis.rki.de/fhir/NamingSystem/ServiceRequestId wurde entfernt DiagnosticReport.basedOn.identifier.system MS 1..1 | Es gibt hier (https://robert-koch-institut.github.io/DEMIS_FHIR-Profile_Vorabveroeffentlichung/rki.demis.laboratory/commenting/Home-resources-terminologies-namingsystems-guide-ServiceRequestId.html) ein Identifier System für Identifier eines Auftrags. Ich vermute, der soll unter Laborbericht.basedOn.identifier genutzt werden. Das geht aus dem Profil leider nicht hervor | ||
| DiagnosticReport.basedOn.reference | DiagnosticReport.basedOn.identifier.type | Kompatibilität zum MII DR ist nicht gegeben, da dort eine Referenz auf einen ServiceRequest erlaubt ist | Der ServiceRequest wird in der Erregernachweismeldung nicht benötigt. In Abstimmung mit HL7-Deutschland, wird DiagnosticReport.basedOn für die Angabe der internen Laborauftragsnummer verwendet, mit DiagnosticReport.basedOn.identifier.type | |
| ServiceRequestId (Identifier des Laborauftrags) | Beispiele wurden nachgetragen | Command 'tree' could not render: File was not found for 'https://demis.rki.de/fhir/NamingSystem/ServiceRequestId' Command 'xml' could not render: File was not found for ExampleResources/LaboratoryReportCVDP-example.xml | ||
| ServiceRequest | In HL7 EU und MIO Laborbefund ist der Grund der Beauftragung (eHN A.3 Order reason) in ServiceRequest.reasonReference untergebracht. Die eigentliche Beauftragung (eHN: A.2 Order information) ist in HL7 EU durch https://build.fhir.org/ig/hl7-eu/laboratory/StructureDefinition-ServiceRequest-eu-lab.html abgebildet. Empfänger steht implizit fest, aber ist nicht modelliert In DEMIS ist der ServiceRequest nicht profiliert | Die Erregernachweismeldung nach § 7 IfSG sieht die inhaltliche Angabe für die Beauftragung und den Grund der Beauftragung nicht vor. Es ist nur das Ergebnis meldepflichtig, wenn es sich um einen nach § 7 spezifizierten Erreger handelt. Daher wird der ServiceRequest nicht profiliert. Die Angabe des Empfängers der Meldung (Composition) wird durch das DEMIS Backend ermittelt und dem Melder im Rahmen der Meldungsquittung zurückgegeben (link auf Quittung) | ||
| PathogenDetection (Observation) | Ein Observation-Profil pro Erreger + entsprechendes Specimen Profil für Erreger Input: bei identifier untersuchungsID und GTIN stark gefordert in MIO Labor → vielleicht auch hier relevant category abweichend von HL7 EU → studyType und specialty slices in DEMIS nicht erlaubt Sowohl effective[x] als auch issued ausgeschlossen → effective[x| in HL7 EU und MIO Labor verpflichtend, issued in MIO Labor verpflichtend value verpflichtend und dataAbsentReason verpflichtend → für Use Case nachvollziehbar, aber abweichend component ausgeschlossen, welche für Attachments wie Bild-Anhänge nach HL7 EU benötigt wirdDurch diverse Streichungen von Elementen (0..0) ist die Kompatibilität zu ISiK, MII, MIO Laborbefung u.ä. nicht gegebenKonkretes Beispiel: Die MII, ISIK gibt die Kategorie einer Observation in loinc und mit einem hl7 CodeSystem an, so wie auch international vorgegeben. Das ist nicht mehr möglich in der DEMIS Version | |||
| Observation.status | Änderung des comment entsprechend der drei erlaubten Statusangaben: Der Status ist szenarienspezifisch folgendermaßen zu belegen: corrected - bei einer Korrekturmeldung; amended - bei einer Ergänzung; final - in allen anderen Fällen | Laut Comments des Elementes sind nur zwei Status erlaubt. Das gebundene ValueSet gibt aber die Möglichkeit, alle vier Status anzugeben.Auch wenn das Binding required ist, kann man dennoch einschränken, welche Codes genutzt werden dürfen. Das sollte auch passieren:When an element is bound to a required value set, derived profiles may state rules on which codes can be used, including removing codes from allowed use, but cannot specify new or additional codes for these elements. | ||
| Observation.referenceRange.typeObservation.referenceRange.appliesTo | Hier fehlt meiner Meinung nach ein MS, da die untergeordneten Elemente teilweise mit MS versehen sind... | Die Angabe von Observation.referenceRange.typeObservation.referenceRange.appliesTo ist nicht notwendig. Nur wenn diese angegebn wird, dann muss sie als "text" erfolgen. Daher haben wir uns hier entschieden, auf MS zu verzichten. | ||
| Observation.specimen | Die Verpflichtung zur referenzierung einer Probe hindert die Kompatibilität zu ISiK, MII und MIO Laborbefund usw.Außerdem zeigt die Praxis, dass Informationen zur Probe meist nicht erhoben und gespeichert werden. Hier empfehlen wir, ggf. stärker mit optionalen Informationen zu arbeiten. | Die Erfahrung aus 4 Jahren Erregernachweismeldung zeigt, dass immer Informationen zur Probe wie Probeneingangsdatum und Probenmaterial vorhanden sind. Zu jeden Untersuchungsergebnis gehört die Probe, die Grundlage für die Untersuchung war, daher wird in der Observation die Referenz auf die Probe gesetzt. | ||
Observation.code.coding | LaboratoryTest (required): Verpflichtende Angabe eines LOINC-Codes aus dem Meldetatbestandspezifischem ValueSet-LaboratoryTest | BREAKING | ||
Observation.code.coding.system | Angabe des systems als Pattern | |||
Observation.code.coding.version | Pflichtangabe (MS 1...1) | BREAKING | ||
Observation.value[x]:valueQuantity.value | Bei Verwendung von Observation.value[x]:valueQuantity ist "value" verpflichtend anzugeben (MS 1...1) | BREAKING | ||
Observation.value[x]:valueQuantity.comparator | Bei Verwendung von Observation.value[x]:valueQuantity soll ein Comparator angegeben werden können (MS 0...1) | |||
Observation.value[x]:valueQuantity.system | Bei Verwendung von Observation.value[x]:valueQuantity ist "system" verpflichtend als http://unitsofmeasure.org anzugeben (MS 1...1) | |||
Observation.value[x]:valueQuantity.code | Bei Verwendung von Observation.value[x]:valueQuantity ist "code" verpflichtend als UCUM Einheit anzugeben (MS 1...1) | |||
Observation.value[x]:valueCodeableConcept | Kann in Erregernachweismeldungen als SNOMED-CT oder LOINC angegeben werden | BREAKING | ||
Observation.value[x]:valueCodeableConcept.coding:codeableConceptSNOMED | ||||
Observation.value[x]:valueCodeableConcept.coding:codeableConceptLOINC | ||||
Observation.value[x]:valueCodeableConcept.coding.system | Bei Verwendung von Observation.value[x]:valueCodeableConcept ist die Angabe des system verpflichtend (MS 1...1) | |||
Observation.value[x]:valueCodeableConcept.coding.version | Bei Verwendung von Observation.value[x]:valueCodeableConcept ist die Angabe der versionverpflichtend (MS 1...1) | |||
Observation.value[x]:valueCodeableConcept.coding.code | Bei Verwendung von Observation.value[x]:valueCodeableConcept ist die Angabe des code verpflichtend (MS 1...1); Die Verwendung von Codes aus dem AnswerSet LOINC AnswerSet-LOINC (required) oder dem erregerspezifischen AnswerSetXYZP (required) ist verbindlich | |||
Observation.value[x]:valueRange | Es kann jetzt technisch ein Bereich als Ergebniswert angegeben werden. | |||
Observation.value[x]:valueRange.low | Bei Verwendung von Observation.value[x]:valueRange müssen der untere und obere Wert des ergebnisbereiches angegeben werden | |||
Observation.value[x]:valueRange.high | Bei Verwendung von Observation.value[x]:valueRange müssen der untere und obere Wert des ergebnisbereiches angegeben werden | |||
Observation.value[x]:valueRange.value | Bei Verwendung von Observation.value[x]:valueRange müssen die Werte als Zahl, mit einer UCUM Einheit angegeben werden | |||
Observation.value[x]:valueRange.system | Bei Verwendung von Observation.value[x]:valueRange müssen die Werte als Zahl, mit einer UCUM Einheit angegeben werden | |||
Observation.value[x]:valueRange.code | Bei Verwendung von Observation.value[x]:valueRange müssen die Werte als Zahl, mit einer UCUM Einheit angegeben werden | |||
Observation.value[x]:valueRatio | Es kann ein Quotient (z.B. Titer) als Ergebnis angegeben werden | |||
Observation.value[x]:valueRatio.numerator | Bei Verwendung von Observation.value[x]:Ratio müssen sowohl Zähler und Nenner (z.B. 1: 60) angegeben werden | |||
Observation.value[x]:valueRatio.denominator | Bei Verwendung von Observation.value[x]:Ratio müssen sowohl Zähler und Nenner (z.B. 1: 60) angegeben werden | |||
Observation.value[x]:valueRatio.value | Bei Verwendung von Observation.value[x]:Ratio müssen die Werte als Zahl, mit einer UCUM Einheit angegeben werden | |||
Observation.value[x]:valueRatio.system | Bei Verwendung von Observation.value[x]:Ratio müssen die Werte als Zahl, mit einer UCUM Einheit angegeben werden | |||
Observation.value[x]:valueRatio.code | Bei Verwendung von Observation.value[x]:Ratio müssen die Werte als Zahl, mit einer UCUM Einheit angegeben werden | |||
Observation.value[x]:valueString | Die Angabe des Ergebnisses als Freitext kann nur noch im Meldetatbestand WBKP erfolgen. | BREAKING | ||
Observation.interpretation.coding:interpretationHL7 | Die Angabe der Observation.interpretation kann sowohl als HL7 Code oder wie im mioLaborbefund als SNOMED Code angegeben werden. | |||
Observation.interpretation.coding:interpretationSNOMED | Die Angabe der Observation.interpretation kann sowohl als HL7 Code oder wie im mioLaborbefund als SNOMED Code angegeben werden. | |||
Observation.interpretation.coding:interpretationSNOMED.version | Bei Verwendung von Observation.interpretation.coding:interpretationSNOMED.code ist die Versionsangabe verbindlich. | |||
Observation.interpretation.coding:interpretationSNOMED.code | Bei Verwendung von Observation.interpretation.coding:interpretationSNOMED.code ist die Angabe eines Codes aus dem verbindlichen ValueSet Interpretation-SNOMED (required) notwendig. | |||
Observation.note | Es ist nur noch ein Hinweisfeld mit Freitextangaben für jede Observation erlaubt | BREAKING | ||
Observation.method | Die Angabe der Observation.method ist verpflichtend (MS 1...1) | BREAKING | ||
Observation.method.coding | Die Angabe der Methode muss als SNOMED-CT Code erfolgen. Das ValueSet Method (extensible) ist noch nicht verbindlich, da ein Wechsel von SNOMED_CT Procedure Codes zu qualifier values stattfindet und noch nicht alle Codes als qualifier values vorhanden sind. | |||
Observation.method.coding.version | Die Angabe der Version ist verpflichtend (MS 1...1) | |||
Observation.method.text | Ergänzende Hinweise oder die LIS-Angaben zur Methode können als Observation.method.text angegeben werden. | |||
Observation.referenceRange | Die Angabe von Referenzbereichen ist nun mit der Aufnahme von Observation.referenceRange möglich | |||
Observation.referenceRange.low | Bei Verwendung von Observation.referenceRange müssen der untere und obere Wert des Referenzbereiches angegeben werden. Es müssen die Werte als Zahl, mit einer UCUM Einheit angegeben werden | |||
Observation.referenceRange.high | Bei Verwendung von Observation.referenceRange müssen der untere und obere Wert des Referenzbereiches angegeben werden. Es müssen die Werte als Zahl, mit einer UCUM Einheit angegeben werden | |||
Observation.referenceRange.type | Die Angabe von Observation.referenceRange.type ist möglich. Bei einer Verwendung müssen system, versin und code verpflichtend angegeben werden. | |||
Observation.referenceRange.appliesTo | Die Angabe von Observation.referenceRange.appliesTo ist möglich. Bei einer Verwendung muss ein Freitext verpflichtend angegeben werden. | |||
IGS-/Transaktions-Id (TransactionId) | Beispiel wurde nachgetragen | Command 'xml' could not render: File was not found for ExampleResources/TransactionID-example.xml | ||
LOINCMethodToSNOMEDMethod: LOINC LP6132-7 ist äquivalent zu 127785005 | entfernt | Zufallsfund: Das klingt nicht richtig, bitte das Mapping einmal fachlich prüfen lassen! | ||
LOINCMethodToSNOMEDMethod:LP31266-7 und LP6115-2 mappen beide auf 359821004 | entfernt | Zufallsfund: Die Angabe der equivalence ist bei beiden Mappings equivalent. Es sieht falsch aus und sollte nochmal gegen das http://hl7.org/fhir/concept-map-equivalence CodeSystem abgeglichen werden. Generell scheint das bei einigen Codes nicht zu passen | ||
LOINCMaterialToSNOMEDMaterial: LP186026-3 mappt auf 708049000, 119361006, 122592007 | entfernt | Zufallsfund: Auch hier passt das equivalence Mapping nicht. Bitte generell überprüfen | ||
Deutsche Übersetzungen von LOINC: 41852-5 | LONG COMMON NAME: Mikroorganismus oder Erreger identifiziert in Probenmaterial | Die Übersetzung stimmt nicht mit der in LOINC angegebenen de-DE Übersetzung überein. Ich habe nicht alle überprüft, bin mir aber sicher, dass da mehr sind | Wir verwenden für LOINC nur offizielle Übersetzungen des BfArM, derzeit deDE15LinguisticVariant | |
Specimen | Eigenes VS für Specimen.type → Abstimmung dafür sinnvoll? Substance Profil gar nicht spezifiziert | Die Erregernachweismeldung nutzt erregerspezifische ValueSets-Material, um ein Mapping im LIS zu vereinfachen und Einschränkungen auf materialspezifische Meldetatbestände (z.B. Adenoviren; Meldepflicht nur für den direkten Nachweis im Konjunktivalabstrich) machen zu können. Die erregerspezifischen ValueSets können in regelmäßigen Abständen erweitert werden. Angaben zu einzelnen Reagienzien für die Durchführung von Laboruntersuchungen, sind für die Erregernachweismeldung nicht relevant | ||
Specimen.accessionIdentifier | Wenn die laboreigene Probennummer angegeben werden soll, dann unter Specimen.accessionIdentifier. | |||
Specimen.accessionIdentifier.system | Wenn Specimen.accessionIdentifier verwendet wird, dann müssen system und value angegeben werden (MS 1...1) | |||
Specimen.accessionIdentifier.value | Wenn Specimen.accessionIdentifier verwendet wird, dann müssen system und value angegeben werden (MS 1...1) | |||
Specimen.type | Die Angabe des Probenmaterials ans SNOMED-CT code wird verpflichtend | BREAKING | ||
Specimen.type.coding | Als Probenmaterial muss ein SNOMED-CT Code aus dem erregerspezifischen ValueSet verwendet werden | |||
Specimen.type.coding.version | Specimen.type.coding.version ist eine verpflichtende Angaben | BREAKING | ||
Specimen.collection | collection: In HL7 EU und MIO Labor bereits FHIR R5 Backport-Extension mit BodyStructure-Referenz → hier noch R4 Logik parent nicht auf DEMIS Specimen eingeschränkt → Warum nicht? | Die FHIR R5 Backport-Extension wurde geprüft. Die ressource "BodyStructure" hat aber zu viele Angabemöglichkeiten, die nicht meldepflcihtig sind, so dass fast alle Felder gestrichen werden müssen. Die Angabe des Abnahmeortes kann im Feld Specimen.collection.bodySite erfolgen | ||
Specimen.collection.collected[x]:collectedPeriod | Angabe einer Zeitperiode zur sammlung des Probenmaterials kann nun wie im mioLaborbefund angegeben werden (0...1) | |||
Specimen.collection.bodySite | Wird in Ihrem LI(M)S der Abnahmeort separat angegeben, so kann dieser unetr Specimen.collection.bodySite angegeben werden | |||
Specimen.collection.bodySite.coding | Wenn Specimen.collection.bodySite verwendet wird, so muss ein SNOMED-CT Code verwendet werden. Ein ValueSet wird derzeit noch nicht vorgegeben | |||
Specimen.collection.bodySite.coding.system | Specimen.collection.bodySite.coding.system; value und code sind verpflichtende Angaben | |||
Specimen.collection.bodySite.coding.value | Specimen.collection.bodySite.coding.system; value und code sind verpflichtende Angaben | |||
Specimen.collection.bodySite.coding.code | Specimen.collection.bodySite.coding.system; value und code sind verpflichtende Angaben | |||
Specimen.processing.extension:clusterID | Die Angabe einer clusterID dient in späteren Meldungen dazu, den Identifier zusammengehörige Genomsequenzdaten melden zu können | |||
Specimen.container | wurde gestrichen (0...0) | container.additive[x] weiterhin erlaubt, aber in HL7 EU ausgeschlossen container.extension:device fehlt für Referenz auf Container-Device, hier in HL7 EU ebenfalls bereits R5 Logik Backport | Im Sinne einer einheitlichen Profilierung, wurden für den Erregernachweis unnötige Felder gestrichen. Die Angaben für die Verpackung des Probenmaterials sind für die Meldepflicht nach § 7 IfSG nicht relevant | |
Specimen.condition | wurde gestrichen (0...0) | Im Sinne einer einheitlichen Profilierung, wurden für den Erregernachweis unnötige Felder gestrichen | ||
Specimen.note | Es kann nur noch eine Freitextfeld pro Specimenressource verwendet werden (0...1) | BREAKING |