Social and Health Information Platform: Piloting a Standards-Based, Digital Platform Linking Social Determinants of Health Data into Clinical Workflows for Community-Wide Use

Abstract

Background Social determinants of health (SDoH)[a] are increasingly recognized as a main contributor to clinical health outcomes, but the technologies and workflows within clinics make it difficult for health care providers to address SDoH needs during routine clinical visits.

Objectives Our objectives were to pilot a digital platform that matches, links, and visualizes patient-level information and community-level deidentified data from across sectors; establish a technical infrastructure that is scalable, generalizable, and interoperable with new datasets or technologies; employ user-centered codesign principles to refine the platform's visualizations, dashboards, and alerts with community health workers, clinicians, and clinic administrators.

Methods We used privacy-preserving record linkage (PPRL) tools to ensure that all identifiable patient data were encrypted, only matched and displayed with consent, and never accessed or stored by the data intermediary. We used limited data sets (LDS) to share nonidentifiable patient data with the data intermediary through a health information exchange (HIE) to take advantage of existing partner agreements, technical infrastructure, and community clinical data.

Results The platform was successfully piloted in two Federally Qualified Health Clinics by 26 clinic staff. SDoH and demographic data from findhelp were successfully linked, matched, and displayed with clinical and demographic data from the HIE, Connxus. Pilot users tested the platform using real-patient data, guiding the refinement of the social and health information platform's visualizations and alerts. Users emphasized the importance of visuals and alerts that gave quick insights into individual patient SDoH needs, survey responses, and clinic-level trends in SDoH service referrals.

Conclusion This pilot shows the importance of PPRL, LDS, and HIE-based data intermediaries in sharing data across sectors and service providers for scalable patient-level care coordination and community-level insights. Clinic staff are integral in designing, developing, and adopting health technologies that will enhance their ability to address SDoH needs within existing workflows without adding undue burdens or additional stress.

Keywords

social determinants of health - digital platform - health information platform - population health - health information exchange

Background and Significance

The World Health Organization, as well as the U.S. Department of Health and Human Services' Healthy People 2030 initiative, defines health not merely as the absence of disease but also as holistic care and the promotion of well-being throughout the community.[1] [2] Recent research shows that roughly half of health outcomes are a result of nonclinical drivers of health or “social determinants of health (SDoH)”—the social factors like access to transportation, food, and housing that greatly impact our ability to get and stay healthy.[3] [4] An effective health care system addresses and integrates social needs and environmental influences into existing clinical workflows and interventions so that patients receive coordinated clinical and social care in a familiar environment. According to the socioecological model's framework of health, multiple levels of interconnected and coordinated services are required to achieve positive health at the population, family, and individual levels; interventions at the individual level impact public health and community resourcing decisions, and vice versa.[5]

Fortunately, there is increasing awareness and financial support to integrate and proactively address social needs as part of regular doctor visits.[6] [7] As recently as January 2023, the Centers for Medicare and Medicaid Services released new guidelines outlining how states can use Medicaid dollars (“in lieu of services and settings” funds) to address patients' SDoH needs like food and housing to help promote wellness.[8] [9] Addressing nonclinical drivers of health has emerged as a foundational concept in population health and public health policy around the world and in the United States, yet there is still a lack of scalable and interoperable technical solutions that integrate SDoH data into existing clinical systems and referral workflows across a community.[10] Health technologies of all types have faced difficulties in being adopted and used by clinic providers for many reasons, including a lack of provider input in the design process, a lack of data standards for interoperability between systems, and inflexibility in the adoption of technical solutions (i.e., a one-size-fits-all approach).[11]

This paper describes our development and pilot of a social and health information platform, social and health information platform (SHIP), that successfully integrated SDOH data into clinical workflows of two pilot clinics in Austin, Texas, including linkage with patients' electronic medical records. We present our experiences and strategies as an example for overcoming common legal, technical, and operational barriers that have hindered communities' past efforts to address SDoH through a shared data platform. Due to the complex nature of community health initiatives, innovative solutions such as SHIP must be developed as a balance between process, culture, staff priorities and needs, and technical considerations such as privacy, ease of adoption, sustainability, and feasibility.[12]

Objective

Data on SDoH needs and interventions should be captured and stored in electronic health records (EHRs) so that clinic staff can more effectively address social needs as part of routine health care.[13] The coronavirus disease 2019 pandemic reemphasized the need for integrating SDoH data into community health reporting,[14] and while many EHRs can store SDoH data in free-text clinical notes or bespoke SDoH modules,[15] a lack of uniform SDoH data standards and regulations makes it difficult for EHRs to integrate, aggregate, store, visualize, or share SDoH data in a meaningful or actionable way—particularly across organizations.[16] [17] Integrating SDoH data directly into EHRs is costly and time-consuming, does not scale well to other organizations or EHRs, and may not even scale to future releases of the EHR for which it was built.[18] Ingesting SDoH data directly into the EHR also requires direct access to patients' protected health information (PHI) data, which can add significant time and complexity in terms of the Institutional Review Board (IRB) requirements or data sharing agreements needed.

