|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)
|Estimated number of stakeholders capturing, accessing using or exchanging||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/|
|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.
|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|
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.
|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.|
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.
|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.
Information from the submission form
|Social Determinant of Health Domain||
The area of social risk documented for a patient (e.g., housing insecurity, alcohol use, transportation security). When exchanging a domain, the following constituent data components should be included: - Source/Assessment: The specific survey, questionnaire, or question set(s) used to calculate the patient’s risk value for the domain, if applicable. If a particular assessment was not used to calculate the patient’s risk value, just the risk value may be exchanged. - Risk Value: The category of risk that applies to a patient for the domain (e.g., “high risk,” “moderate risk,” “low risk,” or “unknown”). - Date: The date the assessment was completed.