3.3.0-ballot - ballot Switzerland flag

This page is part of the CH ATC (R4) (v3.3.0-ballot: Draft Ballot 5) 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

Volume 2 - Transactions

Constraints on Retrieve ATNA Audit Event [ITI-81]

The Retrieve ATNA Audit Event [ITI-81] transaction is defined in IHE ITI TF-2 and the IHE ITI Supplement Add RESTful Query to ATNA. The following rules shall be applied for the CH:ATC profile.

Message Semantics

The Retrieve ATNA Audit Event message shall be a HTTP GET request sent to the Patient Audit Record Repository. This message is a FHIR search (see on AuditEvent Resources (see This “search” target is formatted as:



  1. <scheme> shall be https.
  2. <query> shall include the entity.identifier as defined in Additional ATNA Search Parameters and may include additional ATNA Search parameters. If entity.identifier is not included an HTTP response code 400 - Bad Request shall be returned.

Additional ATNA Search Parameters

The Patient Audit Consumer shall not use the following parameters in a query parameters: address, patient.identifier, source, type, user, outcome. The Patient Audit Consumer may use other parameters as listed in Retrieve Audit Event [ITI-81].

entity.identifier is a parameter of token type. This parameter specifies unique identifier for the object. The parameter value should be identified in accordance to the entity type;
For example:|5678

The Audit Record Repository shall match this parameter with the AuditEvent.entity.what.identifier field that is of type identifier (ParticipantObjectID in DICOM schema).

For the CH:ATC profile the entity.identifier has to be the EPR-SPID:
entity.identifier=urn:oid:2.16.756.|<<<value EPR-SPID>>>

Message Semantics for Response

The returned AuditEvent FHIR resources in the Bundle shall conform the CH:ATC AuditEvent profile, see Volume 3 - Content Profiles.

Security Considerations

The transaction is used to exchange sensitive information and requires authentication and authorization. This profile requires all actors to be grouped with Secure Node or Secure Application implementing the “STX: TLS 1.2 floor using BCP195 Option” defined in the IHE ITI TF-2, chapter

Access control shall be implemented by grouping the CH:ATC Audit Consumer and Audit Record Repository with the Authorization Client and Resource Server from the IUA trial implementation profile using the SAML Token option (see IHE ITI Supplement IUA , chapter As defined therein, the CH:ATC Audit Consumer and Audit Record Repository shall implement the Incorporate Authorization Token [ITI-72] transaction to convey the XUA token.

The actors shall implement the Incorporate Authorization Token [ITI-72] transaction with SAML token option, using the base64url encoded SAML assertion defined in XUA to the authorization header of the HTTP1.1 GET request with key “Bearer” as follows:

GET /example/url/to/resource/location HTTP/1.1
Authorization: "Bearer" fFBGRNJru1FQd[…omitted for brevity…]44AzqT3Zg

The CH:ATC Patient Audit Record Repository shall be grouped with CH:ADR, i.e. the CH:ATC Patient Audit Record 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.

Security Audit Considerations

An audit event as specified in Access Audit Trail Content Profile shall be returned by a query to Patient Audit Record Repository after the Patient Audit Record Repository has been queried by a Patient Audit Consumer.