Trust in healthcare integration

Porting over old content with only slight grammar updates. Originally posted to Medium here in June 2019. Worth checking out, because the graphics are way better there.

---

This post represents a deep dive into how trust between different parties affects healthcare systems integration, dovetailing off of an initial Twitter thread.

Nope, not creepy at all.

Integration and interoperability are mission-critical to many companies and applications in the healthcare space. The advent of the electronic health record (EHR) has created data hubs around which all other applications orbit, dependent on that focal point as a planet is with the sun. Connecting to this data is an important part of the strategy for any company looking to sell in the healthcare space.

Much time and effort have been spent describing and trying to understand the content standards and transport technologies used to connect to EHRs (case in point, one of the most popular articles I’ve written was on the history of healthcare standards for Redox). Far more fundamental and even less understood by the average healthcare company, though, are the trust paradigms that underpin all methods of exchange.

Broadly speaking, healthcare has three main trust paradigms that define exchange, each having its own set of benefits and drawbacks. Healthcare tech companies too often limit their thinking to one model or, worse, spend valuable time/effort trying to integrate using a model inappropriate to their use cases. Here’s a brief overview:

---

Agreements and contracts for each institution. Get your pen ready.

Business Associate Agreements (BAA)

So what is this first line? In another name, it’s just traditional interfacing (also known as edge system interfacing). By this paradigm, companies make an application and sell it to health systems. These companies scale by selling to lots of health systems, one-by-one, so having a mature marketing and sales pipeline is mission-critical. What if you’re consumer or payer facing? In this model, you’re going to have fun, as you’ll still have to make healthcare organization (HCO) agreements one-by-one.

What exactly are these agreements (BAAs) anyway? Luckily, our friends at the University of Southern Florida have a pretty good explanation:

A HIPAA BAA is entered into typically by an outside consultant who provides a service to a medical organization. In many cases, that is an individual or business that works in health IT and may represent a service subcontracted out by healthcare organizations such as hospitals and physician clinics.

As defined by the federal government, a business associate is any person or entity that performs healthcare record services for an insured medical provider but is not a member of the workforce of the covered entity.

These services involve access to healthcare records protected under HIPAA. The guidelines in HIPAA require that covered entities — a hospital, for instance — must enter into a contract with business associates.

…

The goal is to ensure that any business associate uses health information in a secure, safe manner and that patient information is not illegally disclosed or used.

In short, each healthcare organization still needs to agree to allow your app into their ecosystem before their providers can use it or before your application can start interacting with the HCO’s data. To be successful with this paradigm, applications must clearly articulate their value proposition for the healthcare organization, demonstrate the security of their product/platform to the healthcare organization’s standards, and find key stakeholders within the organization to propel the application’s use case forward. In other words, applications should ensure they have a mature, effective B2B marketing and sales team, as they’ll need to convince organizations and not individuals of their value one-by-one.

Traditional interfacing has a lot of different input/outputs. Health Level 7 version 2 (HL7v2), dominates the scene and is by far the most prevalent. However, applications should be ready for EHR vendor APIs (Application Programming Interface) — especially when dealing with Athena or Allscripts, flat files (older EHRs), and Fast Healthcare Interoperability Resources (FHIR). If the application’s workflow leans towards financials or imaging, X12 and DICOM are also still possibilities. Once you get past those hurdles, though, traditional interfacing has some benefits. You can read and write all sorts of data, allowing applications to build deep, embedded workflows.

Benefits

1. Depth of data exchange: Once you’ve been allowed in, the sky is the limit (where the sky is the EHR’s inventory of interfaces, APIs, and other import/export mechanisms). This will vary by the complexity of the EHR and also the type of health system.

Drawbacks

1. Legacy scattered technologies: The history of healthcare technology is a battlefield littered with the wreckage of well-intended “universal” standards and vendor-specific formats. An application intending to scale must be equipped to handle a never-ending onslaught of new formats, files, and functions to understand and process.

2. Variable capabilities across EHRs: The potential of this trust paradigm is only outweighed by its variability across EHRs. Even when just deploying across HCOs of a single EHR, factors like deployment strategy, cost, and technical preferences mean that previously successful integration strategies may differ at a new site. Sending in a message to create a patient, for instance, may be acceptable for some, but a mortal sin at other sites.

3. Myriad IT and change control processes of hospitals: IT divisions of HCOs have been trained for 40+ years that integration is hard, third parties are scary, and mistakes can be career-threatening. As a result, there’s a visceral Pavlovian negative response to new integration projects, even as newer standards (FHIR and APIs) and methodologies (app stores/ecosystems) decrease the tech barrier. Expect that hospital organizations’ change control processes and ability to find ways to say no will be the bane of your existence (assuming that you can overcome challenges 1 and 2).

