This blog post is the first in a three-part series detailing the evolution of Curai Health’s electronic health record (EHR) software, which powers our entire chat-based telehealth platform. This particular post talks about the origins of our EHR, our decision to embrace FHIR as our data model of choice, and some key clinical and engineering design decisions that are central to our goal of long-term, personalized, longitudinal care for each and every patient we serve.
At Curai Health, our mission is to bring the world’s best healthcare to every human being on the planet. In order to achieve that goal, we need to provide our clinicians with tools that enable them to provide the best care possible to their patients. With an all-digital, chat-based telemedicine solution, the notion of “longitudinal care” becomes especially important. This means understanding the patient, their medical context, their life situation, and their healthcare needs in as thorough a manner as possible. Curai Health (at present) doesn’t have the luxury of seeing patients in person, so establishing a strong relationship with each patient and tracking their overall health over time is critical.
In addition to delivering high-quality care, part of our thesis is that scaling healthcare to every human being on the planet will involve utilizing clinical decision support systems powered by machine learning. Those tools are obviously dependent on gathering high-quality structured patient data, while overcoming the inherent tradeoff between structured data gathering and provider efficiency. A provider can quickly type free-text, but absent a leap in clinical language understanding that hasn’t quite occurred yet, free-text is still far inferior to structured data — which involves coding each observation and clinically relevant finding — from a machine learning perspective.
A final component of a good EHR solution relates to interoperability. In healthcare, interoperability is like a combination between the Loch Ness monster, Bigfoot, and the Abominable Snowman; that is to say, you’ll probably know it when you see it, but you’d be hard pressed to find it. However, in recent years, interoperability has become a critical component of the modernization of healthcare, and many institutions are embracing it as an integral part of how doctor — patient relationships will work in the future. At the forefront of this push is the Fast Healthcare Interoperability Resources standard, commonly known as FHIR and pronounced as “fire.” This protocol is a data storage and interchange format that provides opinionated but flexible schemas that captures most of the healthcare information and data you would expect patients to generate — findings, diagnoses, visit notes, prescriptions, medication allergies, lab orders, lab results, etc. And so, we have the three pillars of what a gold-standard EHR would look like:
This blog post series will take you through the journey of how we at Curai have been working to uplevel our EHR to satisfy these requirements. But, before we dive into the details, a little bit of history is in order.
Curai’s EHR solution began as a very simple tool for keeping track of patient visits, which essentially consisted of a few basic input fields. While this served our initial use case of capturing the bare-minimum of patient information, it proved to be insufficient as we further expanded the service into a true, fully-fledged telemedicine product, offering medical recommendations, prescriptions, and lab orders. Now, while patients could still engage with practitioners to get medical information, we also had to tailor the discussion to account for their medical history and to keep track of each patient as well as any traditional brick-and-mortar healthcare provider. The original EHR, both from a data modeling and user experience perspective, was not built to serve this use case. Reflecting back on our three ideals, we strike out swinging. In the old Curai Health EHR, each encounter (or visit with the system) was treated as a standalone entity, with no patient-centric longitudinal component tying multiple such visits together. Our input fields only captured free text. And the bespoke data model was not at all interoperable with any external data sources. We needed to make some drastic changes.
We went back to the drawing board and reimagined our ideal EHR. The result was a data model centered around FHIR and a corresponding user experience that read from and wrote to the new FHIR data model. Choosing to work directly on top of FHIR, rather than translating proprietary data formats into and out of the FHIR data model, does have an alignment cost, where we need to map Curai Health concepts into the corresponding FHIR resources; however, that cost pays for a critical benefit, which is zero-effort interoperability, since the data does not need to be transcoded to share with external partners, merely serialized. We recently presented our work in this area at the 2020 AMIA Annual Symposium and were selected to be a prize winner in their FHIR app competition!
What follows is a description of how we use specific FHIR resources to capture, in structured form, all of the pertinent healthcare data that powers the Curai Health experience for both patients and doctors.
The first resource we need to cover is an Episode of Care…
FHIR defines an Episode of Care (EoC) as “the period of time in which a Healthcare Provider has some responsibility for the care of the patient regarding a specific condition or problem.” There is a lot of flexibility in this definition — an EoC could be any medical issue that a provider follows, from a chronic condition like Diabetes (which spans over lifetime of visits) to an acute issue like an acute sinusitis (which wraps up in a few weeks). Each of these visits are represented by an Encounter, which again can be adapted to represent an outpatient clinic visit or the entirety of a hospitalization, from admission to discharge.
Continuity of Care, the goal of delivering high quality care for patients over a period of time, is a shared responsibility among the Care Team at Curai Health. For a provider to pick up where the last visit left off, they need to understand how the EoC has progressed and what has happened at the last visit. Representing a single visit to the platform, each Encounter would contain all the EoCs discussed in that visit, along with the relevant clinical data. Representing the relationships among Episodes of Care, Encounters, Conditions, Observations (clinical findings), and provider notes became a challenge.
In our first FHIR implementation, we established that multiple EoCs could be associated with a single Encounter. Encounters were used to represent a chat with a provider. A huge benefit of the Curai platform was that a user could have multiple Encounters with us in a day if they were concerned or if providers thought they required close monitoring. Providers could indicate which diagnosis they considered most and least likely (called a differential diagnosis) by virtue of the FHIR attributes in EoC, specifically EpisodeOfCare.diagnosis.condition and condition.rank.
This left the question of where to store supporting evidence. For this, we leveraged a little-used property of Conditions called Condition.evidence to shoehorn Observations into the mix. So, to recap, Episodes of Care develop via Encounters, which feature Conditions and Observations to represent differential diagnoses and clinical findings respectively. As an aside, this proved to be a significant pain point, and as such we have since reworked this structure. But that is a topic for a later post in this series, so stay tuned.
I’ll now hand it over to Viggy, my fellow FHIR jedi, to go behind the scenes to talk about technical considerations.
Did you find this post interesting? Curai is actively hiring for multiple positions across many different disciplines. Check out our careers page here.
