Open City Labs

Redefining Care Coordination

7 Steps for States Seeking to Advance Healthcare Data Exchange & Address the Social Determinants of Health (at lower cost)

Last August I was part of a Summit of healthcare, social care providers, and government leaders in the Midwest. They were seeking to impact State policy to address health related social needs. I spoke on a panel to provide a national context for what other states were doing with 1115 Waivers and how states were investing in SDOH, and the complex interoperability landscape. As I began drafting my recommendations, it occurred to me that most states are in similar situations:

  • They lack the 1115 Waiver to provide massive new funding that you might see in New York, California, or North Carolina.
  • The state health information exchange is interested in a Social Determinants of Health pilot but so far doesn’t have that experience yet.
  • There isn’t (yet) the political will for a major infusion of money across lots of programmatic domains.

In other words, what policy changes and systems level investments do states need to consider so they will have a sound foundation to build on?

This blog post will focus on how to procure technology and in particular interoperability in a way that leverages and builds on national legislative and regulatory requirements. In addition to State Department of Health and Medicaid staff, it has particular relevance for Health Information Exchanges (HIEs)/Health Information Networks (HINs).

The Urgency of a Complete Medical Record, Care Coordination and Service Access

Medical errors remain the 3rd leading cause of death (after heart disease and cancer), even 21 years after the National Academy of Medicine published “To Err is Human.” The top 10% of hospitals are 10X safer than the bottom 10%. The Institute of Medicine defined a medical error as “”the failure of a planned action to be completed as intended or the use of a wrong plan to achieve an aim.” Why has the country failed to reduce avoidable medical errors despite having some of the best Academic Medical Systems in the world?

One major driver is the lack of a complete medical record. The average American has had about 19 doctors over the course of their life, or 28 by the age of 65. Because these doctors use a wide variety of systems, which aren’t always able to exchange data (aka interoperability). Research also shows that patients cannot be counted on to have a reliable memory of their medical history.

Why Market Based Approaches to Interoperability without Regulation Requirements are Failing

Market incentives alone often cut against the motivation to solve interoperability challenges. Integrated health systems typically use a single system, or set of products owned by the same technology company and seek to provide all of the medical services a patient needs. Making it easy for patients to access their medical records outside of the health system could increase the likelihood that patients seek care outside the health system.

Technology companies face similar incentives. Absent regulatory mandates, the largest Health, Social Service and Government tech vendor incumbents, seeking to gain more market share, have little incentive to make it inexpensive and easy to exchange data to their competitors’ systems. Indeed, they argue, a major value proposition of adopting their software is to easily refer and exchange data with other customers of that vendor. Or when data sharing is made available across systems, proprietary data standards and vendor ownership of data embedded in contracts fosters vendor lock-in, and higher software costs.

Or as Lauren Wetterhahn, Executive Director put it quite directly when referring to her community based organization staff, “We find ourselves using systems where we are not able to get the data that our team has entered into the system, out of the system.”

Regulatory Response and Opportunities to Advance Interoperability and Service Access

The 21st Century Cures Act, and subsequent Final Rules issued take a number of steps to: (a) Promote Interoperability, and (b) Patient Access to Health Data. It prohibits information blocking, which is defined as a practice that:

  • Not required by law
  • Not covered by an exception
  • Likely to “interfere with” access, exchange, or use of electronic health information (EHI) and
  • Is Healthcare Providers, Health IT Developer or Certified Health IT, and Health Information Network (HINs), or Health Information Exchange.

Information Blocking requirements for HINs require responding to the United States Core Data for Interoperability (USCDI v1) requests and by May 2, 2022 onward actors are obligated to exchange ALL electronic health information in response to requests from actors involved with treatment payment and operations.

Health IT Developers or Certified Health IT systems have certification overseen by the ONC Health IT Certification Program. As of the HTI-1 Final Rule in January 2024, USCDI V3 becomes the relevant minimum data set that all Certified Health IT systems must support, alongside SMART App Launch HL7® FHIR® US Core IG STU version 6.1.0. USDI V3 includes the ability to support Social Determinants of Health Assessments, Problems/Health Concerns, Referrals and other Interventions by January 1, 2026.

In other words, Health Information Exchanges, Certified EHRs and Healthcare Providers need to have in place a means to exchange SDOH data statewide by January 1, 2026.

Should More Actors Be Designated Health Information Networks (HINs)/Health Information Exchanges (HIEs) and Subject to Information Blocking Provisions?

While this determination will depend on the specific organization, it is worth looking at the Final Rule which defines HINs and HIEs:

