Skip to end of metadata
Go to start of metadata

This page includes discussion of:

  • PSAF Provenance Class Model Basis
  • FHIR Provenance Resource to PSAF Provenance Class Model Map
  • Relevant Healthcare Provenance Platform Specific Implementation Guides Summaries

PSAF Provenance Class Model Basis

The Privacy and Security Architecture Framework Volume 3 Provenance Domain Analysis Model (PSAF Provenance DAM) adopts a healthcare focused conceptual information and behavioral model based on the following:

HL7 PSAF Provenance DAM Foundational Standards

There are several HL7 and IHE platform specific Provenance Implementation Guides that also address healthcare specific use case, transport, and syntax constraints on the same underlying W3C foundational Provenance Data Model (PROV DM). Among these Healthcare Provenance platform specific Implementation Guides are, by standard type and order of publication [with bidirectional links to their discussion sections]:

HL7 EHR Functional Model

HL7 CDA IGs

Cross-Paradigm

HL7 FHIR Provenance related Artifacts

IHE Provenance related Specifications

Given that PSAF Provenance DAM is a healthcare specific conceptual and platform independent model, and that it uses the same HL7 classes and terminology used by the platform specific HL7 and IHE Provenance guidance, alignment among these models’ information models is to be expected, and the behavioral models would not be expected to conflict, i.e., there should be nothing in the PSAF Provenance DAM that precludes any behavior or exchange pattern in the platform specific implementation guidance.

Where there is discordance, it would likely be caused by an evolution in HL7 foundational class models, datatypes, and terminology, but such disruptive changes are rare given the maturity of these standards.  If that were not the case, then the ability to map across HL7 product families and IHE specifications would be far less fruitful than it's been to date.

FHIR Provenance Resource to PSAF Provenance Class Model Map

 The following is a map from the FHIR Provenance Resource to this DAM, because like the DAM, it is based on W3C PROV.  Its purpose is to show that the DAM does not restrict the HL7 platform specific Provenance specifications.

 The FHIR Provenance Resource should be less constrained than the HL7 Data Provenance IG.  The HL7 CDA Data Provenance IG, which is also based on W3C PROV, is more constrained than the FHIR Provenance Resource and the HL7 Data Provenance IG, and thus, more constrained than this DAM.

 Mapping Findings: The DAM Class Model, which is the only normative section of the DAM (with no SHALLs), is less constrained than FHIR Provenance Resource. 

Therefore, this DAM does not put constraints on any of the HL7 Provenance specifications.

 

FHIR Provenance Resource

PSAF Provenance DAM Class Model Map

Element Id

Provenance


Definition

Provenance of a resource is a record that describes entities and processes involved in producing and delivering or otherwise influencing that resource. Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility. Provenance assertions are a form of contextual metadata and can themselves become important records with their own provenance. Provenance statement indicates clinical significance in terms of confidence in authenticity, reliability, and trustworthiness, integrity, and stage in lifecycle (e.g. Document Completion - has the artifact been legally authenticated), all of which may impact security, privacy, and trust policies.


Cardinality

0..*


Type

DomainResource


Alternate Names

History; Event; Activity


Comments

Some parties may be duplicated between the target resource and its provenance. For instance, the prescriber is usually (but not always) the author of the prescription resource. This resource is defined with close consideration for W3C Provenance.


Provenance.target

 Table 2: Attributes of the Entity Class Section 8 page 25

Element Id

Provenance.target

prov:id

Definition

The Reference(s) that were generated or updated by the activity described in this resource. A provenance can point to more than one target if multiple resources were created/updated by the same activity.


Cardinality

1..*

0..1 if only if there is an Activity, else 0..*

Type

Reference(Any)

Entity prov:type

Summary

TRUE
The current definition of the specimen resource contains only basic information about specimen containers. It does not address the recursive nature of containers or the tracking of the location of a container within its parent container (for instance: a tube in a tray in a rack in a freezer). The frequency with which these elements are tracked may depend on the context of use; general lab, bio-banking, etc.  May also need https://build.fhir.org/specimendefinition.html


Comments

Target references are usually version specific, but might not be, if a version has not been assigned or if the provenance information is part of the set of resources being maintained (i.e. a document). When using the RESTful API, the identity of the resource might not be known (especially not the version specific one); the client may either submit the resource first, and then the provenance, or it may submit both using a single transaction. See the notes on transaction for further discussion.


