gemILF_PS_ePA_V3.2.3
Elektronische Gesundheitskarte und Telematikinfrastruktur
Achtung: Version für ePA für alle Release 3.0.3 |
---|
Implementierungsleitfaden Primärsysteme ePA für alle
Version | 3.2.3 |
Revision | 1025250 |
Stand | 24.10.2024 |
Status | freigegeben |
Klassifizierung | öffentlich |
Referenzierung | gemILF_PS_ePA |
Dokumenteninformationen
Änderungen zur Vorversion
Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.
Dokumentenhistorie
Version | Stand | Kap./ Seite | Grund der Änderung, besondere Hinweise | Bearbeitung |
---|---|---|---|---|
3.0.0 | 30.01.2024 | ePA für alle | gematik | |
3.1.0 | 28.03.2024 | ePA für alle - Release 3.0.1 | gematik | |
3.2.0 | 12.07.2024 | ePA für alle - Release 3.0.2 (Ergänzung Kapitel 1 und 2, Überarbeitung Kapitel 6) | gematik | |
3.2.1 | 07.08.2024 | ePA für alle - Releasestand 3.0.2 (Anpassungen) | gematik | |
3.2.2 | 14.08.2024 | 4.1.6 | ePA für alle - Releasestand 3.0.2 (Kap. 4.1.6 ergänzt) | gematik |
3.2.3 | 24.10.2024 | ePA für alle - Releasestand 3.0.3 | gematik |
Inhaltsverzeichnis
1 Einordnung des Dokumentes
1.1 Zielsetzung
Die vorliegende Spezifikation definiert Anforderungen zu Erstellung, Test und Betrieb derjenigen Anteile eines Primär- oder Clientsystems, die zur Nutzung der ePA für alle erforderlich sind.
Technische Standards werden in der ePA verwendet, um Interoperabilität zu steigern und die technischen Voraussetzungen zur Nutzung der Anwendung zu legen. Auf Seiten der Primärsystemhersteller eröffnet die Verwendung von Standards die Chance, wiederverwendbare Schnittstellen zu entwickeln bzw. zu nutzen und einzelne Module austauschbar zu gestalten.
Zum Zweck der Implementierungshilfe werden grundlegende Konzepte und Anwendungsfälle der ePA für alle aus der Sicht der PS-Hersteller erläutert. Dabei werden nicht nur Anwendungsfälle der ePA erläutert, sondern auch praktische Umsetzungshinweise gegeben und auf entsprechende Beispiele verwiesen.
1.2 Zielgruppe
Das Dokument ist maßgeblich für Hersteller von Primärsystemen, welche die Schnittstellen der ePA für alle nutzen. Dieses Dokument kann ebenfalls als Referenz genutzt werden von TI-Verantwortlichen in Leistungserbringerinstitutionen, von Produktmanagern, UX/UI-Designern und von Schulungsverantwortlichen.
Dieser Implementierungsleitfaden gibt einerseits spezifische Anforderungen für Primärsysteme vor, bietet aber andererseits auch allgemeine Hilfestellung bei der Verwendung der ePA-Schnittstellen. Dazu gehören bspw. informative Abschnitte, die die Nutzung der IHE XDS-Schnittstellen des Aktensystems beschreiben.
Die ePA setzt zu großen Teilen auf bestehenden Standards und Spezifikationen wie denen von IHE sowie HL7 (FHIR) auf. Diese Spezifikationen werden durch ePA und auch diesen Implementierungsleitfaden in aller Regel weiter eingeschränkt ("profiliert"). Dies soll die Verwendung bestehender Software-Bibliotheken ermöglichen oder zumindest vereinfachen und zudem auch eine Wiederverwendbarkeit der umzusetzenden Schnittstellen in anderen Kontexten erlauben.
Neben den Schnittstellen zur Verwaltung von Dokumenten ("XDS Document Service" im Aktensystems) werden von der ePA auch REST-Schnittstellen angeboten, bspw. FHIR-Schnittstellen im Rahmen des "Medication Service" zur Verwaltung von Medikationsliste und -plan eines Versicherten. Der Implementierungsleitfaden beschreibt, wie diese Schnittstellen zu nutzen sind und welche zusätzlichen Anforderungen gelten.
1.3 Geltungsbereich
Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Bestätigungs- Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. [gemPTV_ATV_Festlegungen], AFO-Steckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.
Schutzrechts-/Patentrechtshinweis
Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.
1.4 Abgrenzungen
Benutzte Schnittstellen werden in der Spezifikation desjenigen Produkttypen normativ beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang 8.5).
Nicht Bestandteil des vorliegenden Dokumentes sind:
- Festlegungen zum Themenbereich Semantik von Metadaten, insoweit sie im Dokument [gemSpec_Aktensystem_ePAfueralle] beschrieben sind;
- Rendering-Vorschriften zur Form, in der ePA-Dokumente zur Anzeige gebracht werden (ggf. wird auf externe Festlegungen referenziert).
Die ePA dient dem Austausch von medizinischer Dokumentation zwischen Leistungserbringern sowie dem Versicherten. Die medizinische Primärdokumentation der Versichertendaten verbleibt im Primärsystem des jeweiligen Leistungserbringers und wird hier nur insoweit thematisiert, wie es für die Anbindung der ePA an das Primärsystem erforderlich ist.
1.5 Methodik
Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechend, in Großbuchstaben geschriebenen deutschen Schlüsselworten MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.
Anforderungen werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]
Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=] angeführten Inhalte.
1.6 Referenzen für die technische Entwicklung
Für die technische Entwicklung bietet die gematik Absprungpunkte an mehreren Stellen an:
- Dieses Projekt gibt einen Überblick über die Unterstützungsleistungen, die durch die gematik im Rahmen der Entwicklungen in der Telematikinfrastruktur bereitgestellt werden.
- In diesem Projekt befinden sich die Verlinkungen zu Inhalten, die unter GitHub verfügbar gemacht werden und größtenteils normativ sind. Sie werden auch aus der Spezifikation heraus dort, wo sie gebraucht werden, direkt über eine Literaturreferenz verlinkt.
Der ePA liegen mehrere Dokumente zugrunde, die verschiedene Aspekte beschreiben:
- Das Fachkonzept [gemKPT_FK_ePAfueralle] beschreibt die fachlichen Anforderungen an die ePA unter Berücksichtigung der geltenden Gesetzeslage.
- Die Konzeption und Spezifikationen beschreiben die normativen Festlegungen auf Produktebene, u.a.:
- https://github.com/gematik/ePA-Basic/tree/ePA-3.0.3
- https://github.com/gematik/ePA-Basic/blob/ePA-3.0.3/concept/concept.adoc
- https://github.com/gematik/ePA-XDS-Document/blob/ePA-3.0.3/concept/concept.adoc
- https://github.com/gematik/ePA-Medication/blob/ePA-3.0.3/concept/concept.adoc
- https://simplifier.net/guide/medication-service?version=current
Das ePA-Aktensystem stellt die zentralen Schnittstellen der ePA bereit:
Für Primärsystemhersteller werden die Anforderungen an die Umsetzung der ePA für unterschiedliche Typen von Primärsystemen bzw. Clientsystemen in einem sogenannten Steckbrief zusammengefasst. Die Steckbriefe der PS- und CS-Typen enthalten Listen der jeweils relevanten Anforderungen:
Für die Softwareentwicklung kann auf das Repository der gematik zugegriffen werden:
- Das Projekt enthält einen Mock-Up des ePA Aktensystems (konkret VAU-Aufbau, IDP-Flow, Information-Service, Entitlement-Service und Medication-Service), welches zu Test- und Entwicklungszwecken genutzt werden.
1.7 Namenskonvention und IHE
Das IT Infrastructure Technical Framework von Integrating the Healthcare Enterprise (IHE) ist unter anderem Stand der Technik. Auf Basis der von IHE definierten Transaktionen des XDS.b-Integrationsprofils werden Anwendungsfälle über Schnittstellen zwischen den beteiligten Produkttypen und Komponenten umgesetzt.
Beim Einstellen eines Dokuments muss dieses gemäß IHE mit Metadaten (Autor, eindeutige Dokumentenkennung, Dateiformat etc.) versehen werden, die zusammen mit dem Dokument im XDS Document Service gespeichert werden. Ein oder mehrere Dokumente werden in IHE immer als Paket (sog. SubmissionSet) übertragen. Die Zugehörigkeit eines Dokuments zu einem SubmissionSet wird auch im XDS Document Service gespeichert, d.h., es ist ersichtlich, welche Dokumente von wem eingestellt wurden. Für die Anwendungsfälle zum Herunterladen und Löschen von Dokumenten muss zunächst eine Abfrage der Metadaten erfolgen, da in den Metadaten eine Referenz auf die Dokumente enthalten ist. Über diese Referenz können ein oder mehrere Dokumente heruntergeladen oder gelöscht werden. Ebenfalls kann der Anwendungsfall Aktualisieren von Metadaten umgesetzt werden.
Für einen Zugriff auf einmal eingestellte Dokumente stellt ein Client eine Suchanfrage ("Registry Stored Query" gemäß IHE), die sich immer auf das aktuelle ePA-Aktenkonto und die Metadaten der Dokumente bezieht. Eine Versicherten- bzw. ePA-Aktenkontenübergreifende Suche ("alle Versicherten mit den Eigenschaften...") ist nicht möglich. Der XDS Document Service liefert auf Wunsch pro Treffer den vollen Satz der zum Dokument zugehörigen Metadaten oder eine Referenz zurück. Die Ergebnismenge kann vom Client nach den Wünschen des Nutzers nachgefiltert und sortiert werden.
1.8 Formate beim Einstellen von Dokumenten
Der XDS Document Service des ePA-Aktensystems unterstützt gemäß [gemSpec_Aktensystem_ePAfueralle#A_24864] folgende MIME-Type-Formate und Dateiendungen:
- application/pdf (nur PDF/A-1 und 2) (pdf)
- text/plain (txt)
- application/xml (xml)
- application/hl7-v3 (xml)
- application/pkcs7-mime (p7)
- application/fhir+xml (xml)
- application/fhir+json (json)
Dokumente im PDF-Format werden vom XDS Document Service abgelehnt, da sie ausführbaren Code enthalten können. Daher müssen die Clients PDF-Dokumente im Format PDF-A erzeugen. PDF-Dokumente, die nicht im Format PDF-A vorliegen, müssen vor dem Einstellen in die ePA gemäß A_24967* in ein PDF/A-Format konvertiert werden.
1.9 Medizinische Informationsobjekte
Die strukturiert in die ePA einzustellenden Inhalte werden nach § 355 SGB V von der Kassenärztlichen Bundesvereinigung (KBV) in der Form von medizinischen Informationsobjekten (MIO - https://mio.kbv.de/site/mio#tab-Rund+um+die+MIOs ) festgelegt. Im Fachkonzept und in den Spezifikationen der gematik zur ePA werden zudem weitere Anwendungsfälle und strukturierte Datenformate beschrieben und benannt, die ebenfalls einzustellen sind (bspw. der eArztbrief der KBV oder auch Verordnungs- und Dispensierdaten des E-Rezepts).
1.10 Die ePA nach § 341 SGB V
Bei der elektronischen Patientenakte nach § 341 SGB V handelt es sich um eine Anwendung der Telematikinfrastruktur. Sie ist verpflichtend von den gesetzlichen Krankenkassen anzubieten. Die ePA setzt sich u.a. aus einem Server (ePA-Aktensystem) und einem Client zusammen (aus Sicht eines Leistungserbringers ist dies das Primärsystem). Für Leistungserbringer stellt ihr Primärsystem ihre Primärdokumentation zur Verfügung, während die ePA als versorgungsbegleitende Sekundärdokumentation anzusehen ist. Die gerichtete Kommunikation zwischen Leistungserbringern ist nicht der primäre Fokus der ePA; hierfür können u.a. die TI-Anwendungen Kommunikation im Medizinwesen (KIM) und der TI-Messenger genutzt werden. Für den Versicherten kann die ePA ihre Primärdokumentation und ihren Speicherort für ihre eigenen Gesundheitsdaten und -dokumente darstellen. Der Systemüberblick der ePA wird in Kapitel 2 beschrieben.
Wenn ein Versicherter der ePA widersprochen hat, dann ergeben sich keine Nutzungsszenarien für Leistungserbringer im Umgang mit der ePA, wenngleich das Primärsystem auf das Vorhandensein einer ePA prüft. Wenn ein Versicherter der ePA nicht widersprochen hat, dann ergeben sich Lese- und Schreibmöglichkeiten und -pflichten für Leistungserbringer im Umgang mit der ePA. Die ePA ersetzt nicht die lokale Behandlungsdokumentation.
Aus Nutzersicht soll das Hochladen von Dokumenten in die ePA so einfach und schnell wie möglich gestaltet sein sowie doppelte Arbeitsschritte vermieden werden. Das PS soll den Nutzer dabei unterstützen. In der Benutzerführung soll für den Nutzer daher bei der Erstellung dieser Dokumentenarten sichergestellt werden, dass diese Dokumente standardmäßig ohne nachträgliche Metadateneingaben in die ePA eingestellt werden können.
Aufgrund gesetzlicher Vorgaben gibt es bestimmte Daten und Dokumentenkategorien, die verpflichtend von einem Leistungserbringer in die ePA des Versicherten hochgeladen werden müssen. Die Grundlage dafür findet sich je nach Leistungserbringergruppe u.a. in §§ 347, 348 und 349 SGB V.
Mit Verabschiedung des Digital-Gesetzes sind Leistungserbringer künftig zum Hochladen folgender Dokumente verpflichtet, wenn diese im Rahmen der Behandlung entstehen:
- Verordnungs- und Dispensierdaten (dies geschieht automatisch über den E-Rezept-Fachdienst, mit Implementierung des E-Rezepts muss aus Sicht des Primärsystems nichts weiter getan werden)
- Medikationsplan (mit Einführung der ePA 3.1)
- Krankenhaus-Entlassbrief (nach stationärer Behandlung, sowohl vorläufige als auch endgültige Version) (im PDF/A Format)
- Laborbefund (im PDF/A Format)
- Bildbefund (im PDF/A Format)
- Befundberichte aus invasiven oder chirurgischen sowie aus nicht-invasiven oder konservativen Maßnahmen (im PDF/A Format)
- eArztbrief (nach ambulanter Behandlung) (im PDF/A Format) (Empfehlung: aus dem KIM-Workflow heraus)
Die Verpflichtung zum Hochladen eines Dokuments steht in Abhängigkeit von dessen Inhalt. Enthalten Dokumente sensible Informationen, dann muss der Leistungserbringer seinen Patienten darüber informieren und sicherstellen, dass einem Hochladen nicht widersprochen wird. Gemäß §§ 347 und 348 SGB V handelt es sich hierbei um Informationen, die stigmatisierende Auswirkungen haben können wie beispielsweise sexuell übertragbare Infektionen, psychische Erkrankungen und Schwangerschaftsabbrüche. Bei Ergebnissen genetischer Untersuchungen oder Analyse muss gemäß § 353 (3) SGB V eine ausdrückliche Einwilligung zum Hochladen in schriftlicher oder elektronischer Form vorliegen.
Falls der Versicherte dem Hochladen eines Dokuments widerspricht, muss diese Entscheidung im Primärsystem nachprüfbar in der Behandlungsdokumentation protokolliert werden. Zusätzlich soll das betroffene Dokument im Primärsystem gekennzeichnet werden. Eine solche Kennzeichnung soll einfach hinterlegt und ebenso wieder entfernt werden können. Bevor eine Kennzeichnung entfernt wird, soll dem Nutzer des Primärsystems eine Warnung angezeigt werden. Beim Versuch des Hochladens eines gekennzeichneten Dokuments in ein ePA-Aktenkonto soll eine Hinweismeldung angezeigt und das Hochladen unterbunden werden.
Für Leistungserbringer mit einem unmittelbaren Patientenkontakt sollen von ihnen erstellte Dokumente direkt in das ePA-Aktenkonto hochgeladen werden. Für Leistungserbringer mit einem mittelbaren Patientenkontakt liegt unter Umständen kein technisch nachgewiesener Behandlungskontext vor und damit keine Möglichkeit Dokumente in das ePA-Aktenkonto einzustellen. Daher wird empfohlen, dass erstellte Dokumente von dem Leistungserbringer in das ePA-Aktenkonto hochgeladen werden, der den Befundbericht mit der Patient:in bespricht. Eine gesetzliche Regelung gibt es nicht, ob der Versender oder Empfänger eines Dokuments dieses in das ePA-Aktenkonto hoch lädt.
Die Auflistung der Verpflichtungen wird mit den neueren Versionen dieses Implementierungsleitfadens stets aktualisiert.