4. Slow scaling across organizations: Given the problems above, it becomes a herculean effort to try to deploy and integrate at one healthcare organization, let alone many. For applications whose main use cases depend on broad data aggregation or amalgamation, such as patient applications, payor applications, clinical trials, or analytics companies, this trust paradigm is simply not an efficient route to the scale of data needed for success.

---

One agreement with wide-ranging access

Trusted Networks

Okay, so now we’re onto line two in the diagram, aka the trust paradigm of the 2000s. In that decade, trust networks such as Carequality, CommonWell, DirectTrust, and regional health information exchanges (HIEs) were created and began to offer a simpler scaling path than line 1. Trusted networks are just that: follow the defined rules of the network of organizations (rules of trust) and gain access to large swaths of HCOs (networks) at once. This was the dawn of Enterprise Interoperability, the exchange of data between healthcare institutions.

Understandably, this form of trust is quite a step forward. Applications could now reach lots of providers without signing agreement after agreement. Large datasets were accessible, giving a cross-organizational view previously unthinkable. Data could be pulled through Carequality, CommonWell, and HIEs. In terms of writing, applications could push back through DirectTrust or (for some prescriber/pharmacy interactions) Surescripts.

As for tech, Integrating the Healthcare Enterprise (IHE) Cross-Enterprise Document Sharing (XDS) is the most common transport standard for pulling data, Direct is the nationwide transport for push and Consolidated-Clinical Document Architecture (C-CDA) is the content format that acts as a patient snapshot and includes medications, allergies, and problems. Some of the networks dabble in HL7v2 (retro) or FHIR (trendy).

Benefits

1. Large general datasets from across the nation: A C-CDA is an inherently data-rich method of exchange. Although it’s essentially the only content standard in use in this domain, it’s at least a pretty good one when measured by the number of use cases it can service.

2. Simpler access: Compared with BAAs, this allows a much wider breadth of access with a simpler overall process. Sign an agreement, perhaps go through a certification process, and suddenly have the ability to pull or push data from millions of patients across the US.

Drawbacks

The networks aren’t perfect. As it stands, several aspects of their current state and history limit their efficacy:

1. Comprehensiveness of network: Each trusted network is incomplete, in that none have 100% deployment across their user base (generally providers). Some are close, such as Surescripts for the prescription use case, but it’s worth knowing that these networks are partial.

2. Comprehensiveness of data: As mentioned before, the primary data exchanged across most trusted networks (outside of Surescripts) is the C-CDA. This focuses on the core patient data needed for the transfer of care, so use cases requiring specialty data are not well supported (such as oncology or obstetrics). Additionally, the quality of data within that structure is highly variable, in that some EHR vendors have highly structured, discrete C-CDA content, and others have more or less mailed it in and done the bare minimum necessary for federal regulations from Meaningful Use.

3. Legacy technologies: In contrast to the technologies of the BAA trust domain, trusted networks are more consolidated around a defined and well-known set of standards and technologies. However, trusted networks are derived from complex, slightly dated technologies. There’s a solid tweetstorm here about it, but old, obsolete tech contributes strongly to points 1 and 2 above. Adoption is harder, so the comprehensiveness of networks improves more slowly. Similarly, overly complex content standards with arcane rules mean it’s simply harder for vendors to deliver consistently.

4. Purpose of use: Trusted networks are limited in use case (purpose of use). Organizations freely exchange patient data for treatment (and functional equivalents), but payment, research, patient release, and operations are still stuck in the stone ages, using direct hospital agreements as their primary trust paradigm.

Lots of use cases. Not many supported.

5. Ability to push or write data: Not many of the trusted networks are servicing “write” workflows. Most are built around querying workflows. Direct offers the ability to send authenticated, encrypted health information directly to known, trusted recipients over the Internet, but it’s essentially just email with a C-CDA attached. The information is usually received into an email-like client within the EHR or (worse) a third party viewer not directly connected to the patient record. Trusted networks still have a lot of work to do in terms of facilitating the push of data to EHRs, particularly for use cases like referrals or scheduling.

---

Patient Authorization

Line 3 is very new but decidedly exciting. In terms of how it works, by using a patient’s log-in credentials, applications can pull the data roughly equivalent to a C-CDA, known as the Common Clinical Data Set (CCDS). It’s not so different from line 2 in terms of content, but with modern tech, it’s suddenly more reliable and easy to connect.