Provenance.occurred[x]


Element Id

Provenance.occurred[x]


Definition

The period during which the activity occurred.


Cardinality

0..1


Type

Period|dateTime  

prov:generatedAtTime
prov:invalidatedAtTime

[x] Note

See Choice of Data Types for further information about how to use [x]


Comments

The period can be a little arbitrary; where possible, the time should correspond to human assessment of the activity time.


Provenance.recorded


Element Id

Provenance.recorded


Definition

The instant of time at which the activity was recorded.


Cardinality

1..1


Type

instant


Summary

TRUE


Comments

This can be a little different from the time stamp on the resource if there is a delay between recording the event and updating the provenance and target resource.


Provenance.policy


Element Id

Provenance.policy


Definition

Policy or plan the activity was defined by. Typically, a single activity may have multiple applicable policy documents, such as patient consent, guarantor funding, etc.


Cardinality

0..*


Type

uri
why URI - why not a Resource such e.g. https://build.fhir.org/specimendefinition.html

rights - string, which could be a uri

Comments

For example: Where an OAuth token authorizes, the unique identifier from the OAuth token is placed into the policy element Where a policy engine (e.g. XACML) holds policy logic, the unique policy identifier is placed into the policy element. 


Provenance.location

prov:atLocation

Element Id

Provenance.location


Definition

Where the activity occurred, if relevant.


Cardinality

0..1


Type

Reference(Location)


Provenance.reason


Element Id

Provenance.reason


Definition

The reason that the activity was taking place.


Cardinality

0..*


Terminology Binding

V3 Value Set PurposeOfUse (Extensible)


Type

CodeableConcept


Provenance.activity

Table 4: Attributes of the Activity Class Section 8 page 26

Element Id

Provenance.activity

Activity prov:id

Definition

An activity is something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entities.


Cardinality

0..1

0..*

Terminology Binding

Provenance activity type (Extensible)


Type

CodeableConcept

Activity prov:label

Provenance.agent

Table 5: Attributes of Agent Class Section 8 page 27

Element Id

Provenance.agent

Agent prov:id

Definition

An actor taking a role in an activity for which it can be assigned some degree of responsibility for the activity taking place.


Cardinality

1..*

0..*

Requirements

An agent can be a person, an organization, software, device, or other entities that may be ascribed responsibility.


Comments

Several agents may be associated (i.e. has some responsibility for an activity) with an activity and vice-versa.


Provenance.agent.type


Element Id

Provenance.agent.type


Definition

The primary act of participation of the agent with respect to the activity.


Cardinality

0..1


Terminology Binding

Provenance participant type (Extensible)


Type

CodeableConcept

Agent prov:type - example codes Table 6: Agent Types

Requirements

Note: The .type of author could be .role of primary author. Note there are overlapping codes to be used in specific circumstances. See ISO 21298:2018 - Health Informatics - Functional and structural roles.


Summary

TRUE


Comments

For example: assembler, author, doctor, nurse, clerk, etc.


Provenance.agent.role


Element Id

Provenance.agent.role

Agent prov:id

Definition

The functional or structural roles of the agent indicating the agent's competency. The security role enabling the agent with respect to the activity.


Cardinality

0..*

0..*

Terminology Binding

SecurityRoleType (Example)


Type

CodeableConcept

Agent prov:type - example codes Table 6: Agent Types Section 8 page 27

Requirements

Note: The .type of author could be .role of primary author. Note there are overlapping codes to be used in specific circumstances. See ISO 21298:2018 - Health Informatics - Functional and structural roles.


Comments

For example: PRIMAUTH, REVIEWER, VERF, etc.


Provenance.agent.who

Table 5: Attributes of Agent Class Section 8 page 27

Element Id

Provenance.agent.who

Agent prov:label

Definition

The individual, device or organization that participated in the event.


Cardinality

1..1


Type

Reference(Practitioner | PractitionerRole | RelatedPerson | Patient | Device | Organization)

Agent prov:type - example codes Table 6: Agent Types

Patterns

Reference(Practitioner,PractitionerRole,RelatedPerson,Patient,Device,Organization): Common patterns = Participant


Summary

TRUE


Comments

whoIdentity should be used when the agent is not a Resource type.  


Provenance.agent.onBehalfOf


Element Id

Provenance.agent.onBehalfOf

