How to integrate into an EMR and why Epic won with Brendan Keeler

Today I’m interviewing Brendan Keeler, a man that knows more about healthcare data and interoperability than I know about myself.

We discuss:

• What actually goes into an EMR rollout, an integration, etc.
• The impact of the new interoperability rules rules
• How the US and EU differ when it comes to healthcare data 
• Why Epic dominates the EMR market

1) What's your background, current role, and the latest cool healthcare project you worked on? 

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.

2) A lot of people have asked about EMR integrations. I know there are lots of different types of ways you can interact with an EMR if you're a third-party, what are the different types of integrations/techniques for getting data in-and-out? How should a company decide which route to take?

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.

3) Can you walk me through what the steps of integration look like for both the provider and third-party application side? How long does this usually take?

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]

{{sub-form}}

4) You've mentioned FHIR a few times, but practically why is FHIR such a big deal? What are things you can do with FHIR as a standard vs. previous standards?

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.

5) There's been a lot of debate and hope around the ONC's new interoperability rules. What's important about them and what new opportunities do you think it's opened up?

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. 

6) The reality is that Epic has basically swallowed market share for most large provider systems. What is it about Epic that make hospitals default to them?  Who's making that decision and what are they considering when they end up choosing Epic?

Brendan In short: a lack of competitive offerings due to an absurdly high bar for an MVP. 

People tend to think of EHRs as just another piece of enterprise software, which any company can spin up. That plays pretty well for outpatient care, especially if you can segment to just one or two specialties and crush it (ModMed, Elation, etc). However, in light of the continued consolidation of healthcare organizations across the industry, single-specialty organizations are an increasingly rare breed. More importantly, the core of these giant Integrated Delivery Networks is inpatient care (with a vast radius of tightly coupled referring outpatient facilities), and, for inpatient, single-specialty is completely antithetical to how workflows happen. Inpatient is a perfect storm of enterprise software demands unlike really any other industry:

• A reasonable number of total users, but with vastly varying workflows / functions. Surgery and associated needs are drastically different than ED, ICU, cardiology, etc and that's just thinking about doctors, let alone nurses, lab techs, registrars, schedulers, billing admin, infection control, or the myriad roles in play. It's kinda crazy we lump them all together and you need to meet all their needs.
• All of this variation seems to lend itself to best of breed/user-focused software. However, in inpatient, everything is all absurdly dependent on one another, a sprawling Rube Goldberg machine of intertwined user workflows. Each handoff sets off a ton of other decision making and associated actions.
• Lastly, healthcare is demanding in terms of every technical operational metric (latency/uptime/integrity/responsivity) in a way that's fundamentally unique. Outages are bad for transportation or retail or agriculture, but in healthcare, it's people's health and lives. 

Anyway, when you lump these requirements all together, you are left needing a really complex and complete software that meets hundreds of different workflows, requiring thousands of features, with impeccable performance. Note that that's before you add in regulatory requirements. The investment needed to build that basic MVP is ridiculous. A lot of people wonder why you don't see Apple, Amazon, Google, etc going  straight for the jugular here and building an EHR - beyond the core competency issues (why does Jim Cramer thought Apple, a consumer product company, would get into complex enterprise software in an industry they haven't played in is beyond me) it's just a massive lift.

If and when they do make moves there, I have to imagine they too will start with an off-the-shelf EHR and build on top of it. Until then, they'll play to their competencies (Apple with Health Records, Amazon with Alexa/Amazoncare/Pillpack, Google with Cloud Healthcare API, Microsoft with Azure for Health, Salesforce with Health Cloud) and work their way inward.

Hospital leaders are therefore heavily incentivized to use proven products that meet all the workflow and compliance needs but can flex to fit their organization's unique Rube Goldberg machine, leaving a paucity of choice. With Athena exiting the acute care market, Epic and Cerner (or Meditech Expanse as the budget option) are just the last products standing for inpatient care. Epic in particular really sells a compelling vision of simplicity of "the one system" with inherent reduction of friction, while still having the possibly most feature-laden offering. Oh, and contrary to @EPICEMRparody and other sources, a lot of users, especially younger, quite honestly like Epic. 

[Nikhil’s note: you can reach those users via AIM or carrier pigeon]

7) You've spent time in Europe rolling out EMRs/healthcare data exchanges. What's different when it comes to working with healthcare orgs there and rolling out an EMR?

Brendan: International healthcare gives you a strong appreciation for what we're good at or not so. The Dutch, for instance, have widespread electronic image exchange between hospitals (something that the Radiological Society of North America is all about but is not a national priority currently at the ONC or national networks) and really strong systems for referrals from huisarts (Dutch Primary Care Providers) to hospitals, but are a few years behind the US on e-prescribing and discrete clinical data exchange. They have some cool workflows that we had to adapt the software to - multidisciplinary team meetings (MDTMs) for cancer are table stakes for all hospitals, they do a heck of a lot more day treatment (short stay bedded care), and the predominance of midwives as part of their obstetric care are all not that crazy/different at a high level, but getting really inventive with build/configuration was a must.

