| Submitted By: Gary Dickinson / EHR Standards Consulting | |
|---|---|
| Data Element Information | |
| Rationale for Separate Consideration | Author role(s) are crucial to identify participation in action taken and/or authorship of specific data classes or data elements. It offers essential assurance for transparency, accountability, trust, traceability and data integrity. |
| 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. |
| Estimated number of stakeholders capturing, accessing using or exchanging | Any/all stakeholders for any/all use cases. |
| Healthcare Aims |
|
| 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 |
| Number of organizations/individuals with which this data element has been electronically exchanged | 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? |
Metadata, or data that describes other data.
Data Element |
Information from the submission form |
|---|---|
| Author Role(s) |
Description
Author Role(s), in context of action taken and/or in context of USCDI dataset or data element authorship. Should include roles such as: a) action performer, b) assistant, c) observer, d) author of dataset or data element, e) scribe. Provenance set includes the who, what, when, where and why as metadata for USCDI data classes and data elements. Author Role(s) are part of “who”. Author Role(s) 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. Note that Author Role(s) are 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 dididavis on 2021-09-30
Sequoia Data Usability Workgroup Support for Author Role Element
The Sequoia Project Interoperability Matters/Data Usability Workgroup conducted a clinician workshop on June 1, 2021 where feedback was given that it would be desirable to add a role element to provenance to identify what type of provider documented the information exchanged (i.e. Pharmacist, Nurse Practictioner, PCP, etc.). On behalf of the Data Usability Workgroup, I would like to support this submission for consideration, however the role types may not be consistent based on review of the value sets. Either way, I am trying to avoid duplication. Please contact let us know if we can provide additional input.