Agent prov:id

Definition

The individual, device, or organization for whom the change was made.


Cardinality

0..1


Type

Reference(Practitioner | PractitionerRole | RelatedPerson | Patient | Device | Organization)

Agent prov:type - example codes Table 6: Agent Types

Patterns

Reference(Practitioner,PractitionerRole,RelatedPerson,Patient,Device,Organization): Common patterns = Participant


Comments

onBehalfOfIdentity should be used when the agent is not a Resource type.


Provenance.entity

Entity Section 8 page 25 Table 2: Attributes of the Entity Class

Element Id

Provenance.entity




Relevant Healthcare Provenance Platform Specific Implementation Guides Summaries

 The following are excerpts from the list of Healthcare Provenance platform specific Implementation Guides above, which provide summary descriptions that highlight their adherence to the HL7 PSAF Provenance DAM foundational standards listed above.

HL7 Electronic Health Record System Functional Model (EHR-S FM) Release 2.0.1

[Back to Top]

The EHR-S FM supports the binding of the author, time stamp and author signature to a Record Lifecycle Event across the Record’s Lifespan, i.e., by chaining Lifecycle Events. Primarily focused on the creation, maintenance and persistence of provenance within a Record system, and less so on conveying information provenance when disclosed.

Record Infrastructure, Record Lifecycle and Lifespan[4]

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

HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1[5]

[Back to Top]

 DS4P CDA IG focuses on the provenance of the authoring provider, organization, and/or device. It mandates inclusion of timestamp, provider identifier, role, address, telecom, and the provider organization at the Document, Section, and Entry levels where different. Authoring device is recommended. This IG focuses on the creation, persistence, and maintenance of provenance in the source system, and conveying that provenance to downstream recipient with the expectation that recipient systems will persist that provenance.

 CDA cda Mandatory Document Assigned Author[6]

[AssignedAuthor: templateId 2.16.840.1.113883.3.3251.1.3]

This CDA template is used to specify the actual person, organization, and/or device responsible for the contents of the document. If a document is an aggregate of data authored by several providers, then the author will be an organization. If the data is produced by a device, then the document header assigned author is the device identified by its unique identifier. If the author of a section or entry is different than the one identified in the header, then the author must be identified at the appropriate section or entry. This template is intended to help implementers assert conformance to mandatory provenance business

requirements. It demonstrates how the General Header Constraints can be further constraints to ensure that author's email may be included since the email is often the basis for digital certificates.

 DS4P cda Mandatory Document Provenance[7]

[Author: templateId 2.16.840.1.113883.3.3251.1.2]

This CDA template is used to specify the mandatory elements of the ""author" structure in the header of a CDA document. The "author" is used to specify the provenance of the document. Often, if the document contents are authored by several providers, the header may specify only the organization while the section and entry may specify the actual providers responsible for the section and entry contents. Typically, if author specified in the header is not responsible for all the sections and entries in the document, then the "author" associated with those entries must be specified. This template is intended to help implementers assert conformance to mandatory provenance business requirements. It demonstrates how the General Header Constraints can be further constraints to ensure that time when the document was authored is not left "null".

 DS4P cda Mandatory Entry Assigned Author[8]

[AssignedAuthor: templateId 2.16.840.1.113883.3.3251.1.7]

This CDA template specifies the assigned author (e.g. organization. provider, or device) that is responsible for the contents of an act, observation. etc. in an entry. In specific cases the author information is mandatory for complete provenance. This template is intended to help implementers assert conformance to mandatory provenance business requirements. This template is used if the author of an entry differs from the author asserted in the document header. This may be the case when a summary document is sent on behalf of an organization but individual entries are authored by specific providers in that provider organization.

DS4P cda Mandatory Entry Provenance[9]

[Author: templateId 2.16.840.1.113883.3.3251.1.6]

This CDA template is used to specify the provenance of an act, observation, etc. in an entry that contains protected information. This template is intended to help implementers assert conformance to mandatory provenance business requirements. The entry ""author" is further constrained to ensure that time when the document was authored is not left "null" by the sender in the case when the author of the entry differs from the author asserted in the document header.

DPROV CDA HL7 Implementation Guide for CDA® Release 2: Data Provenance, Release 1 – US Realm September 2014 HL7 Reference Draft Standard for Trial Use 1 Ballot[10]   

[Back to Top]

