Kommentare & Antworten Version 1.3.0

Der Export von LDT-Befunddaten setzt voraus, dass das exportierende System diese auch erstellen kann. Ein „normales“ Praxisverwaltungssystem sollte laut Empfehlung der KBV (<span class="nobr"><a href="https://update.kbv.de/ita-update/Labor/Labordatenkommunikation/KBV_ITA_VGEX_FAQ_LDK.pdf" class="external-link" rel="nofollow">https://update.kbv.de/ita-update/Labor/Labordatenkommunikation/KBV_ITA_VGEX_FAQ_LDK.pdf^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>) den LDT-Auftrag Export, sowie den LDT-Befund-Import implementieren.

Die Anforderung P6-03 fordert nun vom PVS einen Export im LDT Format in einer Anlage. Dies zwingt PVS-Hersteller - wenn diese nicht die empfangenen LDT-Befund-Dateien speichern - zusätzlich den LDT-Befund-Export zu implementieren, da sonst keine LDT-Datei erzeugt werden kann.
Eine Speicherung von empfangenen LDT-Dateien ist jedoch nach dem LDK Anforderungskatalog nicht vorgesehen.

Wir würden es daher begrüßen, das bereits in Entwicklung befindliche MIO Laborbefund in die AWST zu integrieren. Dies sollte dazu führen, dass eine entsprechende Anforderung im Anforderungskatalog aufgenommen wird und die Anforderung P6-03 gestrichen wird.”

Das Element encounter.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element encounter.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.total sollte zugelassen werden, damit eventuelle eingetragene Informationen nicht verloren gehen.

Das Element Claim.item:besondere_Kosten.productOrService
sollte mit einem MS versehen werden, da diverse Kind-Elemente ebenfalls ein MS aufweisen.

Das Element Claim.item:auslagen.productOrService sollte mit einem MS versehen werden, da diverse Kind-Elemente ebenfalls ein MS aufweisen.

Das Element Claim.insurance sollte mit einem MS versehen werden, da diverse Kind-Elemente ebenfalls ein MS aufweisen.

Das Element Claim.referral sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.priority sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.patient.reference sollte mit einem MS versehen werden, da das Eltern-Element auch mit einem MS ausgestattet ist und besagtes Element das einzige Kind-Element ist.

Das Element Claim.type sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.extension:unfallbetrieb.extension:ort.value<span class="error">[x]</span> sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.extension:unfallbetrieb.extension:kontaktdaten.value<span class="error">[x]</span> sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.extension:unfallbetrieb.extension:reference.value<span class="error">[x]</span> sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.extension:mahnung.extension:zahlbetrag.value<span class="error">[x]</span> sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.extension:mahnung.extension:zahldatum.value<span class="error">[x]</span> sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.extension:mahnung.extension:mahngebuehr.value<span class="error">[x]</span> sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.extension:mahnung.extension:mahnstufe.value<span class="error">[x]</span>:valueCodeableConcept sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.extension:mahnung.extension:mahndatum.value<span class="error">[x]</span> sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.supportingInfo:vertragskennzeichen
sowie die relevanten Kind-Elemente category und value<span class="error">[x]</span> sollten mit einem MS versehen werden.

Das Element ServiceRequest.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.supportingInfo:leistungsgenehmigung.category sollte mit einem MS versehen werden, da diverse Kind-Elemente mit einem MS versehen sind.

Das Element Claim.supportingInfo:ringversuchszertifikat.category sollte mit einem MS versehen werden, da diverse Kind-Elemente mit einem MS versehen sind.

Das Element Claim.supportingInfo:rechnungsinformation.category sollte mit einem MS versehen werden, da diverse Kind-Elemente mit einem MS versehen sind.

Das Element ServiceRequest.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.supportingInfo:korrekturzaehler.category
sollte mit einem MS versehen werden, da diverse Kind-Elemente mit einem MS versehen sind.

Das Element Claim.supportingInfo sollte mit einem MS versehen werden, da diverse Kind-Elemente mit einem MS versehen sind.

Das Element Claim.referral sowie sämtliche erlaubten Kind-Elemente sollten mit einem MS versehen werden, da die Weiterbehandlung_durch referenziert werden sollte.

Das Element Claim.related.claim.reference sollte mit einem MS versehen werden, da das Eltern-Element auch mit einem MS ausgestattet ist.

Das Element Claim.priority sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Feld Condition.code.text wird für verschiedene Konzepte verwendet. Die AWST nutzt dies für den Transport des Diagnosefreitexts, während in der eAU (Condition_FreeText) das Feld für die Diagnoseerläuterung genutzt wird. Hier wäre eine Vereinheitlichung anzustreben.

Das Element Claim.insurer.reference sollte mit einem MS versehen werden, da das Eltern-Element auch mit einem MS ausgestattet ist.

Das Element Claim.patient.reference sollte mit einem MS versehen werden, da das Eltern-Element auch mit einem MS ausgestattet ist und besagtes Element das einzige Kind-Element ist.

Das Element Claim.type sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.extension:mahnung.extension:zahlbetrag.value<span class="error">[x]</span> sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.extension:mahnung.extension:zahldatum.value<span class="error">[x]</span> sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.extension:mahnung.extension:mahngebuehr.value<span class="error">[x]</span> sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.extension:mahnung.extension:mahnstufe.value<span class="error">[x]</span>:valueCodeableConcept sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Wie geht die AWST mit Storno-Bundles um, welche eventuell empfangen worden sind? Wie können diese exportiert werden?

Das Element Claim.extension:mahnung.extension:mahndatum.value<span class="error">[x]</span> sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Composition.encounter.reference
sollte mit einem MS versehen werden, da das Eltern-Element auch mit einem MS ausgestattet ist und besagtes Element das einzige Kind-Element ist.

Das Element Claim.meta.lastUpdated sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.meta.versionId sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Composition.meta.lastUpdated sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Composition.meta.versionId sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Feld 5006 (Um-Uhrzeit) fehlt.

Das Element Claim.item.detail.udi.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.item.detail.unitPrice.currency sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.item.detail.unitPrice.value sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.item.detail.productOrService sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.item.detail.sequence sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.item.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Ist es geplant das Profil KBV_PR_AW_Begegnung an Profil ISiKKontaktGesundheitseinrichtung anzugleichen?

Im Rahmen der ISiK Spezifikation wurden die Konzepte Abrechnungsfalll & Besuch voneinander getrennt: <span class="nobr"><a href="https://simplifier.net/guide/implementierungsleitfadenisik-basismodul/ImplementationGuide-markdown-Datenobjekte-Datenobjekte-Kontakt?version=current" class="external-link" rel="nofollow">https://simplifier.net/guide/implementierungsleitfadenisik-basismodul/ImplementationGuide-markdown-Datenobjekte-Datenobjekte-Kontakt?version=current^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Sämtliche 1..1 Kind-Elemente der Slices von Claim.item.productOrService.coding sollten mit einem MS versehen werden, da diese 1..1 Elemente sind und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.item.category.coding sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.item.sequence sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.insurance, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.priority, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.provider.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element ist 1..1, ohne ein MustSupport. Darüber hinaus enthält das Element einen fixed Value mit “finished”. So spezifiziert enthält das Element eigentlich keinerlei relevante Information.

Gibt es einen fachlichen Hintergrund vor welchem alle Begegnungen nur den Status “finished” haben können? Was ist mit quartalsweisen Abrechnungsfällen, die noch offen sind?

Könnte man hier nicht besser alle Werte aus die dem HL7 DE ValeSet <span class="nobr"><a href="https://simplifier.net/packages/de.basisprofil.r4/1.4.0/files/656745" class="external-link" rel="nofollow">https://simplifier.net/packages/de.basisprofil.r4/1.4.0/files/656745^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> zulassen?

Das Element Claim.created sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.patient.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Was sind spezielle Begegnungsinformationen? Der Typ wird als CodableConcept spezifiziert, enthält aber nur einen Text. Ohne das CodeSystem kann die Semantik des Elements nicht nachvollzogen werden.

Das Element Claim.use sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.subType.coding, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.type, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.meta.lastUpdated sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.meta.versionId sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Encounter.Appointment sollte auf 0..* gesetzt werden. In der Regel geht einer Begegnung ein Termin voraus bzw. gibt es zu einer Begenung mehere Termine (wenn es nur einen Abrechnugnsfall pro Quartal gibt).
Im Primärsystem ist diese Verbindung bekannt, da es meist möglich ist ausgehend vom Termin eine Begegnung anzulegen

Wenn das encounter.appointment Element vorhanden ist, muss noch spezifiziert werden, wie das Bundle Patientenakte und Termin gefüllt werden sollen, da wegen der Referenz der Termin auch immer Teil der Patientenakte sein wird.

Im xBDT werden mehr Abrechnungstypen unterstützt. Eventuell kann die AWST hier nachziehen.
01 = Privat,
20 = KVB,
21 = Bahn-Unfall,
30 = Post,
31 = Post-Unfall,
50 = Bundesknappschaft
70 = Justizvollzugsanstalt,
71 = Jugendarbeitsschutz
72 = LVA,
73 = BfA,
74 = Sozialamt,
75 = Sozialgericht,
80 = Studenten-Deutsche,
81 = Studenten-Ausländer

Das Element Claim.billablePeriod sollte zugelassen werden, damit der Abrechnungszeitraum angegeben werden kann.

Das Element Claim.item, sowie alle 1..1 Kind-Elemente der Slices sollten mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Alle 1..1 Kind-Elemente von Claim.insurance
sollten mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Alle 1..1 Kind-Elemente von Claim.supportingInfo
sollten mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.referral.reference sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.payee.type, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.related.claim sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.priority, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.provider.reference sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.provider sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.insurer.extension:kundennummer_Abrechnungsdienst sollte mit einem MS versehen werden.

Das Element Claim.patient.reference sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.use sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.subType.coding, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.type.coding, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.identifier.value sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.identifier.type, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.extension:rechnungsempfaenger_Selbstzahler.value<span class="error">[x]</span>:valueReference sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Für die KBV Profile der AWST, VOS und dem eRezept gibt es kein KBV Basis-Profil für den Ressourcen-Typ medicationRequest. Die Kompatibilität der Spezifikationen kann somit nicht aus der Ableitungshierarchie abgeleitet werden.

Gibt es technische Gründe oder Inkompatibilitäten zwischen den KBV Spezifikationen, die die Ableitung von einem Basis-Profil verhindern?

Das Element Claim.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.meta.lastUpdated sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.meta.versionId sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Wie wird zwischen Erstveranlasser und Überweiser unterschieden? Wie werden die KVDT Felder 4217/4241 und 4218/4242 übertragen?

Das KVDT Feld 4108 (Zulassungsnummer des mobilen Lesegeräts) sollte mit aufgenommen werden.

Das KVDT Feld 4233 (stationäre Behandlung von…bis) sollte mit aufgenommen werden.

Das KVDT Feld 4206 (mutmaßlicher Tag der Entbindung) sollte mit aufgenommen werden.

Das KVDT Feld 4204 (eingeschränkter Leisteistungsanspruch gemäß §16) sollte mit aufgenommen werden.

Das Element Claim.insurance.focal sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.insurance.sequence sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.supportingInfo:leistungsgenehmigung.value<span class="error">[x]</span> sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.supportingInfo:leistungsgenehmigung.category sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.supportingInfo:leistungsgenehmigung.sequence sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.supportingInfo:ringversuchszertifikat.value<span class="error">[x]</span> sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.supportingInfo:ringversuchszertifikat.category sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Bestandteil des BMP/eMP ist ein Flag für die Dauermedikation. Für den Zweck einer vollständigen Migration sollten alle Informationen des BMP/eMP medicationStatements auch im AWST Profil enthalten sein. In der VOS (Version 2.1.0) wurde das bereits so umgesetzt.

Wahrscheinlich müsste die übrigen Elemente auch nochmal auf Kompatibilität AWST, VOS und BMP/eMP geprüft werden.

Das Element Claim.supportingInfo:ringversuchszertifikat.sequence sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.related.claim.reference sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.priority, sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.patient.reference sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.use sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.type, sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.extension:zusatzinformationen.extension:anerkannte_Psychotherapie sollte mit einem MS versehen werden.

Das Element Claim.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.meta.lastUpdated sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Claim.meta.versionId sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element AllergyIntolerance.note sollte zugelassen werden, damit eventuelle eingetragene Informationen nicht verloren gehen.

Die Dosisinformation fehlt im Profil KBV_PR_AW_Dauermedikation, ist aber in anderen Spezifikationen vorhanden (VOS, BMP/eMP). Diese sollte ergänzt werden und unter Umständen mit einem geeigneten Fallback-Mechanismus ergänzt werden, da die Dosierung in Legacy-Systemen oft nur ein String ist.

Das Element AllergyIntolerance.catagory sollte zugelassen werden, damit eventuelle eingetragene Informationen nicht verloren gehen.

Das Element AllergyIntolerance.type sollte zugelassen werden, damit eventuelle eingetragene Informationen nicht verloren gehen.

Das Element AllergyIntolerance.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element AllergyIntolerance.asserter.display sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Im Profil KBV_PR_AW_Dauermedikation gibt es keine kodifizierte Information, die eine Medikation zu einer Langzeitmedikation machen würde, außer dass es evtl. kein Enddatum gibt. Somit ist diese nicht von anderen Arten der Medikation zu unterscheiden

Das Element AllergyIntolerance.asserter.extension:befund_Erfasserart.value<span class="error">[x]</span>:valueCodeableConcept.coding, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden.

Das Element AllergyIntolerance.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AllergyIntolerance.patient.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Aktuell ist es möglich mit der AWST folgende Informationen zur Medikation zu migrieren:

• Sprechstundenbedarf (supplyRequest)
• Ausgestellte Rezepte für Patienten (medicationRequest)
• BMP/eMP als Dokument

Es gibt das Profil KBV_PR_AW_Dauermedikation. Der Name suggeriert, dass es sich hier um eine Dauermedikationen handelt. Die Beschreibung der Ressource sagt folgendes: “Hier werden Angaben dazu gemacht, wie ein bestimmtes Arzneimittel eingenommen bzw. verabreicht wird oder werden soll.” - was sehr generisch klingt und gar nicht wie einer Dauermedikation.

Wie wird die aktuelle und die historische Medikation eines Patienten abgebildet?
Wenn die Ressource dafür gedacht ist, aktuelle und historische Medikationen abzubilden, sollte das in der Beschreibung der Ressource entsprechend hinterlegt sein, ggf. könnte auch der Name des Profils angepasst werden.

Das Element AllergyIntolerance.code.coding:codeATC, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden.

Das Element AllergyIntolerance.verificationStatus.coding, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden.

Das Element AllergyIntolerance.clinicalStatus.coding, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden.

Das Element AllergyIntolerance.extension:abatement.value<span class="error">[x]</span> sollte mit einem MS versehen werden.

Das Element AllergyIntolerance.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AllergyIntolerance.meta.lastUpdated sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element AllergyIntolerance.meta.versionId sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Es sollte die Möglichkeit gegeben werden, einen internen Identifier zu einem Arzt zu hinterlegen. So könnten z.B. Kürzel in Patientenakten korrekt genutzt und passend hinterlegt werden (1-Meier, 2-Bauer, 3-Mueller, …)

Gibt es die Möglichkeit, eine Vertretung für den Arzt zu hinterlegen?

Gibt es eine Möglichkeit zur Speicherung von Bankdaten des Arztes?

Das Extension Practitioner.gender.extension:other-amtlich sollte mit einem MS versehen werden.

Das Element Practitioner.address:Postfach.type sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Practitioner.address:Strassenanschrift.type sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Practitioner.telecom, sowie die Kind-Elemente sollten mit einem MS versehen werden.

Sämtliche Extensions des Elements Practitioner.name:geburtsname.family sollten mit einem MS versehen werden.

Das Element Practitioner.name:geburtsname.use sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Sämtliche Extensions des Elements Practitioner.name:name.family sollten mit einem MS versehen werden.

Das Element Practitioner.name:name.use sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Alle 1..1 Kind-Elemente der Slices des Elements Practitioner.identifier sollten mit einem MS versehen werden, da diese 1..1 Elemente sind und das Profil bei Fehlen nicht validiert werden kann.

Das Element Practitioner.extension:ergaenzende_Angaben sollte mit einem MS versehen werden.

Das Element Practitioner.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Practitioner.meta.lastUpdated sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element Practitioner.meta.versionId sollte mit einem MS versehen werden, da es eine Kardinalität von 1..1 besitzt und immer befüllt werden muss.

Das Element PractitionerRole.specialty.text sollte mit einem MS versehen werden.

Im Profil steht: “In dem Element entry wurde nur die erste Ebene der Ressourcen angegeben, d.h. es wurden nur die Ressourcen explizit aufgeführt, die auf andere Ressourcen verweisen und auf die, im Sinne dieses Bundles, selbst nicht referenziert werden.”

Es wurden aber keine Entries für dieses Bundle definiert.

Das Element PractitionerRole.organization.reference sollte mit einem MS versehen werden.

Das Element PractitionerRole.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element PractitionerRole.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element PractitionerRole.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Wird das Feld ServiceRequest.requester.display für die Abbildung des KVDT Feldes 4219 (Überweisung von anderen Ärzten) genutzt?

Die Extension KBV_EX_AW_Betriebsstaette_Hierarchie sollte entfernt werden. Im Element Organization.identifier:Betriebsstaettennummer.type kann diese Information gespeichert werden. Eventuell ist es auch sinnvoll ein weiteres Identifier-Slice für eine NBSNR zu erstellen oder die Kardinalität des BNSR Slices zu erweitern.

Die Extension ergaenzende_Angaben sollte erlaubt werden.

Das Element Organization.address:Postfach.extension:Stadtteil sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Organization.address:Strassenanschrift.extension:Stadtteil sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Organization.identifier:Telematik-ID, sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden.

Das Element Organization.identifier:Betriebsstaettennummer sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Jedes type-Element (und alle 1..1 Kind-Elemente) jedes Slices von Organization.identifier sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Organization.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Organization.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Es wurde kein Entry für die Anlage definiert. Anlagen (documentReference) werden aber nicht von anderen Ressourcen referenziert (außer bei den Einwilligungen).

Das Element Organization.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Am Feld RelatedPerson.gender ist zweimal die gleiche Extension in verschiedenen Versionen angehängt. Ist dies so gewollt?

Das Element RelatedPerson.telecom.value sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Es fehlen Entries für die Bausteindefinitionen, da nicht alle definierten Bausteine auch einer Behandlungsbaustein-Definition zugeordnet sein müssen (z.B. Baustein–Bibliothek aus der sich ein Anwender Vorlagen bzw. die Behandlungsbaustein-Definition zusammen stellt)

Das Element RelatedPerson.telecom.system sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element RelatedPerson.name.use sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element RelatedPerson.relationship, sowie die relevanten Kind-Elemente sollten mit einem MS versehen werden.

Im Element RelatedPerson.relationship ist eine fehlerhafte Beschreibung hinterlegt. Es suggeriert eine Möglichkeit zum Freitexteintrag. Diese Feld ist jedoch nicht erlaubt.

Das Element RelatedPerson.extension:Hinweis sollte mit einem MS versehen werden.

Das Element RelatedPerson.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Im Profil steht: “In dem Element entry wurde nur die erste Ebene der Ressourcen angegeben, d.h. es wurden nur die Ressourcen explizit aufgeführt, die auf andere Ressourcen verweisen und auf die, im Sinne dieses Bundles, selbst nicht referenziert werden.”
Es wurden aber keine Entries für dieses Bundle definiert.

Das Element RelatedPerson.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element RelatedPerson.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Es wurde kein Entry für die Anlage definiert. Anlagen (documentReference) werden aber nicht von anderen Ressourcen refernziertm (außer bei den Einwilligungen).

Die Beschreibung des Profils beschreibt “Hauptdiagnose, Nebendiagnose oder Quartalsdiagnose” - wo werden diese Kategorien beschrieben?

Wie wird post koordinierter ICD10 Code abgebildet? Mit zwei Instanzen einer Diagnosen-Ressource? Gemäß des HL7 DE Implementation Guide <span class="nobr"><a href="https://ig.fhir.de/basisprofile-de/stable/Ressourcen-DiagnosenCondition.html" class="external-link" rel="nofollow">https://ig.fhir.de/basisprofile-de/stable/Ressourcen-DiagnosenCondition.html^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> fehlt die Verbindung zwischen aufgetrennten ICD-10-Codes. Hier wäre die Nutzung der Extension <span class="nobr"><a href="http://hl7.org/fhir/extension-condition-related.html" class="external-link" rel="nofollow">http://hl7.org/fhir/extension-condition-related.html^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> wünschenswert.

Wie verhält sich dann der Alpha-Id-Code? Wird dieser dann in einer dritten Instanz gespeichert? Eine Speicherung mit nur einem ICD-10-Code ist unserer Meinung nach nicht korrekt, da die Information jeweils eine andere ist (AlphaID: post koordinierte Diagnose vs. ICD-10 Hauptdiagnose).

Wie würde folgendes Beispiel umgesetzt werden?
Alpha-ID: I92796
ICD: F44.6+H58.1*

Das Element Condition.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.bodySite.text sollte mit einem MS versehen werden.

Das Element Condition.bodySite.coding, sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.severity.text sollte mit einem MS versehen werden.

Das Element Condition.category:diagnoseart.coding, sowie die 1..1 Kind Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.category:diagnosekategorie.coding, sowie die 1..1 Kind-Elemente sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.verificationStatus, sowie die Kind-Elemente sollten mit einem MS versehen werden.

Das Element Condition.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Profil enthält einen Slice für KBV_PR_AW_Rezept_PracticeSupply warum? Ressourcen mit diesem Profil werden in der Composition KBV_PR_AW_Rezept_Composition referenziert.

Falls das zum Ausschluss von Rezepten mit Patientenbezug dienen soll, muss das spezifiziert werden.

documentReference ConstraintNotAllOrNothingHASOne: Definition passt nicht zur Beschreibung und auch nicht zur Anforderung P6-10

NotAllOrNothingHASOne: "Min. eine aber auch nur eine Referenz aus Betriebsstaette, Patient und Begegnung ist erlaubt"

Bedingung für die Validierung: subject.reference.exists() xor context.encounter.reference.exists() xor context.related.reference.exists()

MustSupport und Kardinalitäten im Profil KBV_PR_AW_Anlage: Es gibt eine Reihe von 1..1 ELementen ohne das MustSupport Flag

documentReference.context.practiceSetting auf 0..1 setzen, mit passendem Binding für XDS Kompatibilität: <span class="nobr"><a href="https://simplifier.net/packages/de.basisprofil.r4/1.4.0/files/package/valueset-1.2.276.0.76.11.37--20190517134631.json" class="external-link" rel="nofollow">https://simplifier.net/packages/de.basisprofil.r4/1.4.0/files/package/valueset-1.2.276.0.76.11.37--20190517134631.json^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

documentReference.context.facilityType auf 0..1 setzen, mit passendem Binding für XDS Kompatibilität: <span class="nobr"><a href="https://simplifier.net/packages/de.basisprofil.r4/1.4.0/files/package/valueset-1.2.276.0.76.11.36--20181001183306.json" class="external-link" rel="nofollow">https://simplifier.net/packages/de.basisprofil.r4/1.4.0/files/package/valueset-1.2.276.0.76.11.36--20181001183306.json^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Die Beschreibung des Elements ​​Procedure.code.coding:omim ist irreführend. Hier sollte nur der OMIM-G Code erlaubt sein, da in reasonCode der OMIM-P Code übertragen wird.

Die sehr generische Beschreibung des Profils sollte konkretisiert werden.

Das Element Procedure.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.category.coding:Klassifizierung_der_Ressource, sowie sämtliche 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Wie werden eventuelle weitere Gesundheitspässe abgebildet, welche nicht im ValueSet KBV_VS_AW_Gesundheitspass_Typ definiert sind? Könnte hier das Element type.text geöffnet werden oder das Binding auf extensible gesetzt werden?

Wir würden es begrüßen, neben den eigenen KBV Passtypen, auch Snomed-CT-Codes der definierten Typen zu erlauben.

Die vorhandene Beschreibung ist sehr generisch und sollte angepasst werden.

Das Element DocumentReference.date sollte mit einem MS versehen werden.

Das Element DocumentReference.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element DocumentReference.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element DocumentReference.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element DocumentReference.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element DocumentReference.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Der angegebene Snomed-CT-Code 463916008 beschreibt eine “Physician-practice-management information system application software” und nicht den Hersteller, wie der Profilname suggeriert.

Wie unterscheidet die AWST zwischen Systemverantwortlichem und Systembetreuer? Wird beides in diesem Profil abgebildet? Falls nicht, wo wird dies abgebildet?

Siehe Satzart: ADT-Datenpaket-Header adt0.

Die bereits vorhandene Extension <span class="nobr"><a href="https://fhir.kbv.de/StructureDefinition/KBV_EX_Base_Responsible_Person_Organization" class="external-link" rel="nofollow">https://fhir.kbv.de/StructureDefinition/KBV_EX_Base_Responsible_Person_Organization^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> aus dem Basisprofil könnte hier genutzt werden.

documentReference.content.attachment.creation - Sollte für die Kompatibilität mit anderen Interop Standards mit als Pflichtfeld definiert werden (1..1, MustSupport). Entweder kennt das exportierende System das Anlagedatum des Dokuments/Anlage bereits oder es wird mit dem Zeitpunkt gefüllt, wenn die Anlage im Export-Dateisystem angelegt wird.

Im Profil ist eine falsche Beschreibung hinterlegt.

Das Element Device.version.value sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Device.type, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Device.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Device.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Device.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Warum werden nicht direkt die ValueSets des Impfpasses genutzt und eigene ValueSets für die AWST erstellt? Zum Beispiel: KBV_VS_AW_Impfung_Vaccine

Es wäre wünschenswert, das Element Immunization.reaction zuzulassen, da so eventuell dokumentierte Impfreaktionen strukturiert übertragen werden können.

Es wäre wünschenswert, das Element Immunization.performer zuzulassen, da so kein Kontext verloren geht.

Es wäre wünschenswert, das Element Immunization.encounter zuzulassen, da so kein Kontext verloren geht.

Wie im MIO Impfpass sollte die verantwortliche Person zugelassen werden.

documentReference.content.attachment.title - was soll passieren, wenn kein Titel für ein Dokument vorhanden ist? Häufig bieten Systeme keine Möglichkeit, einen Titel für ein Dokument anzugeben. Wir schlagen vor die Kardinalität auf 0..1 zu setzen.

Im Element Immunization.occurrence<span class="error">[x]</span>:occurrenceDateTime wurde eine fehlerhafte Definition übertragen. Diese scheint vom MIO Impfpass zu kommen, da sich diese auf die Szenarien im Impfpass bezieht.

Das Element Immunization.protocolApplied.doseNumber<span class="error">[x]</span>, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Die 1..1 Kind-Elemente von Immunization.protocolApplied.targetDisease.coding sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Immunization.note.text sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Immunization.reportOrigin.coding, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Immunization.vaccineCode.coding, sowie die 1..1 Kind-Elemente der einzelnen Slices sollten mit einem MS versehen werden.

Das Element Immunization.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Immunization.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Immunization.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Die SKT Felder 4123 (Personenkreis), 4125 (Gültigkeitszeitraum) und 4126 (SKT Bemerkungen) fehlen. Da die SKT Zusatzangabe in diesem Profil modelliert wurde, würden wir auch erwarten, hier diese Informationen zu finden.

Um einen vollständigen KVDT Export zu ermöglichen, ist es notwendig, ein Feld für die Gebührenordnung zuzulassen. Dies wurde bereits in KBV_PR_AW_Selektivvertrag getan - warum nicht hier?

Das Element Coverage.payor.display sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Coverage.beneficiary.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Sämtliche 1..1 Kind- und Enkel-Elemente aller Slices von Coverage.subscriber.identifier sollten mit einem MS versehen werden, da diese 1..1 Elemente sind und das Profil bei Fehlen nicht validiert werden kann.

Das textuelle Constraint in Coverage.subscriber sollte auch als tatsächliches Constraint umgesetzt werden.

Sollte für die Kompatibilität mit anderen Interop Standards mit als Pflichtfeld definiert werden (1..1, MustSupport)

Das Element Coverage.subscriber.reference sollte mit einem MS versehen werden, da dies durch die Beschreibung in Coverage.subscriber verlangt ist.

Das textuelle Constraint in Coverage.status sollte auch als tatsächliches Constraint umgesetzt werden.

Sämtliche 1..1 Kind- und Enkel-Elemente aller Slices von Coverage.identifier sollten mit einem MS versehen werden, da diese 1..1 Elemente sind und das Profil bei Fehlen nicht validiert werden kann.

Das Element Immunization.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Immunization.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Immunization.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Device.type.coding, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Device.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Device.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Device.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Über die in der VOS vorhandenen Extension (<span class="nobr"><a href="https://fhir.kbv.de/StructureDefinition/KBV_EX_VoS_Medication_Category" class="external-link" rel="nofollow">https://fhir.kbv.de/StructureDefinition/KBV_EX_VoS_Medication_Category^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>) könnte zusätzlich die Kategorie des Medikaments übertragen werden.

Wir verstehen das Profil so, dass “Informationen zu einem Fertigarzneimittel oder einer Rezeptur angegeben werden” können. Wie geht die AWST mit historischen Daten um? Diese sind mitunter nicht die gleichen, welche über eine VOS bezogen werden können. Konkrete Beispiele wären der Preis oder der Festbetrag zum Zeitpunkt der Verordnung. Auch Dinge wie Indikation, Nebenwirkungen, Gegenanzeigen, Wechselwirkungen, Hinweise oder Alternativen könnten übertragen werden.

Das Element Medication.ingredient, sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Medication.code.text sollte mit einem MS versehen werden.

Das Element Medication.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Medication.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Medication.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

documentReference.content.attachment, Extension Version_der_Anlage - was soll hier ausgedrückt werden?

Wir würden erwarten, dass für jede Anlage-/Dokumentversion auch eine dedizierte documentReference Ressource vorhanden ist und diese über das relatesTo Element, unter Angabe des Codes der Beziehung, miteinander verbunden sind.

Die Erweiterung enthält ein CodableConcept, jedoch konnten wir kein CodeSystem Binding finden.

Das Element Practitioner.address, sowie die Kind-Elemente sollten mit einem MS versehen werden, um Adressinformationen für Mitarbeiter übertragen zu können (Mitarbeiterverwaltung).

Das Element Practitioner.telecom, sowie die Kind-Elemente sollten mit einem MS versehen werden, um Kontaktmöglichkeiten für Mitarbeiter übertragen zu können (Mitarbeiterverwaltung).

Das Element Practitioner.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Practitioner.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Practitioner.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element ServiceRequest.authoredOn sollte zugelassen werden, um dokumentieren zu können, wann die Überweisung ausgestellt wurde.

Das Element ServiceRequest.performer.identifier.value sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element ServiceRequest.performer.identifier.system sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element ServiceRequest.performer.reference sollte mit einem MS versehen werden.

Das Element ServiceRequest.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element ServiceRequest.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element ServiceRequest.intent sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element ServiceRequest.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element ServiceRequest.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element ServiceRequest.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element ServiceRequest.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.patient weist eine falsche Beschreibung auf. Das genannte Element “related” existiert hier nicht.

Der Fixed-Value des Elements Consent.status sollte entfernt werden, um auch alte Notfallbenachrichtigte übertragen zu können. Dazu könnte der Code “inactive” verwendet werden und die Verwendung dieses und dem Code “active” durch ein Constraint gesichert werden.

Das Element Consent.provision, sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.policy, sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.source<span class="error">[x]</span>:sourceReference.reference sollte mit einem MS versehen werden.

Das Element Consent.source<span class="error">[x]</span>:sourceReference sollte mit einem MS versehen werden.

Das Element Consent.patient.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.category.coding, sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.scope, sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

documentReference.relatesTo: Dieses Element muss erlaubt sein (0..1). Insbesondere weil der Status “Superseded” auftreten kann und man so die aktuellen Dokument-Metadaten referenzieren kann.

Das Element Consent.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

In der Definition der Ressource ist ein Fehler vorhanden (“eine Freitext”).

Das Element Observation.value<span class="error">[x]</span>:valueString sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.effective<span class="error">[x]</span>, sowie das Kind-Element sollte mit einem MS versehen werden.

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.code.coding:loinc_code, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden.

Das Element Observation.code.coding:kbv_code.code, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.code.coding:kbv_code.system sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Die Kardinalität von Observation.code.coding sollte auf 2..2 angepasst werden.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element solltem möglich sein (0..1), um den Author mit angeben zu können, evtl. mit dem Display als mustSupport, eine Referenz sollt erlaubt, um den Practitioner referenzieren zu können.

Für das Element documentReference.category Slice für XDS classCode hinzufügen, Idealerweise gibt es ein Mapping zwischen dem XDSclassCode und KBV_CS_AW_Ressourcentyp CodeSystem.

Slices für KDL, XDS und ggf. KBV Anlagetypen für typeCode anlegen, um standardisierte Dokumenttypen abbilden zu können.

Mapping für standardisierte Dokumenttypen definieren, idealerweise gibt es ein Mapping zwischen KDL (oder XDS) und den CodeSytemen, die im ValueSet KBV_VS_AW_Anlagetyp genutzt werden.

documentReference.docStatus sollte erlaubt sein (0..1), um die Information zum Bearbeitungsstand zu übermitteln

Was soll mit Dokumenten im Status entered-in-error im Export-System passieren? Sollen diese beim Export nicht mit exportiert werden?

Identifier werden in der Regel mit einem Namespace angegeben, in der AWST sollte die Kardinalität des Identifier.System Elements auf 0..1 gesetzt werden, um diese Angabe zu erlauben.

Es ist unklar, was die Bezeichnung eins Dokuments im Element identifier.type.coding sein soll, auch das CodeSystem gibt keine Auskunft. Wir würden hier eigentlich einen Identifier des Dokuments erwarten

Identifier werden in der Regel mit einem Namespace angegeben und masterIdentifier.system ist Pflichtfeld in ISiK, in der AWST sollte die Kardinalität des Identifier.System Elements auf 0..1 gesetzt werden, um diese Angabe zu erlauben.

documentReference.format - der Format Code ist gefüllt für alle Dokumente, die mit der ePA ausgetauscht wurden (Upload & Download), das Element sollte 0..1 sein und ein Binding auf das IHEXDSformatCodeDE ValueSet enthalten bzw. auf ein ValueSet, was KBV Dokument-Formate und Formate aus IHEXDSformatCodeDE enthält. Entsprechend ist es dann nicht mehr notwendig Formlarversionen von KBV Dokumenten als masterIdentifier abzubilden. Somit können dann auch die Constraints dafür aus dem Profil entfernt werden.

Im Root-Element der DocumentReference und der Anforderung P6-05.5 wird angegeben, dass der MasterIdentifier die Versionsnummer von Standard-Dokumenten enthalten soll. Der Identifier ist jedoch ein vom System festgelegter Dokument-Identifier.

Die Version eines bestimmten Dokumenttyps sollte besser als formatCode in documentReference.content.format abgebildet werden, statt dieses Element für einen anderen Zweck zu verwenden als in der FHIR Spezifikation festgelegt. Die Kombination von typeCode und formatCode erlauben es dem importierenden System, das Dokument richtig zu interpretieren bzw. zu rendern.

MasterIdentifier und Identifier sollten der Verwendung in der ISiK Spezifikation entsprechen.

In der Version 1.3.0 der AWST sind Dokument-Metadaten nicht standardisiert. Für eine Migration eines PVS oder einer Dokumentenverwaltung ist es jedoch notwendig die Dokument-Metadaten zu standardisieren und an die anderen DE Interop-Standards anzugleichen (TI ePA Kompatibilität, ISiK Kompatibilität, Vollständigkeit und Verbesserung der Datenqualität der Dokument-Metadaten)

MustSupport und Kardinalitäten im Profil KBV_PR_AW_Termin: Es gibt eine Reihe von 1..1 Eolementen ohne das MustSupport Flag

Eine Einschränkung auf die aktuell spezifizierten Ressourcentypen ist nicht möglich, da es auch Termine gibt, die in Räumen und mit Geräten stattfinden, diese Information geht verloren.
Hier könnten Slices für Patient, Location, Practitioner angelegt werden. Wenn der Slice offen ist, können auch andere Informationen hinzugefügt werden, mit einem 1..1 MustSupport für das Appointment.participant.actor.display Element.
Durch diese Änderung kann auch eine Kompatiblität zum Profil in der Spezifikation der ISiK Temrinplanung hergestellt werden.

Kompatibilität zu ISiK Terminplanung, Appointment.comment und Appointment.patientInstruction müssen an die ISiK Spezifikation angeglichen werden

Kompatibilität zu ISiK Terminplanung, Appointment.priority muss 0..1 sein, da diese Information vorliegen kann

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Kompatibilität zu ISiK Terminplanung, Appointment.specialty muss 0..1 mustSupport sein, da diese Information im Zusammenhang mit dem serviceType die Art des Termins bestimmt. Idealerweise mit Binding auf das ValueSet IHEXDSauthorSpeciality für bessere Interoperabilität

Die Kardinalität von Observation.code.coding sollte auf 2..2 angepasst werden.

Das Element Observation.category, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Kompatibilität zu ISiK Terminplanung Appointment.serviceType.text: In der Beschreibung steht, dass “ Über die Kategorie können auch Räume abgebildet werden.” Das sollte über den Participant.actor passieren, damit die Elemente fachlich korrekt gefüllt werden und die Spezifikation kompatibel zur ISiK Terminplanung ist.

Gibt es für diese Observation keinen passenden Snomed-CT-Code? Falls doch, wäre es wünschenswert, wenn diese auch Teil des Profiles wird.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.value<span class="error">[x]</span>:valueQuantity, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Kompatibilität zu ISiK Terminplanung, Appointment.serviceType.coding muss 0..1 sein, entsprechend muss das Code System mit exportiert werden, wenn eins vorhanden ist

Das Element Observation.effective<span class="error">[x]</span>, sowie dessen Kind-Element sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Kompatibilität zu ISiK Terminplanung, Appointment.cancelationReason sollte 0..1 sein, da Informationen vorliegen können, warum ein Termin abgesagt wurde

Das Element Observation.code, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Kompatibilität zu ISiK Terminplanung, appointment.status sollte MustSupport sein, eine Einschränkung des ValueSets (AWS-1 Cosntraint) für einen Status ist nicht möglich, da es kein Mapping der übrigen Status auf booked und cancelled gibt

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Es wäre wünschenswert für diese Observation neben dem KBV-Code und dem Loinc-Code auch ein Snomed-CT-Slice zuzulassen.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Kind-Elemente von Observation.component.value<span class="error">[x]</span>, sollten mit einem MS versehen werden, da diese benötigt werden, um Informationen zu transportieren.

Das Element Observation.component.code.coding, sowie dessen Kind-Element sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.value<span class="error">[x]</span>:valueString sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.effective<span class="error">[x]</span>, sowie dessen Kind-Element sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.category.coding, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Die Kardinalität von Observation.component:meanBP.code.coding sollte auf 2..2 angepasst werden.

Die Kardinalität von Observation.component:DiastolicBP.code.coding sollte auf 2..2 angepasst werden.

Die Kardinalität von Observation.component:SystolicBP.code.coding sollte auf 2..2 angepasst werden.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Der appointment.identifier sollte 0..1 sein, sonst geht diese Information verloren, falls diese vorhanden ist.

Die Kardinalität von Observation.code.coding sollte auf 2..2 angepasst werden.

Das Element Observation.category, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Die Kardinalität von Observation.code.coding sollte auf 2..2 angepasst werden.

Das Element Observation.category, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Die Kardinalität von Observation.code.coding sollte auf 2..2 angepasst werden.

Das Element Observation.category, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

In den Observation Ressourcen finden sich immer wieder unterschiedliche Benennungen von Code-Slices. Es wäre wünschenswert, diese einheitlich zu benennen.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Wir regen an, für jedes MS Feld eine Beschreibung zu hinterlegen. Dies würde die Verständlichkeit erhöhen und Missverständnisse vermeiden.

Es sollte eine fachliche Erläuterung in jeder Profilbeschreibung hinzugefügt werden, um die Verständlichkeit und den Einsatzzweck der Ressource besser zu verstehen.

Es sollte eine einheitliche Verwendung von fixedValues bzw. Pattern stattfinden und nicht in einem Profil fixedValues und im anderen Pattern. Dies führt zu Unübersichtlichkeit.

Im IG der DE Basisprofile wird für die Abbildung von Abrechnungsziffern die ChargeItem-Ressource empfohlen (<span class="nobr"><a href="https://ig.fhir.de/basisprofile-de/stable/Ressourcen-AbrechnungsdatenLeistungsziffernChargeItem.html" class="external-link" rel="nofollow">https://ig.fhir.de/basisprofile-de/stable/Ressourcen-AbrechnungsdatenLeistungsziffernChargeItem.html^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>). Warum hat sich die KBV gegen diesen Ressourcen-Typ ausgesprochen und verwendet den Claim Ressourcen-Typ?

Wenn ein Export der Patientenakte mit der Option “mit Terminen” gemäß Akzeptanzkriterium 7 stattfindet, sollen die Termine des Patienten dann Teil des Patientenakten-Bundles sein, oder sollen die Termine in dem Termin-Bundle gespeichert werden?

Warum gibt es keine dedizierte Anforderung für die Anlage des Sprechstundenbedarfs? Aktuell ist das Erzeugen des Sprechstundenbedarf-Bundles Teil der Anforderung KP4-04, jedoch geht aus der Anforderung die fachliche Verbindung zur Patientenakte nicht hervor.

Wie wirken sich die Suchparameter für die Einschränkung des Exports auf den Sprechstundenbedarf aus? Wenn man man z.B. die Patientenakte für einen Patienten exportiert ist es wahrscheinlich nicht notwendig den gesamten Sprechstundenbedarf zu exportieren.

Darüber hinaus enthält das Bundle für den Sprechstundenbedarf diese Entries:

• einen Slice für eine Composition für das Rezept
• und ein für den supplyRequest Sprechstundenbedarf

Wir gehen davon aus, dass Compositions für ein Rezept mit Patientenkontext (medicationRequest) nicht Bestandteil des Sprechstundenbedarf Bundles sein soll. Das muss noch ausspezifiziert werden.

Es wurde nicht definiert, wie mit Dokument-Metadaten (DocumentReference) umzugehen ist, bzw. konnte das aus der jetzigen Spezifikation durch uns nicht herausgelesen werden.

Die Anforderungen für die einzelnen Bundles (KP4-01, P4-02, P4-03, P4-04) geben dazu keine Auskunft In welchem Bundle werden die Metadaten welcher Dokumenttypen gespeichert?
Wenn die Unterscheidung nicht auf Basis von Dokumenttypen getroffen wird, wie werden Dokumente und deren Metadaten für den Export selektiert und einem Bundle zugeordnet?

Mögliche Bundles für das abspeichern der Dokument Metadaten:

• Bundle Adressbuch (KP4-02)
• Bundle Behandlungsbaustein (KP4-03)
• Bundle Patientenakte (KP4-04)
• Bundle Sprechstundenbedarf (KP4-04)
• Bundle Termin (KP4-01)

Dem stehen diese Ordner für Anlagen entgegen:

• Abrechnung
• Begegnung
• Behandler
• Behandlungsbaustein
• Betriebsstätte
• Patient
• Sonstige

Auf Basis der Zuordnung einer Anlage zu einem Ordner, kann nicht eindeutig das passende Bundle für die documentReference identifiziert werden.

Warum ist der Ordner Begegnung nicht ein Unterordner des Ordners Patient? Gibt es ein Dokument, das Fall-Kontext hat, aber keinen Patienten-Kontext? Med. Dokumente haben in der Regel einen Fall-Kontext und landen somit alle in einem gemeinsamen Ordner für die Begegnungen für alle Patienten. Ich glaube, die Auffindbarkeit wird hiermit nicht verbessert, da es nicht der gängigen Informationshierarchie folgt.

Akzeptanzkriterium 3 ist nicht nachvollziehbar:

“ (2) Im Ordner Begegnung müssen alle Anlagedateien (referenziert im KBV-Profil KBV_PR_AW_Anlage) die auf das KBV-Profil KBV_PR_AW_Begegnung referenzieren <span class="error">[...]</span> gespeichert werden

(3) Dies gilt ebenso für alle Instanzen, die auf das KBV-Profil KBV_PR_AW_Begegnung referenzieren und auf die aus dem KBV-Profil KBV_PR_AW_Anlage referenziert wird.”

Was für eine Konstellation ist damit gemeint?

Was passiert mit Dokumenten, die einen Patienten/Encounter und eine Claim Ressource referenzieren? In welchem Ordner soll diese gespeichert werden, Begegnung/Patient oder Abrechnung?

Die Einschränkung der Zuordnung zu dem Ordner passiert in der Spezifikation auf Basis eines Profils, das Profil kann nicht aus der Referenz in der documentReference ermittelt werden und würde eine Suche nach der Ressource im Bundle oder im Backend erfordern, um die Art der Abrechnung bzw. das Profil zu ermitteln. Ich befürchte, dass so etwas in einem Export sehr langsam wird. Wenn die Einschränkung auf Basis des Ressourcen-Typs erfolgt, wäre das nicht notwendig. Oder noch besser, auf Basis des Dokumenttyps in der documentReference.

Akzeptanzkriterium 3 schreibt, dass Verträge nicht in diesem Ordner gespeichert werden dürfen. Was sind “weitere Verträge” für die Abrechnung? Wie sind diese Verträge zu identifizieren, wenn diese auch einen Claim referenzieren?

Die Kardinalität von Observation.component:meanBP.code.coding sollte auf 2..2 angepasst werden.

Die Kardinalität von Observation.component:DiastolicBP.code.coding sollte auf 2..2 angepasst werden.

Die Kardinalität von Observation.component:SystolicBP.code.coding sollte auf 2..2 angepasst werden.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.code, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

In den Anforderungen KP5-54, KP5-55, KP5-56, KP5-57, KP5-58 wird festgelegt, dass entsprechend der referenzierte Ressourcen Anlagen in einen bestimmten Ordner kommen. Diese Zuordnung sollte auf basis standardisierter Dokumenttypen passieren, statt exportierende System zu zwingen, mögliche vorhandene Referenzen zu entfernen.
Darüber hinaus gibt es in der AWST Spezifikation keine Festlegung, welche Referenzen überhaupt zu einer documentReference hinzuzufügen sind.

Der aktuell spezifizierten Logik folgend, müsste die Einschränkung in P6-10 für Practitioner, practitionerRole und mehreren Organizations erweitert werden, um bei der Zuordnung der Dokumente gemäß KP5-54, KP5-55, KP5-56, KP5-57, KP5-58 Eindeutigkeit herzustellen.

• Wenn ein Dokument eine Referenz auf Patient und Organization Ressource hat, welche Referenz soll beim Exportieren entfernt werden?
• Wenn ein Dokument eine Referenz auf Patient und Practitioner Ressource hat, welche Referenz soll beim Exportieren entfernt werden?
• Was passiert mit Dokumenten, die eine Referenzen auf eine PractitionerRole Ressource haben?
• Was passiert mit Dokumenten, die eine Referenz auf Organization und Practitioner Ressource haben, welche Referenz soll beim Exportieren entfernt werden?
• Was passiert mit Dokumenten, die eine Organization, Practitioner und einen Behandlungsbaustein Ressource referenzieren?
• Was passiert mit Dokumenten, die eigene Betriebsstätte und eine andere Organization Ressource referenzieren (z.B. andere Betriebsstätte oder Krankenkasse?)

Das Problem lässt sich bei einer Zuordnung auf Basis von standardisierten Dokumenttypen umgehen.

Die Kardinalität von Observation.code.coding sollte auf 2..2 angepasst werden.

Das Element Observation.category, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Die Kardinalität von Observation.code.coding sollte auf 2..2 angepasst werden.

Das Element Observation.category, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Die Kardinalität von Observation.code.coding sollte auf 2..2 angepasst werden.

Das Element Observation.category, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Die Kardinalität von Observation.code.coding sollte auf 2..2 angepasst werden.

Das Element Observation.category, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Zur Verbesserung der Interoperabilität, Kompatibilität mit der TI ePA und ISiK und der Implementierbarkeit der AWST sollten standardisierte Dokumenttypen für med. Dokumente verwendet werden. Zum Beispiel die DokTypen der KDL, für welches Code-System auch ein XDS-Mapping existiert. <span class="nobr"><a href="https://simplifier.net/kdl/codesystem-kdl-2022" class="external-link" rel="nofollow">https://simplifier.net/kdl/codesystem-kdl-2022^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Fehlende Codes für Dokumente, die nur im Kontext einer PVS Migration existieren (Anlage als Fallback-Mechanismus), sollten in einem eigenen Code-System definiert werden.

Einrichtungs-/Behandler-bezogene Doktypen ohne einen Patientenkontext (z.B. erzeugte Statistiken und Übersichten) sollten in einem eigenen CodeSystem abgebildet sein, um diese Semantik über das CodeSystem herzustellen.

Auf basis von standardisierten Dokumenttypen lassen sich folgende Sachverhalte in der AWST Spezifikation verbessern:

• Dokumente eindeutig einem Ordner in der Datenstruktur zuordnen
• Dokumente eindeutig einem Bundle zuordnen
• Vorhandene Referenzen in Dokument Metadaten müssen beim Export nicht entfernt werden
• Dokumente können nicht auf Basis der Referenz in den Metadaten einem Ordner zugeordnet werden, da in der Referenz das Profil der referenzierten Ressource nicht bekannt ist.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Die Kardinalität von Observation.code.coding sollte auf 2..2 angepasst werden.

Das Element Observation.category, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Es reicht unserer Meinung nach nicht aus, nur festzulegen, dass eine documentReference genau eine Referenz (Patient, Betriebsstätte, Begegnung) haben muss (P6-10).

Zum einen bedeutet dies für das exportierende System bedeutet, dass evtl. vorhandene Informationen weggeschmissen werden und kollidiert mit der Anforderung P3-07.

Gleichzeitig gibt es in Abhängigkeit des Dokumenttyps eine Reihenfolge der Wichtigkeit der referenzierten Informationen.
z.B: Alle Dokumente mit einem Encounter-Kontext haben automatisch auch einen Patienten-Kontext. Der Encounter-Kontext sollte nie in einer documentReference entfernt werden, wenn dieser vorhanden ist.

“Jede Anlage hat genau eine Beziehung zu einer Begegnung, einem Patienten oder einer Betriebsstätte. Diese Beziehung kann allerdings durch eine weitere Referenz (z. B. auf einen Befund) typisiert werden.”

Was bedeutet die Typisierung dieser Beziehung? Welche Information soll dadurch ausgedrückt werden? Diese weitere Referenz kann einen Kontext zu einem anderen Informationsobjekt herstellen, aber nicht das Dokument oder eine andere Referenz in der Ressource typisieren.

Da referenzierte Ressourcen zu den Bundles hinzugefügt werden, sind die gleichen Ressourcen in verschiedenen Bundles enthalten (z.B. Organization, Practitioner). Die Informationen sind somit redundant. Es braucht eine stabile logische Ressourcen-ID, damit sich die Daten beim Import wieder zusammenführen lassen.
Fachlich sollte ausgeschlossen werden, dass Ressourcen IDs nur im Kontext eines Bundles existiern und beim Erstellen des Bundels dynamisch generiert werden.

• Das erfordert, dass die gleiche Ressource in jedem Bundle auch die gleiche logische Ressourcen-ID hat.
• Die logische Ressourcen-ID einer Ressource muss immer gleich bleiben, auch bei einem mehrfachen Export der gleichen Daten.

Die aktuelle Angabe der verwendeten Code-Systeme <span class="nobr"><a href="https://hub.kbv.de/display/AWS/Verwendete+Code-Systeme" class="external-link" rel="nofollow">https://hub.kbv.de/display/AWS/Verwendete+Code-Systeme^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> sieht nach einem Copy-Paste von einer MIO Seite aus. Ist es möglich, eine vollständige Liste aller verwendeter Code System zu bekommen, die nicht von HL7 International definiert sind?

• Alle verwendeten Kataloge (ICD10, AlphaID, EBM, PZN,…)
• Alle verwendeten Code Systeme der KBV Basis
• Alle verwendeten Code Systeme aus der HL7 DE Basis
• Alle weiteren DE standard Code Systeme

Alle Dummy-Werte sollten mit der Data-Absent-Reason Extension versehen werden, ansonsten geht diese Information verloren. Das exportierende System sollte angeben, ob ein Wert unbekannt ist oder nicht-supported, da das ein fachlicher Unterschied ist. <span class="nobr"><a href="https://www.hl7.org/fhir/valueset-data-absent-reason.html" class="external-link" rel="nofollow">https://www.hl7.org/fhir/valueset-data-absent-reason.html^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Ist dieses Vorgehen nur für die Patienten Ressource und der documentReference Ressource (Anlage) vorgesehen? Was ist mit allen anderen Ressourcen?

Es gibt eine Welt vor der AWST mit legacy Daten. Diese Daten lassen sich u.U. nicht in eine FHIR kompatible Datenstruktur migrieren und evtl. auch nicht anreichern, um eine valide FHIR-Ressource zu erzeugen. Somit würde eine gesamte Ressource nicht exportiert werden können, weil ein Element fehlt. Durch den Fallback auf ein generiertes PDF Dokument gehen u.U. strukturierte Informationen, die dem Standard entsprechen, für den Import verloren.

Parallel muss davon ausgegangen werden, dass in der Praxis beim Export Dummy-Werte eingestzt werden, um MustSupport und 1..1 Element in den FHIR Ressourcen zu befüllen, damit die Ressourcen erfolgreich validiert werden können bzw. das System zu zertifizieren.

Wenn Daten inkompatibel sind, nicht vorhanden sind oder nicht verarbeitet werden, sollte es zusätzlich zum PDF-Fallback den Weg geben, die Data-Absent-Reason Extension einzufügen, um die strukturierten Informationen zu exportieren.

Auf organisatorischem Wege muss festgelegt sein, dass die Data-Absent-Reason Extension als Fallback nur für historische Daten verwendet wird. Entsprechend darf der Fallback nicht für Daten verwendet werden, die mit einer AWST-zertifizierten Programmversion des PVS erstellt wurden, da davon auszgehen ist, dass in der zertifizierten Programmversion das Problem bzw. die Inkompatibilität behoben wurde.

Es ist möglich mittels passendem Testfällen und Testdaten die Vollständigkeit des Exports/Imports eines Systems zu überprüfen. Import eines Maximaldatensatz, mit anschließendem Export der Testdaten, wobei in diesem Export kein Data-Absent-Reason vorhanden sein darf, da die Testdaten vollständig sind.

Im Sinne der Standardisierung muss eine Variante für das Referenzieren von Ressourcen vorgegeben sein (Logische Referenzen vs. Absolute/Relative Referenzen).

Beim Import von Daten müssen im Zielsystzem die Referenzen zwischen Informationsobjekten auf Basis der im Export bereitgestellten Referenzen wieder hergestellt werden. Bei der Verwendung logischen Referenzen muss immer über den Business Identifier das zu verlinkende Objekt gesucht werden, was sehr teuer/aufwändig werden kann.

Bei relativen Referenzen könnte man hingegen beim Import mit einem Look-up Table für die Ressourcen IDs aus dem Export- und Importsystem arbeiten, was die Performance des Imports verbessert.

Worst-Case-Szenario ist, wenn für den Export nichts festgelegt ist und man Referenzen immer unterschiedlich behandeln kann (ggf. unterschiedlich je Ressource oder gar unterschiedlich innerhalb eines einzelnen Ressourcentyps). Meiner Meinung nach sollte immer eine relative Referenz auf die Ressource angegeben werden und es den Systemen überlassen sein, ob zusätzlich die Business Identifier oder Name in der Referenz mit übertragen werden.

In vielen Profilen der AWST folgt man diesem Ansatz und macht die Referenz zu einem verpflichtenden Element. Hier sollte man evtl. noch definieren, dass es sich um eine relative Referenz handelt.

Beim Export vorhandene Informationen sollten auf keinen Fall entfernt werden. Ich glaub man wird bei ganz anderen Teilen der Spezifikation Probleme mit dem Datenvolumen haben:

• bei der Historie
  -bei Provenance Ressource
  -bei dem Hinzufügen aller referenzierter Ressourcen zu einem Bundle (Administrative -Ressourcen inklusive deren Historie werden Teil aller Bundels sein)
• Generierung der Narrative mit sämtlichen Inhalten + anschließender Konvertierung zu PDF

Vor diesem Hintergrund werden die 3 Elemente zusätzlichen einer Referenz im Volumen wahrscheinlich nicht auffallen.

Falls in der Anforderung P3-19 andere URLs gemeinst sein sollten, geht das nicht aus der Anforderung hervor und muss konkretisiert werden.

Es gibt für diese konditionale Pflichtfunktionen keine Bedingung in den Anforderungen.

• KP3-08
• KP3-09

Anforderung: In den BUNDLE-Dateien müssen alle für das jeweilige BUNDLE definierten Ressourcen aufgenommen werden. Dabei sind die Definitionen für die unterschiedlichen Ressourcentypen zu beachten.

Definition im laut Root-Element in den FHIR Profilen: Das Bundle fasst alle Inhalte der Patientenakte zusammen. In dem Element Entry wurde nur die erste Ebene der Ressourcen angegeben, d.h. es wurden nur die Ressourcen explizit aufgeführt, die auf andere Ressourcen verweisen und auf die, im Sinne dieses Bundles, selbst nicht referenziert werden.

• Patientenakte: enthält keine Bundle.entries
• Adressbuch: enthält keine Bundle.entries
• Behandlungsbaustein: Bundle.entires sind definiert, aber Anlage fehlt
• Sprechstundenbedarf: Bundle.entries sind definiert, aber Anlage fehlt
• Termin: Bundle.entries sind definiert, aber Anlage fehlt

Das definierte Constraint (care-lvl-de-1:Es dürfen maximal zwei OPS-Codes für den Pflegegrad angegeben werden.) verstehen wir in Bezug auf den Pflegegrad nicht. Könnten Sie dies erläutern und ggf. prüfen?

Gibt es für diese Observation keinen passenden Snomed-CT-Code? Falls doch, wäre es wünschenswert, wenn diese auch Teil des Profiles wird. Entsprechend müssten dann auch die Kardinalitäten der Slices angepasst werden und diese mit einem MS versehen werden.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.code.coding:loinc, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Es fehlt ein Element, wo dokumentiert werden kann, wie viel ein Patient raucht. Dies könnte auch eine eigenständige Ressource sein.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.code, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Wir sind der Meinung, dass die derzeitige Profilierung nicht korrekt ist.

Die Beschreibung des Profils sagt, das: "In dieser Ressource wird der Schwangerschaftsstatus dokumentiert." Dies ist so nicht korrekt, da da noch andere Infos mit profiliert sind - siehe Components. Die Infos der Components passen nicht mit dem definierten LOINC-Code zusammen.

Wir regen an, für jedes Component-Slice ein eigenes Profil anzulegen. Diese könnten z.B. durch “Observation.derivedFrom” gruppiert werden, um den Kontext beizubehalten.

Das Element Observation.performer sollte zugelassen werden, um den direkten Verweis herzustellen (ohne den “Umweg” über den Encounter).

Das Element Observation.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.code.coding sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Observation.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Es sollte die Möglichkeit geschaffen werden zusätzliche Informationen zu übertragen (analog zu der Extension im Practitioner)

Gibt es die Möglichkeit zum Übertragen von Bankinformationen für eine Organisation?

Das Element Organization.address:Postfach sollte mit einem MS versehen werden.

Das Element Organization.address:Strassenanschrift sollte mit einem MS versehen werden.

Das Element Organization.identifier, sowie sämtliche Slices und sämtliche 1..1 Kind-Elemente sollten mit einem MS versehen werden.

Das Element Organization.extension:Adressbuchzuordnung sollte mit einem MS versehen werden.

Das Element Organization.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Organization.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Organization.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Gibt es eine Möglichkeit IV-Verträge von Patienten zu dokumentieren? Wenn nicht, ist dies geplant?

Das Element Patient.generalPractitioner.display sollte mit einem MS versehen werden.

Das Element Patient.generalPractitioner.identifier, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden.

Das Element Patient.communication.preferred sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Patient.communication.language, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Patient.contact sollte mit einem MS versehen werden.

Das Element Patient.birthDate.extension:data-absent-reason sollte mit einem MS versehen werden.

Das Element Patient.gender.extension:other-amtlich sollte mit einem MS versehen werden.

Das Element Patient.name:stammdaten sollte mit einem MS versehen werden.

Das Element Patient.name:geburtsname sollte mit einem MS versehen werden.

Das Element Patient.identifier:versichertenId_PKV.value sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Patient.identifier:versichertenId_PKV.system sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Jedes type-Element (und die 1..1 Kind-Elemente) jedes Slices von Patient.identifier sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Patient.extension:versichertendaten_Zusatzinformationen.extension:adresse-Postfach.value<span class="error">[x]</span>, sowie das entsprechende Kind-Element sollten mit einem MS versehen werden.

Das Element Patient.extension:versichertendaten_Zusatzinformationen.extension:adresse-Strassenadresse.value<span class="error">[x]</span>, sowie die Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Patient.extension:versichertendaten_Zusatzinformationen.extension:geburtsdatum.value<span class="error">[x]</span>, sowie das Kind-Element sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Patient.extension:versichertendaten_Zusatzinformationen.extension:geschlecht.value<span class="error">[x]</span>, sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Patient.extension:zusatzinformationen.extension:religionszugehoerigkeit.value<span class="error">[x]</span>, sowie das Kind-Element sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Patient.extension:aktuelle_Taetigkeit.extension:arbeitgeber.value<span class="error">[x]</span>, sowie die Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Patient.extension:aktuelle_Taetigkeit.extension:aktuelle_Taetigkeit.value<span class="error">[x]</span>, sowie das Kind-Element sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Patient.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Patient.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Patient.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Person.identifier sollte zugelassen werden, um der Person einen generischen Identifier geben zu können (z.B. ein Kürzel).

Das Element Person.managingOrganization.reference sollte mit einem MS versehen werden.

Das Element Person.gender.extension:gender-amtlich sollte mit einem MS versehen werden, da sonst - bei Fehlen des Geburtsdatums - das Profil nicht validiert werden kann falls die Extension nicht unterstützt wird.

Das Element Person.telecom.value sollte mit einem MS versehen werden.

Das Element Person.telecom.system sollte mit einem MS versehen werden.

Das Element Person.extension:schlusssatz.value<span class="error">[x]</span>:valueString sollte mit einem MS versehen werden.

Das Element Person.extension:anrede.value<span class="error">[x]</span>:valueString sollte mit einem MS versehen werden.

Das Element Person.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Person.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Person.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Provenance.agent.onBehalfOf.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Provenance.target.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Provenance.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Provenance.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Provenance.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Wir regen an, eine Extension ähnlich der KBV_EX_AW_Report_Import_Information dem Report_Export hinzuzufügen. In dieser müssen dann nicht exportierbare Inhalte übertragen werden.

Das Element AuditEvent.outcome sollte zugelassen werden, um das Ergebnis des Exports zu übertragen.

Das Element AuditEvent.entity.detail:Filter.value<span class="error">[x]</span>:valueString sollte mit einem MS versehen werden.

Das Element AuditEvent.entity.detail:Filter.value<span class="error">[x]</span>:valueString sollte mit einer 1..1 Kardinalität versehen werden.

Das Element AuditEvent.agent:export_Software.who.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.type sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.contained sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.entity.what.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.agent:import_Software.who.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.type sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.extension:nicht_importierbare_inhalte.extension:elementProfil.value<span class="error">[x]</span>:valueString sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.extension:nicht_importierbare_inhalte.extension:loesungAenderung.value<span class="error">[x]</span>:valueString sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.extension:nicht_importierbare_inhalte.extension:narrativ.value<span class="error">[x]</span>:valueString sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.extension:nicht_importierbare_inhalte.extension:begruendung.value<span class="error">[x]</span>:valueString sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.extension:nicht_importierbare_inhalte.extension:element.value<span class="error">[x]</span>:valueUrl sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.contained sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element AuditEvent.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Es können also nur elektronische Rezepte in der AWST übertragen werden? Was passiert mit “alten” Rezepten?

Die Kardinalität der Extensions sollte auf 0..2 beschränkt werden.

Die Kardinalität der Extensions sollte auf 1..5 beschränkt werden.

Im Zuge des Vergleichs mit dem eRezept ist aufgefallen, dass im eRezept nur 4 Extensions entsprechend der Kardinalität möglich sind, jedoch unter Umständen 5 Extensions vorkommen können.

Die Kardinalität der Extensions sollte auf 0..2 beschränkt werden.

Die Kardinalität der Extensions sollte auf 0..3 beschränkt werden.

Die Kardinalität der Extensions sollte auf 2..4 beschränkt werden.

Die Extension MedicationRequest.extension:Mehrfachverordnung fehlt im Profil. Wie wird in der AWST der Fakt einer Mehrfachverordnung übertragen?

Das Element Contract.author sollte zugelassen werden, um eventuell vorhandene Informationen des Vertrages zu transportieren. Ohne dieses Element (Betreu-/Vertreterarzt) könnten Daten verloren gehen.

Das Element Contract.title sollte zugelassen werden, um eventuell vorhandene Informationen des Vertrages zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Contract.name sollte zugelassen werden, um eventuell vorhandene Informationen des Vertrages zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Contract.term.offer.party.reference.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Contract.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Contract.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Contract.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Contract.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.note sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.performer sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.recorder sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.performed<span class="error">[x]</span> sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.code.text sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.category.coding sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Sämtliche Informationen zur “Vostellungspflicht beim D-Arzt” der Ärztlichen Unfallmeldung (Formular F1050) fehlen.

Die Angaben zum “Beschäftigt seit” der Ärztlichen Unfallmeldung (Formular F1050) fehlen. Diese sollten in der Extension Patient.extension:aktuelle_Taetigkeit
im Profil KBV_PR_AW_Patient untergebracht werden.

Die Angaben zum “Eintreffen um (Uhrzeit)” der Ärztlichen Unfallmeldung (Formular F1050) fehlen im Profil.

Die Angaben zum “Eintreffen am” der Ärztlichen Unfallmeldung (Formular F1050) fehlen im Profil.

Die laufende Nummer der Ärztlichen Unfallmeldung (Formular F1050) könnte in Condition.identifier untergebracht werden.

Das Element Condition.note.text sollte mit einem MS versehen werden.

Das Element Condition.onset<span class="error">[x]</span>:onsetDateTime sollte mit einem MS versehen werden.

Das Element Condition.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.extension:notwendige_Zusatzinformationen sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Condition.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Location.type.coding sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Location.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Location.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Location.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.focalDevice sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.note sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.followUp sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.complicationDetail sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.complication sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.report sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.outcome sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.bodySite sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.reasonReference sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.reasonCode sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.performer sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.recorder sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Wie sieht die Roadmap für die AWST aus, um Datenportabilität in Deutschland herzustellen? Eine Einordnung dieser Ziele/Anwendungsfälle ist wünschenswert:

• Ablösung BDT/xBDT als defakto-Standard (Erweiterung des Scopes der AWST zum MVP)
• Verpflichtung von aktuell optionalen Profilen
• Harmonisierung mit anderen Deutschen Interop Standards
• MIO Integration in die AWST
• Positionierung des Bulk Data Export/Import auf der Roadmap
• Stabilität in die Profile für Abwärtskompatibilität

Eine Roadmap könnte dem Thema Datenportabilität eine Perspektive aufzeigen und es den Herstellern erlauben, Entwicklungen so zu planen, dass Synergien bei der Umsetzung anderer Interoperabilitätsanforderungen entstehen.

Das Element Procedure.statusReason sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.partOf sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.basedOn sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.identifier sollte zugelassen werden, um eventuell vorhandene Informationen der Untersuchung zu transportieren. Ohne dieses Element könnten Daten verloren gehen.

Das Element Procedure.encounter.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.category.coding:Klassifizierung_der_Ressource sowie alle 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Procedure.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Aktuell sind nur Teile der definierten Profile verpflichtend (siehe Liste der Profile im Dokument mit den Festlegungen zur AWST). Es noch nicht möglich, basierend auf der AWST ein Primärsystem zu migrieren. Unserer Meinung nach sollte die AWST den Umfang des BDT/xBDT Formats abdecken, damit Datenmigrationen möglich werden.

Das Element Procedure.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Es scheint eine falsche fachliche Beschreibung vorhanden zu sein. Der Definitionstext der Resource passt besser zur genetischen Untersuchung.

Das Element Consent.provision.actor:aufbewahrt_von.reference.reference sollte mit einem MS versehen werden, da das Eltern-Element ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.provision.actor:betreuer.reference.reference sollte mit einem MS versehen werden, da das Eltern-Element ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.provision.actor:betreuer weist eine unvollständige Definition auf.

Das Element Consent.policy sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.source<span class="error">[x]</span>:sourceReference.reference sollte mit einem MS versehen werden, da das Eltern-Element auch ein MS Element ist und entsprechendes Element das einzige Kind-Element ist.

Das Element Consent.source<span class="error">[x]</span>:sourceReference sollte mit einem MS versehen werden, da das Eltern-Element auch ein MS Element ist und entsprechendes Element das einzige Kind-Element ist.

Das Element Consent.patient.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.category.coding sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.scope sowie die 1..1 Kind-Elemente sollten mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Consent.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element ServiceRequest.performer.display sollte erlaubt werden, da dies eine direkte Abbildung des Feld 4243 im KVDT sein könnte. Unter Umständen ist eine Referenz im System zu einer Betriebsstätte/Arzt nicht möglich. Dieses Element sollte auch mit einem MS versehen werden.

Das Element ServiceRequest.requester sollte erlaubt werden, um eine direkte Beziehung zwischen dem ausstellenden und empfangenden Arzt herzustellen. Dieses Element sollte auch mit einem MS versehen werden.

Das Element ServiceRequest.subject.reference sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element ServiceRequest.intent sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element ServiceRequest.status sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.meta.profile sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.meta.lastUpdated sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Das Element Claim.meta.versionId sollte mit einem MS versehen werden, da es ein 1..1 Element ist und das Profil bei Fehlen nicht validiert werden kann.

Folgende Paketabhängigkeiten sind definiert:

• KBV AWST 1.3.0 → Basiert auf HL7 DE Basis Profile 1.3.2
• KBV AWST 1.2.0 → Basiert auf HL7 DE Basis Profile 0.9.12

In der AWST 1.3.0 wird ein Paket mit Breaking-Changes der HL7 DE Basisprofilen verwendet, somit gibt es zwischen Version 1.2.0 und 1.3.0 auch Breaking-Changes.

Beispiel von Breaking-Changes in der AWST:

• Die Verwendung des ICD-10 Coding-Profils aus der HL7 DE Basis in der Diagnose: <span class="nobr"><a href="https://ig.fhir.de/basisprofile-de/stable/Ressourcen-DiagnosenCondition.html" class="external-link" rel="nofollow">https://ig.fhir.de/basisprofile-de/stable/Ressourcen-DiagnosenCondition.html^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
• Einführung geänderter Canonical URLs für CodeSystem in Basis Profilen, was eine Datenmigration zwischen 1.2.0 und 1.3.0 erforderlich machen kann.
• Änderungen der Kardinalität in Profilen von 0..1 auf 1..1

Gemäß Guidelines zur Versionierung <span class="nobr"><a href="https://docs.npmjs.com/about-semantic-versioning" class="external-link" rel="nofollow">https://docs.npmjs.com/about-semantic-versioning^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> ist die Abwärtskompatibilität nicht mehr gegeben. Auch die Anforderung P6-20 weißt darauf hin, dass eine Abwärtskompatibilität bei der AWST nicht gegeben ist.

Wir sind der Auffassung, dass die Versionsnummer auf 2.0.0 geändert werden muss und darauf hingewiesen werden sollte, wo es in der Spezifikation Breaking-Changes gibt.

Keine Rezertifizierung bereits etablierter Primärsysteme ist eine Ungleichbehandlung und widerspricht dem eigentlichen Ziel der AWST, der Datenportabilität. Erfahrungsgemäß ist davon auszugehen, dass die Erweiterungen nicht vollumfänglich oder in der notwendigen Qualität (Breaking-Changes zwischen den AWST-Versionen) umgesetzt werden.

FHIR Profile bieten die Möglichkeit, jedem Element ein maschinenlesbares Mapping mitzugeben. Teilweise ist das für Informationen aus dem KVDT Datensatz bereits in den spezifizierten Profilen hinterlegt (z.B. Patient).

Es ist anzunehmen, dass Informationen dieser Formate in den am Markt existierenden PVS umgesetzt sind. Um die Implementierbarkeit durch PVS Hersteller zu verbessern, die Spezifikation eindeutiger zu machen, das Daten-Mapping zu standardisieren und die Vollständigkeit der AWST garantieren, sollten die bereits existierenden Datenformate auf die jeweiligen FHIR Ressourcen und Elemente gemappt werden.

Wir würden es Begrüßen, wenn folgende Mappings als Teil der FHIR Profile bereitgestellt werden:

• Vollständiges KVDT Mappings in den FHIR Profilen
• Vollständiges BDT Mappings in den FHIR Profilen
• Vollständiges LDT Mappings in den FHIR Profilen

Es gibt keine Festlegungen/Anforderungen, wie die Bundles zu validieren sind. Das kann beispielsweise mit dem FHIR Validator oder aber auch mit einem XML Schema passieren. Die Ergebnisse der Validierung werden wahrscheinlich unterschiedlich sein.

Ein valides Export-Bundle kann beim Import u.U. nicht validiert werden. Eine aussagekräftige Fehlermeldung wird dabei auch nicht möglich sein, da es sich um das Bundle eines anderen Systems handelt.

Der Alles-oder-Nichts Ansatz ist aus Sicht der Vollständigkeit und Korrektheit zwar nachvollziehbar, wird aber zu einem Problem, wenn nur ein Element nicht valide ist oder die Validierung im Export- und Import-System jeweils unterschiedlich implementiert wurde.

Die Implementierbarkeit und das Funktionieren des Exports und Imports in produktiven Systemen (mit Legacy-Daten) erfordert meiner Meinung nach die Verwendung eines bereitgestellten Referenzvalidators der beim Export- und Importschritt gleiche Validierungsergebnisse liefern wird.

Das Profil KBV_PR_AW_Person repräsentiert eine generische Person. Das kann bspw. ein Anwender, Arzt, MA, Patient etc. sein. Wie kann beim Import einer Person die richtige Zuordnung im Zieldatenmodell garantiert werden?
Können Sie bitte ein Beispiel nennen?

„Die Schnittstellenfestlegung tritt am Tag nach der Veröffentlichung in Kraft. Gleichzeitig tritt die Festlegung „Version 1.2.0“ außer Kraft.“ <span class="error">[Kapitel 6 Gültigkeit]</span>

Anwender möchte auf ein Zielsystem wechseln das noch nicht die Version 1.3.0 unterstützt. Dann muss folglich die Export/Import-Version auswählbar sein.

Ist dies ein zu unterstützendes Szenario bzw. wird es für Kunden eine Übergangsfrist für den Wechsel von Schnittstellenversion 1.2.0 auf 1.3.0 geben?

Wenn ja, sollte dann nur die Vorgängerversion berücksichtigt werden?

Unseres Wissens nach ist ein Kassenschein immer einer Betriebsstätte und nicht einer Kombination aus Betriebsstätte und Arzt zugeordnet. Daher sollte als Referenz beim Provider Organization zu verwenden sein und nicht PractitionerRole.

Beispiel und Rahmenbedingungen wie die PDFs aus Sicht der KBV auszusehen haben bzw was sie enthalten sollen wäre sehr hilfreich.

Müssen wirklich alle Informationen aus der XML auch ins PDF oder kann das reduziert wenn, wenn ja welche Bedingungen gibt es dafür.

Auf Grund der Performance kommen wir in Extrapolationen zu dem Problem, dass ein Wechsel des Systems auf Grund der Validierung mehrere Tage dauern kann.

Folgende Lösung haben wir dafür angedacht:

Trennung der Funktionalität von Archivierung und Wechsel.
Vorab: Auch bei der Trennung in der Anwendungen bleiben die Profile für beide Anwendungen die gleichen.

Bei der Archivierung sollte wie bisher ein XML-Bundle und eine PDF erzeugt werden.

Für den Wechsel zwischen zwei Systemen haben wir folgenden Vorschlag:

In der Zeit des Wechsels müssen beide Server laufen. Beide Server besitzen entsprechende FHIR-Rest-Endpunkte.
Das neue System kann dann die Daten aus dem alten System in einer für es selbst passenden Form abfragen. Zum Beispiel erst die Benutzer, dann die Ärzte, dann die Pateintenstammdaten, dann die Scheine des aktuellen Quartals,...
Ein Vorteil dieser Variante ist, dass das Abfragende System deutlich einfacher die Daten ins eigene System übertragen kann und Dopplungen vermieden werden (keine Prüfung mehr nötig, z.B. ob der entsprechende Arzt schon importiert wurde aus einem anderen Patienten-Bundle).
Zudem ist bei diesem Verfahren möglich, dass das neue System gezielt nur die Patientenstammdaten und alle nicht abgerechneten Scheine, Privatabrechnungen zuerst ins neue System überträgt. Somit wird die Unterbrechung von möglicherweise Tagen(Hochrechnung) deutlich reduziert. Die restlichen Daten könnte das neue System dann im Hintergrund vom Altsystem abfragen und übernehmen.

Aus usnerer Sicht würde das die Nutzbarkeit der Schnittstelle deutlich verbessern.

Auf der Seite Change log (<span class="nobr"><a href="https://hub.kbv.de/display/AWS/Change+log+-+Version+1.3.0" class="external-link" rel="nofollow">https://hub.kbv.de/display/AWS/Change+log+-+Version+1.3.0^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>) ist im Abschnitt Bundle_* die Änderung "Verpflichtung von response.lastupdatet 1..1" aufgeführt.

Das Profil Bundle stellt allerdings nur den Parameter "Bundle.entry.response.lastModified" zur Verfügung. Vermutlich ist es im Changelog nur zu einer Verwechslung gekommen und es müsste hier heißen: "Verpflichtung von response.lastModified 1..1"

4.4, Seite 39: "Bei einem fehlerhaften Export sind alle erzeugten Dateien und Verzeichnisse zu löschen. Der Nutzer ist entsprechend unter Angabe der Fehlerursache darüber zu informieren. Die Reportdatei darf in diesem Fall nicht erzeugt werden.."

Aus unserer Erfahrung führt dieser "alles-oder-nichts"-Ansatz zu Problemen bei großen Exporten, die aufgrund von Fehlern abbrechen. Es wäre besser, wenn sich der Export "merkt", welche Daten bereits exportiert wurden und in der Lage wäre, beliebig neu zu starten und dann an der Stelle weiter zu extrahieren, an der der Abbruch erfolgte.

4.4, Seite 39: "Für die Daten der zusätzlichen Module mit KBV-Zertifizierung wie z.B. eDMP, LDT und eDoku gibt es keine Informationsobjekte. Diese Daten sind im Format und Version der jeweiligen Schnittstelle, die zum Zeitpunkt der Erstellung der Daten gültig war, in Form einer Anlage zu übertragen."
In unserem PVS werden die Exporte, z.B. für DMP, nicht in der exportierten Form als XML-Datei erhalten; es werden für eine DMP-Dokumentation nur alle Daten gespeichert. Aus den Daten wird das XML erzeugt und kann auch jederzeit wieder erzeugt werden. Aufgrund der laufenden Änderungen an der DMP-Schnittstelle werden aber nur die jeweils gültigen Vorschriften zur Erzeugung im System vorgehalten, eine Erstellung in einem historischen Format ist nicht möglich und auch nicht sinnvoll, da die Datenannahmestellen historische Formate im Zweifelsfall auch nicht mehr einlesen können.

{color:#172b4d}Das KBV-Profil KBV_PR_AW_Medikament wird mit der Integration der eRezept-Profile überflüssig. Die Inhalte lassen sich nun mit den Profilen KBV_PR_AW_Rezept_Medication_* abbilden.{color}

In Kapitel 3 Einleitung wird festgelegt, dass trotz Erweiterung des Schnittstellenumfangs keine neue Zertifizierung notwendig wird. Dies wird erfahrungsgemäß dazu führen, dass die Erweiterungen nicht oder nicht vollumfänglich umgesetzt werden. Zugleich dient eine Zertifizierung auch der Qualitätskontrolle sowie der Klärung von Anforderungen, weswegen es wünschenswert wäre, wenn eine Zertifizierung durchgeführt wird.