Nach Abschluss der Kommentierung und der Prüfung sowie Bewertung aller eingegangenen Kommentare ist hier ein Überblick zu den eingegangenen Kommentaren und den Bewertungsergebnissen einsehbar. Hier kann entnommen werden, an welchen Stellen ein Kommentar zu einer Überarbeitung oder zur Aufnahme von Operationalisierungsempfehlungen für die umsetzenden IT-Systeme geführt haben.
Das überarbeitete PIO wird im Rahmen der Benehmensherstellung dargestellt.
Inhalt
| Kommentarthema | Ergebnis |
|---|---|
Die Reihenfolge von Elementen sollte vertauscht werden: Straße, Positionen tauschen in Name 1.1.1 und Identifikatorauswahl 1.1.2 | Die Reihenfolge von Elementen auf der gleichen Ebene ist nur für die Darstellung von Bedeutung. Sie wirkt sich nicht auf den Inhalt oder die Spezifikation aus. Die Reihenfolge haben wir nun auf Ihren Hinweis hin zur besseren Darstellung vertauscht. Auf den Inhalt und die technische Spezifikation hat das keine Auswirkung. Auch die kommende Version der KBV-Basis-Profile wird die veränderte Reihenfolge beinhalten. Die Reihenfolge Name - Identifikator im Element "PatientIn" wurde ebenfalls angepasst. |
| Die Nennung der vorgeschlagenen Identifikatoren setzen eine vorhandene Versicherung (KV, PV) voraus, die nicht immer vorliegt, bzw. die PID, welche jedoch außerhalb der übergebenden Einrichtung meist nutzlos ist, wenn es sich um einen anderen Leistungserbringer handelt. | Die Identifikatoren sind nicht mandatorisch. |
| Medikationsplan: Hier sollte zur Optimierung der Versorgung von Patienten mit chronischen Wunden oder Ödemen (ggf. als Bedingung mit entsprechender ICD-Codierung), mit der Option mehrere Wunden zu listen, Punkte ergänzt werden. | Für den Überleitungsbogen würde die Aufnahme der von Ihnen vorgeschlagenen Informationen den Rahmen übersteigen. Zur Dokumentation von Wunden wird zur Zeit ein separates MIO "Überleitungsbogen Chronische Wunde" von der Hochschule Osnabrück erarbeitet. Wir haben Ihre Punkte an die Hochschule Osnabrück weitergeleitet, sodass sie im MIO "Überleitungsbogen Chronische Wunde" berücksichtigt werden können. |
| Die Kardinalitäten der Stammdaten sollten an die KBV-Basis angepasst werden. | Die Kardinalitäten und Konformitäten wurden an die aktuellen KBV-Basis-Profile (Version 1.2.1) angepasst. |
| Identifikator Pflegefachperson sollte vom Datentyp Identifier sein. | Der Datentyp wurde angepasst. |
| Sollen die einzelnen Komponenten des Barthel-Index auch separat verwendet werden können? Ist das so geplant? | Ja, es soll möglich sein, die einzelnen Teile des Barthel Index unabhängig von einem Barthel Summenscore zu verwenden. Der Grund dafür ist, dass die einzelnen Komponenten des Barthel Index bereits durch uns kodiert sind und daher ohne Aufwand verwendet werden können. Sie stellen eine aufwandsarme Alternative zum Element "Assesssment - frei / Beobachtung" dar, in dem Code und Code-System vom Benutzer ausgewählt werden müssen (direkt oder indirekt über die Verwendung der Primärsoftware). |
| Freiheitsentziehende Maßnahmen Kardinalitäten und Konformitäten | Die Kardinalitäten und Konformitäten wurden angepasst. |
| Zuzahlungsbefreiung Konzepte | Die Konzeptbezeichnungen wurden angepasst. |
| Benennung des Elements "Wert" als Wert in Kontaktdaten | Mit "Wert" ist in diesem Element die Ausprägung der Kontaktinformation gemeint, z.B. "m.mustermann@mio42.de". Der Kontaktkanal wäre dann "E-Mail". Bei einer Telefonnummer ist der Kontaktkanal = "Telefonnummer" und der Wert = 030712345678. |
| Zuzahlungsbefreiung: optimal wäre es, wenn diese Information direkt über die Chipkarte bzw. die Krankenkasse ermittelt und eingetragen werden kann. | Wir unterstützen die automatische Übernahme/Ergänzung von Daten. Es gibt hierzu unter Übergreifende Operationalisierungshinweise, Phase I bereits einen übergreifenden Operationalisierungshinweis "Automatische Übernahme von Daten". Wir haben dort in der Auflistung von Beispielen die Zuzahlungsbefreiung ergänzt. |
Optimal wäre es, wenn die Felder der Pflegeprobleme als Pflichtfelder markiert werden würden. Sonst kann nicht nachvollzogen werden ob das Problem vorher nicht bestand oder lediglich nicht betrachtet wurde. | Die Angabe von Pflegeproblemen ist optional, da es theoretisch auch vorstellbar ist, dass keine Pflegeprobleme vorhanden sind. Der Überleitungsbogen ist zudem als Momentaufnahme gedacht. Es sollen die Probleme genannt werden, die zum Zeitpunkt der Überleitung bestehen und für die empfangende Einrichtung relevant sind. Um herauszufinden, ob das Bestehen von Problemen betrachtet wurde, gibt es die verpflichtende Angabe "Vorliegen von Problemen". |
Optimal wäre es, wenn die Felder der Pflegeprobleme als Pflichtfelder markiert werden würden. Sonst kann nicht nachvollzogen werden ob das Problem vorher nicht bestand oder lediglich nicht betrachtet wurde. Darüber hinaus sollte eine Historie einsehbar sein, wann und durch wen es geändert wurde. | Der Überleitungsbogen ist als Momentaufnahme gedacht. Es sollen die Probleme genannt werden, die zum Zeitpunkt der Überleitung bestehen und für die empfangende Einrichtung relevant sind. Eine Historie bzw. mehrere Versionen eines Überleitungsbogens sind nicht geplant, da wir davon ausgehen, dass ein Überleitungsbogen zu einem einzigen konkreten Zeitpunkt erstellt wird. Selbst wenn ein Überleitungsbogen bereits eine Woche vor Entlassung des/der PatientIn an eine potentielle empfangende Einrichtung versendet wird, muss zur tatsächlichen Entlassung ein neuer, aktueller Überleitungsbogen erstellt werden. Siehe auch Informationsmodell, Phase I |
| Die Möglichkeit der Dokumentation eines Assessments zur genaueren Beschreibung/Begründung der Einschätzung der Schmerzsymptomatik wurde jetzt mit dem Element "Assessment - frei / Beobachtung" eingerichtet. Es wurde auch ein Element "Informationsquelle" hinzugefügt, sodass z.B. auf einen eingescannten Bogen verwiesen werden kann. Es können im Element Schmerzsymptomatik direkt keine Medikamente und/oder Maßnahmen angegeben werden, aber unter den Abschnitten "Pflegerische Maßnahme" und "Medikations-Information" kann die Schmerzsymptomatik jetzt als Anlass/Ursache referenziert werden. Weitere Attribute zur Schmerzsymptomatik (Schmerzstärke (0-10), Lokalisation, Schmerzqualität, stabil/instabil) aufzuführen, war in Absprache mit dem Pflegebeirat nicht vorgesehen. Dafür kann aber aktuell das Freitextelement "Freitext Kommentar" oder das jetzt referenzierbare Element "Assessment - frei / Beobachtung" genutzt werden. |
Assessment, Initiales Screening und differenzierte Einschätzung zum Ernährungsbedarf fehlen bei Ernährung, vgl. Expertenstandard Ernährungsmanagement vom DNQP | Ein Assessment zur genaueren Beschreibung einer Ernährungssituation kann bei "Hinweis zur Ernährung" unter "Anlass/Ursache" mit dem Element "Assessment - frei / Beobachtung" angegeben werden. Zum Beispiel kann bei "Hinweis zur Ernährung" das Ergebnis eines "Mini Nutritional Assessment" angegeben werden. Da es in der Pflege eine Fülle von Assessmentinstrumenten gibt und unterschiedliche Einrichtungen unterschiedliche Instrumente nutzen, haben wir vorerst von der Modellierung bestimmter Instrumente abgesehen. Sollte sich im Verlauf der Umsetzung und Nutzung des PIO in der Praxis eine Notwendigkeit zur Modellierung von bestimmten Assessments aufgrund z.B. häufiger Nutzung ergeben, werden wir das in einer Fortschreibung berücksichtigen. |
| Gehört die Arztnummer wirklich in eine Pflegeüberleitung? Zur Vollständigkeit ist es sicherlich sinnvoll die Nummer dort zu hinterlegen. Allerdings glaube ich nicht, dass die Pflegenden die Arztnummer der behandelnden Ärzte kennen bzw. wo diese einzusehen ist. | Die Arztnummer ist Bestandteil der behandelnden Person im entsprechenden KBV-Basis-Profil (s. https://mio.kbv.de/display/BASE1X0) . Die Angabe ist nicht verpflichtend, das Feld kann also leer gelassen werden. |
Rechtliche Grundlagen - Dokumente Für Freiheitsentziehende Maßnahmen muss ein entsprechender rechtsverbindlicher Beschluss vorliegen, wo ist dieser einzusehen? Zur Isolation muss eine ärztliche Anordnung vorliegen. Wo ist diese einzusehen? Ist hier das Befunddatum wichtig zu hinterlegen? | Viele Dokumente müssen schriftlich vorliegen. Daher sind die Verweise in dem Element "Informationsquelle" immer nur Hinweise darauf, welches Dokument den Eintrag (z.B., dass freiheitsentziehende Maßnahmen notwendig sind) bewirkt hat. Die Angabe im PIO Überleitungsbogen allein kann keine rechtsgültige Grundlage für eine Handlung sein. Ein ausgefülltes Element "Informationsquelle" kann dabei helfen, einen Hinweis mitzugeben, wo so ein Dokument zu finden ist. Es wurde im Element "Freiheitsentziehende Maßnahmen" folgender Operationalisierungshinweis hinzugefügt: "Wenn möglich, sollte bei der Notwendigkeit einer freiheitsentziehenden Maßnahme eine Informationsquelle angegeben werden." Es wurde im Element "Notwendigkeit der räumlichen Isolation" in "Isolation" das Element "Informationsquelle" und folgender Operationalisierungshinweis hinzugefügt: "Wenn möglich, sollte bei der Notwendigkeit einer räumlichen Isolation eine Informationsquelle angegeben werden, z.B. der Hinweis darauf, wo eine entsprechende ärztliche Anordnung zu finden ist." |
| Leider wurde im Informationsmodell der Familienstand nicht berücksichtigt. Ich würde den Familienstand gerne wieder in das Informationsmodell aufnehmen wollen, wenn aber optional. | Der Personenstand, wie in den deutschen Basisprofilen definiert, wurde aufgenommen. |
Es fehlen:
| "Grund der Überleitung (hier wird in der Praxis gern Text geschrieben)" und "Angabe, ob Überleitung geplant oder ungeplant stattfindet" können im Element "Nachricht an die empfangende Einrichtung" freitextlich festgehalten werden. Die zugehörigen MIOs/PIOs können unter "Relevante Informationsquellen" referenziert werden. |
| Es fehlt die Angabe der Religion / Konfession | Die Religion ist nicht Teil des deutschen Basisprofils Patient von HL7, von dem wir ableiten. Es wurde aber jetzt ein Freitext-Feld "Religion/Konfession" im Abschnitt "PatientIn" hinzugefügt. Die Religion kann außerdem als Freitext oder als Code aus SNOMED-CT "descendants of code 1400009 | Spiritual or religious belief (religion/philosophy) |" angegeben werden. |
Mitgegebene
sollen angegeben werden können. | Es wurde unter "Organisatorisches und Soziales" der Abschnitt "Mitgegebene Dokumente / Arzneimittel / Hilfsmittel / Gegenstände" erstellt. Dort können Dinge, die mitgegeben wurden, gelistet werden, wie:
|
| Pflegeeinrichtungen halten in ihren Dokumentationssystemen ebenfalls Daten wie Impfungen und Verordnungen vor. Diese Daten sind sowohl aus pflegerischer als auch aus ärztlicher Sicht relevant. Ist sichergestellt, dass diese Daten auf anderem Wege in die ePA gelangen? Ansonsten wäre es gut, diese Daten ebenfalls mit dem Überleitungsbogen zu übertragen. | Für Impfungen kann das MIO Impfpass verwendet werden. Verordnungen können z.B. als PDF direkt in die ePA hochgeladen werden und vom Überleitungsbogen aus kann auf sie mithilfe des Elements "Informationsquelle" verwiesen werden. Zukünftig wird es auch möglich sein elektronische Verordnungen bzw. Medikationshistorien zu speichern. Für die aktuelle Medikation steht zudem zukünftig die Online-Anwendung eMP zur Verfügung. |
Ambulante Palliativversorgung sind als eigenständige Einrichtungen anzusehen und sollten in die Typ-Liste aufgenommen werden Einrichtungen der Behindertenhilfe ergänzen Stationäre Einrichtungen der Behindertenhilfe Alternativ auch das Wort Eingliederungshilfe Welcher Typ beschreibt ambulante Pflegedienste? Wäre eine zusätzliche Unterscheidung für SAPV Dienste sinnvoll? | Die Einrichtungstypen "Spezialisierte ambulante Palliativversorgung" und "Einrichtung der Eingliederungshilfe" wurden aufgenommen. |
| Wird der Medikationsplan von einer externen Quelle übertragen? | Ja, es ist so gedacht, dass für den Medikationsplan immer eine Quelle angegeben wird. Die Erstellung eines Medikationsplanes fällt nicht in den Zuständigkeitsbereich der Pflegefachperson. Trotzdem ist es notwendig, eine Momentaufnahme des aktuellen Medikationsplans im Überleitungsbogen darzustellen, da die Pflegefachperson häufig Medikamente verabreicht. Im besten Fall wird der Medikationsplan automatisch aus einem aktuellem elektronischen Medikationsplan übernommen. Es kann aber auch sein, dass die Medikation anamnestisch erfragt wurde oder von einem Blatt Papier abgeschrieben wurde. Das alles sind mögliche Informationsquellen. Je nach Art der Informationsquelle liegt es in der Verantwortung der Pflegefachperson, die Medikation mit einem Arzt / einer Ärztin zu beraten und/oder eine bessere Grundlage für den Medikationsplan zu suchen (z.B. eine neue Verordnung). |
| Das Geburtsdatum sollte optional sein und zusätzlich sollte es erlaubt werden nur Teildatumsangaben zu setzen (also auch YYYY und MM/YYYY erlaubt) | Die Kardinalität des Geburtsdatums wurde an die Vorgaben der KBV-Basis-Profile angepasst: 0...1 C 1...1 M Normalerweise sollte das Datum immer angegeben werden. 0...1 O In nicht abschließend definierten Ausnahmen ist eine Nichtangabe erlaubt. Die Genauigkeit der Datumsangabe ist beim Geburtsdatum nicht gesetzt. Somit ist es möglich, unvollständige Angaben zu machen. |
Viele kranke und sterbende Menschen ziehen sich auf ihre Muttersprache zurück und die verbale Verständigung in deutscher Sprache ist eingeschränkt. Sinnvoll wäre eine Kennung, ob z.B. ein Dolmetscher benötigt wird Bitte ein Freitextfeld / Kennzeichen aufnehmen, z.B. für den Vermerk welche Sprache die Muttersprache ist, wie die Sprachqualität ist und ob ein Dolmetscher erforderlich ist. | Eine oder mehrere Sprachen können im Element "Sprache" angegeben werden. Wenn ein/e PatientIn eine bestimmte Sprache bevorzugt, wird in diesem Element nur diese Sprache angegeben. Je nach Kapazität der jeweiligen Einrichtung kann ein Softwaresystem dann eine entsprechende Meldung ausgeben. Der Operationalisierungshinweis "Diese Information kann vom Softwaresystem als Notwendigkeit für einen Dolmetscher dargestellt werden." wurde hinzugefügt. Darüber hinaus wurden die Elemente "Dolmetscher notwendig" und "Weitere Hinweise zur Kommunikation" erstellt. Hier können Sprachkenntnisse weiter beschrieben werden. |
| Bei Allergien (2.8.2) können keine Kreuzallergien (oder Kreuzunverträglichkeiten) abgebildet werden. Ist das richtig? Und wenn ja, wird das nicht benötigt? | Eine Kreuzallergie entsteht, wenn Antikörper gegen ein bestimmtes Allergen A auch eine Reaktion bei Kontakt mit einem anderen Allergen B auslösen. In diesem Fall muss eine Allergie gegen das Allergen A und eine Allergie gegen das Allergen B dokumentiert werden. Die Tatsache oder Annahme, dass beide Reaktionen möglicherweise durch die gleichen Antikörper ausgelöst werden, ist für die klinische Dokumentation irrelevant. Bei hypothetischen, nicht in der Praxis überprüften Risiken einer allergischen (Kreuz)-Reaktion, z.B. auf Grundlage klinischer Studien, kann die hypothetische Allergie mit einem Status "Unbestätigt" angegeben werden. |
| Assessment bei Funktionsbeurteilung hinterlegen | Das Element "Assessment - frei / Beobachtung" ist bei Funktionsbeurteilung hinterlegt. Hier kann ein beliebiges Assessment dokumentiert werden. |
| Assessment bei Risiko hinterlegen | Die Möglichkeit der Dokumentation eines Assessments zur genaueren Beschreibung/Begründung der Einschätzung des Risikos wurde jetzt mit dem Element "Assessment - frei / Beobachtung" eingerichtet. |
Optimal wäre es, wenn hier bereits ersichtlich wird, welche persönlichen Erklärungen vorliegen (z.B. Patientenverfügung, Vorsorgevollmacht, Organspendeausweis etc.) Patient/Einrichtung versteht ggf. etwas anderes unter persönlicher Erklärung --> Eindeutig benennen! Persönliche Erklärung: Die Kardinalität ist hier auf nur eine persönliche Erklärung begrenzt. Warum? Der Inhalt der Erklärung sottle ergänzt bzw. ein Attachment vorgesehen werden. Die Verwendung von gängigen Fachbegriffen ist erforderlich: "Patientenverfügung, Vorsorgevollmacht, Betreuungsverfügung" | Der Abschnitt "Persönliche Erklärungen" wurde angepasst. Es ist jetzt möglich, beliebig viele konkrete Erklärungen anzugeben. Das Element Erklärung hat jetzt auch das Attribut "Art der Erklärung" mit der Werteliste: "Organspendeerklärung, Patientenverfügung, Vorsorgevollmacht". Der Aufbau orientiert sich am MIO Patientenkurzakte. Eine Erklärung kann jetzt außerdem zusätzlich im Abschnitt "Patientenwünsche" referenziert werden. Dokumente können mit dem Element "Informationsquelle" als Anhang zum PIO Überleitungsbogen angefügt werden. |
| Weitere pflegebedürftige Angehörige im Haushalt erfassen soweit nicht in "Pflege durch Angehörige nicht möglich beschreibbar. | Es gibt nun ein Hinweisfeld bei der Kontaktperson (Freitext). Dort können weitere Informationen, beispielsweise die Pflegebedürftigkeitssituation der Kontaktperson, dargestellt werden. |
Fehlt bei den behandelnden Personen, die Rolle des Behandlers in Bezug auf den Patientenkontext, also z.B. "Hausarzt", "Einweiser", "persönlicher Pfleger"? | Es gibt jetzt unter "Kontakt- und behandelnde Personen" das Element "Versorgungsteam". Dort kann eine behandelnde Person in Zusammenhang mit einer "Rolle in Bezug auf den/die PatientIn" gebracht werden, z.B. "Hausarzt" oder "Pflegeperson". |
Zirkuläre Referenzierung auf 2.2.2 hinterlegt; macht inhaltlich wenig Sinn | Das Risiko in "Anlass/Ursache" wurde entfernt. |
| Ist es möglich die Teilthemen Pflegeproblem, Pflegediagnosen und Pflegemaßnahmen in eine Übersicht zu überführen sodass eine Art Pflegeplanung entsteht? | Ja, das ist möglich. Wir geben nicht vor, dass die "Pflegerischen Informationsbausteine" auf eine bestimmte Art und Weise gruppiert werden oder in einer bestimmten Reihenfolge gruppiert bzw. angezeigt werden müssen. Die Anordnung durch das Primärsystem in einer Weise, die eine Pflegeplanung ermöglicht, obliegt den umsetzenden Systemen. |
| Da i.d.R. zu einem Zeitpunkt der Messung selten nur eine Vitalparameter erfasst wird sollte es hinter jedem Vitalparameter einen Button geben, wodurch sich automatisch das aktuelle Datum und die Uhrzeit im Datumsfeld einträgt. Natürlich sollte das Datum und die Uhrzeit auch änderbar sein | Das ist eine Anforderung an die Umsetzung. Wir unterstützen die automatische Übernahme/Ergänzung von Daten. Es gibt hierzu unter Übergreifende Operationalisierungshinweise, Phase I bereits einen übergreifenden Operationalisierungshinweis "Automatische Übernahme von Daten". Wir haben dort in der Auflistung von Beispielen das aktuelle Datum ergänzt. |
| Es fehlt die Möglichkeit der Angabe eines Assessments im Abschnitt Orientierung/Psyche. | Das Element "Assessment - frei / Beobachtung" wurde unter Orientierung/Psyche hinzugefügt. |
| Im Bereich der spezialisierten Pflegefachberufe fehlen Pflegeexperten APN (Advanced Practice Nurses) sowie Community Health Nurses (CHN). Diese sollten bei hohem Qualifikationsgrad und zunehmender Einsatzdichte unbedingt mit aufgenommen werden. | Wir werden die Pflegeexperten APN (Advanced Practice Nurses) sowie Community Health Nurses (CHN) in der entsprechenden Auswahlliste aufnehmen. |
| Kontaktperson: Mehrfacheingaben erlauben und bitte genaue Definition des Verwandtschaftsgrades ermöglichen (wenn vorhanden) | Die Vergabe mehrerer Rollen für eine Kontaktperson ist möglich. Der genaue Verwandtschaftsgrad kann jetzt als Freitext im Feld "Hinweis" angegeben werden. Es gibt außerdem ein erweitertes ValueSet mit Verwandtschaftsgraden. |
Die Aufgabenkreise von (gesetzlich) bestellten Betreuern sind im Überleitungsbogen nicht enthalten. Beispielsweise Vermögen, Unterbringung, Postangelegenheiten... | Diese Angaben könnten in dem neu erstellten Feld "Hinweis" unter dem Abschnitt "Kontaktperson" angegeben werden, wenn nötig. Im Abschnitt "Gesetzlich betreuende Person" wird immer eine Kontaktperson referenziert. Das Hinweisfeld ist eine Eigenschaft dieser Kontaktperson und optional. Allerdings muss hervorgehoben werden, dass die Angaben in den Hinweisfeldern nicht rechtsgültig sind. Rechtsgültig sind nur die Angaben in dem in rechtsgültiger Form vorliegenden Dokument, das die Betreuung beschreibt. |
Optional sollte das Geschlecht der Kontaktperson spezifiziert werden können. | Das administrative Geschlecht wurde bei der Kontaktperson ergänzt. |
| Das Bild des Patienten wird in einigen Systemen für die einfachere Zuordnung verwendet. Falls es optional übertragen werden könnte, wäre das hilfreich. | Das ist jetzt möglich über das Element "Informationsquelle". |
| Wie gibt man an, welche Hilfsmittel zur Sturzprophylaxe angewendet wurden (z.B. Anti-Rutsch-Socken oder Anti-Rutschmatte)? | Im Abschnitt Hilfsmittel wurde nun das Element "Anlass/Ursache" hinzugefügt. Dort kann das Sturzrisiko und/oder die Anzahl der Stürze in den vergangenen 6 Monaten als Anlass für den Gebrauch des Hilfsmittels angegeben werden. |
Bei einem Dialyseshunt ist nicht nur die Art, sondern auch die Lage und Funktionsfähigkeit eine wichtige Information bei der Überleitung. Auch ist wichtig, ob der Shunt Fremdmaterial (=Device) oder kein Fremdmaterial enthält. Wo sollen solche Informationen abgelegt werden? | Solche Informationen können im Falle von Medizinprodukten in den Freitextfeldern abgelegt werden: Hilfsmittel → Hinweis, Implantat → Ergänzende Informationen. Da ein Dialyseshunt wie Sie schreiben nicht immer ein Medizinprodukt enthält, könnte man diesen im Moment am ehesten über "Pflegediagnose" oder "medizinische Diagnose" abbilden. Auch dort gibt es die Möglichkeit von zusätzlichen Freitexten zur genaueren Beschreibung des Problems. Eine Alternative ist die Verwendung des Elements "Assessment - frei / Beobachtung". Da das PIO Überleitungsbogen zunächst eine Schnittmenge der am häufigsten benötigten Informationen abbilden soll, wurde auf Dialysepatienten nicht explizit mit konkreten Feldern (Art der Dialyse, Dialysepflicht, Dialysezugang mit Beschreibung, Art des Zugangs, Lokalisation, Status, usw.) eingegangen. |
Nephrostomie-Wort Katheter fehlt | Wir haben die Abschnitte "Harnableitung" und "Stuhlableitung" angepasst. Das genannte Konzept wurde in "Nephrostomie-Katheter" umbenannt. |
Weitere detaillierte Angaben zum Stoma werden benötigt Wenn der Patient eine Stomaamlage hat, muss es nicht unbedingt heißen, dass er damit auch klarkommt. Die zusätzliche Angabe zur Hilfestellung fehlt, z.B. Pat. kann seine Stomaanlage selbständig versorgen, oder mit Unterstützung durch Pflege/ Angehörigen oder ein Stomatherapeut sollte kontaktiert werden. | Für den Überleitungsbogen in seiner jetzigen Ausbaustufe würde die Aufnahme detaillierter strukturierter Angaben zum Stoma die Zielstellung und den Rahmen übersteigen. Die Informationen zur Stomabeschaffenheit oder dazu, wie der/die PatientIn mit dem Stoma zurechtkommt, können aber im Freitextfeld "Kommentar/Rationale" dokumentiert werden. Zur Dokumentation von Wunden wird zur Zeit ein separates MIO "Überleitungsbogen chronische Wunde" von der Hochschule Osnabrück erarbeitet. Wir haben jetzt auch die Informationsquelle in die Abschnitte "Harnableitung" und "Stuhlableitung" aufgenommen, sodass dort auf Dokumente, in denen weitere Informationen zu finden sind, verwiesen werden kann. |
| Urostoma aufnehmen/Einteiliges System/Zweiteiliges System/Stoma Öffnung/Hautoberfläche | Das System kann in der Angabe des Hilfsmittels berücksichtigt werden. Das Konzept "Urostomie-Katheter" wurde aufgenommen. |
„Nach gründlicher Auseinandersetzung mit der Datenstruktur konnte ich folgende Eintragungsmöglichkeiten nicht ad hoc ausfindig machen: • Angabe Zeitpunkt letzter Dauerkatheterwechsel Diese Angaben sollten auf einen Blick zu finden sein um die direkte Weiterversorgung des zu Pflegenden zu gewährleisten.“ | Folgende Inhalte sind bereits im PIO Überleitungsbogen enthalten: 1) Angabe Zeitpunkt letzter Dauerkatheterwechsel Harnableitung Anlagedatum, Entfernungsdatum 2) Angabe Zeitpunkt letzter BTM (Pflaster)wechsel bzw. letzte Medikamenteneinnahme Medikationspläne/Medikationsplan/Medikationseintrag/Letzte Medikationsverabreichung 3) Aussage über Verbandsmaterial für Überbrückungszeitraum: "Mitgegebene Dokumente / Arzneimittel / Hilfsmittel / Gegenstände" 4) Aussage über eine ausgestellte Erstverordnung HKP zur Sicherung der nahtlosen Weiterversorgung in der Häuslichkeit: "Informationsquelle" Folgende Inhalte wurden hinzugefügt: 5) Angabe Zeitpunkt letzter Stuhlgang 6) Mitgegebene Arzneimittel unter "Mitgegebene Dokumente / Arzneimittel / Hilfsmittel / Gegenstände" 7) Angabe Zeitpunkt letzter Trachealkanülenwechsel unter "Atemwegszugänge" |
| Als Freitext- Datum eingeben, wann der letzte Stuhlgang war. Bei Patienten mit Obstipation (z.B. bei Opioid-induzierte Obstipation) ist die Angabe sehr wichtig. Es fehlt ein Feld "Auffälligkeiten Stuhlgang". | Das Element "Zeitpunkt letzter Stuhlgang" wurde hinzugefügt. Auffälligkeiten beim Stuhlgang können als Pflegeproblem angegeben werden. |
| Screening- und Assessmentinstrumente hinterlegen! (allgemeiner Hinweis für Pflegerische Informationsbausteine) | Das Element "Assessment - frei / Beobachtung" kann jetzt an mehreren Stellen zusätzlich referenziert werden. |
| 1.1.1.4 VersichertenID_GKV, Phase I: Dieses Element ist als "VersichertenID" bezeichnet im Gegensatz zu 1.1.1.1 und 1.1.1.2, bei denen es "Versichertennummer" heißt. Außerdem scheint die ID der Krankenversichertenkarte unter 1.1.1.1 durchaus redundant mit anderen IDs, insbesondere mit der "VersichertenID_GKV". | Es liegt keine Redundanz vor. KVK-Nummer findet nach wie vor Anwendung bei "sonstigen Kostenträgern" (z.B. Bundesbahn- und Postbeamtenversicherung, Bundesgrenzschutz, Bundeswehr, Zivildienst, sowie Verträge zu Leistungen im PKV-Basistarif) und unterscheidet sich strukturell von der GKV-ID. |
In der ambulanten und stationären Langzeitpflege ist die strukturierte Informationssammlung (SIS) das Assessment, das von der überwiegenden Anzahl de Einrichtungen standardmäßig verwendet wird. | Das Strukturmodell/SIS® eignet sich nach Abklärung mit EIN-STEP in seiner aktuellen Konzeption nicht für eine Überleitung – dies ist auch nicht die Intention. Einzelne Informationen aus dem Strukturmodell/SIS® können in den Überleitungsbogen einfließen. |
Es sollten die Möglichkeiten der Angabe einer Sauerstoffsättigung über Beatmungsgeräte berücksichtigt werden. | Auch an Beatmungsgeräte angeschlossene Pulsoximeter können für die Angabe der peripheren Sauerstoffsättigung verwendet werden, wenn sie die periphere Sauerstoffsättigung messen. |
Beatmungspatienten mit entsprechenden Geräten müssen berücksichtigt werden> also das Ablesen der Beatmungsparameter | Einzelheiten zu Beatmungseinstellungen strukturiert abzulegen, würde in der aktuellen Fassung des Überleitungsbogens die Zielstellung und den Rahmen übersteigen. Im neu hinzugefügten Element "Atmungsunterstützung" gibt es aber ein Freitextfeld, in das solche Angaben eingetragen werden können. |
| Pflegeprobleme und Ressourcen sind momentan im Überleitungsbogen der Software nicht enthalten, da in den meisten Pflegeeinrichtungen mittlerweile die SIS® als Assessmenttool eingesetzt wird. Sinnvoller wäre es hier, stattdessen die SIS® zu verwenden, da unter Umständen die Bemühungen der letzten Jahre zur Vereinfachung der Pflegedokumentation zunichte gemacht werden könnten. | Das Strukturmodell/SIS® eignet sich nach Abklärung mit EIN-STEP in seiner aktuellen Konzeption nicht für eine Überleitung – dies ist auch nicht die Intention. Einzelne Informationen aus dem Strukturmodell/SIS® können in den ÜLB einfließen. |
| Besteht bei über den ÜLB hinaus relevanten Informationsbausteinen eine definierte Schnittmenge zu anderen MIO's? Ist konzeptionell eine Übernahme/Ausleitung bzw. ein Abgleich mit für Ärzten relevanten MIO's (z.B. eWundbericht, eHygienebericht) vorgesehen? Ist angedacht oder damit zu rechnen, dass auch niedergelassene Ärzte den eÜberleitungsbogen (als Kopie bzw. Zugriffsrecht auf die ePA) erhalten sollen? | Die kleinste Schnittmenge zwischen dem PIO Überleitungsbogen und anderen MIOs besteht aus den Elementen, die in den KBV-Basis-Profilen definiert sind (siehe https://mio.kbv.de/display/BASE1X0). In allen MIOs bzw. PIOs werden diese übergreifend abgestimmten und definierten Elemente von den KBV-Basis-Profilen abgeleitet. Die KBV-Basis-Profile werden schrittweise um Elemente, die in mehreren MIOs/PIOs verwendet werden, erweitert. Das Ziel der Definition von Basis-Profilen ist die Interoperabilität zwischen den MIOs/PIOs. Es bedeutet Voraussetzungen zu schaffen, damit Informationen ohne technische Probleme innerhalb des Primärsystems übernommen werden können. Es ist jedoch anzumerken, dass für die Nachnutzung von Informationsbausteinen aus anderen Dokumenten die Berechtigung der behandelnden Person auf das entsprechende MIO/PIO vorliegen muss. Wie genau dann die Übertragung oder ein Abgleich von Informationen bewerkstelligt wird, hängt von der jeweiligen Umsetzung seitens des Softwareherstellers ab. Alle behandelnden Personen können auf ein PIO Überleitungsbogen in der ePA zugreifen, wenn der/die PatientIn diese auf das Dokument berechtigt. Der Zugriff auf das PIO oder andere Inhalte der MIOs erfordert zudem eine Umsetzung im benutzten System, in diesem Beispiel eine Anzeigemöglichkeit im Praxisverwaltungssystem des Arztes / der Ärztin. |
SIS Assessment in der stationären Langzeitpflege: Codes für Themenbereiche und Risikomatrix erforderlich Für die strukturierte Übermittlung des SIS Assessments aus der stationären und ambulanten Langzeitpflege sind Codes für die folgenden Themenbereiche des SIS Bogens erforderlich, die in SNOMED nicht definiert sind: Beim in der stationären und ambulanten Langzeitpflege vorwiegend verwendeten "Strukturmodell" werden im Assessment mit dem SIS-Bogen Einschätzungen zu 5 grundsätzlichen Risiken und Phänomenen strukturiert erhoben:
ES IST WICHTIG, dass diese Informationen über in passendes Codesystem vollständig übertragen werden können, z.B. für den Wechsel von einer ambulanten in eine stationäre Langzeitpflege. | Das Strukturmodell/SIS® eignet sich nach Abklärung mit EIN-STEP in seiner aktuellen Konzeption nicht für eine Überleitung – dies ist auch nicht die Intention. Einzelne Informationen aus dem Strukturmodell/SIS® können in den Überleitungsbogen einfließen. |
Welchen Sinn und Wert hat die Information zum Vorliegen eines Problems (2.1.1), wenn im Fall der Angabe, dass Probleme vorliegen (Code = 55607006 : 363713009 = 52101004) bei allen weiteren Informationen (2.1.2 und 2.1.3) die Konformität mit „O“ (optional) angegeben ist und somit keine weiteren Informationen angegeben werden brauchen? Es sollte geprüft werden, ob im Falle der Angabe, dass Probleme, Risiken, Schmerzsymptomatik oder Informationen zu Ernährung, Funktionsbeurteilung, Medizinprodukten und/oder Allergien und Unverträglichkeiten vorliegen (siehe jeweils Werteliste „liegen vor“) keine weiteren Informationen angegeben werden brauchen oder ob es sinnvoller wäre, in diesem Fall die Angabe weiterer Informationen als benötigt zu kennzeichnen, d.h. mit KONFORMITÄT = „C“ (conditional) oder „R“ (required). | Die Anmerkung zur Notwendigkeit einer konditionalen Konformität ist nachvollziehbar. Wenn angegeben wird, dass Probleme vorliegen, kann dies in FHIR® so umgesetzt werden, dass eine Angabe von Problemen notwendig wird. Das Gleiche gilt für den Abschnitt Risiken. |
Warum muss das Vorliegen:
| Der Informationsgehalt der Angabe "Vorliegen von Problemen" besteht darin, dass unterschieden werden kann zwischen einer Nichtangabe wegen fehlender Information - z.B. weil gar nicht nach Problemen gefragt wurde - und der bewussten Aussage, dass es keine Probleme gibt. |
| Eine rein qualitative Beschreibung der Atmung empfinde ich als unzureichend. Hier wäre ein Hinweis auf notwendige Atemunterstützung (bspw. Heimbeatmungsgeräte, Atemwegszugänge, ...) oder Sauerstoffpflicht notwendig. | Folgende Elemente wurden in Zusammenhang mit der Atmung ergänzt:
|
| PIO ist dem Konzept nach ein pflegerisches Informationsobjekt. Daher kann es sich nicht um "Patientin" handeln. Der Terminus ist der medizinischen Terminologie entlehnt und in den entsendenden Einrichtungen außerhalb der Klinik nicht gebräuchlich. Die Spezifizierung wäre hier zu ergänzen durch zum Beispiel „Mensch mit pflegerischem Versorgungsbedarf“ oder „Pflege-Klientin“. | Der Begriff PatientIn leitet sich aus einem KBV-Basis-Profil ab und dient lediglich der übergreifenden, allgemeinverständlichen Darstellung. Einem abweichenden Anzeigenamen steht dies nicht entgegen. Es kann entsprechend von den Primärsystemen geändert werden. |
| Gemeindekennzahl Ermöglicht eine bessere Zuordnung als PLZ | Wir erkennen für die Erfassung der Gemeindekennzahl im Rahmen der Befüllung der elektronischen Patientenakte keinen direkten Nutzen für die medizinische Versorgung. |
Das Körpergewicht lässt sich an keiner Körperstelle ermitteln, sondern bekanntlich nur des gesamten Körpers; Die Körpergröße wird an keiner einzelnen Körperstelle sondern über den gesamten Körper ermittelt; Es ist unklar, warum beim Gewicht eine Körperstelle angegeben werden soll. Bitte streichen. | Das Körpergewicht und die Körpergröße sind KBV-Basis-Profile. Der Wert ist jeweils fix als "ganzer Körper" angegeben, kann also nicht verändert werden. Dieser Aufbau ist so gewählt, damit die Vitalparameter/Körpermaße untereinander konsistent sind. |
Für die Beschreibung von Sturzereignissen ist die bloße Angabe der Anzahl von Stürzen fachlich völlig unzureichend. Hier sind zwingend weitere Angaben zur Sturzsituation, -folgen, Hilfsmitteleinsatz etc. erforderlich Bei der Fragestellung der Stürze ist die Anzahl nicht ausreichend, sondern es sind auch die Umstände und der Bezug zum Sturzassessment von Relevanz (Sturzprävention /z.B. Stoppersocken). Sturzanamnese mit Datum soweit bekannt, Sturzfolge (DNQP Expertenstandard Sturzprophylaxe) Freiheitsentziehende Maßnahmen und Beschlüsse wichtig! | Eine Sturzgefährdung kann als Risiko angegeben werden. Zu einem Risiko kann das Element "Assessment - frei / Beobachtung" angegeben werden. Weiter gibt es im Abschnitt "Risiko" das Element "Anlass/Ursache". Der Abschnitt Anlass/Ursache wurde jetzt ergänzt um die Möglichkeit einer freitextlichen Angabe einer Ursache. Konkrete Assessments, z.B. unter Beachtung des DNQP Expertenstandards, können mit dem Element "Assessment - frei / Beobachtung" abgebildet werden. |
| Der Fokus der Pflege liegt auf der Erkennung von Selbstpflege-Kompetenzen und deren Aktivierung der im jeweiligen Setting zu versorgenden Menschen. Die Perspektive hat sich grundlegend von der Problemsicht in diese Richtung gewandelt. Deshalb erscheint es unangebracht, im Pflegerischen Informationsobjekt eine überholte Pflege-Perspektive zu reaktivieren. Titel ändern in „Erkennen von Selbstpflege-Kompetenzen“ oder „Erkennen von Pflege-Kompetenzen“ oder „Pflegefachliche Diagnose“ oder „Pflegediagnostik“ | Wir bemühen uns darum Begriffe zu verwenden, die von allen verstanden werden. Davon gehen wir bei "Diagnose" und "Pflegeproblem" aus. Im Primärsystem kann der Anzeigename geändert werden, wenn das nötig sein sollte. |
Es bestehen Überschneidungen, fehlende Eindeutigkeit - (zentrale Parenterale Ernährung, Periphere parenterale Ernährung, Totale parenterale Ernährung) Ernährung über perkutane endoskopische Gastrostomie und subcutane parenterale Ernährung fehlt.) | Ernährung über perkutane endoskopische Gastrostomie ist vorhanden im ValueSet für den Hinweis zur Kostdarreichungsform. Es wurde das Konzept "Magensonde" ergänzt. Der Wert "Totale parenterale Ernährung" wurde aufgrund der Uneindeutigkeit entfernt. Die Begriffe "Zentrale parenterale Ernährung" und "Periphere parenterale Ernährung" wurden in "Zentrale intravenöse Ernährung" und "Periphere intravenöse Ernährung" umbenannt. Weitere, weniger geläufige Formen der Kostdarreichungsform können als Freitext oder als selbst ausgewählter Code angegeben werden. |
| An welcher Stelle sollen die Urinmenge, die Dialysatmenge (bei Dialyse) sowie die Trinkmenge und Infusionsmenge eingetragen werden? | Die Überleitung ist keine klinische Dokumentation. Falls es wichtig ist, die genannten Informationen bei einer Überleitung zu transportieren, kann dies wie folgt geschehen: Die Trinkmenge oder eine Trinkmengenbeschränkung kann als Hinweis zur Ernährung erfasst werden. Die Dialysatmenge kann als Assessment - frei / Beobachtung erfasst werden. Hierzu wurde das "Freie Assessment" umbenannt in " Assessment - frei / Beobachtung". Die Infusionsmenge ist über die Medikations-Information abbildbar. In der zukünftigen Entwicklung der MIOs/PIOs werden weitere spezifische Aspekte bezüglich der pflegerischen und medizinischen Versorgung diskutiert und erarbeitet. |
| Geräte können über durch Referenzierung im neu geschaffenen Abschnitt "Mitgegebene Dokumente / Arzneimittel / Hilfsmittel / Gegenstände" als "mitgegeben" gekennzeichnet werden. | |
| An welcher Stelle werden sich die Angaben zur Dialysatableitung bei der Peritonealdialyse finden? Auch die Haut am Austritt des Katheters muss beurteilt werde (z.B. bezüglich einer möglichen Infektion; KAST 1-4) | Diese Angaben können über das Element "Assessment - frei / Beobachtung" gemacht werden. Da der Überleitungsbogen aktuell nur die häufigsten Konstellationen abbilden soll, wurden Informationen zur Dialyse nicht explizit modelliert. |
| Auch weitere Vitalparameter sollten optional erlaubt werden. Beobachtungen des Wundstatus, Beatmungseinstellungen, Infusionlaufraten (z.B. in der außerklinischen Intensivpflege) können ebenfalls sehr relevant für die pflegerische und medizinische Therapie des Patienten sein. | Für die Dokumentation von nicht explizit ausspezifizierten Inhalten weiterer Vitalparameter kann das Element "Assessment - frei / Beobachtung" verwendet werden. Es kann jetzt im Abschnitt "Vitalzeichen und Körpermaße" referenziert werden. |
| In der TI werden Versicherte über eine Krankenversicherungsnummer identifiziert. Hinsichtlich einer "global eindeutig Identifizierung" von Patienten (UUID) bestehen datenschutzrechtliche Bedenken, da dies die Existenz einer öffentlich zugänglichen globalen Patientendatenbank erfordern bzw. ermöglichen würde (Patienten bringen die UUID ja i.A. nicht mit). UUID bitte streichen. Da der Patient über Name und Geburtsdatum identifiziert werden kann, sollte aus Gründen der Datensparsamkeit die Angabe von einrichtungsinternen Kennzeichen wie der Fall- und Patientennummer entfallen. | Grundsätzlich halten wir es für sinnvoll, zusätzlich zu der nicht eineindeutigen Kombination aus Name und Geburtsdatum auch eine organisationsspezifische ID angeben zu können. Der Operationalisierungshinweis zur UUID dient dazu zu verhindern, dass Einrichtungen bzw. Systeme Informationen darüber mitgeben müssen, wie die PID aufgebaut ist. Eine öffentlich zugängliche globale Patientendatenbank ist kein Ziel der MIOs. Dieses Szenario ist im Kontext der ePA und der MIOs nicht vorgesehen und sollte aus dem OP-Hinweis nicht ableitbar sein. |
Kapitel 2.23 sollte in direktem Zusammenhang mit 2.20 stehen, daher nach 2.21 verschieben | Die in unserem Informationsmodell angezeigte Reihenfolge hat keinen Einfluss auf die technische Spezifikation und die spätere Umsetzung im System. Zur besseren Lesbarkeit wurden die Abschnitte wie vorgeschlagen angepasst. |
Bei der Überleitung kommt es in der Übernahmesitutation häufig zu Fragen an die übergebende Einheit. Die Nennung der entsendenden Einrichtung und des Kontaktkanals sind vielfach nicht ausreichend, um die sachgerechte Anschlussversorgung und Versorgungssicherheit von Klient:innen zu gewährleisten. Die Kontaktdaten sind mit der Konformität „M“ um eine Kontaktperson zu ergänzen. Diese Kontaktperson ist in der Regel die verantwortlich handelnde Pflegefachkraft. Diese Position ist an erste Stelle unter 1.2.5.1 zu setzen vor „Kontaktkanal“. | Es obliegt der jeweiligen Einrichtung die fachlichen und organisatorischen Vorgaben im Sinne einer Qualitätssicherung zu implementieren. Abhängig von den örtlichen Gegebenheiten und Anforderungen sollten entsprechend die Kardinalitäten und Konformitäten eingeschränkt werden. |
§ 341 Absatz 2 Nummer 10 sieht vor, dass die elektronische Patientenakte die Einstellung von Daten zur pflegerischen Versorgung ermöglicht. Bei der Auswahl der hierfür infrage kommenden Dokumente haben sich die Verbände und die mio42 GmbH nach eigenem Bekunden (https://mio.kbv.de/pages/viewpage.action?pageId=73138833, PIO Überleitungsbogen, Absatz 1) auf den Überleitungsbogen geeinigt. Der o.g. Gesetzestext sieht ausdrücklich die Berücksichtigung von Daten zur pflegerischen Versorgung nach dem elften Sozialgesetzbuch vor. Dort wurde mit dem zweiten Pflege-Stärkungs-Gesetz ein Pflegebedürftigkeitsbegriff eingeführt. Der Bedarf an pflegerischer Versorgung in der Langzeitpflege (SGB XI) wird seither mittels eines Begutachtungsinstruments festgestellt, der einem Code-System entspricht und für mittlerweile über 4 Millionen pflegebedürftige Menschen in Deutschland verbindlich angewandt wird. Ergänzt um die Risikoeinschätzung der Strukturierten Informationssammlung (SIS) ergibt sich eine Versorgungsmatrix, die alle für eine kurzfristige pflegerische Versorgung bei der Überleitung aus der Klinik in die Langzeitpflege erforderlichen Daten enthält. – Auch umgekehrt liefern die Daten des Begutachtungsinstruments im Falle der Übernahme einer pflegebedürftigen Person aus der Langzeitpflege hinreichend die für die pflegerische Versorgung erforderlichen Informationen, die allenfalls durch medizinische Daten zu ergänzen sind. | Das Begutachtungsinstrument ist kein Überleitungsinstrument. Es dient einem anderen Zweck (Leistungsgewährung). Das Strukturmodell/SIS® eignet sich in seiner aktuellen Konzeption nicht für eine Überleitung. |
Rahmenbedingung der Isolation Die Rahmenbedingungen der Isolation sollten dokumentierbar sein. So gelten z.B. während der Hämodialyse andere Kriterien der Isolation als auf einer Station im Krankenhaus oder einer Pflegeeinrichtung. | Ein Freitextfeld "Hinweis" wurde hinzugefügt. |
Falls der letzte Krankenhausaufenthalt im Pflegedokumentationssystem vorgehalten wird, sollten auch weitere Aufenthalte dort dokumentiert sein. Aus medizinischer Sicht können alle diese Aufenthalte relevant sein. Es sollte daher eine Möglichkeit geben diese optional ebenfalls zu übertragen. Daran ließen sich perspektivisch auch Diagnosen, Maßnahmen usw. verlinken. | Element "Letzter Krankenhausaufenthalt" wird ersetzt durch: Krankenhausaufenthalt 0...* Beschreibung des Elements: "Dokumentation des Zeitpunktes eines für die aktuelle Überleitung relevanten Krankenhausaufenthalts." |
| Bestimmte Maßnahmen, wie die Durchführung einer Dialyse zu Hause oder in einem Nephrologischen Zentrum sind Ärztliche Maßnahmen, die durch pflegerische Maßnahmen untrennbar unterstützt werden. Gibt es eine Möglichkeit Ärztliche und Pflegerische Maßnahmen im Überleitungsbogen gemeinsam zu beschreiben oder müssen solche Maßnahmen "künstlich" getrennt werden und später wieder zusammengeführt werden? | Da es sich um einen pflegerischen Überleitungsbogen handelt, werden pflegerische Maßnahmen beschrieben. Maßnahmen, die ärztliche Tätigkeiten beinhalten, müssten in der empfangenden Einrichtung neu bewertet werden, z.B. wenn es sich um delegierte Maßnahmen handelt. |
| 2.1.3.3.4 referenziert auf 2.1.3 unlogischer Zirkelbezug des Pflegeproblems auf sich selber | Ein Pflegeproblem kann ein anderes Pflegeproblem bedingen, z.B. Immobilität kann Ursache für einen Dekubitus sein. |
| Aus fachlicher Sicht wäre es sinnvoll, hier auch Funktionseinschränkungen mit Verweis auf 2.6 als Anlass/ Ursachen von Pflegeproblemen aufzunehmen | Der Abschnitt "Funktionsbeurteilungen" kann aus technischen Gründen nicht in Anlass/Ursache aufgenommen werden. |
Wir begrüßen ausdrücklich, dass mit der Definition des Pflegeüberleitungsbogens die Grundlage für einen interoperablen, sektorenübergreifenden Informationsaustausch im Bereich der Pflege geschaffen wurde. Aus unserer Sich lässt sich auf Grund der Komplexität des Modells jedoch schwer einschätzen in wie weit das Modell gut für die Praxis und insbesondere auch für die Nutzung in den Krankenhäusern geeignet ist. Aus unserer Sicht könnte deshalb eine Pilotierung / Erprobung - z.B. mit Krankenhäusern und Pflegeeinrichtungen - hilfreich sein, um die Praxistauglichkeit des ÜLB bewerten und das Datenmodell ggf. schärfen zu können. Unklar ist beispielsweise, wie und ob die Abbildung gängiger Instrumente wie PPR2.0 und des Pflegebegutachtungsinstruments unterstützt werden kann (im Hinblick auf die Vermeidung von Doppelerfassungen in Medizin und Pflege). Im Hinblick auf eine Nutzbarkeit des ÜLB im Krankenhausbereich sollten die Daten der Zustandsbeschreibungen und Empfehlungen zum Weaning insbesondere auch in Anlehnung an die AKI-Richtlinie des G-BA abgebildet werden können. Einige Versorgungsbereiche benötigen ggf. weitere Daten: Kinderpflege/Pädiatrie, Psychiatrie (ggf. Beschlüsse), Palliativversorgung (Vollmachten, Patientenverfügung). | Wir stimmen Ihnen zu, dass eine Pilotierung hilfreich sein könnte. Da dies nicht in den gesetzlichen Zuständigkeitsbereich der KBV/mio42 fällt, unterstützen wir ausdrücklich Vorhaben, wie bspw. aus den §125... Projekten, welche eine Erprobung und Evaluation des PIO ÜLB durchführen und nehmen Hinweise sowie Ergebnisse gerne in die Weiterentwicklung des PIO auf. PPR2 ist kein Überleitungsinstrument und der ÜLB ist kein Personalbemessungsinstrument. Daher gibt es keine Relevanz für die PPR2 im ÜLB. Das Pflegebegutachtungsinstrument ist kein Überleitungsinstrument. Es dient einem anderen Zweck (Leistungsgewährung). Angaben zum Weaning können im neu hinzugefügten Abschnitt "Atmungsunterstützung" gemacht werden. Da das PIO Überleitungsbogen zunächst eine Schnittmenge der am häufigsten benötigten Informationen abbilden soll, wurde auf spezielle Situationen (Kinderpflege/Pädiatrie, Psychiatrie, Dialyse) nicht eingegangen. Es ist aber geplant, dass der ÜLB je nach Bedarf erweitert wird. |
| Kontaktperson: Mehrfacheingaben erlauben und bitte genaue Definition des Verwandtschaftsgrades ermöglichen (wenn vorhanden) | Die Vergabe mehrerer Rollen für eine Kontaktperson ist möglich. Der genaue Verwandtschaftsgrad kann jetzt als Freitext im Feld "Hinweis" angegeben werden. Es gibt außerdem ein erweitertes ValueSet mit Verwandtschaftsgraden. |
| Wir bitten den regulativen Grundlagen für die vorgenommene Abbildung des Pflegegrades anzugeben ("Rationale"), da für den stationären Bereich Vorgaben über den OPS-Katalog existieren und nicht unmittelbar klar ist, wie diese über die aktuelle Modellierung abzubilden sind. | Die Abbildung des Pflegegrads ist im Konsens mit dem Pflegebeirat entstanden. |
| Hier sollte nicht nur angegeben werden, ob eine Pflege durch Angehörige möglich ist, sondern auch, ob diese auch tatsächlich durchgeführt wird. | Das ValueSet wurde um den Wert "Pflege durch Angehörige findet statt" ergänzt. |
Gemäß Rückmeldung aus dem Mitgliedsbereich sind die folgenden Themen im pflegerischen Teil der Überleitung nicht berücksichtigt (bitte ggf. ergänzen)
| Die genannten Informationen können folgenden Elementen des Informationsmodells zugeordnet werden:
|
| Da Dokumente vom Patienten bzw. der Patientin aus der ePA gelöscht werden können, ist die Verwendung von URIs nicht sinnvoll. Dead Links verändern das Dokument. | Aus diesem Grund ist die Informationsquelle kein Ersatz für die Information, sondern die Information wird im PIO Überleitungsbogen dokumentiert und die Informationsquelle gibt nur an, woher die Information stammt. Zusätzlich besteht jetzt die Möglichkeit, Dokumente anzuhängen. |
Bitte verwendetes Assesment ergänzen. Bitte Abneigungen ergänzen. | Ein Element "Assessment - frei / Beobachtung" ist eine der Auswahlmöglichkeiten unter "Anlass Ursache" und kann zur Dokumentation der Inhalte eines Assessments verwendet werden. Alternativ kann jetzt auch das Element "Informationsquelle" angegeben werden (z.B. wenn ein Assessment als eingescanntes Dokument vorliegt). Abneigungen können unter "Hinweis zur Ernährung" oder unter "Patientenwunsch" angegeben werden. |
Es ist unklar, warum im Abschnitt "Barthel Index Assessment" die Werte des Barthel Index im Vergleich zu "Einzelne Funktionen nach Barthel" nochmals aufgeführt werden. Bitte erläutern. Beim Barthel Index würde ggf. das Gesamtergebnis genügen. | Die Werte des Barthel-Index werden hier nur referenziert. Ein Barthel-Index muss Angaben zu allen Elementen vorweisen, um gültig zu sein. Es soll aber möglich sein, die Elemente des Barthel-Index auch für sich alleinstehend zu verwenden, falls das gewünscht ist. |
| Implantate sind in vielen Fällen Bestandteil der medizinischen Dokumentation und müssen im ÜLB nicht detailliert aufgeführt werden. Die Pflege benötigt Hinweise über Mundhygiene (Zahnprothesen). Geeignetes Value Set bereitstellen. | Eine Zahnprothese kann als Hilfsmittel im Abschnitt "Hilfsmittel" angegeben werden. |
Der Medikationsplan ist ein separates Dokument und sollte nicht noch einmal im ÜLB aufgeführt werden (Verweis, Anhang). Die Frage der Compliance und eine ggf. erforderlichen Hilfestellung bei der Medikamenteneinnahme sollten ergänzt werden. Idealerweise sollte an dieser Stelle nur eine Referenz auf den e-MP in der Patientenakte liegen - oder falls Redundanz wg. ggf. fehlender Zugriffsberechtigungen auf die ePA gewünscht ist - eine Kopie des e-MP aus der ePA. | Wenn auf einen Medikationsplan verwiesen wird, ist nicht immer garantiert, dass die behandelnde Person eine Zugriffsberechtigung hat. Außerdem soll im PIO ÜLB nur eine Momentaufnahme des Medikationsplanes abgebildet werden. Wenn nur auf ein MIO Medikationsplan verwiesen wird, könnte es zu Missverständnissen kommen, wenn sich zum Zeitpunkt des Aufrufens bereits Einträge geändert haben. Die Möglichkeit, pdf-Anhänge in der Informationsquelle zu ermöglichen, wurde ergänzt. Allerdings ist ein pdf-Anhang nicht maschinenlesbar wie ein MIO, sodass es zu Verarbeitungsschwierigkeiten im Primärsystem kommen kann. Da ein Medikationsplan für die Behandlung eines/einer PatientIn von zentraler Bedeutung ist, haben wir uns aufgrund der oben genannten Hindernisse dazu entschieden, im PIO Überleitungsbogen eine Kopie des Medikationsplanes mit Angabe der Informationsquelle zu ermöglichen. Die Datenstruktur beruht in der jetzigen Version auf bereits veröffentlichten und zukünftig zu veröffentlichenden KBV-Basis-Profilen, die mit den Inhalten von eMP, eRezept usw. abgestimmt wurden. Einnahmehinweise und Hinweise zu Hilfestellungen können jetzt in dem Freitextfeld "Sonstige Information" abgebildet werden. Hinweise zur "Compliance" sehen wir eher als Pflegeproblem oder Hinweis an die empfangende Einrichtung. |
Unter Körpergewicht fehlt die Angabe BMI sowie die Dokumentationsmöglichkeit einer starken Gewichtsveränderung in der letzten Zeit. | Der BMI kann aus den Werten Körpergröße und Gewicht berechnet werden. Eine gesonderte Angabe ist in den KBV-Basis-Profilen daher nicht geplant. Eine starke Gewichtsveränderung kann durch die Angabe mehrerer (zu verschiedenen Zeitpunkten gemessenen) Körpergewichte abgebildet werden oder alternativ als Pflegediagnose oder medizinische Diagnose. |
| Körpergröße: unklar, ob Prothesen der unteren Extremitäten einbezogen werden sollen. | Es wurde unter "Körpergröße" ein Feld "Notiz" hinzugefügt. Dort können ergänzende freitextliche Kommentare und Notizen zur Messung vorgenommen werden, die nicht durch die strukturierten Datenelemente erfassbar sind. |
Beratungsinhalte zu Pflegerisiken Die individuellen Beratungsinhalte zu festgestellten Pflegerisiken (Leitfaden DNQP Expertenstandards) fehlen. Im einem Audit in Anlehnung an den DNQP Expertenstandard zur Dekubitusprophylaxe werden folgende Ergebniskriterien formuliert: "In jedem Expertenstandard der DNQP gibt es Kriterien rund um die Maßnahme einer Pflegeberatung (siehe Anlagen, aus den DNQP Standards). Für die Gewährleistung einer kontinuierlichen Versorgung ist die Dokumentation der individuellen Maßnahmenplanung (bezugnehmend auf die Beratungsempfehlung der Pflege) bei der Pflegeüberleitung zu sichern. Somit ist eine bereits erfolgte Beratung durch die Pflege sichtbar und kann in der ambulanten oder stationären Pflege aufgegriffen werden. . Sind die von der Pflegefachperson beratenen Maßnahmen sinnvoll? . Kann der Patient/Patientin die Zusammenhänge seiner persönlichen Gesundheitsverhaltens überhaupt nachvollziehen? . Wie ist der Dekubitus entstanden? . Was kann der Patient selber tun um einen Dekubitus zu vermeiden? Dies ist insbesondere auch für wissenschaftliche Auszüge aus einer digitalen Pflegeakte von Bedeutung" | Die geforderten Aspekte könnten wie folgt dokumentiert werden:
|
Bestellte/ für die Häuslichkeit organisierte aber noch nicht gelieferte Hilfsmittel fehlen | Es gibt jetzt die Möglichkeit, einen Freitexthinweis zum Hilfsmittel hinzuzufügen, in dem z.B. vermerkt werden kann, dass ein Hilfsmittel noch nicht geliefert wurde. |
Auf dieser Ebene handelt es sich lediglich um die Angabe, ob Risiken vorliegen oder nicht. Erst in 2.2.2.1 erfolgt die Definition des Risikos, hier könnte dann in Freitext oder codiert das angewendete Assessment mit Ergebnis angezeigt werden. | Vielen Dank für Ihre Anmerkung, der wir zustimmen. |
Ein Assessment ist in Abschnitt 2.6.2 ff hinterlegt. | Vielen Dank für Ihre Anmerkung, der wir zustimmen. |
| Die Anzahl der Stellen einer GKV Nummer ist in Art Decor auf 10 beschränkt, aber in FHIR fehlt diese Einschränkung. | Die Anzahl der Stellen der GKV Nummer ist auch in FHIR® beschränkt. Die Stellenbeschränkung wird im vererbenden KBV-Basis-Profil festgelegt, welches vom HL7 Basisprofil abgeleitet ist, und deshalb nicht extra als Constraint im Überleitungsbogen aufgeführt. |
Eine Erweiterung der Kontaktkanäle in 1.4.2.1.4.1 KONTAKTKANAL um die folgenden Werte ist wünschenswert: | Kontaktkanäle, die in der Auswahlliste nicht explizit genannt werden, können als "Sonstiges" gekennzeichnet werden. |
Codierung
| Kommentarthema | Ergebnis |
|---|---|
| Türkisch fehlt in der Auswahlliste bevorzugte Sprache | Wir werden Türkisch als Sprache in die Auswahlliste (ValueSet) zur bevorzugten Sprache aufnehmen. Allerdings sollte dies nicht entkoppelt von den Releases der KBV-Basis-Profile geschehen. Daher kann Türkisch womöglich erst mit einem Fortschreibungs-Release in ein entsprechendes ValueSet eingehen. |
| Codesystem-Übersicht: LOINC ist Doppelt und Canonical URI fehlt | Derzeit wird eine Referenz ("Link zum Verwendeten Code-System") auch für die FHIR®-Codesysteme geführt. Diese entspricht der Defining URL des jeweiligen FHIR®-Codesystems. Ein entsprechender Hinweis wird hinzugefügt werden. Für das FHIR® ValueSet Languages (http://hl7.org/fhir/ValueSet/languages) ist derzeit eine Definition für eine entsprechende OID für BCP-47 (http://tools.ietf.org/html/bcp47) in Arbeit. Das FHIR® ValueSet "Reference Range Meaning" (http://hl7.org/fhir/ValueSet/referencerange-meaning) ist hier falsch geführt und wird ersetzt mit dem entsprechenden Code-System (http://terminology.hl7.org/CodeSystem/referencerange-meaning). Die redundante LOINC®-Angabe wird entfernt. |
| Angaben zu Religion sind nicht möglich | Die Religion sollte über das Element "Kulturelle Gewohnheiten" abgedeckt werden (Patientenwunsch), wird aber zukünftig durch ein dediziertes Datenelement als Freitext modelliert (Konfession/Religion unter PatientIn). |
| Deutsche Sachverhalte auf Biegen und Brechen mit SNOMED darstellen? | Der Antragsstatus zum Pflegegrad wird nicht in SNOMED CT® codiert. Ein OPS-Code wird genutzt ("9-984.b - Erfolgter Antrag auf Einstufung in einen Pflegegrad" für Konzept "Pflegegrad beantragt") und für die restlichen Konzepte wird ein eigenes Code-System erzeugt. |
| Warum werden für den Barthel-Index Codesysteme selbst definiert? | Wir definieren für den eigentlichen Barthel-Index keine eigenen Code-Systeme sondern nutzen die LOINC® Answer Codes, wie hier zu sehen: 2.6.2 Einzelne Funktionen nach Barthel, Phase I Einen Übersetzungsvorschlag haben wir an Regenstrief (über das BfArM) weitergereicht. In Bezug auf die FHIR®-Ebene ist anzumerken, dass wir "eigene" Code-Systeme für den Barthel-Index nutzen; diese benötigen wir aber nur aus technischen Gründen, um alles auf eine deutsche Bezeichnung mappen zu können. |
| Sinn der Extension TAHilfsmittel nicht klar | Diese Extension wird sowohl im Profil des Hilfsmittels als auch im Profil des Implantats verwendet und dient dazu explizit auszudrücken: "es handelt sich um ein Hilfsmittel" bzw. "es handelt sich um ein Implantat". Mit der Extension soll eine klare Abgrenzung beider Profile, welche mit der Ressource Device umgesetzt wurden, erfolgen. Der Code innerhalb der Terminologie-Assoziation war etwas unglücklich gewählt, sodass der eigentliche Sinn der Terminologie-Assoziation wahrscheinlich nicht deutlich wurde. Eine Anpassung des Codes wird erfolgen, so dass zukünftig der folgende SNOMED CT®-Code als Terminologie-Assoziation verwendet wird: 1141802005 | Assistive device (physical object) | . Dieses Konzept schließt zwar möglicherweise Hilfsmittel nicht (als Children) mit ein, die der GKV enthält, ist jedoch präziser als das generische "Device". |
| Unpassende SNOMED CT-Kodierung für den Aufenthaltsort | Da eine Beantragung gegenüber SNOMED International bereits gescheitert ist, wird hierfür ein eigenes Code-System erzeugt werden. Die Elemente dieses "ad-hoc" Code-Systems können perspektivisch Eingang in eine deutsche National Extension finden, die durch das BfArM gepflegt wird. |
| Postkoordinierte SNOMED CT-Ausdrücke in CTUF | Die Nutzung der NNF und der CTUF ist für uns ein neues Thema, dem wir uns zukünftig annehmen. Ihren Codierungsvorschlag in der NNF haben wir übernommen und die anderen PCEs analog codiert. Wir halten die Auffindbarkeit (Retrievability) medizinischer, aber auch administrativer, (wie in diesem Fall) Konzepte, die als PCEs erzeugt werden, für erstrebenswert. Bei den derzeit beobachtbaren Ausbaustufen der Anbindung zwischen FHIR®-Servern und Terminologie-Servern erscheint die maschinelle Auffindbarkeit administrativer PCEs allerdings keine hohe Priorität zu haben. Für eine Datenanalyse wäre derzeit der Kontext des Informationsmodells vermutlich ohnehin unerlässlich. |
| Kodierung für "Ambulanter Pflegedienst" | Das Konzept 66280005 |Private home-based care (environment)| wird für "Ambulanter Pflegedienst" übernommen. |
| CodeSystem KBV_CS_MIO_PS_Contactbook | Die Bezeichnung des Code-Systems war falsch und wird geändert von "KBV_CS_MIO_PS_Contactbook" nach "KBV_CS_MIO_ULB_Address_Book". |
| Unterschied zwischen Clinical findings und Observable Entities | Die vorliegende TA geht auf eine Entscheidung der HL7 TC-FHIR zurück, da deren FHIR®-Profil hier genutzt wird: https://simplifier.net/basisprofil-de-r4/gradderbehinderung --> Element code.coding:snomedct Wir sind bereits auf die TC-FHIR (HL7 Deutschland) zugegangen, um eine Anpassung der TA zu erwirken. Wir werden mit Verweis auf Ihren Kommentar erneut in den Austausch mit dem TC-FHIR gehen. |
| SNOMED PCEs problematisch für den Benachrichtigungsstatus | Die entsprechenden PCEs werden korrigiert. |
| Bezeichnung CodeSystem Krankenkassenkarte | Die Bezeichnung des Code-Systems war falsch und wird geändert zu KBV_CS_MIO_ULB_Health_Insurance_Card. |
| Fehlende Codes für "Empfehlung an die empfangende Einrichtung"? | Es fehlen an dieser Stelle keine SNOMED CT®- Codes. Es geht darum, dass von den nutzenden Einrichtungen an dieser Stelle ein geeigneter SNOMED CT®-Code zur Codierung verwendet werden kann. |
Welcher Wert entspricht "Höherstufung beantragt" (Vorgabe OPS-Katalog)? Soll dies über "Neubeurteilung aktiv" abgebildet werden und ist dies wirklich dasselbe? | Der OPS-Code "9-984.b Erfolgter Antrag auf Einstufung in einen Pflegegrad" wird genutzt für das Konzept "Pflegegrad beantragt", welches wiederum aus der bestehenden Liste entfernt wird. Das Konzept "Neubeurteilung aktiv" wird über einen eigenen Code abgedeckt. |
| Im Bereich der spezialisierten Pflegefachberufe fehlen Pflegeexperten APN (Advanced Practice Nurses) sowie Community Health Nurses (CHN). | Wir werden die Pflegeexperten APN (Advanced Practice Nurses) sowie Community Health Nurses (CHN) in der entsprechenden Auswahlliste aufnehmen. |
Technische Repräsentation
| 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. |
