CH EPR FHIR (R4)
4.0.1-ballot - ballot
This page is part of the CH EPR FHIR (R4) (v4.0.1-ballot: DSTU 4 Ballot 2) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions
According to Swiss EPR regulations, patients have the right to decide who is allowed to access and modify data in their EPR, and under which circumstances (cf. emergency access). The national integration profile “Privacy Policy Query” (CH:PPQ, see Amendment 2.1 of Annex 5 EPRO-FDHA) defines how to specify these decisions as access policies in the XACML 2.0 format and interchange them using the SOAP transport protocol. For mobile applications, this combination of standards is only restrictedly suitable, therefore a more lightweight solution like HL7 FHIR® is required instead.
The national integration profile CH:PPQm — “Privacy Policy Query for Mobile” — is a FHIR-based counterpart of CH:PPQ.
CH:PPQm comprises the following actors and transactions:
Actor: Policy Repository
Role: Stores policies and policy sets and provides the possibility to add, query, update and delete them
Actor: Policy Source
Role: Initiates addition, update and deletion of policies and policy sets
Actor: Policy Consumer
Role: Retrieves policies and policy sets
Table 1 lists the transactions for each actor directly involved in the CH:PPQm Profile. To claim compliance with this profile, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”).
Actors | Transactions | Optionality | Section |
---|---|---|---|
Policy Repository | Mobile Privacy Policy Feed (PPQ-3) | R | PPQ-3 |
Mobile Privacy Policy Bundle Feed (PPQ-4) | R | PPQ-4 | |
Mobile Privacy Policy Retrieve (PPQ-5) | R | PPQ-5 | |
Policy Source | Mobile Privacy Policy Feed (PPQ-3) | O (Note 1) | PPQ-3 |
Mobile Privacy Policy Bundle Feed (PPQ-4) | O (Note 1) | PPQ-4 | |
Policy Consumer | Mobile Privacy Policy Retrieve (PPQ-5) | R | PPQ-5 |
Table 1: CH:PPQm transactions
Note 1: The actor SHALL support at least one transaction.
The required actor groupings are shown in Table 2:
Actors | Actor to be grouped with |
---|---|
Policy Repository | IUA Resource Server |
ATNA Secure Application | |
Policy Source | IUA Authorization Client |
ATNA Secure Application | |
Policy Consumer | IUA Authorization Client |
ATNA Secure Application |
Table 2: CH:PPQm required actors groupings
See also:
This section is not normative.
Implementers may decide to implement CH:PPQm transactions on top of CH:PPQ ones, i.e. to create a FHIR layer over an existing XACML-based Policy Repository. The CH:PPQm specification supports this approach by defining transactions and data structures in a way which allows an efficient bridging between CH:PPQ and CH:PPQm, and by providing message transformation rules (see the page Mappings).
In terms of actor grouping, this would mean that the Policy Repository may be optionally grouped with CH:PPQ Policy Source and CH:PPQ Policy Consumer in order to communicate over PPQ-1 and PPQ-2 with itself.
Note that CH:PPQm is not intended to handle base policies and policy sets, i.e. the ones provided in the official Policy Stack and not related to any particular patients.
In order to provide interoperability between CH:PPQ and CH:PPQm, the page Mappings defines transformation rules between XACML 2.0 Policy Sets and PpqmConsent resources.