Warum „FHIR-kompatibel“ als Aussage zu grob ist
FHIR® ist ein breites Spektrum von Ressourcen, Versionen und Profilen. Für eine konkrete Integration müssen deshalb die tatsächlich verwendeten Profile, deren Versionen, die Validierungslogik und die Zielsysteme benannt werden. Ein einzelner erfolgreicher Parser oder Datentransport belegt keine allgemeine FHIR®- oder ePA-Konformität.
Was ein versionsgebundener Datenfluss beschreibt
- Quelle und Version des strukturierten Inhalts.
- Benannte Profil- und Validierungsgrenze.
- Expliziter Verarbeitungs- oder Ablehnungszustand.
- Übergabe an fachlich verantwortete Folgeprozesse.
Bezug zu TI-Messenger_26_2
A_28763 verwendet de.gematik.fhir und das versionsgebundene fhir.json einschließlich de.gematik.text-Plaintext-Fallback für FHIR-Ressourcen; A_28758 verlangt structuredData.json und Plaintext-Fallbacks für proprietäre Events. Capabilities werden pro Gerät veröffentlicht (A_28762). Verarbeitungsstatus folgt statusRequest.json/statusResponse.json und ist keine Lesebestätigung (A_28760, A_28491). Fachverfahrensstatistiken gehen über eine separate HTTP-Report-Schnittstelle an den Fachdienst; fehlgeschlagene Reports werden maximal 14 Tage gespeichert (A_28919, A_28921). FHIR-VZD-Suche ist ein weiterer eigenständiger Vertrag.
Aktendienste haben eigene FHIR-Verträge
ePA Basic 1.3.2 definiert gemeinsame Regeln sowie Patient-/AuditEvent-Dienste. MHD 1.1.3 ergänzt Dokumentreferenzsuche und Abruf über dem bestehenden XDS Document Service; seine Volltextsuche und Zugriffsprüfungen sind von einem lokalen Dokumentfilter verschieden. Medication 1.3.5 hat eigene Profile und Operationen. Der ePA-FdV-PTV nennt Common 1.3.0, die geprüften Basic- und MHD-Pakete hängen von 1.3.1 ab. Der Wissensartikel zum Aktenzugriff erklärt diese Versionen und ihre unterschiedlichen Verantwortlichkeiten.