Thema 4.3 — Interoperabilität und Datenstandards

In Gesundheit und Pflege ist Interoperabilität keine technische Nettigkeit, sondern eine Anforderung an klinische Sicherheit und Gerechtigkeit: Wenn Systeme die richtigen Daten in der richtigen Form, mit eindeutiger Bedeutung, am Behandlungsort nicht teilen können, werden Menschen geschädigt und Ungerechtigkeit verstärkt.

Warum das in Gesundheit und Pflege wichtig ist#

Die Versorgung eines Menschen findet selten an einem Ort statt. Eine einzelne Episode kann eine Hausarztpraxis, einen Rettungsdienst, eine Notaufnahme, eine Krankenhausstation, eine Gemeindekrankenschwester, eine Apotheke, ein Sozialfürsorgeteam und eine Betreuungsperson zu Hause berühren. Jede hält einen Teil der Akte. Wenn diese Teile nicht sicher und schnell zusammengeführt werden können, treffen Klinikerinnen und Kliniker Entscheidungen mit fehlender Information: eine nicht gesehene Allergie, ein doppelt verordnetes Medikament, ein unnötig wiederholter Test, ein für das Team, das es braucht, unsichtbares Schutzkennzeichen.

Interoperabilität ist es, die eine Menge unverbundener Systeme in etwas verwandelt, das sich aus Sicht der Patientin wie ein verzahnter Service verhält. Sie ist die Infrastruktur unter integrierter Versorgung. Wenn sie funktioniert, kann eine Klinikerin in einer Organisation sehen, was eine andere erfasst hat, und darauf vertrauen, dass es bedeutet, was sie denkt. Wenn sie versagt, bleibt das Versagen oft still, bis jemand geschädigt wird.

Es ist auch eine Gerechtigkeitsfrage. Menschen mit dem komplexesten Bedarf – gebrechliche ältere Erwachsene, jene mit mehreren Langzeiterkrankungen, Menschen, die zwischen Services wechseln – sind genau die Menschen, deren Daten am stärksten fragmentiert sind. Schlechte Interoperabilität schadet daher den Verletzlichsten am meisten. Und es ist eine Frage des öffentlichen Vertrauens: Menschen nehmen vernünftigerweise an, dass der NHS ihre Informationen bereits sinnvoll teilt, und sind bestürzt zu erfahren, wie oft er es nicht tut.

Schließlich schützt Interoperabilität öffentliches Geld. Proprietäre Systeme, die keine Daten austauschen können, binden Organisationen an teure, schwer ersetzbare Verträge und erzwingen kostspielige Punkt-zu-Punkt-Integrationen. Das Bauen nach offenen Standards ist der Weg, Optionen offen zu halten, Lieferanten ehrlich zu halten und zu vermeiden, wiederholt für die Lösung desselben Problems zu zahlen.

Kernkonzepte#

Interoperabilität ist die Fähigkeit verschiedener Systeme, Informationen auszutauschen und zu nutzen. Es ist nützlich, zwei Schichten zu trennen. Syntaktische oder technische Interoperabilität bedeutet, dass zwei Systeme eine Nachricht austauschen können und jedes ihre Struktur parsen kann – der Umschlag kommt an und kann geöffnet werden. Semantische Interoperabilität bedeutet, dass das empfangende System versteht, was der Inhalt bedeutet, auf dieselbe Weise wie der Sender – dass ein Code für „Penicillinallergie“ auf beiden Seiten identisch interpretiert wird. Technische Interoperabilität ohne semantische Interoperabilität ist gefährlich: Daten fließen, aber Bedeutung geht verloren oder wird verzerrt.

Gesundheitsdaten werden mittels Standards ausgetauscht. Health Level 7 (HL7) ist die im Gesundheitswesen am meisten genutzte Standardfamilie. Ihr älteres HL7-Version-2-(v2-)Messaging, das pipe- und caret-getrennten Text nutzt, trägt noch immer eine riesige Menge an Krankenhaus-Messaging und wird das noch Jahre tun. Ihr moderner Standard, HL7 Fast Healthcare Interoperability Resources (FHIR), modelliert klinische Informationen als „Ressourcen“, die über webartige Anwendungsprogrammierschnittstellen (APIs) ausgetauscht werden, was die Arbeit für moderne Entwickler weit leichter macht.