DPROV CDA IG extends the Provenance supported by the DS4P IG by including a Device as an Assigned Author at the Document, Section, and Entry levels where different. It supports author electronic signature and chaining of the source Documents, Sections, and Entries. This IG focuses on the creation, persistence, and maintenance of provenance in the source system, and conveying that provenance to downstream recipient systems with the expectation that recipients will also persist that provenance, and will further convey the chained provenance to downstream recipient with the expectation that recipient systems will persist source provenance, and chain it with any new provenance upon further disclosure.

 The Implementation Guide for CDA (R) Release 2: Data Provenance, Release 1, September 2014 is the result of collaborative efforts between HL7 and the Health and Human Services Office of National Coordinator’s Standards and Interoperability Framework Data Provenance Initiative (DPROV). The DPROV Initiative is sponsored by the Office of the Chief Privacy Officer within the ONC to develop standards and guidance by which health information technology can support clinical, organizational, and jurisdictional requirements to capture, and conveyed provenance about health information. Please visit the Initiative and HL7 sources noted throughout this document for further information and current status of activities.

This IG is the result of a focused effort to identify existing opportunities within CDA R2 where basic provenance information about clinical (and other care related information) – who created it, when was it created, where was it created, how it was created, and why it was created – can be conveyed in a consistent and interoperable manner. This IG represents a consensus approach to meeting the requirements for the conveyance of provenance data within any CDA at the document, section and entry level.

Subsequent and related activities within the S&I Framework and HL7 are expected to provide additional guidance for specific use case events such as:

  • Transitions of provenance as a result of lifecycle events;
  • Inheritance of provenance when a portion of a CDA instance is excerpted and incorporated into another CDA instance

Purpose

This IG provides guidance to any CDA R2 implementer on the use of CDA templates to represent the data provenance as well specifying reusable models as building blocks for use in other information exchange standards.

Scope

The scope of this IG is the conveyance of the basic provenance facts in a CDA instance. As such, it identifies the specific CDA structures and related value sets to communicate provenance related metadata for documents, sections, and entries. This IG strives to be agnostic as to system functionality and workflow in which such data is to be collected. The goal is to provide basic guidance that can be leveraged by or applied to existing and (future) CDA R2 IGs. Use and adoption will inform best practices within the constraints of the base standard and additional constraints of this IG to

achieve consistent and reliable conveyance of provenance.

The core provenance metadata to be captured are:

  • Who contributed to the generation of a CDA, e.g., the participating: authors, authenticators, legal authenticator, custodian, data enterer, performers, and other participants, including assembly software, scoping organizations at the document, section, and entry levels.
  • When an-information event recorded in a CDA occurred
  • Where an information event recorded in a CDA occurred
  • Why an information event recorded in a CDA occurred

Overview

As noted, this IG is agnostic of the policies, procedures and regulations that determine the actual values to be conveyed. In the context of CDA, the facts related to provenance are supported via coding systems and generic structures – author, assignedEntity, etc. The population of these consistent models is the abstract use case that this IG addresses. Constraints defined in each template are intended to ensure the presence and conveyance of these values regardless of how or when they are determined.

