Note: This is the second installment of a three-part series. Check out Part I to review the introduction to this series and our discussion about the seven core elements of care modeling.
As the care delivery landscape becomes more digital with more diverse care teams, care modeling needs to evolve from a periodic offline exercise to an ongoing online capability that's part and parcel of delivery itself. The elements of care modeling discussed in the first installment of this series offer an inventory of decisions that need to be made and monitored and point to software capabilities that are necessary to operationalize those decisions. The best care delivery startups carefully weigh which aspects of the care model they need to build themselves and which dimensions can be accelerated through enabling technology. Before we lay out a framework to help to simplify the dozens of decisions that lie ahead, we need to clarify a few points.
About Systems of Record
Before the HITECH Act, practice management (PM) systems were typically different vendors from electronic medical records (EMRs, same as EHRs). The reason is simple, the business case for PM systems was pretty clear: get paid faster and manage your clinician schedules – asset utilization – more efficiently. So those businesses got started and grew earlier.
Then HITECH came along and it became relatively impossible to be one and not the other. So these two disparate systems of partial record (PMs = operational and financial record, EMRs = clinical record) got mashed up and, for whatever reason, took on the EMR product category banner.
EMRs are the system of record for care delivery. That isn't controversial. What is controversial is the extent to which they are or should be systems of work/engagement or systems of intelligence. Some folks think EMRs will go quietly into the night and be backend systems of record (never gonna happen). Others (*ahem*) are turning EMRs into full-fledged care modeling systems so care delivery companies can extend their systems of work and embed intelligence.
So as you're thinking through your enabling technology, grab the system of record question by the horns and try categorizing your own software and that of your potential vendors into those three groups: systems of record, systems of work, or systems of intelligence. It may help draw out assumptions about software you didn't know you were making.
The Headless EMR
Headless browsers and content management systems (CMSs) have been around for a while. I remember when Headless Chrome came out and was excited by the applications, and it's cool to see companies like Cypress for automated testing use the capabilities to great benefit in the developer toolchain
This post from Brendan Keeler is a great discussion of how the headless concept could be applied to EMRs
Let's dive deeper into the headless CMS approach. They come with (a) extensive APIs that enable companies to build totally custom UIs for their end-users, and (b) pre-built UIs to help employees at the company run the CMS, i.e., manage content, settings, etc. If companies had to rebuild the internal staff-facing UIs for headless CMSs, it would certainly waste time and duplicate effort.
The end user for digital care delivery companies is the patient. So when we say "headless EMR," we mean it in the exact same way headless CMS has been implemented. The head is the patient-facing UI. Rebuilding the internal clinical, operational, and financial UIs to deliver care is a massive undertaking, would require 3rd-party certification in many cases for those UIs, and wouldn't do a whole lot for accelerating go-to-market timelines or improving capital efficiency.
That said, new care delivery companies need a lot of control over their workflows; workflows are the care model in action. And that's where server-side SDKs come into play. Rather than requiring you to rebuild staff-facing UIs, a server-side SDK allows you to control existing ones. It's the best of both worlds, and that is the strength of a Headless EMR.
Now the framework to help you approach your tech-stack adoption…
Fake It
If you anticipate low complexity in your care model, but have only a vague notion of what the first version of your care model will be, you might be able to postpone major technology decisions. Sign a BAA with Google and use Google Workspace to get started in a HIPAA-compliant way. Make a folder for each patient, use Docs for notes and Sheets to track tasks. This is unquestionably unsustainable, but we've seen it done safely as a way to test assumptions and iterate at the low end of complexity without much cost. Keep in mind you're just buying time here, and the risk is falling into a trap where you've amassed unorganized data faster than you've iterated toward a scalable care model with adequate software. We've seen companies graduate successfully from the hack, but we've also seen one bite the dust.
Retrofit It
Retrofitting historically has been the most popular way of pressing existing technologies into service for novel digital care models. With this strategy, you choose an EMR partner (with or without revenue cycle management (RCM) depending on your business), and then build a small number of "sidecar" type applications to fill the gaps. This strategy tends to work well when the information flow is mostly unidirectional, i.e., when you need to only read data out of the EMR, process it, and then display it to your care team in a new way and stop there.
The Retrofit strategy becomes difficult when the gap you need to fill requires writing back into the system of record. And it becomes wholly untenable when the frequency of the read-write cycle is high, e.g., if you're attempting to respond in a sidecar application to events that happen in the system of record, then write those back, and do that in a chained sequence as you'd expect for use cases like diagnostic and treatment guidelines.
Commure seems to be focused on solving some of these issues for the EMR(s) used in the health system setting. So if by some chance you're using Epic through Community Connect or Cerner through some other program, that might be a possibility to increase the viability of a Retrofit to support your care model. If you're like the 99% of care delivery startups who are not using Epic or Cerner, you'll want to go the Retrofit route only if you're primarily solving information retrieval problems and don't plan to bet big on writes or automation.
Gather It
Think of this as a hub-and-spoke model, where you commit to building the hub and then the spokes are various services you integrate to gather the functionality you need.
You take on the burden of being the system of record and gain all of the control that entails. You'll need to define and maintain potentially hundreds of tables, not just to model the different domains of data relevant to you, but also to normalize and merge the data you get from your different integrated services. Examples of services you might need to integrate:
- DrFirst or Truepill for e-prescribing
- Health Gorilla for lab orders
- Particle or Health Gorilla for broader HIE connectivity
- Ribbon for provider data
- Stripe for all kinds of patient payments
- Lob for mail, Twilio for texting, Sendgrid for email
- A secure fax service like sFax
- Wheel for ad hoc staffing
- An insurance clearinghouse for eligibility, claims, and remits
- Patient education content like Healthwise or FDB Meducation
- Welkin for care planning
- DataMotion or SES for compliant exchange with external providers
- The list goes on
- and on… many dozens more possible services
One disadvantage to this approach is that you can't serve Medicare or Medicaid or many Commercially-insured patient populations operating under payment models that require an ONC-certified EMR as the system of record. You could put that certification on your roadmap, but you should probably brace for a very difficult budgeting and capital raising conversation at your next board meeting…
A second disadvantage of Gathering is that your care team will have a disjointed experience and need to learn many different tools, with limited opportunity for workflow automation across system boundaries (we'll get into Automation Boundary Risk in the next section).
But if you don't need to serve those populations, you can steadily build out your system of record and plug in services as you need them. You'll have lots of data normalization to manage, and many product roadmaps to respond to across your different vendors, but you'll have a lot of control, centralized state, and better ability to automate insights with limited-but-hopefully-growing ability to make those insights actionable within 3rd party apps.
Harness It
Harnessing a care delivery platform that offers speed to market and care model control is the holy grail we're after. (Disclaimer: this is the first of two places I'm going to plug Canvas.)
Speed comes from getting a system of record and default system of work/engagement out of the box. Meaning you can use the system on day one for your operational, clinical, and financial needs.
Control comes from a combination of open data exchange between your patient-facing software and Canvas, and then access to a server-side SDK that's tied into an event loop so you can define — in code — the workflows that bring your care model to life.
Because the workflows are native to the system your care team uses for care delivery, you're actually deploying your defined model into the wild. You can monitor performance to see where actual delivery differs from the model, and learn over time. It's a learning system that enables robust care model definition across all the elements described above, and then continuous improvement as time goes on.
This ability — to enable broad and deep 2nd-party developer control of EMR workflows and content — is how Canvas has turned the EMR into a full-fledged care modeling system.
Part III: How to Choose Your Healthcare Tech Partners
In the final installment of this series, we conclude with a set of trade-offs to weigh as you dig in and start choosing technology partners to build your tech stack with, before offering some final thoughts.