Standards für die Nachricht genügen nicht; man braucht auch Standardvokabulare für den Inhalt. SNOMED CT (Systematized Nomenclature of Medicine — Clinical Terms) ist die im gesamten NHS vorgeschriebene klinische Terminologie zur Erfassung von Diagnosen, Symptomen, Eingriffen und mehr. Das NHS Dictionary of medicines and devices (dm+d) ist das Standardvokabular für Arzneimittel und Medizinprodukte und stützt die elektronische Verordnung. Die Internationale Klassifikation der Krankheiten, 10. und 11. Revision (ICD-10 und ICD-11), von der Weltgesundheitsorganisation gepflegt, dienen der Klassifikation, Statistik und Vergütung statt der alltäglichen klinischen Erfassung. openEHR ist eine offene Spezifikation, die die Gesundheitsakte selbst durch gemeinsame, klinisch gesteuerte „Archetypen“ strukturiert, und wird von manchen Organisationen genutzt, um klinische Datenmodelle von jedem einzelnen Lieferanten unabhängig zu halten.

Zwei weitere Ideen sind grundlegend. Die NHS-Nummer ist die gemeinsame Patientenkennung, die es erlaubt, Akten derselben Person organisationsübergreifend verlässlich zu verknüpfen; ohne gemeinsame Kennung ist Abgleichen Raten. Und Integrating the Healthcare Enterprise (IHE) veröffentlicht „Profile“, die genau festlegen, wie bestehende Standards zu kombinieren sind, um konkrete Probleme wie das Teilen von Dokumenten zu lösen, damit verschiedene Lieferanten sie gleich umsetzen.

Unter all dem liegt eine strategische Wahl. Das Bauen nach offenen Standards mit veröffentlichten, wiederverwendbaren APIs hält einen Markt im Wettbewerb und Ihre Daten portabel. Das Verlassen auf proprietäre Schnittstellen erzeugt Vendor Lock-in, bei dem der Lieferantenwechsel so teuer wird, dass Sie faktisch nicht wechseln können. Nichts davon liefert jedoch Wert ohne Datenqualität: genaue, vollständige, zeitnahe, konsistent kodierte Daten sind die Voraussetzung für Interoperabilität, kein Nachgedanke.

Bewährte Praktiken#

1. Unterscheiden Sie semantische von technischer Interoperabilität und gestalten Sie für beide. Es ist leicht zu feiern, dass nun eine Nachricht zwischen zwei Systemen fließt, und zu übersehen, dass sich die empfangende Klinikerin nicht sicher auf ihre Bedeutung verlassen kann. Fragen Sie stets: Interpretiert die andere Seite diese Codes, Einheiten und Negationen genau wie wir? Investieren Sie in gemeinsame Terminologien (SNOMED CT, dm+d) und Wertelisten (Value Sets), nicht nur in Nachrichtenformate, denn eine korrekt übermittelte, aber missverstandene Allergie ist gefährlicher als gar keine Nachricht.

2. Bauen Sie nach offenen Standards und verwenden Sie Plattformen wieder, statt neu zu erfinden. Übernehmen Sie das breit befürwortete Prinzip: nach offenen Standards bauen und bestehende nationale Plattformen und Services wiederverwenden, bevor Sie eigene bauen. Im NHS bedeutet das, HL7-FHIR-APIs zu bevorzugen, die NHS-Nummer als Kennung zu nutzen und sich mit nationalen Services wie der Spine, GP Connect und gemeinsamen Patientenakten zu verbinden, statt maßgeschneiderte Punkt-zu-Punkt-Verbindungen zu schaffen. Wiederverwendung senkt Kosten, verteilt die Wartungslast und bedeutet, dass Ihre Daten reisen können.

