Stellungnahmeergebnisse

1. Softwarehersteller sollten darauf hingewiesen werden, dass die Ärzte ohne zusätzliche Aufwände, wie z.B. manuelles Umkodieren, einen Notfalldatensatz (NFDM) befüllen können sollen.

2. In der nächsten PKA-Version soll eine Befüllung der International Patient Summary (IPS) möglich sein, ohne dass umfangreiche Ergänzungen oder gar eine manuelle Umschlüsselung von Kodierungen durch den Arzt vorgenommen werden müssen.

Eine möglichst flüssige Übernahme von Daten aus MIOs in IT-Systeme ist bei allen MIOs wünschenswert. Durch die standardisierte Spezifikation der MIOs wird das erleichtert. Dabei können jedoch die internen Datenstrukturen der IT-Systeme nicht vorgegeben werden. Die IT-Systemhersteller sollten immer Kundenanforderungen zum erleichterten Umgang mit MIOs berücksichtigen.

Durch ein Mapping im Informationsmodell zum NFDM und wo möglich zur eHDSI-Spezifikation, werden Informationen zur Umsetzung einer flüssigen Datenübernahme bereitgestellt.

In der Fortschreibung des MIO Patientenkurzakte werden Entwicklungen zur IPS auf der EU-Ebene (eHDSI) für einen möglichst flüssigen grenzüberschreitenden Datenaustausch berücksichtigt.

Für die Berücksichtigung semantischer Interoperabilitätsfestlegungen für den europäischen Datenaustausch (§ 219d Abs. 6 SGB V) bitten wir um die Berücksichtigung folgender Anmerkungen für die Codierung:

• LOINC-Codierung der Abschnitte:
• Ergänzung des Elements „Absent or Unknown“
• Zuordnung der Versicherungsnr zu „Insurance Number“
• Überprüfung der Zuordnung der Kodierung im Abschnitt „Persönliche Erklärung“
• Für den grenzüberschreitenden Datenaustausch sollten die aktuellen Vorschläge für eine Erweiterung der MIO PKA und der Preferred Code Systems in Kapitel 4 der Patient Summary Guidelines Revision 3 vom Juni 2021 geprüft und ggf. aufgenommen werden
• Hinweis für Freitext-Datenfelder

Wir haben Ihre Hinweise wie folgt berücksichtigt:

• LOINC®-Codierung der Abschnitte: "Die LOINC®-Codierung der Abschnitte wurde wie folgt angepasst: Implantat → 1184586001 |Medical device document section (record artifact)|"

• Ergänzung des Elements „Absent or Unknown“ : Dieses Element ist in dem NFDM nicht vorgesehen. Da das MIO Patientenkurzakte eine 1:1 Umsetzung des NFDM sein soll, konnten diese Felder nicht aufgenommen werden. Wir haben sie aber im Projekt "Patientenkurzübersicht", das sich an die IPS anlehnt, umgesetzt: Patientenkurzübersicht

• Zuordnung der Versicherungsnr. zu „Insurance Number“: Die Anpassung des eHDSI Mappings wurde umgesetzt, indem der Text in der Rationale zum Abschnitt "Versicherungsnummern" angepasst wurde von 

  
  

  "In dem Template eHDSI Patient Summary entspricht das dem Element: "National Health Care patient ID (country of affiliation), epsos-dataelement-7"

  zu:

  "In dem Template eHDSI Patient Summary entspricht das dem Element: "Insurance Number epsos-dataelement-15".

• Überprüfung der Zuordnung der Codierung im Abschnitt „Persönliche Erklärung“: Das Element "Einwilligung" und das Element "Erklärung" stimmen nicht überein und beziehen sich auf unterschiedliche Inhalte: "Einwilligung" bezieht sich auf die Zustimmung des/der PatientIn zum Anlegen eines DPE bzw. NFD. "Erklärung" bezieht sich auf von PatientInnen abgegebene Verfügungen, bspw. Patientenverfügungen. Da diese Begrifflichkeiten unterschiedliche Inhalte abbilden, werden dementsprechend auch unterschiedliche Codes verwendet.

• Für den grenzüberschreitenden Datenaustausch sollten die aktuellen Vorschläge für eine Erweiterung des MIO Patientenkurzakte und des Preferred Code Systems in Kapitel 4 der Patient Summary Guidelines Revision 3 vom Juni 2021 geprüft und ggf. aufgenommen werden: Diesen Hinweis werden wir für die Erweiterung des MIO Patientenkurzakte berücksichtigen.

