CH EPR FHIR (R4)
5.0.0-ballot - ballot Switzerland flag

This page is part of the CH EPR FHIR (R4) (v5.0.0-ballot: DSTU 5 Ballot) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Mobile Privacy Policy Feed [PPQ-3]

Scope

This transaction is used by the Policy Source to add, update, or delete single privacy policies. Correspondingly, the following HTTP methods SHALL be supported: POST, PUT, and DELETE.

HTTP Method POST

Interaction Diagram for [PPQ-3 POST]Interaction Diagram for [PPQ-3 POST]Policy RepositoryPolicy SourcePolicy RepositoryPolicy SourcePolicy RepositoryPolicy RepositoryHTTPPOST[baseUrl]/ConsentPayload: ConsentHTTP responsePayload: none / OperationOutcome / Consent
Figure 2: PPQ-3: HTTP Method POST

Trigger Event

The Policy Source uses HTTP method POST to submit a single new privacy policy to the Policy Repository.

Request Message

The request body SHALL represent a single Consent resource compliant to the PpqmConsent profile.

The request SHALL be sent to [baseUrl]/Consent.

Expected Actions

Upon receiving the HTTP POST request, the Policy Repository SHALL:

  • Validate the Consent resource contained in the request body.
  • Persist the policy set represented by this Consent.
  • Create a PPQ-3 response according to the transaction outcome.

Response Message

The PPQ-3 response SHALL be created according to the section 3.1.0.8 of the FHIR R4 specification.

HTTP Method PUT

Interaction Diagram for [PPQ-3 PUT]Interaction Diagram for [PPQ-3 PUT]Policy RepositoryPolicy SourcePolicy RepositoryPolicy SourcePolicy RepositoryPolicy RepositoryHTTPPUT[baseUrl]/Consent?identifier=[uuid]Payload: ConsentHTTP responsePayload: none / OperationOutcome / Consent
Figure 3: PPQ-3: HTTP Method PUT

Trigger Event

The Policy Source uses HTTP method PUT to submit a new or update an existing single privacy policy.

Request Message

The request body SHALL represent a single Consent resource compliant to the PpqmConsent profile.

The request SHALL be sent to [baseUrl]/Consent?identifier=[uuid].

Expected Actions

The Policy Repository SHALL implement the Conditional Update pattern described in section 3.1.0.4.3 of the FHIR R4 specification.

Upon receiving the HTTP PUT request, the Policy Repository SHALL:

  • Validate the Consent resource contained in the request body. In particular, it SHALL be validated that the policy set ID is the same as in the HTTP URL.
  • Persist the policy set represented by this Consent.
  • Create a PPQ-3 response according to the transaction outcome.

Response Message

The PPQ-3 response SHALL be created according to the section 3.1.0.4 of the FHIR R4 specification.

HTTP Method DELETE

Interaction Diagram for [PPQ-3 DELETE]Interaction Diagram for [PPQ-3 DELETE]Policy RepositoryPolicy SourcePolicy RepositoryPolicy SourcePolicy RepositoryPolicy RepositoryHTTPDELETE[baseUrl]/Consent?identifier=[uuid]Payload: noneHTTP responsePayload: none / OperationOutcome
Figure 4: PPQ-3: HTTP Method DELETE

Trigger Event

The Policy Source uses HTTP method DELETE to delete a single existing privacy policy from the Policy Repository.

Request Message

The request body SHALL be empty.

The request SHALL be sent to [baseUrl]/Consent?identifier=[uuid].

Expected Actions

The Policy Repository SHALL implement the Conditional Delete pattern described in section 3.1.0.7.1 of the FHIR R4 specification.

Upon receiving the HTTP DELETE request, the Policy Repository SHALL:

  • Delete the policy set referenced in the request.
  • Create a PPQ-3 response according to the transaction outcome.

Response Message

The PPQ-3 response SHALL be created according to the section 3.1.0.7 of the FHIR R4 specification.

Security Considerations

The transaction SHALL be secured by Transport Layer Security (TLS) encryption and server authentication with server certificates.

The transaction SHALL use client authentication and authorization using one of the following strategies:

  1. Use an extended access token defined in IUA conveyed as defined in the Incorporate Access Token [ITI-72] transaction.
  2. or, use mutual authentication (mTLS) on the transport layer in combination with a XUA token for authorization from the Get X-User Assertion transaction (Annex 5.1 1.6.4.2). The XUA token SHALL be conveyed as defined in the Incorporate Access Token [ITI-72] transaction.

The Policy Repository actor shall be grouped with CH:ADR, i.e. the Policy Repository shall use the CH:ADR Authorization Decision Request transaction to authorize the transaction and enforce the authorization decision retrieved from CH:ADR Authorization Decision Response.

The actors SHALL support the traceparent header handling, as defined in Appendix: Trace Context.

Security Audit Considerations

The Policy Source and Policy Repository SHALL record the right audit event for the operations: