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 section describes the Czech national extension (for Accredited Affinity Domains – AAfD) of the Send Audit Resource Request Message – RESTful interaction [ITI-20] transaction defined in the RESTful ATNA profile which is currently prepared as IHE Trial Implementation with the working title ”Add RESTful ATNA (Query and Feed)”. The Audit Record Repository SHALL support the ATX: FHIR Feed Option.
Actor: Any actor or any other application that is grouped with the Secure Node or Secure Application (Audit Creator).
Role: Create an audit record and transmit this record to the Audit Record Repository.
Actor: Audit Record Repository
Role: Receive an audit record from the Audit Record Creator and store this for audit purposes.
The “Send Audit Resource Request Message – FHIR Feed Interaction” is used for auditing the FHIR Audit Event Resource using the RESTful protocol.
This message is sent when an actor that is grouped with Secure Node or Secure Application or an Audit Record Forwarder needs to post a single or multiple AuditEvent Resource to the Audit Record Repository.
Audit events of the MHD transactions SHALL conform to these profiles:
| Transaction | Actor | Profile |
|---|---|---|
| Provide Document Bundle [ITI-65] | Document Source | CZ Audit Event for [ITI-65] Document Source |
| Provide Document Bundle [ITI-65] | Document Recipient | CZ Audit Event for [ITI-65] Document Recipient |
| Find Document Lists [ITI-66] | Document Consumer | CZ Audit Event for [ITI-66] Document List Consumer |
| Find Document Lists [ITI-66] | Document Responder | CZ Audit Event for [ITI-66] Document List |
| Find Document References [ITI-67] | Document Consumer | CZ Audit Event for [ITI-67] Document Consumer |
| Find Document References [ITI-67] | Document Responder | CZ Audit Event for [ITI-67] Document Responder |
| Retrieve Document [ITI-68] | Document Consumer | CZ Audit Event for [ITI-68] Document Consumer |
| Retrieve Document [ITI-68] | Document Responder | CZ Audit Event for [ITI-68] Document Responder |
The content of the audit events that an AAfD makes available to the Activity Journal is described in Volume 3.
Every audit event SHALL record who authenticated with a certificate (mTLS) and with an access token (IUA):
| Data | Source | AuditEvent element |
|---|---|---|
| Calling system (node) | mTLS client certificate [ITI-19] | Agent of the calling system (Document Source / Document Consumer): who.identifier – identity from the certificate (for an AAfD its HCID), network.address – IP address or hostname |
| Called system (node) | mTLS server certificate [ITI-19] | Agent of the called system (Document Recipient / Document Responder): who.identifier, network.address |
| Healthcare provider (PZS) | Healthcare provider identification in the IUA access token | agent[pzs].who.identifier – company ID (IČO, https://ncez.mzcr.cz/fhir/sid/ico) |
| Access token identifier | jti claim of the IUA token |
agent[pzs].policy as urn:ietf:params:oauth:jti:<jti> (as in IHE BALP) |
| Healthcare professional | Identification passed by the provider's system (KRZP) | agent[mainUser].altId, agent[mainUser].name |
| Purpose of use | Request context | agent[mainUser].purposeOfUse |
| Intermediary AAfD (communication between AAfDs) | act claim of the token obtained by RFC 8693 token exchange, and the mTLS certificate |
Agent of the calling system: who.identifier – HCID of the calling AAfD |
| Patient | RID or DRID | entity[patient].what.identifier |
| Transaction correlation | traceparent header |
entity[traceparent] |
The access token or any part of it SHALL NOT be stored in the audit event; only its identifier (jti) is recorded.
When the server rejects a connection or a request, it SHALL record an audit event with an outcome other than 0 (success):
type = DCM#110113 "Security Alert", subtype = DCM#110126 "Node Authentication",type = DCM#110114 "User Authentication", subtype = DCM#110122 "Login".These events are used to evaluate security events (e.g. repeated access with invalid or compromised tokens).
Same message semantics and expected actions apply as described in the ITI-20 transaction.
The Audit Record Repository of the AAfD stores the audit event in its audit log and forwards it to the central eHealth ATNA component (the AAfD acting as Audit Record Forwarder). Participants of the AAfD (healthcare provider systems) may send their audit events to the Audit Record Repository of their AAfD with this transaction.
The CapabilityStatement resource for the Audit Creator is ATNA Audit Creator.
The CapabilityStatement resource for the Audit Record Repository is ATNA Audit Record Repository.
The transaction SHALL be secured by TLS 1.3 (at least TLS 1.2 with strong cipher suites) with mutual node authentication (mTLS) as defined in the ATNA Authenticate Node [ITI-19] transaction. Both client and server authenticate with an X.509 certificate issued by the certification authority of the Czech Ministry of Health (MZČR).
When a healthcare provider system sends an audit event to the Audit Record Repository of the AAfD, it SHALL also convey the IUA access token obtained with Get Access Token [ITI-71] in the Authorization: Bearer header as defined in Incorporate Access Token [ITI-72]. The Audit Record Repository (IUA Resource Server) validates the token as for the MHD transactions (see ITI-65 Security Considerations).
Audit events are forwarded from the AAfD to the central ATNA component over mTLS with the system access token of the AAfD.