3. Machen Sie die NHS-Nummer in jeder Akte und Nachricht unverhandelbar. Verlässliche Aktenverknüpfung hängt von einer vertrauenswürdigen gemeinsamen Kennung ab. Stellen Sie sicher, dass die NHS-Nummer erfasst, gegen den nationalen Demografiedienst verifiziert und in jeder relevanten Akte und Schnittstelle mitgeführt wird. Wo sie fehlt oder unverifiziert ist, behandeln Sie das als zu behebenden Datenqualitätsmangel, denn das Abgleichen allein nach Name und Geburtsdatum erzeugt sowohl gefährliche Fehlzuordnungen als auch verpasste Verknüpfungen.

4. Behandeln Sie Datenqualität als erstklassiges Lieferergebnis. Interoperabilität exportiert Ihre Datenqualitätsprobleme an alle Nachgelagerten. Profilieren Sie Ihre Daten, messen Sie Vollständigkeit und Kodierungskonsistenz und richten Sie Stewardship ein, damit Fehler an der Quelle gefunden und behoben werden. Kodierungsdrift, Freitext, wo strukturierte Daten nötig sind, und uneinheitliche Einheiten werden jede nachgelagerte Analyse und klinische Sicht still verderben; finanzieren Sie diese Arbeit daher ausdrücklich, statt anzunehmen, sie geschehe von selbst.

5. Bevorzugen Sie API-first, lose gekoppelte Architekturen gegenüber engen Integrationen. Gestalten Sie so, dass Fähigkeiten über gut dokumentierte, versionierte APIs bereitgestellt werden, die andere ohne maßgeschneiderte Verhandlung nutzen können. Das ist anfangs langsamer als eine direkte Datenbankverbindung, aber es ist das, was Sie eine Komponente ersetzen lässt, ohne alles darum herum neu zu bauen. Es entspricht auch dem, wie nationale Services und moderne Lieferanten heute integrieren wollen, und stützt die Liefermethoden aus Thema 3.5 — Lieferlebenszyklen.

6. Nutzen Sie veröffentlichte Profile und Konformitätstests, nicht lokale Auslegungen. Standards sind flexibel, und zwei Teams können „dieselbe“ FHIR-Ressource unverträglich umsetzen. Übernehmen Sie nationale Implementierungsleitfäden und IHE-Profile, die die Details festnageln, und verlangen Sie von Lieferanten, vor dem Go-live Konformität dagegen nachzuweisen. Konformitätstests machen aus „wir unterstützen FHIR“ – einer Behauptung, die allein sehr wenig bedeutet – überprüfbare, vertragliche Tatsache.

7. Schreiben Sie Anforderungen an Interoperabilität und offene Standards in Beschaffung und Verträge. Die billigste Zeit, Lock-in zu vermeiden, ist vor der Unterschrift. Verlangen Sie offene, dokumentierte APIs, das Recht, Ihre eigenen Daten in einem Standardformat zu extrahieren, Einhaltung benannter Standards und keine Gebühren für Standardintegrationen. Arbeiten Sie mit Ihren kommerziellen Kolleginnen und Kollegen (siehe Thema 6.3 — Beschaffung und Vertragsgestaltung), damit diese zu verpflichtenden Bewertungskriterien werden, nicht zu Aspirationen, die später weggehandelt werden.

8. Steuern Sie Interoperabilität mit klinischer Sicherheit und Informationsgovernance im Raum. Jeder neue Datenfluss verändert klinisches Risiko und den Umgang mit vertraulichen Informationen. Holen Sie Clinical Safety Officers und Verantwortliche der Informationsgovernance von Anfang an in Designentscheidungen, nicht als abschließende Freigabe, damit gemeinsame Akten sowohl sicher als auch rechtmäßig sind. Das hängt direkt mit Thema 1.6 — Klinische Sicherheit und Risikomanagement und Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit zusammen.

Fragen zur Diskussion im Team#