• Hinweis für Freitext-Datenfelder: Wir haben einen übergreifenden Operationalisierungshinweis formuliert, der auf die Datenspende und die damit verbundene Datenschutzproblematik bei Freitexten hinweist. Dieser lautet wie folgt: "Freitexte und Datenspende - Operationalisierungshinweis für erstellende Systeme: Gemäß § 363 SGB V können PatientInnen ihre Daten für eine Datenspende freigeben. Hierbei sollte beachtet werden, dass bei Freitextfeldern (String/Freitext) keine Daten hinterlegt werden, die eine eindeutige Zuordnung zu einer Person ermöglichen (z.B. Name, Versichertennummer). Das erstellende System sollte die eintragende Person beim Befüllen von Freitexten darauf hinweisen."

Stellungnahme AWMF

Wir begrüßen die hervorragenden Arbeiten zur Patientenkurzakte mit den internationalen Standards FHIR, LOINC, SNOMED CT und den WHO-FIC-Klassifikationen auf Basis der International Patient Summary (IPS).
Eine abgestimmte und gemäß den internationalen Vorgaben der SDO durchzuführende Governance aller beteiligten Institutionen ist jedoch zwingend erforderlich, um die Spezifikationen national zu koordinieren und international kompatibel zu halten. Diese Governance soll gemäß Gesundheits-IT-Interoperabilitäts-Governance-Verordnung (GIGV) bei dem Interop-Council erarbeitet werden. Hierfür müssen zwingend die SDOs und die im Gesetz verankerten Institutionen gemäß den internationalen Prozessen einen Abstimmungsvorgang und eine Zusammenarbeit gewährleisten.

Um die Patientenkurzakte an National Contact Points anschlussfähig zu machen und auch national kompatibel zu halten, fehlen zudem wichtige Komponenten.

Eine nationale Value Set Authority zur Koordinierung der umfangreichen terminologischen Arbeiten beim BfArM in Zusammenarbeit mit der AWMF. Hier müssen deutschlandweit einheitliche Übersetzungsarbeiten erfolgen. Dabei sind die TermInfo-Herausforderungen zu adressieren (HL7-Vokabular/Syntax vs. Vorgabe der Terminologien). In diesem Zusammenhang fallen bei Ihrer Spezifikation zur PKU negativ auf
• Es gibt uneinheitliche Übersetzungen in verschiedenen Spezifikationen von MII, KBV, MIO42, beispielsweise die Seitigkeit in OPS und ICD im Vergleich zur FHIR Spezifikation
• Es werden nicht-evidenzbasierte medizinische Value Sets verwendet. Die Einbindung der AWMF und der Berufsverbände ist erforderlich.
• Häufig wird CodeableConcept.text nicht genutzt, anstatt dessen werden umfangreiche Extensions definiert, die international nicht kompatibel sind.

Eine Kompatibilitätsmatrix aller gesetzliche vorgeschriebenen Spezifikationen ist ebenfalls zu bemängeln. Diese Matrix ist mit einer adäquaten Software auszustatten.

Wir erlauben uns, eine Anhang mit einigen weiter detaillierten Kommentaren hinzuzufügen.

Wir unterstützen die Publikation der IPS Spezifikation aus den oben vorgetragenen Gründen daher nicht.

In der ersten Version des MIO Patientenkurzakte liegt der Fokus darauf, die NFDM-Spezifikation möglichst 1:1 abzubilden und somit die parallele Nutzung der Notfalldaten auf der eGK und der Online-Anwendung zu ermöglichen, solange die eGK-Speicherung noch gesetzlich vorgesehen ist. Für die darauffolgende Ausbaustufe liegt der Fokus dann auf einer IPS. Wo möglich haben wir bereits jetzt ein Mapping zur eHDSI-Spezifikation angegeben. Wir sind u.a. mit der gematik und dem BfArM im Austausch dazu, wie in einer Folgeversion des MIO Patientenkurzakte die eHDSI-Spezifikation noch besser berücksichtigt werden kann. Wir werden anregen, den AWMF in diesen Prozess mit einzubeziehen.

Mit Veröffentlichung Ihrer Stellungnahme werden wir gerne das BfArM auf Ihren Vorschlag einer „Value Set Authority“ hinweisen. Wir werden außerdem anregen, den AWMF in der Diskussion zur Weiterentwicklung der Patientenkurzakte aktiv einzubeziehen. 

Die Seitigkeit wurde im MIO Patientenkurzakte mit ICD ohne sprachliche Übersetzung codiert. Wenn Sie weitere Hinweise dazu haben, gehen wir diesen gerne nach.

Gerne gehen wir konkreten Hinweisen nach. Wenn Sie uns die ValueSets nennen, werden wir überprüfen, aus welcher Quelle diese stammen.

