Information about a person who participates or is expected to participate in the care of a patient.

Data Element
Data Steward
Description

Patients may be their own data stewards, or have other data stewards able to authorize permissions on their data. This term, "Data Steward" is intended to describe an individual or organization authorized and accountable for permission decisions about the health data of the individual. While this may be a RelatedPerson or a member of a CareTeam (existing elements and classes in USCDI FHIR), it may also not be part of those groups. Data stewards may be needed for individual patients who are incapacitated or for minors who lack legal capacity to consent (although be able to assent). Data stewards may also have a critical role in stewardship of health data for deceased individuals, e.g. clinical genetic counseling, research studies. Individuals may also assign stewardship to multiple individuals and organizations. Data stewardship may also authorize designated organizations and/or individuals to determine data use permissions by specific segment (e.g. medication data vs. family history data).
Submitted By: Henry Wei / Google
Data Element Information
Rationale for Separate Consideration A Data Steward is often -- but not always -- a RelatedPerson or a CareTeam. Most notably it may be an organization, rather than an individual. The additional characteristics around a Data Steward -- particularly given the role in determining access and usage permissions for almost every other element in USCDI -- suggests it should be described either separately, or as a specific Role that is clearly separate from other roles in CareTeam. This is because the CareTeam Data Element or RelatedPerson Classes may not even be readable without appropriate permissions from the actual Data Steward.
Use Case Description(s)
Use Case Description A Data Steward element may be most needed for minors (e.g. 60 million school-aged children) as well as elderly and disabled adults at risk of being legally incapacitated (6 million US adults living with dementia). The main use cases for a potential Data Steward element would therefore be to indicate to clinical users and other data users who the appropriate permission-granter is for the data. There may be other use cases where patients designate a healthcare provider or healthcare organization as the Data Steward for their data. Having such a relationship described in USCDI and FHIR may permit additional awareness and notification of health data uses to the Data Steward.

Note that Data Steward is not intended to describe a financial Guarantor -- a responsible party for patients' bills. Data Steward is not a Guarantor, but the same individual may serve as both a Data Steward and a Guarantor. The intended use of Data Steward is in health data permissioning and stewardship.
Estimate the breadth of applicability of the use case(s) for this data element In terms of patients, the entire pool of US patients with health data records (350M+) would likely need to have a Data Steward identified. At least 60 million school-aged children would have a Data Steward identified, most likely a parent or legal guardian as a default data steward.
Link to use case project page https://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=1130
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) FHIR has standards for Person and Organization resources:
https://www.hl7.org/fhir/person.html
https://www.hl7.org/fhir/organization.html

However, role-specific terminology and standards may be needed to describe the specific role(s) of a Data Steward if considered as a separate element, or as a member of the CareTeam.
https://www.hl7.org/fhir/person.html
Additional Specifications N/A
Current Use Not currently captured or accessed with an organization
Extent of exchange N/A
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) No known restrictions on proposed standardization.
Restrictions on Use (e.g. licensing, user fees) No known restrictions on use of the proposed data element.
Privacy and Security Concerns Data stewardship and identity of permission-granters may create specific security requirements. While these are sometimes handled in OAuth2 access scopes, the role of a data steward may not be specific to digital access, but a real-world relationship between a patient's data and a responsible individual or organization. Data Steward definition can help address privacy concerns; however security and verification of the provenance and integrity of the identified Data Steward are needed. Verifying the integrity and authenticity of any Element is beyond the scope of any specific element (existing or proposed), and should most likely be handled consistently across Elements.
Estimate of Overall Burden Immediate burden to patients and providers should be minimal as specific care team members may proxy for Data Steward in the near-term, such as parents and legal guardians.

Over time, particularly with consumer-mediated health data exchange, it may become critical to designate individuals as Data Stewards; therefore the implementation burden is primarily on the healthcare providers and those obtaining consent today in real-world interactions, as well as the identity of those individuals and/or organizations providing or denying consent.
Other Implementation Challenges Legal concept mapping may need to be considered in terms of data stewardship, and modeled into role descriptors and definitions for a proposed Data Steward element. This is true if is an element or if it is a role within another existing element.

Comment

Log in or register to post comments