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 (PHRS FM) Release 2, which will incorporate the Record Infrastructure Section.)
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.”
Record Lifecycle Events
Originate/Retain
2
Amend
3
Translate/
Transform
4
Attest
5
6
Access/View
Output/Report
7
Disclose
8
Transmit
9
Receive/Retain
10
11
De-Identify
Pseudonymize
12
Re-Identify
13
Extract
14
Archive
15
16
Restore
Destroy/Delete
17
Deprecate
18
Re-Activate
19
20
21
22
Merge
Unmerge
Link
Unlink
23
Add Legal Hold
24
25
26
27
Remove Legal
Hold
Verify
Encrypt
Decrypt
Content is originated and retained – often during the course of
an Action itself – to document the Action and its context
Content is modified (from its original or previously retained state)
– typically upon conclusion of an Action, to correct, update or
complete content
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
Content is attested for accuracy and completeness – typically
during/after conclusion of an Action
Content is viewed or accessed
Content is output or reported
Content is disclosed according to organizational policy and/or
jurisdictional law
Content is transmitted – typically to an external entity or system
Content is received and retained – typically from an external
entity or system
Content is transformed into de-identified version
Content is transformed into an pseudomynized version
Content is re-identified from a previously pseudonmynized
version
Content is extracted to render subsets, derivations, summaries
or aggregations
Are archived – typically to off-line (less readily available) storage
media
Are restored from archive
Are destroyed or identified as missing
Are deprecated if found to be improperly identified or otherwise
invalid
Are made active again after being previously Destroyed/Deleted
or Deprecated
Are merged together
Are unmerged from previous merge
Are linked together
Are unlinked from previous linkage
Are marked (and held in an unaltered state) for purposes of a
legal hold (typically as the result of court or legal action)
Are released from legal hold (previously marked and held in
unaltered state)
Content is verified for accuracy, completeness
Content is encoded in a cipher or code
Content is decoded from a cipher or code
CRUDE = Create, Read, Update, Delete, Execute
C
X
X
U
X
X
U
X
X
U
X
X
R
X
X
X
X
X
X
X
C
X
X
U
U
X
X
X
X
U
X
X
U
X
X
U
X
U
D
X
X
X
X
U
X
X
U
X
U
U
U
U
X
X
X
X
X
X
X
X
U
X
X
U
X
X
U
U
U
X
X
X
X
Provenance
1
Occurs when Record Entry(ies)…
FHIR
Resources
Security
Event
Record Entry
Lifecycle Event
(From ISO/HL7 10781 EHR-S Functional Model R2
• RI – Record Infrastructure)
• RI.1 – Record Lifecycle and Lifespan
CRUDE
Sec RI.1.1.x
The following Table describes each Record Lifecycle Event and the FHIR resources used to capture related
metadata:
Record Lifecycle Event Metadata in FHIR Resources
The following table shows the FHIR Resources and Attributes instantiated – as applicable event, provenance
and evidentiary metadata – at each Record Lifecycle Event.
Lifecycle Event
Metadata
WHO
Organization
FHIR Resource
Resource Attribute(s)
Provenance
signature : string 0..*
role : Coding 1..1 « ProvenanceAgentRole+ »
type : Coding 1..1 « ProvenanceAgentType+ »
reference : uri 1..1
signature : string 0..*
role : code 1..1 « ProvenanceEntityRole »
type : Coding 1..1 « ProvenanceEntityType+ »
reference : uri 1..1
role : CodeableConcept 0..* « DICOMRoleId+ »
reference :
Resource(Organization|Practitioner|Patient|Device)
0..1
requester : Boolean 1..1
Provenance.Agent : 0..*
Provenance
Provenance.Agent : 0..*
Patient
SecurityEvent.Participant : 1..*
Action - Performer
TBD
Provenance
Provenance.Agent : 0..*
Record - Author/User
SecurityEvent.Participant : 1..*
Provenance
Provenance.Agent : 0..*
Record - System/Device
SecurityEvent.Participant : 1..*
WHAT
Action - Taken
TBD
SecurityEvent.Event : 1..1
Record - Lifecyle Event
SecurityEvent.Object : 0..*
WHEN
Action - Date/Time
Record - Date/Time
Action - Duration/
Elapsed Time
signature : string 0..*
role : Coding 1..1 « ProvenanceAgentRole+ »
type : Coding 1..1 « ProvenanceAgentType+ »
reference : uri 1..1
role : CodeableConcept 0..* « DICOMRoleId+ »
reference : Resource(Practitioner|Patient|Device) 0..1
userId : string 0..1
requester : Boolean 1..1
signature : string 0..*
role : Coding 1..1 « ProvenanceAgentRole+ »
type : Coding 1..1 « ProvenanceAgentType+ »
reference : uri 1..1
role : CodeableConcept 0..* « DICOMRoleId+ »
reference : Resource(Practitioner|Patient|Device) 0..1
userId : string 0..1
requester : Boolean 1..1
TBD
Provenance
SecurityEvent.Event : 1..1
TBD
type : CodeableConcept 1..1 « SecurityEventType+ »
subtype : CodeableConcept 0..* «
SecurityEventSubType+ »
action : code 0..1 « SecurityEventAction »
policy : uri 0..*
identifier : Identifier 0..1
reference : Resource(Any) 0..1
type : code 0..1 « SecurityEventObjectType »
role : code 0..1 « SecurityEventObjectRole »
lifecycle : code 0..1 « SecurityEventObjectLifecycle »
recorded : instant 1..1
dateTime : instant 1..1
Lifecycle Event
Metadata
WHERE
Action - Physical
Location
FHIR Resource
TBD
Provenance
Record - Network
Address
WHY
Action - Reason,
Rationale, Purpose
Record - Reason,
Rationale, Purpose
SecurityEvent.Participant.Network
Record Entry Content
ID(s): data, docs,
artifacts
Corresponding/linked
Record Entry(ies)
Amendment/Translation
Sequence
Pointer to Pre Event
Entry, if chained
Provenance
reason : CodeableConcept 0..1
policy : uri 0..*
reason : CodeableConcept 0..1
signature : string 0..*
SecurityEvent.Object : 0..*
identifier : Identifier 0..1
reference : Resource(Any) 0..1
SecurityEvent.Object : 0..*
one for each Content item
identifier : Identifier 0..1
reference : Resource(Any) 0..1
SecurityEvent.Object : 0..*
one for each linked Record Entry
identifier : Identifier 0..1
reference : Resource(Any) 0..1
SecurityEvent.Object : 0..*
lifecycle : code 0..1 « SecurityEventObjectLifecycle »
SecurityEvent.Object : 0..*
one to previous instance
identifier : Identifier 0..1
reference : Resource(Any) 0..1
identifier : Identifier 0..1
reference : Resource(Any) 0..1
type : code 0..1 « SecurityEventObjectType »
role : code 0..1 « SecurityEventObjectRole »
lifecycle : code 0..1 « SecurityEventObjectLifecycle »,
where lifecycle = “disclosure”
role : CodeableConcept 0..* « DICOMRoleId+ » [for
role-based permissions]
reference : Resource(Practitioner|Patient|Device) 0..1
userId : string 0..1 [for user-based permissions]
sensitivity : code 0..1
«SecurityEvent.object.sensitivity »
identifier : Identifier 0..1
reference : Resource(Any) 0..1
type : code 0..1 « SecurityEventObjectType »
role : CodeableConcept 0..* « DICOMRoleId+ »
reference : Resource(Practitioner|Patient|Device) 0..1
userId : string 0..1
Source of Copied
Content (e.g.,
copy/paste template)
SecurityEvent.Object : 0..*
one for each source
Event is known
Disclosure
SecurityEvent.Object : 0..*
Record Entry
Permissions
location : Resource(Location) 0..1
identifier : string 0..1
type : code 0..1 «
SecurityEventParticipantNetworkType »
TBD
SecurityEvent.Event : 1..1
Additional Evidentiary Metadata
Provenance
Digital Signature(s)
<< Signature Resource – TBD>>
Record Entry ID
Resource Attribute(s)
SecurityEvent.Participant : 1..*
one for each participant
SecurityEvent.Object : 0..*
Event Transaction
Entries
SecurityEvent.Object : 0..*
one for each Record Entry
Identifier/Version of
Translation Tools
SecurityEvent.Participant : 1..*
one for each tool