To E(HR) or not to E(HR)
Discover more from Health API Guy
To E(HR) or not to E(HR)
The rising class of digital health provider organization are starting small, but may unlock the future of healthcare's least favorite software
To E(HR), or not to E(HR), that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous regulation,
Or to take arms against a sea of interoperability troubles
And by opposing end them.
The Tragedy of Hamlet, Product Owner of Denmark Health
Our poetic product owner and his associated company are fictional, but they might as well not be. A digital health provider organization focusing specifically on the needs of vengeful and murderous 14th-century political leaders is a bit niche, but we are witnessing a Cambrian explosion in healthcare technology, a drastic rise of digitally natively health provider organizations propelled by widespread consumer internet adoption, advances in cloud tooling and the pandemic’s multifaceted influence.
Telehealth has untethered care from brick and mortar walls. Startups focusing on chronic and ongoing care conditions like diabetes, musculoskeletal (MSK) disorders, and mental health have reinvented what care in those disciplines looks like, offering patient-friendly tools. For every flavor of primary care, there seems to be a new startup intent on using technology to break the wheel of the status quo: a spectrum spanning direct primary care, Medicare Advantage, value-based care, or concierge medicine. Simply put, a ton of the most exciting and newsworthy organizations fit this mold -Cityblock, Iora, One Medical, Folx, Doctor on Demand, Carbon Health, Kindbody, Forward, Oak Street, Spora Health, Virta…the list goes on and on. I can’t overstate how constantly exciting the breadth and variety of the new digital health provider organizations focused on specific niches is, but you get the picture.
As Chrissy points out, digital health applications rarely stay that way. The relationship with a patient can only be built up so much with pure technology. Furthermore, the revenues of direct to patient digital health are paltry compared to the beefier nature of digital health provider organizations.
Consider mental health, for example. Although they are great tools, there’s an inherent ceiling to the care and guidance that solutions like Headspace, Calm, or Big Health can provide. What happens when cognitive-behavioral therapy (CBT) isn’t working? When is the anxiety too much? It’s a logical evolution to try to break that ceiling with services, build a path of escalation and capture more revenue from payers or employers. “A few care managers or coaches would be a cool new feature,” thinks the astute Product Manager. From there, with that one well-intentioned thought, the slippery slope from software-only to full-blown digital health provider organization has begun.
Digital health is broad, so let's take a step back here to align definitions. There are essentially three main sub-genres, with overlap and evolution creating a fun Venn diagram:
Patient apps - This is the category of consumer-facing health applications on mobile, web, or other platforms. These are typically pure-play software solving a specific health-related function for a patient. Direct to the patient (B2C) is one way these start, but often as they seek to grow further, they go en masse to groups of patients via employers or their insurances (B2B2C) that have a semi-captive audience and built-in distribution. It’s an interesting organizational transition, as traditional enterprise sales flex a distinctly different muscle than building brand awareness on Instagram and recruiting influencers to hustle your health products. Examples include Calm, OneRecord, or even Fitbit.
Provider software - These organizations sell software solutions to brick and mortar / traditional care provider organizations. This is the convergence of digital technologies with traditional non-digital health care delivery models. Companies in this subdivision make software intended to bring digital trends like telemedicine, artificial intelligence, machine learning, and wearables to disrupt and take market share from legacy health technology vendors. Examples include Solv, Murj, or Vital.
Provider organizations - Digital health companies that employ providers and are covered entities themselves fall into this category. Natively digital and designed from genesis to be customer-friendly, they on paper have distinct advantages over legacy organizations bolting on digital health solutions. Their revenue comes from the same places most traditional healthcare organizations find their revenue - patients, insurers, and employers. Examples are the ones I listed before - Cityblock, Iora, etc.
Note: There’s a strong correlation between these three categories and the three trust frameworks. If I’m doing provider software, I’m exploring BAA-style engagements. If I’m a patient facing app, patient authorization is my first cut. And if I’m a provider organization, trust networks are the name of the game.
As companies evolve, they often come to operate across multiple parts of the Venn. They may, for example, release different products aimed at each segment. For example, DrFirst has a ton of digital health provider software solutions, but also a consumer digital health app, Huddle. Similarly, Amwell sells a digital health provider software solution directly to hospitals but also has its own digital health provider organization, Amwell Medical Group.
Even if companies aren't diversifying through different product lines, they often also start to operate in the margins of the Venn as their single product expands, like our aspiring young PM adding care managers and therefore shifting from pure-play consumer digital health to nascent digital health provider organization. An EHR company (digital health provider software) may expose a patient portal (a digital health consumer app). A telehealth digital health provider organization may white-label their services and sell that package to traditional healthcare organizations (becoming to some extent a digital health provider software with services).
As they make this move, digital health provider organizations come to an inherent conundrum, an enigma wrapped in a mystery. To come full circle back to the beautiful pseudo-Iambic pentameter of our modern-day Shakespeare - to EHR or not to EHR.
Digital health provider organizations don’t always know they need an EHR, especially if they start direct to consumer. They’re trying to reinvent healthcare, so building software tailored to the needs of the specific niche or vertical they’re targeting comes naturally, especially to the Silicon Valley breed. They’re starting small, with one or two workflows. As Reddit user u/Lostwhispers05 describeshere, they’re looking for a CRM for healthcare:
They may be okay at first. Buying Salesforce Health Cloud or creating their own software may work for those starting direct to consumer or in a very specific niche. But as they scale, two simultaneous factors force them slowly to the inescapable moment of whether or not to EHR.
Functionality - As they find product-market fit, these groups layer on new workflows and tools. This causes them to hit the common chokepoints that come as a function of playing in the broader healthcare ecosystem. Their nurses or doctors or care managers need to interact with external parties: e-prescribing, lab orders, clinical data exchange, all the things listed in the 2021 Healthcare Infrastructure Awards™.
Compliance. As these companies grow and look for revenue, they often look beyond the patient themselves at insurers. Of course, in the United States, there is no larger insurer than Uncle Sam. For provider groups submitting for Medicare/Medicaid populations, the providers need to be using a certified EHR, which comes with a lot of baggage.
These two factors expose the breaking point. Do they build all that themselves? Do they really need to certify the software they’ve built up over time? These are semi-solved problems, so they consider off-the-shelf solutions (EHRs). However, they are not willing to sacrifice their uniqueness, the differentiation they have via their own software’s (hopefully) superior usability, capability, and focus. It’s a build vs buy situation, but none of the options are ideal.
Buy an EHR
These groups in effect want a headless EHR. If you’re not familiar with that term, it’s because it’s a riff on the concept of headless CMS:
A headless CMS is any type of content management system where the content repository “body” is separated or decoupled from the presentation layer head. Some traditional CMS platforms offer an API that allows you to send content to a separate presentation layer. They call this “headless” because the presentation layer is separated from the body.
One way to solve the limitations of a traditional CMS is by implementing a “headless” CMS — if the presentation layer of a website is the “head” of a CMS, then cutting off that presentation layer creates a headless CMS.
Note: If you’d like to read more about headless CMS, I highly recommend this Explain It Like I’m 5 (ELI5) thread on Reddit.
Like the linked article mentions, content management systems like Wordpress or Drupal are often where companies start as an easy way of building out their websites, but as they scale and want to reference the content they build in multiple form factors, the limitations of the built-in UI or themes of the CMS hinder them from creating the unique vision they have, even as they are wonderful (or at least good) at administration and creation of content. Headless CMS start with an API first approach, building an API for every action one could want to take in the system and really not investing at all in their own front-end.
Headless EHR is the same concept, but applied to healthcare. With an API-always approach, this mythical beast would be exactly what the pioneering digital health provider organizations need as their foundation.
I say mythical because headless EHRs don’t exist today. Even the most API-forward EHRs are not the open canvases that these digital health provider organizations want or expect. Only a small subset of the functions available in the EHR UI is externally available via API. Beyond that, the data structure of each EHR is a complex and unique spiderweb, with different concepts, primary keys and pointers.
Digital health provider organizations want to build. They want to have the bare minimum necessary in the EHR, but layer on their own views and expanded functionality. They are searching for a simple and inexpensive outpatient cloud software that meets compliance needs. They want built-in integrations for things like claims, e-prescribing, and reference labs, ideally exposed via an API that they can invoke.
The most common EHRs they land on, as far as I’ve been told:
Athenahealth - The granddaddy of all cloud EHRs, it’s one of the most popular outpatient systems and has a really robust API with minimal fees that allows for manipulation of all the standard data, as well as many Athena-specific concepts.
DrChrono - Cloud-based and mobile-friendly, it has strong open APIs. I’ve heard of several groups stripping this down to its chassis and treating it as close to a headless EHR as any. However, you tend to max out and hit a wall sooner than Athena in terms of what you can do.
Elation Heath - Elation is used fairly frequently and I’ve heard good things consistently. Aimed at small practices, they have their API docs in clean ReadMe format with all the main elements (clinical data, scheduling/admin, and master data) and some goodies like webhooks. However, like DrChrono, there’s some implicit endpoint to what you can do.
Carecloud - Similar to Elation, It’s a simple outpatient EHR with a nice clean modern API. A lot of those API calls are unidirectional, though. You, again, meet your now good friend, the wall.
Azalea Health - Several groups asking about what EHR to buy brought up Azalea, who I don’t run into often. FHIR-based API that seems on paper pretty robust.
Kareo - Most groups using Kareo are looking to switch, as their API support is quite limited and fairly ratchet (sorry for the technical terminology). I think they might be inexpensive.
This personally isn’t a decision I’ve gone through, so most of the above is focused on the API/integration available for digital health provider organizations to build upon. There are obviously other factors - cost, speed of implementation, vendor support - that factor into the above (as well as disqualify other EHRs, like Epic or Cerner). When choosing buy over build, the ceiling of innovation for this type of digital health provider organization is largely defined by the capabilities of the EHR as a platform, so it should be heavily weighted.
Continue to Build
Our enterprising product manager has begun to sweat. His or her bright idea to buy has turned into a nightmare of a matrix comparing functionalities and costs, spending long nights reading API documentation only to realize that they miss a necessary input or output. As dawn breaks, they have the eureka moment.
To get that sweet sweet Medicare and Medicaid money, at a certain point you’ll need to be using a certified EHR. The calculus of that exact tipping point is a bit beyond me, but Fred Turkington of Ensocare laid it out in this thread:
When that metaphoric Rubicon is crossed, the product must meet the criteria defined by the ONC in the certification criteria valid at that time. At the time of writing, this is the 2015 Edition Test Method with Cures Update. A subset of the requirements:
Multi-factor authentication
Standard API for patient and population groupings
USCDI
Transitions of care
Clinical information reconciliation and incorporation
E-prescribing
Send and receive a summary of care
CDA creation
View, download, and transmit to 3rd party
Clinical quality measures (CQMs)
Transmission to public health agencies - cases, labs, vaccinations, cancer registries, and more
Direct Messaging
Clinical Decision Support
EHI Export
Pretty simple MVP, right?
It’s not like any one of these criteria is in and of itself difficult. Many are exactly in line with the needs and roadmap of a digital health provider organization. E-prescribing is vital and expected these days. Sending and receiving summaries of care ease the referral workflow as patients move between care settings and acuities. MFA is just smart security-wise (although I’m more of a FIDO / kill-the-password man myself). Summed up as a set of comprehensive requirements, it can become the defining focus for quarters or years for young companies, stunting growth plans and redirecting attention from other efforts.
But… it turns out that building is hard too.
A hopeful future
I am eternally an optimist, so I (perhaps naively) believe that this agony and pain this problem inflicts on our digital health provider organization brethren as they fight the good fight and unbundle the hospital will be not only justified but critical to changing the game fundamentally. This will occur through 3 possible and not necessarily mutually exclusive paths:
Common Functions Commoditization
If you read the last article on this Substack, you know that there’s a large gap in terms of the healthcare utilities we need in the US. There are a lot of companies working hard to fix that problem. Some simplify the experience of existing commodities/networks and slap a “we reach 300 million lives nationwide” whitelabel branding on it. Others are doing hard work, building new networks and capabilities. Regardless, the outcome of this path is that around 75% of the core functions of the EHR defined in the certification criteria become APIs, invoked simply and easily by digital health provider organizations and allowing them to choose “build” without hesitation. We see this occurring to an extent today - Redox for national record retrieval/vaccination information/deep partner integration, Ribbon Health for provider data, Rupa Health for lab orders and results. We even see niche use cases turning into APIs, like home health or phlebotomy.
This benefits everyone. Digital health organizations can move much more quickly to create their products and avoid long prescriptive roadmap decided by regulation. Traditional healthcare organizations can also use such APIs, if they have the technical wherewithal, or their EHR vendors may choose to selectively utilize them.
A Headless EHR Rises
Another possibility, though, is that the pent-up demand for a headless EHR and a true open platform comes to fruition. Could a traditional EHR actually and genuinely commit to openness in the fullest sense, exposing low level primitives and scarily powerful points of integration? Or maybe a brave set of entrepreneurs will seize the opportunity and solve this problem for the digital health community? Building an EHR that meets requirements with a simple regulatory-only minimalistic UI, but delegates real UI creation to customer companies focused on their core constituencies and disease niches might be the answer we’re collectively looking for.
With a headless EHR available, it could become the platform upon which many specialized EHRs are built, displacing traditional outpatient software over time and, perhaps one day, also encroaching on inpatient care (I’m not so sure that’s possible, but hey, you were promised optimism).
Digital Health Dogfood
Dogfooding is one of my least favorite terms in product and engineering. For those unfamiliar, it’s the idea that, before releasing a product into the wild, companies can incubate that product internally within their company, gaining valuable insights and iterating quickly based on their colleagues’ usage.
The last path is this trend writ large - that our digital health provider organizations build really great software for their own provider users but, after growing to a certain size, decide that they could increase their total addressable market by selling that software outside their organization. It’s an entirely different muscle, but it’s something we’re already seeing in a parallel part of the industry with the payer Oscar pivoting to selling their software.
The benefit here would be new, modern and usable EHRs hitting the market and allowing traditional healthcare organizations to make the most of digital health innovations. Compared with the other possibilities, though, this has less of a guarantee of true disruption - while these new incubated EHRs may be more modern, it will just be a shinier version of the status quo if they don’t act as a true open platform. I’m still hopeful, as a lot of these digital health provider startups are really rethinking baseline assumptions, but it’s still a risk.
Hamlet has it rough today. Whether or not to EHR is a complicated and imperfect decision. But the changes happening across the industry - a growing class of digital health provider organizations, cloud-enabled and relentless in their focus on the patient experience - promise a different future reminiscent of a different play, as Cassius Health urges Brutuscare:
Startups at some time are masters of their fates:
The fault, dear reader, is not in our vendors,
But in ourselves, that we are underlings.
To that end - will you join our fictional Cassius Health in this plot and change the narrative of where healthcare will go?
Updates
I’d like to periodically (annually?) update this article to talk about the current state of modern EHRs.
March 21, 2022:
For those curious - I say build today. Better to have a floor to motivate you than a ceiling to hold you back.
Thanks to Nijay, Garrett and Colin for the review and editing. If you have thoughts or know of other good options regarding EHRs as platforms to build upon, please reach out to brendanjkeeler@gmail.com.
To E(HR) or not to E(HR)
Great post. Have you looked at Zus? https://zushealth.com/
Brendan, you have my brain buzzing here. I just wish it wasn't approaching 1am. It'll all be worth it if you and I can arrange to talk sometime soon.
So, let's talk!