We design, profile, publish and maintain FHIR implementation guides — from a single organization's scope to national and regional specifications — in R4 and R5, with conformance rules implementers can validate on their own.
FHIR keeps its resources deliberately flexible so they can serve any country and any clinical domain. That same flexibility is why two «FHIR-compatible» systems can still fail to understand each other. An implementation guide closes the gap: it fixes which resources are used, which elements are mandatory, which terminologies apply, which identifiers are recognized, how information is searched and what a system must satisfy to be considered conformant. At Meddyg we build those guides as executable specifications — profiles, ValueSets, examples, rules and tests published as an installable package — not as documents each implementer reads their own way.
The method is the same. What changes is who governs the specification, how many implementers depend on it and how much a mistake costs.
One organization and the systems operating under its authority.
A whole jurisdiction, or several countries reporting under one shared format.
Both scopes share the same technical pipeline and the same conformance artifacts. What differs is governance, versioning policy and the cost of a breaking change.
Seven stages. Each one produces artifacts that get validated and published — not interim deliverables that stay inside a document.
An implementation guide does not start from a blank document. The WHO defines a five-level ladder for bringing a narrative clinical guideline down to software that executes it and can be tested, and a FHIR guide is exactly level L3. Where the domain already has a published DAK — level L2 — its personas, processes, data elements, indicators and requirements are the input profiling starts from, rather than being rebuilt from scratch in every country.
We use the SMART Guidelines as a reference model and a way of working. It is not a project delivered to the WHO: it is the model we organize the work around when there is a clinical guideline behind the guide.
We define which exchanges the guide covers and which are explicitly out of scope. Actors, scenarios, triggers and the full path of each transaction, end to end.
The use cases come from concrete pain: a result that never arrives, a duplicated encounter, a report someone assembles by hand every month.
The use cases come from a mandate: a notifiable-disease regulation, a public health program or a regional reporting commitment.
Before profiling, we agree on what each data point means. We model the domain's clinical information and decide which FHIR resource represents it — and when the right answer is an extension rather than forcing a resource.
The mapping runs against the models already living in the organization's systems, historical quirks included.
The mapping runs against the regulation and the national core, so the new guide depends on it instead of redefining it on its own.
We constrain resources to what the use case requires: cardinalities, must-support, slicing, allowed types and invariants expressed in FHIRPath. Extensions are defined only when the data does not fit the base resource.
Tight profiling: you can constrain firmly because the universe of systems is known and bounded.
Careful profiling: every mandatory element leaves some implementer out, so what is required today is kept separate from what is announced for the next release.
Sharing structures is not sharing meaning. We define the vocabularies bound to each element, the binding strength and the equivalences with the local codes already in use.
Each system's own code tables are reconciled against the standard vocabulary, without forcing an immediate replacement.
It is settled who publishes and maintains the national ValueSets, and on what terms licensed vocabularies such as SNOMED CT® are distributed.
The guide states what a conformant system must be able to do: which operations it exposes, which searches it supports, which profiles it accepts and what it must reject. Without this, «conformant» is verifiable by no one.
Conformance becomes a contractual clause and the acceptance criterion for a vendor delivery.
Conformance becomes an eligibility requirement: without it, a system does not connect to the ecosystem.
We author the guide in FSH and build it with SUSHI and the IG Publisher, inside a continuous integration pipeline that runs the QA report on every change. The output is a browsable site and an installable package.
It is published on an organizational domain and handed to vendors as part of their integration documentation.
It is published with a declared jurisdiction, version history and presence in public registries, with the canonical URL as each artifact's permanent identity.
A guide nobody manages to implement is worthless. We validate examples with the official validator, prepare material and tests for implementers, walk the first integrations through and leave the change cycle open.
We stay with the first real integration until it validates end to end in production, not just in the test environment.
Connectivity testing and connectathons get organized, and implementer support is sustained throughout the adoption period.
The right question is not which version is better, but who your system needs to talk to and for how long. We work in both and, when the ecosystem demands it, sustain the two at once.
The version with the largest installed base.
More mature resources for domains where R4 fell short.
Almost no ecosystem switches versions overnight. R4 and R5 normally coexist for years, and that coexistence is designed rather than improvised.
Everything an implementer needs to build, validate and demonstrate conformance without depending on a meeting with us.
The guide, built and versioned, installable with the ecosystem's standard tooling.
StructureDefinitions with documented cardinalities, must-support, slicing and invariants.
Terminologies, binding strength and equivalences between local codes and the standards.
Instances that pass the validator, including edge cases and examples that must fail.
What a conformant system exposes: operations, search parameters and accepted profiles.
A repository with FSH, configuration and CI, so the guide stays alive without us.
Compatibility rules, numbering and the transition between releases of the guide.
Onboarding documentation, a test plan and support through the first integrations.
Published specifications in real use, not lab exercises. Each one defines the conformance contract for an exchange that happens today.
The base FHIR resources and core profiles for national clinical exchange: the guide every other one depends on.
Meddyg's roleCollaboration on design, profiling and publication.
Profiles and ValueSets for the clinical terminologies shared across the country's health ecosystem.
Meddyg's roleCollaboration on design, profiling and publication.
Structure and conformance rules for reporting laboratory results via FHIR.
Meddyg's roleCollaboration on design, profiling and publication.
Profiles for exchanging medical imaging study reports.
Meddyg's roleCollaboration on design, profiling and publication.
A guide for reporting notifiable diseases, vaccines and laboratory results. Meddyg implemented and deployed to production the first FHIR server to receive these reports from EDUS/CCSS, later extended to other health providers.
Meddyg's roleParticipation in the design, profiling and publication of the guide, plus implementation of the receiving infrastructure.
The first HL7® FHIR® implementation guide for regional AEFI (Adverse Events Following Immunization) reporting, together with the design of the infrastructure that would receive those reports.
Meddyg's rolePart of the Meddyg team acted as a consultant on the design of the guide and on the design and implementation of the receiving infrastructure.
Integration of the JAdES format into GAUDI, the BCCR's digital signature and sealing platform. Not a guide in itself: it is exactly the kind of conformance rule — how a resource is signed and how that signature is verified — a guide must declare for non-repudiation to be enforceable.
Meddyg's roleTechnical assistance so the BCCR's teams could enable signing of FHIR resources.
The guides above are national and regional in scope. The same method — information model, profiles, terminology, conformance and publication — is what we apply to institutional guides, with shorter cycles and internal governance.
The method is the same; what changes is what is at stake when the specification is left ambiguous.
Ministries and regulators that must set how the country reports and exchanges information. The guide turns written regulation into something verifiable.
Nationwide systems with many facilities and vendors. The guide defines what is required of each, without negotiating it case by case.
Initiatives where several countries must report under one shared format without giving up what is specific to each.
Ecosystems onboarding new participants that need a repeatable technical contract rather than a separate agreement per connection.
Organizations running several clinical systems that want to stop negotiating the format on every new integration.
Results and reports that must reach multiple external receivers with the same structure and the same codes.
Products that must demonstrate conformance with a national guide, or build their own to bring order to client integrations.
If any of these describe your organization, an implementation guide is how the agreement becomes a rule that can be validated.
An implementation guide turns regulations and agreements into rules a system can validate before it reaches production.