DSTU2 QA Preview

This page is part of the FHIR Specification (v1.0.0: DSTU 2 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

E.0 EHRS Functional Model - Record Lifecycle Events Implementation Guide

This implementation guide describes the expected capabilities for an Electronic Health Record System (EHRS) that intends to adhere to HL7's EHRS functional model covering the logging of record life cycle 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.

E.0 Introduction

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.)

E.0 Actions and Record Entries

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.

E.0 Record Lifecycle Events (RLEs)

As described above, Record Entries have a lifespan and lifecycle events (RLEs) occurring during that lifespan. The list of RLEs is offered below, along with FHIR resources pertinent to each RLE. RLE metadata is captured in the AuditEventresource (for all RLEs) and also aProvenanceresource (for each RLEs where Record Entry content is new or updated). CRUDE = Create, Read, Update, Delete, Execute

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)...

CRUDE

FHIR Resources

in Record Entry

Audit

Event

Prove-nance

Action Related

1

Originate/ Retain

Content is originated and retained - often during the course of an Action itself - to document the Action and its context

C

1

1

1..*

2

Amend/

Update

Content is modified (from its original or previously retained state) - typically upon conclusion of an Action - to correct, update or complete content

U

1

1

1..*

3

Translate/ Transform

Content is amended to include translation of content - typically to transform coded data from one coding/classification scheme to another, also from one human language to another

U

1

1

1..*

4

Attest

Content is attested for accuracy and completeness - typically during/after conclusion of an Action

U

1

1

1..*

5

Access/View

Content is viewed or accessed

R

1

0

1..*

6

Output/Report

Content is output or reported

E

1

1

1..*

7

Disclose

Content is disclosed according to organizational policy and/or jurisdictional law

E

1

1

1..*

8

Transmit

Content is transmitted - typically to an external entity or system

E

1

1

1..*

9

Receive/ Retain

Content is received and retained - typically from an external entity or system

C

1

1

1..*

10

De-Identify

Content is transformed into de-identified version

U

1

1

1..*

11

Pseudonymize

Content is transformed into an pseudomynized version

U

1

1

1..*

12

Re-Identify

Content is re-identified from a previously pseudonmynized version

U

1

1

1..*

13

Extract

Content is extracted to render subsets, derivations, summaries or aggregations

U

1

1

1..*

14

Archive

Are archived - typically to off-line (less readily available) storage media

U

1

0

1..*

15

Restore

Are restored from archive

U

1

1

1..*

16

Destroy/Delete

Are destroyed or identified as missing

D

1

1

1..*

17

Deprecate

Are deprecated (e.g., improperly identified or otherwise invalid)

U

1

1

1..*

18

Re-Activate

Are made active again after being previously Destroyed/Deleted or Deprecated

U

1

0

1..*

19

Merge

Are merged together

U

1

1

1..*

20

Unmerge

Are unmerged from previous merge

U

1

1

1..*

21

Link

Are linked together

U

1

1

1..*

22

Unlink

Are unlinked from previous linkage

U

1

1

1..*

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)

U

1

1

1..*

24

Remove Legal Hold

Are released from legal hold (previously marked and held in unaltered state)

U

1

1

1..*

25

Verify

Content is verified for accuracy, completeness

U

1

1

1..*

26

Encrypt

Content is encoded in a cipher

U

1

0

1..*

27

Decrypt

Content is decoded from a cipher

U

1

0

1..*

E.0 Record Lifecycle Event Metadata Captured in FHIR Resources

The following table shows the FHIR Resources and applicable Attributes captured - event, provenance and evidentiary metadata - at each occurrence of a Record Lifecycle Event.

Record Lifecycle Event Metadata

FHIR Resource

Resource Attribute(s)

WHO

Organization

Provenance

signature : string 0..*

Provenance.Agent : 0..*

role : Coding 1..1 « ProvenanceAgentRole+ »
type : Coding 1..1 « ProvenanceAgentType+ »
reference : uri 1..1

Patient

Provenance

signature : string 0..*

Provenance.Agent : 0..*

role : code 1..1 « ProvenanceEntityRole »
type : Coding 1..1 « ProvenanceEntityType+ »
reference : uri 1..1

AuditEvent.Participant : 1..*

role : CodeableConcept 0..* « DICOMRoleId+ »
reference : Resource(Organization|Practitioner|Patient|Device) 0..1

requester : Boolean 1..1

Action - Performer

TBD

Record - Author/User

Provenance

signature : string 0..*

Provenance.Agent : 0..*

role : Coding 1..1 « ProvenanceAgentRole+ »
type : Coding 1..1 « ProvenanceAgentType+ »
reference : uri 1..1

AuditEvent.Participant : 1..*