The biggest takeaway is that each new country is its own beast. You don't just jump into the EU and scale; the national borders are surprisingly harder boundaries for software to traverse than a regular person. The UK, the Netherlands, Denmark, etc all have their own standards/codesets to conform to, regulations to adhere to, and workflow nuances to adapt to. Billing is drastically different from country to country, with nations like the Nordics using variations of single-payer vs the NL, which is well-funded and executed Obamacare-esque "universal healthcare via private insurance". When you add the language barriers on top (if you think reading HL7 standards are already hard, try reading the Dutch version), social policy aspects (32 hour work weeks during projects instead of 50-60), and significantly less money in the mix (US spends a lot more on health IT and admin), it just adds friction and stress. While implementing over there, as fun as it was to be exploring new countries with great colleagues/friends (the Epic Den Bosch office, nicknamed at one time “Burning Man NL” by Epic’s President Carl Dvorak, was an extraordinary cast of ridiculously talented characters) and engaging at a national policy level on behalf of Epic, you did not really want to be on the "first-in-country" install. No matter the level of preparation and development done upfront to deal with those nuances and differences, it was always a mad scramble, all-hands-on-deck, sprint to the finish line all the way to a go-live. This trend continued after my time with recent go-lives in Finland and Belgium and will almost certainly be the case for others to come.   

Beyond that, for better or worse, most of the basic cross-organization healthcare infrastructure is generally more multi-functional, centralized public utilities in the EU countries, whereas here we have single function private companies and non-profits like Surescripts, Carequality/Commonwell, DirectTrust, PatientPing etc). It's interesting to think of what our own infrastructure might be if nationalized.

8) What actually goes into the rollout of a new EMR system? Why does it take so long?

Brendan: The best way to think about this is to actually look away from healthcare. Taking a step back, if you look at most industries, B2B software usually takes some sort of implementation time. B2B SaaS companies (especially when you start to look at anything term or priced as the "enterprise" offering) aren't like consumer SaaS - they're staffed with implementation or customer success to help with configuration. Salesforce, for instance, takes 2-8 weeks to setup for most small businesses. So when you line that up with healthcare, that's not so different than a small practice turning on Athena or one of those small clinic, outpatient focused EHRs. And when you scale up to the whales that Cerner or Epic focus on, you get similar timelines to Coca Cola implementing their Salesforce CRM or Caesar's implementing their Oracle Cloud ERP or (stepping into your former life) or Astra Zeneca with the full Veeva EDC/eTMF/CTMS suite. It's that Rube Goldberg machine of overlapping functions and roles and exponential complexity that needs to be created and validated (with perhaps a bit of extra implementation time due to healthcare needing that high uptime and performance). I think some SaaS companies gets some efficiencies shedding the hardware/server setup but you're essentially sorta implementing five or ten or twenty different distinct B2B softwares for various users when you're getting to that scale, regardless of sector*.

And not to deconstruct and over-generalize an entire role, but the implementation process is pretty much the same at its core across all of those:

• Discover / Plan
• Create/Build/Configure
• Validate with users and test
• Training
• Go-live

You see different variations/groupings that consultants or vendors will point to as their special sauce, but some quick cross-functional googling shows a lot of the same:

https://www.industries.veeva.com/services/

https://www.quora.com/How-many-hours-does-it-take-to-implement-and-customize-Salesforce-com-CRM-for-a-small-business-or-non-profit-organization

https://questoraclecommunity.org/learn/blogs/how-to-cloud-a-five-step-guide-for-a-successful-oracle-erp-cloud-project/

Uncontrollable dependencies are the genesis of unexpected delays and unexpected delays are the death of projects. I think people tend to think in terms of what they know best, so working on data integration and conversion might color my thoughts here, but these are project necessities that are inherently external dependencies and therefore innately represent the biggest threats to projects. The biggest external dependencies you'll see come in terms of loading old data in a clean way (conversions) and connecting other software/hardware tools you use (integration). It's needed in some capacity no matter how you scope things. However, getting buy-in and engagement with the parties (oftentimes competitors) needed there is way harder than customer users or your own company resources. The variability of capabilities and expectations is hardest to control or build out-of-the-box as a vendor. It was always fun to see implementation leads grow from "what are these tech guys doing" to "oh shit this is what makes or breaks our overall deadlines".

*I know I'm going to get slammed in the comments / social by implementers who claim to be the exception to this logic and I invite that discourse on Twitter to learn and hopefully apply it to healthcare. I yearn for forbidden knowledge of the self service install wizard for multi-billion dollar companies' enterprise software.

9) You mentioned that you're working on enterprise-to-enterprise interoperability. What're the main differences there vs. app-to-emr interoperability? And why would these enterprises want to participate in this/what use cases are they trying to enable?