Wir schätzen das Feedback des AWMF und befürworten die aktive Einbringung von Verbesserungsvorschlägen in der Kommentierungsphase sowie als Teil der Benehmensherstellung.

Da wir eine einheitliche Lösung für alle MIOs anstreben, ist die Verwendung des Elements CodeableConcept.text für die deutschen Anzeigenamen nicht möglich. Dieses Element wird in der Regel für Freitextangaben genutzt.

Wir arbeiten momentan an einer neuen Lösung, durch die die komplexen Extensions entfallen würden.

Geplant ist es, weiterhin eine Extension für die deutschen Anzeigenamen zu verwenden, jedoch wollen wir eine eigene Extension entwickeln, die weniger komplex ist. 

Zudem wollen wir die ConceptMaps, die in der Element-Definition der Extension referenziert werden, pro MIO zu einer großen ConceptMap zusammenfassen, damit nicht an jeder Extension die freitextliche Definition ausgelesen werden muss, um die Information zu erhalten, in welcher ConceptMap die entsprechenden Anzeigenamen enthalten sind.

Wir sind derzeit mit verschiedenen Parteien in Klärung, ob diese Lösung eine Verbesserung darstellt und wären auch an Ihrer Meinung interessiert. Dazu kommen wir gern auf Sie zu.

Wir nutzen in einzelnen MIOs bewusst verschiedene Versionen von SNOMED CT®. Das kommt z. B. daher, dass wir ValueSets aus dem europäischen Master ValueSet Katalog verwenden, die ihrerseits zurückgezogene Codes (aus alten SNOMED® Versionen) beinhalten.

Wir sehen ebenso den Bedarf einer zentralen Terminologie-Infrastruktur zur Bereitstellung aller benötigten Terminologien und setzen uns hierfür ein. 

Die Extension für Diagnosesicherheit aus den deutschen Basisprofilen wird in unserer Spezifikation bereits verwendet. Diese bezieht sich jedoch direkt auf den verwendeten ICD-10 Code. Die Angabe unter Condition.severity dient der Angabe des generellen Schweregrads.

Ergänzung nach vertiefender Kommunikation mit dem AWMF:

In der HL7®-DE Basis, von der die KBV-Basis-Profile abgeleitet sind, werden die Diagnosesicherheit und die Seitenlokalisation über Extensions am ICD-10-Code dargestellt.

Zusätzlich haben wir jetzt die Diagnosesicherheit (verification status) auf höherer Ebene ermöglicht, also für den Fall, dass zur Diagnoseangabe kein ICD-10 verwendet wird. In der FHIR®-Spezifikation der KBV-Basis ist der verification satus bereits nicht ausgeschlossen.

Die Extension ist im MIO als optionales Feld möglich, jedoch ist das Element bodySite ein FHIR®-Element, welches gezielt für die Seitenlokalisation der gesamten Condition bestimmt ist. Das Element bodySite würden wir somit nicht ausschließen, da sich die Extension nur auf den ICD-10 Code bezieht und bodySite auf die gesamte Condition.

Ergänzung nach vertiefender Kommunikation mit dem AWMF:

Wir können Ihre Anmerkung sehr gut nachvollziehen. Grundsätzlich ist es in dem KBV-Basis-Profil möglich, spezifischere Angaben zur Seitenlokalisation und Angaben von Mehrfachinformationen zu machen.  Im Falle der Patientenkurzakte sind durch die Vorgabe der 1:1 Umsetzung des NFD andere Körperlokalisationen von Diagnosen als die Seitenlokalisation nicht möglich. Auch das Öffnen des Bindings oder der Kardinalitäten ist uns dadurch nicht möglich.

Das KBV-Basis-Profil wurde im MIO Patientenkurzakte aufgrund der Vorgaben der NFDM-Spezifikation gekürzt. Es fehlt zum Beispiel die Anschrift. Der Inhalt der Patientenkurzakte basiert auf den Vorgaben der gematik zum NFDM. Es ist nicht erwünscht, dass mehr Informationen als im NFDM vorgesehen in die Patientenkurzakte gelangen.

Ergänzung nach vertiefender Kommunikation mit dem AWMF:

Die Sicherstellung der Interoperabilität durch eine gemeinsame Governance ist auch für uns ein erstrebenswertes Ziel, das wir ganz grundsätzlich verfolgen. Da die Spezifikation des MIO Patientenkurzakte an Vorgaben der gematik gekoppelt ist, wurde das KBV-Basis-Profil gekürzt.

Wir werden die Codes entsprechend http://hl7.org/fhir/uv/ips/STU1/ValueSet-pregnancy-status-uv-ips.html