Seitenhistorie
...
| Kommentarthema | Ergebnis |
|---|---|
| Ist es sinnvoller, den Barthel-Index als eine Observation zu modellieren und die jeweiligen Abschnitte als components dieser Observation abzubilden? | Die Option eine Observation mit mehreren Components umzusetzen wurde ausgeschlossen, da für jede einzelne Funktionsbeurteilung wie bspw. "Aufstehen und Gehen" auch separat das Datum der Beurteilung angegeben werden soll. Eine Abbildung des Datums in Observation.component ist jedoch nicht vorgesehen. Es soll zudem ermöglicht werden, dass die Funktionsbeurteilungen auch alleinstehend und ohne das Summenergebnis des Barthel-Index angegeben werden können. |
| Warum wird im Fallbeispiel 1 für den Practitioner (Musterpfleger) für identifier.system ein fixed value angegeben, welcher nicht in der FHIR-Spezifikation spezifiziert wird? Diese spezifiziert nur die ANR, EFN und ZANR näher, allerdings nicht die Telematik-ID, die in diesem Fall genutzt wird. | Der Practitioner (Musterpfleger https://simplifier.net/ulb/9587cccb-00ec-4c65-a1ee-61135bdf8391) in Beispiel 1 hat einen Identifikator für Pflegefachpersonen, den sogenannten Heilberufeausweis. Dieser wird durch unser Profil KBV_PR_MIO_ULB_Practitioner nicht spezifiziert. Dieses spezifiziert bisher nur die ANR, EFN und ZANR und gibt diesen unter identifier.system einen "fixed value", welcher auf den Vorgaben von HL7 Deutschland beruht. Das Profil bietet allerdings die Möglichkeit, einen noch nicht durch das Profil spezifizierten Identifikator anzugeben (erkennbar, wenn man auf Simplifier im Profil KBV_PR_MIO_ULB_Practitioner "identifier" auswählt, worauf sich rechts ein Kasten öffnet, der unter Sliced u. a. folgendes angibt: "Open"). Im Fallbeispiel 1 wird diese Möglichkeit genutzt. Vorgaben zur Abbildung des elektronischen Heilberufeausweises macht HL7 Deutschland mit einem entsprechenden identifier-Profil, an dem wir uns im Beispiel orientieren. Das identifier-Profil (Telematik-ID) können Sie hier abrufen: https://simplifier.net/basisprofil-de-r4/identifiertelematikid. Dort können Sie auch den übernommenen fixed value für identifier.system finden. In der nächsten Version der KBV-Basis-Profile wird die Telematik-ID als identifier mit eingebunden werden, sodass diese dann auch für unsere MIOs/PIOs zur Verfügung steht und dieser momentan etwas umständliche Weg nicht mehr gegangen werden muss. |
| Warum gibt es bei Patient.birthDate.extension:data-absent-reason die Möglichkeit einen data-absent-reason anzugeben, wenn der value bereits auf "unknown" fixiert wurde? Dieser Wert sollte aus dem entsprechendem Codesystem frei wählbar sein, um einen wirklichen Grund angeben zu können, warum das Geburtsdatum fehlt. | Es wird grundsätzlich davon ausgegangen, dass das Geburtsdatum immer vorhanden ist und angegeben werden kann. In nicht näher definierten Ausnahmefällen ist jedoch eine Nichtangabe gestattet. Normalerweise gibt es hierfür den Ersatzwert 00000000. Werden die Patientendaten von einer eGK eingelesen, kann auf dieser bereits der Ersatzwert vorkommen. In FHIR® kann der Ersatzwert nicht hinterlegt werden. Aus diesem Grund wurde eine Extension eingebunden, welche den Wert "unknown" enthalten muss. Dieser Wert dient damit als Platzhalter für den Ersatzwert. |
Warum gibt es bei Provenance.agent.who.extension:data-absent-reason die Möglichkeit eine data-absent-reason anzugeben, wenn der value bereits auf "unknown" fixiert wurde? Dieser Wert sollte aus dem entsprechendem Codesystem frei wählbar sein, um einen wirklichen Grund angeben zu können, warum das Geburtsdatum fehlt. | Durch das Informationsmodell ist es nicht vorgesehen, dass an dieser Stelle eine Eintragung zum Practitioner, etc. gemacht wird. Die entsprechende FHIR®-Ressource gibt das Element agent.who jedoch als Pflichtelement vor (Kardinalität 1..1 siehe https://www.hl7.org/fhir/provenance.html#Provenance). Weil diese Angabe im Überleitungsbogen nicht erwünscht ist, verwenden wir die Extension data-absent-reason und legen den fixed value "unknown" fest. Damit kann das Element agent.who durch unsere Spezifikation ausgeschlossen werden. |
Im Profil KBV_PR_MIO_ULB_Observation_Total_Barthel_Index können der Snomed und Loinc Code für die Elemente Observation.code.coding:snomed und Observation.code.coding:loinc als fixed value angegeben werden. | Wir verwenden zur Festlegung von fest vorgegebenen Inhalten nicht mehr das Feld "Fixed Value" sondern das Feld "Pattern". Leider wird dies auf Simplifier nicht so deutlich angezeigt wie bei einem Fixed Value. Das festgelegte Pattern ist in diesem Fall auf Simplifier ersichtlich, wenn das Element code.coding ausgeklappt und die Elemente "snomed" und "loinc" ausgewählt sind. Wählen Sie eines der Elemente aus, können Sie das Pattern im Feld, welches sich rechts aufklappt, einsehen. In der aktuellen Spezifikation finden Sie auch noch einige Elemente in denen "Fixed Value" genutzt wird. Diese resultieren häufig aus den Basisprofilen von HL7 Deutschland bzw. den KBV-Basis-Profilen. |
| Unter "Observation.code.coding.display" gibt es im Fallbeispiel eine Extension, die in der FHIR-Spezifikation auf simplifier jedoch nicht zu finden ist. | Es handelt sich um einen Fehler in der Kommentierungsversion der FHIR-Spezifikation des Überleitungsbogen. Nach verschiedenen Rückmeldungen wurde entschieden zukünftig die Extension für die vorläufigen deutschen Anzeigenamen nicht mehr zu verwenden und zu entfernen. Dementsprechend wird das Beispiel angepasst und in diesem die Extension entfernt. |
| Die fixed values unter Observation.value[x]:valueQuantity sind für die Atemfrequenz und die Messung der Herzfrequenz unterschiedlich. | Für die genannten Elemente wird immer ein Wert vorgegeben, entweder als "fixed value" oder als "pattern". Es ist dennoch sinnvoll ein einheitliches Bild innerhalb der Profile zu erzeugen, weshalb wir den Sachverhalt zur Korrektur weitergegeben haben. Die Korrektur muss innerhalb der KBV-Basis-Profile erfolgen, von denen diese Profile zu den Vitalparametern abgeleitet wurden. |
| In KBV_PR_MIO_ULB_Condition_Care_Problem wird das Element category mit einem Binding deklariert. Es sollen nur Codes aus dem Valueset ConditionCategoryCodes verwendet werden. Im Fallbeispiel wird jedoch ein SNOMED Code verwendet? | Es handelt sich um ein extensible-Binding, welches von der Basis-Ressource (https://www.hl7.org/fhir/condition.html) übernommen wurde und innerhalb unserer Spezifikation nicht entfernt werden kann. Auf Grund dessen, dass es sich um ein extensible-Binding handelt, ist eine verpflichtende Nutzung der Codes aus diesem ValueSet nicht notwendig. Unsere Spezifikation legt für category.coding ein Pattern fest, das vorgibt, welcher Code an dieser Stelle zu verwenden ist. Der festgelegte Code dient der Kategorisierung des Profils und drückt aus, dass es sich um ein Pflegeproblem handelt. |
Es wird gesagt, dass es sich im Profil KBV_PR_MIO_ULB_Device_Aid um ein Hilfsmittel nach dem GKV-Katalog handelt. Der Verweis auf das Codesystem fehlt an dieser Stelle. | Zum GKV-Hilfsmittelkatalog können wir folgendes mitteilen: Eine entsprechende Cannonical URL werden wir im pattern des Profils KBV_PR_MIO_ULB_Device_Aid unter type.coding einbinden. |
| Sofern es fachlich keine zwingende Notwendigkeit gibt von dem KBV-Basisprofil des Patienten abzuweichen, sollte keine Spezialisierung vorgenommen werden. | Wir versuchen so wenig wie möglich Spezialisierungen vorzunehmen und diese auf das Notwendigste zu beschränken. Manchmal ist es jedoch notwendig, Informationen zu ergänzen, die noch nicht in den KBV-Basis-Profilen vorhanden sind oder Informationen aus den KBV-Basis-Profilen zu entfernen, weil diese im Projekt nicht benötigt werden. Bei den Standardinformationen wie bspw. dem Namen, der Adresse, Kontaktinformationen und dem Geburtsdatum haben wir uns im Überleitungsbogen bereits entschieden keine Spezialisierungen mehr vorzunehmen, sondern alle Informationen (auch Kardinalitäten) der KBV-Basis-Profile zu übernehmen. |
| Es gibt Unstimmigkeiten zwischen dem Informationsmodell und der FHIR-Spezifikation. Damit Systeme erstellt werden können, die gemäß dem Informationsmodell sind, müssen die normativen Vorgaben der FHIR-Spezifikation mit dem informativen Angaben des Infomodells übereinstimmen. | Wir werden das Informationsmodell und die FHIR®-Spezifikation noch einmal abgleichen, um die Inkonsistenzen zu beheben. |
Bei codierten Informationen sind die menschenlesbaren Texte über das Codesystem definiert (SNOMED CT etc.). Damit ergibt sich aus einem in einem .code-Element hinterlegten interoperablen Code eindeutig der menschenlesbare Text. | Wie in den Help-Sessions bereits besprochen, werden wir die Extension für die vorläufigen deutschen Anzeigenamen im Überleitungsbogen entfernen. |
| Im Informationsmodell wird angegeben, dass ein PIO auch erstellt werden kann, ohne zu wissen, wo der Patient hinverlegt wird (z.B. für schnelle Notfallverlegungen). Die Kardinalität der entsprechenden Extension in der Composition fordert jedoch eine Referenz auf die empfangende Einrichtung. | Die Kardinalität wird innerhalb der Kommentierungsphase angepasst. |
| Im Profil KBV_PR_MIO_ULB_Observation_Degree_Of_Disability_Available werden die Elemente effective[x] und value[x] gesliced obwohl nur ein einziges Slice definiert ist. | Wird das Slicing an dieser Stelle nicht vorgenommen, wäre die Spezifikation an beiden Stellen nach unserem Verständnis nicht korrekt ausspezifiziert. Um Interpretationsspielräume zu vermeiden und somit Erleichterung für lesende Systeme zu schaffen, werden die Spezifikationen der MIOs/PIOs immer vollständig ausspezifiziert zur Verfügung gestellt. |
| Die Profile KBV_PR_MIO_ULB_Observation_Degree_Of_Disability_Available und KBV_PR_MIO_ULB_Observation_Degree_Of_Disability sollten in einem Profil zusammengefasst werden oder dass allgemeinere Profil sollte auf das spezifischere Profil referenzieren. | Wir haben uns an dieser Stelle bewusst für getrennte Profile entschieden. Über das Profil KBV_PR_MIO_ULB_Observation_Degree_Of_Disability_Available kann angegeben werden, ob ein Grad der Behinderung überhaupt vorliegt. Mit dem Profil KBV_PR_MIO_ULB_Observation_Degree_Of_Disability werden hingegen nähere Angaben zu dem Grad der Behinderung gemacht, d. h. der Grad der Behinderung kann hier, inkl. der Merkzeichen, genauer spezifiziert werden. Wir halten eine Referenzierung vom allgemeineren Profil auf das näher beschreibende Profil für sinnvoll und werden dies umsetzen. |
| Die Profile KBV_PR_MIO_ULB_Observation_Presence_Risks und KBV_PR_MIO_ULB_Observation_Risk sollten in einem Profil zusammengefasst werden oder dass allgemeinere Profil sollte auf das spezifischere Profil referenzieren. | Wir haben uns an dieser Stelle bewusst für getrennte Profile entschieden. Über das Profil KBV_PR_MIO_ULB_Observation_Presence_Risks kann angegeben werden, ob ein Risiko vorliegt. Mit dem Profil KBV_PR_MIO_ULB_Observation_Risk werden hingegen nähere Angaben zu dem vorliegenden Risiko gemacht, d. h. das Risiko kann hier genauer spezifiziert werden. Wir halten eine Referenzierung vom allgemeineren Profil auf das näher beschreibende Profil für sinnvoll und werden dies umsetzen. |
| Die Profile KBV_PR_MIO_ULB_Observation_Relevant_Information_Medical_Devices, KBV_PR_MIO_ULB_Device_Aid und KBV_PR_MIO_ULB_DeviceUseStatement_Implant sollten in einem Profil zusammengefasst werden oder dass allgemeinere Profil sollte auf die spezifischeren Profile referenzieren. | Wir haben uns an dieser Stelle bewusst für getrennte Profile entschieden. Über das Profil KBV_PR_MIO_ULB_Observation_Relevant_Information_Medical_Devices kann angegeben werden, ob Informationen zu Medizinprodukten vorliegen. Mit den Profilen KBV_PR_MIO_ULB_DeviceUseStatement_Implant und KBV_PR_MIO_ULB_Device_Aid werden hingegen nähere Angaben zu den Medizinprodukten gemacht. Wir halten eine Referenzierung vom allgemeineren Profil auf die näher beschreibenden Profile für sinnvoll und werden dies umsetzen. |
| Die Profile KBV_PR_MIO_ULB_Observation_Presence_Allergies und KBV_PR_MIO_ULB_AllergyIntolerance sollten in einem Profil zusammengefasst werden oder dass allgemeinere Profil sollte auf die spezifischeren Profile referenzieren. | Wir haben uns an dieser Stelle bewusst für getrennte Profile entschieden. Über das Profil KBV_PR_MIO_ULB_Observation_Presence_Allergies kann angegeben werden, ob überhaupt Allergien vorliegen. Mit dem Profil KBV_PR_MIO_ULB_AllergyIntolerance können diese hingegen näher bezeichnet werden. Wir halten eine Referenzierung vom allgemeineren Profil auf das näher beschreibende Profil für sinnvoll und werden dies umsetzen. |
| Im Profil KBV_PR_MIO_ULB_Device_Aid fehlen Informationen, welche Angaben in den Kindelementen von "type" gemacht werden sollen. | In diesem Profil sollen Hilfsmittel aus dem GKV-Hilfsmittelkatalog abgebildet werden. Wir haben eine entsprechende URI für type.coding.system ergänzt, um dies deutlicher hervorzuheben. |
| Die Lesbarkeit der Profile für Umsetzer wird erhöht, wenn für die Spezifizierung von ".code"-Elementen ValueSet-Bindings und/oder Fixed Values verwendet werden und auf die Nutzung von Patterns verzichtet wird. | Uns ist die Problematik bewusst, dass Patterns nicht so deutlich in den Profilen auf Simplifier gekennzeichnet werden. Ausschließlich Fixed Value zu nutzen hat jedoch an einigen Stellen im Profil nicht funktioniert: Wird durch die Spezifikation bspw. ein Code fest vorgegeben, kann dieser unter Fixed Value eingetragen werden. Gleiches gilt für "system" und die "version", aus dem der Code stammt. Probleme gibt es mit dem Display-Wert, da an dieser Stelle zusätzlich mit einer Extension für den deutschen Anzeigenamen gearbeitet wird. Legt man für den Display-Wert auch einen Fixed Value fest und nutzt an diesem display-Element zusätzlich die Extension für den deutschen Anzeigenamen, kommt es zu Problemen bei der Validierung. In unseren Start-MIOs (Impfpass, U-Heft, Mutterpass und Zahnärztliches Bonusheft) wird mit Fixed Values und nicht mit Pattern gearbeitet. Es häufen sich Anfragen, warum die Elemente system, version, code und die Extension für den deutschen Anzeigenamen einen Fixed Value aufweisen, nicht aber display. Um diese Probleme zu umgehen, haben wir entschieden vollständig auf Patterns umzusteigen und diese bereits auf der coding-Ebene festzulegen. Die fest vorgegebenen Werte können dann für system, version, code und display direkt mit einmal auf dieser Ebene eingesehen werden. Vor Kurzem haben wir nach verschiedenen Rückmeldungen entschieden, zukünftig die Extension für den deutschen Anzeigenamen zu entfernen, somit entfällt diese auch im Überleitungsbogen. Auch wenn die oben beschriebene Problematik somit nicht mehr besteht, werden wir vorerst die patterns beibehalten. Dennoch werden wir noch einmal überlegen, ob in Zukunft fixed values oder patterns genutzt werden. |
| Der Satz, dass das Bundle-Element die einzige Ressource ist, die in die ePA gespeichert werden darf, ist leicht irreführend. | Wir werden die Beschreibung entsprechend anpassen. |
| Die Extension für den deutschen Anzeigenamen in KBV_PR_MIO_ULB_Observation_Care_Level für das Element value[x].valueCodeableConcept ist übeflüssig. Das Valueset für den Pflegegrad enthält bereits deutsche Wiedergabenamen. | Wir werden die deutsche Übersetzung an dieser Stelle entfernen. |
| Welchen Sinn hat die Extension von telecom.system um einen deutschen Anzeigenamen des Codes? Die originalen Codes sind selbsterklärend und können in der Anwendung bei Bedarf übersetzt werden. | Es wurde beschlossen, dass alle englischen Codes/Anzeigenamen eine vorläufige deutsche Übersetzung erhalten. Dies ist auch bei den Codes von telecom.system der Fall. Im Austausch mit verschiedenen Herstellern innerhalb unserer Help-Sessions haben wir uns dafür entschieden, die Extension für den vorläufigen deutschen Anzeigenamen zu entfernen, sodass diese auch am Element telecom.system entfällt. Die vorläufigen deutschen Anzeigenamen werden weiterhin von uns zur Verfügung gestellt und in einer großen Conceptmap gebündelt. |
| Die Verwendung von verschachtelten Extensions wie bspw. KBV_EX_Base_Terminology_German oder KBV_EX_MIO_ULB_Terminologie_Assoziation erzeugt unnötigen Overhead. | Die Extension KBV_EX_Base_Terminology_German wurde der offiziellen Übersetzungs-Extension (https://simplifier.net/simplifier.core.r4.extensions/translation) nachempfunden und wird aus den KBV-Basis-Profilen übernommen. Im Austausch mit verschiedenen Herstellern innerhalb unserer Help-Sessions haben wir uns dafür entschieden, die Extension für den vorläufigen deutschen Anzeigenamen zu entfernen. Im Überleitungsbogen wird diese in Zukunft nicht mehr verwendet werden. |
Die Profile KBV_PR_MIO_ULB_Observation_Information_Medicines und | Wir haben uns an dieser Stelle bewusst für getrennte Profile entschieden. Über das Profil KBV_PR_MIO_ULB_Observation_Information_Medicines kann angegeben werden, ob Informationen zur Medikation vorliegen. Mit dem Profil KBV_PR_MIO_ULB_MedicationStatement_Administration_Instruction können hingegen nähere Angaben zur Medikation gemacht werden. Wir halten eine Referenzierung vom allgemeineren Profil auf die näher beschreibenden Profile für sinnvoll und werden dies umsetzen. |
Redaktionell
| Kommentarthema | Ergebnis |
|---|---|
| Fallbeispiel bitte präzisieren hinsichtlich der Übertragung des PIO über ePA / KIM | Wir haben das Fallbeispiel entsprechend angepasst und damit klar gestellt, dass die Übertragung des Überleitungsbogens entweder über die ePA von Hrn. Dr. Yilmaz oder auch per Kommunikationsdienst KIM (Kommunikation im Medizinwesen) erfolgen kann. Wir arbeiten darüber hinaus kontinuierlich an der Weiterentwicklung des Informationsangebots zu unseren MIOs/PIOS, welches die zukünftige Nutzung kurz und einfach erklären soll. |
| Ist eine Zertifizierung für die Implementierung des PIO Überleitungsbogen geplant/vorgesehen? | Nein, eine Zertifizierung ist zum aktuellen Stand vom Gesetzgeber nicht vorgesehen. |
| Nutzung des PIO Überleitungsbogen perspektivisch freiwillig oder verpflichtende Nutzung / Vorgabe zur Vorhaltung in den Primärsystemen? | Die Einführung einer verpflichtenden Nutzung des PIO obliegt den sektorenspezifischen gesetzlichen oder untergesetzlichen Regelungen. Der Nutzen und die Vorteile, die das PIO Überleitungsbogen mit sich bringen kann, werden jedoch nur dann für sämtliche Akteure erlebbar, wenn es auch flächendeckend umgesetzt wird. |
Der Bundesverband privater Anbieter sozialer Dienste e.V. (bpa) wünscht sich eine Pilotierung vor Einführung des PIO Überleitungsbogen. | Die mio42 GmbH, die Bundesarbeitsgemeinschaft der Freien Wohlfahrtspflege e. V. (BAGFW) und der Bundesverband privater Anbieter sozialer Dienste e.V. (bpa) stehen in engem Austausch und führen aktuell Gespräche zur Klärung des weiteren Vorgehens. Eine erste Nutzung im Rahmen eines Pilotprojektes des PIO erfolgt im Setting eines Modellvorhabens nach §125 SGB XI in 2023 (https://www.gkv-spitzenverband.de/pflegeversicherung/forschung/modellprojekte_125/pflege_modellprojekte_125.jsp). Als mio42 sehen wir eine Erprobung des PIO sowohl auf technische als auch auf prozessuale Funktionalitäten vor einer gesamthaften Einführung für die Bundesrepublik als wünschenswert an, um nicht zuletzt eine breite Akzeptanz in der Praxis zu schaffen. Die gesetzliche Frist zur Festlegung gemäß § 355 SGB V Abs. 2b seitens der KBV ist dabei zu beachten. |
