Release 4
FHIR InfrastructureWork Group Maturity Level: 1 Ballot Status:Draft
EHR Work GroupMaturity Level: 1Ballot Status: Trial Use

This implementation guide describes the expected capabilities for an Electronic Health Record System (EHR-S) that intends to adhere to the ISO/HL7 10781 Electronic Health Record System Functional Model Release 2 which covers the logging of record lifecycle events. This implementation guide consists of three parts:

  • A Profile on the Provenance resource describing the information that should be retained for events involving the creation or updating of electronic health records
  • A Profile on the AuditEvent resource describing the information that should be retained for events involving the access or any other manipulation of electronic health records
  • A Conformance Statement which describes the operations an EHR system claiming conformance to this implementation guide must support.

For the purposes of this implementation guide, "must support" means that the system must be capable of capturing and recording those data elements which are so-marked.

This Implementation Guide offers a methodology to support trusted electronic health record (EHR) management using HL7 Fast Health Interoperable Resources (FHIR). This approach is based on the Record Infrastructure Section of ISO/HL7 10781 Electronic Health Record System Functional Model (EHR-S FM) Release 2 and ISO 21089 Trusted End-to-End Information Flows. ISO 10781 was published in 2014 and contains 24 lifecycle events, matching the first 24 in this IG. ISO 21089 has passed ISO Technical Specification ballot and is to be published in 2017 and contains 27 lifecycle events, matching all those in this IG. (This IG also intended applicable to upcoming ISO/HL7 16527 Personal Health Record System Functional Model (PHR-S FM) Release 2, which will incorporate the Record Infrastructure Section.)

From EHR-S FM, Record Infrastructure, Section RI.1, Record Lifecycle and Lifespan:

"Actions are taken to support patient health. Actions are taken in provision of healthcare to individuals. Actions are taken as the result of rules-based EHR System algorithms. Actors (i.e., patients, providers, users, systems) take Actions. (Actions broadly encompass tasks, acts, procedures or services performed or provided.)

"The EHR System captures Actions taken and creates corresponding Record Entries. Record Entries provide persistent evidence of Action occurrence, context, disposition, facts, findings and observations. From the point of Record Entry origination to the end of its lifespan, the EHR System manages each Entry consistent with and according to scope of practice, organizational policy, and jurisdictional law. In support of individual health and in provision of healthcare to individuals, Actors perform Actions and Actions have corresponding Entries in the EHR Record, (i.e., Action instances are documented by Record Entry instances). Record Entries may be captured during the course of the Action or sometime thereafter. The Actor (author/source) of the Record Entry may be the same as an Actor performing the Action or not...

"Actions have associated metadata (e.g., who, what, when, where, why, how, under what conditions, in what context). The corresponding Record Entry captures this metadata along with other Action and Record Entry related information.

"Each Record Entry also includes its own provenance metadata such as who (authoring Actor) and when (documented). Record Entries may be encapsulated to bind Actor (individual, organization, and/or system) signatures to data and metadata content and data/time of occurrence. Actions and related Record Entries capture a chronology of patient health and healthcare and also a chronology of operations and services provided in/by a healthcare enterprise. Record Entries reflect changes in health information from the time it was created, to the time it was amended, sent, received, etc. In this manner, each Record Entry serves as persistent evidence of an Action taken, enabling providers to maintain comprehensive information that may be needed for legal, [clinical,] business, and disclosure purposes. To satisfy these purposes, Record Entries must also be retained and persisted without alteration. Record Entries have both a lifecycle and a lifespan. Lifecycle Events include originate, retain, amend, verify, attest, access/view, de-identify, transmit/receive, and more. Lifecycle Events occur at various points in a Record Entry lifespan, always starting with a point of origination and retention (i.e., when the Entry is first created and stored).

"A Record Entry may have a pre and post Event state if content is modified. In this case, the original Record Entry is preserved (with signature binding) and a new Entry is created (with new signature binding). A Record Entry contains data and metadata, in multiple formats, following various conventions and standards. Included data may be tagged, and/or delimited, structured (concise, encoded, computable), or unstructured (free form, non-computable). Data may be encoded as text, document, images, audio, waveforms, in ASCII, binary or other encoding."

