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.
