MEMMDigital Health Platformby ITL Software GmbH
Start / Healthcare / FHIR®
Healthcare / FHIR®

FHIR®-Profile ändern sich. Wie bleiben Datenflüsse prüfbar?

Unterschiedliche Profile und Versionsstände erschweren die Prüfung strukturierter Gesundheitsdaten zwischen Systemen. MEMM beschreibt versionierte Profil-, Validierungs- und Verarbeitungsgrenzen für klar benannte Anwendungsfälle und strukturierte Inhalte. Unterstützte FHIR®-Versionen, Profile, Zielsysteme und Prüfverfahren werden projektspezifisch dokumentiert; eine allgemeine FHIR®-, ePA- oder TI-Konformität wird nicht behauptet.

Ein Feld · synthetisches Beispiel

Patient.active: Der Typ zählt.

  1. Vorher "active": "true" Zeichenkette Typregel nicht erfüllt
  2. Nachher "active": true Boolean Typregel erfüllt

Verglichen wird nur der JSON-Typ dieses vorhandenen Feldes. Auch Boolean false erfüllt dieselbe Regel.

Die lokale Feldprüfung ausprobieren
Statisches Lernbeispiel. Keine vollständige FHIR- oder Profilprüfung; kein Fachdienst hat eine Ressource angenommen.
Versionierte Fachverträge: TI-Messaging, TI-Flow, DiPag und ePA verwenden FHIR in unterschiedlichen Rollen. Die Vertragsübersicht trennt Nachrichten, Task-Operationen, Rechnungen und Aktenzugriff; die Quellenerläuterungen benennen Versionen und offene Quellenabweichungen.
Validierungsgrenze: Eine zusätzliche lokale Vorprüfung kann offensichtliche Strukturfehler abweisen. Die verbindlichen Regeln zur Erzeugung von FHIR-Ressourcen gelten für Clients auch ohne diese Zusatzprüfung. Eine lokale Prüfung allein beweist keine Gleichwertigkeit mit dem normativen Fachdienst-Validator. Der TI-Flow Core IG 2.0.0 beschreibt eine separate Schnittstelle für die Client-Entwicklung und -Integration; daraus folgt kein öffentliches $validate am produktiven Fachdienst. Veröffentlichtes CapabilityStatement ↗.

Integrationsvertrag

01

Kontext erfassen

Eingang, Quelle, Version und Verarbeitungskorrelation werden für den vereinbarten Datenfluss eindeutig zugeordnet.

02

Scope prüfen

Nur ausdrücklich freigegebene Profile, Versionen und Regeln werden als unterstützter Scope behandelt; unbekannte Kombinationen erhalten einen definierten Ablehnungszustand.

03

Verarbeitung begrenzen

Wiederholungen, Effekte und Verantwortungsübergaben werden innerhalb der benannten Integrationsgrenze modelliert.

04

Änderung zuordnen

Release-, Konfigurations- und Prüfreferenzen können einem konkreten Datenfluss oder Adapterstand zugeordnet werden.

Durchgespieltes Beispiel · synthetische Daten

Ein Feld. Ein sichtbarer Fehler. Eine bewusste Korrektur.

Ein kleines Patient-Beispiel führt vom falschen JSON-Typ zum lokalen Prüfergebnis. Den Unterschied machen die Anführungszeichen.

  1. Eingang

    Das Feld enthält Text

    Der vorhandene active-Wert ist die Zeichenkette "true". Das Beispiel prüft genau dieses eine Feld.

    "active": "true"
  2. Lokale Prüfung

    Der Typfehler wird sichtbar

    Die Zeichenkette erfüllt die Boolean-Typregel des Beispiels nicht. Es wird nichts an einen Fachdienst gesendet.

    string ≠ boolean
  3. Korrektur

    Den JSON-Typ ändern

    Die Anführungszeichen entfallen. Der Wert ist jetzt ein Boolean; das geänderte Beispiel muss erneut geprüft werden.

    "active": true
  4. Ergebnis

    Die lokale Feldprüfung besteht

    Nur diese Typprüfung ist bestanden. Die übrige Ressource und ein etwaiges Produktprofil bleiben ungeprüft.

    boolean → lokale Prüfung bestanden
Was belegt diese kleine Prüfung tatsächlich?

FHIR R4 definiert Patient.active als optionalen Boolean (0..1). Das Feld beschreibt die aktive Nutzung des Datensatzes, nicht den medizinischen Zustand der Person. Dieses Beispiel enthält das Feld immer und prüft ausschließlich dessen JSON-Typ.