EHR, PHR and other Systems, designed to follow ISO/HL7 10781 and ISO 21089 record management methodology and incorporate FHIR resources natively, will create Record Entries with one or more FHIR resource instances. These FHIR resources will be bound to an AuditEvent resource instance and, in the case where content is new or updated, a Provenance resource instance in the Record Entry.

As described above, Record Entries have a lifespan and may have lifecycle events (RLEs) occurring during that lifespan. Following is the current list of RLEs:

Sec RI.1.1.x Record Entry Lifecycle Event

From ISO/HL7 10781 EHR-S Functional Model R2
• RI - Record Infrastructure
• RI.1 - Record Lifecycle and Lifespan

Occurs when an Agent...

1 Originate/Retain Causes the system to: a) initiate capture of potential record content, and b) incorporate that content into the storage considered a permanent part of the health record
2 Update/Amend Makes any change to record entry content currently residing in storage considered permanent (persistent)
3 Transform/Translate Causes the system to change the form, language or code system used to represent record entry content
4 Attest Causes the system to capture the agent’s digital signature (or equivalent indication) during formal validation of record entry content
5 Access/View Causes the system to obtain and open a record entry for inspection or review
6 Output/Report Causes the system to produce and deliver record entry content in a particular form and manner
7 Disclose Causes the system to release, transfer, provision access to, or otherwise divulge record entry content
8 Transmit Causes the system to send record entry content from one (EHR/PHR/other) system to another
9 Receive/Retain Causes the system to: a) initiate capture of data content from elsewhere, and b) incorporate that content into the storage considered a permanent part of the health record
10 De-Identify Causes the system to scrub record entry content to reduce the association between a set of identifying data and the data subject in a way that might or might not be reversible
11 Pseudonymize v
12 Re-Identify Causes the system to restore information to data that allows identification of information source and/or information subject
13 Extract Causes the system to selectively pull out a subset of record entry content, based on explicit criteria
14 Archive Causes the system to create and move archive artifacts containing record entry content, typically to long-term offline storage
15 Restore Causes the system to recreate record entries and their content from a previous created archive artifact
16 Destroy/Delete Causes the system to permanently erase record entry content from the system
17 Deprecate Causes the system to tag record entry(ies) as obsolete, erroneous or untrustworthy, to warn against its future use
18 Re-Activate Causes the system to recreate or restore full status to record entries previously deleted or deprecated
19 Merge Causes the system to combine or join content from two or more record entries, resulting in a single logical record entry
20 Unmerge Causes the system to reverse a previous record entry merge operation, rendering them separate again
21 Link Causes the system to connect related record entries
22 Unlink Causes the system to disconnect two or more record entries previously connected, rendering them separate (disconnected) again
23 Add Legal Hold Causes the system to tag or otherwise indicate special access management and suspension of record entry deletion/destruction, if deemed relevant to a lawsuit or which are reasonably anticipated to be relevant or to fulfill organizational policy under the legal doctrine of "duty to preserve"
24 Remove Legal Hold Causes the system to remove a tag or other cues for special access management had required to fulfill organizational policy under the legal doctrine of "duty to preserve"
25 Verify Causes the system to confirm compliance of data or data objects with regulations, requirements, specifications, or other imposed conditions based on organizational policy
26 Encrypt Causes the system to encode record entry content in a cipher
27 Decrypt Causes the system to decode record entry content from a cipher

CRUDE = Create, Read, Update, Delete, Execute. Record Lifecycle Events (RLEs) are specializations of basic CRUDE events for purposes of health data/record management end-to-end. End-to-end means: 1) for the duration of data/record lifespan within the source EHR, PHR or other system, and 2) following the path of data/record exchange system by system downstream to the ultimate point of access/use.

FHIR resources – when captured natively in the source EHR, PHR or other system Record Entries – include resources resulting from the Action taken (e.g., register patient, order medication, take progress note). Plus, all RLEs depend on the AuditEvent resource to capture basic metadata. Plus, all RLEs which Create or Update resource content depend on the Provenance resource to capture content-related metadata. The following table shows how RLEs relate to CRUDE events. Some RLEs create separate new artifacts as shown.