1. Wo in unseren Versorgungspfaden schafft fehlende oder missverstandene Daten heute das größte klinische Risiko? Investitionen in Interoperabilität sollten Schaden und Wert folgen, nicht der architektonischen Mode. Kartieren Sie die Reisen, die Ihre komplexesten Patientinnen und Patienten tatsächlich nehmen, und finden Sie die Übergaben, an denen Information verloren geht, sich verzögert oder ohne verlässliche Bedeutung eintrifft. Fragen Sie Klinikpersonal, wo es routinemäßig blind arbeitet – die Verlegungen, die Lücken außerhalb der Dienstzeiten, die Grenze zwischen Gesundheit und Sozialfürsorge. Unterscheiden Sie Stellen, an denen Daten gar nicht fließen, von Stellen, an denen sie fließen, aber nicht vertrauenswürdig sind, denn diese brauchen unterschiedliche Lösungen. Überlegen Sie, welche Populationen am stärksten betroffen sind, da Fragmentierung Menschen mit dem komplexesten Bedarf tendenziell am härtesten trifft. Die Antwort sagt Ihnen, wo Sie beginnen sollen, und gibt Ihnen einen Sicherheitsfall, der mehr Gewicht tragen wird als jedes technische Argument.

2. Wie exponiert sind wir gegenüber Vendor Lock-in, und was würde es uns tatsächlich kosten, unsere wichtigsten klinischen Systeme zu wechseln? Viele Organisationen entdecken den wahren Preis eines geschlossenen Systems erst, wenn sie versuchen, es zu verlassen. Gehen Sie konkret durch, was es bräuchte, Ihre Daten in nutzbarer Standardform zu extrahieren und zu einem anderen Lieferanten zu wechseln. Prüfen Sie Ihre Verträge darauf, wem die Daten gehören, welche Standardschnittstellen existieren und ob Ihnen Integrationen berechnet werden, die Routine sein sollten. Identifizieren Sie die proprietären Schnittstellen und Datenformate, die entwirrt werden müssten. Wägen Sie das gegen die Offenheit von Alternativen und nationalen Plattformen ab, die Sie stattdessen wiederverwenden könnten. Es geht nicht um ständigen Lieferantenwechsel, sondern darum, Ihren Hebel zu verstehen und das Risiko zu senken, dass die Roadmap eines einzelnen Anbieters Ihre einzige Option wird.

3. Sind unsere Daten gut genug, um sicher geteilt zu werden, und woran würden wir es erkennen? Schlechte Daten zu teilen blamiert Sie nicht nur – es pflanzt Fehler in die Entscheidungen anderer Klinikerinnen fort. Fragen Sie, ob Sie Vollständigkeit, Genauigkeit, Zeitnähe und Kodierungskonsistenz der Daten, die Sie bereitstellen wollen, tatsächlich messen. Besprechen Sie, wer in Ihrer Organisation die Datenqualität verantwortet und ob er Zeit und Mandat hat, Probleme an der Quelle zu beheben. Überlegen Sie, welcher Anteil der Akten eine verifizierte NHS-Nummer trägt und wie viel klinisch wichtige Information noch in Freitext statt in kodierten Feldern steht. Denken Sie darüber nach, wie Sie einen systematischen Kodierungsfehler erkennen würden, bevor er eine gemeinsame Patientenakte erreicht. Können Sie diese Fragen nicht mit Evidenz beantworten, behandeln Sie das als eigenen Befund und finanzieren Sie die Datenqualitätsarbeit, bevor Sie das Rohr erweitern.

4. Wenn ein Lieferant sagt „wir unterstützen FHIR“, wie würden wir das vor dem Go-live tatsächlich verifizieren? Ein Standard-Etikett ist eine Marketingbehauptung, bis es gegen einen bestimmten Implementierungsleitfaden getestet wurde. Besprechen Sie, ob Ihre Organisation überhaupt eine eigene Fähigkeit zum Konformitätstesten hat oder Lieferanten einfach aufs Wort glaubt. Zwei Systeme können jeweils „FHIR-konform“ sein und dennoch keine nutzbare Nachricht austauschen können, weil der Standard bewusst flexibel ist und die Bedeutung in den Profilen und Wertelisten lebt, die ihn festnageln. Fragen Sie, welche nationalen Implementierungsleitfäden und IHE-Profile für die betreffende Schnittstelle gelten und wer auf Ihrer Seite kompetent ist, sie zu lesen. Überlegen Sie, ob Konformität als Bedingung des Anschlusses in den Vertrag geschrieben oder schmerzhaft während der Integration entdeckt wird. Eine ehrliche Antwort benennt das konkrete Profil, gegen das Sie testen würden, die Person oder Funktion, die den Test durchführte, und den Punkt im Zeitplan, an dem ein durchfallender Lieferant abgewiesen statt durchgewunken wird.

