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.