E.0 Introduction 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.)

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 DTS 21089 Trusted End-to-End Information Flows. (This IG is also intended to be 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 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 an

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 resource instance and, in the case where content is new or updated, a Provenance resource instance in the Record Entry. resource instance in the Record Entry.

E.0 Record Lifecycle Events (RLEs) Record Lifecycle Events (RLEs) 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)…

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 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	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	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	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	Content is attested for accuracy and completeness - typically during/after conclusion of an Action
5	Access/View Content is viewed or accessed	Content is viewed or accessed
6	Output/Report Content is output or reported	Content is output or reported
7	Disclose Content is disclosed according to organizational policy and/or jurisdictional law	Content is disclosed according to organizational policy and/or jurisdictional law
8	Transmit Content is transmitted – typically to an external entity or system	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	Content is received and retained - typically from an external entity or system
10	De-Identify Content is transformed into de-identified version	Content is transformed into de-identified version
11	Pseudonymize Content is transformed into an pseudomynized version	Content is transformed into an pseudomynized version
12	Re-Identify Content is re-identified from a previously pseudomynized version	Content is re-identified from a previously pseudomynized version
13	Extract Content is extracted to render subsets, derivations, summaries or aggregations	Content is extracted to render subsets, derivations, summaries or aggregations
14	Archive Are archived – typically to off-line (less readily available) storage media	Are archived - typically to off-line (less readily available) storage media
15	Restore Are restored from previous archive	Are restored from previous archive
16	Destroy/Delete Are destroyed or identified as missing	Are destroyed or identified as missing
17	Deprecate Are deprecated (e.g., improperly identified or otherwise invalid)	Are deprecated (e.g., improperly identified or otherwise invalid)
18	Re-Activate Are made active again after previous Destroy/Delete or Deprecate	Are made active again after previous Destroy/Delete or Deprecate
19	Merge Are merged together	Are merged together
20	Unmerge Are unmerged from previous merge	Are unmerged from previous merge
21	Link Are linked together	Are linked together
22	Unlink Are unlinked from previous linkage	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)	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)	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	Content is reviewed and affirmed for accuracy, completeness
26	Encrypt Content is encoded in a cipher	Content is encoded in a cipher
27	Decrypt Content is decoded from a cipher	Content is decoded from a cipher

E.0 CRUDE Events CRUDE Events 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 which C reate or U pdate 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 and are currently limited to basic

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 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 reate or U pdate 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 – Create , R – Read , and U – Update D – Delete E – Execute New Artifacts 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 C reated at RLE Audit Event Provenance Action Related 1 reated at RLE
		Audit Event	Prove- nance	Action Related
1	Originate/Retain	1..1	1..1	1..* C New Instance(s)	C New Instance(s)	---
2	Update/Amend	1..1	1..1	1..* C or U Instance(s)	C or U Instance(s)	---
3	Transform/Translate	1..1	1..1 a	1..*	--- C New transformed/ translated artifact	C New transformed/ translated artifact
4	Attest	1..1	1..1	1..* C or U Instance(s) (Provenance incl. Signature)	C or U Instance(s) (Provenance incl. Signature)	---
5	Access/View	1..1	1..1 a	1..* R Instance(s) C New extract artifact	R Instance(s)	C New extract artifact
6	Output/Report	1..1	1..1 a	1..*	--- C New output/report artifact	C New output/report artifact
7	Disclose	1..1	1..1 a	1..*	--- C New disclosure artifact	C New disclosure artifact
8	Transmit	1..1	1..1 a	1..*	--- C New transmittal artifact	C New transmittal artifact
9	Receive/Retain	1..1	1..1	1..* C New Instance(s)	C New Instance(s)	---
10	De-Identify	1..1	1..1 a	1..*	--- C New de-identified artifact	C New de-identified artifact
11	Pseudonymize	1..1	1..1 a	1..*	--- C New pseudomynized artifact	C New pseudomynized artifact
12	Re-Identify	1..1	1..1 b	1..* C or U Instance(s) Note b	C or U Instance(s) Note b	---
13	Extract	1..1	1..1 a	1..*	--- C New extract artifact	C New extract artifact
14	Archive	1..1	1..1 a	1..*	--- C New archive artifact	C New archive artifact
15	Restore	1..1	1..1 b	1..* C or U Instance(s) – Note b	C or U Instance(s) - Note b	---
16	Destroy/Delete	1..1	0..0	1..* D Instance(s)	D Instance(s)	---
17	Deprecate	1..1	1..1 b	1..* C or U Instance(s) – Note b	C or U Instance(s) - Note b	---
18	Re-Activate	1..1	1..1 b	1..* C or U Instance(s) – Note b	C or U Instance(s) - Note b	---
19	Merge	1..1	1..1 b	1..* C or U Instance(s) – Note b	C or U Instance(s) - Note b	---
20	Unmerge	1..1	1..1 b	1..* C or U Instance(s) – Note b	C or U Instance(s) - Note b	---
21	Link	1..1	1..1 b	1..* C or U Instance(s) – Note b	C or U Instance(s) - Note b	---
22	Unlink	1..1	1..1 b	1..* C or U Instance(s) – Note b	C or U Instance(s) - Note b	---
23 Add Legal Hold	Add Legal Hold	1..1	1..1 b	1..* C or U Instance(s) – Note b	C or U Instance(s) - Note b	---
24 Remove Legal Hold	Remove Legal Hold	1..1	1..1 b	1..* C or U Instance(s) – Note b	C or U Instance(s) - Note b	---
25	Verify	1..1	1..1 b	1..* C or U Instance(s) – Note b	C or U Instance(s) - Note b	---
26	Encrypt	1..1	1..1 a	1..*	--- C New encrypted artifact	C New encrypted artifact
27	Decrypt	1..1	1..1 b	1..* C or U Instance(s) – Note b	C or U Instance(s) - Note b	--- Note a: RLE typically C reates

