The metadata, or extra information about data, regarding who created the data and when it was created.

Data Element

Applicable Vocabulary Standard(s)

Author Time Stamp

Author Organization

Organization associated with author.

Data Element

Applicable Vocabulary Standard(s)

Author Time Stamp

Author Organization

Organization associated with author.

Data Element

Applicable Vocabulary Standard(s)

Author Time Stamp

Date and time of author action.

Author Organization

Organization associated with author.

Data Element

Applicable Vocabulary Standard(s)

Author Time Stamp

Date and time of author action.

Author Organization

Organization associated with author.

Data Element

Applicable Vocabulary Standard(s)

Author

Actor that created or revised the data.

Usage note: The actor may be a provider, a patient, a device, an outside medical record, or something else. The source of the information can be used to form assessments about its quality, reliability, trustworthiness, or can indicate where to go to determine the origins of the information.

Author Role

Category of actor that participated in the creation or revision of data.

Usage note: The source of the information can be used to form assessments about its quality, reliability, trustworthiness, or can indicate where to go to determine the origins of the information.

Examples include but are not limited to provider, patient, family member, and device.

Author Time Stamp

Date and time of author action.

Author Organization

Organization associated with author.

Data Element

Source

Comment

CMS-CCSQ Recommend advancing data elements to Level 1

Data Elements: Signature and Purpose of Capture (Level 0)

  1. Recommendation: Advance the Signature and Purpose of Capture data elements to Level 1. 
  2. Rationale: Vocabulary and functional standards are not sufficiently advanced to merit inclusion in USCDI v6, but merit elevation to Level 1 to advance further discussion and consideration in the future. Signature is required as part of the Minimum Data Set (MDS), Inpatient Rehabilitation Facility-Patient Assessment Instrument (IRF-PAI), Long-Term Care Hospital (LTHS) Continuity Assessment Record and Evaluation (CARE) Data Set (LCDS), and Hospice Item Set (HIS) assessments. We emphasize the importance of capturing Signature as an individual data element when it is not already exchanged or captured as part of another data element, such as a document, note, or order. The following LOINC codes can be leveraged to support this data element:
  • 85814-2 (IRF-PAI Signature of persons completing the assessment)
  • 85647-6 (Signature of person collecting or coordinating collection of assessment information Provider)
  • 85648-4 (Signature of persons completing the assessment)
  • 70127-6 (Signature verifying assessment completion)

PACIO's Recommendation V6 Purpose of Capture / Rationale

  • Data Class: Provenance  
  • Data Elements: Purpose of Capture (Level 0) / Rationale (Level 0) 
  • Recommendation: Advance Purpose of Capture OR Rationale to Level 1, and remove the other. 
  • Rationale: The PACIO (Post-Acute Care Interoperability) Project, established February 2019, is a collaborative effort between industry, government, and other stakeholders, with the goal of establishing a framework for the development of FHIR implementation guides to facilitate health information exchange. The PACIO Community recommends the following data elements that are currently at other levels should be upgraded. 
  • Purpose of Capture OR Rationale (Currently Level 0) – Information is gathered from numerous sources for their own specific purposes. The level of detail, completeness, and quality of the information is highly dependent on the interests of those capturing the information, for instance, a therapist gathering information about a patient’s gait as part of a dedicated gait assessment may be weighed differently than a nurse’s assessment of the same patient’s gait as part of an intake assessment. This gives important context about the collected information and how it might also be repurposed for other uses such as population and public health. Both the Purpose of Capture and Rationale data elements contain this information, and both have identical descriptions in USCDI. The PACIO Project supports the advancement of one of these data elements to Level 1, and the removal of the other. 

Author and Author Role

NACHC strongly supports the need for provenance in healthcare data including the addition of Author and Author Role as described below.

 

Provenance: Author and Author Role [New Data Elements]

https://www.healthit.gov/isa/taxonomy/term/1171/draft-uscdi-v5

https://www.healthit.gov/isa/taxonomy/term/2201/draft-uscdi-v5

 

HL7 applauds the addition of Author and Author Role so that now individual clinicians can be identified, as well as patients and their caregivers.  The ability to recognize patients and caregivers as authors paves the way to including more patient contributed health data in a medical record.  The ability to individually identify a data author provides richer information to patients.  HL7 highlights one nuance to consider: if an author is external to an organization or leaves an organization, they might not have an organizational ID or system ID. Patients and caregivers would most likely also not have identifiers while clinicians may have an NPI/license number/certificate number.  An author could potentially be a device as well, such as a patient’s Fitbit. HL7 recommends that it be made more explicit in USCDI v5 that a device could author data.

