How to win friends and integrate systems
It’s easier than you fear but still harder than it should be
This post is a joint production brought to you by Brendan of Health API Guy and Eric Guroff of Ratio PBC (blog here) - you should subscribe to the former and go work at the latter! Tremendous thanks to Evan Brociner, Erica Jain, Rik Renard, Rachel Menon, Jonathan Pira, Garrett Rhodes, Jan-Felix Schneider, Bailey Davidson, and Jesse Cooke for their invaluable input.
You wake up in a cold sweat.
You’re the Head of Product and you have overcome mountains. You’ve identified use cases, built something that meaningfully solves problems, found your first customers, and even raised a bit of money.
Yet tonight is the night you wake up at 2:44 AM, drenched and shivering as you face your biggest challenge yet, one that could stop all that success in its tracks.
Integration.
Integration is one of software’s most common problems - not only in healthcare but across all industries. A single piece of software can rarely do all the things an organization needs, so stitching together the various tools used in an enterprise is nearly always necessary.
With a problem so common, a comprehensive solution must exist, right? The rise of tools like Zapier, Tray.io, or Mulesoft accommodated general integration needs for most enterprises, so someone must have cracked the code and created a rinse and repeat, turnkey experience to solve healthcare’s integration needs.
The problem within the problem (problemception?), though, is that healthcare organizations and their tools are decidedly not homogenous. They are as varied as the ocean is deep - a vast array of niche tools, unique workflows, and small technical nuances that (when viewed in aggregate) defy generalizability. These turn integration work into the ultimate product Pyrrhic victory: a slowly increasing tide of tech debt that drains your company’s time and energy as you stare endlessly at pipe-delimited puzzles inscribed in poorly documented PDFs.
Thus you awake early, losing sleep and prematurely graying your hair, as stress over integration mounts. You find yourself surrounded by questions: can this problem be outsourced? What tools can make this easier? Is FHIR the answer? What about EHR API programs? You smoke a cigarette on the back porch and take the dog for a dawn walk, but answers elude you.
Our good friend Rik over at Awell encapsulated it well:
Eric Guroff and I don’t want that for you. We want you safe and snug in your bed, focusing on the problems you want to solve as you build a better future for patients and providers. So we worked together to create the ultimate guide to integration: the state of affairs, best practices, tools, players, and recommendations you can use to minimize the integration’s blast radius on your product roadmap and maximize its value to you as a feature for your users.
The main problem with integration is that not all software is created equal. Consider these entirely hypothetical examples to set the table and prime the pump:
Glex is a remote patient monitoring (RPM) startup, selling to any care institution that will buy them. They need to receive orders prescribing RPM to a patient and to send back summaries of the data they collected over time.
Wistly is a patient engagement and scheduling app that sells to legacy small clinics with a value proposition of patient acquisition and retention. They need to synchronize existing patient demographics and appointments, understand provider availability, and write new patients and appointments into the provider’s schedule.
Care R Us is a population health analytics company that sells to Accountable Care Organizations with a value proposition of understanding their managed population’s data at scale with AI and machine learning. They need All The Data™ to slice and dice and create their patented Valuable Insights™.
Omega Health, a growth-stage virtual-first care clinic for primary care, MSK, and diabetes, is going to market as a close referral partner with legacy health systems. They need to synchronize patient data bidirectionally, send referrals, and share progress notes.
These are just a small sample of the wide world of workflows one might encounter in the wild, but you can immediately see how disparate their data needs are.
A brief aside from the authors:
While all these applications and use cases differ, they are united in that they represent integration (termed intra-operability by the legendary Garrett Rhodes) - the connectivity of applications within a given healthcare organization enterprise - rather than interoperability (the connectivity between provider organizations). While these problems parallel one another by nature of connecting systems and data, they require drastically different tools.
Interoperability connectivity use cases, such as patient access, exchange between healthcare organizations, or de-identified data exchange offer a different set of problems entirely. Further reading here, here, and here if interested.
So before you can evaluate tools and create your strategy, you need rules. You need principles. You need a framework.
Every software company is a unique snowflake - a fractal of compounding choices of workflow, tech stack, personnel, go-to-market, and so much more that makes them different from one another. Like Socrates said: “to know thyself is the beginning of (EHR integration strategy) wisdom”. Determining who you are, where you are in your journey, and your exact needs are critical to making sound decisions.
So what are those factors you need to consider to build a foundational framework?
What does your user need?
To integrate successfully, you must know what data flows are needed to support your application. In order to know your data flow, you must map out your workflow(s) accurately, in exacting detail. In short, workflow drives dataflow. Some simple applications only require synchronized patient demographics to reduce double documentation. Others call for complex back-and-forth business logic, pulling intricate data structures (like active medications) and writing back discrete measurements.
Authors’ Note
Notably, analytics-style companies have drastically different data needs than more operational sidecar applications. Does your workflow need real-time synchronization of select data types or can it get by with a daily or weekly load of the full database?
Your exact, prescriptive workflow and data flow definitions will typically reduce swirl when engaging customers and partners, allowing you to focus on the technologies in play and the results-oriented work of implementation and testing.
Who is your market?
The EHR market may feel consolidated, but there’s a sneakily high variety of these little monsters hiding out there. The ONC’s list of certified health technologies enumerates 798 of them, but that doesn’t count an abundance of pseudo-EHRs aimed at healthcare organizations that don’t need CMS dollars (and therefore don’t necessarily need a certified EHR). High-end products in the EHR market like Epic and Cerner carry a wide range of integration technologies, including oodles of inputs and outputs built over decades of industry progress from EDI to XML to JSON. Newer EHR entrants like Canvas, Elation or Healthie offer robust, nearly headless APIs to play with. Meanwhile, more niche legacy EHRs hold sparser offerings, to the point that some support no true integration options. There’s nothing more discouraging than setting forth and investing in a bold, forward-thinking integration strategy of using FHIR, only to be dragged into the mud of flat-file exchange over SFTP or an RPA setup hacked together by the lackluster integration capabilities of the dumpster fire long-tail EHR of your first customer.
Understanding the EHRs of your customer pipeline allows you to map out what integration technologies you’ll likely encounter, improving the odds of choosing the right tool or vendor to work with. As you review that pipeline, you may even be able to predict the consolidation of your customer base around a single EHR (often Epic or athenahealth), making investments into EHR-specific app programs like Epic’s App Orchard, Cerner’s CODE, or athenahealth’s Marketplace more viable and attractive. Knowledge databases cataloging healthcare organizations’ EHRs (such as Definitive Health) can be expensive but are worth the price of admission to avoid even more costly mistakes in this area. There’s also Redox’s free tool that can be helpful, although it’s limited to healthcare organizations they’ve connected to before.
Author Aside
This article is largely focused on business associate applications - digital health tools selling to provider organizations and thus seeing a broad array of EHRs they need to connect to. Virtual first care organizations, the other major subcategory in digital health, typically build or buy their own EHR and less frequently sell to other providers. Given this difference, it is more common for these groups to connect directly to their EHR’s APIs or interfaces and to participate in national interoperability networks like Carequality and Surescripts.
Knowing your prospects’ EHRs is only half the battle, though. Even if you are dialed in on a customer base with a single EHR, customer perspectives on the EHR vendor marketplaces and integration technologies can vary wildly. For instance, within the Epic community, some organizations have shifted to “API only” strategies, migrating all their integrations to FHIR and proprietary API formats. These organizations have a strong preference for App Orchard participants or FHIR-capable applications. On the flip side, some established organizations have expansive integration teams supporting hundreds of ancillary applications via older technologies like HL7v2 and X12. These groups may not have done an API integration before, may be reluctant to shift to new technology, or may have outdated restrictions on APIs, as in this example.
What investment are you willing to make?
One of the last things to think about as you build your integration strategy: do you desire integration to be a core competency of your company? Whatever solution you choose, no path removes all the pain illustrated here. Any path includes triangulating the best balance of spending time, money, and effort for your team. But a choice remains: will you invest the blood, sweat, and tears in making integrations a knowledge area (and perhaps even a differentiator) for your company? Or will you do your best to save those calories for other, more essential features and functionality?
EHR-specific expertise can be a valuable muscle to build not only in your technical team but also in other functions (such as sales or marketing). Knowing the ceiling of what’s possible with integration capabilities, the particular nuances of implementation, and similar customers’ experiences with a given EHR can be powerful knowledge when reassuring and guiding prospects. It’s not unheard of for healthcare companies selling to care organizations to structure their sales or CS teams by EHR market segment.
When in doubt, creating a cost matrix or calculator helps. Hiring is hard and expensive, and managed services can come with some sticker shock. Redox has a calculator that might be a bit biased, but can be used (or easily modified) as a starting point.
Okay, so at this point, you’ve meditated deeply on your integration priorities, leading your team on an interoperability mindfulness retreat, and you’re feeling renewed as you return with a crystal clear perspective on your integration needs. Unfortunately, the existential dread returns almost immediately, as you survey the vast array of solutions filling the interoperability landscape, and you shudder in fear and confusion.
What are my options?
If you squint your eyes and look hard enough, every product decision is just a Byzantine configuration of a build-or-buy decision. Integration is no different! Your task here is just to map that level of investment from the previous section onto the available tools and networks. So let’s dive into the wild world of what’s available to you today.
Build Options
For many of you, building is the cool, logical first instinct. You’re a startup who just wants to create! You’re a large enterprise with nigh unlimited resources and grand architectural plans! You’re inherently distrustful of middleman-style vendors who prevent you from getting close to the wire!
Whatever your prerogative, building can be valid. The tension here, though, is the vast array of formats, standards, and connectivity you might need to accommodate.
For mature, robust EHRs at the cutting edge, you’ll see Application Programming Interfaces (APIs) and associated programs/marketplaces to enroll, onboard, test, and deploy applications for a given EHR. Increasingly, this segment is utilizing FHIR for this purpose, but many major EHR vendors augment this standard with proprietary endpoints as well. If you can map your market and workflows to confine yourself to only integrating with APIs, the experience may not be unlike that of connecting to a modern SaaS application. It’s work, but programming languages and tools are geared to help you here, and new engineering hires can pick this up relatively quickly.
However, it’s actually quite hard to confine yourself to just using APIs with health systems. Your workflow may be geared to receive push notifications, you may want to sell to eClinicalWorks or other long-tail EHRs, or you might want huge sets of data (which APIs today don’t handle particularly well).
Your build effort thus starts sliding into the deep, downward spiral of integration despair. You develop support for parsing HL7v2 and X12, older pipe-delimited standards, fed over MLLP connectivity, a pre-Internet communication method designed for on-premise networking. Your team is hesitant but digs in thinking it will be a one-off.
You begin to see smaller clinics and rural health systems unable to output data in real-time, instead delivering flat files or extracts regularly. You invest in SFTP to pick these up daily. You lose some engineers who just want to go work at Google “because it will be easier.”
As you extend further into EHRs with limited or non-existent capabilities, you angrily decide that if the EHRs won’t play ball and exchange data, you’ll take it by force. You develop the capability to directly connect to the operational and reporting databases of these vendors by ODBC or (if blocked there) to use Robotic Process Automation to scrape the data you need. Developers have added your company to no-fly-zones and deny lists on Hacker News at this point.
Years later, you sit hunched over your laptop, a grizzled veteran of healthcare data exchange, peering out upon the horrendous, beautiful creation you and your team have created: a convoluted spectrum of microservices and technologies. You wonder what could have gone differently as your leadership team sells off assets to Optum at a discount and closes up shop.
This storytelling is, perhaps, hyperbolic. But it’s not exaggerating the gamut of what’s possible in healthcare integration. Picking and choosing wisely which aspects of integration you’ll do yourself and which you’ll use a vendor for is vital to success.
Buy Options
Roughly speaking, you have three broad categories of buy options available to you - each with advantages and disadvantages. It’s worth reminding once more that these “buy” options don’t fully alleviate the pain of integration; they just might make the work faster by virtue of hyper-specialized tooling, services, and support.
The first and most simple category includes tools you buy that help you build more quickly. Historically, health systems and applications have often used integration engines (a healthcare-specific term for a service bus) to manage the exchange of data between systems. Some of these evolved in the cloud era to a more fully featured, API-ready integration platform as a service (iPaaS), but conceptually they’re just a continuation of what has existed for years: a tool with pre-built connectors and adapters, data manipulation, and rule-based routing.
Some popular examples include:
Depending on which cloud vendor you are hosted on, you may have built-in tooling you can use. For instance, Google Cloud has support for healthcare standards like HL7v2 and DICOM in addition to FHIR.
What these interface engines and iPaaS don’t necessarily get you, however, is any pre-built connectivity. There’s a learning curve to understanding the data formats, the technical implementation of different integration types, and the capabilities you can expect across different EHRs. For that reason, many applications choose to buy a second category of service: Managed Service Provider integration platforms. These providers purport to offer even easier connectivity than interface engines in that:
Expert staff help educate and onboard your team, guiding them through the various integrations
Pre-built adapters abstract away the nuances of individual EHR or health system formats into a more normalized data model, lowering your engineering investment
Connections to health systems for any of their customers can hypothetically be reused for the next customer, accelerating implementations
Some of the key managed service offerings today are:
Rhapsody Envoy (formerly Datica)
Lastly, several interoperability companies have popped up that act as on-ramps to pre-existing nationwide networks and health information exchanges (HIE), such as Carequality and Commonwell. Via those networks, the on-ramps can offer a broad “connect once, pull from most health systems” capability. While this structure traditionally benefits interoperability between healthcare organizations, it can be a viable integration strategy for some business associate applications. Viability here presumes that your workflow is fairly simplistic (along the lines of “I need to pull a patient record”) and does not require deep bidirectional exchange (such as ordering, resulting, or scheduling). This strategy is akin to using a screwdriver to nail something into the wall - it can certainly work, but isn’t exactly fit for purpose. For that reason, it’s generally best to think of these on-ramps as augmentative to your overall strategy rather than a full solution. You have to have an extremely basic workflow for these products to fully accommodate your needs.
Examples of HIE on-ramp companies include:
Okay, so what does this look like in practice?
We’re product managers, so let’s make a framework! Piecing all the decision factors together, we’ve put together a resource we’re calling the “EHR Integration Strategy Canvas™®©.” The Canvas is melatonin for digital health product leaders: the tool you use to get all the integration-fueled anxiety out of your head, so you can get back to a good night’s rest. You’ll sleep soundly with peace of mind once you’ve got a rock-solid strategy for how you’re going to deliver EHR integrations.
To make this concrete, let’s walk through some of the hypothetical scenarios we outlined using the EHR Integration Strategy Canvas.
Scenario 1: “Wistly” Patient Engagement and Scheduling App
You’re the Head of Product for a slick, new patient engagement and scheduling app targeted toward small, independent clinics. You’ve been selling and implementing the Wistly app in a non-integrated way for a little while now, and on just about every sales call your team is hearing that if you haven’t done integration with *their EHR* before, it’s not worth their time. They’ve tried scheduling apps before that ended up just being a huge headache for the admin staff, so the only way they’ll buy your product is if you can demonstrate and guarantee a seamless, real-time, bi-directional scheduling integration.
Let's walk through the framework.
What does my user need? (workflow)
The first step is to map out the workflow for your end users. As a patient engagement and scheduling app, your core users are patients who need a doctor’s appointment. While there are probably several different workflows your app will handle, let’s start with a common one: a patient needs to find a new doctor and book an appointment, but they later realize that the time isn’t going to work for them, so they need to reschedule that appointment.
What data is required in each system? (dataflow)
Once you know your user’s workflow(s), you’re ready to map out the dataflow. It’s helpful to look at each step in the workflow and identify what data is needed to accomplish that step and what system that data lives in or where it needs to go. In this scenario, the EHR contains some data that the patient needs to accomplish their tasks (e.g. providers’ available appointment slots), and the Wistly app contains some patient-generated data that the EHR needs for the patient to accomplish their tasks as well (e.g. the slot the patient selects needs to be held for them in the EHR).
Who is my market? (segmentation by EHR vendor)
Now that you’ve mapped out your workflows and dataflows for all your core workflows and each of your users, you’re ready to segment the organizations that will use your product by what EHRs they use. Looking at your sales pipeline, you notice a focus on small and mid-size primary care practices, so you start researching what EHRs are most common for these practices.
You start by logging into Definitive Healthcare – a healthcare-focused market data product your sales and marketing teams use – where you find the reported EHR used by independent primary care practices in your target market(s). This provides a good starting point for crucial vendors you’ll likely run into. Depending on your company’s maturity, you may also connect with your sales team and ask them to add an EHR vendor discovery question to each of their sales calls, or if they’re already collecting that data, you can pull a report from your CRM. Finally, you reach out to other health tech folks in your network to get a better picture of which EHR vendors they expect you’re most likely to encounter and learn what it’s like to integrate with them.
What am I willing to invest?
You know what your users need, where the data lives, and what EHR vendors your future customers use. Now you need to ballpark your appetite: what am I (or my boss and the board) willing to invest to accomplish EHR integration? This is the most subjective question on this Canvas, but it comes down to how core EHR integration is to your company/product’s ability to be successful in the market. Do you need some lightweight (ha!) integration to “check the box” and reduce duplicate data entry for staff? Or is tight integration so core to the user experience that how seamlessly it works will be a major factor in whether a customer buys your product or not? How many engineers are you prepared to staff to work on integration capabilities?
My EHR Integration Strategy
Rest easy, product leader; you know your strategy. EHR integration is the most important feature that your customers will use to decide whether to purchase or not purchase your product, so you’ve decided that integration will be a core competency of your organization. You decide to build integrations with the vendors you expect to see frequently while buying a 3rd party solution to make sure you’re not closing off the 50% of your market that uses the long tail of “other” EHRs you’re unlikely to see twice. Staff up a product development team focused on integrations and start executing your strategy!
Scenario 2: “Care R Us” Population Health Analytics Company
Alright, now we’re ready for another scenario: you’re the CTO and a Ph.D. data scientist at a population health analytics company called Care R Us, a former retail giant pivoting into healthcare and selling to Accountable Care Organizations (ACOs). You’ve gone to market with an analytics package built on claims data, but to generate the insights your customers are looking for, you also need to start analyzing clinical data locked within their EHRs. The most valuable work you can provide is to make meaning from this data, but you’re currently unsure how to even access it. Enter the Canvas.
What does my user need?
Your users are the population health management team within an ACO. They already have a care management system, but they purchase the analytics application to help prioritize who should receive which interventions and to gain a better understanding of the effectiveness of the interventions they’re deploying.
What data is required?
Who is my market? (Segmentation by EHR)
To get a rough picture of the industry, you start by analyzing data your sales team has captured from your existing customers. Here the picture is pretty daunting: of the 24 ACOs you’ve collected data on (including current and prospective customers), the average ACO has 7 different EHR instances within their various sites (this doesn’t even count claims + other systems you’re looking to ingest data from), and no single vendor (let alone instance) represents more than 10% of clinical sites. You see some of the names you’re familiar with: Epic, Athena, Nextgen, GE, eClinicalWorks, but you also see lots of names you’ve never heard of: Carecloud, Medent, Kareo, and much more.
What am I willing to invest? (differentiation)
When you line up the growth you forecasted in your investor materials with how many different EHRs you’ll need to source data from, and assume a high-performing 3 person integrations team (PM + 2 Devs) could deliver two EHR integrations per quarter, you realize you’d need to allocate 150% of your forecasted R&D budget just on ingesting EHR data. You *had* planned to allocate 60-80% of that spend on data engineering and data science to normalize and generate insights from the data - which is where you differentiate against existing care management and analytics vendors. In this market, your board is firm about maintaining a lengthy runway, so increasing to >200% of R&D spend is out of the question.
As CTO, you may have a preference for building and owning your own tech stack, but it’s time to start researching vendors that can enable you to deliver on your forecasted growth rate without blowing up your R&D budget.
My EHR Integration Strategy
The Canvas leads you to a clear preference: a vendor that can get data out of many different EHR vendors faster and more cheaply than self-piloted integration work. You don’t require real-time data, so you start taking demos for EHR integration middleware solutions with competency in large data extractions, such as Ellkay or Healthjump. With the EHR data loaded on a nightly basis into your data lake, your internal teams can concentrate on cleaning and analyzing the data.
The Takeaway
You’re seeing this title and thinking, “Hold up, Eric and Brendan promised me at least two more examples.” Frankly, you’re not wrong, but as much as we’d love to pump out another 5000 words on that topic, we’d be doing you, dear reader, a disservice. We’re having a contest! Readers can use this tool with the two examples above (or their own fun hypothetical examples) and submit them to integrationcanvas@gmail.com. We’ll take those answers and write a small follow-up post at some point.
In any case, the main takeaway from this article should be that there is no silver bullet that can slay the werewolf that is EHR integration. We fully understand that’s disappointing - there’s a natural desire to possess a single tool that uniformly overcomes this thorny beast of a problem. The wild, everchanging diversity inherent to the EHR landscape, the unique workflow needs of your company and product, and the proclivity and resolve your company has for investing in EHR integration means that your strategy is highly likely to be hybrid in nature - mixing building, buying of tools, and working with managed service vendors or HIE on-ramps. As Lizzo once said after a particularly difficult eClinicalWorks project: “Truth hurts” but “We just keep it pushing like aye, aye, aye”. Words to live by as we all persist through the integration grind.
Thank you for sharing such comprehensive and insightful knowledge on the complexities of EHR integration! The detailed breakdown of workflow and dataflow mapping, market segmentation, and investment considerations is incredibly valuable. Your explanation of the differences between building and buying integration solutions, along with specific examples of tools and providers, is particularly useful. I also appreciate the introduction of the EHR Integration Strategy Canvas – it's a practical framework that I'm sure will help many product leaders tackle their integration challenges more effectively. Thanks again for this invaluable guide!