@Apple’s Health Records is the biggest player using this trust paradigm (given it’s on every iPhone), but also one of the best, as they do this just about as well as it can be done right now. If you own an iPhone, you can go and jump in there to get a picture of how patient authorization works. If not, there are some alternatives, such as CarePassport, myFHR, or Coral Health.

SMART on FHIR (Substitutable Medical Applications, Reusable Technologies) is the technology framework that enables this model. It relies on OpenID Connect, which many consumers are familiar with from their day-to-day Internet explorations across websites and applications using Google, Facebook, or another provider as a central log-in source of truth. It’s huge for the industry, opening up an entirely new class of trust that enables patients as active participants. For this reason, it wouldn’t be hard to argue that SMART is as large as a step forward as FHIR is itself. Without SMART creating a new trust paradigm, FHIR is simply a new technology littering the landscape of the BAA world.

It’s worth noting that patient authorization cannibalizes the market for some use cases in trusted networks. Personal health records (PHRs) that previously may have needed to pay to join Carequality and Commonwell have viable paths to access data for free. However, as long as patient authorization has the limitations listed above (data set, patient portal usage, etc), the two approaches are still somewhat complementary. Additionally, for scenarios where the patient isn’t authorizing (like provider to provider messaging), direct trust networks are still an important piece of the overall integration puzzle.

Benefits

1. Blowing the doors open for patients as participants: This trust paradigm simply changes the game for patients. Previously shackled to a healthcare organization’s patient portal (or worse, paper, in the event no patient portal is offered), this paradigm has propelled forward an era of equal opportunity in the PHR space, spurring innovation by leveling the integration playing field. However limited that might be currently (see below), it’s still a massive step forward for patients to have freedom of choice in terms of an application that can pull their records.

2. Large general datasets from across the nation: The CCDS is an inherently data-rich method of exchange (although slightly less so than C-CDA). So it’s not a bad place to start for this newborn trust paradigm.

Drawbacks

There are a couple of limitations, though:

1. Patient as the user: It’s reliant on patient credentials, so it’s only useful if you’re building a consumer-facing application. Note that this is not so much a flaw to be fixed as a fact of the paradigm.

2. EHR support: It’s still not fully supported across EHRs. Only a handful of the government-mandated patient APIs are in the FHIR format(178 out of 330 certified EHRs, per ONC). Only a fraction of those offer full, open SMART on FHIR. Lastly, for some EHR vendors, you still need to sign agreements/get enabled at the HCO level (line 1 of our trust matrix). A safe assumption right now is that if you’re doing this method, you’re more or less only getting Epic sites.

3. Patient portal reliance: Patient portal usage is necessary (in that a patient must have log-in credentials to authorize the release of their data). If they don’t, you’re joining trust networks or signing BAAs.

4. Comprehensiveness of data: The data that’s accessible is the CCDS. If you want anything beyond that, such as images, documents, advanced vitals, specialty-specific data, etc, you’re out of luck. As you can imagine, back to BAA world you go.

5. Ability to push or write data: There are no write capabilities, as it stands. The application must utilize Direct (a trusted network that has limited abilities to push back to a broad network of HCOs) or direct BAAs to facilitate that sort of exchange.

---

Future

Beyond the current state of healthcare trust paradigms, it’s also worth examing how we (patients, providers, vendors, and regulators) can improve the state of each paradigm to build better healthcare outcomes.

BAAs

In general, the world of BAAs will continue to be the most important route for most new applications in the healthcare space for the foreseeable future. In contrast to the other areas, the impact of upcoming legislation (ONC Cures and TEFCA) don’t directly affect this trust paradigm. However, a couple of emergent strategies and trends come to mind as important:

1. A shift of responsibility from HCOs to EHR vendors for application security and privacy: App ecosystems are popping up with each EHR vendor. In this model, applications can register, build, test, and even be certified by EHR vendors in advance of selling to healthcare systems. Previously, this all occurred live in implementation after selling to an HCO, so applications can frontload their efforts. Perhaps more importantly, though, the vetting of applications by EHRs potentially means that partial trust is established earlier, allowing for quicker contracting of their BAAs with HCOs.

2. Consolidation of disparate technologies around FHIR: The disparate technologies of yesterday are slowly being supplanted by SMART on FHIR. Given that a SMART on FHIR is generally faster and easier than a traditional HL7v2 implementation, this is a positive shift. The pace of this consolidation across vendors and healthcare organizations will be an important trend to watch.