Die vollständige lokale Regel: typeof resource.active === 'boolean'

Dies ist kein vollständiger FHIR-Validator. Andere Felder, Primitive Extensions, Profile, Terminologien, Berechtigungen und die Annahme durch einen Fachdienst werden nicht geprüft. Der Button speichert und übermittelt keine Ressource.

Felddefinition: HL7 FHIR R4 4.0.1 · Patient.active ↗

Dies ist kein vollständiger FHIR-Validator. Andere Felder, Primitive Extensions, Profile, Terminologien, Berechtigungen und die Annahme durch einen Fachdienst werden nicht geprüft. Der Button speichert und übermittelt keine Ressource.

Weiter zu den verschiedenen FHIR-Produktverträgen →
Beispielhafte Integrationsfelder

Von Dokumentmetadaten bis zu strukturierten Folgeaktionen.

Die Beispiele beschreiben mögliche Projektfelder und keine bereits zugesicherte Unterstützung eines bestimmten gesetzlichen oder technischen Verfahrens.

Dokument- und Metadatenflüsse

Versionen, Herkunft, Status und Übergabepunkte ausgewählter Dokumentprozesse entlang eines vereinbarten Profils behandeln.

Strukturierte Inhalte & Folgeaktionen

Versionierte Profilreferenzen, Verarbeitungsstatus und Capability-Grenzen für strukturierte Inhalte mit fachlich verantworteten Folgeaktionen verbinden, ohne medizinische Entscheidungen in der Integrationsschicht zu behaupten.

Aufbewahrungs- und Zugriffsgrenzen

Projektbezogene Regeln für Speicherung, Zugriff, Einschränkung und Löschung als ausdrücklich benannte Verantwortungsgrenzen abbilden.

FHIR Contracts · Scope Separation

FHIR ist ein Interoperabilitätsstandard; Profile, Implementierungsleitfäden und Operationen bilden unterschiedliche Produktverträge.

TI-Flow FHIR

FHIR Task, Flowtype und Fachdienstoperationen folgen den IG zu TI-Flow_26_3; die maßgebliche FD-Validierung ist separat nachzuweisen. Lokale Vorprüfung beweist keine Validator-Parität.

gemProdT_TI-Flow-FD_PTV_1.0.0-0_V1.0.0 ↗

TI-M strukturierte Daten

Zwei getrennte TI-M-Verträge: strukturierte fachliche Nutzdaten in Messaging-/Matrix-Events und FHIR-VZD-Verzeichnisabfragen zur Teilnehmerermittlung. Keiner davon ist die TI-Flow-Task-API.

gemProdT_TI-M_Hl_Client_Pro_PTV_1.0.0-0_V1.0.0 ↗

DiPag / FHIR

DiPag verwendet FHIR R4 4.0.1 und de.gematik.dipag 1.0.8. RE-PS, FdV und KTR haben getrennte Rollen; DocumentReference und rollenspezifische Operationen bilden den Rechnungsvertrag. Persönliche Status und Markierungen sind kein Erstattungsbescheid.

Draft_DiPag_26_1 ↗

ePA: Basic, MHD und Medication

Basic 1.3.2 definiert gemeinsame FHIR-Regeln, Audit Event Service und Patient Service. MHD 1.1.3 ermöglicht lesende Metadaten-/Volltextsuche und Dokumentabruf aus dem XDS Document Service (ITI-67/ITI-68); Dokumente werden weiterhin über XDS eingestellt. Medication 1.3.5 hat eigene Daten- und Operationsverträge. Die jeweiligen Aktenzugriffsrechte bleiben maßgeblich; Common-Versionen aus PTV und Paketabhängigkeiten werden getrennt nachgewiesen.

gemProdT_ePA_FdV_PTV_3.1.3-3_V1.0.0 ↗

Unterstützte Profile und Operationen sind je Version und Host-/Fachdienstrolle getrennt auszuweisen; keine pauschale FHIR-Konformitätsbehauptung.

Versionierte Integrationsgrenze

Externe Profile können sich ändern. Der Host integriert gegen einen kontrollierten Vertrag.

Die öffentliche Architektur trennt externe FHIR®-Kontexte, eine benannte MEMM-Integrationsgrenze und hostseitige Fachprozesse. Unterstützte Profile und Versionen bleiben dabei ausdrücklich release- und projektspezifisch.

01Version zuerst

