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, 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 relevant event and thus would record an Audit Event, such as a trusted intermediary.
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
– Manipulation of data that exposes the data to users.
The content of an Audit Event is intended for use by security system administrators, security and privacy information managers, and records management personnel. This content is not intended to be accessible or used directly by other healthcare users, such as providers or patients, although reports generated from the raw data would be useful. An example is a patient-centric accounting of disclosures or an access report. Servers that provide support for Audit Event resources would not generally accept update or delete operations on the resources, as this would compromise the integrity of the audit record. Access to the Audit Event would typically be limited to security, privacy, or other system administration purposes.
Relationship of Audit Event 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 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 Audit Event target resource.
The audit event is based on the IHE-ATNA (Integrating the Healthcare Enterprise – Audit Trail and Node Authentication) Audit record definitions, originally from RFC 3881, and now managed by DICOM. This resource is managed collaboratively between HL7, DICOM, and IHE. The primary purpose of this resource is the maintenance of security audit log information. However, it can also be used for any audit logging needs and simple event-based notification.
Fast Healthcare Interoperability Resources (FHIR) is a draft standard describing data formats and elements (known as “resources”) and an application programming interface (API) for exchanging electronic health records. The standard was created by the Health Level Seven International (HL7) health-care standards organization.
Its goal is to facilitate interoperation between legacy healthcare systems, to make it easy to provide healthcare information to healthcare providers and individuals on a wide variety of devices from computers to tablets to cell phones, and to allow third-party application developers to provide medical applications which can be easily integrated into existing systems.
FHIR provides an alternative to document-centric approaches by directly exposing discrete data elements as services. For example, basic elements of healthcare like patients, admissions, diagnostic reports and medications can each be retrieved and manipulated via their own resource URLs (Uniform Resource Locators). FHIR was supported at an American Medical Informatics Association meeting by many EHR (Electronic Health Record) vendors which value its open and extensible nature.