MEMMDigital Health Platformby ITL Software GmbH
Home / Technical Knowledge / ePA record access
ePA · FdV · Record services

ePA record access: session, device binding, permissions and document services

ePA access links a protected VAU channel and authenticated userSession to a HealthRecordContext for a specific record. Device confirmation, entitlement, objections and document visibility have separate effects. Removing a device does not terminate an already active session; logoutFdV is a separate operation. XDS, MHD, Basic and Medication retain their own service contracts. The reviewed product and provider documents define responsibilities; HCSA illustrates selected journeys with synthetic local data.

Topics:ePAVAUHealthRecordContextDevice bindingMHDFHIR
ITL Software GmbHTechnical classificationReviewed: 17 Oct 2026
The key relationship

Distinguish session and record access

  1. FdV · VAU · userSession

    Protected channel and authenticated session

    check for the specific record
  2. HealthRecordContext

    Record-specific entitlement, objections and visibility

    under each service contract
  3. Documents and FHIR services

    XDS / MHD · Basic · Medication

Selected access boundaries. Device confirmation, session termination and business authorization have separate rules; this is not a universal ZETA access path.

ePA frontend, record system and provider

The frontend product profile 3.1.3-3, document 1.0.0, ties the document and access architecture considered here to gemSpec_ePA_FdV 2.8.0, record system 1.8.2 and IDP Frontend 2.0.0. It includes Basic IG 1.3.2, MHD IG 1.1.3 and Medication IG 1.3.5. The frontend serves the insured user; the record system holds the record and enforces access on the server. Record-system product requirements and provider requirements have their own PTV/ATV profiles 3.1.3-3. A mobile UI concept alone does not satisfy these three evidence scopes. The ePA-Basic and ePA-XDS-Document interfaces are pinned to ePA-3.1.3 and its resolved immutable commits.

VAU channel, userSession and a specific record

The frontend establishes a VAU channel to the record system and checks its VAU certificate. sendAuthorizationRequestFdV initiates authentication through the health identity, sectoral IDP and authenticator; sendAuthCodeFdV passes the received authorization code to the record system. The authenticated userSession is distinct from the HealthRecordContext of a specific record. A record request identifies the record through x-insurantid and requires the corresponding entitlement and further access checks. This supports access by owners and authorized representatives to different records. A generic ZETA allow result or TI-M Client ePA login does not replace this ePA frontend contract.

Ending a session and removing a device

logoutFdV ends the userSession, deletes its temporary session data and closes its HealthRecordContexts. Further access requires a new login and a newly negotiated VAU channel. The frontend ends the session at most 20 minutes after the last user activity; the record system also enforces an inactivity rule. By contrast, deleteDevice removes a device registration. The device API explicitly states that an already active userSession remains unaffected. A product must therefore treat logout and device management as different actions. The local HCSA demo holds no real ePA session and performs neither operation.

Device confirmation before record access

At the home record system, the frontend proves a registered and confirmed device with x-device-identifier and x-device-token. At another record system, a device attestation issued by the home system provides this proof. Without confirmed registration, the authenticated session remains restricted to device management. registerDevice and confirmPendingDevice cover registration and confirmation; getDeviceAttestation requires a confirmed device. The special x-authorize-representative mode supports representative enrolment and restricts access to entitlement management. It does not open a general document session. Health-identity login, device confirmation and record entitlement therefore each serve a distinct purpose.

Entitlement, objection and visibility

Entitlement Management governs an actor’s access entitlement to a specific record. The owner has a static entitlement; a representative requires an explicit entitlement. setEntitlement processes a signed entitlement statement, while deleteEntitlement revokes a revocable entitlement. Consent Decision Management instead records objections to defined functions: permit means no objection, while deny means an objection with function-specific effects. A general objection to the ePA itself lies outside this service. Constraint Management hides eligible documents, folders or categories through GeneralDenyPolicies; emp and technical cannot be hidden through this mechanism. Server-side LegalPolicy and role checks apply in addition. Favorites in the HCSA demo are local bookmarks and change none of these permissions.

Finding documents: XDS, MHD and Basic

XDS uses SOAP/WSDL, including DocumentRegistry_RegistryStoredQuery for metadata searches and DocumentRepository_RetrieveDocumentSet for retrieval. The frontend’s additional MHD consumer uses DocumentReference search and read: Find Document References (ITI-67) combines metadata with full-text search through _content. Every MHD search supplies at least patient.identifier and status; its path is /epa/mhd/api/v1/fhir/DocumentReference. Retrieve Document (ITI-68) retrieves content through DocumentReference.content.attachment.url. A missing document and a document hidden from the requester both return 404 on retrieval. Basic IG 1.3.2 describes Patient and AuditEvent among other shared requirements; Medication IG 1.3.5 describes eML/eMP. These are separate contracts. The HCSA filter searches synthetic document names and dates locally and does not implement MHD full-text search.

TI Common: product pin and package dependency

FdV PTV 3.1.3-3 names TI Common 1.3.0. The inspected de.gematik.epa 1.3.2 and de.gematik.epa.mhd 1.1.3 packages instead declare de.gematik.ti 1.3.1 as a dependency. The two Common versions are therefore documented separately. One concrete difference is in the TI Organization profile: 1.3.1 sets mustSupport=true on Organization.extension; 1.3.0 lacks this marking on that element. This matters when interpreting profile requirements and designing corresponding tests, but by itself does not prove data-exchange incompatibility. The reviewed material contains no official resolution of the version difference. It supports neither automatic substitution of the product pin nor a blanket conformance claim.

Versioned primary sources

What this page explicitly does not claim: This is a source-based explanation of selected ePA duties, not a test result for a production frontend or record system. The PTV Common 1.3.0 reference and package dependency 1.3.1 remain separately recorded; the reviewed sources contain no official resolution.
Continue reading

Related architecture topics

PTV · ATV · DraftNormative document matrixVersioned product and provider documents from TI-Flow_26_3, TI-Messenger_26_2 and ePA 3.1.3-3, alongside clearly identified App/DiPag drafts.Read technical brief →Mobile Healthcare · DiPagApp & DiPag draftsDraft_App_26_1 and Draft_DiPag_26_1 as provisional development references, separate from the synthetic HCSA user-interface concept.Read technical brief →Access & PolicyIdentity, attributes & policyA control model that keeps identity evidence, attributes, authorization policy and the final execution decision distinct.Read technical brief →Healthcare IntegrationFHIR® & structured dataHow FHIR®-related structured data, profile versions and validation boundaries are classified without making a general FHIR®, ePA or TI conformance statement.Read technical brief →