Electronic health records (EHRs) are now nearly universal in hospitals, but true interoperability with other health IT systems remains inconsistent. A US study of 1.7 million patient safety event reports found that breakdowns in interoperability were responsible for thousands of safety hazards, most occurring within the same hospital system, not just across organizations. While this data is a decade old, we do know that the cost of this fragmentation is enormous.
Research by the West Health Institute estimates that interoperable systems could prevent $2 billion in adverse events, eliminate $3 billion in redundant testing, and add $12 billion in clinician productivity every year.
At the same time, the size of the Software as a Medical Device (SaMD) is projected to reach $6.87 billion USD by 2032. These devices have the potential to transform care delivery, but adoption still hits a wall: integration into hospital workflows. Interoperability barriers remain one of the biggest hurdles to realizing their value.
For SaMD manufacturers, the business case is clear: devices that deliver data “where and when it’s needed” — directly inside the EHR — gain physician preference. Doctors are far more likely to recommend devices that seamlessly fit their workflow. The result is better patient outcomes and stronger device sales, making interoperability a strategic differentiator.
What is FHIR standard in healthcare?
FHIR (Fast Healthcare Interoperability Resources) is an interoperability standard that enables medical devices, health IT systems and applications to "talk to each other.” It’s developed by HL7 (Health Level Seven International) specifically to meet the industry's growing demand for standardized, real-time information sharing using modern web technologies.
Where FHIR stands apart is that it enables real-time, standardized data exchange directly within the hospital EHR by removing the integration bottlenecks that have long plagued HL7 v2 and legacy systems design is centered around modern web API technologies, specifically RESTful APIs that use standard HTTP methods (GET, POST, PUT, DELETE) to create, access, update or delete healthcare data resources.
FHIR resources, such as patients, observations, medications and procedures, are all accessible through well-defined API endpoints, allowing systems and devices to exchange information securely and in real-time. This ushers in a new era where interoperability is built on web APIs, and FHIR interoperability is viewed as essential for any connected health product.
What are differences between FHIR and HL7 v2?
HL7 Version 2 (v2) is a text-based messages in a pipe-delimited format (e.g. fields separated by “|”) that allow different hospital systems (EHRs, lab systems, billing, etc.) to communicate.
It’s the most widely implemented standard for the past 30+ years. This was revolutionary in the 1980s and 90s: instead of custom-building every interface, hospitals could use HL7 v2 messages to connect systems for admissions, orders, results, billing and more. The standard’s flexibility and wide adoption are its strengths but also its Achilles’ heel.
The standard intentionally allows customization, which required specialized interface engineers and costly middleware and led to significant implementation inconsistencies between organizations. On top of that, HL7 v2 was designed for an older era of point-to-point connections within a hospital, not for a future that is heavily cloud and mobile based.
In a hospital setting, integrating SaMD via FHIR means device data can flow automatically and securely into the electronic health record through standardized APIs. Instead of creating one-off integrations or maintaining custom interfaces, SaMD manufacturers leverage FHIR’s modular resources, such as “Observation” or “Patient”, to transmit clinically relevant data directly into clinician workflows.
This drastically reduces the effort to onboard a new device or data-sharing partner – instead of building a new feed for each, you leverage the same API calls. Most importantly, FHIR is built for extensibility without breaking interoperability. For device manufacturers, the contrast between the legacy integration model and a FHIR-enabled model is night and day.
FHIR's API-driven model enables real-time access, minimizes manual documentation, reduces onboarding time for new devices, and most importantly, empowers doctors and nurses to view up-to-date device readings alongside labs and vitals in the EHR. The result is streamlined workflows for clinicians and improved care coordination for patients.
As shown above, the device backend communicates directly with the hospital’s EHR via a FHIR API over HTTPS. In practice, this means the device’s cloud system can write data (e.g. an Observation resource for a blood glucose reading) to the EHR database or read relevant clinical context from the EHR, all through standard RESTful API calls. There is no need for dedicated VPN tunnels or custom parsing engines – the data is exchanged over secure web protocols.
With FHIR, once the hospital enables its API and the device maker implements the standard, that single integration can work across many hospitals and EHRs with minimal adjustments. The result is a much faster onboarding of new sites and a continuous data flow from the device into the clinician’s existing workflow.
In a FHIR-enabled model, the device data appears inside the physician’s normal EHR environment – for example, remote sensor readings might show up in the EHR charts alongside lab results or vital signs, rather than living in a separate silo. This has profound implications. Doctors and nurses no longer need to “toggle between systems or manually enter data,” which saves them time and reduces errors.
Overcoming implementation challenges
I always say that interoperability is 80% political and only 20% technical. In other words, the biggest hurdles are often aligning stakeholders, workflows and incentives amongst hospital staff. For medical device manufactures, here are some common implementation challenges and how you can address them:
- HL7 legacy: need for hybrid environments: Hospitals won’t rip out HL7 overnight. Most will run hybrid setups – HL7 v2 still powering legacy feeds, while FHIR APIs emerge for modern use cases. Designing your device around FHIR now positions you for the future-proof path while still being able to bridge HL7 during the transition. FHIR coverage is expanding with each year and regulation (and many hospitals use middleware to fill gaps in the interim). By designing a flexible integration layer and delivering value now while positioning for a full FHIR future
- Standards fragmentation: Even with FHIR, there are optional elements and regional “profiles”. The industry is addressing this with implementation guides like US Core profiles, which all certified EHRs in the US should support. As a device maker, staying informed on these profiles and conforming to them, such as using the standardized codes/fields for vital signs, can maximize cross-system compatibility. It’s also wise to build in configurability: for instance, allow mapping of data fields in case one hospital’s API expects a slightly different coding for a device observation
- Trust gap and stakeholder incentives: No matter how sound an interoperability standard is, you still need hospital cooperation to implement it. Hospitals and EHR vendors often have competing priorities. Be mindful of issues like information blocking where EHR vendors charged high fees or resisted third-party integrations to protect their turf. Show hospitals that integrating your device reduces staff burden, improves care and lowers costs with case studies. With regulatory requirements from the government, hospitals across developed countries are under pressure to hit quality and interoperability targets, so frame your integration not as a technical task but as a strategic initiative that advances their goals
What next for FHIR standard?
Despite these challenges, the trajectory is clearly toward more connectivity, not less. Each year, more hospitals report using APIs for data exchange and more devices embrace open standards. The key is to be proactive: plan for the non-technical aspects just as much as the technical ones. That means building strong partnerships with hospital IT and clinical champions, adhering to standards and privacy/security requirements, and iterating based on user feedback.
If interoperability is treated as “mission-critical infrastructure” and given proper resources and executive attention, it delivers enormous payoff in efficiency and patient care. As a device maker, championing FHIR and integration from day one signals that you are ready for the future of healthcare.
Want to learn how you can bring your interoperability strategy to life?
