Chile now requires clinical record interoperability: why this changes everything for digital health

In May 2024, Chile published Law 21.668. In one sentence: all healthcare providers — public and private — are now required to make their clinical records interoperable. Sounds bureaucratic. It’s revolutionary.

I’m a medical technologist by training. I spent years working in clinical laboratories. I lived the problem from the inside: patients repeating tests because the new facility had no access to previous results. Doctors making decisions with incomplete information. A system paying multiple times for the same thing — an estimated $300 million USD per year in duplicate tests in Chile alone.

Now I’m on the other side, building Examya, a platform that processes medical orders with AI. And this law changes the rules of the game.

What the law says (no legalese)

Law 21.668 amends Law 20.584 on Patient Rights and Duties. The key points:

Mandatory: Not optional. All providers must share clinical records electronically. Continuity of care: The goal is that a patient can switch providers without losing their history. Regulation deadline: The Ministry of Health has 18 months from publication (November 2025) to define exact technical standards. Gradual rollout: Implementation will be progressive based on provider size.

The regulation is where the meat is. It defines which exchange standard will be used, which terminologies, how patients are identified. Everything points to FHIR.

FHIR: the standard that’s coming

FHIR (Fast Healthcare Interoperability Resources) is the HL7 standard replacing legacy formats (HL7 v2, CDA) worldwide. Instead of monolithic messages, FHIR models healthcare as REST resources: a Patient, a ServiceRequest, a DiagnosticReport. Native JSON, REST APIs, designed for the modern web.

In Chile, CENS (National Center for Health Information Systems) is already working on national FHIR profiles. The HL7 Chile Connectathon 2026 will be the first event where implementers validate their integrations against these profiles. Examya will be there.

Why does this matter for a builder? Because it means health data will speak a common language. And when data speaks a common language, you can build things on top.

The opportunity nobody is seeing

Most laboratories and medical centers in Chile run legacy systems that speak HL7 v2 — a protocol from 1987. The law forces them to interoperate. They can’t do it without help.

That’s the opportunity: middleware that receives HL7 v2 messages from laboratories, translates them to FHIR resources, and exposes a standard API. Every lab that needs to comply with the law will need this kind of solution — and most don’t have the internal capacity to build it.

But the middleware is just layer 1.

AI + interoperability: where Examya comes in

Examya already processes medical orders with AI. A user sends an order via WhatsApp (photo, PDF, free text), and our pipeline:

1. Extracts tests with OCR + NLP
2. Classifies each test against our catalog
3. Suggests laboratories and prices
4. Generates a conversational purchase flow

All of this currently works with proprietary data. With FHIR, the output could be a standard ServiceRequest that any laboratory in the country understands. With SNOMED CT, each test would be coded in a universal terminology.

And here’s the part that excites me most: AIToF.

AIToF: AI transparency in clinical data

AIToF (AI Transparency on FHIR) is an HL7 Implementation Guide that defines how to mark data generated or processed by AI. Each FHIR resource can carry metadata saying: “this field was generated by model examya-ocr-v2.3, with confidence 0.94, on April 16, 2026.”

Why does it matter? Because in healthcare, traceability isn’t a nice-to-have. If your AI misclassifies a test, you need to know exactly which model did it, with what input, and when. AIToF standardizes that.

Examya could be the first system in Chile with AIToF compliance. Not because it’s mandatory today — but because it will be mandatory tomorrow. And arriving first at a standard everyone will need to follow is a competitive advantage you can’t buy.

MCP + FHIR: agents that speak healthcare

There’s one last piece. At Examya we use MCP (Model Context Protocol) so our agents can access external tools. Imagine publishing an MCP Server that exposes Examya’s FHIR API. Any AI agent — from Google, Anthropic, open-source — could query medical orders, check statuses, retrieve results. No custom integration needed.

A2A (Agent-to-Agent Protocol) takes this further: agents from different systems negotiating with each other. A lab’s agent asking a hospital’s agent whether a patient already has previous results for a similar test. All over FHIR, all traceable with AIToF.

Sounds like science fiction. But every piece already exists. They just need to be assembled.

The roadmap

For Examya, the strategy is clear:

Q2-Q3 2026: Adopt FHIR R4 for the API, implement SNOMED CT + LOINC coding, participate in the HL7 Chile Connectathon as an implementer. Join HL7 Chile.

Q4 2026 - Q1 2027: Publish Examya’s MCP Server, implement AIToF for AI transparency, develop the HL7 v2 → FHIR translation middleware, first lab pilots.

2027+: Middleware as a SaaS product, premium analytics with AI over interoperable data, A2A Agent Card for the healthcare ecosystem.

Why I’m writing this

I’m not an interoperability consultant. I’m a builder creating healthcare tools from a town of 20,000 people in Patagonia. But precisely because of that, I think the perspective matters: the technology Chile needs to comply with this law won’t come from a corporate office in Santiago. It will come from small teams that understand both the clinical problem and the modern stack.

Law 21.668 isn’t just regulation. It’s a market signal. And those who read it first will build first.

---

Working on health interoperability in LATAM? I’d love to connect. Reach me on LinkedIn, X or Instagram.