Wer pflegt die FHIR-Profile nach dem Go-live?

Der eigentliche Test beginnt nicht beim ersten erfolgreichen API-Call, sondern sechs Monate später — wenn sich zeigt, ob Profile, Terminologien und Mappings tatsächlich gepflegt werden.

Was am Go-live endet

Ein Projekt hat ein Ende: Budget, Plan, Abnahme, Termin. Am Go-live ist die Schnittstelle gebaut, die Profile sind geschrieben, die Mappings stehen, der erste Austausch läuft. Der Auftrag ist erfüllt.

Was endet, ist der Auftrag. Was nicht endet, ist der Gegenstand.

Was danach beginnt

Drei Dinge altern ab dem Tag nach dem Go-live — ob jemand sie pflegt oder nicht:

• Profile. Implementation Guides bekommen neue Versionen, Basisprofile ziehen nach, Anforderungen ändern sich. Ein Profil, das niemand nachzieht, beschreibt bald ein System, das es so nicht mehr gibt.
• Terminologien. ICD-10-GM, OPS, LOINC, ATC und KDL erscheinen in Jahresständen. Codes fallen weg, kommen hinzu, verschieben ihre Bedeutung. Ein ValueSet ohne Pflege bindet an einen Stand, den die Quelle längst verlassen hat.
• Mappings. Sie sind die empfindlichste Stelle, weil sie nur mittelbar auffallen. Ändert sich im Quellsystem ein Feld oder eine Hausregel, bildet das Mapping weiter ab — nur eben etwas anderes als vorher.

Das Niemandsland

Diese drei Aufgaben liegen zwischen den Zuständigkeiten. Die IT verantwortet Betrieb und Verfügbarkeit — Profilpflege steht in keinem Betriebshandbuch. Der Fachbereich kennt die Bedeutung der Daten, nicht die StructureDefinition, in der sie steht. Die Architektur hat entschieden und ist weitergezogen.

So entsteht ein Niemandsland: Jeder hält die Pflege für die Aufgabe eines anderen. Das ist kein Vorwurf an Personen, sondern eine Lücke in der Aufbauorganisation — und die schließt sich nicht von selbst.

Woran man nach sechs Monaten erkennt, ob Governance lebt

Governance ist kein Dokument, sondern eine Praxis. Ein halbes Jahr später lässt sie sich an nüchternen Fragen ablesen:

• Gibt es je Profil einen namentlich benannten Verantwortlichen — eine Person, kein Team?
• Liegen die Profile versioniert im selben Werkzeug wie der Code?
• Ist seit dem Go-live ein Terminologie-Jahresstand nachgezogen worden — und wurde die Auswirkung geprüft, nicht nur die Datei getauscht?
• Erreicht eine Änderung im Quellsystem die Mapping-Pflege, bevor sie in den Daten ankommt?
• Wird die Schnittstelle regelmäßig geprüft, oder erst, wenn jemand sich beschwert?

Wer diese Fragen mit Ja beantwortet, betreibt. Wer sie mit „müsste man mal“ beantwortet, hat ein Projekt abgeschlossen und keinen Betrieb begonnen.

Warum das grüne Häkchen hier nicht genügt

Die naheliegende Antwort ist ein Validator im Nachtlauf. Er ist nützlich und notwendig und beantwortet genau eine Frage: Entspricht diese Ressource den Regeln des Profils? Ist das Profil veraltet, prüft er gegen die veraltete Regel und meldet grün. Bildet ein Mapping seit dem letzten Release etwas anderes ab, bleibt das Ergebnis wohlgeformt und die Prüfung still — beschrieben in Was FHIR-Validierung NICHT prüft.

Betrieb heißt deshalb: eine zweite Frage stellen. Nicht nur „ist es konform?“, sondern „ist es noch dasselbe?“.