RLEs in blue are included in FHIR Connectathon Tracks and are currently limited to basic C, R, and U events.

Sec RI.1.1.x Record Lifecycle Event FHIR Resources
in Record Entry
CRUDE - At each RLE,
per Record Entry instance
C - Create
R - Read
U - Update
D - Delete
E - Execute
New Artifacts
Created at RLE
Audit
Event
Prove-
nance
Action Related
1 Originate/Retain 1..1 1..1 1..* C New Instance(s) ---
2 Update/Amend 1..1 1..1 1..* C or U Instance(s) ---
3 Transform/Translate 1..1 1..1a 1..* --- C New transformed/ translated artifact
4 Attest 1..1 1..1 1..* C or U Instance(s)
(Provenance incl. Signature)
---
5 Access/View 1..1 1..1a 1..* R Instance(s) C New extract artifact
6 Output/Report 1..1 1..1a 1..* --- C New output/report artifact
7 Disclose 1..1 1..1a 1..* --- C New disclosure artifact
8 Transmit 1..1 1..1a 1..* --- C New transmittal artifact
9 Receive/Retain 1..1 1..1 1..* C New Instance(s) ---
10 De-Identify 1..1 1..1a 1..* --- C New de-identified artifact
11 Pseudonymize 1..1 1..1a 1..* --- C New pseudomynized artifact
12 Re-Identify 1..1 1..1b 1..* C or U Instance(s) Note b ---
13 Extract 1..1 1..1a 1..* --- C New extract artifact
14 Archive 1..1 1..1a 1..* --- C New archive artifact
15 Restore 1..1 1..1b 1..* C or U Instance(s) - Note b ---
16 Destroy/Delete 1..1 0..0 1..* D Instance(s) ---
17 Deprecate 1..1 1..1b 1..* C or U Instance(s) - Note b ---
18 Re-Activate 1..1 1..1b 1..* C or U Instance(s) - Note b ---
19 Merge 1..1 1..1b 1..* C or U Instance(s) - Note b ---
20 Unmerge 1..1 1..1b 1..* C or U Instance(s) - Note b ---
21 Link 1..1 1..1b 1..* C or U Instance(s) - Note b ---
22 Unlink 1..1 1..1b 1..* C or U Instance(s) - Note b ---
23 Add Legal Hold 1..1 1..1b 1..* C or U Instance(s) - Note b ---
24 Remove Legal Hold 1..1 1..1b 1..* C or U Instance(s) - Note b ---
25 Verify 1..1 1..1b 1..* C or U Instance(s) - Note b ---
26 Encrypt 1..1 1..1a 1..* --- C New encrypted artifact
27 Decrypt 1..1 1..1b 1..* C or U Instance(s) - Note b ---

a: RLE typically Creates a new artifact (see last column) and the (one) Provenance Resource is bound to this artifact (not Record Entry instance(s)).
b: Depending on system design, RLE may Create or Update Record Entry instance(s) and thus the (one) Provenance Resource is bound to these instance(s).

The following table shows the FHIR Resources and applicable Attributes captured - event, provenance and evidentiary metadata - at each occurrence of a Record Lifecycle Event. W5 metadata includes who, what, when, where, why attributes as shown below. W5 metadata elements are required.

Record Lifecycle Event Metadata FHIR Resource Resource Element(s)
WHO
Organization Provenance signature : Signature 0..*
Provenance.agent : 0..* role : Coding 1..1 « ProvenanceAgentRole+ »
actor : Reference(Organization) 0..1
userId : Identifier 0..1
AuditEvent.agent : 1..* role : CodeableConcept 0..* « ActiveParticipantRoleCode »
reference : Reference(Organization) 0..1
userId : Identifier 0..1
Patient Provenance signature : Signature 0..*
Provenance.agent : 0..* role : Coding 1..1 « ProvenanceAgentRole+ »
actor : Reference(Patient) 0..1
userId : Identifier 0..1
AuditEvent.agent : 1..* role : CodeableConcept 0..* « ActiveParticipantRoleCode »
reference : Reference(Patient) 0..1
userId : Identifier 0..1