3. A change in mindset within HCOs: Unfortunately, even though SMART on FHIR for providers lowers the overall technical barrier, its trust paradigm is still built upon a BAA, as it stands, which is for most healthcare organizations still a nightmarish ordeal. Innovative healthcare organizations, however, are recognizing the change that app ecosystems and SMART on FHIR offer. They are spinning up digital health programs, oftentimes with lighter weight security and change management than their traditional IT governance structures, to allow quicker innovation.

Trusted Networks

Trusted Exchange Framework and Common Agreement (TEFCA) is coming legislation and promises to shake up the trusted networks model. With our national interoperability network currently somewhat disjointed on the whole, with various partially connected hubs and webs, the legislation will work to simplify access and connect the disparate parts.

TEFCA will … “establish a single on-ramp for HIE that will enable providers, hospitals, and other healthcare stakeholders to join any health information network (HIN) and then to automatically connect and participate in nationwide health information exchange.”

In that light, we can review how TEFCA affects the problems of trusted networks listed above.

1. Comprehensiveness of network: This is a primary goal of the legislation and it promises to help drastically in this regard by unifying disparate networks, making a cohesive network of networks. While everyone agrees on this outcome, some dispute ONC’s approach here. Personally, I’m for it.

2. Comprehensiveness of data: TEFCA doesn’t really make any moves to address this, per se. Content is not a focus and the legislation seems to just solidify the C-CDA exchange, so efforts to improve the situation will have to come from the private sector.

3. Legacy technologies: TEFCA keeps the existing legacy technologies such as IHE XCA, XCPD, and XCDR in place as the primary (required) standards, but listed new technologies like FHIR as alternatives. Pundits around the industry debate the correct approach here (“if it ain’t broke, don’t fix it” vs “one standard to rule them all”). I’ll shy away from that debate and say that the existing networks are robust, but that it would be nice to see a clear transition plan to modern technologies.

4. Purpose of use: TEFCA expands on the permitted purposes of use quite drastically, which should be beneficial most immediately to payers.

• Treatment

• Quality Assessment and Improvement

• Business Planning and Development

• Utilization Review

• Public Health

• Benefits Determination

• Individual Access Services

Outside of Individual Access Services, reasonable fees may apply for these new use cases, however. As a result, it will be interesting to see how new players and use cases are added to the existing networks. Given the history here, I wouldn’t expect all the networks to suddenly open up to previously underserved purposes of use, but I am hopeful for innovative networks to lead the charge (as Commonwell is now doing for patient Release of Information).

5. Ability to push or write data: TEFCA calls out the need to be able to push data across its network, but doesn’t explicitly expand on existing use cases in a major way. As a result, it’s not likely that we see a major expansion (like FHIR within Direct) supported by EHRs in the near term.

Patient Authorization

ONC’s recent Cures NPRM is generally aimed at this trust paradigm. For patient authorization, clearly, the push has to be towards fixing the aforementioned flaws, so it’s worth assessing how the legislation tackles each problem.

1. Consumer-facing only: As noted before, this is a fact of the paradigm.

2. EHR support: ONC tackles this head-on, but only for certified EHR technologies. OpenID Connect + SMART are written into the rule, so after the rule becomes law, we’ll see vendors shift from the random assortment of MU3 patient APIs towards SMART on FHIR. The availability of data should continue to increase from the roughly 300 or so institutions now offering SMART on FHIR to a much higher percentage of US healthcare organizations.

3. Patient portal adoption: Patients need to be further incentivized to create and use patient portals. New consumer-facing applications will play into this (given they rely on those log-ins, they incentivize patients to create and maintain them), but ultimately, HCOs need to be proactive in pushing use.

4. CCDS: The good news is that the new USCDI is more comprehensive than the CCDS. However, unless it changes, it’s still missing important data, as it really only added clinical notes. Giving patients access to images, advanced vitals, or specialty data like oncology staging would move the needle on patient authorized applications towards truly impactful.

5. Write capabilities: The legislation stays away from this with a ten-foot pole. Future legislation will be needed, as HCOs and EHRs will be very hesitant to open their systems in that way without some pushing. For the foreseeable future, write capabilities will entail using Direct (a very rudimentary write, in that it only allows for essentially secure email with at best a C-CDA) or utilizing direct agreements with hospitals through BAAs.

Other Trust Frameworks?

