Implementing healthcare systems is a complex challenge that often leads to frustrating outcomes. Single vendors struggle to deliver comprehensive solutions due to their limited expertise across the diverse workflows in healthcare. A chilling example of this is a Veterans Affairs center that spent 4.4 billion dollars on modernization, yet tragically contributed to four veteran deaths. Building custom systems by hiring experts for each area is prohibitively expensive and results in disconnected data silos that can't communicate effectively. Each new requirement tends to create a new isolated system, further complicating the landscape.
Traditional approaches to healthcare software development have significant drawbacks. Standalone software often lacks integration capabilities, mega-suites can be inflexible and expensive, and custom-built solutions are time-consuming and difficult to maintain. These issues highlight the need for a more effective approach that can address the complex needs of healthcare organizations while remaining adaptable and cost-effective. We previously wrote about this inflexibility and why Health Data Platforms may be the only viable solution to this madness.
Building interfaces on health data platforms can be a double-edged sword. While these platforms offer flexibility and are based on standards that make software development easier, they often require significant effort to implement well. The platforms come with developer-friendly interfaces, but these are far from what healthcare practitioners actually need in their day-to-day work. This means that teams must invest time and resources to customize the platform to fit their specific use cases, as the out-of-the-box solutions rarely cover all the necessary workflows.
However, it's important to note that building completely custom user interfaces (UIs) on health data platforms is also challenging. It requires deep expertise in both healthcare processes and software development, which can be costly and time-consuming.
Low-code platforms, while promising quick solutions, often introduce unnecessary abstractions that can complicate rather than simplify the development process. The ideal approach lies somewhere in the middle – leveraging the strengths of health data platforms while carefully crafting user interfaces that truly meet the needs of healthcare professionals without overcomplicating the development process.
Low-code solutions, often bundled with Health Data Platforms, initially seem like an attractive option for building user interfaces. They promise faster development and easier maintenance, which can be appealing. However, these platforms essentially create a new abstraction layer, reinventing HTML, CSS, and JavaScript, which can introduce its own set of challenges. This limitation has led to the rise of specialized consultants who know these tools well, potentially creating a new dependency for healthcare organizations.
Now with the rise of AI coding platforms such as Cursor and Github copilot, writing code is easier than ever. They can understand context, suggest entire code blocks, and even complete complex functions based on natural language descriptions. Moreover, these tools continuously learn and improve, adapting to individual coding styles and project-specific requirements.
Developing a full-code EHR system is undoubtedly challenging, but it offers the flexibility and control necessary for creating a healthcare solution. By building on top of existing health data platforms, developers can leverage standardized data models and APIs while maintaining the ability to customize as needed. Building your own custom EHR to fit your needs might seem like a good idea starting out, however with a list of ever changing requirements it becomes challenging quickly. If every part of the EHR can change based on requirements, over time each implementation of EHR becomes its own separate version and leads to unmaintained software. Such software is often undocumented and failure prone.
We have successfully implemented our approach of common abstractions multiple times, as evidenced by projects like the COVID Care India platform and the Portable Health Clinic case study. These experiences have taught us valuable lessons about common patterns in EHR development, such as patient lists, forms with value sets, patient summaries, and embeddable applications.
Leveraging our vast implementation experience, we have identified common patterns that can be abstracted, in order to create a more efficient development process. This way, we can retain the power and flexibility of a full-code solution. The common patterns we have arrived at are Patient Lists, Forms, Summaries and Embeddable applications.
We built Medblocks with the knowledge of common patterns of the EHR that we have learnt over the years. We identified common patterns in how medical data is stored and used, and these patterns became the building blocks for our system. By using these familiar "blocks," we can develop standardized computable artifacts that can be plugged into the EMR and deliver customized needs to each workflow. Medblocks is designed to be a modern electronic health record (EHR) system that works across different health data platforms.
Let me briefly explain it below.
We've created a patient list system based on FHIR standards, using concepts like encounters and practitioners. This patient list is the starting point for all healthcare providers, and we've made sure it works seamlessly with FHIR APIs.
Creating forms that work for all clinical situations is challenging. Different healthcare providers need different fields and ways of interacting with forms. We learned this firsthand while working with various hospitals. To address this, we use openEHR templates as the foundation for our forms. This allows us to make changes quickly without altering any code.
By using openEHR templates as our source of truth, we can automatically generate forms that clinicians can design themselves.
Above is an image of an autogenerated form that is meant to collect information about past procedures and diagnosis.
The same form when it is built using web components.
For larger forms with more than 10 fields, auto-generated forms can become too long and repetitive. In these cases, we support custom forms using web components based on HTML standards. This allows for rich, interactive elements like whiteboards, complex validation, and AI workflows.
Web components allow us to have elements such as drawing on skeleton diagrams.
Some forms need to use specific codes for compliance, analytics, or to encode complex data. We use systems like SNOMED CT, ICD-10, and LOINC. Medblocks has a built-in terminology server to help search through various value sets and integrate them smoothly with openEHR templates.
Valuesets being used to collect diagnosis
After a form is filled out, healthcare providers need to view the information collected during a patient's visit or across multiple visits to make informed decisions. We found that the way information is viewed, often differs significantly from how it is collected. Working with physicians, we developed two main types of summaries:
- Encounter Summary: Shows a patient's health information from a single visit.
- Form Summary: Displays long-term data from a specific form over time.
The summary component uses web component standards, just like our forms. It can run openEHR’s Archetype Query Language (AQL) to gather and display all relevant patient data.
Summary widget summarizing a patient's visit post surgery
Same widget as above showing the data underneath when expanded
A drug prescription form with its corresponding form widget summarizing data from all previous form entries
Embedded applications tackle the challenge of expanding an existing EHR system after it has been deployed. Let's consider a scenario where a research team wants to create an application for a small clinical trial. They need just one form and prefer not to store data in the main platform due to specific operational requirements.
In such cases, applications can be built using either the SMART on FHIR or SMART on openEHR platform standards. These standards allow new applications to be launched within the existing system, understanding the patient context and accessing relevant data from the main platform.
We've implemented this approach at a few sites so far to understand how a complete solution works from start to finish. This includes everything from creating forms to teaching people how to use them and all the steps in between. We want to be more open about what we're building and why we make certain decisions along the way. Even though we've had our system running live for a year now, we're still learning if this approach is right for everyone.
If you have any ideas or feel that this extensible approach might be right for you, feel free to reach out to us at: https://medblocks.com/contact.
As always, we look forward to hearing from you!