We put a FHIR layer in front of the systems already running — EHR, laboratory, imaging, legacy systems with no API — so they speak the standard without being replaced, with conformance verified and operations untouched.
The systems that carry clinical operations can rarely be switched off: they hold years of data, processes tied to them, live contracts and users who depend on them working tomorrow at seven. Yet they are increasingly asked to take part in exchanges they were never designed for: expose a result, report to an authority, feed a consolidated view, connect to a network. A FHIR layer resolves that tension by translating between what the system stores and what the ecosystem requires, without touching its database or its operation. Designed well, it buys years of headroom. Designed badly, it becomes the next legacy system: one more box nobody dares to touch.
«Legacy systems» says nothing. What defines the work is the real shape of the source and what you find once you open it.
Direct access to the clinical system's relational schema, almost always read-only and against a replica, so it does not compete with operations.
Undocumented tables, fields reused for two different things, status flags only their author understands, and business rules that live in the application rather than the model.
Admission, order and result messaging already flowing between systems, which can be used as a source instead of building a new extraction.
Site-specific Z segments, optional fields used creatively, and the fact that a message describes an event, not the patient's current state.
CSV, fixed-width or XML the system already generates for reports or for other consumers, processed in batches.
Fixed generation windows, partial or repeated deliveries, legacy character encodings, and no mechanism to tell what changed since the previous file.
Interfaces the vendor already exposes, built for one specific consumer and with a data model of their own.
Granularity that does not match the FHIR resource, undocumented pagination and concurrency limits, and contract changes that arrive without notice.
Imaging studies and reports, where the metadata lives in the equipment and the PACS before it reaches the clinical record.
Patient identifiers different from the EHR's, reports as free text inside the study, and volumes that make materializing unworkable without clear criteria.
The catalogs holding real processes together even though they live in no system: services, practitioners, code equivalences.
No version control, no formal owner, and the truth spread across several copies that do not agree with each other.
It is the first architectural decision and the one that determines cost, latency and who feels an outage. It is almost never a pure choice.
The layer translates each query against the source system, in the moment.
Data is transformed and loaded into a FHIR repository that serves the queries.
Pure extremes are uncommon. Most layers that operate well are deliberate combinations of both.
Six stages. The first decides what can be taken out of the source without risking clinical operations.
Before mapping anything, we work out what the system really stores and what can be extracted without endangering what already works.
We decide which resource represents each data point, which profile applies and where every element comes from — including the ones the source does not have.
Delivery mode, scope per domain, security and the contract with consumers. This is where what is expensive to change later gets settled.
Transformations, exposure and error handling get implemented, with edge cases treated as part of the scope rather than as surprises.
The layer is tested against the profiles it must meet, with valid examples and with examples that must be rejected.
A layer without monitoring fails silently and is discovered when someone complains about data that never arrived.
The difference between a layer that survives a demo and one that holds up an ecosystem is in details that only surface when a third party tries to consume it.
The JSON is assembled by hand until it «looks right» and tested only against your own client.
Every resource is validated against the applicable guide's profile, in continuous integration, with examples that must pass and examples that must fail.
A copied CapabilityStatement is published, declaring operations and searches nobody implemented.
It declares exactly what the layer supports. A consumer should be able to plan their integration by reading it, not by discovering the hard way what works.
Two or three parameters are implemented and the rest are silently ignored, returning everything as if the filter did not exist.
Declared parameters are implemented, or they are not declared. And pagination is tested with the source's real volumes, not with test data.
Internal keys are used as if they were FHIR ids, resources the layer never exposes get referenced, and local codes are sent without saying where they come from.
Every reference resolves or is declared logical, business identifiers travel in identifier with their system, and every code carries its own.
A generic 500 is returned on failure or, worse, a 200 carrying an incomplete resource.
Errors come back as an OperationOutcome, with severity, code and a location that tells the consumer what to fix.
It gets filled with a default value, an invented date or a generic code so the resource will validate.
What is absent is represented as absent. Where the guide requires the element, the mechanisms meant for unknown data are used and the gap is documented, rather than fabricating it.
The layer in operation, plus everything needed to consume it, audit it and evolve it without us.
The service deployed, with its endpoints, its security and its configuration documented.
Element-by-element correspondence between the source and the resources, with decisions recorded.
Declared equivalences between local codes and the standard terminologies.
What the layer actually supports: resources, operations and search parameters.
Valid examples, examples that must fail, and the tests that run on every change.
Latency, error and freshness metrics, with alerts on whatever could not be transformed.
How to authenticate, what to search, what to expect and what limits the layer has.
What gets materialized next, which domains follow, and when to revisit the delivery mode.
FHIR infrastructure built over systems and platforms that already existed and kept running.
Meddyg implemented and deployed to production the first FHIR server to receive reports of notifiable diseases, vaccines and laboratory results from EDUS/CCSS, later extended to other health providers.
Part of the Meddyg team acted as a consultant on the design and implementation of the infrastructure that would receive regional AEFI reports, alongside the guide defining their format.
Proofs of concept with Costa Rica's National Digital Government Agency to validate FHIR resource transactions over the national X-Road platform, as part of the country's functional interoperability demonstration.
Technical assistance so the Central Bank of Costa Rica's teams could enable signing of FHIR resources with the JAdES format inside GAUDI, its digital signature and sealing platform.
The cases above are FHIR infrastructure built over systems and platforms that were already running. The same method — source analysis, mapping, choice of delivery mode and conformance validation — is what we apply to a facade over a legacy EHR or departmental system.
They all share one constraint: the source system cannot be stopped or replaced within the timeframe in which they have to interoperate.
A clinical system that will not be replaced and is now being asked to expose data, report, or connect to a network.
Products that must demonstrate FHIR capability to clients and tenders without rebuilding their database.
Results and reports that must reach multiple external receivers with the same structure and the same codes.
Mission-critical systems that must take part in a national ecosystem without opening their database or stopping operations.
Ecosystems onboarding participants whose systems do not speak the standard and that need a repeatable connection pattern.
Exchange with providers whose systems expose formats of their own and evolve at their own pace.
If any of these describe your organization, a FHIR layer can solve the exchange without putting at risk what already works.
A well-designed layer lets today's systems take part in the ecosystem without touching their operation or mortgaging the modernization path.