Who Maintains the FHIR Profiles After Go-live?

The actual test doesn’t start with the first successful API call, but six months later — when it shows whether profiles, terminologies and mappings are actually maintained.

What ends at go-live

A project has an end: a budget, a plan, a sign-off, a date. At go-live the interface is built, the profiles are written, the mappings are in place. The assignment is complete.

What ends is the assignment. What does not end is the subject matter.

What begins afterwards

Three things age from the day after go-live, maintained or not:

• Profiles. Implementation guides get new versions, base profiles follow, requirements change. A profile that nobody updates soon describes a system that no longer exists in that form.
• Terminologies. ICD-10-GM, OPS, LOINC, ATC and KDL are published in annual releases. Codes disappear, codes are added, meanings shift. A value set without maintenance binds to a state the source left long ago.
• Mappings. They are the most sensitive point, because they only fail indirectly. If a field or a local convention changes in the source system, the mapping keeps mapping — just something other than before.

The no-man’s-land

These three tasks sit between responsibilities. IT owns operations and availability — profile maintenance appears in no operations manual. The clinical departments know what the data mean, not the StructureDefinition in which that meaning is fixed. Architecture decided and moved on.

That is how a no-man’s-land arises: everyone considers maintenance to be someone else’s job. This is not a reproach aimed at people; it is a gap in the organizational structure — and it does not close by itself.

How to tell after six months whether governance is alive

Governance is not a document but a practice. Half a year later it can be read off a few sober questions:

• Is there a named owner per profile — one person, not a team?
• Are the profiles versioned in the same tool as the code?
• Has an annual terminology release been adopted since go-live — and was its effect checked, not just the file replaced?
• Does a change in the source system reach mapping maintenance before it reaches the data?
• Is the interface checked regularly, or only once someone complains?

Whoever answers these questions with yes is running operations. Whoever answers with “we really should” has finished a project and not started an operation.

Why the green check is not enough here

The obvious answer is a validator in the nightly run. It is useful and necessary, and answers exactly one question: does this resource comply with the profile’s rules? If the profile is out of date, it checks against the outdated rule and reports green. If a mapping has been mapping something different since the last release, the result stays well-formed and the check stays silent — described in What FHIR Validation Does NOT Check.

Operations therefore means asking a second question. Not only “is it conformant?”, but “is it still the same?”.