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.
