Costa Rica now has a Health Interoperability Regulation: what it means and what to do now

A milestone for Costa Rican digital health

Today, October 7, 2026, at the 2026 National Interoperability Meeting, President Laura Fernández Delgado, Minister of Health Dr. Alexander Sánchez Cabo and Minister of Science, Innovation, Technology and Telecommunications Paula Bogantes Zamora signed the Regulation on Interoperability and Secure Exchange of Health Data and Recognition of the Right of Persons to the Availability of their Health Data (Reglamento de Interoperabilidad e Intercambio Seguro de Datos de Salud), also known as the Health Interoperability Decree (Decreto de Interoperabilidad en Salud).

For the first time, Costa Rica has common rules so that hospitals, clinics, laboratories and imaging centers, whether public, private or mixed, can exchange health data with standards, security and traceability. The new regulation repeals decree 39652-S-MICIT of 2016 on the use of standards and takes effect upon publication in La Gaceta, the official gazette.

In this article we explain what it is about, what it aims for, whom it covers, what should be addressed right away and how Meddyg can support you.

What it is about

The regulation creates the National Health Interoperability Model: the reference framework for exchanging health data securely and in a standardized way between providers, and between them and the Ministry of Health (art. 10). It has five key features:

• Federated architecture. Clinical data stays in the custody of whoever generates it. The regulation expressly prohibits creating a centralized repository of health records (arts. 1 and 10).
• Narrowly scoped shared components. Common services for identification, authentication, authorization, terminologies, location or indexing, traceability and auditing are allowed, as long as they do not store clinical content persistently.
• Open standards. The Model is based on open or widely adopted standards, without unjustified licensing barriers, and respects technological neutrality.
• Stewardship separate from operation. The Ministry of Health leads, regulates and makes things official, but it does not develop, host or fund providers' infrastructure (art. 14). Each actor provides and maintains its own technology.
• Versioned technical instruments. Guides, profiles and guidelines are published with a version, an enforcement date, a transition period and a change history, after technical consultation (arts. 13, 21 and 22).

One point that often goes unnoticed: interoperating is not, in itself, an authorization to process data (art. 23). Each exchange needs its own legal basis, usually informed consent or a legal provision.

What it aims for

The central goal is for information to follow the person: today's lab result or mammogram should be available, securely, to whoever treats them tomorrow. Article 2 sets out eight objectives, which we can group into three:

1. Better care. Continuity, quality, timeliness and comprehensiveness of care, with fewer duplicate tests, paperwork and records.
2. People's rights. People own their health data (art. 8). The regulation recognizes the right to availability: obtaining their data in a structured, interoperable and machine-processable format, and requesting its secure transmission to another provider (art. 5(f)).
3. A governed ecosystem. Clear roles and responsibilities, efficient use of public and private resources, and exchange for public health purposes where there is a legal basis.

In practice, the right to availability turns portability into a technical capability providers must be able to offer, not a photocopy errand.

Scope: who it applies to and who does what

The regulation applies to every public, private or mixed health service provider that enables, implements or takes part in interoperability processes (art. 3). Joining is voluntary, but whoever decides to interoperate is bound to comply with all of it. It also does not suspend prior legal obligations, such as mandatory reporting.

Where applicable, it also covers technology vendors and data processors operating on behalf of providers: developers of health record systems, LIS, RIS/PACS, cloud services and integrators.

Key deadlines. The Ministry has five months from entry into force to publish the initial technical specification of the Model and its Progressive Implementation Plan (Transitional Provision I). Those already interoperating must adjust within the period that Plan sets (Transitional Provision II). No conformance obligation will be enforceable before final specifications, testing tools and a reasonable adaptation period exist (art. 15(f)).

What to address right away

The Implementation Plan has not been published yet, but much of the work does not depend on it. Whoever starts now will be ready when enforcement dates are set.

Governance and legal compliance

