From dede6b14498ef4a3c824635cdefe4b579cebe046 Mon Sep 17 00:00:00 2001 From: <> Date: Mon, 27 Jan 2025 09:59:05 +0000 Subject: [PATCH] Deployed 3a4b2a5 with MkDocs version: 1.6.1 --- .nojekyll | 0 404.html | 1 + Atna/index.html | 37 + AuthenticateUser/index.html | 339 + GetXAssertion/index.html | 128 + IdPRenew/index.html | 183 + ImmunizationAdministrationDocument/index.html | 383 + ImmunizationAdministrationSections/index.html | 342 + MedicationCardDocument/index.html | 906 +++ PDQ/index.html | 254 + PIXFeed/index.html | 229 + PIXQuery/index.html | 224 + ProvideAndRegister/index.html | 272 + ProvideXAssertion/index.html | 32 + Questionnaire/index.html | 852 +++ RegistryStoredQuery/index.html | 449 ++ RetrieveDocumentSet/index.html | 219 + SSOLogout/index.html | 143 + assets/images/favicon.png | Bin 0 -> 1870 bytes assets/javascripts/bundle.cd18aaf1.min.js | 29 + assets/javascripts/bundle.cd18aaf1.min.js.map | 7 + assets/javascripts/lunr/min/lunr.ar.min.js | 1 + assets/javascripts/lunr/min/lunr.da.min.js | 18 + assets/javascripts/lunr/min/lunr.de.min.js | 18 + assets/javascripts/lunr/min/lunr.du.min.js | 18 + assets/javascripts/lunr/min/lunr.el.min.js | 1 + assets/javascripts/lunr/min/lunr.es.min.js | 18 + assets/javascripts/lunr/min/lunr.fi.min.js | 18 + assets/javascripts/lunr/min/lunr.fr.min.js | 18 + assets/javascripts/lunr/min/lunr.he.min.js | 1 + assets/javascripts/lunr/min/lunr.hi.min.js | 1 + assets/javascripts/lunr/min/lunr.hu.min.js | 18 + assets/javascripts/lunr/min/lunr.hy.min.js | 1 + assets/javascripts/lunr/min/lunr.it.min.js | 18 + assets/javascripts/lunr/min/lunr.ja.min.js | 1 + assets/javascripts/lunr/min/lunr.jp.min.js | 1 + assets/javascripts/lunr/min/lunr.kn.min.js | 1 + assets/javascripts/lunr/min/lunr.ko.min.js | 1 + assets/javascripts/lunr/min/lunr.multi.min.js | 1 + assets/javascripts/lunr/min/lunr.nl.min.js | 18 + assets/javascripts/lunr/min/lunr.no.min.js | 18 + assets/javascripts/lunr/min/lunr.pt.min.js | 18 + assets/javascripts/lunr/min/lunr.ro.min.js | 18 + assets/javascripts/lunr/min/lunr.ru.min.js | 18 + assets/javascripts/lunr/min/lunr.sa.min.js | 1 + .../lunr/min/lunr.stemmer.support.min.js | 1 + assets/javascripts/lunr/min/lunr.sv.min.js | 18 + assets/javascripts/lunr/min/lunr.ta.min.js | 1 + assets/javascripts/lunr/min/lunr.te.min.js | 1 + assets/javascripts/lunr/min/lunr.th.min.js | 1 + assets/javascripts/lunr/min/lunr.tr.min.js | 18 + assets/javascripts/lunr/min/lunr.vi.min.js | 1 + assets/javascripts/lunr/min/lunr.zh.min.js | 1 + assets/javascripts/lunr/tinyseg.js | 206 + assets/javascripts/lunr/wordcut.js | 6708 +++++++++++++++++ .../workers/search.f886a092.min.js | 42 + .../workers/search.f886a092.min.js.map | 7 + assets/stylesheets/main.fad675c6.min.css | 1 + assets/stylesheets/main.fad675c6.min.css.map | 1 + assets/stylesheets/palette.356b1318.min.css | 1 + .../stylesheets/palette.356b1318.min.css.map | 1 + css/timeago.css | 15 + gazelle/index.html | 1 + index.html | 1 + js/timeago.min.js | 2 + js/timeago_mkdocs_material.js | 33 + media/SAML-Artifact-flow.png | Bin 0 -> 40104 bytes media/SAML-Logout.png | Bin 0 -> 22522 bytes media/ehealthsuisse.css | 87 + media/favicon.png | Bin 0 -> 1434 bytes media/logo.png | Bin 0 -> 15784 bytes media/logo.svg | 5 + playground/index.html | 1 + search/search_index.json | 1 + sitemap.xml | 79 + sitemap.xml.gz | Bin 0 -> 393 bytes 76 files changed, 12508 insertions(+) create mode 100644 .nojekyll create mode 100644 404.html create mode 100644 Atna/index.html create mode 100644 AuthenticateUser/index.html create mode 100644 GetXAssertion/index.html create mode 100644 IdPRenew/index.html create mode 100644 ImmunizationAdministrationDocument/index.html create mode 100644 ImmunizationAdministrationSections/index.html create mode 100644 MedicationCardDocument/index.html create mode 100644 PDQ/index.html create mode 100644 PIXFeed/index.html create mode 100644 PIXQuery/index.html create mode 100644 ProvideAndRegister/index.html create mode 100644 ProvideXAssertion/index.html create mode 100644 Questionnaire/index.html create mode 100644 RegistryStoredQuery/index.html create mode 100644 RetrieveDocumentSet/index.html create mode 100644 SSOLogout/index.html create mode 100644 assets/images/favicon.png create mode 100644 assets/javascripts/bundle.cd18aaf1.min.js create mode 100644 assets/javascripts/bundle.cd18aaf1.min.js.map create mode 100644 assets/javascripts/lunr/min/lunr.ar.min.js create mode 100644 assets/javascripts/lunr/min/lunr.da.min.js create mode 100644 assets/javascripts/lunr/min/lunr.de.min.js create mode 100644 assets/javascripts/lunr/min/lunr.du.min.js create mode 100644 assets/javascripts/lunr/min/lunr.el.min.js create mode 100644 assets/javascripts/lunr/min/lunr.es.min.js create mode 100644 assets/javascripts/lunr/min/lunr.fi.min.js create mode 100644 assets/javascripts/lunr/min/lunr.fr.min.js create mode 100644 assets/javascripts/lunr/min/lunr.he.min.js create mode 100644 assets/javascripts/lunr/min/lunr.hi.min.js create mode 100644 assets/javascripts/lunr/min/lunr.hu.min.js create mode 100644 assets/javascripts/lunr/min/lunr.hy.min.js create mode 100644 assets/javascripts/lunr/min/lunr.it.min.js create mode 100644 assets/javascripts/lunr/min/lunr.ja.min.js create mode 100644 assets/javascripts/lunr/min/lunr.jp.min.js create mode 100644 assets/javascripts/lunr/min/lunr.kn.min.js create mode 100644 assets/javascripts/lunr/min/lunr.ko.min.js create mode 100644 assets/javascripts/lunr/min/lunr.multi.min.js create mode 100644 assets/javascripts/lunr/min/lunr.nl.min.js create mode 100644 assets/javascripts/lunr/min/lunr.no.min.js create mode 100644 assets/javascripts/lunr/min/lunr.pt.min.js create mode 100644 assets/javascripts/lunr/min/lunr.ro.min.js create mode 100644 assets/javascripts/lunr/min/lunr.ru.min.js create mode 100644 assets/javascripts/lunr/min/lunr.sa.min.js create mode 100644 assets/javascripts/lunr/min/lunr.stemmer.support.min.js create mode 100644 assets/javascripts/lunr/min/lunr.sv.min.js create mode 100644 assets/javascripts/lunr/min/lunr.ta.min.js create mode 100644 assets/javascripts/lunr/min/lunr.te.min.js create mode 100644 assets/javascripts/lunr/min/lunr.th.min.js create mode 100644 assets/javascripts/lunr/min/lunr.tr.min.js create mode 100644 assets/javascripts/lunr/min/lunr.vi.min.js create mode 100644 assets/javascripts/lunr/min/lunr.zh.min.js create mode 100644 assets/javascripts/lunr/tinyseg.js create mode 100644 assets/javascripts/lunr/wordcut.js create mode 100644 assets/javascripts/workers/search.f886a092.min.js create mode 100644 assets/javascripts/workers/search.f886a092.min.js.map create mode 100644 assets/stylesheets/main.fad675c6.min.css create mode 100644 assets/stylesheets/main.fad675c6.min.css.map create mode 100644 assets/stylesheets/palette.356b1318.min.css create mode 100644 assets/stylesheets/palette.356b1318.min.css.map create mode 100644 css/timeago.css create mode 100644 gazelle/index.html create mode 100644 index.html create mode 100644 js/timeago.min.js create mode 100644 js/timeago_mkdocs_material.js create mode 100644 media/SAML-Artifact-flow.png create mode 100644 media/SAML-Logout.png create mode 100644 media/ehealthsuisse.css create mode 100644 media/favicon.png create mode 100644 media/logo.png create mode 100644 media/logo.svg create mode 100644 playground/index.html create mode 100644 search/search_index.json create mode 100644 sitemap.xml create mode 100644 sitemap.xml.gz diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000..e69de29 diff --git a/404.html b/404.html new file mode 100644 index 0000000..b5cad30 --- /dev/null +++ b/404.html @@ -0,0 +1 @@ +
When executing most of the transactions with the EPR, there is a requirement to send an audit log to the community describing who did what and when, on the client's side. The community also creates such an audit log, and both can be compared if the need arises.
Since the audit logs may contain information about the transaction outcome, you have to wait for the community response before creating the audit log.
Warning
You have to do your best efforts to send the audit logs, even if the transaction has failed (network issue or error 500 for example).
The base specification of the <AuditMessage>
format is given in DICOM PS3.15. Additional requirements are described in:
An audit log is simply wrapped in a <AuditMessage>
element. No namespace is needed.
The first child is a EventIdentification element that describes the transaction:
<EventIdentification EventActionCode="★action_code" EventDateTime="★date_time" EventOutcomeIndicator="★outcome">
+ <EventID csd-code="★transaction_code" codeSystemName="DCM" originalText="★transaction_display"/>
+ <EventTypeCode csd-code="★type_code" codeSystemName="IHE Transactions" originalText="★type_display"/>
+ <PurposeOfUse csd-code="★puo_code" codeSystemName="2.16.756.5.30.1.127.3.10.5" originalText="★puo_display" />
+</EventIdentification>
+
action_code
, transaction_code
, transaction_display
,type_code
and type_display
depend on the transaction type and are defined in the IHE transaction profile, in the 'Security Considerations' section;date_time
is the date and time at which the transaction was made. It shall contain a timezone, and shall follow the xsd:dateTime format;outcome
describes whether the transaction was successful or not: 0
is a success, 4
is a minor failure, 8
is a serious failure and 12
is a major failure. The choice of the failure type is left to the implementers;puo_code
and puo_display
are the Purpose of Use code and display name, respectively. It is mandatory when the transaction is secured by XUA; otherwise, the whole <PurposeOfUse>
element shall be omitted.Then, two ActiveParticipants describe the source and destination participants.
The first ActiveParticipant describes the source participant, which often is the one that has sent the transaction (but not always). It has the following content:
<ActiveParticipant UserID="★user_id" AlternativeUserID="★alt_user_id" NetworkAccessPointID="★nap_id" NetworkAccessPointTypeCode="★nap_type" UserIsRequest="true">
+ <RoleIDCode csd-code="110153" codeSystemName="DCM" originalText="Source Role ID"/>
+</ActiveParticipant>
+
user_id
is required and can be filled as you want. It can be a process ID, a login name, or other identifiers;alt_user_id
is the process ID as used within the local operating system in the local system logs;nap_id
is the DNS name or IP address of the source;nap_type
is 1
for machine (DNS) name, 2
for IP address.Other attributes are optional.
The second ActiveParticipant describes the destination participant, which often is the one that has received the transaction (but not always). It has the following content:
<ActiveParticipant UserID="★user_id" NetworkAccessPointID="★nap_id" NetworkAccessPointTypeCode="★nap_type" UserIsRequest="false">
+ <RoleIDCode csd-code="110152" codeSystemName="DCM" originalText="Destination Role ID"/>
+</ActiveParticipant>
+
user_id
is the SOAP endpoint URI;nap_id
is the DNS name or IP address of the destination;nap_type
is 1
for machine (DNS) name, 2
for IP address.Other attributes are optional.
Warning
In some transactions such as ITI-43, the source and destination participants are reversed. Always check the IHE specifications for the correct order. The participant "server" is the one having the "SOAP endpoint URI", the participant "client" is the one having the "process ID".
Following that is the <AuditSourceIdentification>
element. It contains the following:
oid
is required by the Amendment 1 to Annex 5 (§1.5.2) and must be an OID of your OID hierarchy. Please ask your community if it has requirements about the use of this OID. The source
value is required by the standard, but its value choice is left to the implementers; it should contain an "Identifier of the source". You can copy the oid
value if you want. If the transaction is secured by XUA (like ITI-18, ITI-41, ITI-43), then additional ActiveParticipants shall be specified to describe the authenticated participant of the transaction.
The first additional ActiveParticipant is described in IHE ITI-40, §3.40.4.2. It is required for all roles. It shall contain:
<ActiveParticipant UserID="★user_id" UserName="★alias<★user@★issuer>" UserIsRequest="false" />
+
user_id
is required and can be filled as you want. It can be a process ID, a login name, or other identifiers;alias
(optional) is the SAML Assertion's Subject/NameID/@SPProvidedID
attribute;user
(required) is the SAML Assertion's Subject/NameID
content;issuer
(required) is the SAML Assertion's Issuer
content.The other attributes and subject role specification are optional.
The second additional ActiveParticipant is described in the Amendment 1 to Annex 5, §1.6.4.3.5.1. It is required for all roles. It shall contain:
<ActiveParticipant UserID="★user_id" UserName="★user_name" UserIsRequestor="false">
+ <RoleIDCode csd-code="★code" codeSystemName="2.16.756.5.30.1.127.3.10.6" originalText="★display"/>
+</ActiveParticipant>
+
user_id
(required) is the SAML Assertion's Subject/NameID
content;user_name
(required) is the SAML Assertion's AttributeStatement/Attribute[@Name="urn:oasis:names:tc:xspa:1.0:subject:subject-id"]/AttributeValue
content;code
(required) is the SAML Assertion's AttributeStatement/Attribute[@Name="urn:oasis:names:tc:xacml:2.0:subject:role"]/AttributeValue/Role/@code
attribute.Other attributes are optional.
The third additional ActiveParticipant is described in the Amendment 1 to Annex 5, §1.6.4.3.5.1. It is only required for assistants and technical users. It shall contain:
<ActiveParticipant UserID="★user_id" UserName="★user_name" UserIsRequest="false">
+ <RoleIDCode csd-code="★code" codeSystemName="2.16.756.5.30.1.127.3.10.6" originalText="★display" />
+</ActiveParticipant>
+
user_id
(required) is the SAML Assertion's Subject/SubjectConfirmation/NameID
content;user_name
(required) is the SAML Assertion's Subject/SubjectConfirmation/SubjectConfirmationData/AttributeStatement/Attribute[@Name="urn:oasis:names:tc:xspa:1.0:subject:subject-id"]/AttributeValue
content;code
(required) is either TCU
or ASS
.Some ParticipantObjectIdentification elements may be used to include additional details about the query content.
For ITI-18 transaction, the query content has to be included in the <ParticipantObjectIdentification>
element:
<ParticipantObjectIdentification ParticipantObjectID="★participant_object_id" ParticipantObjectTypeCode="2" ParticipantObjectTypeCodeRole="24">
+ <ParticipantObjectIDTypeCode csd-code="★transaction_code" codeSystemName="IHE Transactions" originalText="★transaction_display" />
+ <ParticipantObjectQuery>★query_b64</ParticipantObjectQuery>
+ <ParticipantObjectDetail type="QueryEncoding" value="★query_encoding_b64" />
+</ParticipantObjectIdentification>
+
participant_object_id
is the Stored Query ID for ITI-18, or optional for ITI-45 and ITI-47;transaction_code
and transaction_display
are the same as in EventIdentification/EventID
;query_b64
is the XML representation of a part of the query, base64-encoded:AdhocQueryRequest
;QueryByParameter
segment of the query;query_encoding_b64
is the query encoding, encoded in base64. Usually VVRGLTg=
(UTF-8).For ITI-18 transactions, an additional <ParticipantObjectIdentification>
is required inside, if the homeCommunityID is specified in the query:
<ParticipantObjectDetail type="urn:ihe:iti:xca:2010:homeCommunityId" value="★home_community_id_b64" />
+
home_community_id_b64
is the value of the homeCommunityId, base64-encoded. <ParticipantObjectIdentification ParticipantObjectID="★patient_id" ParticipantObjectTypeCode="1" ParticipantObjectTypeCodeRole="1">
+ <ParticipantObjectIDTypeCode csd-code="2" codeSystemName="RFC-3881" originalText="Patient Number" />
+</ParticipantObjectIdentification>
+
patient_id
is the patient identifier encoded in HL7 CX format (e.g. value^^^&1.2.3&ISO
). For ITI-41 requests, a <ParticipantObjectIdentification>
is required to describe the Submission Set:
<ParticipantObjectIdentification ParticipantObjectID="★submission_set_unique_id" ParticipantObjectTypeCode="2" ParticipantObjectTypeCodeRole="20">
+ <ParticipantObjectIDTypeCode csd-code="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" originalText="submission set classificationNode" codeSystemName="IHE XDS Metadata"/>
+</ParticipantObjectIdentification>
+
submission_set_unique_id
is the URN-encoded Submission Set unique ID. For ITI-43 transactions, a <ParticipantObjectIdentification>
is required to describe the document to be retrieved:
<ParticipantObjectIdentification ParticipantObjectID="★document_unique_id" ParticipantObjectTypeCode="2" ParticipantObjectTypeCodeRole="3" ParticipantObjectSensitivity="★confidentiality_code">
+ <ParticipantObjectIDTypeCode csd-code="9" codeSystemName="RFC-3881" originalText="Report Number"/>
+ <ParticipantObjectDetail type="Repository Unique Id" value="★repo_unique_id_b64"/>
+</ParticipantObjectIdentification>
+
document_unique_id
is the document unique ID;repo_unique_id_b64
is the repository unique ID;confidentiality_code
is the document confidentiality code, if known. The format is HL7v2 CE with the code system OID as the code (e.g.: 1051000195109^normal^2.16.840.1.113883.6.96
).If the home community ID is known, another ParticipantObjectDetail is required inside: <ParticipantObjectDetail type="ihe:homeCommunityID" value="★home_community_id_b64"/>
. The value must be base64-encoded.
ActiveParticipant | ParticipantObjectIdentification | |||||||
---|---|---|---|---|---|---|---|---|
Transaction | EventIdentification | Source | Destination | XUA | Query | Patient | Submission Set | Document |
ITI-18 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ |
ITI-41 | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ❌ |
ITI-43 | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | ✅ |
ITI-44 | ✅ | ✅ | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ |
ITI-45 | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ❌ | ❌ |
ITI-47 | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ❌ | ❌ |
ITI-57 | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ❌ |
The audit log shall be sent to the community as a syslog message either over TCP (with TLS). The relevant specifications are:
The choice of values in the Syslog headers is left to the implementers.
An example of a Syslog message sent over TCP is:
2027 <85>1 2024-06-25T13:47:57.600Z mag-cara-695f6f7f49-zsxxw IPF 1 IHE+RFC-3881 - <?xml version="1.0" encoding="UTF-8"?><AuditMessage><EventIdentification EventActionCode="E" EventDateTime="2024-06-25T13:47:57.598829760Z" EventOutcomeIndicator="12"><EventID csd-code="110112" codeSystemName="DCM" originalText="Query" /><EventTypeCode csd-code="ITI-67" codeSystemName="IHE Transactions" originalText="Mobile Document Reference Query" /></EventIdentification><ActiveParticipant UserID="/mag-cara/fhir/DocumentReference" UserIsRequestor="true" NetworkAccessPointID="147.87.210.77" NetworkAccessPointTypeCode="2"><RoleIDCode csd-code="110153" codeSystemName="DCM" originalText="Source Role ID" /></ActiveParticipant><ActiveParticipant UserID="https://test.ahdis.ch/mag-cara/fhir/DocumentReference" AlternativeUserID="1" UserIsRequestor="false" NetworkAccessPointID="10.28.2.28" NetworkAccessPointTypeCode="2"><RoleIDCode csd-code="110152" codeSystemName="DCM" originalText="Destination Role ID" /></ActiveParticipant><AuditSourceIdentification AuditEnterpriseSiteID="1.3.6.1.4.1.21367.2017.2.7.109" AuditSourceID="IPF"><AuditSourceTypeCode csd-code="9" codeSystemName="DCM" originalText="Other" /></AuditSourceIdentification><ParticipantObjectIdentification ParticipantObjectID="urn:oid:1.1.1.99.1|215503a0-11d2-4197-822a-053791ab5a8e" ParticipantObjectTypeCode="1" ParticipantObjectTypeCodeRole="1"><ParticipantObjectIDTypeCode csd-code="2" codeSystemName="RFC-3881" originalText="Patient Number" /></ParticipantObjectIdentification><ParticipantObjectIdentification ParticipantObjectID="MobileDocumentReferenceQuery" ParticipantObjectTypeCode="2" ParticipantObjectTypeCodeRole="24"><ParticipantObjectIDTypeCode csd-code="ITI-67" codeSystemName="IHE Transactions" originalText="Mobile Document Reference Query" /><ParticipantObjectQuery>c3RhdHVzPWN1cnJlbnQmcGF0aWVudC5pZGVudGlmaWVyPXVybjpvaWQ6MS4xLjEuOTkuMXwyMTU1MDNhMC0xMWQyLTQxOTctODIyYS0wNTM3OTFhYjVhOGU=</ParticipantObjectQuery></ParticipantObjectIdentification></AuditMessage>
+
Note
Notice the UTF-8 BOM at the beginning of the payload (just before <?xml
). It is required by the syslog protocol for UTF-8 messages. 2027 is the number of bytes in the following message (2025 characters + 2 extra bytes for the BOM).
Transaction to authenticate a user at a identity provider certified for the Swiss EPR. Primary systems shall use this transaction to retrieve a IdP assertion. The IdP assertion is required to retrieve the XUA Assertion to be used with EPR transactions.
Primary systems shall use this transaction to retrieve an IdP assertion authentication the user for the access to the Swiss EPR.
The requirements for the transaction are defined in Annex 8 of the ordinances of the Swiss EPR.
The EPR requires primary systems to implement authentication as described in the SAML 2.0 specification family, i.e.,
Primary systems do need implement all the bindings and profiles supported by the SAML 2.0 specification family.
In the Swiss EPR the following bindings are required:
In the Swiss EPR the following profiles are required:
The usage of the profiles and binding used to authenticate user for the Swiss EPR is described in the following sections.
The transaction to authenticate a user for the access to the Swiss EPR is a multi-step flow consisting of HTTP Post and SOAP Web Service calls, as displayed in the following figure:
Figure 1: Authentication Sequence Diagram
The sequence consists of the following steps, each using assigned transaction messages:
The transaction shall be performed by the primary system when the user aims to access the EPR. The primary system shall redirect the user agent (browser) to the IdP authentication endpoint with a AuthnRequest message as defined in Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0.
When the user is authenticated by the IdP, the IdP responds with a HTTP redirect to the registered endpoint of the primary system as specified in Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0.
The following snippet is taken from a sample request recorded during the EPR projectathon in September 2020. Some elements were ommitted to increase readability. The raw request file may be found here.
The AuthnRequest conveys the following information to be set by the primary system:
The following snippet is taken from a sample request recorded during the EPR projectathon in September 2020. It conveys two parameter to be used by the primary system:
https://epdtest.mycompany.local:8549/ACS?SAMLart=AAQAAOjXNPPr%2Fr7FO5WpiZ%2B2vAl5KMFibkRaAGwIkwXh%2Bo7DgsG2LMDE58c%3D&RelayState=idp%23468
+
The transaction uses front channel HTTP communication via the user agent (browser).
The transactions shall use TLS secured transports (HTTPS) to ensure data privacy and with server authentication.
The transaction shall be performed by the primary system to exchange the artifact to a SAML 2.0 IdP Assertion.
The primary system shall use the SOAP backchannel with an ArtifactResolve request message as defined in Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0.
The IdP server responds the SAML 2.0 IdP Assertion of the authenticated user.
The following snippet is taken from a sample request recorded during the EPR projectathon in September 2020. Some elements are omitted to increase readability. The raw request file may be found here.
The ArtifactResolve conveys the following information to be set by the primary system:
The following snippet is taken from a sample response recorded during the EPR projectathon in September 2020. Some elements are omitted to increase readability. The raw version may be found here.
The ArtifactResponse conveys the following information which shall be evaluated by the primary system:
The following snippet shows an example of a IdP Assertion conveyed with the response.
The primary system must keep the IdP Assertion in memory to use it to authenticate the Get X-User Assertion transaction.
The primary system is not required to analyze the IdP Assertion further, but may extract the following information from the assertion:
The primary system shall send the request messages to the IdP of the community using the http POST binding as defined in the W3C SOAP specification. It may look like:
The Artifact Resolve transaction shall be secured by using the SOAP backchannel with TLS and mutual authentication with client and server certificate validation. The certificates shall be exchanged during the client registration process.
Primary systems shall protocol the transaction in their logs to ensure traceability. No further requirements are defined in the ordinances of the Swiss EPR.
The transaction can be tested with the test suite of the EPR reference environment, test systems of the EPR communities or the EPR Playground.
Transaction to retrieve a SAML 2.0 assertion for authorization of transactions in the Swiss EPR. Primary systems shall use this transaction to retrieve a SAML 2 assertions to be used with EPR transactions, which require authorization.
Primary systems shall use this transaction to retrieve a SAML 2 assertions to be used with the Provide X-User Assertion with XDS.b transactions as defined in the IHE XUA profile with Swiss specific extensions defined in
Amendment 1 to Annex 5.
The primary system shall provide claims (e.g., user role, purpose of use) with the request as defined in Amendment 1 to Annex 5.
The community verifies the claims and responds with a XUA compliant SAML 2.0 Assertion defined in Amendment 1 to Annex 5.
Messages are encoded as described in the WS Trust standard, with restrictions defined in the IHE profile and the ordinances to the Swiss EPR.
The following snippet is taken from a sample request recorded during the EPR projectathon in September 2020. Some elements are omitted to increase readability. The raw request file may be found here.
The snippet shows a request performed by a healthcare professional performing a the normal access. For other roles and situations the claims are different. Other examples may be found at XUA examples.
The request message shall be a XML SOAP envelope with the query embedded in the Body element of the SOAP envelope. The SOAP Header element conveys the following information:
The SOAP Body element contains the RequestSecurityToken element with the following claims to be set by the primary system. It's child element read:
AppliesTo the URL of the community endpoint the XUA assertion shall be used for authorization, whose value is set in the Address child element.
resourceID conveying the EPR-SPID of the patient EPR to access in CX format (see see PIXFeed)
purposeOfUse conveying the purpose of use of the request, which must be taken from the EPR value set defined in Annex 3 of the ordinances of the Swiss electronic patient dossier.
role conveying the EPR role of the user, which must be taken from the EPR value set defined in Annex 3.
The following snippet is taken from a sample response recorded during the EPR projectathon in September 2020. Some elements were ommitted to increase readability. The raw file may be found here.
The response message is a XML SOAP envelope with the XUA Assertion embedded in the the Body element of the SOAP envelope (see example below, lines 21 to 23). Primary systems shall extract the XUA Assertion to use the im the security header of the XDS.b transactions, which require authorization. For primary systems, there is no need to extract information from the XUA assertion.
The XUA Assertion is omitted in the snippet below. For examples of see here.
The primary system shall send the request messages to the X-Assertion Provider of the community using the http POST binding as defined in the W3C SOAP specification. It may look like:
Primary systems shall protocol the request and response for traceability. There are no further requirements on protocols defined in the ordinances of the Swiss EPR.
To ensure privacy the transaction must be secured using https with mutual authentication, using X.509 certificates (extended validation required) and client and server side certificate validation.
The retrieval of a XUA assertion requires user authentication by providing the IdP assertion in the Security header of the SOAP envelope (see Message Semantics). The IdP assertion shall be retrieved by the primary system by using the Authenticate User transaction.
The transaction can be tested with the test suite of the EPR reference environment or the test systems of the EPR communities.
Transaction to renew a IdP Assertion. Primary systems may use this transaction to retrieve a new IdP Assertion, without requiring the user to enter her credentials.
Primary systems shall use this transaction retrieve a new IdP Assertion by sending an assertion retrieved beforehand.
Messages are encoded as described in Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 and the ordinances to the Swiss EPR.
Primary systems shall use this transaction to renew a assertion whose lifetime is exceeded.
The following snippet is adapted from a sample request recorded during the EPR projectathon in September 2020. Some elements and namespaces were omitted to increase readability. The raw request file may be found here.
The Header element of the SOAP envelope contains the data used to sign the request message, as required from the ordinances of the Swiss EPR in Annex 8 and specified in the Web Service Security: SOAP Message Security 1.1. specification.
Primary systems shall embed the SAML Assertion in the the Body of the SOAP envelope (see lines 58 .. 60 in example below).
The community responds with a SAML 2.0 IdP assertion whose lifetime is updated.
The following snippet is adapted from a sample request recorded during the EPR projectathon in September 2020. Some elements and namespaces were ommitted to increase readability. The raw request file may be found here.
A SAML 2.0 IdP Assertion with identical attributes but updated lifetime is conveyed in the the Body of the SOAP envelope (see lines 67 .. 69). Examples of Swiss EPR compliant XUA assertions may be found here.
The primary system shall send the request messages to the registry of the community using the http POST binding as defined in the W3C SOAP specification. It may look like:
Primary systems shall protocol the request and response for traceability. There are no further requirements on protocols defined in the ordinances of the Swiss EPR.
To ensure privacy the transaction must be secured using the TLS SOAP backchannel with mutual authentication by server and client certificate validation.
The transaction can be tested with the Gazelle test suite of the EPR reference environment, or test systems of the EPR communities.
In a primary system, different vaccinations are documented in a treatment context. Primary systems can use this Exchange Format to generate a Immunization Administration document.
In the resource "Bundle", all resources are collected in a container.
{
+ "resourceType" : "Bundle",
+ "id" : "A-D2-HCP1-C1",
+ "meta" : {
+ "profile" : [
+ "http://fhir.ch/ig/ch-vacd/StructureDefinition/ch-vacd-document-immunization-administration"
+ ]
+ },
+ "identifier" : {
+ "system" : "urn:ietf:rfc:3986",
+ "value" : "urn:uuid:bef441e1-58b1-48e3-aa51-61237a3c20cd"
+ },
+ "type" : "document",
+ "timestamp" : "2021-06-15T00:00:00.390+02:00",
+ "entry" : [
+ ....
+ ]
+}
+
In the resource "Composition", general information about the document is specified. It should be the first entry in the list.
"entry" : [
+ {
+ "fullUrl" : "http://test.fhir.ch/r4/Composition/A-D2-HCP1-C1-Composition",
+ "resource" : {
+ "resourceType" : "Composition",
+ "id" : "A-D2-HCP1-C1-Composition",
+ "meta" : {
+ "profile" : [
+ "http://fhir.ch/ig/ch-vacd/StructureDefinition/ch-vacd-composition-immunization-administration"
+ ]
+ },
+ "language" : "en-US",
+ "text" : {
+ "status" : "generated",
+ "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"en-US\" lang=\"en-US\"><h3>Immunization Administration</h3><p><b>Id: </b>A-D2-HCP1-C1-Composition</p><p><b>Identifier: </b><span>urn:ietf:rfc:3986#urn:uuid:ab0add6e-0049-4567-8609-8d3ffdd84af0</span></p><p><b>Status: </b>Final</p><p><b>Code: </b><span>Immunization record (http://snomed.info/sct#41000179103)</span></p><p><b>Patient: </b><a href=\"Patient-TC-patient.html\">Patient/TC-patient</a> Wegmueller Monika</p><p><b>Date: </b>June 15, 2021</p><p><b>Authors:</b></p><table><tr><td><p><a href=\"Practitioner-TC-HCP1-C1.html\">Practitioner/TC-HCP1-C1</a> Bereit Allzeit</p><p><a href=\"Organization-TC-ORG1.html\">Organization/TC-ORG1</a> Gruppenpraxis CH</p></td></tr></table><p><b>Confidentiality: </b>null<span> Normal (qualifier value) (http://snomed.info/sct#17621005)</span></p><p><b>Sections:</b></p><table><tr><td>Immunization Administration</td></tr></table></div>"
+ },
+ "extension" : [
+ {
+ "id" : "versionNumber",
+ "url" : "http://fhir.ch/ig/ch-core/StructureDefinition/ch-ext-epr-versionnumber",
+ "valueUnsignedInt" : 1
+ }
+ ],
+ "identifier" : {
+ "system" : "urn:ietf:rfc:3986",
+ "value" : "urn:uuid:ab0add6e-0049-4567-8609-8d3ffdd84af0"
+ },
+ "status" : "final",
+ "type" : {
+ "coding" : [
+ {
+ "system" : "http://snomed.info/sct",
+ "code" : "41000179103",
+ "display" : "Immunization record"
+ }
+ ]
+ },
+
"subject" : {
+ "reference" : "Patient/TC-patient"
+ },
+ "date" : "2021-06-15T00:00:00+02:00",
+ "author" : [
+ {
+ "reference" : "PractitionerRole/TC-HCP1-ORG1-ROLE-author"
+ }
+ ],
+ "title" : "Immunization Administration",
+
"confidentiality" : "N",
+ "_confidentiality" : {
+ "extension" : [
+ {
+ "url" : "http://fhir.ch/ig/ch-core/StructureDefinition/ch-ext-epr-confidentialitycode",
+ "valueCodeableConcept" : {
+ "coding" : [
+ {
+ "system" : "http://snomed.info/sct",
+ "code" : "17621005",
+ "display" : "Normal (qualifier value)"
+ }
+ ]
+ }
+ }
+ ]
+ },
+ "custodian" : {
+ "reference" : "Organization/TC-ORG1"
+ },
+
"section" : [
+ {
+ "id" : "administration",
+ "title" : "Immunization Administration",
+ "code" : {
+ "coding" : [
+ {
+ "system" : "http://loinc.org",
+ "code" : "11369-6",
+ "display" : "Hx of Immunization"
+ }
+ ]
+ },
+ "text" : {
+ "status" : "generated",
+ "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"en-US\" lang=\"en-US\"><p><b>Code: </b><span>Hx of Immunization (http://loinc.org#11369-6)</span></p><p><b>Entries:</b></p><table><tr><td><a href=\"Immunization-TCA01-IMMUN2-HCP1-ORG1-ROLE.html\">Immunization/TCA01-IMMUN2-HCP1-ORG1-ROLE</a></td></tr></table></div>"
+ },
+ "entry" : [
+ {
+ "reference" : "Immunization/TCA01-IMMUN2-HCP1-ORG1-ROLE"
+ }
+ ]
+ }
+ ]
+
In the "Patient" resource, the demographic and administrative data of a patient are specified.
{
+ "fullUrl" : "http://test.fhir.ch/r4/Patient/TC-patient",
+ "resource" : {
+ "resourceType" : "Patient",
+ "id" : "TC-patient",
+ "meta" : {
+ "profile" : [
+ "http://fhir.ch/ig/ch-core/StructureDefinition/ch-core-patient-epr"
+ ]
+ },
+ "text" : {
+ "status" : "generated",
+ "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative</b></p><div style=\"display: inline-block; background-color: #d9e0e7; padding: 6px; margin: 4px; border: 1px solid #8da1b4; border-radius: 5px; line-height: 60%\"><p style=\"margin-bottom: 0px\">Resource \"TC-patient\" </p><p style=\"margin-bottom: 0px\">Profile: <a href=\"http://fhir.ch/ig/ch-core/StructureDefinition-ch-core-patient-epr.html\">CH Core Patient Profile EPR</a></p></div><p><b>identifier</b>: id: 123.71.332.115, id: 8077560000000000000000</p><p><b>name</b>: Monika Wegmueller </p><p><b>telecom</b>: ph: tel:+41.32.685.12.34(HOME)</p><p><b>gender</b>: female</p><p><b>birthDate</b>: 1967-02-10</p><p><b>address</b>: Leidensweg 10 Specimendorf 9876 CH </p></div>"
+ },
+ "identifier" : [
+ {
+ "system" : "urn:oid:2.16.756.5.31",
+ "value" : "123.71.332.115"
+ },
+ {
+ "system" : "urn:oid:2.16.756.5.30.1.123.100.1.1.1",
+ "value" : "8077560000000000000000"
+ }
+ ],
+ "name" : [
+ {
+ "family" : "Wegmueller",
+ "given" : [
+ "Monika"
+ ]
+ }
+ ],
+ "telecom" : [
+ {
+ "system" : "phone",
+ "value" : "tel:+41.32.685.12.34",
+ "use" : "home"
+ }
+ ],
+ "gender" : "female",
+ "birthDate" : "1967-02-10",
+ "address" : [
+ {
+ "type" : "both",
+ "line" : [
+ "Leidensweg 10"
+ ],
+ "city" : "Specimendorf",
+ "postalCode" : "9876",
+ "country" : "CH"
+ }
+ ]
+ }
+ },
+
The resource Practitioner indicates which practitioner has given a vaccination.
{
+ "fullUrl" : "http://test.fhir.ch/r4/Practitioner/TC-HCP1-C1",
+ "resource" : {
+ "resourceType" : "Practitioner",
+ "id" : "TC-HCP1-C1",
+ "meta" : {
+ "profile" : [
+ "http://fhir.ch/ig/ch-core/StructureDefinition/ch-core-practitioner-epr"
+ ]
+ },
+ "text" : {
+ "status" : "generated",
+ "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative</b></p><div style=\"display: inline-block; background-color: #d9e0e7; padding: 6px; margin: 4px; border: 1px solid #8da1b4; border-radius: 5px; line-height: 60%\"><p style=\"margin-bottom: 0px\">Resource \"TC-HCP1-C1\" </p><p style=\"margin-bottom: 0px\">Profile: <a href=\"http://fhir.ch/ig/ch-core/StructureDefinition-ch-core-practitioner-epr.html\">CH Core Practitioner Profile EPR</a></p></div><p><b>identifier</b>: id: 7608888888888</p><p><b>active</b>: true</p><p><b>name</b>: Allzeit Bereit </p><p><b>telecom</b>: ph: tel:+41.32.234.55.66(WORK), fax: fax:+41.32.234.55.67(WORK), <a href=\"mailto:mailto:allzeit.bereit@gruppenpraxis.ch\">mailto:allzeit.bereit@gruppenpraxis.ch</a>, <a href=\"http://www.gruppenpraxis.ch\">http://www.gruppenpraxis.ch</a></p><p><b>address</b>: Doktorgasse 2 Musterhausen 8888 CH </p></div>"
+ },
+ "identifier" : [
+ {
+ "system" : "urn:oid:2.51.1.3",
+ "value" : "7608888888888"
+ }
+ ],
+ "active" : true,
+ "name" : [
+ {
+ "family" : "Bereit",
+ "given" : [
+ "Allzeit"
+ ],
+ "prefix" : [
+ "Dr. med."
+ ]
+ }
+ ],
+ "telecom" : [
+ {
+ "system" : "phone",
+ "value" : "tel:+41.32.234.55.66",
+ "use" : "work"
+ },
+ {
+ "system" : "fax",
+ "value" : "fax:+41.32.234.55.67",
+ "use" : "work"
+ },
+ {
+ "system" : "email",
+ "value" : "mailto:allzeit.bereit@gruppenpraxis.ch",
+ "use" : "work"
+ },
+ {
+ "system" : "url",
+ "value" : "http://www.gruppenpraxis.ch",
+ "use" : "work"
+ }
+ ],
+ "address" : [
+ {
+ "type" : "physical",
+ "line" : [
+ "Doktorgasse 2"
+ ],
+ "city" : "Musterhausen",
+ "postalCode" : "8888",
+ "country" : "CH"
+ }
+ ]
+ }
+ },
+
The resource stores the information about the organization that creates the Immunization Administration Document
{
+ "fullUrl" : "http://test.fhir.ch/r4/Organization/TC-ORG1",
+ "resource" : {
+ "resourceType" : "Organization",
+ "id" : "TC-ORG1",
+ "meta" : {
+ "profile" : [
+ "http://fhir.ch/ig/ch-core/StructureDefinition/ch-core-organization-epr"
+ ]
+ },
+ "text" : {
+ "status" : "generated",
+ "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative</b></p><div style=\"display: inline-block; background-color: #d9e0e7; padding: 6px; margin: 4px; border: 1px solid #8da1b4; border-radius: 5px; line-height: 60%\"><p style=\"margin-bottom: 0px\">Resource \"TC-ORG1\" </p><p style=\"margin-bottom: 0px\">Profile: <a href=\"http://fhir.ch/ig/ch-core/StructureDefinition-ch-core-organization-epr.html\">CH Core Organization Profile EPR</a></p></div><p><b>identifier</b>: id: 7608888888888</p><p><b>name</b>: Gruppenpraxis CH</p><p><b>telecom</b>: ph: tel:+41.32.234.55.66(WORK), fax: fax:+41.32.234.55.67(WORK), <a href=\"mailto:mailto:bereit@gruppenpraxis.ch\">mailto:bereit@gruppenpraxis.ch</a>, <a href=\"http://www.gruppenpraxis.ch\">http://www.gruppenpraxis.ch</a></p><p><b>address</b>: Doktorgasse 2 Musterhausen ZH 8888 CH </p></div>"
+ },
+ "identifier" : [
+ {
+ "system" : "urn:oid:2.51.1.3",
+ "value" : "7608888888888"
+ }
+ ],
+ "name" : "Gruppenpraxis CH",
+ "telecom" : [
+ {
+ "system" : "phone",
+ "value" : "tel:+41.32.234.55.66",
+ "use" : "work"
+ },
+ {
+ "system" : "fax",
+ "value" : "fax:+41.32.234.55.67",
+ "use" : "work"
+ },
+ {
+ "system" : "email",
+ "value" : "mailto:bereit@gruppenpraxis.ch",
+ "use" : "work"
+ },
+ {
+ "system" : "url",
+ "value" : "http://www.gruppenpraxis.ch",
+ "use" : "work"
+ }
+ ],
+ "address" : [
+ {
+ "line" : [
+ "Doktorgasse 2"
+ ],
+ "city" : "Musterhausen",
+ "state" : "ZH",
+ "postalCode" : "8888",
+ "country" : "CH"
+ }
+ ]
+ }
+ },
+
In the resource "Immunization" the data of the patientes vaccination is defined.
{
+ "fullUrl" : "http://test.fhir.ch/r4/Immunization/TCA01-IMMUN2-HCP1-ORG1-ROLE",
+ "resource" : {
+ "resourceType" : "Immunization",
+ "id" : "TCA01-IMMUN2-HCP1-ORG1-ROLE",
+ "meta" : {
+ "profile" : [
+ "http://fhir.ch/ig/ch-vacd/StructureDefinition/ch-vacd-immunization"
+ ]
+ },
+ "text" : {
+ "status" : "extensions",
+ "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative</b></p><div style=\"display: inline-block; background-color: #d9e0e7; padding: 6px; margin: 4px; border: 1px solid #8da1b4; border-radius: 5px; line-height: 60%\"><p style=\"margin-bottom: 0px\">Resource \"TCA01-IMMUN2-HCP1-ORG1-ROLE\" </p><p style=\"margin-bottom: 0px\">Profile: <a href=\"StructureDefinition-ch-vacd-immunization.html\">CH VACD Immunization Profile</a></p></div><p><b>CH VACD Extension Immunization Recorder Reference</b>: <a href=\"#PractitionerRole_TC-HCP1-ORG1-ROLE-author\">See above (PractitionerRole/TC-HCP1-ORG1-ROLE-author)</a></p><p><b>identifier</b>: id: 11853642-8ff4-45ae-af98-44c58b3bf0b7</p><p><b>status</b>: completed</p><p><b>vaccineCode</b>: Boostrix <span style=\"background: LightGoldenRodYellow; margin: 4px; border: 1px solid khaki\"> (<a href=\"CodeSystem-ch-vacd-swissmedic-cs.html\">Swiss Medic Authorized Vaccines Codesystem</a>#637)</span></p><p><b>patient</b>: <a href=\"#Patient_TC-patient\">See above (Patient/TC-patient)</a></p><p><b>occurrence</b>: 2021-06-15</p><p><b>recorded</b>: 2021-06-15T00:00:00.39+02:00</p><p><b>lotNumber</b>: 14-34218</p><p><b>route</b>: Intramuscular use <span style=\"background: LightGoldenRodYellow; margin: 4px; border: 1px solid khaki\"> (standardterms.edqm.eu#20035000)</span></p><h3>Performers</h3><table class=\"grid\"><tr><td>-</td><td><b>Actor</b></td></tr><tr><td>*</td><td><a href=\"#PractitionerRole_TC-HCP1-ORG1-ROLE-performer\">See above (PractitionerRole/TC-HCP1-ORG1-ROLE-performer)</a></td></tr></table><h3>ProtocolApplieds</h3><table class=\"grid\"><tr><td>-</td><td><b>TargetDisease</b></td><td><b>DoseNumber[x]</b></td></tr><tr><td>*</td><td>Diphtheria caused by Corynebacterium diphtheriae (disorder) <span style=\"background: LightGoldenRodYellow; margin: 4px; border: 1px solid khaki\"> (<a href=\"https://browser.ihtsdotools.org/\">SNOMED CT</a>#397430003)</span>, Tetanus (disorder) <span style=\"background: LightGoldenRodYellow; margin: 4px; border: 1px solid khaki\"> (<a href=\"https://browser.ihtsdotools.org/\">SNOMED CT</a>#76902006)</span>, Pertussis (disorder) <span style=\"background: LightGoldenRodYellow; margin: 4px; border: 1px solid khaki\"> (<a href=\"https://browser.ihtsdotools.org/\">SNOMED CT</a>#27836007)</span></td><td>1</td></tr></table></div>"
+ },
+ "extension" : [
+ {
+ "url" : "http://fhir.ch/ig/ch-vacd/StructureDefinition/ch-vacd-ext-immunization-recorder-reference",
+ "valueReference" : {
+ "reference" : "PractitionerRole/TC-HCP1-ORG1-ROLE-author"
+ }
+ }
+ ],
+ "identifier" : [
+ {
+ "system" : "urn:oid:2.16.756.5.30.1.402.1.3.1.1.1",
+ "value" : "11853642-8ff4-45ae-af98-44c58b3bf0b7"
+ }
+ ],
+ "status" : "completed",
+ "vaccineCode" : {
+ "coding" : [
+ {
+ "system" : "http://fhir.ch/ig/ch-vacd/CodeSystem/ch-vacd-swissmedic-cs",
+ "code" : "637",
+ "display" : "Boostrix"
+ }
+ ]
+ },
+ "patient" : {
+ "reference" : "Patient/TC-patient"
+ },
+ "occurrenceDateTime" : "2021-06-15",
+ "recorded" : "2021-06-15T00:00:00.390+02:00",
+ "lotNumber" : "14-34218",
+ "route" : {
+ "coding" : [
+ {
+ "system" : "http://standardterms.edqm.eu",
+ "code" : "20035000",
+ "display" : "Intramuscular use"
+ }
+ ]
+ },
+ "performer" : [
+ {
+ "actor" : {
+ "reference" : "PractitionerRole/TC-HCP1-ORG1-ROLE-performer"
+ }
+ }
+ ],
+ "protocolApplied" : [
+ {
+ "targetDisease" : [
+ {
+ "coding" : [
+ {
+ "system" : "http://snomed.info/sct",
+ "code" : "397430003",
+ "display" : "Diphtheria caused by Corynebacterium diphtheriae (disorder)"
+ }
+ ]
+ },
+ {
+ "coding" : [
+ {
+ "system" : "http://snomed.info/sct",
+ "code" : "76902006",
+ "display" : "Tetanus (disorder)"
+ }
+ ]
+ },
+ {
+ "coding" : [
+ {
+ "system" : "http://snomed.info/sct",
+ "code" : "27836007",
+ "display" : "Pertussis (disorder)"
+ }
+ ]
+ }
+ ],
+ "doseNumberPositiveInt" : 1
+ }
+ ]
+ }
+ }
+
A Immunization Administration document contains a compositions with different possible sections inside. In minimum one section (optionality: C) next to the optional sections (optionality: O) has to be defined.
The following sections can be defined:
Name | id | System | Code | Display | Optionality |
---|---|---|---|---|---|
Immunization Administration | administration | http://loinc.org | 11369-6 | Hx of Immunization | C |
Medical Problems | medicalproblems | http://loinc.org | 11450-4 | Problem list Reported | C |
Past Illnesses | pastillnesses | http://loinc.org | 11348-0 | Hx of Past illness | C |
Allergies and Intolerences | allergyintolerances | http://loinc.org | 48765-2 | Allergies and adverse reactions Document | C |
Other Relevant Observatons | otherrelevantobservations | http://loinc.org | 30954-2 | Relevant diagnostic tests/laboratory data Narrative | C |
Laboratory-Serology | laboratory-serology | http://loinc.org | 18727-8 | Serology studies (set) | C |
Pregnancy | pregnancy | http://loinc.org | 10162-6 | Pregnancies Hx | C |
Annotation | annotation | http://loinc.org | 48767-8 | Annotation comment Imp | O |
Original representation | originalRepresentation | http://loinc.org | 55108-5 | Clinical presentation | O |
In a primary system, different medications are documented in a treatment context. Primary systems can use this Exchange Format to generate a Medication Card document with the help of the Content Creator.
In the resource "Bundle", all resources are collected in a container.
In the resource "Composition", general information about the document is specified.
In the "Patient" resource, the demographic and administrative data of a patient are specified.
The resource Practitioner indicates which practitioner has prescribed a medication.
The resource stores the information about the organization that create the Medication Card document.
In the resource "MedicationStatement" the data of the patient's medication are specified.
Example normal Dosing (incl. Dosage Non-Structured):
Profile information (normal Dosing)
Profile information (Dosage Non-Structured)
Example split Dosing (incl. Dosage Non-Structured):
Profile information (split Dosing)
Profile information (Dosage Non-Structured)
The resource "Binary" represents the original representation of the Medication Card document.
Transaction to search for patient identities and data from a community using the patient demographic data as search criteria. Primary systems may use this transaction to verify if a patient uses a Swiss EPR and is already registered in the community.
Primary systems may use this transaction to search for patients which are already registered in the community, either because the patient opened the Swiss EPR in the community or because the patient opened the Swiss EPR in a remote community and was already registered by another primary system to store documents. In the Swiss EPR the IHE PDQV3 profile and transactions shall be used to search for patients by demographic data.
To search for patients the primary system shall perform a Patient Demographic Query [ITI-47]. Within the query request the primary system shall provide the demographic data as search criteria. In the Swiss EPR each community must support the name, birthdate, gender and nationality. Individual communities may support other demographic data (e.g., address and other contact data).
The community sends a response with all patient data sets matching the search criteria. Each patient data set contains the known demographic data, the EPR-SPID and the assigned ID. The response contains the master data set as well as all known patient data sets, as registered by other primary systems.
Messages are encoded as described in the HL7 V3 standard with restrictions defined in the IHE PDQ V3 profile and the ordinances to the Swiss EPR.
Since the HL7 V3 standard is very generic, the request message is quite lengthy and needs some background information to interpret. The raw version of a request message may be found here. For a step by step interpretation of the request message, see section below.
The request message is not very complex, but lengthy due to the genericity of the HL7 V3 standard. Therefore the following step by step interpretation may be of help to interpret the response.
The SOAP Header element conveys the following information:
For the patient demographic query no Security header element is required, since in the Swiss EPR the access to the patient data is authorized for all applications, which are registered and authenticate with a client certificate (see section Security Requirements).
The SOAP Body element conveys the administrative information required for a PRPA_IN201305UV02 message in HL7 V3 syntax in which primary systems must set the following values:
The query is encoded in a HL7 V3 controlAct object as follows:
The HL7 controlAct object conveys the query search parameter in a HL7 V3 parameterList element.
In the above example these are
The query supports many more search options and filter parameter. For a documentation of the options see IHE PDQ V3.
Since the HL7 V3 standard is very generic, the response message is quite lengthy and needs some background information to interpret. The raw version of a response message may be found here. For a step by step interpretation of the message, see section below.
The PDQV3 service responds with a list of patient data which match the search parameter in a HL7 V3 subject child element of the controlAct object. The subject child element conveys the following information:
The primary system shall send the request messages to the registry of the community using the http POST binding as defined in the W3C SOAP specification. It may look like:
Primary systems shall store syslog messages to the audit record repository of the community using TLS transport protocol. The audit message uses XML formatting as specified in RFC 3881 with restrictions specified in the IHE ITI TF and the Extension 1 to Annex5 in the ordinances of the Swiss electronic patient record (see Section 1.5 "Requirements on ATNA").
The message is made of the following blocks:
To ensure privacy the transaction must be secured using https with mutual authentication, with X.509 certificates (extended validation required) and client and server side certificate validation.
Note
The transaction can be tested with the test suite of the EPR reference environment, test systems of the EPR communities or the EPR Playground.
Transaction to register a patient in a community. Primary systems shall use this transaction to register patient data to be able to provide and retrieve documents to the patients EPR.
Primary systems shall use this transaction to register patient data with the local ID, the patient is registered in the primary system. In the Swiss EPR the IHE PIX V3 profile and transactions shall be used to register the patient data.
To register the patient data the primary system shall perform a Patient Identity Feed HL7 V3 [ITI-44] transaction. In the feed request the primary system must provide the demographic data as provided by the ZAS central service, which includes the name, birthdate, gender, nationality and the EPR-SPID. Primary systems may provide other demographic data (e.g., address and other contact data).
The community response includes a success confirmation, or a error code in the case an error occurred in the community during registration. In case of success the community stores the patient data provided by the primary system, matches the data set to other patient data set registered by other primary systems and assigns the patient data set to a master patient record and the master patient ID (XAD-PID).
To perform the PIX V3 feed fo the EPR, primary systems must retrieve the demographic data and the EPR-SPID from the ZAS central service. While the interface to be used by the communities is specified in the ordinances to the Swiss electronic patient dossier, the interface for primary systems is not, since communities provide simplified interfaces for primary systems to retrieve the data or included the interface in the registration workflow. Please contact the community you want to connect to on implementation details.
Messages are encoded as described in the HL7 V3 standard with restrictions defined in the IHE Patient Identity Feed HL7 V3 profile and the ordinances to the Swiss EPR.
Due to the genericity of the underlying HL7 V3 standard, the request message is quite lengthy. A raw version of a request message may be found here.
For a step by step interpretation of the request message, see section below.
The request message is not very complex, but lengthy due to the genericity of the HL7 V3 standard.
The SOAP Header element shall convey the following information:
Optional elements may be included according to the specification in the W3C SOAP specification.
For the patient identity feed no Security header element is required, since in the Swiss EPR the access to the patient data is authorized for all applications, which are registered in the community and authenticate with a client certificate (see section Security Requirements).
The SOAP Body element conveys the administrative information required for a PRPA_IN201305UV02 message in HL7 V3 syntax.
Primary systems shall set the following values:
The patient data are encoded in a HL7 V3 controlActProcess object as follows:
The subject child element conveys the following information in its child elements.
The patient child element conveys the patients identifiers and patient demographics:
The patients demographic data are conveyed in the patientPerson child element:
The custodian element shall convey the OID of the provider organization in the id child element:
The PIX V3 Feed service responds with a message indicating the success of the transaction. A raw version of a response message may be found here.
The primary system shall send the request messages to the registry of the community using the http POST binding as defined in the W3C SOAP specification. It may look like:
Primary systems shall store syslog messages to the audit record repository of the community using TLS transport protocol. The audit message uses XML formatting as specified in RFC 3881 with restrictions specified in the IHE ITI TF and the Extension 1 to Annex5 in the ordinances of the Swiss electronic patient record (see Section 1.5 "Requirements on ATNA").
The following snippet shows a example audit message to be written by the primary system:
The message is made of the following blocks:
To ensure privacy the transaction must be secured using https with mutual authentication, with X.509 certificates (extended validation required) and client and server side certificate validation.
Note
The transaction can be tested with the test suite of the EPR reference environment, test systems of the EPR communities or the **EPR Playground.
Transaction to get the master patient ID of a patient in a community using the local ID.
Primary systems shall use this transaction to retrieve the master patient ID (XAD-SPID) for patients the primary systems wants to retrieve or provide documents for. In the Swiss EPR the IHE PIX V3 profile and transactions shall be used to retrieve the master patient ID.
To retrieve the master patient ID for the patient to access the patients EPR, the the primary system shall perform a Patient V3 Query [ITI-45]. Within the query request the primary system shall provide the local ID of the patient in the primary system, as well as the data source parameter of the assigning authority of the community and the the assigning authority EPR-SPID. The local ID must match the local ID the primary system registered the patient with (see PIX Feed).
If the patient is registered in the community, the community sends a response with the master patient ID (XAD-PID) and the EPR-SPID.
Messages are encoded as described in the HL7 V3 standard with restrictions defined in the IHE PIX V3 Query profile and the ordinances to the Swiss EPR.
Due to the genericity of the underlying HL7 V3 standard, the request message is quite lengthy. A raw version of a request message may be found here.
For a step by step interpretation of the request message, see section below.
The request message is not complex in nature, but quite lengthy due to the genericity of the HL7 V3 standard.
The SOAP Header element shall convey the following information:
Optional elements may be included according to the specification in the W3C SOAP specification.
For the PIX query no Security header element is required, since in the Swiss EPR the access to the patient data is authorized for all applications, which are registered in the community and authenticate with a client certificate (see section Security Requirements).
The SOAP Body element conveys the administrative information required for a HL7 V3 PRPA_IN201310UV02 message in HL7 V3 syntax.
Primary systems shall set the following values:
The query parameter are encoded in a HL7 V3 controlActProcess element of the message. Primary systems shall set the following query attributes:
controlActProcess element | |
---|---|
The query parameter are conveyed in the queryByParameter child element:
The PIX V3 Feed service responds with the master patient ID (XAD-PID) and the EPR-SPID, the patient is registered with in the community.
The request message is not very complex, but quite lengthy due to the genericity of the HL7 V3 standard. A raw version of a response message may be found here.
The SOAP Header element shall conveys the following information:
The SOAP Body element conveys the administrative information required for a PRPA_IN201310UV02 message in HL7 V3 syntax and the query result encoded in the controlActProcess element.
The controlActProcess element conveys the following information for the primary system in the subject child element:
The patient child element conveys the master patient ID (XAD-SPID) and the EPR-SPID as follows:
The custodian child element conveys information on the responding system with the the OID of the provider organization in the id child element as follows:
The primary system shall send the request messages to the registry of the community using the http POST binding as defined in the W3C SOAP specification. It may look like:
Primary systems shall store syslog messages to the audit record repository of the community using TLS transport protocol. The audit message uses XML formatting as specified in RFC 3881 with restrictions specified in the IHE ITI TF and the Extension 1 to Annex5 in the ordinances of the Swiss electronic patient record (see Section 1.5 "Requirements on ATNA").
The following snippet shows a example audit message to be written by the primary system:
The message is made of the following blocks:
To ensure privacy the transaction must be secured using https with mutual authentication, with X.509 certificates (extended validation required) and client and server side certificate validation.
Note
The transaction can be tested with the test suite of the EPR reference environment, test systems of the EPR communities or the EPR Playground.
Transaction to store one or more documents to a community. Primary systems shall use this transaction to export documents and the to a community repository to add it to a patients EPR.
Primary systems shall use this transaction to provide documents and the related document metadata to a patient EPR. In the Swiss EPR the IHE XDS.b profile and transactions shall be used.
To store the document metadata of the document, the primary system shall perform a Provide And Register Document Set [ITI-41] transaction. Within the request, the primary systems shall provide the master patient ID as retrieved from the PIX Query, the document metadata as defined in the ordinances of the Swiss EPR and the binary data of the document.
The community responds with a code indicating the successful registration of the document.
Messages are encoded as described in the ebXML standard with restrictions defined in the IHE profile and the ordinances to the Swiss EPR.
Since the ebXML standard is very generic, the request message is quite lengthy and needs some background information to interpret.
The structure of the result set is as follows (see example below):
The table of the identifier used to indicate the metadata attributes is defined by the metadata model used by IHE XDS.b in IHE ITI Technical Framework Vol. 3, Section 4.2.5.1 and IHE ITI Technical Framework Vol. 3, Section 4.2.5.2 .
The corresponding interpretation of the metadata attributes in the Swiss EPR and the supported value sets may be found in Annex 3 of the ordinances of the Swiss electronic patient dossier.
A request message is quite lengthy. A listing with abrevations used in the step by step interpretation below is found here. The raw version of the request message may be found here.
The request message is not very complex, but lengthy due to the genericity of the ebXML standard. Therefore the following step by step interpretation may be of help to interpret the response.
The SOAP Header element conveys the following information:
The SOAP Body element conveys the following objects in ebXML syntax:
We will explain the RegistryPackage object defining the submission set first. For the other elements, see below.
The structure of the RegistryPackage object defining the submission set is as follows (see example below):
The RegistryPackage object defining the submission set has one Slot child elements with name submissionTime which conveys the request timestamp, and a Name element to convey the display name of the submission set (see lines 17 to 25 below).
RegistryPackage element | |
---|---|
The RegistryPackage object defining the submission set has three Classification child elements conveying the submission set metadata:
The RegistryPackage object defining the submission set has three ExternalIdentifier child elements:
The request contains 1..N ExtrinsicObject representing the document metadata for each document. The interpretation of the document metadata matches the document metadata interpretation, which is explained in detail in step by step example in the Registry Stored Query page and will not be reproduced here. Please see Registry Stored Query for the interpretation of the document metadata.
The request contains one Association object linking the document and document metadata to a submission set defined in the RegistryPackage (see Submission Set).
The Association object thus conveys two parameter to link the objects:
In addition the Association object conveys a status indicator, which must take the value Original (see snippet below).
The provide and register service responds with a message indicating the success of the transaction. The outcome indicator is encoded in the Body element of the SOAP envelope as follows:
The raw version of a response message may be found here.
The system shall send the request messages to the repository service of the community using the MIME Multipart/Related binding as specified in the SOAP MTOM specification of the W3C.
The request in MTOM format may look as follows:
The provide and register service sends the response message in the MIME Multipart/Related binding as specified in the SOAP MTOM specification of the W3C.
The response in MTOM format may look as follows:
Primary systems shall store syslog messages to the audit record repository of the community using TLS transport protocol. The audit message uses XML formatting as specified in RFC 3881 with restrictions specified in the IHE ITI TF and the Extension 1 to Annex5 in the ordinances of the Swiss electronic patient record (see Section 1.5 "Requirements on ATNA").
The following snippet shows an example audit message to be written by the primary system:
The message is made of the following blocks:
TODO Update with gazelle example
To ensure privacy the transaction must be secured using https with mutual authentication, with X.509 certificates (extended validation required) and client and server side certificate validation.
To enable authorization, the transaction must convey the XUA Assertion for authorization in the security header of the SOAP envelope. See Provide X-User Assertion for the implementation details.
Note
The transaction can be tested with the test suite of the EPR reference environment, test systems of the EPR communities or the EPR Playground.
Method to provide a SAML 2.0 assertion in the Web Service Security header to authorize transactions. Primary systems shall use this transaction to provide a SAML Assertion to authorize transactions.
Primary systems shall use this transaction to provide SAML 2 assertions retrieved by the Get X-User Assertion with XDS.b transactions as defined in the IHE XUA profile with Swiss specific extensions defined in
Amendment 1 to Annex 5.
This transaction is not used standalone and shall be used in conjunction with other transactions which require authorization. These are:
Primary systems shall use a Get X-User Assertion transaction to retrieve XUA SAML Assertion for authorization, before performing transactions which require authorization. The XUA SAML Assertion for authorization shall be added to the Security header of the SOAP envelope used for the transaction, which requires authorization.
The following snippet shows an abbreviated example message with a SAML Assertion:
For the details on the Assertion content, please see the step by step example in Get X-User Assertion .
This transaction does not require separate ATNA audit log messages, but adds requirements to the transactions used with, as described in section 1.6.4.3.5 of Amendment 1 to Annex 5.
The transaction can be tested with the test suite of the EPR reference environment or test systems of the EPR communities.
This guide aims to explain how to build a FHIR Questionnaire, and in particular how to use the extensions necessary to make full use of the @i4mi/fhir-questionnaire-renderer
library. You can use the Questionnaire Prototype from the mHealth prototype project to render the questionnaire.
Questionnaire
resource in QuasarQuestionnaireResponse
resources, prepopulation and more.Your are free to set whatever fields you want inside your Questionnaire
resource (note that the status
field is mandatory), however only the following fields will be rendered by the Questionnaire Renderer:
title
the title of the questionnairedescription
the description as a markdown stringitem
the array that contains the questionsFor a more detailed and commented example, see the last chapter of this guide.
To add a question, add an object inside the item
array. Every question should have a unique linkId
and a type
. The rendering library supports the following subset of the questionnaire item types:
group
display
boolean
decimal
integer
date
datetime
time
string
text
url
To specify if a questionnaire item is required to be answered, set the field required
to true
.
For details, please see the official documentation for enableWhen.
For choice questions, you can specify the potential answer options in the answerOptions field. Usually, it makes the most sense to use the valueCoding type here, but in this documentation we chose valueString for keeping it simpler.
Choice question | |
---|---|
The repeats
field declares if a choice question can have multiple answers or not. Set it to true
to have a multiple choice question.
As an alternative to answerOptions
, you can link to a ValueSet in the answerValueSet
field with an #
and the id of the contained value-set. The valueSet resource must be in the contained
of the Questionnaire, external ValueSets are not supported as of now.
In a FHIR questionnaire, it is possible to have subquestions for a question. Just add the subquestion in the item
field of the parent question. Of course, a parent item can have multiple subquestions, and the subquestions themselves can have subquestions again. This is rendered in a hierarchical way by the questionnaire renderer. If you want to display the subquestions depending from the answer given to the parent question, you have to declare them as depending questions (see next chapter).
Sub-question | |
---|---|
You can also dynamically enable or not some questions, depending on the status of other questions.
Depending question | |
---|---|
You can also define an initial answer, that is preset to a question and can be changed by the user.
Initial value | |
---|---|
It is possible to specify how questions should be rendered by adding an extension to an element or to its child (see next chapters for more information).
Currently only the Help-Button
, Prompt
and Unit
codes are supported. To see which items do support these codes, please refer on documentation of fhir-questionnaire-renderer.
For choice
questions you can specify if the question should be rendered with radio control (one answer) or with checkboxes (multiple answer allowed) by adding an extension directly to the question. If you do not use this extension on choice
questions, they will be rendered as dropdown control and the repeats
will be used to determine if it is or not a multiple answers question.
If you want to add explanatory/help text to a question, you can do so by adding an item with display
element with the help
code and questionnaire-itemControl
extension as described below.
The help element will take the form of an icon with a question mark which will display the text when hovering over it on a computer or pressing it on a mobile device.
If you want to add prompt/placeholder to an input question, you can do so by adding an item with display
element with the prompt
code and questionnaire-itemControl
extension as described below.
The prompt element will take the form of a text inside an input to give information about what should be entered.
If you want to add unit to an input question, you can do so by adding an item with display
element with the unit
code and questionnaire-itemControl
extension as described below.
The unit element will be displayed at the end of the input field as an indication of the unit of what the user should enter. Please not that the unit is only cosmetic, if you want to have an answer corresponding to an input with its unit, you should use a quantity item, but its not supported by this project.
If you want to render choice
question with checkbox control, you can do so by adding the check-box
code and questionnaire-itemControl
extension as described below.
If you want to render choice
question with radio control, you can do so by adding the radio-button
code and questionnaire-itemControl
extension as described below.
To add internationalisation to a questionnaire, use the FHIR extension translation. The following is applicable for most text elements of a questionnaire (text
, title
, description
, ...). Please note, that for choice questions with answerOptions, internationalisation is not supported. In this case, you need to use an answerValueSet with designation.
The @i4mi/fhir_questionnaire
library will process the extension, see the documentation for more information.
Besides the initial value (see above), it is also possible to prepopulate the answers to the questions, using another FHIR resource with the information contained. The difference between initial values and prepopulation is that, with initial values, the preset answers are the same for every user, while with prepopulation, the answers can be set dynamically for every user, depending on the resource that is passed to the Questionnaire library. How the information is to be extracted from the passed resource is described in FHIRPath.
For this, you have to have the initialExpression extension in every item that should be prepopulated, with the FHIRPath expression that extracts the wanted value from the passed resource.
Prepopulation | |
---|---|
Of course, you also have to pass the resource containing the information to the QuestionnaireData library. You can do this like this:
More information on prepopulating are found on the @i4mi/fhir-questionnaire README.
This is a detailled example using many of the concepts explained above. It is based on the organ donation questionnaire used in this app, however some redundancies are stripped out for better readability.
Detailed example | |
---|---|
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + 37 + 38 + 39 + 40 + 41 + 42 + 43 + 44 + 45 + 46 + 47 + 48 + 49 + 50 + 51 + 52 + 53 + 54 + 55 + 56 + 57 + 58 + 59 + 60 + 61 + 62 + 63 + 64 + 65 + 66 + 67 + 68 + 69 + 70 + 71 + 72 + 73 + 74 + 75 + 76 + 77 + 78 + 79 + 80 + 81 + 82 + 83 + 84 + 85 + 86 + 87 + 88 + 89 + 90 + 91 + 92 + 93 + 94 + 95 + 96 + 97 + 98 + 99 +100 +101 +102 +103 +104 +105 +106 +107 +108 +109 +110 +111 +112 +113 +114 +115 +116 +117 +118 +119 +120 +121 +122 +123 +124 +125 +126 +127 +128 +129 +130 +131 +132 +133 +134 +135 +136 +137 +138 +139 +140 +141 +142 +143 +144 +145 +146 +147 +148 +149 +150 +151 +152 +153 +154 +155 +156 +157 +158 +159 +160 +161 +162 +163 +164 +165 +166 +167 +168 +169 +170 +171 +172 +173 +174 +175 +176 +177 +178 |
|
Transaction to lookup the document metadata for the documents stored in a patient's EPR. Primary systems shall use this transaction to view the metadata of the available documents for to display the data in the UI.
Primary systems shall use this transaction to retrieve the document metadata for the documents stored in a patients EPR. In the Swiss EPR the IHE XDS.b profile and transactions shall be used to retrieve the document metadata.
To retrieve the document metadata of the document stored in a patients EPR, the primary system shall perform a Registry Stored Query [ITI-18]. The Registry Stored Query [ITI-18] supports various query parameter as search and filter parameter. The most common parameter used in the Swiss EPR are the patient ID in CX format and the status information, which must be Approved.
The community responds with the metadata sets of all documents registered in the patient's EPR, which match the search and filter parameter of the query. The profile is based upon the ebXML standard. Due to the genericity of the ebXML standard, the response is not human readable and needs without background information given below.
Messages are encoded as described in the ebXML standard with restrictions defined in the IHE profile and the ordinances to the Swiss EPR.
The following snippet is taken from a sample request recorded during the EPR projectathon in September 2020. Some elements were omitted to increase readability. The raw request file may be found here.
The request message shall be a XML SOAP envelope with the query embedded in the Body element of the SOAP envelope. The SOAP Header element conveys the following information:
The SOAP Body element conveys the AdhocQuery (lines 15 to 26 below) with the following information:
TODO add the originalProvider to the response message.
Since the ebXML standard is very generic, the response message is quite lengthy and needs some background information to interpret.
The structure of the result set is as follows (see example below):
The table of the identifier used to indicate the metadata attributes is defined by the metadata model used by IHE XDS.b in IHE ITI Technical Framework Vol. 3, Section 4.2.5.2.
The corresponding interpretation of the metadata attributes in the Swiss EPR and the supported value sets may be found in Annex 3 of the ordinances of the Swiss electronic patient dossier.
A request message is quite lengthy. A listing with abrevations used in the step by step interpretation below is found here. The raw version of the message may be found here.
The response message is not very complex, but quite lengthy due to the genericity of the ebXML standard. Therefore the following step by step interpretation may be of help to interpret the response.
The SOAP Header element conveys the following information:
The SOAP body element conveys 0..N ExtrinsicObject elements, each conveying the metadata of a single document.
The element has fixed attributes defined in the IHE ITI Technical Framework. Beyond these, the ExtrinsicObject conveys the following information for the primary system:
As explained above, a subset of the relevant metadata are defined in ebXML slot elements. These are:
A subset of the relevant metadata are defined in ebXML Classification elements. These are:
A subset of the relevant metadata are defined in ebXML ExternalIdentifier elements. These are:
The primary system shall send the request messages to the registry of the community using the http POST binding as defined in the W3C SOAP specification. It may look like:
Primary systems shall store syslog messages to the audit record repository of the community using TLS transport protocol. The audit message uses XML formatting as specified in RFC 3881 with restrictions specified in the IHE ITI TF and the Extension 1 to Annex5 in the ordinances of the Swiss electronic patient record (see Section 1.5 "Requirements on ATNA").
The following snippet shows a example audit message to be written by the primary system:
The message is made of the following blocks:
To ensure privacy the transaction must be secured using https with mutual authentication, using X.509 certificates (extended validation required) and client and server side certificate validation.
To enable authorization, the transaction must convey the XUA Assertion for authorization in the security header of the SOAP envelope. See Provide X-User Assertion for the implementation details.
Note
The transaction can be tested with the test suite of the EPR reference environment, test systems of the EPR communities or the EPR Playground.
Transaction to retrieve one or more documents from a community. Primary systems shall use this transaction to read documents from the EPR and integrate to the primary system or to display the document in the UI.
Primary systems shall use this transaction to retrieve documents from a patients EPR. In the Swiss EPR the IHE XDS.b profile and transactions shall be used.
To retrieve the document metadata of the document, the the primary system shall perform a Retrieve Document Set [ITI-43] transaction. Within the request, the primary systems shall provide the master patient ID as retrieved from the PIX Query, and the repository as well as the documents unique IDs taken from the response of the Registry Stored Query. In the Swiss EPR currently only supports the synchronous exchange option is supported.
The community responds the set of documents.
Messages are encoded as described in the ebXML standard with restrictions defined in the IHE profile and the ordinances to the Swiss EPR.
The following snippet displays a sample request recorded during the EPR projectathon in September 2020, with abrevations to increase readability. The raw request file may be found here.
The request message shall be a XML SOAP envelope with the query embedded in the Body element of the SOAP envelope. The SOAP Header element conveys the following information:
The SOAP Body element conveys the ebXML RetrieveDocumentSetRequest which shall convey 1..N DocumentRequest elements (lines 12 to 16 below) with the following information:
The following snippet displays a sample response recorded during the EPR projectathon in September 2020, with abrevations to increase readability. The raw request file may be found here.
The SOAP Header element of the response conveys the following information:
The SOAP Body element conveys the ebXML RetrieveDocumentSetResponse which conveys 1..N DocumentResponse elements (lines 9 to 17 below) with the following information:
The system shall send the request messages to the repository service of the community using the MIME Multipart/Related binding as specified in the SOAP MTOM specification of the W3C.
The repository responds the documents using the MIME Multipart/Related binding as specified in the SOAP MTOM specification of the W3C. A full message may look like:
Primary systems shall store syslog messages to the audit record repository of the community using TLS transport protocol. The audit message uses XML formatting as specified in RFC 3881 with restrictions specified in the IHE ITI TF and the Extension 1 to Annex5 in the ordinances of the Swiss electronic patient record (see Section 1.5 "Requirements on ATNA").
The following snippet shows a example audit message to be written by the primary system:
The message is made of the following blocks:
To ensure privacy the transaction must be secured using https with mutual authentication, with X.509 certificates (extended validation required) and client and server side certificate validation.
To enable authorization, the transaction must convey the XUA Assertion for authorization in the security header of the SOAP envelope. See Provide X-User Assertion for the implementation details.
Note
The transaction can be tested with the test suite of the EPR reference environment, test systems of the EPR communities or the EPR Playground.
Transaction to log out a user from the IdP and all session participants. Primary systems shall perform this transaction to notify the IdP, when a user logs out, or to receive a notification from the IdP, when the user logged out from another application sharing the same IdP session.
Primary systems shall perform this transaction to notify the IdP, when a user logs out, or to receive a notification from the IdP, when the user logged from another relying party sharing the same session.
Messages are encoded as described in Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 and the ordinances to the Swiss EPR.
The following snippet shows the content of a logout request, with some elements omitted to increase readability.
The major content (lines 9..32) of the message is required for to sign the message compliant with the SAML 2.0 specification. Apart from that, the message conveys the following information:
The following snippet shows the content of a logout response, with some elements omitted to increase readability.
The major content (lines 9..32) of the message is required for to sign the message compliant with the SAML 2.0 specification. Apart from that, the message conveys the following information:
The LogoutRequest may be send by primary systems to the IdP using one of the following bindings:
Primary systems shall protocol the transaction in their logs to ensure traceability. No further requirements are defined in the ordinances of the Swiss EPR.
Communication via the SOAP backchannel shall be secured with TLS and mutual authentication, using client and server certificate validation. The certificates used, shall be exchanged during the client registration process.
Communication via the frontchannel (involving the browser) shall be secured with HTTPS and mutual authentication, using server certificate validation.
The transaction can be tested with the Gazelle test suite of the EPR reference environment, or test systems of the EPR communities.
{"use strict";/*!
+ * escape-html
+ * Copyright(c) 2012-2013 TJ Holowaychuk
+ * Copyright(c) 2015 Andreas Lubbe
+ * Copyright(c) 2015 Tiancheng "Timothy" Gu
+ * MIT Licensed
+ */var $a=/["'&<>]/;Un.exports=Ra;function Ra(e){var t=""+e,r=$a.exec(t);if(!r)return t;var o,n="",i=0,s=0;for(i=r.index;i