Brendan: So a metaphor helps here. Healthcare organizations are like cities with their own little closed ecosystems with their own rules and bylaws. If we look at transportation around those cities, we see a lot of variety, where small towns may still have dirt paths but big cities have all sorts of roads and light rail and scooters and such. The same applies for these organizations, with small outpatient clinics using SFTP of CSVs or other dirt road equivalents and the big cities of Kaiser or Mayo having much more modern "transportation" like FHIR.

Enterprise to enterprise is answering the question of how to get between the cities. You can use planes or highways or long distance trains but you need to build up and maintain that infrastructure. The cities aren't always itching to create that. There's often a lot of federal involvement and assistance and oversight. 

Backing out of the metaphor and into the real, enterprise interop is all about the transition of care of the patient, generally between covered entities. From PCP to acute care, acute care to skilled nursing facility, skilled nursing facility to a pharmacy, and then to the insurer. The fact that we have any friction in those handoffs today is detrimental to all, but mainly to the patient. There's no reason you should ever have to fully write in your meds, allergies, problems, med history, etc. Carequality, DirectTrust, Surescripts, etc all exist as that well-established but still not fully used infrastructure in this realm. 

The actual standards in use matter, in that easier/better standards make adoption easier, but people focus way too much on that, to be honest. Whether the use case is satisfied by HL7v2 or by FHIR or by CDA, what actually matters is adoption. Surescripts and NCPDP make the prescription process really easy - it's super rare to see printed prescriptions any more. And that's not because NCPDP is a fantastic standard - it's not. It's distinctly an ancient relic of generations past - obtuse XML, hidden behind paywalls, and pretty much in vendors' pocket. But Meaningful Use 2 ensured nearly 100% adoption and 100% adoption of a bad standard is exponentially better for our overall ecosystem than 50% of a good one. I honestly wish the federal government was more heavy-handed in this regard.  We could use the Interstate Highway System for healthcare. The other major piece of legislation coming up, TEFCA, focuses on enterprise to enterprise interoperability and is promising, but lacks teeth in that it’s voluntary and not incentivizing anyone to make the necessary investments.

So it's that interoperability between healthcare organizations (and not the app to EHR interoperability within an enterprise) that is ultimately the biggest problem in sight for us as a nation. Pull back the curtain a little and you see that so many of the endemic problems and bad experiences in healthcare come from the shoddy covered entity handoffs:

"Oh, referrals and prior auth suck." -> Handoffs between healthcare organizations and payer

"Why can't I move my prescription from CVS to the Walgreen's near me?"  -> Handoff between two pharmacies

"Why is the lab faxing COVID data to my physician and the state registry?" -> Handoff between reference lab and state agencies

"I can't find what provider to use" -> Handoffs between payer back to providers

You can play this game all day from bottom-up by thinking of problems in healthcare and how they relate to handoffs or top-down by thinking of handoffs and associated pain points (I’ve taken a pass with my one newsletter article here). All those should be motivators for enterprises, especially when viewed in a population health/value-based care light, but there are a few things that block that many of these handoffs are status quo from a pre-digital world.

One is simple ignorance/lack of awareness and that's curable. The second is data ownership. Data is sometimes viewed between these parties as an asset currently and that's a problem. You don't see modern cities throwing up walls and tight border control to restrict their population; modern cities compete on their ability to attract residents and visitors with valuable services and interesting experiences. Healthcare is still living in a time of walled cities. So I'm a strong proponent of open and mandatory exchange between covered entities (healthcare organizations, pharmacies, labs, payers). With full enterprise-to-enterprise exchange and no friction between covered entities, these organizations can focus and compete on their core competencies of providing care/dispensing meds/approving claims/whatever they're supposed to be doing instead of data hoarding. The outcome is that competition increases, choice increases, and the patient experience is ultimately bettered. The full adoption and use of all the infrastructure (i.e. building roads and train tracks between all cities and towns) is a must to achieve that goal.

Bonus: The stories of Epic's insane campus are well-known by this point. Do you have a favorite room in it and why?

Brendan: Most of my domestic Epic career was spent in Atlanta, Omaha, and other implementation sites, or on State Street trying in vain to improve my relationship status (I knew nothing), so my time (and favorite) was the lower levels of the Voyager Hall / Deep Space complex. It's sorta the mullet of Epic building, with a nice and put together visitor center and educational complex for customers on the top, but a byzantine maze of tunnels ultimately radiating outward under the entire campus. Some say that there are new hires that will forever roam those halls looking for an open meeting room. A stark contrast to the buildings with dragons and slides that local schools toured weekly, it had a distinct 10 Cloverfield Lane vibe and fun features like the ability to withstand a direct hit from a midsize ballistic missile. Firmly convinced there's a Raven Rock style command room down there somewhere for Judy and the team if needed.

As an unasked for extra - My favorite Epic-ism was EpicCorps. Lot to unpack there, naming the group of EHR company employees who were sent abroad after a federal volunteer organization for international social assistance (but hey, maybe that's why there was a 30% pay cut).

Thinkboi out,

Nikhil aka. “EpicCorps probably sounds super cool if you're not in healthcare"

Twitter: @nikillinit
IG: @outofpockethealth

---

{{sub-form}}

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.