5. Wer verantwortet Standards, Terminologie und Konformität in unserer Organisation, und hat er das Mandat, Nein zu sagen? Interoperabilität verfällt ohne Stewardship: Wertelisten driften, lokale Leitfäden divergieren, und jedes neue Projekt erfindet still seine eigene Auslegung. Fragen Sie, ob es eine benannte Funktion gibt, die für Standards, SNOMED-CT- und dm+d-Teilmengen und Konformität verantwortlich ist, oder ob dieses Wissen in den Köpfen weniger Einzelner sitzt. Bedenken Sie die Spannung zwischen zentraler Konsistenz und lokaler Liefergeschwindigkeit – Teams unter Druck bauen das Schnellste, sofern eine Standardfunktion keine echte Befugnis hat, Wiederverwendung zu verlangen. Besprechen Sie, wie Terminologiepflege finanziert wird, da sie unglamourös, kontinuierlich ist und allen statt einem einzelnen Projekt nützt. Schauen Sie, wie Sie Umsetzungen im Gleichschritt halten, während sich FHIR, SNOMED CT und nationale Leitfäden weiterentwickeln, statt bei der zuerst übernommenen Version einzufrieren. Eine ehrliche Antwort benennt die rechenschaftspflichtige Verantwortliche, ihre Finanzierung und ein jüngeres Beispiel, in dem sie einen Standard entweder durchsetzte oder daran scheiterte.

6. Sind die Menschen, deren Akten wir zusammenführen, informiert und einverstanden damit, wie ihre Daten fließen? Interoperabilität ist nicht nur eine technische und klinische Angelegenheit, sondern eine Frage des öffentlichen Vertrauens und der Rechtsgrundlage. Menschen nehmen vernünftigerweise an, dass der NHS ihre Informationen bereits sinnvoll teilt, und sind bestürzt, wenn er es nicht tut und wenn er es auf Weisen tut, die sie nicht erwarteten. Besprechen Sie, ob Patientinnen und Patienten verstehen, welche Organisationen ihre gemeinsame Akte sehen können, wie ein National Data Opt-out oder ein lokales Einwilligungsmodell über den Fluss hinweg beachtet wird und wie Zugriff erfasst und prüfbar ist. Bedenken Sie die Gerechtigkeitsdimension: Die Menschen, deren Daten am stärksten fragmentiert sind – jene mit komplexem Bedarf –, sind auch jene, die am wenigsten in der Lage sind, Opt-outs und Informationshinweise zu navigieren. Holen Sie Informationsgovernance und, wo relevant, Patientinnen und Patienten oder ihre Vertretungen in das Design, statt Einwilligung als am Ende abgehaktes Kästchen zu behandeln. Eine ehrliche Antwort kann die Rechtsgrundlage jedes Flusses beschreiben, wie ein Mensch herausfinden würde, wer seine Akte gesehen hat, und wie seine Entscheidungen durchgängig respektiert werden.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein Integrated Care System im Norden Englands macht sich daran, Klinikpersonal eine einzige Sicht auf gemeinsame Medikation über Hausarztpraxis, Krankenhaus und Gemeindeapotheke zu geben, nachdem eine Überprüfung eines ernsten Vorfalls ergab, dass eine Patientin von Teams, die die Akten der anderen nicht sehen konnten, zwei wechselwirkende Medikamente verordnet bekommen hatte.

