Looking for a job in health tech? Check out the 85+ other awesome healthcare jobs on the job board + give your preferences to get alerted to new postings. If you're a company that wants to get your job in front of high quality healthcare candidates, click "post a job" on the board.
Today I’m interviewing Brendan Keeler, a man that knows more about healthcare data and interoperability than I know about myself.
Because this interview was so great but also long, I'm splitting it up across two newsletters. But for eager beavers, you can see the full interview on the site right now.
Brendan: I'm a New Jersey-ite in exile (happily living now in Portland, Oregon having just moved from San Francisco). Before you ask, I have yet to get a tattoo or Subaru but I own a bike. I love dogs and healthcare. I've worked domestically and abroad (the Netherlands) for a large part of my career at the evil empire Epic.
Once I moved back to the states, I joined Redox (a fantastic managed service integration company for BAA apps looking to scale connections across EHRs) and worked as the EHR Experience PM, focused around trusted national exchange networks (such as Carequality, DirectTrust, and Commonwell) and how to make it easier for EHR customers (and virtual first care providers, who often build their own EHR) to participate in enterprise-to-enterprise healthcare interoperability (which differs a lot from the integration a traditional BAA app does). For the last six months, I served on the Carequality Advisory Council, which was a great way to get more involved in shaping that framework at a national level.
In April, I joined Zus Health, a younger startup that looks to serve the builders of digital health, all the exciting companies innovating in reimbursement (cash pay, value based care, direct payer contracting), modality (virtual care, home health, continuous episodes of engagement), or the technology of the provider and patient care experiences. It’s an absolute Cambrian Explosion of these companies and they’re all frustrated by the existing set of broken, walled, and expensive solutions that should be commodities. It’s the absolute Venn diagram of prior experiences and my own personal industry passions to be able to build the developer friendly tools from the ground up that will enable all the other companies and affect the radical change in healthcare we need.
Brendan: Well, the first thing to know is that all EMR integration is a series of tubes. ;)
In all seriousness, first and most important questions to think about are less about technologies and more about trust** and workflow. The decision tree starts with answering "Who am I?” and sorting yourself into one of three categories: provider software, provider organizations, and patient apps.
Are you building a B2B application to sell for use by healthcare providers or other healthcare organization workers? You’re provider software. Are you a digital health delivery organization that employs providers? You’re a provider organization. Are you an application sold or used directly by the patient/consumer? You’re a patient app."
If you’re provider software, you're in the world of Business Associate Agreements (BAAs). You're not in a world of open access or even EHR level access; you're negotiating with individual hospitals or practices. Before you worry a ton about integration, your main concern needs to be defining your value prop for your target healthcare organization user(s). It can be a provider, a scheduler, a nurse, revenue cycle admins, or literally any number of roles, but you have to fundamentally fix or improve a problem that they feel acutely. They need to want you so badly that they'll go to war for you to convince their IT team or other parties that you're their savior to unblock any potential blockers. Many IT departments have been trained over the decades to have a Pavlovian negative response to the stimulus of "new project".
While seemingly obvious, it's something I've seen far too many companies come in nebulously and get bogged down in bureaucracy. "Give us all the data and we'll figure out a problem to solve" AI companies fail, where "I'm going to reduce physician clicks by 50% and here is exactly how" wins. Once you fully comprehend your problems to be solved, you can craft your prescriptive integration approach that you'll woo the IT teams with.
Once you've done that, the technical landscape is extremely varied. There are hundreds of EHRs ranging from the big guns (Epic, Athena,Cerner, etc) to mid-markets that crush certain specialties (PointClickCare, ModMed, Elation, etc) to dumpster fire long-tail EHRs that small practices cling onto (Kareo, Practice Fusion). Beyond that, edge interfacing (integration of HCO tools with the main EHR) has existed for 40 years**, so you see a range of protocols/formats for security, transport, and content. It can be absolutely overwhelming in terms of acronyms - HL7v2, CDA, FHIR, X12, DICOM, CSV, JSON, XML (and that's just content standards). It's like a community garden that hasn't been effectively pruned - even though newer/superior technologies are out there (hello, Application Programming Interfaces - APIs), the management of the garden (ONC) has not mandated rip-and-replace to remove the old weeds, each garden has different vegetables, and many of the individual gardeners are at this point decrepit. For content standards, HL7v2 is prevalent, especially for Epic/Cerner, but proprietary APIs also need to be factored in (for newer cloud EHRs like Athena and Allscripts) as different EHR vendor app programs grow. One route is to identify what EHR(s) your target customer healthcare organizations (HCO) use and ideally focus on a single EHR to start, optimizing your strategy around their particular nuances/eccentricities. Another is to use an intermediary managed service integration partner to normalize the experience, which is where Redox typically helps.
If you’re a provider organization, you are a covered entity. You need to accomplish a lot of internal and external integrations of different types and workflows. There are increasingly a number of networks that exist that you’ll need to think about (e-prescribing, clinical data retrieval, referrals, labs, immunizations, eligibility and claims, to name a few), with Stripe-like companies existing to serve as value add on-ramps to those networks. There are also specialized service tools to augment your clinical workforce with pharmacy, lab, home health, or telehealth services. Although we’re still figuring out who we want to be when we grow up and building like crazy, Zus is hoping to serve this class of digital health company to start.
If you’re a patient app, you're in a really new and exciting area of growth - consumer health tools. You won't have to worry about complex site-by-site Business Associate Agreements (BAAs) or other data-sharing agreements, as your authorization comes from the patient themselves, but because it's so new, your integration options are essentially limited SMART on FHIR to pull a patient's clinical information. As you look at workflow and decide you want or need to go deeper, you'll, unfortunately, need to consider the last category of BAA-style engagement, which means convincing hospitals to let you in by expressing some value prop for them/their users (thus meaning you're now also building a B2B provider app. Congrats).
All in all, the landscape isn’t exactly crystal clear, but it is positive to see so many infrastructure companies popping up to fill needs.
Brendan: Assuming you've made a tool you're selling for healthcare organizations - you've convinced your users you solve a valuable problem for them. You've gone through a security review with the hospital IT team. At this point, you'll typically kickoff an implementation process that ranges from one week (simple applications with experience) to months (definitely saw long implementations with slow vendors while at Epic).
Establishing connectivity (a VPN, the appropriate HTTPS connection, etc) to a testing/staging environment is a first step, followed by functional testing of each interface/API message flow. Even if you're used to a message format (HL7v2 ADT, for instance, or FHIR Patient Resource), each healthcare organization is a beautiful and unique snowflake. Site-specific variations on codesets or content can and will break your assumptions and previous work.
After that's been established and you're processing messages, you'll want to test full workflows (often called integrated testing, workflow testing, or end-to-end testing). You have a workflow or workflows you need users to accomplish to achieve the value you've promised/expressed. You should/need to test all of them thoroughly. You may wrap other testing types (volume testing, negative behavior testing, etc) in here if you're risk-averse. Certain EHR vendors may insert themselves here to charge the health systems for installing newer/rarer interfaces.
Lastly, you'll migrate build/configuration to the production environment and go live. This will typically occur after you've trained users in the product. You may utilize a cutover plan to facilitate this.
EHR app programs (Epic App Orchard, Cerner CODE, Allscripts ADP, Athena MDP, etc) can help alleviate / shorten some of these processes. The upfront approval process (for EHRs whose program includes that) can help speed the security reviews. Additionally, the technologies underpinning those programs (APIs) just mean the connectivity and functional testing is usually quicker. However, there are additional costs charged from EHR vendor to the app, which brings up the same confrontation we see in other app economies (looking at you, United States Congress and Apple App Store) but with perhaps even stronger emotions, given the unique nature of health data.
If you’re a provider organization, you’re going to be using a varied litany list to accomplish your goals. You may use some on-ramp API vendors for nationwide networks, like DoseSpot for e-prescribing or Eligible for eligibility. You’ll want an integration engine or a workflow automation tool to stitch together your own software, your EHR, and the other core application. You may augment your staff with telehealth services from Wheel, home health from Axle, or health coaches from Pillar.
Consumer apps have it much easier (for the limited data mandated to be exposed by SMART on FHIR). There's zero healthcare organization involvement in the process, as Meaningful Use 3 legislation and the recent ONC Cures Act means open access once authorized by the patient. You follow a pretty simple flow. From your app, you launch to the health system endpoint for the patient to log in using their patient portal credentials and authorize your app. Once they do, you'll be passed back to the app with an access token, with which they can pull down the US Core Data Interoperability data set. Given there are going to be 100,000s of provider endpoints and 1000s of payer endpoints, there are also some Plaid-like vendors that aggregate these endpoints to simplify the work for you, such as 1up, HumanAPI, or OneRecord.
If you want to check this out in action, Apple Health Records (available on all iPhones) or OneRecord are two great Personal Health Records that utilize this functionality. As noted before, though, you'll need to consider the hospital by hospital approach if your consumer app needs functionalities
[Nikhil’s note: I have done the Apple Health Records flow - it’s really nifty if you remember your patient portal credentials]
Brendan: For starters, FHIR as a name is a distinct level up from HL7v2, its main predecessor. On the flip side, every bad pun you can think of related to it has been made and will continue to be made by generations of health tech conference presenters to come.
Beyond that, what's wild about FHIR is that the actual content isn't that different from old content standards (still the same demographics, orders, results, etc, just in a new format). FHIR is exciting simply because it's an Application Programming Interface (API) which is an Internet era way of systems exchanging data with other systems. What's so great about APIs is that, when implemented correctly, they are a firm contract between an API provider (like Facebook, Apple, or Epic) and an API consumer (an app developer). Knowing exactly what can be requested and what responses will remove the need for human interaction when developing and allows engineers to be self-service. HL7v2 on paper had a firm contract (the specifications are well-documented) but in practice, each EHR and healthcare organization would implement it how they chose. That leads to a lot of wasted hours spent on extra engineering and implementation due to site-by-site variation.
APIs are also great because they're ridiculously easy to use and understand. Ease of use matters a lot. The successor to HL7v2 before FHIR was a group of standards called HL7v3 that were too rigid and hard to use, leading to a decade's worth of work... not being implemented. A good API has public and open documentation, with no fees or gating, that developers can read and even download Software Development Kits (SDKs - code snippets in various languages that plug into the API) to reduce what they need to create. Beats the hell out of dense PDFs and paywalls (aka what the insurance industry still does with the X12 standard and pharmacies do with the NCPDP standard).
What's kind of unique about healthcare here is that most other fields don't have an industry-wide standard API. It's not like Apple and Android have the same mobile APIs or Salesforce and Hubspot have the same CRM APIs. You generally see one or two major players with enough market share capitalize on that position by shifting from product to platform and allowing developers to build. By spending money to create simple-to-use APIs, great developer tools, and solid app channel marketing/sales, these dominant vendors can accelerate innovation and charge for those platform services. Everyone is happy (except maybe Congress). But healthcare is more fragmented (330+ EHR vendors out in the wild) and the biggest players have really failed strategically to capitalize, meaning now the government, through the ONC, has had to regulate to mandate a single standard API format.
Brendan: The new ONC Cures Final Rule has a lot of meat on it at 320 pages, but there are two main important pieces to focus on - first, it radically enables patients by mandating that patients can now choose and use their own apps to access their EHR data without any healthcare organization approval. This patient authorized exchange is dramatically different than anything we've had before in the world limited to BAAs and hospital-to-hospital exchange, which lent itself to EHRs and healthcare organizations exhibiting (at best) paternalistic instincts towards their patients and (at worst) outright anti-competitive behavior in sharing data. It arms a new but growing class of health applications - consumer-facing tools - with a rich set of data that EHR vendors and healthcare organizations have to expose. Given the broad access and you'll increasingly see it as a commoditized feature in consumer tools - Apple has led the pack with iOS's Health Records, but it could really benefit any consumer-facing health app, such as Whoop, Fitbit, or even Facebook's new vaccination and checkup reminders.
What's absolutely terrifying people here is that it truly is open access for any app the patient chooses, bringing the data outside of the protections of HIPAA (metaphoric Gondor) and into the lightly guarded realm of the FTC (metaphoric Hobbiton). The main fear - All the problems of controversies like Tik Tok/China, Cambridge Analytica, and FaceApp/Russia, wrapped into one, except with health data. Data privacy wonks and certain EHR vendors fiercely combated this last spring (unclear why they waited throughout the entire comment period last year) citing this reason and asking for more vetting of applications. The final rule didn't change anything there, so non-profit industry groups like CARIN are doing their best to fill the gaps with a voluntary Code of Conduct for app developers. Ultimately, there's definitely risk, but the size of that risk depends on whether you think a patient is a rational buyer/tech user who can make truly informed choices of apps for themselves.
Beyond that, many developers are really looking at another area of the rule, the information blocking provisions, expecting it to be a panacea to solve all their interoperability problems. It won’t. It focuses heavily on patient access or access by patient consented applications, but it’s not like you can say “hey, please deliver my data by carrier pigeon.” There are exceptions (that are totally reasonable) that allow the health systems to reject that and point you to supported ways of getting your data.
The rule does reduce the fees EHRs can impose on their app programs, which is great, and serves to allow for a lot easier access to reading that USCDI data set. But it's not a full rip-and-replace of old tech, so while some workflows will become frictionless to integrate, on the whole, integration (especially for provider facing applications) is still looking at a Frankenstein hodgepodge of tech for at least a decade.
Last thought here - on the EHR side, this helps large incumbents, furthering trends we've seen since [Meaningful Use 2]. Epic opposed this rule pretty strongly, but contrary to popular opinion, compliance with this regulation, like most, will be hard and expensive for smaller EHR vendors to implement, forcing their customers to flock upstream to EHRs with the resources to easily comply. For healthcare organizations, they'll be incentivized to consolidate with larger health systems.
TO BE CONTINUED - SEE THE FULL POST HERE IF YOU WANNA READ THE WHOLE THING NOW. WHY AM I YELLING.
Nikhil aka "wow a post that's too long for even me"
If you’re enjoying the newsletter, do me a solid and shoot this over to a friend or healthcare slack channel and tell them to sign up. The line between unemployment and founder of a startup is traction and whether your parents believe you have a job.
Read more posts like this in your inbox
Subscribe to the newsletter