role : CodeableConcept 0..* « DICOMRoleId+ »
reference : Resource(Practitioner|Patient|Device) 0..1
userId : string 0..1

requester : Boolean 1..1

Record - System/Device

Provenance

signature : string 0..*

Provenance.Agent : 0..*

role : Coding 1..1 « ProvenanceAgentRole+ »
type : Coding 1..1 « ProvenanceAgentType+ »
reference : uri 1..1

AuditEvent.Participant : 1..*

role : CodeableConcept 0..* « DICOMRoleId+ »
reference : Resource(Practitioner|Patient|Device) 0..1
userId : string 0..1

requester : Boolean 1..1

WHAT

Action - Taken

TBD

Record - Lifecyle Event

AuditEvent.Event : 1..1

type : CodeableConcept 1..1 « AuditEventType+ »
subtype : CodeableConcept 0..* « AuditEventSubType+ »
action : code 0..1 « AuditEventAction »

policy: uri 0..*

AuditEvent.Object : 0..*

identifier : Identifier 0..1
reference : Resource(Any) 0..1
type : code 0..1 « AuditEventObjectType »
role : code 0..1 « AuditEventObjectRole »
lifecycle : code 0..1 « AuditEventObjectLifecycle »

WHEN

Action - Date/Time

TBD

Record - Date/Time

Provenance

recorded : instant 1..1

AuditEvent.Event : 1..1

dateTime : instant 1..1

Action - Duration/ Elapsed Time

TBD

WHERE

Action - Physical Location

TBD

Record - Network Address

Provenance

location : Resource(Location) 0..1

AuditEvent.Participant.Network

identifier : string 0..1
type : code 0..1 « AuditEventParticipantNetworkType »

WHY

Action - Reason, Rationale, Purpose

TBD

Record - Reason, Rationale, Purpose

Provenance

reason : CodeableConcept 0..1

policy : uri 0..*

AuditEvent.Event : 1..1

reason : CodeableConcept 0..1

Additional Evidentiary Metadata

Digital Signature(s)

Provenance

« Signature Resource - TBD»

signature : string 0..*

Record Entry ID

AuditEvent.Object : 0..*

identifier : Identifier 0..1
reference : Resource(Any) 0..1

Record Entry Content ID(s): data, docs, artifacts

AuditEvent.Object : 0..*

one for each Content item

identifier : Identifier 0..1
reference : Resource(Any) 0..1

Corresponding/linked Record Entry(ies)

AuditEvent.Object : 0..*

one for each linked Record Entry

identifier : Identifier 0..1
reference : Resource(Any) 0..1

Amendment/Translation Sequence

AuditEvent.Object : 0..*

lifecycle : code 0..1 « AuditEventObjectLifecycle »

Pointer to Pre Event Entry, if chained

AuditEvent.Object : 0..*

one to previous instance

identifier : Identifier 0..1
reference : Resource(Any) 0..1

Source of Copied Content (e.g., copy/paste template)

AuditEvent.Object : 0..*

one for each source

identifier : Identifier 0..1
reference : Resource(Any) 0..1
type : code 0..1 « AuditEventObjectType »
role : code 0..1 « AuditEventObjectRole »

Event is known Disclosure

AuditEvent.Object : 0..*

lifecycle : code 0..1 « AuditEventObjectLifecycle », where lifecycle = "disclosure"

Record Entry Permissions

AuditEvent.Participant : 1..*

one for each participant

[for role-based permissions]

role : CodeableConcept 0..* « DICOMRoleId+ »

[for user-based permissions]

reference : Resource(Practitioner|Patient|Device) 0..1
userId : string 0..1

AuditEvent.Object : 0..*

sensitivity : code 0..1 «AuditEvent.object.sensitivity »

Event Transaction Entries

AuditEvent.Object : 0..*

one for each Record Entry

identifier : Identifier 0..1
reference : Resource(Any) 0..1
type : code 0..1 « AuditEventObjectType »

Identifier/Version of Translation Tools

AuditEvent.Participant : 1..*

one for each tool

role : CodeableConcept 0..* « DICOMRoleId+ »

reference : Resource(Practitioner|Patient|Device) 0..1
userId : string 0..1

EXAMPLE - Lifecycle Events for a Record Entry

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 bound FHIR Resource Instances

Retaining

without Alteration

1 - Pre

Originate/Retain Order

N/A

N/A

1 - Post

Medication v1

MedicationOrder v1

AuditEvent v1

Provenance v1

N/A

2 - Pre

Update/Amend Order

Medication v1

MedicationOrder v1

AuditEvent v1

Provenance v1

N/A

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

N/A

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

N/A

4 - Post

AuditEvent v4

All v1-3 Instances

And on...