Die Versuchung ist, ein „Medikations-Dashboard“ von einem Lieferanten zu kaufen und es direkt in die Datenbank jedes Systems zu verdrahten. Der Interoperabilitätsleiter widersteht dem. Stattdessen übernimmt das Programm einen Ansatz „nach offenen Standards bauen“. Jedes Quellsystem stellt Medikationsdaten als HL7-FHIR-Ressourcen bereit; jedes Arzneimittel wird mit dem dm+d kodiert, damit „dasselbe Arzneimittel“ überall dasselbe bedeutet; und jede Akte ist auf eine verifizierte NHS-Nummer geschlüsselt, damit die richtigen Medikamente an der richtigen Person hängen. Hausarztdaten werden über GP Connect statt über einen maßgeschneiderten Feed bezogen und nutzen so eine nationale Fähigkeit wieder, statt eine lokale zu erfinden.

Frühes Datenprofiling bewährt sich sofort. Das System einer Praxis hat bestimmte Medikamente als Freitext statt als kodierte dm+d-Einträge erfasst, wodurch sie für jede automatisierte Wechselwirkungsprüfung unsichtbar gewesen wären. Das wird vor dem Go-live an der Quelle behoben. Das Team findet auch eine Häufung von Akten mit unverifizierten NHS-Nummern und leitet sie zum Abgleich durch den nationalen Demografiedienst.

Die Clinical Safety Officer und der Verantwortliche der Informationsgovernance gehören durchgehend zur Designgruppe. Gemeinsam definieren sie genau, welche Daten mit wem, auf welcher Rechtsgrundlage geteilt und wie der Zugriff einer Klinikerin erfasst wird – die Anliegen von Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit. Lieferanten müssen vor dem Anschluss Konformitätstests gegen den nationalen FHIR-Implementierungsleitfaden bestehen. Zwölf Monate später ist die verzahnte Medikationssicht live, eine Wechselwirkung, die früher übersehen worden wäre, wurde bereits gefangen, und – weil alles auf offenen Schnittstellen gebaut wurde – nutzt ein zweiter Anwendungsfall, gemeinsame Allergieinformationen, den größten Teil derselben Infrastruktur zu einem Bruchteil der ursprünglichen Kosten wieder.

Sektorperspektiven#

Startup#

Ein Startup der digitalen Gesundheit steht und fällt damit, wie leicht es sich in bestehende Systeme einstecken lässt; behandeln Sie Interoperabilität daher als Kernfunktion, nicht als Compliance-Pflicht. FHIR-APIs zu bauen und SNOMED CT sowie dm+d von Anfang an zu nutzen macht Sie weit leichter kaufbar und integrierbar und signalisiert vorsichtigen NHS-Käufern Reife. Widerstehen Sie dem Drang, ein eigenes Datenmodell zu erfinden, wenn ein Standard existiert; Ihre Differenzierung sollte Ihr Produkt sein, nicht ein proprietäres Format, das zur Haftung wird. Den Umgang mit der NHS-Nummer und die Informationsgovernance früh richtig zu machen ist es, was Sie vom Pilot in die Beschaffung bringt. Gestalten Sie so, dass ein Kunde im Prinzip seine Daten extrahieren und gehen könnte – paradoxerweise verdient gerade diese Offenheit das Vertrauen, ihn zu halten.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim oder eine Einzelstandort-Klinik – trägt dieselben Pflichten, Daten sicher zu teilen, wie der größte Trust, aber mit einem Bruchteil der technischen Fähigkeit. Interoperabilität ist hier überwiegend eine Disziplin von Beschaffung und Konfiguration statt des Engineerings: Wählen Sie Systeme, die bereits FHIR sprechen, sich mit nationalen Services wie GP Connect und der Spine verbinden und out of the box mit SNOMED CT und dm+d kodieren, sodass Sie Standards erben, statt sie zu bauen. Machen Sie die Erfassung verifizierter NHS-Nummern zum Teil der täglichen Praxis, denn ohne Integrationsteam, das später Fehlzuordnungen abgleicht, ist die richtige Kennung bei der Registrierung Ihr billigster Schutz. Stützen Sie sich auf Programme gemeinsamer Patientenakten und die gemeinsame Infrastruktur Ihres Integrated Care Systems, statt maßgeschneiderte Verbindungen zu beauftragen, die Sie nicht warten können. Wenn Sie einen Systemvertrag unterschreiben oder verlängern, bestehen Sie in klaren Worten auf Datenextraktionsrechten und offenen Schnittstellen, denn eine kleine Organisation spürt Vendor Lock-in am schärfsten und hat den geringsten Hebel, ihm hinterher zu entkommen.