^{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 may} : RLE typically C reate or reates 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 C reate or U pdate Record Entry instance(s) and thus the (one) Provenance Resource is bound to these instance(s). pdate Record Entry instance(s) and thus the (one) Provenance Resource is bound to these instance(s).

E.0 Record Lifecycle Event Metadata Captured in FHIR Resources 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. 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)

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|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	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 (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 Action - Performer [See W5 Report for specific resource attribute] Record - Author/User	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 : 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 Record - System/Device	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
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	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
WHAT Action - Taken
Action - Taken	Provenance	Activity : Coding 0..1 « ProvenanceActivity »
	AuditEvent Event ; BackboneElement 1..1 Record - Lifecyle Event AuditEvent.Event : 1..1 type : Coding 1..1 « AuditEventType+ » subtype : Coding 0..1 « AuditEventSubType+ » action : code 0..1 « AuditEventAction » AuditEvent.Object : 0..* identifier : Identifier 0..1 reference : Resource(Any) 0..1 type : Coding 0..1 « AuditEventObjectType » role : Coding 0..1 « AuditEventObjectRole » lifecycle : Coding 0..1 [Placeholder – TBD]	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
Action - Date/Time	Provenance Period : Period 0..1 Record - Date/Time	period : Period 0..1
	AuditEvent	recorded : instant 1..1
Record - Date/Time	Provenance recorded : instant 1..1 AuditEvent.Event : 1..1 dateTime : instant 1..1	recorded : instant 1..1
	AuditEvent : 1..1	recorded : instant 1..1
WHERE Action - Physical Location
Action - Physical Location	Provenance location : Resource(Location) 0..1 Record - Network Address	location : Reference(Location) 0..1
	AuditEvent	site : BackboneElement 0..1 identifier : string 1..1 type : Coding 0..* « AuditEventSourceType »
Record - Network Address	Provenance location : Resource(Location) 0..1 AuditEvent.Participant.Network address : string 0..1 type : code 0..1 « AuditEventParticipantNetworkType »	location : Reference(Location) 0..1
	AuditEvent.agent.Network	address : BackboneElement 0..1 type : code 0..1 « AuditEventAgentNetworkType »
WHY Action - Reason, Rationale, Purpose
Action - Reason, Rationale, Purpose	Provenance reason : CodeableConcept 0..1 Record - Reason, Rationale, Purpose	reason : Coding 0..*
	AuditEvent	purposeOfUse : Coding 0..* « AuditEventPurposeOfUse »
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)	reason : Coding 0..*
		policy : uri 0..*
	AuditEvent : 1..1	purposeOfEvent : Coding 0..*
Additional Evidentiary Metadata, as applicable
Digital Signature(s)	Provenance one per signature	signature : Signature 0..*
Record Entry ID	Provenance signature : Signature 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 : Coding 0..1 [Placeholder – TBD] 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 : Coding 0..1 « AuditEventObjectType » role : Coding 0..1 « AuditEventObjectRole » 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]	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] role : CodeableConcept 0..* « [as specified] » [for user-based permissions] reference : Resource(Practitioner|Organization| Device|Patient|RelatedPerson) 0..1 userId : Identifier 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 reference : Resource(Any) 0..1 type : Coding 0..1 « AuditEventObjectType » 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 userId : Identifier 0..1 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 : 1..* 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

E.0 EXAMPLE - Lifecycle Events for a Record Entry 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 FHIR Resource Instances Retaining without Alteration 1 - Pre Originate/Retain Order

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
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 © HL7.org 2011+. FHIR DSTU2 (v1.0.2-7202) generated on Sat, Oct 24, 2015 07:44+1100. Links: Search | Version History | Table of Contents | Compare to DSTU1
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...