Action - Performer

Record - Author/User

Provenance signature : Signature 0..*
Provenance.agent : 0..* role : Coding 1..1 « ProvenanceAgentRole+ »
actor : Reference (Organization|Practitioner| Patient|Device|RelatedPerson) 0..1
userId : Identifier 0..1
AuditEvent.agent : 1..* role : CodeableConcept 0..* « ActiveParticipantRoleCode »
reference : Reference(Organization|Practitioner| Patient|Device|RelatedPerson) 0..1
userId : Identifier 0..1
Record - System/Device Provenance signature : Signature 0..*
Provenance.agent : 0..* role : Coding 1..1 « ProvenanceAgentRole+ »
actor :Reference(Device) 0..1
userId : Identifier 0..1
AuditEvent.agent : 1..* role : CodeableConcept 0..* « ActiveParticipantRoleCode »
reference : Reference(Device) 0..1
userId : Identifier 0..1
WHAT
Action - Taken Provenance Activity : Coding 0..1 « ProvenanceActivity »
AuditEvent Event : BackboneElement 1..1
Record - Lifecyle Event AuditEvent type : Coding 1..1 « AuditEventType+ »
subtype : Coding 0..1 « AuditEventSubType+ »
action : code 0..1 « AuditEventAction»
AuditEvent.entity : 0..* identifier : Identifier 0..1
reference : Reference(Any) 0..1
type : Coding 0..1 « AuditEventEventType »
role : Coding 0..1 « AuditEventEventRole »
lifecycle : Coding 0..1
WHEN
Action - Date/Time Provenance period : Period 0..1
AuditEvent recorded : instant 1..1
Record - Date/Time Provenance recorded : instant 1..1
AuditEvent recorded : instant 1..1
WHERE
Action - Physical Location Provenance location : Reference(Location) 0..1
AuditEvent.source : 1..1 site : BackboneElement 0..1
identifier : string 1..1
type : Coding 0..* « AuditEventSourceType »
Record - Network Address Provenance location : Reference(Location) 0..1
AuditEvent.agent.network address : BackboneElement 0..1
type : code 0..1 « AuditEventAgentNetworkType »
WHY
Action - Reason, Rationale, Purpose Provenance reason : Coding 0..*
AuditEvent.agent purposeOfUse : Coding 0..* « AuditEventPurposeOfUse »
Record - Reason, Rationale, Purpose Provenance reason : Coding 0..*
policy : uri 0..*
AuditEvent purposeOfEvent : Coding 0..*
Additional Evidentiary Metadata, as applicable
Digital Signature(s) Provenance
one per signature
signature : Signature 0..*
Record Entry ID Provenance Target : Reference(Any) 0..*
AuditEvent.entity : 0..* identifier : Identifier 0..1
reference : Reference(Any) 0..1
Record Entry Content ID(s):
data, docs, artifacts
Provenance Target : Reference(Any) 0..*
Provenance.entity : 0..*
one per Record Entry
role : Coding 0..1 « ProvenanceEntityRole »
type : Coding 0..1 « ProvenanceResourceType »
reference : Reference(Any) 0..1
agent : [see Provenance.agent]
AuditEvent.entity : 0..*
one per Content item
identifier : Identifier 0..1
reference : Reference(Any) 0..1
Corresponding/linked Record Entry(ies) Provenance.entity : 0..*
one per linked Record Entry
role : Coding 0..1 « ProvenanceEntityRole »
type : Coding 0..1 « ProvenanceResourceType »
reference : Reference(Any) 0..1
agent : [see Provenance.agent]
AuditEvent.entity : 0..*
one per linked Record Entry
identifier : Identifier 0..1
reference : Reference(Any) 0..1
Amendment/Translation Sequence Provenance.entity : 0..*
one for each Record Entry in sequence
role : Coding 0..1 « ProvenanceEntityRole »
type : Coding 0..1 « ProvenanceResourceType »
reference : Reference(Any) 0..1
agent : [see Provenance.agent]
AuditEvent.entity : 0..* lifecycle : Coding 0..1
Pointer to Pre Event Entry, if chained Provenance.entity : 0..*
one per previous instance
role : Coding 0..1 « ProvenanceEntityRole »
type : Coding 0..1 « ProvenanceResourceType »
reference : Reference(Any) 0..1
agent : [see Provenance.agent]
AuditEvent.entity : 0..*
one per previous instance
identifier : Identifier 0..1
reference : Reference(Any) 0..1
Source of Copied Content
(e.g. copy/paste template)
Provenance.entity : 0..*
one per source
role : Coding 0..1 « ProvenanceEntityRole »
type : Coding 0..1 « ProvenanceResourceType »
reference : Reference(Any) 0..1
agent : [see Provenance.agent]
AuditEvent.source : 1..1
one per source
site : BackboneElement 0..1
identifier : string 1..1
type : Coding 0..* « AuditEventSourceType »
AuditEvent.entity : 0..*
one per source
identifier : Identifier 0..1
reference : Reference(Any) 0..1
type : Coding 0..1 « AuditEventEventType »
role : Coding 0..1 « AuditEventEventRole »
Event is known Disclosure AuditEvent.entity : 0..* lifecycle : Coding 0..1
where lifecycle = "disclosure"
Record Entry Permissions AuditEvent.agent : 1..*
one per agent
[for role-based permissions]
role : CodeableConcept 0..* « [as specified] »
[for user-based permissions]
reference : Reference(Practitioner|Organization|Device|Patient|RelatedPerson) 0..1
userId : Identifier 0..1
AuditEvent.entity : 0..*
One per agent label
securityLabel : Coding 0..1 « [as specified] »
Event Transaction Entries Provenance.entity : 0..*
one per Record Entry
role : Coding 0..1 « ProvenanceEntityRole »
type : Coding 0..1 « ProvenanceResourceType »
reference : Reference(Any) 0..1
agent : [see Provenance.agent]
AuditEvent.entity : 0..*
one per Record Entry
identifier : Identifier 0..1
reference : Reference(Any) 0..1
type : Coding 0..1 « AuditEventEntityType »
Identifier/Version of Translation Tools Provenance.entity : 0..*
one per translation event
role : Coding 0..1 « ProvenanceEntityRole »
type : Coding 0..1 « ProvenanceResourceType »
reference : Reference(Any) 0..1
agent : [see Provenance.agent]
AuditEvent.agent : 1..*
one per translation event
role : CodeableConcept 0..* « ActiveParticipantRoleCode »
reference : Reference(Device) 0..1
userId : Identifier 0..1