Großunternehmen#

Ein großer Anbieter oder Lieferant trägt typischerweise Jahrzehnte an Altlasten: HL7-v2-Schnittstellen, mehrere elektronische Aktensysteme und Integrations-Engines, die alles zusammenhalten. Die realistische Strategie ist nicht, alles herauszureißen, sondern eine API-first-, standardbasierte Schicht vor die Landschaft zu legen, Flüsse schrittweise zu FHIR zu migrieren und v2 dort weiterlaufen zu lassen, wo es muss. Hüten Sie sich bei jeder Verlängerung entschieden vor Lock-in und bestehen Sie auf Konformitätstests, damit „standardkonform“ verifiziert statt behauptet ist. Etablieren Sie eine interne Funktion für Standards und Konformität, damit einzelne Projekte nicht je ihre eigene Auslegung erfinden. Das hängt eng damit zusammen, wie Sie zentrale operative Plattformen in Thema 5.4 — Enterprise Resource Planning (ERP) steuern, wo dieselbe Disziplin aus Wiederverwendung und offenen Schnittstellen gilt.

Regierung#

Nationale und regionale Stellen setzen die Regeln des Marktes, sodass ihre Wahlen zu Standards durch jede Organisation wirken. Das Wertvollste, was die Regierung tun kann, ist, offene Standards vorzuschreiben, klare Implementierungsleitfäden und Konformitätsanforderungen zu veröffentlichen und wiederverwendbare nationale Plattformen bereitzustellen – die Spine, GP Connect, Rahmen für gemeinsame Patientenakten, den NHS-Nummer-Dienst –, damit lokale Organisationen einmal bauen und wiederverwenden. Konsistenz zählt mehr als Perfektion: Ein fest durchgesetzter, gut genug Standard schlägt einen theoretisch überlegenen, den alle unterschiedlich umsetzen. Die Regierung muss auch die unglamouröse Arbeit von Terminologiepflege und Datenqualitätsverbesserung finanzieren, denn dies sind öffentliche Güter, die keine einzelne Organisation allein finanziert. Diese Verwalterrolle hängt mit Thema 9.1 — Zusammenarbeit mit lokalen und nationalen Regierungen und damit zusammen, wie Partner in Thema 9.0 — Zusammenarbeit mit Partnerorganisationen kooperieren.

Häufige Fehlermuster#

• Technische Verbindung mit semantischem Verstehen verwechseln. Den Sieg erklären, wenn eine Nachricht fließt, ohne zu bestätigen, dass beide Seiten ihre Codes, Einheiten und Negationen identisch interpretieren. Das Ergebnis sind Daten, die integriert aussehen, aber still falsch gelesen werden.
• Schlechte Daten schneller teilen. Das Rohr erweitern, bevor die Datenqualität behoben ist, sodass Kodierungsfehler, Freitext und fehlende NHS-Nummern in die Entscheidungen anderer Klinikerinnen und jede nachgelagerte Analyse fortgepflanzt werden.
• „Wir unterstützen FHIR“ als leere Behauptung. Ein Standard-Etikett ohne Konformitätstest gegen einen bestimmten Implementierungsleitfaden akzeptieren, sodass zwei „konforme“ Systeme dennoch nicht miteinander sprechen können.
• Maßgeschneiderte Punkt-zu-Punkt-Integrationen. Direkte Verbindungen zwischen jedem Paar von Systemen bauen und ein brüchiges Geflecht erzeugen, das mit dem Wachstum exponentiell schwerer und teurer zu warten wird.
• Lock-in per Voreinstellung. Verträge mit proprietären Schnittstellen und ohne Datenextraktionsrechte unterzeichnen und die Kosten der Falle erst entdecken, wenn man den Lieferanten wechseln will.
• Governance als abschließendes Tor behandeln. Klinische Sicherheit und Informationsgovernance nur zur Freigabe einbeziehen, sodass Probleme spät und teuer auftauchen oder unter Lieferdruck durchgewinkt werden.
• Standards ohne Stewardship. Terminologien und Profile übernehmen, aber niemanden finanzieren, der Wertelisten pflegt, Konformität überwacht oder Umsetzungen im Gleichschritt hält, während sich Standards weiterentwickeln.

