HL7 Czech Health information exchange Implementation Guide
0.0.1 - ci-build
HL7 Czech Health information exchange Implementation Guide
0.0.1 - ci-build
HL7 Czech Health information exchange Implementation Guide, published by HL7 Czech Republic. This guide is not an authorized publication; it is the continuous build for version 0.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7-cz/HIE/ and changes regularly. See the Directory of published versions
This implementation specification focuses on the national implementation of the MHD (Mobile access to Health Documents) profile within the environment of Accredited Affinity Domains (AAfD) and the central eHealth services (EZ), based on the national Standard of Accredited Affinity Domains.
The following diagram illustrates the core architecture of the solution and the interactions between systems:
Figure 1: Diagram of the core architecture
Health Document Publishing System
The provider’s primary system that publishes documents and metadata via MHD and related interfaces.
Central eHealth Services
Provide the Patient Identity Registry (KRP), Authorization Registry, code systems and terminology, time-stamping, and audit services. They also ensure query routing and federation across AAfDs using the Home Community ID (HCID).
Publishing and Consuming AAfD
Domain components that support document submission and search, identity and authorization verification, notifications, and auditing.
Health Document Consuming System
The end-user application (e.g., clinical system or portal) that, once authorized, can search for and retrieve documents, and may also receive notifications of newly published records.
The diagram highlights the supported IHE transactions (ITI-65, ITI-66, ITI-67, ITI-68, DSUBm/ITI-112, RESTful ATNA/ITI-20) as well as the national eHealth interfaces (e.g., Authorization Registry, Time Authority, code systems). This architecture constitutes the foundation for interoperable sharing of healthcare documentation in the Czech Republic.
The national MHD specification for the Czech Republic requires support for the transactions ITI-65, ITI-66, ITI-67, and ITI-68 to enable the sharing of healthcare documents within Accredited Affinity Domains (AAfD). In the Czech context, ITI-66 (Find Document Lists) is mandatory for cross-domain searching using the Home Community ID (HCID).
A healthcare provider in AAfD-B issues a query (ITI-66/67) for a patient’s documents. The home AAfD uses the HCID to forward the request to neighboring AAfDs (including AAfD-A) and aggregates the returned results. From the retrieved metadata, the provider selects a specific record, and an ITI-68 request is then directed to the repository in AAfD-A, from which the document is securely retrieved. All steps are secured with mTLS and IUA access tokens and audited via RESTful ATNA.
When a new document is published in an AAfD, the system uses the DSUBm profile (ITI-112) to send a notification to the registered healthcare provider who previously subscribed to this event. The notification contains basic metadata (e.g., patient identifier RID, document type, reference to the DocumentReference) so that the provider knows a new record is available. The provider can then initiate a search and retrieval of the document using standard MHD transactions (ITI-66 through ITI-68).
If a healthcare professional needs to correct or invalidate a document, the primary system issues a request for change. In the AAfD environment, this is typically handled by publishing a new version of the document and invalidating the original record. In contrast, the Temporary Repository provides dedicated services for Update/Invalidate (PUT) operations. This ensures that users always work with valid and up-to-date metadata and content.
| Actor | Role | Main Transactions |
|---|---|---|
| Document Source | Publishes documents and metadata into the AAfD | ITI-65 Provide Document Bundle |
| Document Consumer | Searches for and retrieves documents | ITI-66 Find, ITI-67 Find References, ITI-68 Retrieve |
| Document Responder | Responds to search queries and returns metadata | ITI-66, ITI-67 |
| Document Recipient | Receives published documents into the repository | ITI-65 |
| Notification Recipient | Receives notifications of newly published documents | DSUBm / ITI-112 |
| Actor | Required grouping | Note |
|---|---|---|
| Document Source | IUA Authorization Client, ATNA Secure Node / Secure Application, ATNA Audit Creator | Publishing documents requires mTLS, an access token and audit logging |
| Document Consumer | IUA Authorization Client, ATNA Secure Node / Secure Application, ATNA Audit Creator | Searching and retrieving documents requires mTLS, an access token and audit logging |
| Document Responder (Registry) | IUA Resource Server, ATNA Secure Node, ATNA Audit Creator | Query responses require token validation and audit logging. Access tokens are issued by the central eHealth authorization server; an AAfD issues tokens only in token exchange for communication between AAfDs (RFC 8693). |
| Document Recipient (Repository) | Document Registry, IUA Resource Server, ATNA Secure Node, ATNA Audit Creator | Responsible for storing documents and maintaining metadata in the AAfD, token validation and audit logging |
| Notification Recipient | IUA Resource Server, ATNA Secure Node / Secure Application, ATNA Audit Creator | Receives notifications about newly published documents |
All AAfD actors must also interoperate with central eHealth services: the Core Patient Registry (RID patient identifier), Authorization Registry, Terminology Server, and Time Authority.
The home Accredited Affinity Domain (AAfD) receives an ITI-66 query containing the unique patient identifier (RID). Using the HCID index, it identifies relevant partner AAfDs and forwards the query to them. The home AAfD then aggregates the returned DocumentReference records and provides the user with a consolidated result set. When a specific record is selected, an ITI-68 Retrieve Document request is directed to the repository of the respective AAfD where the document is stored.
All communication uses TLS 1.3 (at least TLS 1.2 with strong cipher suites) with mutual node authentication (mTLS) as defined in ATNA [ITI-19], with certificates issued by the certification authority of the Czech Ministry of Health. In addition, every request carries an IUA access token (OAuth 2.0 / JWT) issued by the central eHealth authorization server ([ITI-71], [ITI-72]); between AAfDs the token is obtained by RFC 8693 token exchange. Each transaction is logged using RESTful ATNA (ITI-20), including the node identities and the access token details. See the security sections of the individual transactions (e.g. ITI-65) and ITI-20. Patient identity and healthcare professional permissions are validated against the Core Patient Registry (KRPZS/KRP) and the Authorization and Mandates Registry (RO).
Values for classification, document types, and formats are derived from the national Terminology Server for eHealth. Patient identity within the transactions is consistently represented by the RID from the Core Patient Registry (KRP).