Ressource oder Kapitel im IG | Referenz | Art des Kommentars | kommentierter Text bzw. kommentiertes Element | Grund der Kommentierung | Änderungsvorschlag | Organisation/Person |
---|---|---|---|---|---|---|
Specimen.collection.bodysite.coding -> binding | https://simplifier.net/rki.demis.ars/abnahmeortsnomed | generell | Mischung aus body structure, morphologic abnormality, physical object. Im MIO Laborbefund differenzierter umgesetzt, es gibt verschiedene Elemente bei Entnahmeort: Körperstruktur (Körperstelle; Lateralität; Lokalisation; Morphologie) und außerkörperliche Quelle. | Ggf. macht eine differenziertere Darstellung und Aufteilung in die vier Bereiche an dieser Stelle für ARS mehr Sinn, auch aus Kompatibilitätsgründen. | Team MIO Laborbefund, mio42 GmbH | |
Valueset: AntwortSemiquantitativeErregerergebnisseSNOMED | https://simplifier.net/rki.demis.ars/antwortsemiquantitativeergebnissesnomed | generell | Zum MIO Laborbefund wurde dieser Begriff "semiquantitativ" kontrovers diskutiert. Zusammen mit den Laborfachexperten wurde wurde die Valueset-Bezeichnung wie folgt abgestimmt: "Qualitative Mengenangabe" (example Binding) | Dieses Thema wurde auch schon bei der MII-Kommentierung besprochen. Vorschlag: Keine Verwendung des Begriffs "semiquantitativ" | Team MIO Laborbefund, mio42 GmbH | |
ValueSet: AntwortMreSNOMED | https://simplifier.net/rki.demis.ars/antwortmresnomed | generell | Verwendung ist fachlich und inhaltlich nicht ganz klar. Und worfür stehen die Codes 2MRGN, 3MRGN, 4MRGN? | Weitere Erläuterung möglich? | Team MIO Laborbefund, mio42 GmbH | |
ValueSet 'MaterialSNOMED' | https://simplifier.net/rki.demis.ars/materialsnomed | generell | In diesem Valueset sind nicht nur Probenmaterialien enthalten sondern auch Probenentnahmemethoden. | Fachlich gesehen macht es Sinn, die Probenmaterialien und Probenentnamemethoden voneinander zu trennen. (Im MIO Labrbefund sind diese Angaben getrennt voneinander möglich.) | Team MIO Laborbefund, mio42 GmbH | |
Observation.extension:triggeredBy | https://simplifier.net/rki.demis.ars/observation | technisch | Warum wird nicht die Backport Extension von HL7 verwendet? | Bei HL7 Europe Laboratory Report wird diese Extension genutzt Backport Extension von Hl7 Europe: http://hl7.org/fhir/5.0/StructureDefinition/extension-Observation.triggeredBy | Team MIO Laborbefund, mio42 GmbH | |
Observation.specimen | https://simplifier.net/rki.demis.ars/observation | technisch | Warum ist dieses Element verpflichtend? | Im MIO Laborbefund und HL7 Europe Laboratory Report: Observation.specimen 0...1 | Team MIO Laborbefund, mio42 GmbH | |
Specimen.accessionIdentifier | https://simplifier.net/rki.demis.ars/specimen | technisch | Warum wird hier der accessionIdentifier verwendet? | Im MIO Laborbefund wird identifier verwendet | Team MIO Laborbefund, mio42 GmbH | |
Specimen.type | https://simplifier.net/rki.demis.ars/specimen | technisch | Warum ist Specimen.type verpflichtend? | Im MIO Laborbefund und HL7 Europe Laboratory Report Specimen.type: 0...1 | Team MIO Laborbefund, mio42 GmbH | |
Organization.identifier, Organization.type, Organization.address | https://simplifier.net/rki.demis.ars/hospital | technisch | Warum sind diese Elemente verpflichtend? | Im MIO Laborbefund sind diese Element auf 0...* | Team MIO Laborbefund, mio42 GmbH | |
Device.manufacturer, Device.type | https://simplifier.net/rki.demis.ars/software | technisch | Warum sind diese Elemente verpflichtend? | Im MIO Laborbefund Device.manufacturer: nicht vorhanden Device.type: 0...1 | Team MIO Laborbefund, mio42 GmbH | |
Patient.gender | https://simplifier.net/rki.demis.ars/patient | technisch | Warum ist Patient.gender verpflichtend? | Im MIO Laborbefund und HL7 Europe Laboratory Report Patient.gender: 0...1 | Team MIO Laborbefund, mio42 GmbH | |
Alle Profilierungen, die meta.profil mit einer fixed Value belegen | z.B.: https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Bundle?version=1.0.0.alpha.1 | technisch | meta.profile | meta.profile sollte nicht constrained werden. Es sollte ausreichen, dass eine Instanz die Regeln eines Profils erfüllt, ohne dies explizit deklarieren zu müssen. Die Deklaration von meta.profile hat keine semantische Bedeutung und sollte auch niemals dazu verwendet zu werden, Semantik zu transportieren. Instanzen, die ohne eine Deklaration gegen ein Profil validieren, sollten genauso behandelt werden wie Instanzen, die mit Deklaration validieren. Ebenso sollte die Deklaration eines Profils niemals dazu führen, dass die Validierung übergangen wird. Die Konformität zu einem Profil muss trotz Deklaration stets überprüft werden, sofern die Konformität zu diesem Profil für das validierende System von Belang ist. Es sollte NIEMALS verhindert werden, dass meta.profile zusätzliche Werte enthalten kann. Begründung: Es muss immer davon ausgegangen werden, dass einzelne Systeme mehrere Spezifikationen gleichzeitig implementieren und deren Instanzen daher Konformität zu mehreren Profilen deklarieren müssen. In Zukunft kann es erforderlich sein, über meta.profile auch Auskunft über die FHIR-Version, auf der Instanz basiert, zu kommunizieren. Quelle: https://simplifier.net/guide/best-practice-bei-der-implementierung-und-spezifizierung-mit-hl7/%C3%9Cbersicht/Spezifikation/Profilierung?version=1.0.0 | Projektteam Data der gematik | |
Labortestung | https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Labortestung?version=1.0.0.alpha.1 | technisch | category | Um Kompatibel zur ISiKLaboruntersuchung (https://simplifier.net/isik-labor-v4/isiklaboruntersuchung) zu sein, sollte die category mit angegeben werden. | Projektteam Data der gematik | |
Labortestung | https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Labortestung?version=1.0.0.alpha.1 | technisch | code | Um Kompatibel zur ISiKLaboruntersuchung (https://simplifier.net/isik-labor-v4/isiklaboruntersuchung) zu sein, sollte loinc und snomed im code angegeben werden können | Projektteam Data der gematik | |
Station | https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Station?version=1.0.0.alpha.1 | technisch | physicalType | Um kompatibel zu den Pflichtangaben der ISiKStandort Profilierung zu sein, sollte physicalType zugelassen werden: https://simplifier.net/isik-basis-v4/isikstandort | Projektteam Data der gematik | |
Krankenhausstandort | https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Krankenhausstandort?version=1.0.0.alpha.1 | technisch | identifier:HauptIk | Damit bei der IK eine Kompatibilität zur ISiKOrganization (https://simplifier.net/isik-basis-v4/isikorganisation) gegeben ist, bitte das Identifierprofil aus dem de Basis für die IK nutzen https://simplifier.net/packages/de.basisprofil.r4/1.5.0/files/2461153 | Projektteam Data der gematik | |
Alle Profile auf Basis Organization | z.B.: https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Krankenhausstandort?version=1.0.0.alpha.1 | technisch | type | In ISiK Organization Profilen von ISiK werden im type bspw. Fab301 Code und IHE XDS HealthcareFacilityTypeCode angegeben. Durch die Einschränkung auf ausschließlich einen durch DEMIS definierten Type, ist eine ISiK Organization nicht wiederverwendbar und kann so nicht für die DEMIS Meldung wiederverwendet werden. | Projektteam Data der gematik | |
Alle Profilierungen, die meta.profil mit einer fixed Value belegen | z.B.: https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Bundle?version=1.0.0.alpha.1 | technisch | meta.profile | meta.profile sollte nicht constrained werden. Es sollte ausreichen, dass eine Instanz die Regeln eines Profils erfüllt, ohne dies explizit deklarieren zu müssen. Die Deklaration von meta.profile hat keine semantische Bedeutung und sollte auch niemals dazu verwendet zu werden, Semantik zu transportieren. Instanzen, die ohne eine Deklaration gegen ein Profil validieren, sollten genauso behandelt werden wie Instanzen, die mit Deklaration validieren. Ebenso sollte die Deklaration eines Profils niemals dazu führen, dass die Validierung übergangen wird. Die Konformität zu einem Profil muss trotz Deklaration stets überprüft werden, sofern die Konformität zu diesem Profil für das validierende System von Belang ist. Es sollte NIEMALS verhindert werden, dass meta.profile zusätzliche Werte enthalten kann. Begründung: Es muss immer davon ausgegangen werden, dass einzelne Systeme mehrere Spezifikationen gleichzeitig implementieren und deren Instanzen daher Konformität zu mehreren Profilen deklarieren müssen. In Zukunft kann es erforderlich sein, über meta.profile auch Auskunft über die FHIR-Version, auf der Instanz basiert, zu kommunizieren. Quelle: https://simplifier.net/guide/best-practice-bei-der-implementierung-und-spezifizierung-mit-hl7/%C3%9Cbersicht/Spezifikation/Profilierung?version=1.0.0 | HL7 Deutschland, TC FHIR | |
Terminologien | https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Composition?version=1.0.0.alpha.1 | generell | Composition.type und Composition.section.code | Warum wird in der Composition im type Snomed und im section code loinc verwendet? Beide identifizieren die Instanz als Laborbericht. Im Sinne der Durchsuchbarkeit von Ressourcen (da es nur einen Default Suchparameter auf Composition.type gibt), empfehle ich die Nutzung von Slicing und der Angabe beider Codes im Type. | HL7 Deutschland, TC FHIR | |
Laborbericht | https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Laborbericht?version=1.0.0.alpha.1 | technisch | category | In der MII und auch in allen internationalen Profilierungen von Laborberichten wird in der Category mit LOINC und einem V2 CodeSystem angegeben, dass es sich um einen Laborbefund handelt. Im Sinne der Kompatibilität empfehle ich, das ebenfalls zu übernehmen. | HL7 Deutschland, TC FHIR | |
(Siehe auch: https://www.medizininformatik-initiative.de/Kerndatensatz/Modul_Laborbefund/DiagnosticReport.html) | HL7 Deutschland, TC FHIR | |||||
Laborbericht | https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Laborbericht?version=1.0.0.alpha.1 | technisch | effective oder issued | Das Entfernen eines Datums finde ich sehr gefährlich, weil es die Möglichkeit zur Einordnung des Laborbefundes in einen zeitlichen Kontext komplett entfernt. | HL7 Deutschland, TC FHIR | |
TriggeredBy | https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/Extensions/TriggeredBy?version=1.0.0.alpha.1 | technisch | Canonical | Backport Extensions werden anders erstellt: https://hl7.org/fhir/versions.html#extensions Die Canonical ist in dem Fall fest vorgegeben. | HL7 Deutschland, TC FHIR | |
Labortestung | https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Labortestung?version=1.0.0.alpha.1 | technisch | category | Siehe Punkt 6, genauso bei der Observation | HL7 Deutschland, TC FHIR | |
Station | https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Station?version=1.0.0.alpha.1 | technisch | physicalType | In der Encounter.location Referenz auf die Station ist ein physicalType zugelassen, dann sollte er auch in der Instanz selber vorhanden sein | HL7 Deutschland, TC FHIR | |
Krankenhausstandort | https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Krankenhausstandort?version=1.0.0.alpha.1 | technisch | identifier:HauptIk | Bitte das Identifierprofil aus dem de Basis für die IK nutzen https://simplifier.net/packages/de.basisprofil.r4/1.5.0/files/2461153 | HL7 Deutschland, TC FHIR | |
Alle Profile auf Basis Organization | z.B.: https://simplifier.net/guide/ars-implementierungsleitfaden/Home/Ressourcen/StructureDefinitions/Krankenhausstandort?version=1.0.0.alpha.1 | technisch | type | Durch die Setzung von Kardinalitäten geht die Möglichkeit verloren, andere Typen wie bspw. Fab301 Code o.ä. anzugeben, wodurch eine Inkompatibilität zu ISiK, MII, MIOs usw. entsteht. | HL7 Deutschland, TC FHIR | |
Im Rahmen der Semantik sollten, wo immer möglich, bestehende bzw. kompatible Value-Sets etc. (§7 Meldung, Laborbefund ePA) verwendet werden. Das gleiche gilt für relevante allgemeingültige Ressourcen (Coverage). | epiNET AG | |||||
Labortestung | https://simplifier.net/rki.demis.ars/observation | generell | Über Observation können die Ergebnisse von Isolaten, Phänotyp oder Genotyp abgebildet werden. Es wäre für die Verarbeitung der Observation sinnvoll dieser ein Attribut hinzuzufügen, welches diese oben aufgeführten Gruppen klassifiziert. Ggf. sind weitere Gruppen in diesen Zusammenhang sinnvoll. | epiNET AG | ||
Labortestung | https://simplifier.net/rki.demis.ars/observation | generell | Die Ergebnisse zum Phänotyp eines Isolats sind in der Regel eine umfassende Liste von Einzeltestungen, die in direktem Zusammenhang zum Isolat stehen. Sinnvoll ist es diese zu klammern und in Bezug zum relevanten Isolat zu setzen. | epiNET AG | ||
Labortestung | https://simplifier.net/rki.demis.ars/observation | generell | Ergebnisse zum Genotyp eines Isolats können ein oder mehrere Attribute liefern, die in direktem Zusammenhang zum Isolat stehen. Sinnvoll ist diese zu klammern und in Bezug zum relevanten Isolat zu setzen. | epiNET AG |
DEMIS Wissensdatenbank
Overview
Content Tools