Das zentrale Arbeitsprodukt von K04 ist der Schnittstellensteckbrief. Er dient als gemeinsame Verständigungsgrundlage zwischen Fachbereich, IT, Hersteller, Datenschutz, Informationssicherheit, Qualitätsmanagement und Management. Bei komplexen Projekten ersetzt er keine vollständige technische Spezifikation. Er verhindert jedoch, dass Entwicklung oder Beschaffung auf unklaren Annahmen aufbauen.

Der Steckbrief beschreibt zunächst Identität, Zweck und Geltungsbereich der Schnittstelle. Danach werden Quelle und Ziel, beteiligte fachliche und technische Rollen sowie die auszutauschenden Informationsobjekte festgelegt. Für die Datenelemente werden Definition, Datentyp, Kardinalität, Terminologie, Einheit, Herkunft und Qualitätsregeln dokumentiert. Beim Standardstapel werden beispielsweise FHIR-Version, Profile, Implementation Guides, MIO oder ISiK, DICOM-Dienste und Terminologieversionen eindeutig benannt.

Ebenso wichtig sind Interaktionen, Identitäten, Provenienz und Sicherheit. Der Steckbrief muss beschreiben, wodurch eine Übertragung ausgelöst wird, ob Push oder Pull verwendet wird, welche Operationen zulässig sind, wie Wiederholungen behandelt werden und welche Authentisierung beziehungsweise Autorisierung vorgesehen ist. Für Fehler werden Ablehnung, Quarantäne, Retry, manuelle Klärung und gegebenenfalls klinische Eskalation festgelegt.

Für die Beschaffung bedeutet dies, dass pauschale Marketingaussagen wie „FHIR-ready“, „DICOM-kompatibel“ oder „ISiK-konform“ nicht ausreichen. Hersteller sollten konkret angeben können, welche FHIR-Version und Profile unterstützt werden, welche ISiK-Stufe und welches Modul betroffen sind, welche DICOMweb-Operationen verfügbar sind, welche Terminologien unterstützt werden und wie Fehler zurückgemeldet werden. Auch Updatefähigkeit, Testumgebung und Exit-Möglichkeiten gehören in die Bewertung.

Vor dem Produktivbetrieb können Proof of Concept und Pilot unterschiedliche Aufgaben übernehmen. Ein Proof of Concept prüft grundlegende technische und fachliche Risiken mit synthetischen Daten und begrenztem Umfang. Ein Pilot geht weiter und betrachtet reale Arbeitsprozesse, Rollen, Support, Ausfallbetrieb und Schulung. Erst danach sollte ein regulärer Betrieb mit definierten Servicelevels, Monitoring und Änderungssteuerung beginnen.

Im Betrieb reichen technische Verfügbarkeitswerte allein nicht aus. Sinnvolle Kennzahlen können zusätzlich Quarantänequote, Validierungsfehler, Dubletten, nicht auflösbare Identitäten, Verzögerung zwischen Messung und Sichtbarkeit oder offene Fehler umfassen. Gleichzeitig muss zwischen einem aktuellen Incident und dessen zugrunde liegender Ursache unterschieden werden. Bei einer falschen Einheitenanzeige muss beispielsweise zunächst der sichere Betrieb wiederhergestellt und anschließend geklärt werden, ob Mapping, Spezifikation oder Teststrategie die Ursache waren.

K04 benennt außerdem klare Stoppsignale. Dazu gehören mögliche falsche Patientenzuordnungen, fehlende oder verwechselbare Einheiten, nicht nachvollziehbare Korrekturen, klinisch relevante Informationen ohne verantwortete Bearbeitung, unkontrollierte Dubletten, fehlende Profilversionen, lokale Codes ohne Mappingregeln oder Projekte, in denen niemand fachliche Datenverantwortung übernimmt. In solchen Situationen darf nicht einfach weiter implementiert und später „nachgebessert“ werden.

Interoperabilität ist damit nicht nur eine Aufgabe der IT. Ärztliche Fachrollen beurteilen die klinische Eignung, Pflege bringt Wissen über Erhebung und Arbeitsabläufe ein, pharmazeutische Fachrollen bewerten Arzneimittelsemantik, Management und Beschaffung definieren prüfbare Anforderungen, IT implementiert Schnittstellen und technische Kontrollen, während Qualitäts- und Projektmanagement Anforderungen, Risiken, Tests und Freigaben nachvollziehbar miteinander verbinden.