Healthcare has data standards. None of them are standard.

When you hire an electrician, they can work on any building in the country. The outlet shape is the same. The voltage is the same. The wire colors follow the same convention. A licensed electrician from Florida can walk into a house in Oregon and get to work without spending six months learning that particular building's custom implementation of electricity.

When you hire a healthcare IT team to build a data connection between a provider and a payer, they spend the first three to six months doing nothing but mapping. Figuring out which fields the payer uses, how they deviate from the standard, what their companion guide says, and which edge cases their system silently rejects. Only then can actual development begin.

That gap has nothing to do with how advanced the technology is. Healthcare's data standards are simply not standard. We have quite a few of them. The issue is that every organization treats them as a starting point, then builds their own version on top. A standard everyone implements differently might as well not exist.

The standards we already have

Let me be specific about what exists, because the common assumption that healthcare has no standards is wrong. The more accurate issue is what those standards actually deliver in practice.

The pattern is consistent. The standard defines a format. Everyone agrees to use the format. Then every organization adds their own layer of custom behavior on top of it, which quietly makes the standard meaningless for anyone trying to connect two systems together.

What it actually feels like to build in this environment

Here is a concrete example of what the companion guide issue looks like in practice. Let us say you are building an 837 claim submission flow. X12 defines the standard. You read it. You build to it. Then you try to submit to three different payers.

Multiply this across every transaction type, every payer, every EMR, and every data exchange. Every connection is a custom project. Every integration is a one-off. The 'standard' saves you the trouble of negotiating what format to use. It does not save you the trouble of learning each organization's custom version of that format.

We standardized the voltage but not the plug

The electrical analogy is worth staying with for a moment, because it explains why what we built is not what we needed.

In the 1880s, different American cities ran on different voltages. Some ran on 110 volts, some on 220, some on direct current, some on alternating current. Thomas Edison and George Westinghouse fought publicly about which system should win. Eventually, standards emerged. The voltage was standardized. The frequency was standardized. Electrical systems became interoperable at the infrastructure level.

But imagine if, after standardizing the voltage, the US had said: 'Each manufacturer may design their own outlet shape. The voltage is the same. Everything else is up to them.' Appliances from one manufacturer would not plug into outlets from another. Every home would need adapters. Electricians would need a specialized certification for each manufacturer's system.

That is the healthcare data situation. We standardized the voltage: the format, the protocol, the transport layer. We left the plug shape up to each organization. And then we are surprised that nothing connects without a custom adapter.

Healthcare has never had that moment. We have never said: the connection point is fixed. Everything behind it is yours to build however you want. But the interface itself is non-negotiable.

Why the standards did not stick

This is not an accident. The organizations with the most to lose from real standardization have historically had the most influence over the organizations that set standards.

Proprietary data formats create switching costs. If your claims data lives in a payer's custom format, and moving it to a new system requires a six-month mapping project, you are less likely to move. The friction is not a bug. For many organizations, the friction is a competitive advantage, even if nobody says so directly.

EMR vendors have operated the same way for decades. Moving from one EMR to another is painful because each vendor stores data in a proprietary structure that does not map cleanly onto anyone else's structure. If clinical data were truly standardized at the field level, switching EMRs would be like switching phone carriers. You keep your number, your contacts, your history. The vendors know this. The proprietary structure is part of the product.

Payers have a similar dynamic. A provider network built on proprietary EDI configurations is a network that is harder to replicate or defect from. Standardization would make it easier for providers to work with multiple payers interchangeably, which reduces one of the structural advantages larger payer networks have over smaller ones.

None of this is conspiratorial. It is just incentives. The organizations that benefit most from true interoperability, patients, providers, and smaller health plans that cannot afford large IT teams, are rarely the ones with the most seats at the standards table.

What a real standard would actually look like

Real standards in other industries share a common characteristic: they are specific enough to make compliance unambiguous, and they are enforced by something other than good intentions.

Shipping containers are a useful example. In the 1950s, every shipping company used different container sizes. Loading a ship required custom equipment for each carrier. Transferring cargo between ships was a logistical nightmare. Then the ISO standardized container dimensions. Not the color, not the locking mechanism, not the material. Just the dimensions. 20 feet by 8 feet by 8.5 feet. That single constraint, rigidly enforced across the entire global industry, created modern global trade.

Healthcare's equivalent would require something similar in specificity. Not 'use FHIR R4' but 'the member demographics resource must return these twelve fields, populated in this format, using these code sets, with no optional exceptions.' Not 'submit claims in X12 837' but 'the rendering provider segment must contain exactly these values in exactly these fields, with no companion guide variations permitted.'

The question of enforcement

Standards without enforcement are guidelines. The history of healthcare interoperability is full of guidelines that everybody agreed to in principle and then implemented differently in practice.

The CMS interoperability rules are a meaningful step forward. Requiring payers to implement FHIR APIs for patient data access created real infrastructure that did not exist before. But 'implement a FHIR API' is still a format requirement, not a content requirement. The data coming out of those APIs still varies enormously.

Real enforcement would look like certification testing with specific test cases for each required data element, and public reporting on which systems pass. It would look like financial penalties for systems that are technically compliant but practically unusable. It would look like the government saying, as the EU said about USB-C: this is the interface, it is not negotiable, you have two years to comply.

The political barriers are real. Healthcare is a significant portion of the US economy, and the organizations with the most to lose from standardization have significant lobbying presence. But the same was true of the electrical industry, the telecommunications industry, and the automotive industry. Standards happened in all of them, eventually, because the cost of not having them became too visible to ignore.

What changes when we get this right

The tangible impact of real standardization is not just faster integration projects, though that alone would save the industry billions annually. The deeper impact is what becomes possible when connection is cheap.

Right now, a small provider group joining a new payer network faces a months-long technical onboarding process before they can submit a single claim electronically. A population health company trying to onboard a new health plan client spends most of their first year on data mapping rather than analytics. A patient moving between health systems has to re-establish their medical history from scratch because their prior system's data does not travel cleanly.

With true standards, a provider joining a new network is a configuration change, not a development project. A new data partnership is a matter of days, not months. A patient's clinical history moves with them the way their phone number moves when they switch carriers.

The technology for all of this already exists. FHIR is a capable protocol. X12 is a functional format. The standards bodies have done significant work. Nothing here is technically hard. What is missing is the collective will to enforce specificity rather than keep accepting variation, and an honest acknowledgment that the variation we have tolerated has been profitable for some and costly for everyone else.

I have spent 15 years building connections between systems that should, by any reasonable logic, already be connected. The technical work is not the hard part. The hard part is learning, for every new payer, every new EMR, and every new data partner, how they chose to implement the standard differently from everyone else.

That work will keep existing until someone draws a line and says: the plug shape stopped being a competitive advantage a long time ago. It is just infrastructure. And infrastructure that cannot interconnect is really just expensive equipment that happens to look the same from the outside.

We built the voltage standard. It is long past time to standardize the plug.

Ajay Chaudhary

Founder & Principal Consultant, Vavion Health

15+ years building data connections across healthcare's fragmented technology landscape. EDI implementation, FHIR API integration, payer and provider data pipelines, and the standards work that sits between where the industry is and where it needs to be.