an individual or entity that determines, controls, or has the discretion to administer any requirement, policy, or agreement that permits, enables, or requires the use of any technology or services for access, exchange, or use of EHI: (1) Among more than two unaffiliated individuals or entities (other than the individual or entity to which this definition might apply) that are enabled to exchange with each other; and (2) that is for a treatment, payment, or health care operations purpose… In consideration of comments, we also narrowed the definition in three ways.

Wow, that’s a mouthful! Let’s break it down. To determine if an entity is an HIN/HIE do they:

EHI Handling – Manage or Facilitate Electronic Health Information (EHI) belonging to two or more unaffiliated entities?

Control over Exchange – Do they set requirements, policies, or agreements that govern how EHI is accessed, exchanged or used by other entities?

Purpose of Exchange – Is the exchange of EHI facilitated for treatment, payment, or healthcare operations purposes?

Under the “Treatment” purpose mentioned above, if a patient is receiving care at a social care provider would social care providers (and the referral platforms/community information exchanges) be required to share the information with other clinical or social care providers involved in the patient’s treatment?

Yes.

In 2018 the Office of Civil Rights (OCR) provided guidance that specifically described social needs data falls under Protected Health Information (PHI) for treatment purposes. This guidance offers two examples:

Without authorization:

health care providers who believe that disclosures to certain social service entities are a necessary component of, or may help further, the individual’s health or mental health care may disclose the minimum necessary PHI to such entities without the individual’s authorization. For example, a provider may disclose PHI about a patient needing mental health care supportive housing to a service agency that arranges such services for individuals.

With authorization:

Thus, providers could in one authorization identify a broad range of social services entities that may receive the PHI if the individual agrees. For example, an authorization could indicate that PHI will be disclosed to “social services providers” for purposes of “supportive housing, public benefits, counseling, and job readiness.”

Categorizing Assessment Data and Fine Grained Consent

At Open City Labs our vision has been to enable healthcare, social care providers, and government agencies to seamlessly connect people with the services to advance health and well being, while getting the right information to the right person involved in a person’s care at the right time, while protecting patients’ wishes on where their data goes. As part of this we AI to organize a Patient’s data, which can be pulled up as the individual assessments/forms,

Navigator360 Displaying Patient Data Unified by Questionnaire or Assessment Sections

or unified across assessments/forms into Categories or Sections:

Navigator360 Displaying Patient Data Unified by Categories and Sections

Capturing and modeling data on this level of granularity enables us to enforce consent.  It also supports role based access to people (e.g. Case Manager) or an entire organization, more dynamically enforcing “minimal necessary” provision. Open City Labs is committed to tracking enforcing patient consent in ways that go beyond the minimum requirements of the law.

That being said, there are significant opportunities for States to leverage health information exchange data and integrated eligibility to proactively inform patients that they are likely eligible. As I wrote in this previous blog post, enrolling people in programs like SNAP and WIC for government benefits via APIs, so that local community based organization navigators don’t have to reenter the data in their system in government forms multiple times. These and other programs are 100% covered by federal government budgets, while providing the added benefit of reducing Medicaid expenditures by keeping patients healthy. For example:

  • Supplemental Nutrition Assistance Program – Enrollment in SNAP, a food subsidy program has been shown to reduce healthcare costs ($1,400-$4,100 per person annually). Yet just 42% of eligible older adults are enrolled in SNAP.
  • Special Supplement for Women Infants and Children (WIC) – WIC has been shown to reduce the likelihood of preterm birth by 48%, saving $58,917 per preterm birth (in healthcare costs for the baby and mother). Yet only 50% of eligible people are enrolled in WIC nationwide.

Open City Labs has leveraged AI/Machine Learning to map eligibility requirements for 227 government program (e.g. SNAP, WIC etc.) across 35 government agencies, and PDF form data for 63, so that information entered in one form or pulled in from a health information exchange can automatically be reused when someone is applying for multiple programs.

Recommendations for States

Existing recommendations provide enforcement mechanisms for information blocking, which involve the HHS Office of Inspector General reviewing complaints on a case by case basis. Even without 1115 waivers states have significant levers to strengthen their hand when procuring technology:

Require Data Standards Adoption for New Procurements & Reporting