Reifegradmodell#

Checkliste#

• Jede relevante Akte und Schnittstelle trägt eine verifizierte NHS-Nummer, mit einem Prozess, fehlende oder nicht abgeglichene zu klären.
• Neue Schnittstellen nutzen HL7 FHIR und benannte nationale Implementierungsleitfäden, mit HL7 v2 nur dort beibehalten, wo Migration noch nicht gerechtfertigt ist.
• Klinischer Inhalt wird mit SNOMED CT kodiert und Arzneimittel mit dm+d, gegen vereinbarte Wertelisten.
• Die Datenqualität von allem, was Sie teilen wollen, ist profiliert, gemessen, verantwortet und an der Quelle verbessert, bevor das Rohr erweitert wird.
• Lieferanten müssen vor dem Anschluss Konformitätstests gegen ein bestimmtes Profil bestehen – „unterstützt FHIR“ wird nie allein akzeptiert.
• Nationale Plattformen (Spine, GP Connect, gemeinsame Patientenakten) werden wiederverwendet, bevor irgendeine maßgeschneiderte Integration gebaut wird.
• Verträge schreiben offene, dokumentierte APIs, Datenextraktionsrechte in einem Standardformat und keine Gebühren für Standardintegrationen vor.
• Verantwortliche für klinische Sicherheit und Informationsgovernance sind von Anfang an in der Designgruppe, nicht nur bei der Freigabe.
• Die Architektur ist API-first und lose gekoppelt, sodass eine Komponente ersetzt werden kann, ohne alles darum herum neu zu bauen.
• Eine benannte Funktion verantwortet Standards, Konformität und Terminologiepflege in der Organisation.

Zentrale Quellen#

• NHS England — Interoperabilitätsstandards, die Spine, GP Connect und Programme gemeinsamer Patientenakten.
• HL7 International — der FHIR-Standard und die HL7-v2-Spezifikationen.
• SNOMED International — SNOMED-CT-Terminologie und Umsetzungsleitlinien.
• NHS Business Services Authority — das Dictionary of medicines and devices (dm+d).
• Integrating the Healthcare Enterprise (IHE) — Interoperabilitätsprofile.
• openEHR International — offene Spezifikationen zur Strukturierung der Gesundheitsakte.
• Weltgesundheitsorganisation — die Internationale Klassifikation der Krankheiten (ICD-10 und ICD-11).

Referenzen#

1. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
2. Semantic interoperability — Wikipedia — https://en.wikipedia.org/wiki/Semantic_interoperability
3. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
4. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
5. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
6. ICD-11 — Wikipedia — https://en.wikipedia.org/wiki/ICD-11
7. ICD-10 — Wikipedia — https://en.wikipedia.org/wiki/ICD-10
8. openEHR — Wikipedia — https://en.wikipedia.org/wiki/OpenEHR
9. NHS number — Wikipedia — https://en.wikipedia.org/wiki/NHS_number
10. Integrating the Healthcare Enterprise — Wikipedia — https://en.wikipedia.org/wiki/Integrating_the_Healthcare_Enterprise
11. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. API — Wikipedia — https://en.wikipedia.org/wiki/API
14. Data quality — Wikipedia — https://en.wikipedia.org/wiki/Data_quality
15. FHIR standard — HL7 International — https://www.hl7.org/fhir/
16. SNOMED CT — SNOMED International — https://www.snomed.org/
17. Dictionary of medicines and devices (dm+d) — NHS Business Services Authority — https://www.nhsbsa.nhs.uk/pharmacies-gp-practices-and-appliance-contractors/dictionary-medicines-and-devices-dmd
18. GP Connect — NHS England Digital — https://digital.nhs.uk/services/gp-connect
19. Spine — NHS England Digital — https://digital.nhs.uk/services/spine
20. International Classification of Diseases (ICD) — World Health Organization — https://www.who.int/standards/classifications/classification-of-diseases