In addition, the inclusion of new fields in the Provenance class can better enable communication of patient generated health data. However, in USCDI v5 as in v4, several of the new fields represent data types that might be especially sensitive to the patient. Some examples in V5 include Pronoun, Name to Use, and Sex for Clinical Use.  ONC should consider appropriate protection of these specific data items, while balancing all healthcare stakeholder interests.

PACIO Comments on Author Role

  • Data Class: Provenance
  • Data Elements: Author Role (Draft V5)
  • Recommendation: Include Author Role in the final draft of Version 5 but specify that this data element captures the role the author is currently performing.
  • Rationale: The PACIO (Post-Acute Care Interoperability) Project, established February 2019, is a collaborative effort between industry, government, and other stakeholders, with the goal of establishing a framework for the development of FHIR implementation guides to facilitate health information exchange. 
  • The PACIO Community applauds the inclusion of Author Role in USCDI. The language in the description of this data element suggests that it is capturing the category of the actor. We believe that this element should capture the actual role the author is fulfilling when they are recording or attesting to information as this could be dynamic throughout a period of care or an encounter. As examples, a family member should be able to record “primary caregiver” in addition to being a relation, and a nurse on a team of nurses should be able to record which job or role they were fulfilling when a given activity takes place as these roles might change during a shift.

PACIO Comments on Author

  • Data Class: Provenance
  • Data Elements: Author (Draft V5)
  • Recommendation: Include data element “Author” in USCDI V5 and clarify 
  • Rationale: The PACIO (Post-Acute Care Interoperability) Project, established February 2019, is a collaborative effort between industry, government, and other stakeholders, with the goal of establishing a framework for the development of FHIR implementation guides to facilitate health information exchange.
    • Author (currently Draft V5) – The PACIO Project supports the inclusion of Author in the final version of USCDI 5. This data element is critical for ensuring the integrity and trustworthiness of all other information captured in an EHR by capturing who is responsible for the data’s creation. We also recommend clarification of what information could be used to serve as an Author identifier. Because of varying state rules around licensure and certification, providers licensed or certified in multiple states with different associated numbers, and the fact that some clinical disciplines also do not routinely use an NPI, we recommend that a suite of options with clear guidance satisfy this requirement. 
    • We also point to patient and family authored information, critical to documenting accurate and holistic care, care preferences, and care planning. These authors are the people at the very center of care being delivered and they do not have ID numbers that are collected and used in a standardized way across the healthcare system. This is another reason we strongly support the Author Role data element for inclusion in Draft V5, as it could help clarify exactly who authored critical information that is entered outside of the healthcare system – please see our comments regarding Author Role.

PACIO Comments on Provenance Level 0

  • Data Class: Provenance
  • Data Elements: Signature (Level 0), and Purpose of Capture (Level 0)
  • Recommendation: Advance data elements, “Signature,” and “Purpose of Capture” to Level 1.
  • Rationale: The PACIO (Post-Acute Care Interoperability) Project, established February 2019, is a collaborative effort between industry, government, and other stakeholders, with the goal of establishing a framework for the development of FHIR implementation guides to facilitate health information exchange. The PACIO Community recommends the following data elements that are currently at other levels should be upgraded.
    • Signature (Currently Level 0) – Some documents and other information such as POLST orders and prescriptions need to be signed so that other practitioners can use them. A signature can also be used to confirm the veracity of information that is not coming through a direct connection with a trusted source, this itself requires a high degree of coordination that not all actors can yet perform. Signatures are used for many other applications and may encompass all manner of roles such as witness, notary, provider, or patient.
    • Purpose of Capture (Currently Level 0) – Information is gathered from numerous sources for their own specific purposes. The level of detail, completeness, and quality of the information is going to be highly dependent on the interests of those capturing the information. This gives important context about the collected information and how it might be repurposed for other uses such as population and public health.

USCDI V5 Feedback

The Provenance data class now includes Author as a data element and Author Role as a data element. However, the examples provided for Author Role are actually types of Authors, not Author Roles. An author can be a provider, a patient, a family member, or a device.  The examples need to be moved to explain the different types of authors there can be. 

Author – Actor that participated in the creation or revision of data. Examples of authors include but are not limited to provider, patient, family member, and device.

Author Role - Category of actor that participated in the creation or revision of data. Examples include but are not limited to provider, patient, family member, and device.

The Author Role data element describes the role the author plays, and the possible roles differ depending on the type of author. 

If the Author is the Patient, then the role they play is “oneself”. 

2.16.840.1.113883.11.20.12.1

Personal And Legal Relationship Role Type

ONESELF

self

RoleCode

 

