by Brian D. Handspicker
Co-Chair, HL7 Human and Social Services WG (HSS); Chair, DirectTrust Information Exchange for Human Services CB (IX4HS); Technical Advisor, Center on Excellence for Alignment of Health and Social Care; Fellow, National Interoperability Collaborative

This post builds upon a recent blog by Lisa Nelson, Fractional Chief Technical Officer, “FHIR Over Direct: Accelerating the Pace toward Trusted, Scalable Interoperability,” by exploring how the same approach of FHIR Over Direct can be applied to socialcare — a critical but often underrepresented component of health and well-being.

Socialcare, provided by human and social services organizations, is a natural complement to healthcare. Health Related Social Needs (HRSN), also known as Social Determinants of Health (SDOH), can account for 60 to 80 percent of an individual’s health and well-being.

Unfortunately, while healthcare has decades of experience defining, implementing and using standards for electronic health record interoperability and information exchange, socialcare has no formal standards and only a few de facto standards, such as the OpenReferral directory API, the Department of Housing and Urban Development’s Homeless Management Information System (HMIS) API, and the 211 Human Services Indexing System (211HSIS).

The Gravity Project has been defining standard codes for SDOH conditions and standard Fast Healthcare Interoperability Resources (FHIR)-based referral workflows to allow healthcare practitioners to diagnose and refer patients for socialcare services to treat these conditions.

One could consider the current socialcare situation as being similar to the state of electronic healthcare records of the late 1960s: there are various systems that support electronic socialcare records, but no standard ways to represent or exchange them.

There have been some local and/or very narrow attempts to define socialcare standards based on the National Information Exchange Model, but they never came to full fruition.

With the healthcare industry requirement to screen for HRSN, there is new impetus to define standards for socialcare. If we were to take a greenfield approach to defining those standards, experience would suggest that it would take a couple of decades to define, get vendors to implement and have users adopt a new bespoke set of standards. But given the close relationship between socialcare and healthcare at the intersection of HRSN, we could make faster progress creating socialcare standards if we were to adopt and extend standards based on FHIR.

There are a few challenges to this proposed approach.

  1. Socialcare business processes are not the same as healthcare. Socialcare is a very diverse collection of different programs and practices often defined independently – and sometimes incompatibly – by federal and state legislation, as well as by international, national, or local charitable organizations.
  2. Socialcare organizations lag healthcare in terms of software investment and sophistication. Referrals are more often delivered via phone, fax or email in non-standard formats.
  3. Socialcare organizations are underfunded and over-referred to for their service populations. They are hard-pressed to support their basic services, let alone invest in new standards-based software systems, support new security hardware and software, and train their employees in new processes and technology. They have not (yet) had the significant federal investment that healthcare has seen in the past 20 years that transformed healthcare interoperability standards and motivated adoption of electronic health records systems. Such investment will be as necessary for socialcare as it was for healthcare to enable standards-based modernization of socialcare.

There are barriers to the adoption of FHIR-based socialcare solutions by social services organizations. As noted above, the combination of under-funding and lag in software investment leaves social services organizations unable to afford new FHIR-based applications and ill-suited to adoption of new technologies that deviate from their long-standing workflows. In addition to the cost of new technologies and associated training, there is strong resistance from healthcare organizations to allow electronic access to their servers and the data they manage by anyone outside their organization, even if they are a formal Covered Entity or Business Associate, and even if there are formal patient consents that allow that access.

Treating HRSN will improve our population’s overall health and well-being and reduce our long-term health costs. But transitioning to FHIR-based standards will require stepwise adoption strategies as entire communities of service providers slowly and piecemeal come up to speed with FHIR-based systems.

One approach that could provide both an “on-ramp” to future adoption of FHIR applications and ease the organizational resistance to data access, would be to support new socialcare interoperability standards that allow the exchange of FHIR resource attachments to Direct Secure Messages based on Implementation Guides that mirror the workflow of FHIR RESTful transactions. This approach would allow implementers to make progress on the various socialcare-specific FHIR Resource Profiles and workflows needed to support specific user narratives and use cases. Transporting FHIR payloads or FHIR messaging transactions over Direct to simulate FHIR RESTful transactions offers a stepwise adoption strategy.

Those organizations that can afford FHIR applications and are sufficiently trusted to access partner FHIR servers can do so based on FHIR RESTful transactions. Those organizations that have not yet been able to invest in FHIR applications and/or are too small to warrant access to another organization’s FHIR servers, can still be supported “at arm’s length” with FHIR payloads in Direct Secure Messages.

This approach ensures that Covered Entities remain in tight control over their data by being able to properly vet any requests for information before pushing that information out electronically via Direct. Since all Certified Electronic Health Record Technology (CEHRT) systems are required to support Direct Secure Messaging, this would be a natural on-ramp for organizations to start exchanging FHIR-based data, while doing so in a workflow that is similar to their current email and fax-based processes. Then, when they can afford to invest in FHIR-based applications, both financially and in terms of changes to their workflows, the FHIR client data that they have accumulated through Direct messages can be imported into their new FHIR servers to pre-populate their FHIR database with information already provided in the needed FHIR formats.

Call-to-Action: To unlock the full potential of socialcare interoperability, we need to come together across both healthcare and socialcare domains to extend and evolve FHIR standards to support both healthcare to socialcare data exchange and socialcare to socialcare data exchange.

FHIR Over Direct offers a practical, cost-effective on-ramp for organizations that need a more incremental path forward. By simulating FHIR workflows through Direct Secure Messaging, we can accelerate standards adoption in real-world settings without requiring immediate investment in new APIs or infrastructure.

In addition, we should call on the federal government, through the ASTP/ONC, to “seize the moment” – aligning incentives, policy enablers, and funding to ensure the standardization for socialcare interoperability, vendor adoption of those standards, and ability of socialcare organizations to afford new interoperability-based software.

Join the DirectTrust Information Exchange for Human Services Consensus Body, the HL7 Human and Social Services Work Group, and the Gravity Project, as we work toward a comprehensive set of FHIR-based socialcare standards and accelerate their adoption through the use of FHIR Over Direct.