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 | Change | Eingegangener Kommentar | Begründung/Kommentar |
|---|---|---|---|---|
| Alle StructureDefinition-Profile | Die Begrenzung der maximalen Kardinalität von Elementen sollte vermieden werden. Constraints auf wiederholbaren Elementen sollten durch ein offenes Slicing definiert und spezifiziert werden. Begründung: Werden maximale Kardinalitäten eingeschränkt, zwingt dies die Implementierer dazu, individuelle Schnittstellen zu entwickeln, die nicht benötigte Elemente gezielt entfernen, während hingegen das Ignorieren überflüssiger Informationen niemanden etwas kostet. Wird eine maximale Kardinalität auf 0 reduziert, so bedeutet dies, dass die Verwendung des Feldes explizit verboten ist. Instanzen, in denen diese Felder gefüllt sind, gelten als nicht valide. Dies sollte nur dann verwendet werden, wenn es die ausdrückliche Intention ist, ein Element zu verbieten, niemals um auszudrücken, dass ein Feld nicht relevant/nicht benötigt/nicht genutzt wird. Ausnahmen: Was aus Gründen der Interoperabilität technisch sinnvoll erscheint, ist nicht immer mit datenschutzrechtlichen Vorgaben übereinzubringen. Häufig sind Spezifizierer gezwungen, Elemente durch Constraints zu verbieten, weil die Übermittlung der darin enthaltenen Information in einem konkreten Kontext nicht gestattet ist. Irrelevante Informationen einfach auf Empfängerseite zu ignorieren genügt nicht dem Gebot der Datensparsamkeit! [...] Quelle: https://simplifier.net/guide/best-practice-bei-der-implementierung-und-spezifizierung-mit-hl7/%C3%9Cbersicht/Spezifikation/Profilierung?version=1.0.0 | Aufgrund der Einschränkungen des IfSG behalten wir die constraints bei. Dies hat zur Folge, dass für DEMIS-Meldungen eine separate Schnittstelle bedient werden muss. Daher haben wir auch überflüsige Informationen, die für die Meldungsinhalte nicht relevant sind gestrichen, um den Herstellern die Umsetzung zu erleichtern, da die Entscheidung, ob senden oder nicht, vorweggenommen wird. | ||
| 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 | Die Angabe von mehreren meta.profilen wurde geprüft. Derzeit ist eine positive Validierung bei der Angabe des spezifischen Profils und eines zusätzlichen Profils nicht möglich. Daher wurde die Einschränkung auf das spezifische Profil vorerst belassen. | ||
| ValueSets mit SNOMED-CT Codes, bzw. alle ValueSets | Folgende Anpassungen an ValueSets wurden gemacht: Einfügen von jurisdiction und contact Anpassung der Darstellung von Übersetzungen und deutschen Anzeigenamen | Hier wurden SNOMED CT Codes übersetzt. Wurde dies mit dem BfArM abgesprochen? Nur das BfArM hat das Recht, Codes aus SNOMED CT für Deutschland zu übersetzen. Stichproben haben ergeben, dass die Übersetzungen nicht durch das BfArM durchgeführt wurden. | Für die Anzeige im Meldeportal werden zwingend deutsche Anzeigenamen benötigt. Alle noch nicht vom BfArM übersetzten Codes gehen in die dann nächste Übersetzungsrunde, um eine offizielle Übersetzung zu erhalten | |
| Alle Referenzen, die auf ein bestimmtes Profil eingeschränkt sind | Die HL7 Deutschland e.V. Best Practices geben dazu Folgendes an: Umgang mit Target-Profilen im Datentyp Reference Bei der Profilierung des Datentyps Reference sollte - wo möglich - auf die Verwendung von Target-Profilen verzichtet werden. Begründung: Im Kontext einer Spezifikation mag es zwar sinnvoll sein, auszudrücken, dass beispielsweise eine konforme Observation nur auf einen konformen Patienten verweisen darf, jedoch verhindert diese Festlegung die Wiederverwendung des Observation-Profils in anderen Kontexten. Klinische Profile aus Spezifikationen wie z.B. US Core oder International Patient Summary konnten daher in der Vergangenheit trotz identischer fachlicher Anforderungen nicht wiederverwendet werden, weil die Constraints der dort referenzierten Patienten- oder Practitioner-Profile nicht übereinstimmten. Das Weglassen von Target-Profilen hingegen hat meist keine negativen Konsequenzen, da davon ausgegangen werden kann, dass Systeme, die das Observation-Profil einer Spezifikation implementieren auch erfordern, dass die Patienten-Ressourcen konform zur selben Spezifikation sind. Bei Konformitäts-Tests werden üblicherweise beide Profile unabhänig voneinander getestet (Systeme müssen nachweisen, dass sowohl ihre Observation- als auch ihre Patienten-Ressourcen konform sind), eine indirekte Prüfung der Konformität von Patienten-Ressourcen über die Observation wäre unüblich. | |||
| Alle IGs | Die Vielzahl der Profile (Laborbericht, Erregernachweis, Probe) die sich lediglich durch die zu verwendenden Codes unterscheiden scheint dem Zweck zu dienen, medizinische Modelle/Plausibilitäten als Schnittstellenspezifikation abzubilden. Die Fragen, die diskutiert werden sollten sind folgende: 1. Ist die Schnittstellenspezifikation der richtige Ort, um medizinische Plausibilität zu prüfen? 2. Ist es langfristig plausibel, die Vielzahl der Profile und deren Abhängigkeiten zu pflegen und stets auf dem aktuellsten Stand zu halten? 3. Soll jede Änderung an den zulässigen Codes/medizinischen Inhalten eine Änderung der Schnittstelleninhalte zu Folge haben? 4. Können updates der Schnittstellenspezifikation künftig schnell genug erstellt, abgestimmt, kommentiert, publiziert, verteilt und implementiert werden, um die sich ändernden medizinischen Anforderungen und Laborverfahren schnell genug abzubilden? 5. Welche Mehrwerte bietet die Plausibilisierung an der Schnittstelle gegenüber einer rein syntaktischen Spezifikation? 6. Könnte die medizinische Plausibilität auch anders, unabhängig von der Schnittstellenspezifikation überprüft werden (z.B. durch Businesslogik in einem Referenzvalidator?, Durch Invarianten, die in einem separaten Profil publiziert und getestet werden können?) 7. Wie stabil ist das Konstrukt im Krisenfall (nächste Pandemie), wenn in kurzen Zeiträumen neue Codes, neue Laborverfahren etabliert werden müssen, Häufig Verwirrung über geltende Vorgaben herrscht: Sollen die Meldungen dann an der Schnittstelle abgewiesen werden, oder wäre es nicht wichtiger, diese zunächst mal entgegenzunehmen und erst in zweiter Linie als "bedingt plausibel" zu kennzeichnen. | Die Meldepflicht nach IfSG unterliegt zum Teil erregerspezifischen Einschränkungen (z.B. alle Erregernachweise oder nur direkte Erregernachweise sind meldepflichtig). Daher haben wir die erregerspezifische Profilierung beibehalten. Dieser liegt auch ein Servicegedanke zu Grunde, da es den Anwender so erleichtert wird, aus der Vielzahl von Termen der verendeten Terminologien die relevante zu identifizieren und eine Meldung nach der vorgegebenen abgestimmten Semantik (https://wiki.gematik.de/x/GOy5J) zu ermöglichen. So können wir zudem die Qualität sicher stellen, die für die Verarbeitung bei den Empfängern notwendig ist. | ||
| Alle Profilierungen, die einen identifier auf uuid Basis profiliert haben | Es wurde ein eigenes Code system angelegt für alle DEMIS identifier (notificationID, notifcationBundleID) und identifier.type und system entsprechend profiliert | |||
NotificationBundle (Erregernachweismeldevorgang) | Die Bildungsvorschrift für Meldevorgangs-Id wurde im technischen Profil ergänzt: Als system MUSS https://demis.rki.de/fhir/NamingSystem/NotificationBundleId verwendet werden. | Diese Informationen gehen aus dem technischen Profil nicht hervor und sollten noch im Profil abgebildet werden. | ||
| Alle Slicing | Folgende Slicing wurde entsprechend angepasst: Bundle.entry: MS 1..* NotificationLaboratory | Wenn Elemente gesliced sind, sollte: - das sliced Element auch entsprechend mit MS versehen werden - die Min-Kardinalität der Anzahl der der verpflichtenden Slices entsprechen - bei Closed-Slicing sollte auch die Max-Kardinalität angepasst werden (unabhängig davon sollte im Sinne der Kompatibilität zu anderen Specs Closed-Slicing nur in besonderen Fällen verwendet werden.) | ||
| Datatypes | Alle fixed values für nicht primitive Datentypen wurden in Pattern geändert | |||
| Patient | Angaben zu Health insurance nicht ausspezifiziert aber auch nicht eingeschränkt, Daten anderer Use-Cases können überführt werden (One-Way kompatibel) | Der Patient.identifier ist zwar nicht ausspezifiziert, aber Angaben zu Health insurance dürfen in Meldungen nach §§ 6 und 7 IfSG nicht übermittelt werden. | ||
| Patient ( Betroffene Person (nicht namentlich)) | umbenannt in Betroffene Person (anonym) | nicht kompatibel zu eHN, sollte diskutiert werden | Die Angabe der nichtnamentlichen Person ist eine meldespezifische Angabe im IfSG, die spezifische Profilierung wird benötigt | |
| Patient.name | In ISiK dürfen mehrere Namen angegeben werden, dies ist notwendig, um bspw. den Geburtsnamen anzugeben. Um den ISiKPatient als Basis für DEMIS nutzen zu können, müsste die Einschränkung auf nur einen Namen aufgehoben werden. | Die Angabe des z.B. Geburtsnamen ist nicht Teil der gesetzlich meldepflichtigen Angaben und muss daher in Meldungen nach §§ 6 und 7 IfSG unterbunden werden. Wie in der Eingangskommentierung genannt, sind DEMIS-Profile für spezifische Anwendungen von Laborberichten und ärztlicher Diagnostik, die einer spezifischen Profilierung bedarf. | ||
| Patient.telecom:Phone.value | warning auf error gesetzt für die Angabe einer validen Telefonnummer: "$this.matches('^[0+][0-9 \\-\\(\\)]{6,50}$')" | BREAKING | ||
| Patient.telecom:Email.value | warning auf error gesetzt für die Angabe einer validen Email.Adresse: "$this.matches('^[a-zA-Z0-9._%+-]+@(?:[a-zA-Z0-9-]+[.])+[a-zA-Z0-9]{2,63}$')" | BREAKING | ||
| Patient.address | Durch das 0..0 bei use im Slice der Hauptwohnung geht die Kompatibilität zu ISiK, MII, MIOs usw. verloren | Auch mio verwendet address.use 0...0 | ||
| Patient.address.extension:facility | Die Inhalte der Extension sind hier an der falschen Stelle, sie wären viel besser im contact Element aufgehoben, wo eine Referenz und entsprechende Kodierung vorgesehen ist | Semantisch ist der "contact" nicht geeignet für die Abbildung der Einrichtungsunterkunft der betroffenen Person (ggf. Ausbrucherkennung in Einrichtung, Wohnort der betroffenen Person). Es handelt sich nicht um die alternative Kontaktperson des Patienten | ||
Patient.active | von nicht profiliert zu gestrichen (0...0) | |||
Patient.gender.extension:other-amtlich | neu aufgenommen, die Verwendung der extention bei der Geschlechtsangabe "other" ist verpflichtend | BREAKING | ||
Patient.birthDate | warning auf error gesetzt für die Angabe des Geburtsdatums: "$this.toString().matches('^19[0-9]{2}-[0-9]{2}-[0-9]{2}|20[0-9]{2}-[0-9]{2}-[0-9]{2}|19[0-9]{2}-[0-9]{2}|20[0-9]{2}-[0-9]{2}|19[0-9]{2}|20[0-9]{2}$')" | BREAKING | ||
Patient.deceased[x] | Entfernen des MS | Diese Angabe betrifft nur die DEMIS-Erkrankungsmeldung (https://simplifier.net/rki.demis.disease): Angaben zum Tod der betroffenen Person sollen ausschließlich über den Fragebogen DiseaseQuestionsCommon dokumentiert werden, siehe dazu linkId isDead und deathDate in https://simplifier.net/guide/rki.demis.disease/Home/resources/questionnaires/guide-diseasequestionscommon.md?version=current. | ||
Patient.address:hauptwohnung | slice direkt auf address, zu Angabe der drei gesetzlichen Aufenthaltsorte für die Betroffene Person bzw. zwei gesetzliche Aufenthaltsorte für die Betroffene Person (anonym) | |||
Patient.adress:hauptwohnung.period | von nicht profiliert zu gestrichen (0...0) | |||
Patient.general | von nicht profiliert zu gestrichen (0...0) | |||
| Practitioner/Organization | | Angaben im eHN A.1.5. Author (by whom the Laboratory result report or a subset of its results was authored) und eHN A.1.6 Legal authenticator (The person taking responsibility for the medical content of the document) Klärung der Rolle Melder / Einsender vs. legal Authenticator in DEMIS | Sowohl bei Author (nach A.1.5. EU Health Report) als auch bei Legal authenticator (nach A.1.6 EU Health Report) handelt es sich in gesetzliche Meldungen nach IfSG um den Melder, der in den Meldungen als Notifier (Practitioner) oder NotiferFacility (Organization) abgebildet wird. | |
Practitioner.telecom:Phone.value | warning auf error gesetzt für die Angabe einer validen Telefonnummer: "$this.matches('^[0+][0-9 \\-\\(\\)]{6,50}$')". Die gilt für alle Practitioner-Ressourcen im Profil | BREAKING | ||
Practitioner.telecom:Email.value | warning auf error gesetzt für die Angabe einer validen Email-Adresse: "$this.matches('^[a-zA-Z0-9._%+-]+@(?:[a-zA-Z0-9-]+[.])+[a-zA-Z0-9]{2,63}$')". Die gilt für alle Practitioner-Ressourcen im Profil | BREAKING | ||
| Organization.type | Angebot von ConceptMaps zur Abbilung von ISIK Codes auf DEMIS-OrganizationType (z.B. IHEHealthcareFacilityCodes2DEMISOrganizationTypeCodes) | 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. | ||
Organization.telecom:Phone.value | warning auf error gesetzt für die Angabe einer validen Telefonnummer: "$this.matches('^[0+][0-9 \\-\\(\\)]{6,50}$')". Die gilt für alle Organisationen im Profil | BREAKING | ||
Organization.telecom:Email.value | warning auf error gesetzt für die Angabe einer validen Email-Adresse: "$this.matches('^[a-zA-Z0-9._%+-]+@(?:[a-zA-Z0-9-]+[.])+[a-zA-Z0-9]{2,63}$')". Die gilt für alle Organisationen im Profil | BREAKING | ||
| Organization.address.line (und alle weiteren Ressourcen mit Adressangabe) | Alle address.line wurden auf 0...3 oder 1...3 gesetzt | In ISiK kann wie im in AddressDeBasis auch vorgesehen in drei line Elementen die Adresse angegeben werden. Damit eine Kompatibilität gewährleistet ist, müsste die max Kardinalität von 1 auf 3 erhöht werden. | ||
Organization.active | von nicht profiliert zu gestrichen (0...0) | |||
Organization.alias (Übermittlungsstelle) | von nicht profiliert zu gestrichen (0...0) | |||
Organization.identifier | slice, Unordered, Open, by system(Value) um mehrere Identifier der SubmittingFacility angeben zu können | |||
Organization.identifier:DEMISParticipantId (MelderEinrichtung) | MS 0...1 | |||
Practitioner.identifier | von nicht profiliert zu gestrichen (0...0) | |||
Practitioner.active | von nicht profiliert zu gestrichen (0...0) | |||
PractitionerRole.identifier | von nicht profiliert zu gestrichen (0...0) | |||
PractitionerRole.active | von nicht profiliert zu gestrichen (0...0) | |||
PractitionerRole.period | von nicht profiliert zu gestrichen (0...0) | |||
PractitionerRole.practitioner PractitionerRole.organization | MS-flag | Die beiden Elemente sollten mit MS geflaggt sein. Im Text werden sie als relevant im Use Case beschrieben | ||
PractitionerRole.code | von nicht profiliert zu gestrichen (0...0) | |||
PractitionerRole.specialty | von nicht profiliert zu gestrichen (0...0) | |||
PractitionerRole.location | von nicht profiliert zu gestrichen (0...0) | |||
PractitionerRole.healthcareService | von nicht profiliert zu gestrichen (0...0) | |||
PractitionerRole.telecom | von nicht profiliert zu gestrichen (0...0) | |||
PractitionerRole.availableTime | von nicht profiliert zu gestrichen (0...0) | |||
PractitionerRole.notAvailable | von nicht profiliert zu gestrichen (0...0) | |||
PractitionerRole.availabilityExceptions | von nicht profiliert zu gestrichen (0...0) | |||
PractitionerRole.endpoint | von nicht profiliert zu gestrichen (0...0) | |||
| Identifier | Anlegen von identifiern für die Abbildung der DEMIS-Teilnehmernummer (demisParticipantId); des Patienten-Pseudonyms der Surveillance-Systeme nach §13 IfSG, der internen ID der Einrichtng | |||
Practitioner.extension:salutation (SubmittingPerson und Notifier) | Angabemöglichkeit der salutation auch bei SubmittingPerson | Anrede Der vollständige Name inkl. Anrede sollte, falls für den Use-Case erforderlich, in HumanName.text in korrekter Reihenfolge dokumentiert werden (z.B. "Frau Dr. Martha Musterfrau"). Andernfalls kann die Anrede teilweise aus dem Administrativen Geschlecht der Person (Patien.gender) abgeleitet werden. Hier sind jedoch Extensions zur Abbildung des Geschlechts 'Divers' und einer abweichenden Gender Identity (Siehe Geschlecht) in Betracht zu ziehen um nicht fälschlicherweise eine falsche Anrede zu verwenden. Quelle: https://simplifier.net/guide/leitfaden-de-basis-r4/ig-markdown-Ressourcen-Patient?version=current | Die Angabe der Anrede wird für die Darstellung im DEMIS-Meldeportal für den Einsender und Melder benötigt. Für einen Practitioner.name.text kann kein ValueSet angelegt werden. | |
Practitioner.address.extension:county | .district ist mit 0..0 rausgestrichen, wo in der FHIR Core Beschreibung steht "District name (aka county)" | Es wird eine erweiterung der Practitioner.address.extension um den Amtliche Gemeindeschlüssel (AGS) im deutschen Basisprofil angestrebt. Bis dahin wird die extension "county" entfernt. | ||
Bundle.total | von nicht profiliert zu gestrichen (0...0) | |||
Bundle.link | von nicht profiliert zu gestrichen (0...0) | |||
Bundle.entry:notification.search Bundle.entry:notification.request Bundle.entry:notification.response | von nicht profiliert zu gestrichen (0...0) | Zu klären: Umgang mit Feldern in Bundle.entry: search, request, response, noticifcation → bei HL7 EU ausgeschlossen, bei DEMIS erlaubt. | ||
Bundle.identifier (Quittung) | von nicht profiliert zu gestrichen (0...0) | |||
Bundle.signature (Quittung) | von nicht profiliert zu gestrichen (0...0) | |||
Bundle/Composition | Weiterhin fehlend: bidirektionale Referenzierung zwischen Composition und Bundle wie in HL7 EU IG | Die bidirektionale Referenzierung wird nicht profiliert, da nicht benötigt | ||
Composition.identifier.value | validNotificationId: Die NotificationId muss dem UUID-Format [0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} entsprechen. | BREAKING | ||
Composition.relatesTo.target[x].identifier.value | Composition: idOfReferencedNotificationUnequalToNotificationId: Die in relatesTo angegebene ID der referenzierten Meldung darf nicht gleich der Meldungs-ID (Composition.identifier) sein. | BREAKING | Mit Composition.relatesTo wird in einem Sekundärlabor auf die vorhergehende Meldung aus dem Pirmärlabor verwiesen. Dies ermöglicht die Verarbeitung von zusammengehörigen Meldungen beim Empfänger der Meldung (siehe Lifecyclemanagement Szenarien 2C und 3C). Für die Verarbeitung im Backend ist es notwendig, dass nicht auf die selbe Meldung verwiesen werden kann. | |
Composition.identifier.use | von nicht profiliert zu gestrichen (0...0) | |||
Composition.identifier.type | von nicht profiliert zu gestrichen (0...0) | |||
Composition.identifier.period | von nicht profiliert zu gestrichen (0...0) | |||
Composition.identifier.assigner | von nicht profiliert zu gestrichen (0...0) | |||
Composition.status | Verpflichtendes Binding an das ValueSet NotificationStatus (required) - Einschränkung auf drei Statusangaben | 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 | ||
| Composition.extension:receivedNotificationBundle | ||||
| Composition.attester | eHN A.1.7 Result validator (Composition.attester) Nicht extra in DEMIS abgebildet? | Ist für gesetzliche Meldungen nach IfSG nicht relevant und daher nicht profiliert | ||
| Composition (Quittung) | MS-Flag für section eingeführt, slice auf section mit Composition.section:reportingSite | Die beschriebene Information ist so technisch nicht im Profil abgebildet. Weder hat section ein MS flag, noch ist gesliced, welche Inhalte in der Composition enthalten sein sollen. Ebenfalls ist das Beispiel verwirrend, weil es nicht profilierte Informationen beinhaltet. | ||
OperationOutcome.issue.details | MS-Flag gesetzt | Im Beispiel und im Text ist beschrieben, was passieren soll, leider werden da Elemente genutzt, die dann nicht mit MS geflaggt sind | ||
| CapabilityStatements | Wurden ergänzt | Alle Capability Statements sind nicht als Instanzen in Simplifier enthalten. Die Links führen zu leeren Suchergebnissen | ||
| CodeSystem Postleitzahl | Das Codesystem Postleitzahl wurde entfernt. Langfristig werden Anpassungen im Backend erfolgen und damit die Rückgabe der Adressprüfung beim Routing an den Nutzer erfolgen | Warum wird kein sprechender Display gewählt? Die Postleitzahlen werden nicht durch das RKI definiert und sollten daher auch nicht im Namen des RKI veröffentlicht werden. | Die Postleitzahl wird für das Routing benötigt, sie dient nicht der Darstellung der dazugehörigen Gemeinde. | |
| CodeSystem Land | Fällt weg und wird durch ISO-Codes ersetzt | |||
CodeSystem salutation | Angabe der Anrede (salutation) erweitert um "keine Anrede | Was ist mit nicht-binären Personen, die sich weder mit Herr, noch Frau angesprochen werden möchten? |