Ein Profilname allein definiert keinen unterstützten Scope. Version, Zielsystem und Prüfreferenz gehören zur Integrationsvereinbarung.

02Fail closed

Unbekannte oder nicht freigegebene Kombinationen sollen nicht still als kompatibel behandelt werden, sondern einen definierten Ablehnungszustand behalten.

03Fachlogik bleibt beim Host

MEMM kann strukturierte Übergaben begrenzen und nachvollziehbar machen, ohne medizinische Bewertung oder organisationsspezifische Fachentscheidungen zu übernehmen.

Scope-Grenze: Das Boundary-Modell beschreibt ein Architekturprinzip. Es erweitert keine Aussage zu FHIR®-, ePA-, TI-, Profil- oder Interoperabilitätskonformität.
Einordnung: Matrix, FHIR®, TI, TI-M, TI-Flow, ZETA, ePA und gematik bezeichnen externe Standards, Infrastrukturen oder Integrationskontexte. Keine Zertifizierung, Zulassung oder Beauftragung durch gematik oder eine andere Behörde wird behauptet. Unterstützte Profile, Versionen und Betriebsgrenzen werden vor einem Einsatz schriftlich bestätigt.
Regulatorische Grenze: Die öffentliche Darstellung ist ein Produkt- und Architekturüberblick. Sie legt keine medizinische Zweckbestimmung fest und ersetzt weder Interoperabilitätsprüfung noch Datenschutz-Folgenabschätzung, Konformitätsbewertung oder behördliche Zulassung.
TI-Flow_26_3 · FHIR IG

FHIR-Profilfamilien sind getrennt zu versionieren und zu prüfen.

Releasegebundene IG-Referenzen, keine MEMM-Abdeckungszusage. Operationen, Validierung und Versionsverträglichkeit sind je IG und Test gesondert zu prüfen.

common

TI Common

FHIR IG 1.4.0

Gemeinsame FHIR-Bausteine für TI-Dienste; dienstspezifische IG referenzieren Profile, Terminologien und Grundregeln nach Bedarf.

Offizielle Quelle ↗
core

TI-Flow Core

FHIR IG 2.0.0

Workflowübergreifende Task-Operationen, Rollenprüfung, Status, Fehlerbehandlung und FHIR-Validierung zwischen Clients und TI-Flow-Fachdienst.

Offizielle Quelle ↗
rx

E-Rezept

FHIR IG 2.0.0

Arzneimittelverordnung und Abgabe zwischen verordnendem PS, Apotheke, Versicherten und Fachdienst; zusätzlich Mapping und asynchrone Übermittlung an ePA Medication.

Offizielle Quelle ↗
bfarm

BfArM

FHIR IG 2.0.0

Eigener Übermittlungsvertrag vom TI-Flow-Fachdienst zum BfArM-Webdienst für den digitalen E-T-Rezept-Durchschlag an das T-Register; der Verordnungsworkflow 166 bleibt im E-Rezept-IG.

Offizielle Quelle ↗
diga

DiGA

FHIR IG 2.0.0

Workflow 162: Verordnende erstellen eine DiGA-Verordnung; Versicherte weisen sie dem Kostenträger zu. Dieser stellt einen Freischaltcode oder eine begründete Rückmeldung bereit.

Offizielle Quelle ↗
chargeitem

ChargeItem

FHIR IG 2.0.0

PKV-Abrechnungsinformationen zu E-Rezepten: Das Apothekenverwaltungssystem stellt Daten bereit; Fachdienst und berechtigte Clients verwalten ChargeItem, Consent und zugehörige Kommunikation. Die Abrechnung außerhalb des Fachdienstes liegt außerhalb dieses IG.

Offizielle Quelle ↗
epa-medication

ePA Medication Service

FHIR IG 1.3.5

Eigener ePA-Daten- und Schnittstellenvertrag für Medikationsliste und Medikationsplan. TI-Flow ist für seine asynchrone Übermittlung ein aufrufendes System; ein erfolgreicher TI-Flow-Request bestätigt noch keine ePA-Übernahme.

Offizielle Quelle ↗
Anforderungen im Zusammenhang

Was die Spezifikationen für diese Architektur bedeuten.

Ausgewählte Anforderungen mit fester Quellenversion. Ein Thema aufklappen, um Verantwortung, Schnittstelle oder Datengrenze nachzulesen.

FHIR-Nutzdaten innerhalb von Matrix-Events

