FHIR profiles are not an end in themselves

0 Where this fits in our article series

This article closes a gap between several topics we have already covered: AI as a co-pilot in interoperability projects, the role of document worlds in CDA and their gradual transition (Part 1, Part 2), as well as the importance of terminologies and metadata/ontologies.

Because in practice, profiling is the point where everything comes together: professional requirements, semantics, testability, and operations. This is exactly where it is decided whether FHIR becomes scalable – or whether projects end in mapping backlogs, special-case logic, and version chaos.

1 Why profiles often solve the wrong problem

In many FHIR projects, work begins with the question: “Which constraints do we need on this resource?” Technically that is the obvious move – professionally it is often too early. Ambiguities from workshops, process variants, and incomplete semantic decisions are then poured directly into constraints.

Typical symptoms of such profiles:

• they are hard to explain professionally (“Why is this field mandatory?”),
• they are project-driven (instead of domain-driven),
• they are barely reusable,
• they are only syntactically valid, but semantically inconsistent.

2 Use case → information need → profile

A stable profile does not arise directly from a resource, but from a professional need. The often-skipped intermediate step is the information need: what really must be transmitted so that a process works and decisions can be made safely?

2.1 What a use case must provide

• Who exchanges data (actors, systems, roles)?
• When in the process (trigger, event, timing)?
• For what purpose (care, billing, research, documentation)?
• Which decision depends on the data (e.g. continue medication, verify a diagnosis, interpret lab results)?

2.2 From information need to profile

Only then does profiling become clean: mandatory fields, cardinalities, references, and terminology bindings are the formal implementation of a professionally justified information need – not its replacement.

3 Typical anti-patterns in profiling

3.1 “One profile per project”

Every project defines its own profiles – often with minimal differences. This creates fragmentation, mapping effort, and rising operating costs.

Guardrail: Profiles are organizational or domain assets, not project artifacts.

3.2 Over-constraining as false security

Everything is made mandatory: cardinalities at 1..1, narrow ValueSets, project-specific extensions. In the short term this looks “clean”, in the long term it blocks new use cases and partner connections.

Guardrail: As restrictive as necessary – as open as possible. Every constraint needs a professional justification.

3.3 Profiling without a terminology strategy

FHIR standardizes transport and structure. Meaning arises through terminologies. Without binding code systems, ValueSets, and mapping rules, interoperability becomes an illusion.

In depth: Terminologies in FHIR: Without SNOMED/LOINC, it gets expensive.

Guardrail: A profile without terminology governance is not a contract, but a recommendation.

3.4 Profiles without testability

If profiles exist only as a StructureDefinition but not as reproducible tests, quality remains a claim. At the latest with the second implementer, the gap shows.

Guardrail: What is not testable is not interoperable – no matter how correctly it is modeled.

4 Profiles as a contract: governance instead of tinkering

4.1 Ownership and decision-making capacity

For every profile it must be clear: who is professionally responsible? Who decides on changes? Who prioritizes extensions? Without ownership, profiles become orphaned artifacts.

4.2 Versioning, changes, and deprecation

Changes are normal. What matters is the how: versions with clear semantics, documented breaking changes, deprecation instead of abrupt removal. That is interoperability operations – not “documentation”.

Anyone coming from a CDA world knows the pattern: stable exchange definitions need clear rules and release processes. (cf. CDA → FHIR without a Big Bang (Part 1) and Part 2).

4.3 Profiles in the Implementation Guide (IG)

An IG is not just a technical collection. It is a means of communication for partners, a professional explanation, a reference for examples, and the basis for tests. Profiles without IG context are formally correct, but practically weak.

5 Quality comes from tests, not from discussions

5.1 What must be tested

• Syntactic conformance: validation against profiles.
• Semantics: terminology validation (ValueSets, code systems, versions).
• Completeness: mandatory fields/Must-Support per use case.
• Consistency: references, identifier strategies, reuse.

5.2 Profiles as a measuring instrument

Good profiles enable metrics: validation rate, terminology errors, missing mandatory fields, impact across versions. This makes interoperability controllable – not just claimed.

6 Fewer profiles, better profiles

Many organizations have too many profiles – and only a few of them are stable and reusable. A sustainable approach means:

• central, well-justified profiles (domain/organization instead of project),
• use-case derivation with a clear information need,
• clean terminologies and metadata references (cf. Ontologies & ISO metadata),
• binding tests and an operational release model.

7 Conclusion

FHIR profiles are not an end in themselves and not a purely technical exercise. They are contracts between organizations, systems, and people. Stable profiles do not emerge from “more constraints”, but from clear professional decisions, clean semantics, traceable governance, and measurable quality in operation.

Those who understand profiles this way reduce complexity instead of multiplying it – and create the foundation for real, scalable interoperability.