• Formally appoint the person or body that coordinates data protection in interoperability (art. 24).
• Register or update with PRODHAB the database to be interoperated and its operating protocols (art. 19(l)).
• Redesign informed consent: express, specific to each purpose, verifiable in digital form and revocable in part or in full (arts. 6, 25 and 26).
• Define emergency access ("break the glass"), strictly necessary and always logged (art. 27).
• Review contracts with technology vendors and include the minimum clauses of art. 9: purpose, confidentiality, security, incidents, subcontracting, data location, auditing and return in a usable format.

Technology and data

• Inventory systems (health records, LIS, RIS/PACS), data and flows, and measure the gap against the published HL7 FHIR National Guides.
• Clean up the local test catalog and map it to standard terminologies (LOINC, SNOMED CT), keeping the provenance and version of each transformation (art. 19(d)).
• Implement authentication, role-based authorization and audit logs that make it possible to reconstruct who accessed what, when and why (arts. 5(r) and 19).
• Prepare how to deliver each person's data in a structured, interoperable format (right to availability).

Security and continuity

• Document the incident procedure and its notification to CSIRT-CR, the Ministry of Health, the operator of the affected component, PRODHAB and the people affected (art. 28).
• Have a contingency plan to keep providing care and reporting if interoperability goes down (art. 30).

For technology vendors, the task runs in parallel: add the national FHIR guides, consent management and traceability to their product roadmap, and prepare the compliance evidence their customers are going to ask for.

First use cases: laboratory and mammography over X-Road

The Ministry of Health prioritized two use cases to get started: Laboratory Results and Medical Imaging Reports, the latter starting with mammograms. For its part, MICITT, in its technology coordination role (art. 16), decided that exchange between institutions will run over X-Road, the national secure data exchange layer.

Each use case has three roles, and a single provider can play several of them:

• Producer: generates the data. For example, the laboratory that validates a complete blood count or the imaging center that issues a mammography report.
• Custodian: keeps the data in its systems, is accountable for its security and decides, on a legal basis, whom to release it to. It is usually the same provider that produced it.
• Consumer: queries the data to care for the person. For example, the gynecologist who needs the previous mammogram or the hospital that receives a patient with recent tests.

Clinical data never leaves for a central repository: it travels between X-Road Security Servers only when an authorized consumer requests it, and the shared components only identify, locate and log.

This video shows, in seven steps and without audio, what that model can look like in action: the exchange community each institution connects to only once, the person's single identity, the laboratory that publishes only metadata, the hospital that finds and retrieves the result, the person who sees what is theirs and the security of every access. The on-screen text is in Spanish.

You can also watch it on its own page: A future vision of health interoperability.

How Meddyg can support you

At Meddyg we work every day with HL7 FHIR, clinical terminologies and exchange architectures, and we have taken part in developing the national interoperability guides. That is why we can support each actor according to the role it plays in the first two use cases.

We work in three formats, depending on each organization's maturity:

1. Readiness assessment. In a few weeks: systems inventory, gap against the guides and the regulation, risks and a prioritized roadmap. It is our interoperability assessment.
2. Implementation. We build or integrate whatever is missing to produce, keep custody of or consume interoperable data, on your current platform or with our products.
3. Ongoing support. Tracking new versions of the guides, conformance testing, training and support as the Implementation Plan changes.

Let's start now

The regulation gives the country clear rules; now it is time to turn them into systems that work and data that reaches whoever needs it on time. Those who prepare before the Ministry publishes the Implementation Plan will have an advantage: less urgency, lower cost and a better position with patients, insurers and partners.

If your organization produces laboratory results or mammography reports, keeps custody of health records or needs to query information from other providers, let's talk. Write to us to schedule a readiness assessment.

References

• Regulation on Interoperability and Secure Exchange of Health Data and Recognition of the Right of Persons to the Availability of their Health Data (Health Interoperability Decree), signed on October 7, 2026.
• National Interoperability Guides, Ministry of Health (in Spanish).
• Law No. 8968, Protection of Persons with regard to the Processing of their Personal Data, and its Regulation, decree No. 37554-JP.

Cover photo: Ministry of Health of Costa Rica.