Action = Medication Order

Record Lifecycle Event (RLEs), in sequence: 1) originate/retain, 2) update/amend, 3) attest, 4) access/view...

Note that Record Entries have a pre-lifecycle event state (except for the genesis originate/retain event). Record Entries also have a post-lifecycle event state (except for the terminus destroy/delete event).

Event Sequence Record Lifecycle Event Record Entry Content - including
FHIR Resource Instances
Retaining
without Alteration
1 - Pre Originate/Retain Order --- ---
1 - Post Medication v1
MedicationOrder v1
AuditEvent v1
Provenance v1
---
2 - Pre Update/Amend Order Medication v1
MedicationOrder v1
AuditEvent v1
Provenance v1
All v1 Instances
2 - Post Medication v2
MedicationOrder v2
AuditEvent v2
Provenance v2
All v1 Instances
3 - Pre Attest Order Medication v2
MedicationOrder v2
AuditEvent v2
Provenance v2
All v1/2 Instances
3 - Post Medication v3
MedicationOrder v3
AuditEvent v3
Provenance v3 (with signature )
All v1/2 Instances
4 - Pre Access/View Order Medication v3
MedicationOrder v3
AuditEvent v3
Provenance v3
All v1/2/3 Instances
4 - Post AuditEvent v4 All v1/2/3 Instances
And on...