The metadata, or extra information about data, regarding who created the data and when it was created.
Data Element
|
Physical Location
Description
Location where action was taken and/or where dataset or data element was collected (captured, sourced). Location should include room (within) building (within) organization. Provenance set includes the who, what, when, where and why as metadata for USCDI data classes and data elements. Physical Location is part of “where”. Physical Location must be associated with each USCDI dataset or data element that has a unique provenance set. Occurs when data is originated (captured, collected or sourced), updated, verified, attested, transformed (e.g., to/from exchange artifact such as HL7 v2 message, document or FHIR resource instance). Note that Physical Location is intrinsic to what the source EHR/HIT system already knows, thus it does not require extra data collection (burden) by the clinician or other end user.
|
Submitted By: Gary Dickinson
/ EHR Standards Consulting
|
Data Element Information |
Rationale for Separate Consideration |
Physical Location anchors data classes and data elements to the actual location where they were collected (captured, sourced). This is a must for transparency, accountability, assurance (trust) and traceability. |
Use Case Description(s) |
Use Case Description |
All use cases (including health data/record exchange) where essential assurance of transparency, accountability, trust, traceability and data integrity is required. |
Estimate the breadth of applicability of the use case(s) for this data element
|
Any/all stakeholders for any/all use cases. |
Healthcare Aims |
- Improving patient experience of care (quality and/or satisfaction)
- Improving the health of populations
- Reducing the cost of care
- Improving provider experience of care
|
Maturity of Use and Technical Specifications for Data Element |
Applicable Standard(s) |
N/A |
Additional Specifications |
N/A |
Current Use |
Extensively used in production environments |
Supporting Artifacts |
FHIR Core Release 4.0.1 – Record Lifecycle Event Implementation Guide
ISO 21089:2018 – Trusted End-to-End Information Flows
ISO/HL7 10781 – Electronic Health Record System Functional Model, Release 2.1
http://hl7.org/fhir/ehrsrle/ehrsrle.html
|
Extent of exchange
|
5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders. |
Potential Challenges |
Restrictions on Standardization (e.g. proprietary code) |
None |
Restrictions on Use (e.g. licensing, user fees) |
None |
Privacy and Security Concerns |
None. In fact enables health data/record audit events and audit logs (audit trails).
• Who did what when where and why (actions taken)
• Who documented what when where and why (health record entries) |
Estimate of Overall Burden |
As stated previously, most all of the submitted Provenance elements are intrinsic to what the source EHR/HIT system already knows, thus will not require extra data collection (burden) by the clinician or other end user. |
Other Implementation Challenges |
The usual resistance from certain stakeholders – those who believe Provenance is unnecessary – after all, who would believe that transparency, accountability, assurance, traceability and data integrity are essential/integral to trusted health data/record management and use? |
|
Submitted by gldickinson on
HL7 FHIR Record Lifecycle Event Implementation Guide
Please update reference to HL7 FHIR Record Lifecycle Event Implementation Guide, published December 2023: http://hl7.org/fhir/uv/ehrs-rle/Informative1/