FHIR-Ressourcen werden mit dem Event-Typ de.gematik.fhir und fhir.json übertragen: eingebettet oder als JSON-/XML-Datei, mit Metadaten zu StructureDefinition, Ressourcentyp und FHIR-Version. Auch fhir.json verlangt einen Plaintext-Fallback unter de.gematik.text. Plaintext bezeichnet hier die Textrepräsentation im Event und hebt dessen E2EE-Schutz nicht auf. Proprietäre Events verwenden structuredData.json und einen Plaintext-Fallback unter de.gematik.text; auch unbekannte Events müssen vorhandene Text- und Datei-Fallbacks zugänglich machen. Ein Fachverfahren wird mit type und version im Block de.gematik.fachverfahren identifiziert. FHIR-VZD-Suche, TI-Flow-Operationen und dieser Nachrichtenvertrag sind getrennte Schnittstellen.

Gerätefähigkeiten und Verarbeitungsstatus

Client Capabilities werden unter de.gematik.client_capability.${device_id} im Nutzerprofil veröffentlicht. Bei einem vorhandenen Dehydrated Device müssen nach Logout des letzten Geräts dort Capabilities hinterlegt werden. Der Verarbeitungsstatus nutzt eigene Anfrage- und Antwortstrukturen: from_device, optional to_device und lifetime sowie einen Bezug auf die ursprüngliche event_id. Eine gültige, an das Gerät gerichtete Anfrage muss beantwortet werden. Die Antwort verknüpft success oder error über m.reference mit dem ursprünglichen Event; dieser Verarbeitungsstatus ist von Zustellung oder Lesebestätigung zu unterscheiden.

Separater HTTP-Report für Fachverfahren

Der Client erfasst Metadaten gesendeter und empfangener Fachverfahren und übermittelt die Statistik per POST /report an den Fachdienst. Der Report beschreibt einen Messbeginn (start) und Zähler (Anzahl) je Fachverfahren und Version in den optionalen Listen sent und received. Das ist ein eigener Vertrag neben Matrix-Events und FHIR-VZD-Suche. Fehlgeschlagene Reports werden höchstens 14 Tage zwischengespeichert und nach konfigurierbarem Intervall oder bei der nächsten aktiven Verbindung erneut übertragen. Quellenhinweis: Die vollständige URL im Headless-PTV verweist auf Commit f8654d7…, während die Versionsspalte dcd2d280 nennt; der Link hier folgt ausdrücklich der vollständigen PTV-URL.

Fragebögen als konkreter TI-M-ePA-Vertrag

TI-M ePA Clients müssen de.gematik.questionnaire.generic v1 und de.gematik.questionnaire.consent v1 auf Empfängerseite unterstützen: Capabilities unmittelbar nach Login veröffentlichen, empfangene Fragebögen einschließlich Vorbelegungen ausfüllbar darstellen, finale Antworten als de.gematik.fhir-Event zurücksenden und beantwortete Fragebögen später wieder anzeigen. Die Pflicht betrifft den TI-M Client ePA. Sie beschreibt keinen bereits nachgewiesenen MEMM-Formularumfang und gewährt keinen Zugriff auf die elektronische Patientenakte.

$create: Task, PrescriptionID und AccessCode

Das verordnende Primärsystem übermittelt workflowType an POST /Task/$create. Der Fachdienst prüft die zugelassene Rolle der Leistungserbringerinstitution anhand von zeta-user-info.professionOID sowie die Eingaben, erzeugt den AccessCode und liefert bei Erfolg einen Task im Status draft. Task.id entspricht der PrescriptionID. Beide Identifikatoren und der AccessCode gehören zum nachfolgenden Aktivierungskontext; der AccessCode ist geschützt zu behandeln. Ein interner BPMN-Vorgang besitzt keine eigene Autorität über den Status dieses Tasks.

$activate: Signatur erhalten, Zugriff und Status prüfen

Das Primärsystem erzeugt das profilkonforme Verordnungsbundle mit der erhaltenen PrescriptionID. Die QES erfolgt durch den Leistungserbringer über die Konnektor-Signaturoperation als enveloping CAdES mit eingebetteter OCSP-Antwort; authoredOn und QES-Erstellung müssen taggleich sein. Der Adapter erhält Inhalt und Signaturobjekt unverändert und verpackt die signierten Daten als ePrescription-Binary in Parameters. POST /Task/<id>/$activate benötigt Task-ID, AccessCode im Header X-AccessCode oder Parameter ?ac sowie die QES-Daten. Der Fachdienst prüft unter anderem Rolle, AccessCode, Ausgangsstatus draft, Signatur, PrescriptionID und Profil. Erst Erfolg liefert Task.status = ready. FHIR-Fehlerantworten bleiben als OperationOutcome erkennbar. Die eigene Zertifikats- und Sperrstatusprüfung des Fachdienstes einschließlich einer vorgeschriebenen OCSP-Ergänzung bleibt von der Adapteraufgabe getrennt.