Integrating SDoH data outside of the EHR presents its own unique set of challenges. Needing to have multiple programs or browser windows open to understand a patient's full treatment is frequently cited as a frustration for front-line health workers,[19] and new technologies require ongoing training support so that clinic staff stay engaged and know how to use technologies without being overwhelmed by too many features or steps to data entry and review.[20]

We codeveloped SHIP with community health workers (CHWs) and clinicians to link and display clinical and SDoH data as a part of existing clinical workflows (i.e., when a patient's chart was opened in the EHR, pop-up SHIP alerts would open patient-specific visuals). We also wanted to create a back-end data warehouse where population-level analysis of linked clinical and social data could inform community health planning, resource allocation, and program evaluation. Our specific objectives were to demonstrate in real clinics that:

• (1) SHIP can match and link patient records across different organizations and sectors.

• (2) Access to SDoH assessments and referrals can be adopted in clinical workflows easily using SHIP.

• (3) Aggregate or population-level trends can be tracked and reported using SHIP.

Materials and Methods

Study Design, Population, and Setting

Our main partners in building SHIP were the information technology (IT) and clinical teams at two FQHC test clinics Lone Star Circle of Care and People's Community Clinic and our pilot mental health clinic integral care, our social service referral platform partner findhelp (formerly Aunt Bertha), Austin's local Health Information Exchange Connxus (formerly Integrated Care Collaboration), the vendor for our privacy-preserving record linkage (PPRL) tools Datavant, and the nonprofit United Way of Greater Austin who manages and triages requests for social services via 211 and ConnectATX.

The two initial data sources for SHIP were health data from Connxus and SDoH referral and assessment data from findhelp. As the neutral data convener, the business associate agreements and licenses were held by the University of Texas (UT) Austin Dell Medical School (DMS). All users of the platform were authenticated, and all data in transit were encrypted and stored in a secure Health Insurance Portability and Accountability Act (HIPAA)-compliant UT/DMS-controlled instance of Amazon Web Services (AWS). SHIP was piloted for over 12 months with 11 licensed clinicians, nine CHWs, three clinic managers, and three clinic administrators. These staff also engaged in design meetings before the pilot and helped analyze SHIP's successes and areas for improvement in poststudy focus groups and surveys. There were an additional 12 months spent before the pilot began setting up the basic design of SHIP, testing the PPRL tools, creating the back-end infrastructure, and establishing the IRB and other legal agreements needed to link SDoH data in clinics via SHIP.

The SHIP pilot implementation blended user-centered design principles with an agile method of technology development and employed a mixed methods approach to evaluation, combining quantitative data on data linkage and usage with qualitative feedback from focus groups with clinic staff. Front-line staff (e.g., CHWs, clinicians, and clinic managers) were the primary drivers of SHIP's development through ongoing focus groups, on-site clinic visits to shadow and observe workflows, and codesign sessions reviewing and modifying visual mockups.

We used the well-established implementation science framework called “RE-AIM” (reach, effectiveness, adoption, implementation, and maintenance) to break down SHIP's performance and use in five distinct areas.[21] The RE-AIM framework helps evaluate each part of an implementation, from its ability to achieve its intended goals with end users (reach and effectiveness), through the initial uptake of the technology (adoption and implementation) and the ability to long-term sustain the technology (maintenance).[22]

Data Collection, Analysis, and Results

SHIP's evaluation metrics were developed during the 12-month, prepilot project planning phase with input from all project partners. Using the RE-AIM framework, we developed metrics to measure SHIP's success in terms of front-end user adoption and back-end system performance. The main result was that SHIP worked as designed in two real-world clinic settings, with patient records successfully linked and matched across settings to give clinic staff insights into real-time related to individual and aggregated SDoH needs. [Table 1] shows the goals of SHIP and the related development features that achieved each goal, followed by sections detailing the results for each project goal.

Table 1 Functions of SHIP successfully tested in the pilot

Desired functionalities of SHIP	Description
Match and link patient records across different organizations	Using a privacy preserving record linkage service (PPRL) and medical record numbers (MRN) with limited datasets
SDoH assessments and referrals can be adopted in clinical workflow	Using an API-based alert tool (“SideKick,” a SHIP component) and visuals to deliver SDoH information in existing workflows, including summaries of cross-organization SDoH assessments
Population-level clinical and SDoH trends can be tracked	Using intelligent modeling to normalize SDoH data and map them across SDoH and clinical categories to deliver aggregate insights with AWS, SQL, etc.

Abbreviations: API, application programming interface; AWS, Amazon Web Services; SDoH, social determinants of health; SHIP, social health information platform; SQL, Structured Query Language.

Limited Data Sets and a Neutral Data Convener

HIPAA defines an LDS as patient data that has specific, easily identifiable demographic characteristics removed to maintain anonymity and privacy.[23] Organizations are able to share an LDS without specific written consent as long as (1) there is a data use agreement in place between the organizations and (2) the data are only being used for research, health care operations, or public health programs.[23] Per HIPAA's LDS guidelines, the following data elements were removed from the Connxus and findhelp datasets before being sent to SHIP: first and last name; postal address information (other than town, cities, states, and zip codes); telephone and fax numbers; e-mail addresses, Uniform Resource Locators and Internet Protocol addresses; social security numbers; certificate and license numbers; vehicle identification numbers; device identifiers and serial numbers; biometric identifiers; and full-face photographs or comparable images.

Connxus sent all the remaining data in their clinical data repository (CDR), including medications, laboratories, clinical encounters and utilization, and diagnoses. Connxus also sent SDoH survey data for one clinic that documented surveys in their EHR instead of findhelp. Findhelp sent a more limited set of data elements related only to SDoH, as defined in our data sharing agreement: dates of SDoH referrals; email of staff who placed each SDoH referral; the organization and programs that clients were referred to; the specific types of SDoH services that each organization provides (e.g., food and transportation); current status of referral (e.g., “client got help,” “client not eligible,” and “pending”); and the date, location, and result of all prior SDoH assessments. [Table 2] illustrates sample sizes of the different data exchanged via SHIP that required AWS storage. The initial LDS exchanged had to be refreshed at regular intervals to ensure the currency of the data related to the new patient encounters. SHIP visuals displayed a combination of SDoH data from findhelp (e.g., dates and results of referrals and assessment results) and clinical data from Connxus (e.g., dates of clinical encounters, medications, and diagnoses).

Table 2 Size and dates of data exchanged for social and health information platform

	Initial LDS
Connxus/HIE—clinical data	53 GB—(5/31/21)
Connxus/HIE—SdoH survey data and one clinic	3 GB—(12/21/21)
Findhelp—SDoH survey and referral data	35.6 MB—(6/1/21)
Datavant—tokenized match data	1.7 GB—(8/12/21)

Abbreviations: HIE, health information exchange; LDS, limited data set; SDoH, social determinants of health.

Record Matching and Linking Using Privacy-Preserving Record Linkage

PPRL securely encrypts strings of patient data to be sent, received, and matched with accuracy and precision. PPRL tools are used in multiple clinical research networks across the country, including the nationally recognized Patient-Centered Outcomes Research Network which stores more than 100 million patient records.[24] PPRL technologies use HIPAA-compliant algorithms to create a unique cryptographic hash or “token” based on an individual's demographic data (for example, last name + first name + date of birth + 3-digit zip).[25] The PPRL tools encrypt data by turning the long strings of unique patient information into a unique string of characters (e.g., vjo89ah37…) that are then linked between the two datasets to see where patient data successfully matches. Each token is a unique “key” to one individual's data and cannot be decoded to identify the source of data or the individual's identity.

The SHIP pilot utilized PPRL tools developed by Datavant that allowed findhelp and Connxus to send 44-character base-64 strings of tokenized data while the Dell Medical School served as the neutral data convener that securely received and matched the encrypted tokens. PPRL's unique design allowed Dell Medical School (as the neutral data convener) to receive and match nonidentifiable data in the form of LDS and tokens without complex legal agreements and threats to privacy which accompany storage of PHI and are often used by narrow-focused internal IT teams as a reason to delay or deny such innovative solutions. [Table 3] summarizes metrics related to SHIP's successful matching and linking of cross-sectoral data using PPRL.

Table 3 Cross-sector patient records matched and linked using PPRL

	October 2021	September 2022
No. of valid and unique Connxus records for PPRL matching	1,030,001	1,071,044
No. of valid and unique findhelp records for PPRL matching	5,833	12,334
No. of patient records successfully matched using PPRL	879	1,764

Abbreviation: PPRL, privacy-preserving record linkage.

As part of SHIP's prepilot development and testing activities, we also did a “data fill rate analysis” to see which pieces of demographic data were present in both of our datasets (Connxus and findhelp) and available to use for creating tokens and matching patients. For example, comparing the percentage of patient files in Connxus and findhelp included patient's email address or cell phone number, to verify if tokens that use email or cell phone would be likely to generate and match. During the prepilot period, we also tested all the Datavant PPRL tools using fake data to make sure tokens were created, sent, received, and matched correctly.

[Fig. 1] shows a diagram of SHIP's technical architecture, including our two initial data sources (Connxus and findhelp) along with the LDS and PPRL tokens or “hashes.” Connxus provides the LDS from its integrated patient CDR to the SHIP platform at Dell Medical School in addition to sending demographics and patient ID to Datavant as a third party, to convert this information into encrypted tokens or “hashes.” Datavant's PPRL tools perform a similar process converting demographic data and user IDs from findhelp, which contributes social service referral information to the SHIP platform at Dell Medical School. In this way, patients' PHI is not connected with the sensitive clinical or social service information at any stage, while still allowing records matching to occur between two different data sources (Connxus and findhelp) via the neutral data intermediary (Dell Medical School). When an individual's information is accessed through the SHIP application programming interfaces (API), the encrypted tokens or “hashes” from Connxus and findhelp that were matched allow the integrated information from clinical and social service referrals to be delivered as a visualization or alert in the clinical site's workflow.

Fig. 1 SHIP Architectural Diagram. API, application programming interface; AWS, Amazon Web Services; CDR, clinical data repository; DB: database; DWH, data warehouse; ETL, extract, transform, load; Hash ID: unique identifier; LDS: limited data set; PatID: patient ID; UID: user ID.

User-Centered Design

Having end users guide the development, and refinement of new health technology is integral to the final product being adopted and being useful.[26] Our team began the design process for SHIP by conducting a series of site visits to observe and understand firsthand the everyday priorities and struggles in the clinic—particularly around screening patients, delivering SDoH services, and documentation. By having ongoing meetings with clinic leadership (e.g., directors of public health, evaluators, and clinic managers), multiple clinical site visits early in the project, and treating clinic-based CHWs and clinicians as true experts in SDoH-focused clinical service delivery, we built trust and received valuable feedback about how to design and improve SHIP. Clinic staff provided insight regarding the timing and length of how patients flowed through the clinic, common frustrations reviewing patient records, and the goals that different providers have for each step of the patient's visit. For example, one clinic staff said “because we have those [SHIP] pop ups and all that information, that can be something that triggers the provider, ‘oh, this patient needs this particular resource’ […] in an efficient way […] versus again, going back and forth.” [Fig. 2] shows an example of how SDoH alerts and patient-level visualization were codesigned to trigger based on common actions users were already taking in their EHR.

Fig. 2 Example of SHIP's integrated SDoH pop-up alerts and SDoH referral dashboard (data presented in the figure are imaginary).

We then led a series of nine focus groups with clinic users covering similar topics as the site visits. Some sessions consisted of staff performing different roles within one organization (to align on strategic priorities and documentation standards) and others included participants across multiple organizations that performed the same role, such as CHWs or clinicians (to avoid power dynamics based on job title or supervisory status and create a free flow of ideas focused on job-specific tasks and opportunities for SHIP). Focus group ideas were then organized by theme and continuously prioritized for development with end users. For example, in the focus group with only clinicians, participants focused on which SDoH information would be most important for providers to see in pop-up alerts given their limited time—“for example, a patient doesn't have refrigeration at home and doesn't have an insulin pen. So today, when the physician is prescribing insulin, they need to consider a type of insulin that doesn't need refrigeration.” CHW focus groups centered on completing common SDoH tasks more efficiently—[Fig. 3] shows a SHIP visual designed by CHWs to help organize and prioritize SDoH interventions based on urgency and type—completion of an SDoH survey, placing of SDoH referrals, or follow-up calls on pending referrals. [Fig. 4] is a separate SHIP visual codesigned with CHWs that quickly summarizes a patient's responses to an SDoH survey, indicating the type of follow-up needed and providing details on any referrals previously placed (including the email of the clinic and staff who placed the referral).

Fig. 3 SHIP visual organizing SDoH follow-up needed for patients (data presented in the figure are imaginary).

Fig. 4 SHIP visual summarizing patient SDoH survey results and referrals (data presented in the figure are imaginary).

Our team also had monthly and ad hoc meetings with clinic IT teams to design, develop, and test SHIP. Key IT members provided iterative feedback on SHIP's design, security, features, and visuals, and these meetings were crucial in assuring adherence to SHIP project timelines while balancing our goals with the IT teams' other day-to-day priorities. By providing the technical teams insight into clinical priorities, workflow, and everyday tasks—and similarly sharing the technical development process with clinical staff—we engaged in the process of codevelopment and were able to approach individual tasks guided by the project's larger shared goals and constraints, promoting a shared sense of ownership over the end product. As one focus group participant said, “I think SHIP is helping break down silos… being able to get this group together and share practices and share some of the challenges […] that's trying to move us in the right direction.” [Table 4] provides preliminary data on the number of hours spent by clinical staff in piloting SHIP to inform the display of linked data in clinical workflows.

Table 4 Clinician and CHWTesting and adoption of SHIP to view SDoH alerts and visuals in clinical workflows

	Total hours spent in SHIP	Total no. of log-ins to SHIP	Total no. of SHIP dashboards launched
October–December 2021	224.4	112	327
January–March 2022	113.9	104	278
April–June 2022	89.3	92	274
July–September 2022	152.0	205	548

Abbreviation: SHIP, social health information platform.

Discussion

While the focus and increased funding for SDOH integration into clinical care is a welcome policy direction, the dearth of successful examples of such integrations is a challenge for future adoption. The implementation strategies and data architectural designs piloted in our study are an important contribution because (1) they are scalable and replicable in other communities; (2) they reduce the burden on the clinic IT team by using APIs for data exchange, reducing the burden of integration on IT teams at individual organizations; (3) they do not rely on individual EHR integrations both to extract and display clinical information in the clinical workflow. SHIP was able to harmonize, link, and aggregate data regardless of the data source (e.g., multiple EHRs, social service referral platforms, Structured Query Language exports, and comma-separated values); (4) SHIP implementation and use by physicians and CHWs in clinics demonstrates the need to include end users and codesigners of the platform early on; and (5) the use of PPRL and limited datasets may help reduce the legal and compliance complications that delay projects with multiple stakeholders and enterprises. SHIP provides an interoperable steppingstone toward easier integration of SDoH data into EHRs and other workflows via the HIE, smoother coordination and follow-up on services between clinical providers and social service providers, ability to customize features based on each partners' capacity and specific job role, and eventual alignment with payers and policymakers via secure population-level reporting and streamlined standards compliance. Such efforts are never merely informatics solutions—they require a community-wide collaboration, dialog, and alignment, led by the end users and affected patients. The governance of such platforms and data-sharing agreements go well beyond the legal requirements under HIPAA to deliver the improvements in population health promised by data sharing and care coordination.

Recommendations

The following are key recommendations for future community SDoH data initiatives like SHIP, based on our multiyear work with the community successfully piloting SHIP in clinical settings:

• Using an LDS as your data source allows for greater flexibility in how you use the data. SHIP's visuals included aggregated data for patient data from the HIE without requiring a SHIP-specific consent, while still allowing us to collect a SHIP consent before displaying PHI or any patient-level visuals. The LDS structure also allowed us to begin our pilot quickly, without requiring new data-sharing agreements between partners. By leveraging existing HIE consents, partner agreements, and clinics' contracts with findhelp, SHIP was able to provide the maximum amount of value from the data and stay nimble. We also benefited from exchanging data early on so that we could work out schema, data transit, and data storage issues well before transmitting real patient data.

• Developing visuals and features that help manage the quick-pace and fast-changing priorities of clinics is extremely useful. Front-line staff members were very interested in SHIP's SDoH pop-up alerts (SideKick) because they alerted to possible SDoH needs as part of their normal documentation workflow (i.e., opening a patient file in their EHR) and gave the option of clicking to see a full SHIP visual or ignoring the pop-up until it disappears. Clinicians reported not having enough time to view SDoH data visuals but appreciated a quick pop-up reminder regarding social needs so they could have another staff work with the patient before leaving the clinic. CHWs reported that SHIP's “worklist” visuals ([Fig. 3]) were especially helpful, providing a simple, organized workflow of patients who needed an SDoH assessment, an SDoH referral, and a follow-up on an SDoH referral.

• Having an HIE serve as the main data aggregator provides crucial infrastructure and predictability in terms of data quality and security. An HIE backbone helped ensure the clinical data followed a standardized schema, including expectations regarding the accuracy, completeness, and timeliness of data. We were able to test and innovate on ideas quickly by building off of the established data-sharing agreements, community trust, and legal partnerships of the HIE. We were also able to use the HIE to help standardize some data definitions across partners, for example, agreeing on common definitions of what determines a “successful” versus “unsuccessful” referral, and how referral details should be documented. It was also crucial that we used nationally recognized data standardization and interoperability approaches (e.g., Gravity SDoH standards and Fast Health Interoperability Resources, from HL7, a standards developing organization) so that SHIP is portable and scalable for future communities and datasets.

• PPRL allowed us to link patient's clinical data quickly and accurately with their SDoH data and test data linkage opportunities without sending PHI. Having project managers that could understand the data elements needed to create encrypted tokens and translate that to documentation processes in clinics was crucial to improving the records matched rate over time. We also found it helpful to do a “data fill rate” analysis early, to see which elements of the data tokens (e.g., date of birth, email) were present in our datasets, and then did a round of sending and linking dummy data to test PPRL tools before go-live. While PPRL showed to be an invaluable tool for securely matching patients across disparate data sources without transferring identifiable PHI, health care sector solutions that match and deduplicate patients using PHI (e.g., Enterprise Master Patient Index or EMPI) are still more robust and reliable in their ability to match and link.

• Be collaborative, humble, and patient when collaborating with clinic staff to develop new health technologies. Health care workers are crucial to the success of any public health intervention or health technology. Truly treating them as experts in patient care keeps them engaged and enthused in research projects. It is important to release mockup visuals early and often to the users so they see results and know that you are working to improve their work experience based on their input. Users also reported appreciating the collaboration with the Dell Medical School research team because we proactively communicated milestones while demonstrating consideration for short-term project delays so that clinic or IT staff could focus on other priorities as needed (e.g., patient and technology emergencies). Clinic staff reported that it was helpful to have research team members with clinical experience who could empathize with their job pressures, motivations, and the severity of patients' needs.

Limitations

The following are barriers we encountered as part of the SHIP pilot, with suggestions for possible areas of future research and development.

• The limitations of doing human-subjects research under an IRB made it difficult to fully pilot SHIP as part of the normal, everyday clinic workflow. Because SHIP patient-level visuals and alerts required a SHIP-specific consent, staff could not seamlessly use SHIP with whatever patients walked in the door each day, and instead had to mindfully set aside time to “test” SHIP with a specific consented subset of their caseload.

• There is still no common and comprehensive taxonomy for SDoH needs, which limits the ability of SHIP-like projects to scale and produce meaningful data visuals across platforms and partners. Our project utilized findhelp's “Open Eligibility Project”[27] taxonomy for SDoH data and mapped SDoH assessments to the Gravity Project's SDoH taxonomy,[28] but there is a myriad of taxonomies being used which only further complicates SDoH data collection, sharing, and harmonization.

• The SHIP pilot was limited by the type of SDoH data that staff were able to document in findhelp. While we were able to successfully track the final disposition of individual referrals (i.e., “closing the loop”), a patient may receive a successful referral but still have an ongoing need in that SDoH area. While SDoH surveys are helpful in estimating base-level needs at scale and SDoH referrals are helpful in estimating whether patients' SDoH needs were resolved, survey and referrals tracking software are still no substitute for the more detailed information staff get when they have a conversation with patients.

• While the SHIP pilot was able to analyze trends in clinical utilization and whether SDoH services met reported needs, our pilot study did not focus on evaluating the effectiveness of SHIP in terms of direct impact on client health outcomes.

Conclusion

The SHIP pilot demonstrated that linking patient records across disparate sectors, data sources, and organizations is possible and that linked data can be used to create patient-level and community-level visuals and alerts that give insights into social and clinical gaps and successes. By building our system on existing data sharing agreements and data sources (HIE and findhelp) and using a combination of LDS, PPRL, and nationally recognized data standards to share data quickly and securely, we were able to rapidly iterate on our initial design and provide clinic staff with an SDoH coordination solution that was designed by them and worked flexibly within existing workflows.

Clinical Relevance Statement

This study provided insights and recommendations into how communities can navigate the most common technical and legal hurdles around cross-sector data sharing, storage, and linkage so that future “community data connectivity” projects are able to move quicker and with fewer delays. A combination of PPRL, limited datasets, and an HIE-supported infrastructure combined with user-driven design and testing allowed SHIP to rapidly reiterate its design to meet the specific day-to-day priorities and resource limitations of clinics. This study found that user-centered design was integral to our health technology garnering engagement, inspiring enthusiasm for adoption, and creating a sense of respect and openness to provide genuine feedback and new ideas.

Multiple-Choice Questions

1. What is the name of the national effort to develop standard codes to help store and send Social Determinants of Health data?

   • Gravity Project

   • FHIR

   • LOINC

   • ICD-10

   Correct Answer: The correct answer is option a. Founded in 2019, the Gravity Project is a national collaborative effort led by the Office of National Coordinator for Health IT, with the goal of developing, testing, and standardizing SDoH data for use in patient care coordination and population health initiatives. The choices besides Gravity Project are all focused on clinical data standards. Fast Health Interoperability Resources (FHIRs) are a set of federally mandated standards for exchanging health care data between different systems. Logical Observation Identifiers Names and Codes is the international standard for documenting, storing and exchanging clinical laboratory, clinical observation, and health measurement data. The International Classification of Diseases Tenth Revision is another clinical classification system that focuses specifically on diagnosis codes that represent specific conditions, diseases, injuries, or health problems.

2. Which of the following is considered a social determinant of health?

   • Asthma

   • Obesity

   • Safe housing (e.g., no mold or other allergens)

   • Diabetes Type 1

   Correct Answer: The correct answer is option c. Social determinants of health are defined as the social and environmental (i.e., non-clinical) factors that impact an individual's health and wellness. A lack of transportation to pick up prescription medications or a moldy house that continually activates asthma symptoms are examples of how SDoH can directly impact one's ability to get and stay healthy. Clinical diagnoses like asthma or obesity are often caused or exacerbated by social determinants of health (e.g., exposure to household allergens or an inability to access or afford healthy foods), yet they are not considered SDoH.

3. While developing successful health technologies is a joint effort between many groups, who should lead the design to determine what the clinic health technologies look like and how they work?

   • Technical staff (e.g., developers and data analysts)

   • Funders (e.g., local governments and philanthropist organizations)

   • Clinic staff (e.g., CHWs and physicians)

   • Research staff (e.g., academics and evaluators)

   Correct Answer: The correct answer is option c. Developing and improving health technologies is a collaborative effort between all the staff listed above, but clinic staff should lead the actual development and refinement process because they have the most pragmatic and rich insight into data needs, bottlenecks in workflow and documentation, frustrations with existing technologies, and day-to-day clinic priorities. Funders, research staff, and clinic leadership (e.g. chief medical information officers, directors of IT) are instrumental in setting the overarching vision and goals of a new health technology, and technical staff are essential in determining the feasibility of and process for implementing any suggested features, but clinic staff are uniquely positioned to use their expertise and every-day experiences to guide the design and adoption of new technologies. With their real-world experience navigating systems of care and coordinating social referrals for patients, CHWs are particularly essential leaders in developing useful and usable digital tools that address SDoH.

4. Who is mostly likely to benefit from a shared, standards-based clinical and social data platform like SHIP?

   • Patients

   • Physicians

   • CHWs and social workers

   • All of the above

   Correct Answer: The correct answer is option d. Due to a myriad of legal, regulatory, and technical barriers, coordinating care between the health care system and social service providers is often very difficult and time-consuming. Duplicative services and surveys and inefficient care coordination places an increased burden of time an effort on the patients, social workers, and CHWs who are trying to coordinate social services, increases physician frustration regarding clinical interventions that fail due to unaddressed SDoH needs and ultimately delays treatment. Digital platforms like SHIP that leverage existing data sharing agreements, data utilities (e.g., HIEs), and national data standards (e.g., Gravity Project and FHIR) to improve community-wide data sharing present a scalable solution for solving some of the most common barriers to efficient cross-sector care coordination.

Conflict of Interest

Eliel Oliveira and Anjum Khurshid are cofounders of Pulsar LLC which is a company that provides health IT services.

Protection of Human Subjects

This study was performed in compliance with federal regulations regarding personally identifiable health information, the University of Texas at Austin's Information Security Office (ISO) testing and review policies, and the University of Texas at Austin's Institutional Review Board (IRB) for Human Subjects Research (Protocol Number 2020–04–0067).

^a Also known as “social drivers of health” or “non-medical drivers of health (NDoH).”

• References

• 1 Healthy People 20230. Healthy People 2030 Framework. Office of Disease Prevention and Health Promotion. Accessed August 08, 2023 at: https://health.gov/healthypeople/about/healthy-people-2030-framework
• 2 Constitution of the World Health Organization. World Health Organization. Accessed August 08, 2023 at: https://www.who.int/about/governance/constitution
• 3 Magnan S. Social Determinants of Health 101 For Health Care: Five Plus Five. NAM Perspectives. Discussion Paper. Washington, DC: National Academy of Medicine; 2017.
• 4 Hood CM, Gennuso KP, Swain GR, Catlin BB. County health rankings: relationships between determinant factors and health outcomes. Am J Prev Med 2016; 50 (02) 129-135
• 5 Sallis JF, Owen N, Fisher EB. Ecological models of health behavior. In: Glanz K, Rimer BK, Viswanath K. eds. Health Behavior and Health Education. 4th ed.. San Francisco: John Wiley & Sons; 2008: 465-485
• 6 Chen M, Tan X, Padman R. Social determinants of health in electronic health records and their impact on analysis and risk prediction:a systematic review. J Am Med Inform Assoc 2020; 27 (11) 1764-1773
• 7 Solomon LS, Kanter MH. Health care steps up to social determinants of health: current context. Perm J 2018; 22: 18-139
• 8 Assistant Secretary for Public Affairs (ASPA). HHS offers states flexibility to better address Medicaid enrollees' needs. HHS.gov. Accessed August 08, 2023 at: https://www.hhs.gov/about/news/2023/01/04/hhs-offers-states-flexibility-to-better-address-medicaid-enrollees-needs.html Published January 4, 2023.
• 9 HHS Offers States Flexibility to Better Address Medicaid Enrollees' Needs. CMS. Accessed August 08, 2023 at: https://www.cms.gov/newsroom/press-releases/hhs-offers-states-flexibility-better-address-medicaid-enrollees-needs Published January 4, 2023
• 10 Gold R, Bunce A, Cowburn S. et al. Adoption of social determinants of health EHR tools by community health centers. Ann Fam Med 2018; 16 (05) 399-407
• 11 Institute of Medicine (US) Committee on Quality of Health Care in America. Crossing the Quality Chasm: A New Health System for the 21st Century. Washington, DC: National Academies Press; 2001. PMID: 25057539.
• 12 Gruß I, Bunce A, Davis J, Dambrun K, Cottrell E, Gold R. Initiating and implementing social determinants of health data collection in community health centers. Popul Health Manag 2021; 24 (01) 52-58
• 13 National Academies of Sciences, Engineering, and Medicine. Integrating Social Care into the Delivery of Health Care: Moving Upstream to Improve the Nation's Health. Washington, DC: The National Academies Press; 2019. https://doi.org/10.17226/25467
• 14 Crawford A, Serhal E. Digital health equity and COVID-19: the innovation curve cannot reinforce the social gradient of health. J Med Internet Res 2020; 22 (06) e19361
• 15 Rosenbloom ST, Denny JC, Xu H, Lorenzi N, Stead WW, Johnson KB. Data from clinical notes: a perspective on the tension between structure and flexible documentation. J Am Med Inform Assoc 2011; 18 (02) 181-186
• 16 Freij M, Dullabh P, Lewis S, Smith SR, Hovey L, Dhopeshwarkar R. Incorporating social determinants of health in electronic health records: qualitative study of current practices among top vendors. JMIR Med Inform 2019; 7 (02) e13849
• 17 Cantor MN, Thorpe L. Integrating data on social determinants of health into electronic health records. Health Aff (Millwood) 2018; 37 (04) 585-590
• 18 Rousseau JF, Oliveira E, Tierney WM, Khurshid A. Methods for development and application of data standards in an ontology-driven information model for measuring, managing, and computing social determinants of health for individuals, households, and communities evaluated through an example of asthma. J Biomed Inform 2022; 136: 104241
• 19 Tomar D, Bhati JP, Tomar P, Kaur G. Chapter 2 – Migration of healthcare relational database to NoSQL cloud database for healthcare analytics and management. ScienceDirect Published January 1, 2019. Accessed September 25, 2023 at: https://www.sciencedirect.com/science/article/abs/pii/B9780128153680000026
• 20 Bakken S. Can informatics innovation help mitigate clinician burnout?. J Am Med Inform Assoc 2019; 26 (02) 93-94
• 21 Glasgow RE, Harden SM, Gaglio B. et al. Re-aim planning and evaluation framework: adapting to new science and practice with a 20-Year review. Front Public Health 2019; 7: 64
• 22 Gaglio B, Shoup JA, Glasgow RE. The RE-AIM framework: a systematic review of use over time. Am J Public Health 2013; 103 (06) e38-e46
• 23 What is a Limited Data Set Under HIPAA? HIPAA J 2023. Accessed August 08, 2023 at: https://www.hipaajournal.com/limited-data-set-under-hipaa/
• 24 Kiernan D, Carton T, Toh S. et al. Establishing a framework for privacy-preserving record linkage among electronic health record and administrative claims databases within PCORnet^®, the National Patient-Centered Clinical Research Network. BMC Res Notes 2022; 15 (01) 337
• 25 Vatsalan D, Sehili Z, Christen P, Rahm E. Privacy-preserving record linkage for big data: current approaches and research challenges. Handbook of Big Data Technologies 2017; 851-895
• 26 Dabbs ADV, Myers BA, Mc Curry KR. et al. User-centered design and interactive health technologies for patients. CIN: computers, informatics. Nursing. 2009; 27 (03) 175-183
• 27 The Open Eligibility Project. findhelp. Accessed August 08, 2023 at: https://support.findhelp.com/hc/en-us/articles/4404055283227-The-Open-Eligibility-Project Published January 10, 2023
• 28 Dieterle R. The Gravity Project. HITAC Interoperability Standards Priorities Task Force 2021 Presentation. Accessed August 08, 2023 at: https://www.healthit.gov/sites/default/files/facas/2021-04-08_Gravity_Project_Presentation.pdf Published April 8, 2021

Publication History

Received: 20 March 2023

Accepted: 21 July 2023

Article published online:
08 November 2023