At MassLight, we invest in health and medical startups by providing capital and engineering teams. We’ve run into the same problem consistently: writing software to improve clinician and patient experiences was crippled by the EHR.
Seemingly simple actions like programmatically retrieving appointments, improving patient-clinician communication, or automatically updating patient information were challenging. We found ourselves constantly limited by the EHR’s API — if the EHR had an API at all. These APIs are rarely built using technology that is practical for engineers to integrate into custom code, or they don't provide data in the expected industry-standard formats. Effectively, clinical organizations didn’t own their own data; it was siloed by the EHR vendor.
A few years ago a large pediatric urgent care organization asked us to sidestep these issues altogether by building them a custom EHR. Like nearly every clinical organization, they knew the software experience for their clinicians and patients wasn’t as good as it could be. We reluctantly declined the opportunity because it was too risky and expensive, both for us and them. We estimated it would take a team of 30 engineers three or four years to complete, and even with a team of this size, the project would still have a set of risks we weren’t comfortable assuming.
But internally the question nagged at us: was spending millions of dollars and thousands of hours on a custom EHR for each of our clients the only way to avoid these frustrating roadblocks? We regularly discussed what it would take to make building a custom EHR feasible. We considered how the complexity of a project like this could be simplified, and debated the concept of a “headless EHR”. A headless EHR is designed to work only as an API; applications are built on top of it.
To help understand the value of a headless EHR, consider cloud platforms. Much of the software built today is on top of cloud platforms. For years, the tech industry has utilized these platforms to provide services for dozens of tasks, provision and manage servers, host data stores, and for authentication and security. You can think of Oystehr’s headless EHR like an “AWS for EHRs.” A headless EHR has the potential to solve a host of technical, operational, and regulatory challenges, eliminating 85% of the effort needed to build custom EHRs or other specialized health tech software in a way that isn’t possible on generic cloud providers.
Oystehr is our headless EHR.
Fast Healthcare Interoperability Resources (FHIR) are a healthcare industry standard for interoperability. It makes integrating with other applications built using FHIR easier and smoother.
This prevents vendor lock-in; with many EHRs, data is exported in that EHR’s custom format — if the EHR lets you export your data in the first place. Switching from one EHR to another is often an expensive and lengthy process. If you decide you’re unhappy with Oystehr, just export all of your resources and they’re already in an industry standard format.
Oystehr is a backend. Here are some of its benefits:
Like most cloud platforms, we charge usage-based pricing. No up-front costs, no annual contracts, no per-provider or fixed monthly fees, no percent of revenue, and no hidden integration or API access charges. Pricing is simple and transparent, with a free tier.
We are planning a few sample projects to help you get started that cover some common use cases of Oystehr.
We’re building Oystehr and are using it internally with a few customers. Our first customer product is live on Oystehr today. You can access Oystehr sandboxfor free, so developers can sign up themselves and start exploring. For a full view of our roadmap, visit the homepage on oystehr.com
Curious to explore how Oystehr works? Request free access and check it out.
FAQs
1. How does Oystehr's headless EHR approach differ from traditional EHR systems, and what advantages does it offer in terms of technical, operational, and regulatory challenges?
Oystehr's headless EHR functions solely as an API, making it distinct from traditional EHR systems. It aims to simplify complexities associated with building custom EHRs and addresses technical, operational, and regulatory challenges by providing a backend infrastructure, serverless APIs, FHIR interoperability, and compliance features.
2. Are there practical examples or case studies showcasing Oystehr's effectiveness in real-world applications?
Here’s a recent case study on how the virtual pulmonary rehabilitation clinic, FlexTogether, was able to reduce claim submission efforts by 80% using Oystehr's claim submission service.
Our new behavioral health intake application, built on Oystehr, allowed us to build a solution that is customized for our use including scheduling, insurance validation, and direct integration with our eClinicalWorks EHR.
Chief Medical Information Officer at PM Pediatric Care