Unbekannte Ausgänge nach der jeweiligen Operation klären

Retry und Client-Failover richten sich nach der veröffentlichten Fehlerbehandlung und der konkreten Operation. A264 unterscheidet unter anderem 4xx außer 408/429 (kein Retry), 429 (stündlich, höchstens zehn Wiederholungen) und 502/506 (Retry nur mit Client-Failover, höchstens zehn Wiederholungen). Äußerer HTTP-Status und innerer ASL-Status werden berücksichtigt. Ein Timeout ist zunächst ein unbekannter Ausgang. Ein abgelehnter Folgeaufruf beweist nicht, dass der Remote-Task seit dem letzten bestätigten Stand unverändert blieb. Für einen verlorenen $activate-Response beschreibt der Core IG einen erneuten Aufruf; der erläuternde Client-Hinweis nennt dabei 403, die serverseitige Statusanforderung A175 dagegen 412. Diese Quellenabweichung bleibt ausdrücklich offen. Die Architektur leitet daraus weder einen universellen Fehlercode noch eine pauschale Wiederholungsregel ab.

Normativer Validator: OCI, Konfiguration und Offline-Betrieb

Der Hersteller liefert ein CoreImage; daraus entsteht mit gematik-FHIR-Konfiguration ein OCI-ValidatorImage. Pakete, Regeln, expandierte Terminologien und aus Differentials erzeugte Snapshots werden beim Build gebunden. Eine unplausible oder inkonsistente Konfiguration muss den Build abbrechen. Externe Paket-Registry- und Terminologieverbindungen zur Laufzeit sind untersagt. Die Komponente ist technisch zu isolieren und muss dieselben Ergebnisse wie der Referenzvalidator erzeugen; ein proprietärer Validator ist bei dieser Ergebnisgleichheit möglich. Die interne Anbindung kann per REST oder internem Protokoll erfolgen. Der Fachdienst exponiert $validate nicht an Clients; der separate ClientValidationServer dient Entwicklung und Integration. Betriebslogs enthalten keine validierten Nutzdaten.

TI-Flow: Profilgültigkeit pro Ressource und Zeitpunkt

Ein interner Mapper-Pin legt die extern zulässige Profilversion nicht fest. Der TI-Flow-Fachdienst bestimmt den normativen Referenzzeitpunkt je Ressource, etwa MedicationRequest.authoredOn oder MedicationDispense.whenHandedOver, und wertet ihn gegen die aktuelle FHIR-Konfiguration aus. Datums- und Zeitangaben ohne Zeitzone folgen der am jeweiligen Datum gültigen deutschen Zeit (CET/CEST). Der Core IG verlangt bei verpflichtendem meta.profile genau einen Eintrag und für generierte Ressourcen eine major.minor-Versionsangabe im Canonical; die vollständige Paketversion bleibt gesondert dokumentiert. Client-Regeln für fullUrl, auflösbare Referenzen und profilierte Extensions gelten zusätzlich. Eine optionale Vorprüfung hebt diese Erzeugungsregeln nicht auf.

ePA Medication: eigener asynchroner Übermittlungsweg

Der TI-Flow-Fachdienst übermittelt Daten der Flowtypes 160, 166, 169, 200 und 209 asynchron an den ePA Medication Service. Der erfolgreiche ursprüngliche Client-Aufruf bestätigt daher noch keine Übernahme in die ePA. Der Fachdienst ordnet Verordnungs- und Dispensierdaten den ePA-Profilen zu und nutzt die dort definierten Bereitstellungs- und Stornierungsoperationen. TI-Flow E-Rezept 2.0.0 regelt die Auslösung und das Mapping; ePA Medication 1.3.5 beschreibt den eigenen Daten- und Schnittstellenvertrag. Diese Rollen sind getrennt von einer allgemeinen ePA-FdV-Integration zu prüfen.

DiPag FHIR 1.0.8: Akteure und Operationen

