This section corresponds to the Record Audit Event [ITI-20] transaction of the IHE IT Infrastructure Technical Framework. This transaction is used to report auditable events to an Audit Record Repository.
Scope
This transaction is used to report auditable events to an Audit Record Repository using FHIR Feed option.
Actor Roles
Actor | Role |
Any actor grouped with the Audit Creator | Create an audit record and transmit this record to the Audit Record Repository. |
Audit Record Repository | Receive an audit record from the Audit Record Creator and store this for audit purposes. |
Audit Record Forwarder | Forward an audit record to Audit Record Repositories. |
Referenced Standards
HL7 FHIR | Release 4 http://hl7.org/fhir/R4/index.html |
RFC4627 | The application/json Media Type for JavaScript Object Notation (JSON) |
Messages
Note 1: Any actor initiating [ITI-20] may send to more than one Audit Record Repository.
Note 2: The Audit Repository that receives an [ITI-20] transaction may or may not be grouped with an Audit Record Forwarder. This diagram does not show a chain of forwarding between actors.
In the context of CA:Aud, Transaction [ITI-20] defines two different interactions that can be used for auditing:
- The “Send Audit Resource Request Message - FHIR Feed Interaction” is used for auditing a single FHIR AuditEvent Resource using RESTful protocol (see section Send Audit Resource Request Message).
- The “Send Audit Bundle Request Message - FHIR Feed Interaction” is used for auditing a bundle of FHIR AuditEvent Resources using RESTful protocol (see section Send Audit Bundle Request Message).
Send Audit Resource Request Message – FHIR Feed Interaction
An actor that is grouped with an Audit Creator or Audit Record Forwarder, detects an event that should be reported and uses the Send Audit Resource Request message to send a report about the event to an Audit Record Repository.
An Audit Creator or Audit Record Forwarder, that supports the FHIR Feed Interaction, uses this message to post a single AuditEvent Resource to the Audit Record Repository using a FHIR create interaction (see https://www.hl7.org/fhir/R4/http.html#create).
Trigger Events
This message is sent when an actor that is grouped with an Audit Creator or Audit Record Forwarder needs to post a single AuditEvent Resource to the Audit Record Repository.
There are two trigger events:
- An Audit Creator detects an event that should be reported to the Audit Record Repository. This transaction does not specify all the policies or reasons for reporting events. They may be specified in other IHE profiles, they may be specified by local law or regulation, or they may be specified by local policy.
- An Audit Record Forwarder determines that a received AuditEvent Resource should be sent to another Audit Record Repository. This transaction does not specify what rules or policies determine whether an AuditEvent Resource should be forwarded.
An actor in any IHE profile, when grouped with an Audit Creator, shall be able to report the events defined in table below. Additional reportable events are often identified for specific events in other IHE profiles and are documented in that profile or transaction.
Audit Record trigger events:
Audit Event Trigger | Description |
Actor-start-stop | Startup and shutdown of any actor. Applies to all actors. Is distinct from hardware powerup and shutdown. |
Audit-Log-Used | The audit trail repository has been accessed or modified by something other than the arrival of audit trail messages. |
Begin-storing-instances | Begin storing SOP Instances for a study. This may be a mix of instances. |
Instances-deleted | SOP Instances are deleted from a specific study. One event covers all instances deleted for the particular study. |
Instances-Stored | Instances for a particular study have been stored on this system. One event covers all instances stored for the particular study. |
Mobile-machine-event | Mobile machine joins or leaves secure domain. |
Node-Authentication-failure | A secure node authentication failure has occurred during TLS negotiation, e.g., invalid certificate. |
Order-record-event | Order record created, accessed, modified or deleted. Involved actors: Order Placer. This includes initial order, updates or amendments, delivery, completion, and cancellation. See note below. |
Patient-record-event | Patient record created, modified, or accessed. |
PHI-export | Any export of PHI on media, either removable physical media such as CD-ROM or electronic transfer of files such as email. Any printing activity, paper or film, local or remote, which prints PHI. |
PHI-import | Any import of PHI on media, either removable physical media such as CD-ROM or electronic transfers of files such as email. |
Procedure-record-event | Procedure record created, modified, accessed or deleted. |
Query Information | A query has been received, either as part of an IHE transaction, or as part other products functions. For example: 1. Modality Worklist Query 2. Instance or Image Availability Query 3. PIX, PDQ, or XDS Query Notes: The general guidance is to log the query event with the query parameters and not the result of the query. The result of a query may be very large and is likely to be of limited value vs. the overhead. The query parameters can be used effectively to detect bad behavior and the expectation is that given the query parameters the result could be regenerated if necessary. |
Security Alert | Security Administrative actions create, modify, delete, query, and display the following: Configuration and other changes, e.g., software updates that affect any software that processes protected information. Hardware changes may also be reported in this event. 1. Security attributes and auditable events for the application functions used for patient management, clinical processes, registry of business objects and methods (e.g., WSDL, UDDI), program creation and maintenance, etc. 2. Security domains according to various organizational categories such as entity-wide, institutional, departmental, etc. 3. Security categories or groupings for functions and data such as patient management, nursing, clinical, etc. 4. The allowable access permissions associated with functions and data, such as create, read, update, delete, and execution of specific functional units or object access or manipulation methods. 5. Security roles according to various task-grouping categories such as security administration, admissions desk, nurses, physicians, clinical specialists, etc. It also includes the association of permissions with roles for role-based access control. 6. User accounts. This includes assigning or changing password or other authentication data. It also includes the association of roles with users for role-based access control, or permissions with users for user-based access control. 7. Unauthorized user attempt to use security administration functions. 8. Audit enabling and disabling. 9. User authentication revocation. 10. Emergency Mode Access (aka Break-Glass) Security administration events should always be audited. |
User Authentication | This message describes the event of a user log on or log off, whether successful or not. No Participant Objects are needed for this message. |
Study-Object-Event | Study is created, modified, accessed, or deleted. This reports on addition of new instances to existing studies as well as creation of new studies. |
Study-used | SOP Instances from a specific study are created, modified or accessed. One event covers all instances used for the particular study. |
Message Semantics
An Audit Creator or Audit Record Forwarder shall issue an HTTP request according to requirements defined in the FHIR specification for “create” interaction (http://hl7.org/fhir/R4/http.html#create). The message uses an HTTP POST method to send a FHIR AuditEvent Resource.
The Audit Creator or Audit Record Forwarder shall submit the FHIR AuditEvent Resource in either XML format or JSON format. Values for mime-type of the request message are defined in the ITI TF-2: Appendix Z.6.
An AuditEvent Resource that reflects Audit Message definition defined in IHE Technical Framework shall conform to the requirements below.
FHIR AuditEvent Resource Attribute | Description |
type | Identifier for a family of the event. For example, a menu item, program, rule, policy, function code, application name or URL. It identifies the performed function. |
subtype | Identifier for the category of event. |
action | Indicator for type of action performed during the event that generated the audit. |
recorded | The time when the event was recorded. |
outcome | Indicates whether the event succeeded or failed. |
outcomeDesc | A free text description of the outcome of the event. |
purposeOfEvent | The purposeOfUse (reason) that was used during the event being recorded. |
agent | An actor taking an active role in the event or activity that is logged. |
agent.type | Specification of the participation type the user plays when performing the event. |
agent.role | The security role that the user was acting under, that come from local codes defined by the access control security system (e.g. RBAC, ABAC) used in the local context. |
agent.who | Reference to who this agent is that was involved in the event. |
agent.altId | Alternative agent Identifier. For a human, this should be a user identifier text string from authentication system. This identifier would be one known to a common authentication system (e.g. single sign-on), if available. |
agent.name | Human-meaningful name for the agent. |
agent.requestor | Indicator that the user is or is not the requestor, or initiator, for the event being audited. |
agent.policy | The policy or plan that authorized the activity being recorded. Typically, a single activity may have multiple applicable policies, such as patient consent, guarantor funding, etc. The policy would also indicate the security token used. |
agent.media | Type of media involved. Used when the event is about exporting/importing onto media. |
agent.network.address | An identifier for the network access point of the user device for the audit event. |
agent.network.type | An identifier for the type of network access point that originated the audit event. |
source | The system that is reporting the event. |
source.site | Logical source location within the healthcare enterprise network. For example, a hospital or other provider location within a multi-entity provider group. |
source.observer | Identifier of the source where the event was detected. |
source.type | Code specifying the type of source where event originated. |
entity | Specific instances of data or objects that have been accessed. |
entity.what | Identifies a specific instance of the entity. The reference should be version specific. |
entity.type | The type of the object that was involved in this audit event. |
entity.role | Code representing the role the entity played in the event being audited. |
entity.lifecycle | Identifier for the data life-cycle stage for the entity. |
entity.securityLabel | Security labels for the identified entity. |
A name of the entity in the audit event. | |
entity.query | The query parameters for a query-type entities. |
entity.detail | Tagged value pairs for conveying additional information about the entity. |
entity.detail.type | The type of extra detail provided in the value. |
entity.detail.ValueBase64Binary | The value of the extra Base64Binary detail. |
Expected Actions
The Audit Record Repository shall support all the mime-types defined in ITI TF-2: Appendix Z.6.
On receipt of the Send Audit Resource Request message, the Audit Record Repository shall validate the Resources and respond with one of the HTTP codes defined in section Message Semantics.
For the Resource received, the Audit Record Repository may:
- discard the Resource as irrelevant
- retain the Resource in an internal data store
- perform other processing on the Resource
The Audit Record Repository may apply a variety of data retention rules to the data store. This transaction does not specify data retention rules. These usually depend upon the purposes assigned to a specific Audit Record Repository.
The Audit Record Repository shall store any resources that were not discarded and make them available for further search via the Retrieve ATNA Audit Event [ITI-81] transaction.
When the Audit Record Repository is grouped with an Audit Record Forwarder, the Audit Record Forwarder shall:
- apply filtering rules to all AuditEvent Resources received by the Audit Record Repository, and
- forward all AuditEvent Resources that match filters to their configured destinations.
Send Audit Resource Response
The Audit Record Repository responds to the Audit Creator or Audit Record Forwarder using a Send Audit Resource Response message in order to inform the client about the result of the operation.
Trigger Events
When the Audit Record Repository has finished storing the AuditEvent Resource received, it sends this message back to the client acknowledging the result of the request.
Message Semantics
The Audit Record Repository returns an HTTP Status code appropriate to the processing, conforming to specification requirements as specified in https://www.hl7.org/fhir/R4/http.html#create.
If the outcome is a success, the http status code of the response shall be a 2xx code. If the outcome is a failure, the Audit Record Repository shall be capable of returning status codes according to what is defined in https://www.hl7.org/fhir/R4/http.html#create.
The Audit Record Repository can return other status codes 4xx or 5xx in accordance to internal business rules that are out of scope for this transaction.
The Audit Record Repository should be able to handle errors in such a way that audit records intended to be recorded are not lost (e.g., errors due to validation of the message format).
Expected Actions
The Audit Record Repository could return failures. For this reason, it is up to the client to decide what to do with failures that have been returned by the Audit Record Repository.
Send Audit Bundle Request Message – FHIR Feed Interaction
An Audit Creator or Audit Record Forwarder that supports the ATX: FHIR Feed Option uses this message to post a Bundle of AuditEvent Resources to the Audit Record Repository using a FHIR batch interaction (see https://www.hl7.org/fhir/R4/http.html#transaction).
Trigger Events
This message is sent when an Audit Record Forwarder or an actor that is grouped with Audit Creator needs to send multiple events that has been audited to the Audit Record Repository.
There are two trigger events:
- An Audit Creator detects at least one event that should be reported to the Audit Record Repository. This transaction does not specify all of the policies or reasons for reporting events. They may be specified in other IHE profiles, they may be specified by local law or regulation, or they may be specified by local policy.
- An Audit Record Forwarder determines that at least one received AuditEvent Resource should be sent to another Audit Record Repository. This transaction does not specify what rules or policies determine whether an AuditEvent Resource should be forwarded.
An actor in any IHE profile, when grouped with an Audit Creator, shall be able to report the events defined in the table in section Send Audit Resource Request Message, Trigger Events. Additional reportable events are often identified for specific events in other IHE profiles and are documented in that profile or transaction.
Message Semantics
An Audit Record Forwarder or an actor that is grouped with Audit Creator shall issue an HTTP request according to requirements defined in the FHIR specification for “batch” interaction (see https://www.hl7.org/fhir/R4/http.html#transaction).
The Audit Record Repository and the client shall both support the “batch” interaction. The message uses an HTTP POST method to submit a FHIR Bundle Resource. The client shall post FHIR resources in either XML format or JSON format. Values for mime-type of the request message are defined in ITI TF-2: Appendix Z.6.
The FHIR Bundle Resource shall contain at least one FHIR AuditEvent Resource (https://www.hl7.org/fhir/R4/auditevent.html).
The element Bundle.entry.request.method shall be POST.
AuditEvent Resources included in the Bundle that reflect Audit Message definitions defined in IHE Technical Framework shall conform to the requirements defined in section Send Audit Resource Request Message Semantics.
Bundle Resource Constraints:
Element & Cardinality | Constraints |
type | Shall be: batch |
entry | Shall contain at least one AuditEvent Resource |
entry.request.method | Shall be: POST |
Expected Actions
The Audit Record Repository shall support all the mime-types defined in ITI TF-2: Appendix Z.6.
On receipt of the Send Audit Bundle Resource Request, the Audit Record Repository shall validate Resources included in it and respond with one of the HTTP codes defined in section Send Audit Bundle Response Message Semantics.
For each Resource received in the Bundle, the Audit Record Repository may:
- Discard the Resource as irrelevant.
- Retain the Resource in an internal data store.
- Perform other processing on the Resource.
The Audit Record Repository may apply a variety of data retention rules to the data store. This transaction does not specify data retention rules. These are usually dependent upon the purposes assigned to a specific Audit Record Repository.
The Audit Record Repository shall store any resources that were not discarded and make them available for further search via the Retrieve ATNA Audit Event [ITI-81] transaction.
When the Audit Record Repository is grouped with an Audit Record Forwarder, the Audit Record Forwarder shall:
- Apply filtering rules to all AuditEvent Resources received by the Audit Record Repository, and
- Forward all AuditEvent Resources that match filters to their configured destinations.
Send Audit Bundle Response
The Audit Record Repository sends a Send Audit Bundle Response message in response to a Send Audit Bundle Request.
Trigger Events
When the Audit Record Repository has finished storing the AuditEvent Resources received in the Bundle Resource, it sends back this message to the client acknowledging the result of the request.
Message Semantics
The Audit Record Repository returns an HTTP Status code appropriate to the processing, conforming to specification requirements as specified in https://www.hl7.org/fhir/R4/http.html#transaction-response.
When the Audit Record Repository has processed the request shall return an HTTP response with an overall status code.
To allow the client to know the outcome of the transaction, and the identities assigned to the resources by the Audit Record Repository, the Audit Record Repository shall return a Bundle, with type set to batch-response. Each entry element shall contain a response element with an HTTP Status Code which details the outcome of processing of the request entry.
If no “Prefer” header is specified in the request the server should respond as if it is set to return=minimal; see https://www.hl7.org/fhir/R4/http.html#ops.
If the outcome of the entry is a success, the http status code of the response shall be a 2xx code.
If the outcome of the entry is a failure, the Audit Record Repository shall be capable of returning status codes according to what is defined in https://www.hl7.org/fhir/R4/http.html#create.
The Audit Record Repository can return other status codes 4xx or 5xx in accordance to internal business rules that are out of scope for this transaction.
The Audit Record Repository should be able to handle errors in such a way that audit records intended to be recorded are not lost (e.g., errors due to validation of the message format).
Expected Actions
The Audit Record Repository could return a partial success for the Bundle where some resources succeeded and other not. For this reason, it is up to the client to decide what to do with failures that have been returned by the Audit Record Repository.
Security Considerations
The use of the TLS or HTTPS transport mechanism is recommended because the audit event messages often contain PHI or other sensitive information.
The use of the TLS transport mechanism is not always required because there are other means of protection that may be more appropriate in some situations. The decision to use the UDP transport mechanism should be based upon a security and privacy risk analysis.
The data store within the Audit Record Repository may contain sensitive information, and the Audit Record Repository analysis facilities may allow sensitive queries. It will be a high value target for malicious actors and should be protected accordingly.
The Audit Record Repository is required to generate audit event messages for various kinds of use of the data store and configuration changes. This is specified in section Send Audit Resource Request Message, Trigger Events.
If the AuditEvent Message Option is supported on the Audit Record Repository, update, delete and patch interaction of AuditEvent Resources should be managed by local policies.