In healthcare IT, everyone talks about standards. But why do we have so many? Why don’t they just work together? And what’s standing in the way of real interoperability? Let’s break it down.

The problem: A fragmented digital healthcare landscape

Imagine you’re a patient living in Gothenburg. You were treated at a clinic in Stockholm last month, and now your local doctor needs access to your MRI results and medication history. Sounds like it should be simple in 2025, right?

The reality is that health data is often locked inside different systems that don’t speak the same language. Even within one country, like Sweden, hospitals, clinics, and laboratories use different electronic health record (EHR) systems, each with their own data formats, logic, and structure. This is where standards come in.

Why we need standards in healthcare

Standards define how health data is described, exchanged, and interpreted across systems. They’re meant to ensure that a diagnosis means the same thing in one system as it does in another, that a lab result can be read and reused no matter which lab produced it, and that a doctor in one part of the country can understand a medical report from another. In theory, standards form the foundation of interoperability: the ability for systems to work together, reliably and safely.

The most common health data standards

To understand how interoperability works (or fails) it's helpful to know that different standards serve different purposes. Some define what medical data means, others define how it’s exchanged, and others handle how it's stored. Here's a quick overview of the most widely used standards and what role they play:

Terminology & coding standards define what medical data means, ensuring consistent language across systems so that a condition like “myocardial infarction” is understood the same way in any hospital, country, or EHR. For instance, SNOMED CT is used to encode clinical concepts like diagnoses and procedures, ICD-10 and the newer ICD-11 are international classifications for diseases and billing, and LOINC provides consistent codes for lab tests and clinical measurements.

Exchange & document format standards define how health data is structured and exchanged, whether via real-time APIs or document files. FHIR is the most widely adopted modern standard here, enabling fast and flexible API-based data exchange. CDA is an older format for full clinical documents like discharge letters, while DICOM is used to store and transmit medical images such as CT scans and X-rays, along with associated metadata.

Data models & storage standards define how health data is organized and stored over time, independent of specific applications. openEHR separates clinical content from software by using reusable templates, making it well-suited for long-term, vendor-neutral data storage. FHIR also includes a data model through its resource structure and is sometimes used for lightweight storage needs in simpler systems.

So… why isn’t it all interoperable yet?

If we have all these standards, why do healthcare systems still struggle to exchange data smoothly?

The core issue is that standards aren’t all-in-one solutions. They each focus on a specific part of the puzzle. For example, SNOMED CT defines what a diagnosis means, while FHIR defines how that diagnosis might be shared between systems. openEHR handles how clinical data is stored over time, and LOINC gives a common name to a lab result. But these don’t replace each other, they work side by side. This overlap is where things get tricky. Even to share a simple lab result, a system might use a FHIR Observation resource to transmit the data, a LOINC code to describe the test, SNOMED CT to encode associated findings, and still need to navigate national privacy or consent rules before any data can be exchanged at all.

In theory, this layering works. But in practice, implementation varies. Not every EHR supports every part of a standard. Some vendors interpret standards loosely, or extend them in proprietary ways. Even when two systems use the same standard, they might name or organize things differently. And there are plenty of other reasons.

So while standards are the necessary foundation, they don’t automatically create interoperability, they only make it possible. Bridging those gaps still requires effort, translation, and sometimes quite a bit of custom work.

Where Leyr comes in

Leyr was built around a simple idea: integrating with EHRs shouldn’t mean rebuilding integrations from scratch every time.

In practice, every EHR is a bit different, even when they support the same standards. One might expose parts of FHIR, another might require flat file uploads, and a third could use a custom authentication flow or internal coding system. For developers, navigating this complexity means spending countless hours learning the specifics of each EHR before they can even begin working with real patient data.

Leyr simplifies that process. It offers a unified API that acts as a translation layer between an application and the EHRs one wants to connect with. Behind the scenes, Leyr handles:

• Communication with the specific EHR APIs

• Authentication and token management (OAuth2, client credentials, etc.)

• Normalizing data structures where feasible, so developers experience more consistency between different EHRs, even if full standardization isn't always possible

This doesn’t mean Leyr magically standardizes every field across all systems. Many details still depend on the capabilities of the underlying EHR. However, by providing a consistent interface and abstracting much of the system-specific complexity, Leyr reduces integration effort, minimizes surprises during implementation, and lowers the maintenance burden of supporting multiple EHRs.

In a world where healthcare standards are necessary but not sufficient, Leyr fills the practical gap: making interoperability easier to implement, so developers can focus on building products that help patients and providers, instead of wrestling with system differences.