If the Author is a provider, then the role they play is based on the role they are licensed to play within the organization they are working for. Note – this is why the PractitionerRole resource is key to be used in FHIR when referencing a provider. You need to bring together the practitioner, the organization they are working for, and the facility they are working out of. Sometimes you need all that context to understand what role the author is playing.  For a Practitioner type of Author, the role is usually expressed using concepts from the NUCC Provider Taxonomy.  A great deal of work was done to create curated value sets to use to represent provider roles using NUCC codes was contributed to the Provider Directory IG being developed within HL7. This can be confusing because there is a tight coupling between the type of care a practitioner is licensed to provide and the role that practitioner plays on the care team. For example, a practitioner licensed to practice Cardiology serves the role of a Cardiologist on the care team. There are a few notable exceptions. For example, a practitioner who is a Cardiologist may play the role of the patient’s primary care provider. Additionally, HL7 provides a general role designation vocabulary for Practitioners. These value sets are also being used for practitioner roles in the DirectTrust Provider Directory. When conveying the Author’s role, a combination of concepts can be needed. 

Individual and Group Specialties: http://hl7.org/fhir/us/ndh/ValueSet/IndividualAndGroupSpecialtiesVS

PractitionerRole Code Value Set: http://hl7.org/fhir/us/ndh/ValueSet/PractitionerRoleVS

If the Author is a family member, then the role they play is described as their relationship to the patient, i.e. Mother, Father, Sibling, Child, etc. These family member role terms are typically drawn from the Personal and Legal Relationship Role Type value set. 

2.16.840.1.113883.11.20.12.1

Personal And Legal Relationship Role Type

 

If the author is a device, I’m not sure we have a well established “role type” value set established yet.

Additional roles that are essential for the data provenance requirements in the Advance Healthcare Directives space include:  Authenticator, Witness, and Notary. 

Authenticator

A person or organization who manually, electronically, or digitally signs a document or form.

Cross list note: May be relevant in many other Data Classes.

 

Witness

A person who observes or attests to a person completing a document or form (in person or via virtual workflows).

Cross list note: May be relevant in many other Data Classes.

 

Notary

A person who follows defined “notarizing procedures” to complete a notarization process for a document or form.

Cross list note: May be relevant in many other Data Classes.

Provenance Legal Author and Author Role

The Texas Health Services Authority Interoperability Collaborative is supportive of inclusion of legal author and author role as it will provide additional critical information involved with the clinical decision-making.  However, as each state may define legal author differently, it would be helpful if there was a national definition. The ability to rely on a national definition would increase efficiencies for the vendor community with implementation standards. A national definition would also reduce the burden of differing state definitions for those organizations that deliver clinical services across state lines or receive patients from other states.

Comment

Recommend adding Unique Identifier as a data element. This will support the traceability of messages. FHIR data exchanges shall have the ability to identify an update to the original message (e.g., HL7 v2.5 Update Patient Information). The value becomes more important as automatic ingestion of external messages is implemented (i.e., source identifies data entered on wrong patient, and is aware the data was exchanged, then an update can be triggered). 

PACIO Comments on Data Elements Under Provenance in V5

  • Data Class: Provenance
  • Data Elements: Author (Level 2), Signature (Level 0), Author Roles (Level 0), and Purpose of Capture (Level 0)
  • Recommendation: Include data element “Author” in USCDI V5 and advance data elements, “Signature,” “Author Roles,” and “Purpose of Capture” to Level 1.
  • Rationale: The PACIO (Post-Acute Care Interoperability) Project, established February 2019, is a collaborative effort between industry, government, and other stakeholders, with the goal of establishing a framework for the development of FHIR implementation guides to facilitate health information exchange. The PACIO Community recommends the following data elements that are currently at other levels should be upgraded.
    • Author (currently on Level 2) - Author time and organization is not going to have a lot of meaning without the author particularly in non-institutional data sources. As we move to more patient centered care, there will be other contributors of data including patients and non-clinician Caregivers
    • Signature (Currently Level 0) – Some documents and other information, such as end of life, like POLST, orders need to be signed in order to trusted and used. Without a signature there is no way to validate the veracity of data that may not be coming from a direct trusted source.
    • Author Role(s) (Currently Level 0) – The role in which data is captured is important to more fully understand data. It is important to know not only what organization or author created the data but the capacity in which they were operating under in order to properly understand the data.
    • Purpose of Capture (Currently Level 0) – Information is gathered from numerous sources for their own specific purposes. The level of detail, completeness, and quality of the information is going to be highly dependent on the interests of those capturing the information. This is important to understand more about the data and how it can be further used for things such as population and public health.

Log in or register to post comments