These codes are excerpted from ISO Standard, TS 21089-2017 - Health Informatics - Trusted End-to-End Information Flows, Copyright by ISO International. Copies of this standard are available through the ISO Web Site at www.iso.org.
This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed
or info@snomed.org
.
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 ( src
)
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
The codes SHALL be taken from The codes SHOULD be taken from
eHDSI Language http://hl7.org/fhir/ValueSet/languages|4.0.1
( required
to http://terminology.ehdsi.eu/ValueSet/eHDSILanguage
)
Tato kapitola specifikuje česká národní rozšíření pro doplněk Add RESTful ATNA (Query and Feed), publikovaný v rámci profilu IHE ITI Trial Implementation
.
This section specifies Czech national extensions to the Add RESTful ATNA (Query and Feed) supplement, which is published
as an IHE ITI Trial Implementation profile.
Tato implementační specifikace se zaměřuje na národní implementaci profilu MHD (Mobile access to Health Documents) a Restful ATNA v prostředí akreditovaných afinitních domén (AAfD) a centrálních služeb elektronického zdravotnictví (EZ) vycházející z národního Standard Akreditovaných afinitních domén
This implementation specification focuses on the national implementation of the MHD (Mobile access to Health Documents) profile and Restful ATNA within the environment of Accredited Affinity Domains (AAfD) and the central eHealth services (EZ), based on the national Standard of Accredited Affinity Domains
.
Tato kapitola popisuje české národní rozšíření (pro akreditované afinitní domény – AAfD) pro transakci „Send Audit Resource Request Message – RESTful interaction ITI-20
“, definovanou v profilu RESTful ATNA (doplňek „Add RESTful ATNA (Query and Feed)“ v režimu IHE Trial Implementation). Úložiště auditních záznamů (Audit Record Repository) MUSÍ podporovat volbu ATX: FHIR Feed Option.
Transakce MUSÍ být zabezpečena protokolem TLS 1.3 (minimálně TLS 1.2 se silnými šifrovacími sadami) se vzájemnou autentizací uzlů (mTLS) dle transakce ATNA Authenticate Node [ITI-19]
. Klient i server se prokazují certifikátem X.509 vydaným certifikační autoritou MZČR.
Odesílá-li auditní událost IS PZS do úložiště auditních záznamů AAfD, MUSÍ současně předat přístupový token IUA získaný transakcí Get Access Token [ITI-71]
v hlavičce Authorization: Bearer
dle transakce Incorporate Access Token [ITI-72]
. Úložiště auditních záznamů (IUA Resource Server) token validuje stejně jako u transakcí MHD (viz Bezpečnostní hlediska ITI-65
).
Odesílá-li auditní událost IS PZS do úložiště auditních záznamů AAfD, MUSÍ současně předat přístupový token IUA získaný transakcí Get Access Token [ITI-71]
v hlavičce Authorization: Bearer
dle transakce Incorporate Access Token [ITI-72]
. Úložiště auditních záznamů (IUA Resource Server) token validuje stejně jako u transakcí MHD (viz Bezpečnostní hlediska ITI-65
).
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.
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
).
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
).
Transakce MUSÍ být zabezpečena protokolem TLS 1.3 (minimálně TLS 1.2 se silnými šifrovacími sadami) se vzájemnou autentizací uzlů (mTLS) dle transakce ATNA Authenticate Node [ITI-19]
. Klient i server se prokazují certifikátem X.509 vydaným certifikační autoritou MZČR a každá strana ověřuje platnost certifikátu protistrany. mTLS se používá pro veškerou komunikaci: mezi IS PZS a AAfD, mezi AAfD navzájem i mezi AAfD a centrálními službami elektronického zdravotnictví.
IS PZS získá metadata centrálního autorizačního serveru elektronického zdravotnictví transakcí Get Authorization Server Metadata [ITI-103]
a přístupový token transakcí Get Access Token [ITI-71]
. Vůči autorizačnímu serveru se prokazuje JWT assertion podepsanou privátním klíčem svého systémového certifikátu. Token obsahuje identifikaci PZS. Token se obnovuje před uplynutím jeho platnosti.
IS PZS získá metadata centrálního autorizačního serveru elektronického zdravotnictví transakcí Get Authorization Server Metadata [ITI-103]
a přístupový token transakcí Get Access Token [ITI-71]
. Vůči autorizačnímu serveru se prokazuje JWT assertion podepsanou privátním klíčem svého systémového certifikátu. Token obsahuje identifikaci PZS. Token se obnovuje před uplynutím jeho platnosti.
Předává-li domovská AAfD požadavek do jiné AAfD, získá pro cílovou AAfD nový přístupový token mechanismem OAuth 2.0 Token Exchange dle RFC 8693
: subject_token
je přístupový token PZS, actor_token
je systémový token volající AAfD. Cílová AAfD ověří v Katalogu služeb, že volající AAfD je akreditovaná, a vydá token, který obsahuje identitu PZS ( sub
) a identitu zprostředkující AAfD ( act
). Přímé předávání tokenu PZS do jiné AAfD bez validace není dovoleno.
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), and each side validates the certificate of its peer. mTLS is used for all communication: between the healthcare provider's system (IS PZS) and the AAfD, between AAfDs, and between an AAfD and the central eHealth services.
The IS PZS retrieves the metadata of the central eHealth authorization server with Get Authorization Server Metadata [ITI-103]
and an access token with Get Access Token [ITI-71]
. It authenticates to the authorization server with a JWT assertion signed with the private key of its system certificate. The token contains the identification of the healthcare provider (PZS). The token is renewed before it expires.
The IS PZS retrieves the metadata of the central eHealth authorization server with Get Authorization Server Metadata [ITI-103]
and an access token with Get Access Token [ITI-71]
. It authenticates to the authorization server with a JWT assertion signed with the private key of its system certificate. The token contains the identification of the healthcare provider (PZS). The token is renewed before it expires.
When the home AAfD forwards a request to another AAfD, it obtains a new access token for the target AAfD using OAuth 2.0 Token Exchange as defined in RFC 8693
: the subject_token
is the access token of the healthcare provider and the actor_token
is the system token of the calling AAfD. The target AAfD verifies in the eHealth Service Catalogue that the calling AAfD is accredited and issues a token containing the identity of the healthcare provider ( sub
) and of the intermediary AAfD ( act
). Forwarding the healthcare provider's token to another AAfD without validation is not allowed.
Odpovídající dokument může vrátit jiné kódy stavu HTTP. Pokyny pro řešení odmítnutí přístupu souvisejícího s použitím 200, 403 a 404 naleznete v ITI TF-2x: Příloha Z.7
.
Odpovídající dokumenty implementující tuto transakci musí poskytnout zdroj CapabilityStatement, jak je popsáno v ITI TF-2x: Příloha Z.3
, který označuje, že transakce byla implementována.
The Document Responder may return other HTTP Status Codes. Guidance on handling Access Denied related to use of 200, 403 and 404 can be found in ITI TF-2x: Appendix Z.7
.
Document Responders implementing this transaction shall provide a CapabilityStatement Resource as described in ITI TF-2x: Appendix Z.3
indicating the transaction has been implemented.
Tato implementační specifikace se zaměřuje na národní implementaci profilu MHD (Mobile access to Health Documents) v prostředí akreditovaných afinitních domén (AAfD) a centrálních služeb elektronického zdravotnictví (EZ) vycházející z národního Standard Akreditovaných afinitních domén
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
.
(
required
)
