| Submitted By: Michael Saito
/ Epic
|
| Data Element Information |
| Use Case Description(s) |
| Use Case Description |
Adopting the Social Determinant of Health (SDOH) data class would create a standard interoperability framework for the structured exchange of that data. Providers can use insight they gain from SDOH they exchange with other organizations to better inform the care provided to the patient by:
-Referring the patient to community resources (e.g., housing, nutrition, domestic violence support)
-Understanding barriers to the patient’s care (e.g., financial constraints, mobility challenges)
-Understanding a patient’s mental health (e.g., screening for drug use, alcohol use, or depression)
|
| Estimate the breadth of applicability of the use case(s) for this data element
|
Numerous provider organizations capture and store this data within their health IT systems today. We anticipate that an increasing number of provider organizations will have an interest in consistently capturing and exchanging this data as the shift toward comprehensive, value-based care continues. |
| Link to use case project page |
https://www.hl7.org/gravity/ |
| Healthcare Aims |
- Improving patient experience of care (quality and/or satisfaction)
- Improving the health of populations
- Reducing the cost of care
|
| Maturity of Use and Technical Specifications for Data Element |
| Applicable Standard(s) |
LOINC can be used to express a number of assessments used to evaluate a patient’s social determinants of health.
SNOMED CT can be used to document a clinical observation stemming from an assessment when it is appropriate.
https://loinc.org/ http://www.snomed.org/
|
| Additional Specifications |
The HL7 Gravity project aims to develop implementation guides that would facilitate the exchange of this data element using FHIR APIs. |
| Current Use |
Extensively used in production environments |
| Supporting Artifacts |
Provider organizations using Epic software today have the capability to conduct a broad range of assessments designed to capture and store information about a patient’s Social Determinants of Health. This information includes the risk level and factors considered in determining that risk level. Systems certified to criterion (a)(15) in ONC’s Health IT Certification Program would have the capability to document certain social, psychological, and behavioral data. The Interoperability Standards Advisory secion on Social, Psychological, and Behavioral Data includes standards that can be used to express a number of Social Determinant of Health domains.
|
| 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. |
| Supporting Artifacts |
Organizations using Epic software engage in standards-based exchange of SDOH data today, but in a non-exstensible manner. Standardizing the exchange of SDOH data in the extensible manner we propose for the USCDI would greatly improve exchange workflows.
|
| Potential Challenges |
| Restrictions on Standardization (e.g. proprietary code) |
We are not aware of any restrictions that would prevent the standardization of the exchange of these data elements. |
| Restrictions on Use (e.g. licensing, user fees) |
Organizations may need to license the clinical content (e.g., a particular proprietary assessment used to assess an aspect of a patient’s Social Determinants of Health) to build the assessment in their system.
However, this would not prevent them from exchanging data generated from SDOH assessments, since the assessment content would not be exchanged, only the domain, name of the assessment, risk categorization, and date of the assessment.
|
| Privacy and Security Concerns |
Social Determinant of Health Data in some instances may be considered of even greater sensitivity than other patient-identifiable health information, since the results of certain screenings could result in discrimination (e.g., care discrimination based on a financial screening). Examples of SDOH data that would often be considered of heightened sensitivity compared to other medical information would include results from assessments for drug use or intimate partner violence. |
| Estimate of Overall Burden |
Organizations that do not use health IT capable of capturing SDOH data today would need to adopt upgraded technology to do so. Health IT developers could need to complete a significant amount of development to implement updated FHIR APIs and changes to CCDA documents they send and receive to facilitate exchange SDOH data in the structured manner described.
Provider organizations would also need to complete data mapping to automate the consumption and reconciliation of SDOH data they receive, similar to the mapping required to exchange lab tests and results. Similar to mapping for lab tests and results, however, not all of the domains, assessment types, or categorizations may be well represented by the code sets. |
| Other Implementation Challenges |
We recommend adopting the approach described here as a first phase to standardizing the exchange of SDOH data. Using our model for exchange, stakeholders would be able to exchange information about the type of assessment and level of risk for a particular SDOH domain, which provides an extensible framework that enables flexible, discrete, and immediate exchange of SDOH data.
While such a framework has great potential because of its flexibility and extensibility, it would require significant mapping effort on the part of exchanging entities to enable improved semantic interoperability (similar to mapping that stakeholders complete today to improve semantic interoperability of lab tests and results). Ideally, an initiative to exchange SDOH data in the USCDI would adopt our model of exchange, but be accompanied by a parallel effort to standardize the assessments used to evaluate a patient’s social determinants of health in the provider community. Building consensus on standard screenings used to assess Housing Instability, Alcohol Use, Transportation Security, Food Insecurity, and in other domains would accelerate the ability for organizations to exchange that data, and arrive at consistent interpretations of their meaning in the context of patient care.
As the provider community builds consensus on standard screenings used to assess SDOH Domains, additional work may be required to eliminate or reduce licensing barriers to the extent that the clinical content used in those screenings is proprietary. |
Official Website of The Office of the National Coordinator for Health Information Technology (ONC)
Submitted by cmayo@med.umich.edu on
Inclusion of Disability at SDOH measure
Could a measure for disability be included among the SDOH elements? There are several reasons for this suggestion.
1) The disability community is an underserved population, not typically recognized in other measures.
2) Incidence of disabilities cuts across socio-economic lines while also compounding the effects of other markers for social determinants of health. For example, the challenges faced by a patient who is black and living in a rural setting a multiplied if the individual also has a disability.
3) Disability for an individual has a strong collateral effects on other family members in the household affecting their access to health care. For example, the economic , employment, insurance, and access impacts on a family caring for a child with cognitive disabilities can reach well beyond the individual alone.
Even baseline measure, such as used in the American Community Survey, would be helpful.
https://www.census.gov/topics/health/disability/guidance/data-collection-acs.html#:~:text=The%20American%20Community%20Survey%20%28ACS%29%20Go-outside-home%20Disability%20Because,or%20emotional%20condition%20lasting%206%20months%20or%20more%2C
This field is for general comments on this specific data element. To submit new USCDI data classes and/or data elements, please use the USCDI ONDEC system: https://healthit.gov/ONDEC