Building on an existing standard like the way New York State built on the Gravity Project’s SDOH Clinical Care Implementation Guide offers several advantages:

  • Open Standards provide clear definitions of interventions that can be evaluated for their effectiveness, providing reproducible results that can inform policy and program design.
  • Free and Open Standards reduce interoperability costs by preventing friction and making it easier for vendors to adopt, while growing the number of software engineers with experience building to that standard.
  • Standards bodies have built in staff, expertise, and vendor and community participation.
  • Standards processes have existing processes for providing frameworks and governance for testing and providing feedback on standards. Connectathons are events where vendors integrate in testing environments and provide feedback for continuous improvements.
  • There are existing processes for improving and versioning the standards as more is learned about what data is needed from professionals and community members alike.

Provide a Useful Level of Standards Specificity

While previous California Healthcare Policies have required standards for other data exchange use cases, these policies have not been specific enough to reduce the cost or time it takes to achieve interoperability. A conversation with the Executive Director/CEO of one of the QHIOs about what keeps them up at night went something like this, “I have several hundred integrations to complete and not one looks like another.” For example, too many and or inadequately detailed policies might not specify the profile or the version of the standard.

Inadequate Detail: “Fast Healthcare Interoperability Resources (FHIR)”

Adequate Detail: “Fast Healthcare Interoperability Resources (FHIR) US Core Implementation Guide (IG) 4.0 FHIR Version 4.01”

Issue guidance to relevant government agencies to identify potential standards in their domains–the services that address SDOH come from a wide variety of government agencies.

Go Statewide with Patient Access to their Own Data (Be Bold)

Whereas the “Patient Access” provisions of the Patient Access Final Rule apply to CMS regulated Medicare Advantage (MA), Medicaid, Children’s Health Insurance Program (CHIP), and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs), two states, California and Tennessee have led the way in extending the same requirements to all health plans (public and private) registered in their state. These provisions would require all claims data to be made available via an API, so that patients could access their medical data in an app of their choice. Apps would have to go through a registration process to pass privacy and security requirements.  Patient’s would have to prove their identity before accessing their medical data.

Altogether, these regulations, enabled by open standards, creates a dynamic market place. Healthcare providers and Health IT Systems can compete based on innovative features and design, without market share being captured by the organizations that own the most data.

In advancing Provider and Patient Access to data, it is important to note the extensive safeguards California put in place to protect patient privacy:

* Any criminal justice information provided by jails may include release dates, incarceration dates, and limited demographic information such as name, date of birth, sex, and race, but does not consist of the full criminal history of an Enrollee or a criminal identification and information (CII) number…

To ensure health information made available to providers to better coordinate care and improve treatment is not used for other purposes:

• Providers sharing information under CalAIM are not subject to: (1) the Violence Against Women Act (VAWA) or similar federal laws limiting the disclosure of information related to domestic violence providers; or (2) the Family Educational Rights and Privacy Act (FERPA). VAWA and FERPA often require an individual’s consent for disclosures, even in cases where such consent is not required under HIPAA.

Patient Safety is prioritized if data sharing could do harm.

• Psychotherapy notes, as defined under HIPAA, are not disclosed.

And HIPAA of course.

Any disclosures that occur are made in compliance with all applicable security requirements, including the requirements of the HIPAA security rule… data sharing entities exchanging PII have undergone all legally required privacy and security training, including HIPAA training, if applicable.

Ensure Regulatory Compliance for the above recommendations

As regulatory enforcement gets underway, it is unclear how comprehensive the HHS Office of Inspector General will be, particularly in an underfunded organization. While 21st Century Cures Act’s Information Blocking and Patient Access has laid the groundwork, states have an opportunity to pass their own legislation that strengthens regulatory enforcement, or outline procurement requirements for statewide technology procurements.

For states with 1115 Waivers, or In-lieu-of-services provisions under Medicaid to deliver, for example, nutrition supports, the establishment of a “Participant Directory” could serve as a means of tracking compliance with Information Blocking and Patient Access API requirements, while also lowering the costs of interoperability for integration partners.

For participants in California’s 1115 Waiver, an example of this can be found in the details of a CalHHS Data Exchange Framework Policy and Procedure regarding the subject “Participant Directory” (Policy OPP-14). This policy provides requirements for:

“updating, storing, and communicating certain information concerning the network(s), health information organization(s), or technology(ies).”

The importance of a Directory’s accuracy has implications that go straight to the heart of whether Care Coordination and service access is successful.  It directly impacts the trust of patients and providers in the system. Patients who are provided with information about services that are no longer available, or for which they are not eligible can easily become disaffected and lose trust in the agencies seeking to help them. Put another way, absent eligibility information and accurate directory data providers will make inappropriate referrals.

