STU 3 Candidate
This page is part of the FHIR Specification (v1.4.0: STU 3 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
. Page versions: R4 R3 R2
FHIR Infrastructure  Work Group |
Maturity Level: 1 | Ballot Status:Draft |
This implementation guide describes the expected capabilities for an Electronic Health Record System (EHRS) 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:
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. (This is 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 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 anAuditEventresource instance and, in the case where content is new or updated, aProvenanceresource instance in the Record Entry.
As described above, Record Entries have a lifespan and 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 Record Entry(ies) |
|
|
1 |
Originate/Retain |
Content is originated and retained often during the course of an Action itself to document the Action and its context |
|
|
2 |
Update/Amend |
Content is modified (from its original or previously retained state) typically upon conclusion of an Action to correct, update or complete content |
|
|
3 |
Transform/Translate |
Content is transformed/translated typically coded data from one coding/classification scheme to another, also from one human language to another into a new version |
|
|
4 |
Attest |
Content is attested for accuracy and completeness typically during/after conclusion of an Action |
|
|
5 |
Access/View |
Content is viewed or accessed |
|
|
6 |
Output/Report |
Content is output or reported |
|
|
7 |
Disclose |
Content is disclosed according to organizational policy and/or jurisdictional law |
|
|
8 |
Transmit |
Content is transmitted typically to an external entity or system |
|
|
9 |
Receive/Retain |
Content is received and retained typically from an external entity or system |
|
|
10 |
De-Identify |
Content is transformed into de-identified version |
|
|
11 |
Pseudonymize |
Content is transformed into an pseudomynized version |
|
|
12 |
Re-Identify |
Content is re-identified from a previously pseudomynized version |
|
|
13 |
Extract |
Content is extracted to render subsets, derivations, summaries or aggregations |
|
|
14 |
Archive |
Are archived typically to off-line (less readily available) storage media |
|
|
15 |
Restore |
Are restored from previous archive |
|
|
16 |
Destroy/Delete |
Are destroyed or identified as missing |
|
|
17 |
Deprecate |
Are deprecated (e.g., improperly identified or otherwise invalid) |
|
|
18 |
Re-Activate |
Are made active again after previous Destroy/Delete or Deprecate |
|
|
19 |
Merge |
Are merged together |
|
|
20 |
Unmerge |
Are unmerged from previous merge |
|
|
21 |
Link |
Are linked together |
|
|
22 |
Unlink |
Are unlinked from previous linkage |
|
|
23 |
Add Legal Hold |
Are marked (and held in an unaltered state) for purposes of a legal hold (typically as the result of court or legal action) |
|
|
24 |
Remove Legal Hold |
Are released from legal hold (previously marked and held in unaltered state) |
|
|
25 |
Verify |
Content is reviewed and affirmed for accuracy, completeness |
|
|
26 |
Encrypt |
Content is encoded in a cipher |
|
|
27 |
Decrypt |
Content is decoded from a cipher |
CRUDE = Create, Read, Update, Delete, Execute. Record Lifecycle Events 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). Plus, all RLEs depend on the AuditEvent resource to capture basic metadata. Plus, all RLEs whichCreate orUpdate 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 blueare included in FHIR Connectathon and are currently limited to basicC,R, andUevents.
|
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 C reated at RLE |
||
|
Audit Event |
Provenance |
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..1 a |
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..1 a |
1..* |
R Instance(s) |
C New extract artifact |
|
6 |
Output/Report |
1..1 |
1..1 a |
1..* |
--- |
C New output/report artifact |
|
7 |
Disclose |
1..1 |
1..1 a |
1..* |
--- |
C New disclosure artifact |
|
8 |
Transmit |
1..1 |
1..1 a |
1..* |
--- |
C New transmittal artifact |
|
9 |
Receive/Retain |
1..1 |
1..1 |
1..* |
C New Instance(s) |
--- |
|
10 |
De-Identify |
1..1 |
1..1 a |
1..* |
--- |
C New de-identified artifact |
|
11 |
Pseudonymize |
1..1 |
1..1 a |
1..* |
--- |
C New pseudomynized artifact |
|
12 |
Re-Identify |
1..1 |
1..1 b |
1..* |
C or U Instance(s) Note b |
--- |
|
13 |
Extract |
1..1 |
1..1 a |
1..* |
--- |
C New extract artifact |
|
14 |
Archive |
1..1 |
1..1 a |
1..* |
--- |
C New archive artifact |
|
15 |
Restore |
1..1 |
1..1 b |
1..* |
C or U Instance(s) Note b |
--- |
|
16 |
Destroy/Delete |
1..1 |
0..0 |
1..* |
D Instance(s) |
--- |
|
17 |
Deprecate |
1..1 |
1..1 b |
1..* |
C or U Instance(s) Note b |
--- |
|
18 |
Re-Activate |
1..1 |
1..1 b |
1..* |
C or U Instance(s) Note b |
--- |
|
19 |
Merge |
1..1 |
1..1 b |
1..* |
C or U Instance(s) Note b |
--- |
|
20 |
Unmerge |
1..1 |
1..1 b |
1..* |
C or U Instance(s) Note b |
--- |
|
21 |
Link |
1..1 |
1..1 b |
1..* |
C or U Instance(s) Note b |
--- |
|
22 |
Unlink |
1..1 |
1..1 b |
1..* |
C or U Instance(s) Note b |
--- |
|
23 |
Add Legal Hold |
1..1 |
1..1 b |
1..* |
C or U Instance(s) Note b |
--- |
|
24 |
Remove Legal Hold |
1..1 |
1..1 b |
1..* |
C or U Instance(s) Note b |
--- |
|
25 |
Verify |
1..1 |
1..1 b |
1..* |
C or U Instance(s) Note b |
--- |
|
26 |
Encrypt |
1..1 |
1..1 a |
1..* |
--- |
C New encrypted artifact |
|
27 |
Decrypt |
1..1 |
1..1 b |
1..* |
C or U Instance(s) Note b |
--- |
Note a: RLE typicallyCreates a new artifact (see last column) and the (one) Provenance Resource is bound to this artifact (not Record Entry instance(s)).
Note b: Depending on system design, RLE mayCreate orUpdate 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 Attribute(s) |
|
WHO |
||
|
Organization |
Provenance |
signature : Signature 0..* |
|
Provenance.Agent : 0..* |
role : Coding 1..1 « ProvenanceAgentRole+ » actor : Reference (Organization|Practitioner| Patient|Device|RelatedPerson) 0..1 userId : 0..1 Identifier |
|
|
AuditEvent.Participant : 1..* |
role :
CodeableConcept 0..* « DICOMRoleId+ » userId : Identifier 0..1 requester : Boolean 1..1 |
|
|
Patient |
Provenance |
signature : Signature 0..* |
|
Provenance.Agent : 0..* |
role : Coding 1..1 « ProvenanceAgentRole+ » actor : Reference (Organization|Practitioner| Patient|Device|RelatedPerson) 0..1 userId : 0..1 Identifier |
|
|
AuditEvent.Participant : 1..* |
role :
CodeableConcept 0..* « DICOMRoleId+ » userId : Identifier 0..1 requester : Boolean 1..1 |
|
|
Action - Performer |
[See W5 Report for specific resource attribute] |
|
|
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 : 0..1 Identifier |
|
|
AuditEvent.Participant : 1..* |
role :
CodeableConcept 0..* « DICOMRoleId+ » userId : Identifier 0..1 requester : Boolean 1..1 |
|
|
Record - System/Device |
Provenance |
signature : Signature 0..* |
|
Provenance.Agent : 0..* |
role : Coding 1..1 « ProvenanceAgentRole+ » actor : Reference ( Organization|Practitioner| Patient|Device|RelatedPerson) 0..1 userId : 0..1 Identifier |
|
|
AuditEvent.Participant : 1..* |
role : CodeableConcept 0..* « DICOMRoleId+ » reference : Resource(Organization|Practitioner| Patient|Device|RelatedPerson) 0..1 userId : Identifier 0..1 requester : Boolean 1..1 |
|
|
WHAT |
||
|
Action - Taken |
AuditEvent |
Event ; BackboneElement 1..1 |
|
Record - Lifecyle Event |
AuditEvent.Event : 1..1 |
type :
Coding 1..1 « AuditEventType+ » |
|
AuditEvent.Object : 0..* |
identifier
: Identifier 0..1 |
|
|
WHEN |
||
|
Action - Date/Time |
Provenance |
Period : Period 0..1 |
|
Record - Date/Time |
Provenance |
recorded : instant 1..1 |
|
AuditEvent.Event : 1..1 |
dateTime : instant 1..1 |
|
|
WHERE |
||
|
Action - Physical Location |
Provenance |
location : Resource(Location) 0..1 |
|
Record - Network Address |
Provenance |
location : Resource(Location) 0..1 |
|
AuditEvent.Participant.Network |
address :
string 0..1 |
|
|
WHY |
||
|
Action - Reason, Rationale, Purpose |
Provenance |
reason : CodeableConcept 0..1 |
|
Record - Reason, Rationale, Purpose |
Provenance |
reason : CodeableConcept 0..1 |
|
policy : uri 0..* |
||
|
AuditEvent.Event : 1..1 |
purposeOfEvent : Coding 0..* |
|
|
Additional Evidentiary Metadata |
||
|
Digital Signature(s) |
Provenance |
signature : Signature 0..* |
|
Record Entry ID |
AuditEvent.Object : 0..* |
identifier
: Identifier 0..1 |
|
Record Entry Content ID(s): data, docs, artifacts |
AuditEvent.Object : 0..* one for each Content item |
identifier
: Identifier 0..1 |
|
Corresponding/linked Record Entry(ies) |
AuditEvent.Object : 0..* one for each linked Record Entry |
identifier
: Identifier 0..1 |
|
Amendment/Translation Sequence |
AuditEvent.Object : 0..* |
lifecycle : Coding 0..1 [Placeholder TBD] |
|
Pointer to Pre Event Entry, if chained |
AuditEvent.Object : 0..* one to previous instance |
identifier
: Identifier 0..1 |
|
Source of Copied Content (e.g., copy/paste template) |
AuditEvent.Object : 0..* one for each source |
identifier
: Identifier 0..1 |
|
Event is known Disclosure |
AuditEvent.Object : 0..* |
lifecycle : Coding 0..1 [Placeholder TBD] where lifecycle = disclosure |
|
Record Entry Permissions |
AuditEvent.Participant : 1..* one for each participant |
[for role-based permissions] role : CodeableConcept 0..* « [as specified] » [for user-based permissions]
reference
: Resource(Practitioner|Organization|
Device|Patient|RelatedPerson) 0..1 |
|
AuditEvent.Object : 0..* |
securityLabel : Coding 0..1 « [as specified] » |
|
|
Event Transaction Entries |
AuditEvent.Object : 0..* one for each Record Entry |
identifier
: Identifier 0..1 |
|
Identifier/Version of Translation Tools |
AuditEvent.Participant : 1..* one for each tool |
role : CodeableConcept 0..* « DICOMRoleId+ »
reference
: Resource(Practitioner|Organization|
Device|Patient|RelatedPerson) 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 Provenanc e 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 |
|||
© HL7.org 2011+. FHIR STU3 Candidate (v1.4.0-8139) generated on Thu, Mar 31, 2016 08:10+1100. QA Page
Links: Search |
Version History |
Table of Contents |
Compare to DSTU2 |
|
Propose a change