During analysis of current practices, it became clear the abstract use case required constraints on the base CDA in two areas:

  • The first was to note the distinction of documents that are authored by patients versus those that are authored by clinical staff and others who have a recognized role in the care or treatment of a patient under the auspices and fulfillment of clinical or business practices for an organization such as a hospital or home health service. This IG builds on the previous work that resulted in the Patient Generated Document Template as defined in the Consolidated CDA, Release 2 Implementation guide (publication in progress). This template provides an unambiguous means of identifying those documents (or portions there-of) as having been authored by a patient or related person who acts as the patients advocate, but is clearly not a member of the provider-related organizations.
  • The second is to recognize a new type of actor referred to as an Assembler. This actor compiles new artifacts (CDA instances) from existing artifacts portions thereof but is distinctly different from the type of software or device that is use to collect and capture new information. As defined by this IG, the following criteria are used to determine how or where each of these types of non-human actors are conveyed:
    • Devices meeting existing CDA concepts of a device author, which capture and create new information, such as blood pressure, glucose meters, and health applications that may be used for mHealth, which may in turn be incorporated into records captured in e.g., an EHR or PHR
    • Software not meeting existing CDA concepts of a device author, which provides no new content but simply collates and repackages existing content (with existing provenance information intact is considered an Assembler, such as software used to generate a CDA response to a query for existing information, existing content (with existing provenance information intact) is considered an Assembler.

While the use of such applications is new, it is important to recognize the effect of this type of activity on the subjective aspects of provenance such as trust and reliability. By clearly identifying those documents that are created algorithmically with no human intervention or oversight, a recipient is able to discern that these may have a different level of trust. The HL7 DPROV CDA IG is designed to meet these emerging capabilities using templates that address these distinctions, which can be used with any CDA profiles or IGs.

Approach

Working with specifications generated from formal UML models provides the opportunity to work with the data from the perspective of the underlying model and electronic format and to explore many design issues thoroughly. Taking this as an initial step ensures that the data set developers and standards community can reach consensus prior to the larger commitment of time that would be required to bring the full data set into standard format.

HL7 Guidance: Basic Provenance for C-CDA and FHIR, Release 1 - US Realm September 2019 HL7 Informative Ballot

[Back to Top]

The Basic Provenance IG supports retaining the author, time stamp, organization of a Record’s “last hop” including any transmitter or transformer actors for C-CDA and FHIR artifacts. There are no expectations that the recipient will persist, add to, or further convey provenance to downstream recipients.

 Discussion on the Basic Provenance Project on Confluence

The Basic Provenance Implementation Guide provides US Realm functional and technical guidance on what constitutes minimal “provenance”. This guidance should inform future implementations of the data class identified in the US Core Data for Interoperability published by the Office of the National Coordinator.

Specifically, the IG will include technical guidance for C-CDA 2.1, and US FHIR Core (based on R4). Guidance will be limited to the set of data classes identified in the US Core Data for Interoperability, and any additional information needed to convey those data classes within C-CDA and FHIR.

The guidance here complements other more advanced HL7 and industry provenance efforts (see Appendix – Advanced Provenance Efforts).

From the Introduction of the September HL7 Guidance: Basic Provenance for C-CDA and FHIR, Release 1 - US Realm September 2019 HL7 Informative Ballot :

A more advanced definition of provenance from the HL7 FHIR Provenance Resource1:

Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility. Provenance assertions are a form of contextual metadata and can themselves become important records with their own provenance. Provenance statement indicates clinical significance in terms of confidence in authenticity, reliability, and trustworthiness, integrity, and stage in lifecycle (e.g. Document Completion - has the artifact been legally authenticated), all of which may impact security, privacy, and trust policies.

The Draft U.S. Core Data for Interoperability (USCDI) and Expansion Process, published by ONC on Jan 5, 2018 indicated 22 “data classes” in the list of Draft USCDI Version 1 Data Classes. While many of those data classes have already been defined within the C-CDA and FHIR standards, “provenance” has not been. For interoperability to be achieved with this data class, functional and technical guidance are needed regarding what details constitute “provenance”, technically how provenance information should be represented in the C-CDA and FHIR standards, and the best practices around that representation.

This informative guide is a prioritized first step towards including more robust provenance in clinical data exchange.

FHIR Provenance Resource

[Back to Top]

The FHIR Provenance Resource supports conveyance of the target Resource’s agent(s), including their identifiers, roles, contact information and organization, the agent action(s) and purposes, and input entities, which may be chained.

Provenance of a resource is a record that describes entities and processes involved in producing and delivering or otherwise influencing that resource. Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility. Provenance assertions are a form of contextual metadata and can themselves become important records with their own provenance. Provenance statement indicates clinical significance in terms of confidence in authenticity, reliability, and trustworthiness, integrity, and stage in lifecycle (e.g. Document Completion - has the artifact been legally authenticated), all of which may impact security, privacy, and trust policies.

Scope and Usage

The Provenance resource tracks information about the activity that created, revised, deleted, or signed a version of a resource, describing the entities and agents involved. This information can be used to form assessments about its quality, reliability, trustworthiness, or to provide pointers for where to go to further investigate the origins of the resource and the information in it.

Provenance resources are a record-keeping assertion that gathers information about the context in which the information in a resource was obtained. Provenance resources are prepared by the application that initiates the create/update etc. of the resource. An AuditEvent resource contains overlapping information, but is created as events occur, to track and audit the events. AuditEvent resources are often (though not exclusively) created by the application responding to the read/query/create/update/etc. event.

6.3.2 Boundaries and Relationships

Many other FHIR resources contain some elements that represent information about how the resource was obtained, and therefore they overlap with the functionality of the Provenance resource. These properties in other resources should always be used in preference to the Provenance resource, and the Provenance resource should be used where additional information is required, or explicit record or provenance is desired.

The relationship between a resource and its provenance is established by a reference from the provenance resource to its target. In this way, provenance may be provided about any resource or version, including past versions. There may be multiple provenance records for a given resource or version of a resource.

6.3.3 Background and Context

The Provenance resource is based on the W3C Provenance specification , and mappings are provided. The Provenance resource is tailored to fit the FHIR use-cases for provenance more directly. In terms of W3C Provenance the FHIR Provenance resource covers "Generation" of "Entity" with respect to FHIR defined resources for creation or updating; whereas AuditEvent covers "Usage" of "Entity" and all other "Activity" as defined in W3C Provenance.

The W3C Provenance Specification has the following fundamental model:

Where:

  • Entity - An entity is a physical, digital, conceptual or other kind of thing with some fixed aspects; entities may be real or imaginary. One or more entities can be the input (.entity) of an activity, and one or more entities can be the output (.target).
  • Agent - An agent is something that bears some form of responsibility for an activity taking place, for the existence of an entity, or for another agent's activity.
  • Activity - An activity is something that occurs over a time period and acts upon or with entities. It may include consuming, processing, transforming, modifying, relocating, using, or generating entities.

The Provenance resource corresponds to a single activity that identifies a set of resources (target) generated by the activity. The activity also references other entities (entity) that were used and the agents (agent) that were associated with the activity. To record multiple activities that resulted in one (target), record each (activity) in independent Provenance records all pointing at that (target).

The Provenance resource depends upon having References to all the resources, entities, and agents involved in the activity. These References need not be resolvable. The references must provide a unique and unambiguous identification. If a resource, entity, or agent can have different versions that must be identified, then the Reference must have versioning information included.

Versioning and unique identification are not mandated for all systems that provide Resources, entities, and agents. But, inclusion of Provenance requirements may introduce requirements for versioning and unique identification on those systems.

The Provenance resource is based on leveraging the W3C Provenance specification to represent HL7 support of provenance throughout its standards and explicitly modeled as functional capabilities in ISO/HL7 10781 EHR System Functional Model Release 2 and ISO 21089 Trusted End-to-End Information Flows. Mappings are provided. The Provenance resource is tailored to fit the FHIR use-cases for provenance more directly. In terms of W3C Provenance the FHIR Provenance resources covers "Generation" of "Entity" with respect to FHIR defined resources for creation or updating; whereas AuditEvent covers "Usage" of "Entity" and all other "Activity" as defined in W3C Provenanc

FHIR Record Lifecycle Events Implementation Guide

[Back to Top]

The FHIR Record Lifecycle Events IG supports conveyance of the target Resource’s agent(s), including their identifiers, roles, contact information and organization, the agent action(s) and purposes, and input entities, which may be chained. Additional support for conveying the Record Lifecycle Event that triggered the provenance is included.

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

US Core R4 Basic Provenance Guidance[11]

[Back to Top]

US Core Basic Provenance IG focuses on support for the “last hop” minimum provenance: Timestamp, the Target Resource, Author, Author Organization, Transmitter, and Transmitter Organization.

​This section provides implementers with important definitions to create and share the Provenance Resource1.

Basic Provenance

The FHIR Provenance Resource provides a foundation for assessing authenticity, enabling trust, and allowing reproducibility. It isn’t scoped to a specific use case, nor limits the number of Provenance records associated with a Resource. The basic guidance here, and in the US Core Provenance Profile focuses on a key subset of elements, the ‘last hop’, and specific use cases. The guidance here does not preclude more advanced use cases or additional elements.

Full Provenance of a Resource requires details from the original creator of a Resource and all intermediary actors that updated the Resource. Members of the Argonaut community and the HL7 security working group discussed the current sharing approaches, and display to end user, and agreed the most important information is the last organization making a meaningful clinical update to the data, and the prior system providing the data, the ‘last hop’. Participants didn’t dispute the potential need to recreate the full chain, but didn’t see this as relevant to the immediate end-user.

Key Provenance Elements

The guidance for Provenance in US Core focuses on 6 key elements: Timestamp, the Target Resource, Author, Author Organization, Transmitter, and Transmitter Organization. The timestamp is the date and time the author created, updated, or deleted the data. The target is the Resource the Provenance record supports. The Author represents the person(s) responsible for the information. The Author Organization represents the organization the author is associated when they created, updated, or deleted the data. The Transmitter represents the system responsible for transmitting the information. The Transmitter Organization represents the organization responsible for the transmission.

US Core R4 StructureDefinition-us-core-provenance[12]

[Back to Top]

US Core StructureDefinition describes the capabilities required to support the “last hop” minimum provenance: Timestamp, the Target Resource, Author, Author Organization, Transmitter, and Transmitter Organization.

This profile sets minimum expectations for the Provenance resource to record, search and fetch Provenance information associated with a record. It identifies which core elements, extensions, vocabularies and value sets SHALL be present in the resource when using this profile. This FHIR Provenance profile here covers the minimal (basic) information to support lineage of information. Prior to reviewing this profile, implementers are encouraged to read the Basic Provenance guidance page which documents several key use cases.

Example Usage Scenarios:

The following are example usage scenarios for the US Core Provenance profile:

  • Query for the Provenance records associated with an Allergy
  • Query for the Provenance records associated with a Problem

Mandatory and Must Support Data Elements

The following data-elements are mandatory (i.e. data MUST be present) or must be supported if the data is present in the sending system (Must Support definition). They are presented below in a simple human-readable explanation. Profile specific guidance and examples are provided as well. The Formal Profile Definition below provides the formal summary, definitions, and terminology requirements.

Each Provenance must have:

  1. resource(s) the Provenance record is supporting (target)
  2. a date and time for the activity

Each Provenance must support:

  1. an author responsible for the update
  2. the author organization responsible for the information
  3. the transmitter that provided the information
  4. the transmitter organization responsible for the transmission (if the transmitter is a device the transmitter organization must also be valued).

Profile specific implementation guidance:

  • If a system receives a provider in Provenance.agent.who as free text they must capture who sent them the information as the organization. On request they SHALL provide this organization as the source and MAY include the free text provider.

IHE PCC 5 Technical Framework SupplementQuery for Existing Data for Mobile10 (QEDm) HL7® FHIR®Release 4 Using Resources at FMM Levels 2-NRev. 2.0– Draft for Public Comment[13]

 [Back to Top]

IHE QEDm leverages FHIR Provenance Resource to provide the ability to communicate the provenance of lists of clinical data that were reconciled, when they were reconciled and who did the reconciliation. 

  Query for Existing Data for Mobile

The Query for Existing Data for Mobile Profile (QEDm) supports queries for clinical data elements, including observations, allergy and intolerances, conditions, diagnostic results, medications, immunizations, procedures, encounters and provenance by making the information widely available to other systems within and across enterprises. It defines a transaction used to query a list of specific data elements, persisted as FHIR resources.

It’s functionally equivalent to the QED Profile, but is conceived to be implemented by applications specific to mobile devices. The term “mobile” should be considered in a wider sense: it identifies not only mobile applications, but the whole class of systems that are resource- and platform-constrained. (e.g., tablets, smartphones, and embedded devices including home-health devices, but also larger systems where needs are simple, such as pulling the latest summary for display).

IHE QEDm with its Provenance Option and mXDE define rules to ensure consistency and traceability of information used for clinical decisions. When a data element is accessed by a Clinical Data Consumer, identifiers from that data element can be used to access one or more documents in which this data element was originally recorded, providing a valuable broader clinical context.

The flows of information are depicted in the figure on the right:

  1. Specific data elements are extracted from the structured documents per mXDE Profile (Mobile Cross-Enterprise Document Data Element Extraction).
  2. Data elements (e.g. allergies) queried using the FHIR based QEDm Profile. Each data element is referenced to the document(s) from which it was extracted per mXDE Profile.
  3. Clinician accesses context of any data element of interest using source documents (XDS, MHD Profiles) providing the clinical context in which the observation was recorded.

Data Element-Level Granularity access is central to mXDE and is discussed in Section 45.1 of Volume 1 of the IT Infrastructure Technical Framework. The Provenance information, returned with each fine-grained data element in the QEDm Query responses, allows identification of the document from which the fine-grained data element was extracted and is described in the Provenance Option of the QEDm Profile.[14]

Summary - The Reconciliation of Clinical Content and Care Providers profile[15] provides the structures and transactions needed to communicate the list of reconciled items, when they were reconciled and who did the reconciliation. This can be accomplished with any CDA® or FHIR® constructed list regardless of implementation guide.

Reconciled information is needed to prevent information redundancy and to support clinical care, quality reporting, financial transactions, public health reporting, clinical trials, drug interaction checking, and patient qualification for various protocols. A wide variety of systems will need to reconcile clinical data as information is exchanged, stored and maintained in EMR system or other clinical data repository. This is needed to prevent confusion and conflict of clinical information that can lead to patient safety issues.

This profile provides the ability to communicate lists of clinical data that were reconciled, when they were reconciled and who did the reconciliation. 

IHE Reconciliation of Clinical Content and Care Providers (RECON) – Revised 2016-11-11[16]

[Back to Top]

IHE RECON leverages FHIR Provenance Resource to provide the ability to communicate the provenance of lists of clinical data that were reconciled, when they were reconciled and who did the reconciliation. 

The Provenance resource MAY be used in conjunction with reconciled lists, for recording additional detail about who performed reconciliation and when it was performed, and the sources of information. Whenever the Provenance resource is used for reconciled content, the following constraints shall be met. The Provenance resource contains the content about who reconciled the list, when, and what content was considered. This is akin to the CDA Reconciliation Act

 Definition   FHIR Provenance Resource describes the activity that led to the creation of a set of resources. This information can be used to help determine their reliability or trace where the information in them came from. The focus of the provenance resource is record keeping, audit and traceability, and not explicit statements of clinical significance.

  

IHE RECON: FHIR Resource Provenance - Content[17]


Provenance of a resource is a record that describes entities and processes involved in producing and delivering or otherwise influencing that resource. Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility. Provenance assertions are a form of contextual metadata and can themselves become important records with their own provenance. Provenance statement indicates clinical significance in terms of confidence in authenticity, reliability, and trustworthiness, integrity, and stage in lifecycle (e.g. Document Completion - has the artifact been legally authenticated), all of which may impact security, privacy, and trust policies.

IHE RECON: 6.3.1 Scope and Usage

The Provenance resource tracks information about the activity that created, revised, deleted, or signed a version of a resource, describing the entities and agents involved. This information can be used to form assessments about its quality, reliability, trustworthiness, or to provide pointers for where to go to further investigate the origins of the resource and the information in it.

Provenance resources are a record-keeping assertion that gathers information about the context in which the information in a resource was obtained. Provenance resources are prepared by the application that initiates the create/update etc. of the resource. An AuditEvent resource contains overlapping information, but is created as events occur, to track and audit the events. AuditEvent resources are often (though not exclusively) created by the application responding to the read/query/create/update/etc. event.


[1] See PROV-Overview: An Overview of the PROV Family of Documents W3C Working Group Note 30 April 2013http://www.w3.org/TR/prov-overview/

[2] International Virtual Observatory Alliance (IVOA), IVOA Provenance Data Model, Version 1.0, IVOA Proposed Recommendation, 15 Oct. 2018. http://www.ivoa.net/documents/ProvenanceDM/20181015/PR-ProvenanceDM-1.0-20181015.pdf

[3] http://www.w3.org/TR/prov-dm/ April 30, 2013

[4] HL7 Electronic Health Record System Functional Model (EHR-S FM) Release 2.0.1 7/30/2016 page 87.


[5] Data Segmentation for Privacy (DS4P) Implementation Guide, Release 1 Part 1: CDA R2 and Privacy Metadata Reusable Content Profile May 13, 2014

[6] DS4P CDA IG page 54

[7] DS4P CDA IG page 55

[8] DS4P CDA IG page 57

[9] DS4P CDA IG page 58

[10] http://www.hl7.org/implement/standards/product_brief.cfm?product_id=420

[11] https://build.fhir.org/ig/HL7/US-Core-R4/basic-provenance.html

[12] https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-provenance.html

[13] https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_QEDm_Rev2-0_PC_2019-01-11.pdf

[14] https://wiki.ihe.net/index.php/Query_for_Existing_Data_for_Mobile

[15] https://wiki.ihe.net/index.php/Reconciliation_of_Clinical_Content_and_Care_Providers

[16] https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_RECON.pdf

[17] https://build.fhir.org/provenance.html


  • No labels