---
type: "resource"
title: "AuditEvent"
resource: "AuditEvent"
---
# AuditEvent
## Introduction
## Scope and Usage
The audit event is based on the [IHE-ATNA Audit record definitions](https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html), originally from [RFC 3881](http://tools.ietf.org/html/rfc3881), and now managed by DICOM (see [DICOM Part 15 Annex A5](http://medical.nema.org/medical/dicom/current/output/html/part15.html#sect_A.5)).
- ASTM E2147 - Setup the concept of security audit logs for healthcare including accounting of disclosures
- IETF RFC 3881 - Defined the Information Model (IETF rule forced this to be informative)
- DICOM Audit Log Message - Made the information model Normative, defined Vocabulary, Transport Binding, and Schema
- IHE ATNA - Defines the grouping with secure transport and access controls; and defined specific audit log records for specific IHE transactions.
- NIST SP800-92 - Shows how to do audit log management and reporting - consistent with our model
- HL7 PASS - Defined an Audit Service with responsibilities and a query interface for reporting use
- ISO 27789 - Defined the subset of audit events that an EHR would need
- ISO/HL7 10781 EHR System Functional Model Release 2
- ISO 21089 Trusted End-to-End Information Flows
This resource is managed collaboratively between HL7, DICOM, and IHE.
A record of an event relevant for purposes such as operations, privacy, security, maintenance, and performance analysis.
## Background and Context
All actors - such as applications, processes, and services - involved in an auditable event SHOULD record an AuditEvent. This will likely result in multiple AuditEvent entries that show whether privacy and security safeguards, such as access control, are properly functioning across an enterprise's system-of-systems. Thus, it is typical to get an auditable event recorded by both the application in a workflow process and the servers that support them. For this reason, duplicate entries are expected, which is helpful because it MAY aid in the detection of security, privacy, or other operational problems. For example, fewer than expected actors being recorded in a multi-actor process or attributes related to those records being in conflict, which is an indication of a security problem. There MAY be non-participating actors, such as trusted intermediary, that also detect a security, privacy, or operational relevant event and thus would record an AuditEvent.
Security relevant events are not limited to communications or RESTful events. They include:
- software start-up and shutdown;
- user login and logout;
- access control decisions;
- configuration events;
- software installation;
- policy rules changes; and
- manipulation of data that exposes the data to users.
See the [Audit Event Category](valueset-audit-event-type-example) vocabulary for guidance on some security relevant event categories.
The AuditEvent resource holds the details of an event in terms of who, what, where, when, and why. Where the identification of the who participated is the agent. An agent can be a person, an organization, software, device, or other actors that MAY be ascribed responsibility. What objects were used/created/updated is recorded as the entity. An entity is an identifiable physical, digital, conceptual or other kind of thing; entities MAY be real or imaginary.
The content of an AuditEvent is primarily intended for administrative use; used by security system administrators, security and privacy information managers, records management personnel, etc. The AuditEvent MAY also inform the Patient about uses of their data. This content can be accessible or used directly by other healthcare users, such as providers or patients for gaining insight into who and what has been done. The AuditEvent record includes very sensitive information so access to the AuditEvent would be highly privileged and controlled. For example, when providing AuditEvent to a patient the data feed would be limited to the Patient compartment, and the content MAY be subsetted or masked in order to meet privacy needs. The AuditEvent record is not intended to replace other audit logs, but rather used to enhance them, or to be used as an API to many audit logs.
Relationship of AuditEvent and Provenance resources are often (though not exclusively) created by the application responding to the create/read/query/update/delete/execute etc. event. A [Provenance](provenance) resource contains overlapping information, but is a record-keeping assertion that gathers information about the context in which the information in a resource "came to be" in its current state, e.g., whether it was created de novo or obtained from another entity in whole, part, or by transformation. Provenance resources are prepared by the application that initiates the create/update of the resource and MAY be persisted with the AuditEvent target resource.
## Notes
### Using Coded Values
The AuditEvent resource and the ATNA Audit record are used in many contexts throughout healthcare. The coded values defined in the "extensible" bindings above are those widely used and/or defined by DICOM, IHE or ISO, who defined these codes to meet very specific use cases. These codes SHOULD be used when they are suitable. When needed, other codes can be defined.
Note: When using codes from a vocabulary, the `display` element for the code can be left off to keep the AuditEvent size small and minimize impact of a large audit log of similar entries.
The set of codes defined for this resource is expected to grow over time, and additional codes MAY be proposed / requested using the "Propose a change" link above below.
### Event codes for Common Scenarios
This table summarizes common event scenarios, and the codes that SHOULD be used for each case.
| **Scenario** | **category** | **code** | **action** | **Other** |
| --- | --- | --- | --- | --- |
| User Login ([example](auditevent-examples)) | [110114](http://dicom.nema.org/resources/ontology/DCM#DCM_110114) User Authentication | [110122](http://dicom.nema.org/resources/ontology/DCM#DCM_110122) User Authentication | [E](valueset-audit-event-action) Execute | One agent which contains the details of the logged-in user. |
| User Logout ([example](auditevent-examples)) | [110114](http://dicom.nema.org/resources/ontology/DCM#DCM_110114) User Authentication | [110123](http://dicom.nema.org/resources/ontology/DCM#DCM_110123) User Logout | [E](valueset-audit-event-action) Execute | One agent which contains the details of the logged-out user. |
| REST operation logged on server ([example](audit-event-example-vread)) | [rest](valueset-audit-event-type-example) RESTful Operation | [\[code\]](valueset-type-restful-interaction) defined for operation | [\*](valueset-audit-event-action) (see below) | Agent for logged in user, if available. |
| Search operation logged on server ([example](audit-event-example-search)) | [rest](valueset-audit-event-type-example) RESTful Operation | [\[code\]](valueset-type-restful-interaction) defined for operation | [E](valueset-audit-event-action) Execute | Agent for logged in user, if available, and one object with a query element. The Execute action is used as the server must execute the search parameters to get the results, whereas a Read action identifies a specific object. |
| Break-Glass started ([example](auditevent-example-breakglass-start)) | [110113](http://dicom.nema.org/resources/ontology/DCM#DCM_110114) Security Alert | [110127](http://dicom.nema.org/resources/ontology/DCM#DCM_110122) Emergency Override Started | [E](valueset-audit-event-action) Execute | Agent is the user who is authorized to break-glass and has declared an emergency override. Note there is an Emergency Override Stopped code that can be used to indicate the closing of the break-glass event, when it is known. |
Audit Event Actions for RESTful operations:
| **Operation** | **Action** |
| --- | --- |
| create | C |
| read, vread, history-instance, history-type, history-system | R |
| update | U |
| delete | D |
| transaction, operation, conformance, validate, search, search-type, search-system | E |
#### Recording Search Events
A search event is recorded as an Execute action as the server must execute the search parameters to get the results. The category is a `rest` operation. The code SHOULD be `search`. The Server is identified in an `.agent` as the role `Destination Role ID`, and the client is identified in an `.agent` as the role `Source Role ID`. Additional `.agent` elements MAY be used to identify user, application, organization, etc.
A Search Event records one `.entity` element that holds the search request, and SHOULD NOT record the contents of the search response so as to limit duplication of sensitive health information that is already present in the system, and discoverable by replaying the search request.
The `AuditEvent.entity.query` SHALL hold the whole WHOLE http header and body encoded as base64binary. This SHOULD preserve as much of the raw http header and body as possible to best capture any attempts by clients or intermediaries to misbehave. There SHOULD be no sanitization or normalization of this value.
The FHIR specification defines a harmonized search parameter string, which is returned in the searchset bundle as the `.link.url` on the `.link` for self. This string could be recorded in the `AuditEvent.entry.description` as it is well behaved and represents what was actually processed as search parameters. See: [conformance](http://hl7.org/fhir/search.html#conformance)
Where there are identifiable Patient subject(s) associated with the returned Resource(s), the [AuditEvent.patient](auditevent#patient) SHOULD be used to record the Patient as the subject of the data or activity. When multiple patient results are returned one AuditEvent is created for every Patient identified in the resulting search set. Note this is true when the search set bundle includes any number of resources that collectively reference multiple Patients. This includes one Resource with multiple subject values, or many Resources with single subject values that are different.
### Encoding a FHIR operation outcome
FHIR interactions can result in a rich description of the outcome using the [OperationOutcome](operationoutcome). The [OperationOutcome](operationoutcome) Resource is a collection of error, warning or information messages that result from a system action. This describes in detail the outcome of some operation, such as when a [RESTful operation](http#operations) fails.
When recording into an AuditEvent that some FHIR interaction has happened, the AuditEvent SHOULD include the [OperationOutcome](operationoutcome) from that FHIR interaction. This is done by placing the OperationOutcome into an AuditEvent.entity. Likely as a [contained](references#contained) resource, given that OperationOutcome resources often are not persisted.
`entity.what` is the OperationOutcome -- Likely [contained](references#contained)
`entity.type` is code `[OperationOutcome](codesystem-fhir-types#fhir-types-OperationOutcome)`
`entity.description` explains why this OperationOutcome was included.
See [transaction failure example](auditevent-example-error): When a client attempts to post (create) an `Observation` Resource, using a server `Patient` endpoint; this would result in an error with an OperationOutcome.
### authorization and agent.authorization
The AuditEvent provides the element `AuditEvent.authorization` to convey the purpose of use for the whole event and `AuditEvent.agent.authorization` to convey the purpose of use that a particular actor (machine, person, software) was involved in the event.
`AuditEvent.authorization` is an element at the level of AuditEvent and can convey the purpose of the activity that resulted in the event. This will occur when the system that is reporting the event is aware of the purpose of the event. A specific example would be a radiology reporting system where a radiologist has created and is sending a finished report. This system likely knows the purpose, e.g., "treatment". It is multi-valued because the one event MAY be related to multiple purposes.
It is also commonplace that the reporting system does not have information about the purpose of the event. In these cases, the event report would not have an authorization.
It is also likely that the same event will be reported from different perspectives, e.g., by both the sender and recipient of a communication. These two different perspectives can have different knowledge regarding the purposeOfUse authorization.
`AuditEvent.agent.authorization` is an element at the level of `agent` within AuditEvent. This describes the reason that this person, machine, or software is participating in the activity that resulted in the event. For example, an individual person participating in the event MAY assert a purpose of use from their perspective. It is also possible that they are participating for multiple reasons and report multiple purposeOfUse.
The reporting system might not have knowledge regarding why a particular machine or person was involved and would omit this element in those cases.
When the same event is reported from multiple perspectives, the reports can have different knowledge regarding the purpose.
### Patient as subject of data or activity reference in AuditEvent.patient
It is a best practice to include a reference to the Patient affected by any auditable event, in order to enable Privacy Accounting of Disclosures and Access Logs, and to enable privacy office and security office audit log analysis. Reasonable efforts SHOULD be taken to assure the Patient is recorded, but it is recognized that there are times when this is not reasonable.
Where an activity impacts more than one Patient subject; multiple AuditEvent resources SHOULD be recorded, one for each Patient subject. This best enables segmentation of the AuditEvent details so as to limit the Privacy impact. The use of multiple AuditEvent is a best-practice and SHOULD be driven by a Policy. There will be cases where the use of multiple AuditEvent resources are not necessary, such as public health reporting.
To record a REST interaction or $operation, it is often necessary to complete the transaction in order to determine the Patient subject. Inspection of the potential returned results MAY be necessary. Some REST and $operations include parameters limiting the results to a specific Patient, in these cases this parameter informs the inclusion of the Patient reference.
Implementation Guides MAY make the AuditEvent requirements more clear given the workflow or security context mandated by the Implementation Guide.
## StructureDefinition
### Elements (Simplified)
- **[AuditEvent](/auditevent-definitions#AuditEvent)** [0..*]: - Record of an event
- **[AuditEvent.type](/auditevent-definitions#AuditEvent.type)** [1..1]: [CodeableConcept](/CodeableConcept) example:[audit-event-type-example](/valueset-audit-event-type-example) High level categorization of audit event
- **[AuditEvent.subtype](/auditevent-definitions#AuditEvent.subtype)** [0..*]: [CodeableConcept](/CodeableConcept) example:[audit-event-sub-type-example](/valueset-audit-event-sub-type-example) Specific type of event
- **[AuditEvent.action](/auditevent-definitions#AuditEvent.action)** [0..1]: [code](/code) required:[audit-event-action](/valueset-audit-event-action) Type of action performed during the event
- **[AuditEvent.severity](/auditevent-definitions#AuditEvent.severity)** [0..1]: [code](/code) required:[audit-event-severity](/valueset-audit-event-severity) emergency | alert | critical | error | warning | notice | informational | debug
- **[AuditEvent.occurred[x]](/auditevent-definitions#AuditEvent.occurred%5Bx%5D)** [0..1]: [Period](/Period), [dateTime](/dateTime) When the activity occurred
- **[AuditEvent.recorded](/auditevent-definitions#AuditEvent.recorded)** [1..1]: [instant](/instant) Time when the event was recorded
- **[AuditEvent.outcome](/auditevent-definitions#AuditEvent.outcome)** [0..1]: [BackboneElement](/BackboneElement) Whether the event succeeded or failed
- **[AuditEvent.outcome.code](/auditevent-definitions#AuditEvent.outcome.code)** [1..1]: [Coding](/Coding) preferred:[audit-event-outcome](/valueset-audit-event-outcome) Whether the event succeeded or failed
- **[AuditEvent.outcome.detail](/auditevent-definitions#AuditEvent.outcome.detail)** [0..*]: [CodeableConcept](/CodeableConcept) example:[audit-event-outcome-detail-example](/valueset-audit-event-outcome-detail-example) Additional outcome detail
- **[AuditEvent.authorization](/auditevent-definitions#AuditEvent.authorization)** [0..*]: [CodeableConcept](/CodeableConcept) example:[v3-PurposeOfUse](/valueset-v3-PurposeOfUse) Authorization related to the event
- **[AuditEvent.basedOn](/auditevent-definitions#AuditEvent.basedOn)** [0..*]: Reference([Resource](/Resource)) Workflow authorization within which this event occurred
- **[AuditEvent.patient](/auditevent-definitions#AuditEvent.patient)** [0..1]: Reference([Patient](/Patient)) The patient is the subject of the data used/created/updated/deleted during the activity
- **[AuditEvent.encounter](/auditevent-definitions#AuditEvent.encounter)** [0..1]: Reference([Encounter](/Encounter)) Encounter within which this event occurred or which the event is tightly associated
- **[AuditEvent.agent](/auditevent-definitions#AuditEvent.agent)** [1..*]: [BackboneElement](/BackboneElement) Actor involved in the event
- **[AuditEvent.agent.type](/auditevent-definitions#AuditEvent.agent.type)** [0..1]: [CodeableConcept](/CodeableConcept) preferred:[participation-role-type](/valueset-participation-role-type) How agent participated
- **[AuditEvent.agent.role](/auditevent-definitions#AuditEvent.agent.role)** [0..*]: [CodeableConcept](/CodeableConcept) example:[security-role-type-example](/valueset-security-role-type-example) Agent role in the event
- **[AuditEvent.agent.who](/auditevent-definitions#AuditEvent.agent.who)** [1..1]: [Reference(Practitioner](/Reference(Practitioner), [PractitionerRole](/PractitionerRole), [Organization](/Organization), [CareTeam](/CareTeam), [Patient](/Patient), [Device](/Device), [DeviceDefinition](/DeviceDefinition), [RelatedPerson](/RelatedPerson), [Group](/Group), [HealthcareService)](/HealthcareService)) Identifier of who
- **[AuditEvent.agent.requestor](/auditevent-definitions#AuditEvent.agent.requestor)** [0..1]: [boolean](/boolean) Whether user is initiator
- **[AuditEvent.agent.location](/auditevent-definitions#AuditEvent.agent.location)** [0..1]: Reference([Location](/Location)) The agent location when the event occurred
- **[AuditEvent.agent.policy](/auditevent-definitions#AuditEvent.agent.policy)** [0..*]: [uri](/uri) Policy that authorized the agent participation in the event
- **[AuditEvent.agent.network[x]](/auditevent-definitions#AuditEvent.agent.network%5Bx%5D)** [0..1]: Reference([Endpoint](/Endpoint)), [uri](/uri), [string](/string) This agent network location for the activity
- **[AuditEvent.agent.authorization](/auditevent-definitions#AuditEvent.agent.authorization)** [0..*]: [CodeableConcept](/CodeableConcept) example:[v3-PurposeOfUse](/valueset-v3-PurposeOfUse) Allowable authorization for this agent
- **[AuditEvent.source](/auditevent-definitions#AuditEvent.source)** [1..1]: [BackboneElement](/BackboneElement) Audit Event Reporter
- **[AuditEvent.source.site](/auditevent-definitions#AuditEvent.source.site)** [0..1]: Reference([Location](/Location)) Logical source location within the enterprise
- **[AuditEvent.source.observer](/auditevent-definitions#AuditEvent.source.observer)** [1..1]: [Reference(Practitioner](/Reference(Practitioner), [PractitionerRole](/PractitionerRole), [Organization](/Organization), [CareTeam](/CareTeam), [Patient](/Patient), [Device](/Device), [RelatedPerson)](/RelatedPerson)) The identity of source detecting the event
- **[AuditEvent.source.type](/auditevent-definitions#AuditEvent.source.type)** [0..*]: [CodeableConcept](/CodeableConcept) preferred:[security-source-type](/valueset-security-source-type) The type of source where event originated
- **[AuditEvent.entity](/auditevent-definitions#AuditEvent.entity)** [0..*]: [BackboneElement](/BackboneElement) Data or objects used
- **[AuditEvent.entity.what](/auditevent-definitions#AuditEvent.entity.what)** [0..1]: Reference([Resource](/Resource)) Specific instance of resource
- **[AuditEvent.entity.role](/auditevent-definitions#AuditEvent.entity.role)** [0..1]: [CodeableConcept](/CodeableConcept) example:[object-role-example](/valueset-object-role-example) What role the entity played
- **[AuditEvent.entity.securityLabel](/auditevent-definitions#AuditEvent.entity.securityLabel)** [0..*]: [CodeableConcept](/CodeableConcept) example:[security-label-example](/valueset-security-label-example) Security labels on the entity
- **[AuditEvent.entity.description](/auditevent-definitions#AuditEvent.entity.description)** [0..1]: [string](/string) Descriptive text
- **[AuditEvent.entity.query](/auditevent-definitions#AuditEvent.entity.query)** [0..1]: [base64Binary](/base64Binary) Query parameters
- **[AuditEvent.entity.detail](/auditevent-definitions#AuditEvent.entity.detail)** [0..*]: [BackboneElement](/BackboneElement) Additional Information about the entity
- **[AuditEvent.entity.detail.type](/auditevent-definitions#AuditEvent.entity.detail.type)** [1..1]: [CodeableConcept](/CodeableConcept) example:[audit-entity-detail-type-example](/valueset-audit-entity-detail-type-example) The name of the extra detail property
- **[AuditEvent.entity.detail.value[x]](/auditevent-definitions#AuditEvent.entity.detail.value%5Bx%5D)** [1..1]: [Quantity](/Quantity), [CodeableConcept](/CodeableConcept), [string](/string), [boolean](/boolean), [integer](/integer), [Range](/Range), [Ratio](/Ratio), [time](/time), [dateTime](/dateTime), [Period](/Period), [base64Binary](/base64Binary) Property value
- **[AuditEvent.entity.agent](/auditevent-definitions#AuditEvent.entity.agent)** [0..*]: - Entity is attributed to this agent
## Mappings
- [AuditEvent Mappings](/auditevent-mappings) — 140 mapping entries
## Implementation Guide
### implementationguide-AuditEvent-core.xml
```xml
```
## Resource Packs
### list-AuditEvent-packs.xml
```xml
-
```
## Search Parameters
- [action](/auditevent-search#action) — **token** — Type of action performed during the event — `AuditEvent.action`
- [agent](/auditevent-search#agent) — **reference** — Identifier of who — `AuditEvent.agent.who`
- [agent-role](/auditevent-search#agent-role) — **token** — Agent role in the event — `AuditEvent.agent.role`
- [based-on](/auditevent-search#based-on) — **reference** — Reference to the service request. — `AuditEvent.basedOn`
- [date](/auditevent-search#date) — **date** — Time when the event was recorded — `AuditEvent.recorded`
- [encounter](/auditevent-search#encounter) — **reference** — Encounter related to the activity recorded in the AuditEvent — `AuditEvent.encounter`
- [entity](/auditevent-search#entity) — **reference** — Specific instance of resource — `AuditEvent.entity.what`
- [entity-role](/auditevent-search#entity-role) — **token** — What role the entity played — `AuditEvent.entity.role`
- [outcome](/auditevent-search#outcome) — **token** — Whether the event succeeded or failed — `AuditEvent.outcome.code`
- [patient](/auditevent-search#patient) — **reference** — Where the activity involved patient data — `AuditEvent.patient`
- [policy](/auditevent-search#policy) — **uri** — Policy that authorized event — `AuditEvent.agent.policy`
- [purpose](/auditevent-search#purpose) — **token** — The authorization (purposeOfUse) of the event — `AuditEvent.authorization | AuditEvent.agent.authorization`
- [source](/auditevent-search#source) — **reference** — The identity of source detecting the event — `AuditEvent.source.observer`
- [subtype](/auditevent-search#subtype) — **token** — More specific code for the event — `AuditEvent.subtype`
- [type](/auditevent-search#type) — **token** — Type (category) of event — `AuditEvent.type`
- [entity-desc](/auditevent-search#entity-desc) — **string** — Description of an entity — `AuditEvent.entity.description`
[Full Search Parameters](/auditevent-search)
## Examples
- [auditevent-example](/auditevent-example-auditevent-example) — auditevent-example
- [auditevent-example-advanced-create](/auditevent-example-auditevent-example-advanced-create) — auditevent-example-advanced-create
- [auditevent-example-breakglass-start](/auditevent-example-auditevent-example-breakglass-start) — auditevent-example-breakglass-start
- [auditevent-example-consent-authz](/auditevent-example-auditevent-example-consent-authz) — auditevent-example-consent-authz
- [auditevent-example-disclosure](/auditevent-example-auditevent-example-disclosure) — auditevent-example-disclosure
- [auditevent-example-error](/auditevent-example-auditevent-example-error) — auditevent-example-error
- [auditevent-examples-header](/auditevent-example-auditevent-examples-header) — auditevent-examples-header
- [example](/auditevent-example-example) — auditevent-example — General AuditEvent Example
- [example-advanced-create](/auditevent-example-example-advanced-create) — auditevent-example-advanced-create — An AuditEvent recording a create of a List resource for a given Patient, Encounter, and CarePlan.
- [example-breakglass-start](/auditevent-example-example-breakglass-start) — auditevent-example-breakglass-start — Record that a Break-Glass event has started
- [example-consent-permit-authz](/auditevent-example-example-consent-permit-authz) — auditevent-example-consent-authz — An AuditEvent recording a 'permit' authorization decision by a Consent Decision Service, based on a Consent resource (C1) filed by a patient (P1), in response to a request by an organization (Org1) for the purpose of treatment (TREAT).
- [example-disclosure](/auditevent-example-example-disclosure) — auditevent-example-disclosure — Accounting of a Disclosure
- [example-error](/auditevent-example-example-error) — auditevent-example-error — Audit of a transaction that was failed resulting in OperationOutcome
- [example-login](/auditevent-example-example-login) — audit-event-example-login — Login example
- [example-logout](/auditevent-example-example-logout) — audit-event-example-logout — Logout example
- [example-media](/auditevent-example-example-media) — audit-event-example-media — Export of DocumentReference to Media
- [example-pixQuery](/auditevent-example-example-pixQuery) — audit-event-example-pixQuery — Converted ATNA message from a PIX query
- [example-rest](/auditevent-example-example-rest) — audit-event-example-vread — RESTful vread Operation
- [example-rest-create-traceID](/auditevent-example-example-rest-create-traceID) — audit-event-example-create-traceID — RESTful create with TraceID
- [example-search](/auditevent-example-example-search) — audit-event-example-search — RESTful search operation
[Full Examples](/auditevent-examples)
## Mapping Exceptions
### auditevent-event-mapping-exceptions.xml
### Divergent Elements
- **Event.basedOn** → **AuditEvent.basedOn**
- missingTypes | reason=More specific to the use-case | pattern=Reference(Request)
- extraTypes | reason=More specific to the use-case
- summary | reason=Not needed | pattern=true
- shortUnmatched | reason=More specific to the use-case | pattern=Fulfills plan, proposal or order | resource=Workflow authorization within which this event occurred
- definitionUnmatched | reason=More specific description | pattern=A plan, proposal or order that is fulfilled in whole or in part by this audit event. | resource=Allows tracing of authorization for the events and tracking whether proposals/recommendations were acted upon.
- **Event.category** → **AuditEvent.type**
- commentsUnmatched | reason=Unknown | pattern=Categorization might be done automatically (inferred by code) or manually by user assertion. The absence of a category may limit the ability to determine when the element should be handled, so strong consideration should be given to how systems will be able to determine category values for legacy data and how data that cannot be categorized will be handled. As well, some categories might not be mutually exclusive, so systems should prepare for multiple declared categories - even within a single category 'axis'.
In general, there should not be a 'strong' binding ('required' or 'extensible') on the category element overall. Instead, the element can be sliced and bindings can be asserted that apply to particular repetitions. | resource=Categorization might be done automatically (inferred by code) or manually by user assertion. The absence of a category MAY limit the ability to determine when the element SHOULD be handled, so strong consideration SHOULD be given to how systems will be able to determine category values for legacy data and how data that cannot be categorized will be handled. As well, some categories might not be mutually exclusive, so systems SHOULD prepare for multiple declared categories - even within a single category 'axis'.
In general, there SHOULD NOT be a 'strong' binding ('required' or 'extensible') on the category element overall. Instead, the element can be sliced and bindings can be asserted that apply to particular repetitions.
- **Event.code** → **AuditEvent.subtype**
- shortUnmatched | reason=More specific to the use-case | pattern=What service was done | resource=Specific type of event
- definitionUnmatched | reason=More specific to the use-case | pattern=A code that identifies the specific service or action that was or is being performed. | resource=Describes what happened. The most specific codes for the event.
- **Event.subject** → **AuditEvent.patient**
- missingTypes | reason=Specific to Patient only | pattern=Reference(Group)
- shortUnmatched | reason=More specific to the use-case | pattern=Individual service was done for/to | resource=The patient is the subject of the data used/created/updated/deleted during the activity
- definitionUnmatched | reason=More specific to the use-case | pattern=The individual or set of individuals the action is being or was performed on. | resource=The patient element is available to enable deterministic tracking of activities that involve the patient as the subject of the data used in an activity.
- requirementsUnmatched | reason=Unknown | pattern=Links the audit event to the Patient context. May also affect access control. | resource=When the .patient is populated it SHALL be accurate to the subject of the used data. The .patient SHALL NOT be populated when the used data used/created/updated/deleted (.entity) by the activity does not involve a subject. Note that when the patient is an agent, they will be recorded as an agent. When the Patient resource is Created, Updated, or Deleted it will be recorded as an entity. May also affect access control.
- **Event.encounter** → **AuditEvent.encounter**
- summary | reason=Not needed | pattern=true
- shortUnmatched | reason=More specific description | pattern=Encounter the audit event is part of | resource=Encounter within which this event occurred or which the event is tightly associated
- definitionUnmatched | reason=Unknown | pattern=The Encounter during which this audit event was created or to which the creation of this record is tightly associated. | resource=This will typically be the encounter the event occurred, but some events MAY be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission lab tests).
- commentsUnmatched | reason=Unknown | pattern=This will typically be the encounter the audit event was created during, but some audit events may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission lab tests). | resource=This will typically be the encounter the audit event was created during, but some audit events MAY be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission lab tests).
- **Event.occurrence[x]** → **AuditEvent.occurred[x]**
- missingTypes | reason=not applicable | pattern=Timing
- summary | reason=Not needed | pattern=true
- shortUnmatched | reason=More specific description | pattern=When audit event occurred/is occurring | resource=When the activity occurred
- definitionUnmatched | reason=More specific description | pattern=The date, period or timing when the audit event did occur or is occurring. | resource=The time or period during which the activity occurred.
- commentsUnmatched | reason=Unknown | pattern=This indicates when the activity actually occurred or is occurring, not when it was asked/requested/ordered to occur. For the latter, look at the occurence element of the Request this {{event}} is "basedOn". The status code allows differentiation of whether the timing reflects a historic event or an ongoing event. Ongoing events should not include an upper bound in the Period or Timing.bounds.
. | resource=The time or period can be a little arbitrary; where possible, the time SHOULD correspond to human assessment of the activity time.
- **Event.performer** → **AuditEvent.agent**
- extraTypes | reason=Needed by use-case
- shortUnmatched | reason=More specific description | pattern=Who performed audit event and what they did | resource=Actor involved in the event
- definitionUnmatched | reason=More specific description | pattern=Indicates who or what performed the audit event and how they were involved. | resource=An actor taking an active role in the event or activity that is logged.
- **Event.performer.function** → **AuditEvent.agent.type**
- summary | reason=Not needed | pattern=true
- shortUnmatched | reason=More specific description | pattern=Type of performance | resource=How agent participated
- definitionUnmatched | reason=More specific description | pattern=Distinguishes the type of involvement of the performer in the audit event.. | resource=The Functional Role of the user when performing the event.
- requirementsUnmatched | reason=More specific description | pattern=Allows disambiguation of the types of involvement of different performers. | resource=Functional roles reflect functional aspects of relationships between entities. Functional roles are bound to the realization/performance of acts, where actions might be concatenated to an activity or even to a process. This element will hold the functional role that the agent played in the activity that is the focus of this Provenance. Where an agent played multiple functional roles, they will be listed as multiple .agent elements representing each functional participation. See ISO 21298:2018 - Health Informatics - Functional and structural roles, and ISO 22600-2:2014 - Health Informatics - Privilege Management and Access Control - Part 2: formal models.
- **Event.performer.actor** → **AuditEvent.agent.who**
- extraTypes | reason=Unknown
- shortUnmatched | reason=More specific description | pattern=Who performed audit event | resource=Identifier of who
- definitionUnmatched | reason=More specific description | pattern=Indicates who or what performed the audit event. | resource=Reference to who this agent is that was involved in the event.
- **Event.location** → **AuditEvent.agent.location**
- summary | reason=Not needed | pattern=true
- shortUnmatched | reason=More specific description | pattern=Where audit event occurred | resource=The agent location when the event occurred
- definitionUnmatched | reason=More specific description | pattern=The principal physical location where the audit event was performed. | resource=Where the agent location is known, the agent location when the event occurred.
- requirementsUnmatched | reason=More specific description | pattern=Ties the event to where the records are likely kept and provides context around the event occurrence (e.g. if it occurred inside or outside a dedicated healthcare setting).
- **Event.reason** → **AuditEvent.authorization**
- missingTypes | reason=Unknown | pattern=CodeableReference(Condition, Observation, DiagnosticReport, DocumentReference)
- extraTypes | reason=Use-Case need
- shortUnmatched | reason=Use-Case need | pattern=Why was audit event performed? | resource=Authorization related to the event
- definitionUnmatched | reason=Use-Case need | pattern=Describes why the audit event occurred in coded or textual form or Indicates another resource whose existence justifies this audit event. | resource=The authorization (e.g., PurposeOfUse) that was used during the event being recorded.
- commentsUnmatched | reason=More specific description | pattern=Textual reasons can be captured using reasonCode.text. | resource=Use AuditEvent.agent.authorization when you know that it is specific to the agent, otherwise use AuditEvent.authorization. For example, during a machine-to-machine transfer it might not be obvious to the audit system who caused the event, but it does know why.
### Unmapped Elements
- **Event.partOf** — Not relevant for this resource
- **Event.reported** — Not relevant for this resource
- **Event.relevantHistory** — Not relevant for this resource
- **Event.status** — Not relevant for this resource
- **Event.statusReason** — Not relevant for this resource
- **Event.note** — Not relevant for this resource
- **Event.recorded** — Not relevant for this resource
- **Event.product** — Not relevant for this resource
- **Event.identifier** — Not relevant for this resource
- **Event.researchStudy** — Not relevant for this resource
### auditevent-fivews-mapping-exceptions.xml
### Divergent Elements
- **FiveWs.what[x]** → **AuditEvent.subtype**
- **FiveWs.what[x]** → **AuditEvent.outcome.detail**
- **FiveWs.what[x]** → **AuditEvent.entity**
- **FiveWs.context** → **AuditEvent.entity.securityLabel**
- **FiveWs.context** → **AuditEvent.entity.detail**
### Unmapped Elements
- **FiveWs.author** — Unknown
- **FiveWs.actor** — Unknown
- **FiveWs.cause** — Unknown
- **FiveWs.version** — Not relevant for this resource
- **FiveWs.init** — Not relevant for this resource
- **FiveWs.identifier** — Not relevant for this resource
- **FiveWs.source** — Unknown
- **FiveWs.grade** — Not relevant for this resource
- **FiveWs.status** — Not relevant for this resource
- **FiveWs.planned** — Not relevant for this resource