Implementation Guide
ePA Basisfunktionalitäten
Version 1.3.1 - release

## Basisdienst Patient Service

Die Basisfunktionalität Patient Service dient dazu, demografische Daten des Versicherten – darunter Name, Vorname, Geburtsdatum und Anrede – klar und eindeutig in der ePA zu verankern. Dadurch wird es den Kostenträgern ermöglicht, diese grundlegenden Informationen direkt in das ePA-Aktenkonto einzupflegen. Zudem ermöglicht dies den Kostenträgern, Aktualisierungen bei Änderungen der demografischen Daten – beispielsweise eine Änderung des Nachnamens – zeitnah in einem Aktenkonto des ePA-Aktensystems bekannt zu machen.

Die technische Umsetzung dieser Basisfunktionalität erfolgt durch die Bereitstellung einer FHIR R4 Patient-Ressource per [FHIR Conditional update]. Die FHIR Patient-Ressource ermöglicht es, dass diese demografischen Daten in einem strukturierten Format bereitgestellt werden. Sämtliche FHIR-Instanzen sind somit direkt oder indirekt mit einer Patient-Ressource über einen KVNR-basierten Identifier verknüpft.

Ein wichtiger Aspekt der Basisfunktionalität Patient Service ist auch die interne Verwendung dieser demografischen Daten in den versorgungsspezifischen Services des ePA-Aktensystems, wie zum Beispiel dem ePA Medication Service. Bei Funktionen wie dem Abrufen der elektronischen Medikationsliste (eML) wird die Patient-Ressource intern genutzt und dem Suchergebnis hinzugefügt.

Das folgende UML-Sequenzdiagramm verdeutlicht das Einstellen einer Patient-Ressourceninstanz sowie Nachnutzung in einem FHIR Data Service (hier: ePA Medication Service).

Abbildung: Einstellen einer Patient-Ressourceninstanz sowie Nachnutzung in einem FHIR Data Service

### Schnittstellenimplementierung

Der Patient Service MUSS sämtliche FHIR-Schnittstellen unter den folgenden Pfaden verfügbar machen:

- `[base]/epa/patient/api/v1/fhir/`

wobei `[base]` einem gültigen Pfadnamen eines VAU-Kanals nach folgendem Schema entsprechen muss: `http://epa4all` Der Patient Service MUSS die Funktion `GET [base]/epa/patient/api/v1/fhir/metadata` implementieren. Diese Funktionalität stellt sicher, dass bei einem Aufruf von `/metadata` das FHIR CapabilityStatement mit dem Namen EPAPatientServer des Servers zurückgegeben wird. Dieses Capability Statement bietet eine detaillierte Beschreibung der Fähigkeiten des ePA Patient Service und ist entscheidend für das Verständnis der unterstützten FHIR-Funktionalitäten. Das Clientsystem des Kostenträgers MUSS die Nutzung der die in diesem Implementation Guide definierte Schnittstelle "Patient Service: Versicherteninformationen hinzufügen/aktualisieren" implementieren. Das ePA-Frontend des Versicherten KANN die Nutzung der die in diesem Implementation Guide definierte Schnittstelle "Patient Service: Query API" implementieren.