Elektronische Gesundheitskarte und Telematikinfrastruktur

Implementierungsleitfaden Primärsysteme ePA für alle

    

     

      
Version
      
3.3.0
     
     

      
Revision
      
980795
     
     

      
Stand
      
22.08.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

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.

Falls ein Primärsystem bisher das technische Framework von IHE noch nicht verwendet, wird es durch diesen Implementierungsleitfaden in die Lage versetzt, die ePA-Schnittstellen IHE-konform zu verwenden.

Falls ein Primärsystem das technische Framework von IHE bereits verwendet, schildert der Implementierungsleitfaden ihm die relevanten Einschränkungen des IHE-Frameworks, die für die ePA der Telematikinfrastruktur von Relevanz sind. Die IHE-Konformität dieser Schnittstellen ermöglicht ihm die Anbindung weiterer Anwendungen.

Mit der ePA für alle werden viele Schnittstellen als REST-Schnittstellen angeboten. Der Implementierungsleitfaden beschreibt die Umsetzung dieser Schnittstellen und der genutzten FHIR-Ressourcen.

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) fest­gelegt 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 fungiert als Sekundärdokumentation von Daten der Versicherten. Die Primärdokumentation der Versichertendaten im Primärsystem wird 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:

• https://gematik.github.io/universal/index.html

• https://gematik.github.io/universal/specifications.html

Der ePA liegen mehrere Dokumente zugrunde, die verschiedene Aspekte beschreiben:

• Das Fachkonzept [gemKPT_FK_ePAfueralle_V1.0.0_RC2] 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.:

• Für Primärsystemhersteller werden die Anforderungen an die Umsetzung der ePA in den jeweiligen Clients zusammengefasst unter:

• https://gemspec.gematik.de/docs/gemSST/  

Für die Softwareentwicklung kann auf das Repository der gematik zugegriffen werden:

• https://github.com/gematik/epa-deployment

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_24854] folgende MIME-Type-Formate und Dateiendungen:

• application/pdf (nur PDF/A-1 und 2) (pdf)
• image/jpeg (jpeg oder jpg)
• image/png (png)
• image/tiff (tiff)
• 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, falls sie Dokumente im PDF-Format einstellen wollen, diese gemäß A_24967-01 zunächst in ein PDF/A-Format konvertieren.

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.

2 Systemüberblick

2.1 Einführung