It’s worth considering if there are other possibilities in the future in terms of how we conceptualize trust in healthcare exchange. One possibility would be pure provider authorization, where each individual provider user could choose and launch an application for their own use using their credentials, similar to patient authorization. In this paradigm, SMART on FHIR would work seamlessly for providers and there wouldn’t be the current overhead of a prerequisite BAA with the hospital.

Some major changes would be needed, though. One possibility is that EHRs or another centralized party would take on the full responsibility of vetting, certifying, and approving applications before they’re released into this paradigm, taking on responsibility for ensuring the functionality, security, and privacy of the apps. It’s hard to imagine HCOs trusting the EHRs to do this fully, though, so I’d imagine the only way this occurs is if there’s a policy push at a state or national level.

Beyond that, this author struggles to envision other trust paradigms, but I’m always open to hearing your thoughts or ideas, so please reach out!

EDIT: Grahame brought up the idea of government as a possible trust entity, which is in line with the pure provider authorization, in that government could act as the verifying and registering body for applications in certain countries. When writing above, I was thinking more of private industry (which is why I said “EHR vendors or another centralized party”) fulfilling that role, most likely due to my US-minded brain discounting the government taking on that responsibility domestically. However, the government is about as centralized as it gets, so for countries willing to take that plunge, it’s well-suited to provide the necessary pre-requisite services for pure provider authorization.

Another piece I missed is the natural evolution from patient portal credentialing towards a single authorization for a patient. The CARIN Alliance is doing the work there towards a future where a patient uses a single, trusted log-in to access their data across all EHRs. It’ll likely take legislation to force EHR vendors to accept this third party authentication rather than the patient portal credentials they maintain, though.

---

What it means when you’re developing

So those are the three paradigms. As you’re building digital health applications (or anything that needs healthcare data), consider all three. Combining them can be your differentiator.

Applications for patients

If I’m direct to the patient, I’m starting with the third. Consumers are used to logging in with Open ID from their day-to-day Internet activities. However, the patient authorization space is crowded to the point of saturation. As a result, what’s so interesting is that the no-friction, open access means all players are doing up to the limit of what’s possible. Patient authorized data has been completely commoditized. In short, what Apple Health is doing is really almost identical to what 1up Health, MyLinks.com, myFHR, or any number of other patient authorized access players are doing in the space. There’s simply an upper bound on what’s possible. Any new legislation will continue to open up what’s possible, but applications will quickly hit that ceiling. Therefore, new consumer applications will have to rely on novel visualizations, advanced analytics, and integrations with different data sources (that have more inherent friction) to differentiate.

Thus, as a direct to patient application, once you’ve hit the ceiling, it makes sense to combine patient authorization with deeper integration strategies. Joining trusted networks may make sense, depending on what purpose of use you have. Eventually, at some level, your needs will dictate you’re probably going to want to think about BAAs.

Applications for Providers (or other HCO users)

Provider apps should start with BAAs. It’s necessary to understand the process there and adapt to it. App programs from EHR vendors (or other vendors like Redox) can drastically accelerate your deployment, although you’ll still need to market, sell, and sign agreements to hospitals (a.k.a. you still have to hustle).

The other methods may be able to supplement your approach, depending on what workflows you’re servicing. In general, if you’re making primary software for an entire organization (EHR, reference lab, pharmacy, LTPAC, social care, or any other organization providing treatment), it’s worthwhile to get your enterprise interoperability strategy sorted.

Other Applications

If you’re not aimed at patients or HCO users, you’re likely talking about payers or pharma. In that case, you’re locked out of most direct trust networks at this time. Assessing your workflow and use case is valuable, as there may be certain networks, especially at the regional level, that could be a fit. It may also be viable to use patients’ authorization to get the data you want, despite the limitations across EHR vendors currently. However, it’s most likely you’ll need to approach it from a BAA perspective, so firming up your value proposition for HCOs is important. You may be able to leverage a close relationship with an EHR (through an app program or through a partnership) into accelerating this process.

---

The Plug

Hopefully, this walkthrough was helpful when considering integration within healthcare from a trust paradigm perspective. As you look at building your connections yourself, buying a solution, or working with a partner, consider Redox. We’re one of the few interoperability vendors that actually span all three trust paradigms and we’re industry-leading in navigating the most difficult (the world of BAAs). At the very least, I guarantee we’re fun to talk to.

If you found this post interesting, it would mean a lot to me if you could click on the “claps” icon below to let me know. Let me know through the comments your general thoughts. For more in-depth discussions, feel free to reach out via email at brendan@redoxengine.com or brendanjkeeler@gmail.com. Also, let me know if you see any glaring errors and I’ll fix them!