Before you buy a component you need to know where it lives, who answers for it and what crosses each boundary. We define digital health architectures that can be operated, audited and connected to a national network without being rebuilt.
Almost no institution starts from zero. It has a health record, a laboratory, a PACS, a portal and a backlog of pending projects. The trouble starts when new pieces have to be brought in — a master patient index, a product catalogue, credential and facility validation — and nobody can say precisely where they should live, who maintains them, what they expose outward or how they connect to the national exchange platform. Our job is to close those decisions and write them down, in enough detail to procure, build and audit against.
Four planes, and none of them gets resolved by the next one. When an organization jumps straight to the technology plane, it ends up with correct components that nobody knows how to operate and nobody answers for.
Who decides, who approves, and how does a decision get changed?
What gets decided hereWhat does each piece of data mean, and what is its source of truth?
What gets decided hereWhich components exist, and what contract does each one meet?
What gets decided hereWhere does it run, how is it protected, and how is it sustained?
What gets decided hereThis is not a shopping list. Each component solves a concrete problem and drags in a decision that usually has no owner until some project closes it on its own terms.
Answers whether two records in two different systems are the same person, and keeps the link between their identifiers.
Whether matching is deterministic on the national identifier, probabilistic, or both with a human review queue; and which system owns the master identifier.
Gives every medicine, supply and device a stable identifier, so prescribing, dispensing and inventory are talking about the same product.
Whether to adopt the national catalogue, an international one or your own, and how to map what is already loaded in the systems without losing history.
Confirms that whoever signs a clinical act is licensed to do so, at the moment they do it.
Whether validation is queried live against the authoritative source — the professional board or the national registry — or replicated locally, and what happens when that source does not respond.
Uniquely identifies every site, service and unit, which is what makes it possible to route, report and audit by location.
Which coding is used — the national health licensing scheme or another — and who updates the registry when a site opens, changes services or closes.
Publishes and validates the CodeSystems, ValueSets and ConceptMaps the systems use, instead of leaving every code table embedded in every application.
Whether to run your own terminology server or consume the national one, and how to version a ValueSet without invalidating data already captured.
Keeps what has to be kept — FHIR resources, documents, images — with a retention policy and a tested way to get it back. It is the source of truth, which is why it is never exposed directly.
Which content is the source of truth here and which is a copy of another system, because that determines who may write to it and what is lost if it goes down.
Records who accessed what, when and on what grounds. The exposure point emits the event, but the record is kept here and append-only: whoever reaches the boundary must not be able to rewrite the evidence of their own access.
Whether auditing lives in each system or is centralized, and how long you keep a record that may end up being evidence.
Determines who is asking, on whose behalf, and what they are entitled to reach — for people and for systems alike.
What system identity can settle and what requires the identity of the human user, and where consent is recorded when data leaves the institution.
The profile-conformant copy that answers external queries: only what has already been published, materialized from the source of truth and rebuildable at any time.
What gets materialized, how fresh it has to be, and how it is rebuilt from the source when the profile changes. If this copy becomes the only one, it has stopped being a copy.
The single door through which the institution publishes and consumes information outward: API gateway, FHIR layer, national network node.
What gets exposed, under which profile and to whom; and whether that door stores data or only lets it through.
The question most often postponed is where each component lives. And it is not an infrastructure question: it decides what can be exposed, what has to be replicated, and which controls are mandatory at each point.
The space where your institution is one member among many: providers, state registries and the national exchange platform. You do not administer it, but you do decide how you present yourself to it.
Nothing is published here without an explicit contract: profile, terminology, requester identity and a record of the transaction.
The only zone reachable from outside. This is where the components that talk to the outside world live — and only those. Everything passing through is authenticated, authorized and logged.
Nothing living here is a source of truth. The DMZ translates, routes and publishes rebuildable copies of what has already been authorized, with no direct access to the internal databases.
The health record, the repositories, the master index, terminology and auditing. None of it is exposed directly; it is reached only through the DMZ.
No external system reaches in here, and no internal component reaches out to the internet on its own.
A boundary is not defined by where the firewall sits, but by what is allowed across it and on what proof.
Queries and responses from the internal components serving an external request, already reduced to what that request needs.
Connections initiated from the inside, service accounts with least privilege, different credentials per environment, and the result logged.
Resources that conform to a published profile with its terminology bound, and only toward identified, authorized requesters.
Mutual authentication between systems, authorization per use case rather than per whole system, signing and sealing where the data carries evidentiary weight, and a log of every message.
In Costa Rica the national exchange platform is X-Road. Fitting it into the architecture changes less than people fear and more than they plan for.
The institution installs its own security server. It is the only component that talks to the national network; none of your other systems ever does so directly.
Every organization and every subsystem is registered and issued certificates. The network knows who is asking before the question reaches you.
The platform signs and time-stamps what passes through it. That settles non-repudiation, but it also forces you to decide what you send: whatever crosses is on the record.
There is no national database holding everything. Each institution remains the owner of its information and answers specific queries.
Meddyg runs proofs of concept with Costa Rica's National Digital Government Agency to validate FHIR resource transactions over X-Road, as part of the country's functional interoperability demonstration. In other countries the platform has a different name; the architectural decisions you have to close — where the node goes, what is exposed, who authorizes and what is logged — are the same.
We work on models already proven in other countries and ecosystems. For your institution that means three concrete things: fewer months arguing about what is already settled, an architecture the rest of the ecosystem recognizes, and requirements you can put in a tender and enforce.
Building in-house what the country is about to provide, and paying for it twice.
We tell you what is worth reusing and what to build, and hand you the open-standards and portability requirements to enforce in every procurement. That is what keeps you from finding out three years later that you cannot change vendors.
Half a year spent arguing about what each component is called and who answers for it.
Your architecture ends up named in the same vocabulary the rest of the ecosystem uses. When it is time to integrate, the conversation starts at the right point instead of in the glossary.
Discovering mid-implementation that the component you already bought cannot meet the national profile.
We turn the profile the national guide requires into a verifiable architectural requirement, before you buy. If a product does not meet it, you find out while you can still change product.
Every team interpreting the clinical guideline its own way, leaving you with five versions of the same process.
We bring the guideline down to the system along a proven route: from the document to the processes and data, from there to the FHIR profile, and from there to something testable before production. If your domain already has a published DAK, you skip the slowest stage of the project.
Risk does not appear when you adopt standards; it appears when you expose a system that was designed to live inside a closed network. These are the guardrails we define alongside the architecture, not after it.
An API over the entire health record gets published because it was faster than defining the exchange.
One use case is exposed at a time, with its profile and its scope. What is not in a published contract cannot be asked for.
Any system already inside can query anything, because the network is considered safe.
System and end-user authentication on every call, permissions per use case, and different credentials per environment.
When you have to answer who accessed a record, the information is scattered across logs that have already rotated.
The access log is designed as a component, with defined retention and its own query path, from the first exchange onward.
The entire resource is returned because the consumer will “filter later”, and that copy is now out of your control.
Minimization by design: each exchange defines its minimum set, and the response is trimmed at the exposure point.
An exchanged clinical document cannot prove who issued it or that it was not altered.
Signing and sealing on the exchanges that require it. Meddyg provided technical assistance to the Banco Central de Costa Rica to enable JAdES signing of FHIR resources.
Testing happens against production because the test environment has nothing resembling real data.
Separate environments with synthetic or anonymized data, controlled promotion, and different secrets in each one.
Each phase closes a question and leaves an artefact behind. An architecture with no artefacts cannot be procured, built or audited.
What is there today, who operates it, and what is actually being exchanged?
We inventory systems, live integrations, clinical flows and standing contracts. Not what the diagram says: what is running.
What does the organization need to be able to do that it cannot do today?
We prioritize exchanges by clinical value and feasibility, and write them up as functional and non-functional requirements. Where a WHO DAK exists for the domain, we take it as the starting point.
Which components exist in the desired state, and what contract does each one meet?
We define the component catalogue, their responsibilities and their boundaries, with the profiles and terminologies each one has to conform to.
Where does each component live, and what crosses each boundary?
We place each component in its zone, define the controls on each boundary and the single exposure point toward the national network.
Who answers for each component, and how does a decision get changed?
We assign owners, define the architecture decision record and the route for approving an exception without the exception becoming the norm.
In what order does it get built, and what can go to production first?
We sequence the work into increments that can be released and measured, starting with the one that solves a real exchange rather than the one that is biggest.
Is what was defined actually what is being built?
We review vendor deliverables against the defined contracts and adjust the architecture when reality demands it — with the decision on record.
Documents you can procure, build and audit against — not something presented once and then filed away.
Current state, target architecture, components and their contracts, at the level of detail a tender document demands.
What lives in each zone, what crosses each boundary and under what control, and how the organization connects to the national platform.
Every component with its responsibility, its owner, its contract and the buy, build or reuse decision behind it.
Each decision with its context, the alternatives weighed and the consequence accepted. It is what keeps the same argument from returning every year.
Per-boundary controls, access matrix, audit and signing requirements, written so they can be demanded contractually.
Releasable increments, dependencies, risks and the order worth building in so something reaches production early.
Architecture is not the diagram you hand over: it is what is still working three years later. These are projects where Meddyg defined or built the architecture that stayed in operation.
Proofs of concept with the National Digital Government Agency to validate FHIR resource transactions over the national platform, within Costa Rica's functional interoperability demonstration: secure exchange between different systems, without centralizing the data.
Design, production deployment and operation of the first FHIR server receiving notifiable disease, vaccination and laboratory result notifications from EDUS/CCSS, and later from other health facilities.
Technical assistance to the Banco Central de Costa Rica to integrate the JAdES format within GAUDI, its digital signing and sealing platform, enabling the signing of FHIR resources.
Implementation of PACS architectures and diagnostic workstations for medical image exchange under the DICOM standard, in public hospitals of the Dominican Republic's National Health Service.
The models we name on this page are the method we work with, not clients. When a case belongs to a client, we say so by name — as with the four above.
The service serves both those defining an architecture for the first time and those who already have one written and need to connect it to the ecosystem.
Social security funds, ministries and hospitals that have to take on national components and connect to the country's exchange platform.
Hospitals, clinics and laboratories that need to take part in the ecosystem without rebuilding their systems or opening up their network.
Teams that already hold the mandate to define the architecture and need decisions closed and defensible.
Leaders who have to enable exchange without widening the institution's exposure surface.
Manufacturers that have to conform to a national profile and show how their product fits into the client's architecture.
Initiatives that need a shared reference architecture so each institution does not solve it its own way.
If you recognize three or more, the problem is not technological: these are open decisions that each project is closing on its own, differently every time.
We define the architecture your organization needs to operate today and connect tomorrow, with the decisions written down, the components placed and the security guardrails set from the design stage.