In today’s healthcare landscape, Electronic Health Record (EHR) systems are the backbone of clinical operations. However, the growing demands of modern healthcare often outpace the development cycles of these core systems. This is where EHR sidecars come into play - but what exactly are they, and why are they so crucial?
When most people hear about EHR sidecars, they often think of them as a recent innovation, emerging alongside modern standards like FHIR and SMART apps. However, the story of sidecars is much older and more fundamental to healthcare IT evolution than many realize.
At its simplest, a sidecar is a separate system that runs alongside the main EHR. It doesn’t replace the EHR, but it adds capabilities that the EHR can’t provide on its own, whether that’s analytics, decision support, or a new application for clinicians.
Think of a sidecar as a companion app that sits next to the EHR. The EHR continues to handle core patient records, while the sidecar provides additional functions. From a clinician’s perspective, it often means switching between the EHR and the companion app, each handling a different part of their work.
In the illustration, the clinician starts in the EHR to view the patient’s record. When they need something the EHR doesn’t provide, they switch to the sidecar. The EHR remains the main source of truth, while the sidecar adds extra support. Whether that’s another view of the data or a tool to help with decisions. Moving between the two gives the clinician a more complete picture.
The need for sidecars stems from a fundamental challenge in healthcare IT: EHRs, while powerful and essential, operate on slow development cycles. New features and improvements often take months or years to implement, as they must go through vendor roadmaps, extensive testing, and regulatory compliance. For hospitals and clinics dealing with rapidly evolving healthcare needs, this pace can be frustratingly slow.
Meanwhile, clinicians face immediate challenges that demand quick solutions:
- Real-time decision support at the point of care
- Automated reminders for care gap closure
- Enhanced patient engagement tools
- Custom workflows for specific specialties or departments
Sidecars came out of that need. They were built as separate systems that could add what the EHR was missing without breaking the core record. Because they solved real problems in a practical way, sidecars have stood the test of time and remain widely used today.
This disconnect between urgent clinical needs and EHR development timelines created the perfect environment for sidecar solutions to flourish. In this article, we’ll explore the evolution of EHR sidecars, and understand how they have stood the test of time and still remain relevant today.
Before HL7 v2 (Pre-1990s): The Best-of-Breed Era
We’ll start with the time before HL7 v2. In those days, hospitals often used what was called a Best-of-Breed approach. Each department picked the system that worked best for them.The lab had its own Laboratory Information System (LIS), radiology had a Radiology Information System (RIS), pharmacy had its own software, and billing used something different again.
The problem was that these systems didn’t really talk to each other. Data lived inside each application, and moving it across departments was messy. Sometimes it meant printing reports and sending them by hand. Other times it meant custom, one-off interfaces that were expensive to build and hard to maintain.
This setup gave departments freedom to use tools they liked, but it created silos. Without a common language, hospitals struggled to keep information in sync. That gap set the stage for HL7 v2, which came in to provide a shared way for these systems to exchange messages.
At the time, hospitals were already beginning to computerize different parts of their operations. As the HL7 v2.3.1 Introduction notes
It is not uncommon today for the average hospital to have installed computer systems for admission, discharge, and transfer; clinical laboratories; radiology; billing and accounts receivable… Often these applications have been developed by different vendors or in-house groups, with each product having highly specific information formats.
This meant that while technology was spreading, the systems remained siloed, each speaking its own language, and integration was still a major challenge.
In this image, you can see how a practitioner had to work across multiple terminals, each connected to a different system, a clear example of the fragmented, Best-of-Breed environment that existed before HL7 brought a common standard.
With HL7 v2 (1990s–2000s): Best-of-Breed with a Common Language
Now we come to the Best-of-Breed era with HL7 v2, which shaped hospitals through the 1990s and 2000s. Hospitals still used different systems for labs, radiology, pharmacy, and billing but this time there was a common way to connect them. HL7 v2 used short, pipe-delimited messages to share things like admissions (ADT), orders (ORM), and results (ORU) between systems.
This didn’t replace the Best-of-Breed approach, but it made it much easier to manage. Departments could stick with the tools they knew, while HL7 v2 kept patient data flowing across the hospital.
A patient admission fires an ADT^A01 message from the registration system. A clinician placing a lab order then sends an ORM^O01 message to the LIS. When the lab is done, the LIS returns an ORU^R01 message with the results back to the EHR.
This loop works without a single vendor controlling everything and HL7 v2 messages moving data between systems. As explained in The Complete Guide to HL7, this kind of messaging made Best-of-Breed setups possible. The downside was that these messages didn’t share context. They only passed snapshots of information, which often left workflows fragmented.
The image shows how different systems like admissions, billing, pharmacy, labs, and imaging all connect through HL7 v2 at the center. Instead of custom links between each system, the interface engine acts as a hub, passing messages so data can move across the hospital.
Despite this setup, clinicians still faced a big challenge. They had to manually switch between different screens, and the systems couldn’t share the same context. Each terminal showed its own slice of information, making it hard to coordinate care smoothly.
CCOW context sharing (late 1990s/2000s)
CCOW (Clinical Context Object Workgroup) is an HL7 standard that was created to keep different clinical apps in sync. The idea was straightforward - if one app set the patient, the others would follow. This saved clinicians from having to search or select the same patient over and over again in each system. It made multiple apps feel more connected, even though they came from different vendors.
Because it was vendor-independent, CCOW became a common way to manage Best-of-Breed desktops. Hospitals used it to tie together labs, radiology, pharmacy, and other apps into a single desktop experience. It was an important step toward easing the burden on clinicians.
The above illustration shows how if an EHR switches to Patient A, the CCOW Context manager enables the Radiology viewer, Lab viewer and the Sidecar to switch context to the same Patient A.
There were some drawbacks to CCOW. It depended on a central Context Manager to keep everything in sync, and the “context” it shared wasn’t actual clinical data but only subjects like patient or user. As the LEADTOOLS CCOW documentation
explains, context changes are proposed and propagated by the Context Manager, while separate identifiers or messaging standards such as HL7 v2 are still required for the underlying data exchange.
Adoption was also difficult, since every app had to be CCOW-enabled for it to work smoothly.
HITECH / Meaningful Use (2009–2011)
The HITECH Act of 2009 created the Medicare and Medicaid EHR Incentive Program, often called “Meaningful Use.” These programs offered payments to clinicians and hospitals that adopted Certified EHR Technology (CEHRT) and used it in specific ways, like sending prescriptions electronically, exchanging information, and reporting on quality measures. Stage 1 began in 2011 and marked the first real push for EHR adoption at scale in the U.S.
In the study “Investment subsidies and the adoption of electronic medical records in hospitals” (PubMed), it is reported that adoption rates among independent hospitals rose from 48% in 2008 to 77% by 2011.
The effect of the HITECH Act was immediate. After 2009, Health IT job postings rose far faster than healthcare jobs or overall job growth. This surge reflects how quickly hospitals adopted EHR systems at scale, creating a massive demand for technical expertise to implement, maintain, and expand them.
In the study Factors Affecting Physician Professional Satisfaction and Their Implications for Patient Care, Health Systems, and Health Policy, it is noted that
For many physicians, the current state of EHR technology significantly worsened professional satisfaction in multiple ways. Poor EHR usability, time-consuming data entry, interference with face-to-face patient care, inefficient and less fulfilling work content, inability to exchange health information between EHR products, and degradation of clinical documentation were prominent sources of professional dissatisfaction.
This shows that while adoption accelerated, it also brought unintended drawbacks for clinicians.
These challenges created a surge in sidecar development. Healthcare organizations, faced with clinician dissatisfaction and workflow inefficiencies, turned to sidecars as a quick and a reliable solution. The EHR adoption wave, while challenging, ultimately expanded the role and importance of sidecars in healthcare IT.
SMART → SMART on FHIR (2010 - 2013+)
The idea of “substitutable apps” began with SMART (Substitutable Medical Apps & Reusable Technologies), a project from Harvard and Boston Children’s. Its goal was to let third-party apps run on different EHRs without custom integrations. Between 2010 and 2012, the team defined the app model and showed working demos, building on Mandl and Kohane’s 2009 call for an apps-based health IT ecosystem.
When FHIR emerged, SMART was updated in 2013 to use FHIR’s web-native resources and OAuth2. This became SMART on FHIR, now the standard way to launch and authorize add-on apps inside or alongside EHRs, as described in the HL7 SMART App Launch IG. Today it’s widely adopted, for example, an EHR can launch a SMART app with patient context, the app can read FHIR data, and, with the right permissions, write back safely.
In the given illustration, we can see how SMART on FHIR is launched in two ways from an EHR. The first one on the left shows how it is launched within an EHR and the one on the right shows how SMART on FHIR can be launched on a separate tab.
In the early years, both SMART and later SMART on FHIR faced slow uptake. Many EHR vendors were reluctant to open their APIs, and where APIs did exist, implementations often varied. App developers ran into inconsistent support across systems, which meant the original “write once, run anywhere” took longer to achieve. As Mandl and Kohane noted in their article Escaping the EHR trap—the future of health IT, the structure of the EHR market often worked against the vision of substitutable apps, slowing real-world adoption .
ONC’s Cures Act Final Rule (2016)
The ONC’s 21st Century Cures Act, required EHR vendors to provide standard APIs based on FHIR and SMART on FHIR. It also introduced rules against information blocking, making sure that health data could be shared more easily and without unnecessary restrictions.
For sidecar applications, this created a much better environment. Instead of relying on closed or proprietary connections, developers could use a common set of APIs available across different EHR systems. This consistency made it more practical to build apps that work in many places, helping sidecars move from isolated projects to wider use.
According to a 2018 Pew Charitable Trusts analysis, the 21st Century Cures Act pushed vendors toward standardized APIs, giving patients and third-party developers more reliable access to health data. By requiring open, FHIR-based connections, the law created new opportunities for apps to improve care coordination, patient engagement, and innovation around the EHR ecosystem.
CDS Hooks 1.0 (2018)
In 2018, CDS Hooks 1.0 gave EHRs a standard way to talk to external apps during care. For example, when a doctor opens a chart or selects an order, the EHR sends that information to a CDS service, which replies with “cards” showing tips, warnings, or links to launch a SMART app.
This made sidecar apps more useful. They could now appear inside the workflow at the right time, offering real-time decision support instead of sitting as separate add-ons.
This example shows what happens when a doctor orders a medication. The EHR triggers a CDS Hook, which calls an external CDS service. That service checks the FHIR server for allergies and returns a “card” to the EHR. The card warns that the patient is allergic to penicillin and suggests an alternative. This is how CDS Hooks brings real-time decision support directly into the workflow.
FHIRCast (2018+)
FHIRCast is HL7’s modern, web-based standard for keeping multiple apps in sync on the same patient or study in real time.
It uses the W3C WebSub publish/subscribe pattern, with a central Hub that sends updates to apps through webhooks or WebSockets. Common events like Patient-open or ImagingStudy-open let every connected app know which patient or study is currently in view.
In this example, a user launches a SMART app that subscribes to a shared FHIRcast session. When the driving app opens Patient A, an event notification is published, and all subscribed apps update to the same patient view. Each app can then access the FHIR server for details as needed. When the session ends, apps simply unsubscribe. This allows different applications to stay in sync in real time without manual switching by the clinician.
Conclusion
We’ve seen how EHR sidecars started, how they changed over time, and how new standards made them stronger. From Best-of-Breed systems and HL7 v2 to SMART on FHIR and FHIRCast, the goal has always been the same which is to give clinicians what the core EHR could not.
Sidecars were created out of necessity, and that is why they have stayed relevant. Even as technology moved forward, the idea of extending the EHR in practical ways has remained. And therefore Sidecars continue to be a key part of healthcare IT today.
Looking ahead, modern standards like FHIR and open APIs are making sidecars more powerful and easier to integrate than ever before. As healthcare continues to evolve with AI, remote care, and personalized medicine, sidecars will keep playing their crucial role and bridge the gap between what EHRs provide and what healthcare needs.