Der Vertrag nutzt FHIR R4 4.0.1 und das Paket de.gematik.dipag 1.0.8. RE-PS übermittelt Rechnungen an Patient/{id}/$invoice-submit. Das FdV sucht eigene DocumentReference-Ressourcen, ruft Inhalte über DocumentReference/$retrieve ab und verwaltet den Rechnungsvorgang über $change-status, $process-flag und $erase auf DocumentReference/{id}; AuditEvent dient dem Nutzerprotokoll. RE-PS und KTR-PS können Dokumente über $retrieve mit Dokumenttoken abrufen. Claims und Scopes bleiben rollenspezifisch. Die Einreichung zur Erstattung erfolgt im MVP über andere Wege, etwa die Teilen-Funktion des FdV; sie ist nicht der RE-PS-Aufruf $invoice-submit.

Dokumenttoken, Profile und Markierungen

Der Dokumenttoken ist der Identifier mit dem System https://gematik.de/fhir/sid/dipag-token; er ist nicht die technische DocumentReference.id. Das CapabilityStatement sieht DocumentReference-Suche und Operationen vor, keinen direkten DocumentReference-read. Für $invoice-submit gilt das Eingangsprofil dipag-dokumentenmetadaten-eingang; der Fachdienst verwendet dipag-dokumentenmetadaten-intern. $process-flag ersetzt den vollständigen änderbaren Markierungssatz. Ohne Markierungen werden diese entfernt; persönlich und abgerufen durch KTR bleiben ausgenommen. Die persönlichen Bearbeitungszustände sind offen, erledigt und papierkorb. Sie sind keine Erstattungsentscheidung eines Kostenträgers.

Quellenhinweis zur Submit-Operation

In gemSpec_DiPag_FD 1.1.3_CC nennt A_25849-01 die Operation $invoice-submit, A_25880 dagegen $dipag-submit. OperationDefinition Submit und CapabilityStatementFD im Paket 1.0.8 verwenden beide invoice-submit. Die Operationskarte auf dieser Seite folgt ausdrücklich diesem Paket. Die abweichende PDF-Stelle bleibt als Quellenwiderspruch dokumentiert; der Paketbefund ist keine offizielle Berichtigung des PDF.

Dokumente finden: XDS, MHD und Basic

XDS verwendet SOAP/WSDL, etwa DocumentRegistry_RegistryStoredQuery für Metadatensuche und DocumentRepository_RetrieveDocumentSet für den Abruf. Der zusätzliche MHD-Consumer des FdV nutzt DocumentReference-Suche und -read: Find Document References (ITI-67) verbindet Metadaten mit der Volltextsuche über _content. Jede MHD-Suche belegt mindestens patient.identifier und status; der Pfad lautet /epa/mhd/api/v1/fhir/DocumentReference. Retrieve Document (ITI-68) ruft den Inhalt über DocumentReference.content.attachment.url ab. Ein nicht vorhandenes und ein vor dem Anfragenden verborgenes Dokument liefern dabei beide 404. Basic IG 1.3.2 beschreibt unter anderem Patient und AuditEvent; Medication IG 1.3.5 beschreibt eML/eMP. Diese Verträge sind getrennt. Der HCSA-Filter durchsucht lokal Namen und Datum synthetischer Dokumente und implementiert keine MHD-Volltextsuche.

TI Common: PTV-Pin und Paketabhängigkeit

Der FdV-PTV 3.1.3-3 nennt TI Common 1.3.0. Die tatsächlich geprüften Pakete de.gematik.epa 1.3.2 und de.gematik.epa.mhd 1.1.3 deklarieren dagegen de.gematik.ti 1.3.1 als Abhängigkeit. Die beiden Common-Versionen sind deshalb getrennt dokumentiert. Ein konkreter Unterschied liegt im Profil TI Organization: 1.3.1 setzt mustSupport=true auf Organization.extension; in 1.3.0 fehlt diese Kennzeichnung an diesem Element. Das ist relevant für die Auswertung von Profilanforderungen und zugehörige Tests, beweist für sich allein aber keine Inkompatibilität im Datenaustausch. Eine offizielle Auflösung des Versionsunterschieds ist im geprüften Material nicht enthalten. Weder eine automatische Ersetzung des PTV-Pins noch eine pauschale Konformitätsaussage wird daraus abgeleitet.

Redaktioneller Quellenabgleich: 17. Oktober 2026. Die Zuordnung erklärt Anforderungen; Implementierungsprüfung und Produktzulassung benötigen eigene Nachweise.