The current policy requires providers/participants in CalAim to list basic organization, and service details.  This includes the name of the vendor of the system they use and contact information for the technology team responsible for troubleshooting. While this inclusion of technology team contact information (e.g. Joe Smith, Epic) in the Participant Directory is a clear innovation in comparison to what exists in much of the rest of the country, it falls short of what it could be, and the objective of the Office of the National Coordinator for Health IT’s objective of “interoperability with little additional effort.” To oversimplify, imagine different email providers Gmail, Yahoo etc. required point-to-point integration that cost a lot of money to send emails across systems, and you were designing a way to look up how to email an old friend of yours. You can think of the Participant Directory as a directory of Customer/Tech Support numbers/emails for the people at Gmail/Yahoo etc., instead of a Contacts with the person’s email address, whom you were trying to email.

Improving Directory Accuracy and Requiring Endpoints for Procured Technology

Endpoints one piece of technology discovers the location of another technology, and provides instructions on what kind of data it supports and how to exchange that data, along with data security requirements (in a way understandable by machines and software engineers).

You have probably heard of the 80/20 rule, where 80% of the effort only gets you 20% of the progress, whereas 20% of the effort gets you 80% of the progress.

Here are the key takeaway.

While no state to my knowledge that has fully achieved the dream of cross agency interoperability (Health, Social Services, School etc.) to enable person centered care and integrated service delivery, the 20% of effort from an interoperability perspective is in the following:

  1. Formalizing that the 21st Century Cures Act does consider Social Care Referral Platforms as Health Information Networks and are subject to information blocking provisions, or issuing regulations or procurement requirements that amount to the same.
  2. Extend Patient Access API requirements to all health insurance plans to super charge a dynamic app ecosystem for patient access to their own data (as California and Tennessee already have).
  3. Requiring standardized endpoints to be included and maintained as part of a Participant Directory, and enforcing information blocking as a combination of (a) the presence of the endpoints, and (b) some measure of complaints and mediation windows for those endpoints working.
  4. Aligning procurement requirements for technology around open standards for a Person’s identity (see the work of the CARIN Alliance), so that records are located and consent tracked.
  5. Aligning procurement requirements for technology around consent technology or at least a common standard for representing consent data across differing agency and program regulations (e.g. HIPAA, FERPA, 1115 Waiver, SNAP, WIC etc.).
  6. Prohibiting vendor data ownership provisions in contract requirements that prevent flexibility in future tech procurements, avoiding vendor lock-in.
  7. Providing a means for other systems to subscribe to updates to a Statewide Participant Directory, so that directory updates are propagated to other systems instantaneously, and providers only have to update their information in one place.

Recommendations 1-6 will have minimal costs for states and can set up all state agencies for future procurements of systems that are interoperable at lower costs.

States considering approaches to improving directory quality and reducing the cost of interoperability can reach out to Open City Labs at ([email protected]) for a free consult to better understand their options, and why directory federation is such a critical part of the solution.

Provide Funding to Enable Data Exchange and Improve Service Access

As I note in my first blog post/newsletter on the role of policy and data standards in shaping tech impact on health equity: people, processes, programming, and cross-sector partnerships and the funding to address the clinical, behavioral and social determinants of health are all upstream of interoperability infrastructure and data standards. People’s experience of care delivery and how technology is used is downstream of the invisible infrastructure that transports data to their systems. If policymakers want to advance health and well-being and reduce Medicaid costs they can begin that process with targeted regulatory and procurement requirements at modest costs, and scale their investments in both the community based organizations, programming, partnerships and infrastructure for open standards based interoperability as more funding becomes available.

How to Advance Health Equity and Address Social Determinants of Health – Role of Policy and Data Standards in Shaping Tech Impact

Matt Bishop is CEO of Open City Labs, an award winning digital health company that develops software to streamline enrollment in government benefits, social services and clinical care, while unifying patient data in integrated Care Plans. Open City Labs was the first to implement in production the Gravity Project’s FHIR SDOH referral standard and is recognized as a Success Story by the Gravity Project. Open City Labs was the winner of the Administration for Community Living’s Social Care Referrals Challenge and Bonus Challenge, which tackled the need for referral interoperability across systems. He is a member of the HIMSS Social Determinants of Health Committee and HIMSS Health Equity Pre-conference active contributor to numerous ANSI accredited standards bodies, including Health Level Seven International, The Gravity Project, the co-author of the IHE International‘s 360x-SD (SDOH closed loop referral), National Directory for Healthcare Providers and numerous subcommittees within DirectTrust.


Stay up to date, sign up for our monthly email