Thema 4.6 — Elektronische Patientenakten und klinische Systeme

Die elektronische Patientenakte ist das operative Rückgrat eines modernen Krankenhauses; wie Sie sie auswählen, konfigurieren, einführen und fortlaufend optimieren, ist daher eine Entscheidung zu klinischer Sicherheit, Personalproduktivität und öffentlichem Geld, die die Versorgung ein Jahrzehnt prägen wird – keine einmalige IT-Beschaffung.

Warum das in Gesundheit und Pflege wichtig ist#

Die elektronische Patientenakte (Electronic Patient Record, EPR) ist das einzige System, durch das inzwischen der größte Teil der klinischen Arbeit fließt. Ärztinnen, Ärzte und Pflegekräfte lesen sie, um zu wissen, was einer Patientin fehlt, fordern die Tests und Medikamente an, die den Verlauf der Patientin verändern, und dokumentieren die Entscheidungen, auf die sich andere Stunden oder Jahre später verlassen werden. Wenn die EPR gut ist, macht sie das Sichere zum Leichten: die richtige Dosis, die richtige Allergiewarnung, die Ergebnisse vor der Person, die sie braucht. Wenn sie schlecht ist, begräbt sie Klinikpersonal unter Klicks, versteckt das Signal im Rauschen und formt still das klinische Verhalten auf Weisen um, die niemand beabsichtigte.

Deshalb ist ein EPR-Programm anders als fast jedes andere Technologieprojekt, das Sie führen werden. Es berührt jede Klinikerin, jede Schicht, jede Patientin, und zwar genau im Moment der Versorgung. Ein schlecht konfiguriertes Order-Set kann einen Dosierungsfehler über ein ganzes Krankenhaus fortpflanzen; ein verpatzter Go-live kann monatelang jede Konsultation verlängern; eine Datenmigration, die Allergien oder den Reanimationsstatus verliert, kann jemanden töten. Die Akte ist zudem ein rechtliches und regulatorisches Artefakt – die medizinrechtliche Darstellung dessen, was getan wurde und warum –, sodass ihre Integrität, Verfügbarkeit und Prüfbarkeit gesetzliches Gewicht tragen (siehe Thema 1.6 — Klinische Sicherheit und Risikomanagement und Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit).

Der Einsatz ist auch finanziell und strategisch. Eine EPR gehört zu den größten Einzelinvestitionen, die ein Trust je tätigt, über ihr Leben oft zig Millionen Pfund, und sie bindet die Organisation über viele Jahre an einen Lieferanten und eine Arbeitsweise. National hat das Frontline-Digitisation-Programm von NHS England eine Kern-EPR zur Grunderwartung für jeden Akut-, Gemeinde-, Psychiatrie- und Rettungsdienstanbieter gemacht und Kapitalfinanzierung an digitale Reife gekoppelt. Die EPR richtig zu machen ist inzwischen untrennbar davon, das Betriebsmodell richtig zu machen (siehe Thema 1.1 — Das Betriebsmodell). Sie falsch zu machen verschwendet öffentliches Geld, erschöpft Klinikpersonal und kann eine Organisation Jahre zurückwerfen.

Kernkonzepte#

Eine elektronische Gesundheitsakte (Electronic Health Record, EHR) ist die systematisierte, digitale Sammlung der Gesundheitsinformationen einer Patientin. In der britischen Praxis bezeichnet das Beinahe-Synonym elektronische Patientenakte (EPR) meist das klinische Kernsystem einer Anbieterorganisation – die Akte und das Werkzeug, das Klinikpersonal am Behandlungsort nutzt. Darum herum sitzt eine Familie klinischer Systeme, historisch als Krankenhausinformationssystem (Hospital Information System, HIS) beschrieben: das Patientenverwaltungssystem (Patient Administration System, PAS), das Aufnahmen, Entlassungen, Verlegungen und ambulante Termine verfolgt; klinische Dokumentation; Ergebnisberichte; und Spezialsysteme für OP, Mutterschaft, Notaufnahme und Intensivversorgung.

Computerized Physician Order Entry (CPOE, auch Auftragskommunikation oder „Order Comms“ genannt) ist die elektronische Eingabe klinischer Aufträge – Tests, Medikamente, Überweisungen – direkt durch die anfordernde Klinikerin, die Papier und Telefonate ersetzt. Dort wird ein großer Teil des Sicherheitswerts einer EPR realisiert, weil Aufträge geprüft, in Order-Sets standardisiert und automatisch geleitet werden können. CPOE ist eng gekoppelt an die elektronische Verordnung und an klinische Entscheidungsunterstützung, die Warnungen und Anleitung im Arbeitsablauf zeigt (behandelt in Thema 4.7 — Klinische Entscheidungsunterstützung und klinische Informatik und Thema 4.8 — Elektronische Verordnung und Arzneimittelmanagement).

Zwei Designentscheidungen bestimmen ein EPR-Programm. Die erste ist Konfiguration versus Anpassung (Customization): Konfiguration schneidet das Produkt mit den Hebeln zu, die der Hersteller unterstützt (Bildschirme, Order-Sets, Rollen, Regeln bauen), und bleibt innerhalb des unterstützten Upgrade-Pfads, während Anpassung maßgeschneiderten Code oder Strukturen schreibt, die der Hersteller nicht vorsah, was mächtig ist, aber bei jedem Upgrade zur Wartungs- und Sicherheitsverbindlichkeit wird. Die zweite ist die Einführungsform: Big-Bang-Einführung (direkter Umstieg, bei dem die ganze Organisation an einem Datum umschaltet) versus ein phasenweiser oder modularer Rollout, der Standorte oder Funktionen nacheinander live bringt. Jede Form tauscht Risikokonzentration gegen Integrationskomplexität und „Big-Bang-Müdigkeit“.

Das Programm wird ebenso von Klinikpersonal wie von Technikern geführt. Der Chief Medical Informatics Officer (CMIO, im Vereinigten Königreich meist Chief Clinical Information Officer, CCIO) und der Chief Nursing Information Officer (CNIO) sind leitende Klinikerinnen und Kliniker, die klinisches Design, Sicherheit und Annahme des Systems verantworten – die Brücke zwischen der Front und dem Bau. Ihre Disziplin ist die Gesundheitsinformatik: Informations- und Computerwissenschaft anzuwenden, um Management und Nutzung klinischer Informationen zu verbessern.

Mehrere Konzepte auf Systemebene kehren wieder. Datenmigration ist die einmalige Übertragung historischer Akten aus Altsystemen in die neue EPR – technisch Routine, klinisch heikel. Eine Integrations-Engine (Schnittstellen-Engine) leitet Nachrichten zwischen Systemen mit Standards wie Health Level Seven (HL7) und FHIR (siehe Thema 4.3 — Interoperabilität und Datenstandards). Ein Health Information Exchange oder eine gemeinsame Patientenakte lässt Organisationen eines Gebiets die Akten der anderen lesen. Und weil die Akte sicherheitskritisch ist, sind Ausfallverfahren (Downtime Procedures) – die Business-Continuity-Pläne für den Fall, dass die EPR nicht verfügbar ist – ein Kernbestandteil des Systems, kein Nachgedanke (siehe Thema 3.9 — Business Continuity und Disaster Recovery). Digitale Reife wird gemeinhin mit dem Electronic Medical Record Adoption Model (EMRAM) der Healthcare Information and Management Systems Society (HIMSS) verglichen, einer Skala von 0–7 der Fähigkeit klinischer Systeme.

Bewährte Praktiken#

1. Machen Sie klinische Führung zum Rückgrat des Programms, nicht zur Konsultierten. Eine EPR gelingt oder scheitert daran, ob Klinikpersonal sie besitzt. Ernennen und statten Sie einen CCIO und eine CNIO mit echter Befugnis und geschützter Zeit aus, bauen Sie ein Netz klinischer „digitaler Champions“ in jeder Fachrichtung und auf jeder Station auf und geben Sie der klinischen Designführung echte Entscheidungsrechte über Bau und Konfiguration. Das Muster, das scheitert, ist ein technisch geführtes Programm, das Klinikpersonal durch gelegentliche Workshops „einbindet“; das Muster, das funktioniert, behandelt praktizierende Klinikerinnen als Mitautoren des Systems, das sie jede Schicht nutzen werden.

2. Konfigurieren Sie das unterstützte Produkt; passen Sie nur mit offenen Augen an. Jede maßgeschneiderte Anpassung ist eine Schuld, die Sie bei jedem Upgrade zurückzahlen, und eine verborgene Sicherheitsfläche, die niemand neu testet. Konfigurieren Sie standardmäßig innerhalb des unterstützten Modells des Herstellers, übernehmen Sie die getesteten Inhalte und Order-Sets des Produkts, wo sie sicher sind, und reservieren Sie echte Anpassung für die wenigen Stellen, an denen ein echter klinischer oder gesetzlicher Bedarf anders nicht erfüllt werden kann – jede dokumentiert, risikobewertet und verantwortet. Widerstehen Sie dem Drang, Ihr altes System in dem neuen nachzubauen; „mach, dass es wie das Papierformular funktioniert“ ist, wie Organisationen eine moderne EPR bezahlen und ihre Altlasten erben.

3. Wählen Sie die Einführungsform bewusst und entschärfen Sie, welche Sie auch wählen. Big Bang konzentriert das Risiko auf ein Datum, vermeidet aber den Schmerz und die Kosten, zwei Systeme parallel zu betreiben und zu integrieren; ein phasenweiser oder modularer Rollout verteilt Risiko und lässt Sie lernen, vervielfacht aber Schnittstellen, Doppelbetrieb und Veränderungsmüdigkeit. Entscheiden Sie nach Ihrer Risikobereitschaft, der Integrationskomplexität und danach, wie viel klinische Störung die Organisation auf einmal absorbieren kann (siehe Thema 8.0 — Innovation phasenweise einführen). Welche Sie auch wählen, investieren Sie überproportional in den Umstieg: geprobte Probeläufe, eine Einsatzzentrale, massive Unterstützung durch Personal auf den Stationen in den ersten Wochen und eine klare, geübte Rückfallposition.

4. Behandeln Sie Datenmigration als Übung der klinischen Sicherheit, nicht als Datenverrohrung. Zu entscheiden, welche Historie in die neue Akte wandert – und zu verifizieren, dass sie korrekt ankam –, ist der Punkt, an dem Migrationen Patientinnen und Patienten schaden, durch verlorene Allergien, nicht passende Kennungen oder abgeschnittene Medikationshistorien. Vereinbaren Sie ausdrücklich, was automatisch migriert, was zusammengefasst und was in einem schreibgeschützten Archiv des Altsystems belassen wird und wie Klinikpersonal es erreicht; gleichen Sie dann migrierte Daten mit klinischer Freigabe vor dem Go-live ab und validieren Sie sie. Nehmen Sie nie an, ein Feld sei sauber zugeordnet, nur weil der Ladelauf fehlerfrei lief – eine technisch erfolgreiche Migration kann dennoch klinisch falsch sein (siehe Thema 4.9 — Datenqualität und Stammdatenmanagement).

5. Planen Sie den Produktivitätseinbruch und finanzieren Sie die Optimierung, die ihm folgt. Fast jedem EPR-Go-live folgt eine Phase verringerten Durchsatzes, während Personal das System lernt, und Organisationen, die etwas anderes vorgeben, schaden sowohl der Sicherheit als auch der Moral. Verringern Sie elektive Aktivität rund um den Go-live bewusst, schützen Sie Schulungszeit und setzen Sie mit dem Vorstand realistische Erholungsverläufe fest, damit der Einbruch ein geplantes Ereignis ist, keine Krise (siehe Thema 8.1 — Veränderungsmanagement). Entscheidend ist, dass Sie danach fortlaufende Optimierung budgetieren und besetzen: Der Wert einer EPR wird in den Jahren nach dem Go-live realisiert, durch iteratives Feinjustieren von Arbeitsabläufen, Order-Sets und Alarmen – eine Produktdisziplin, kein Projekt, das beim Umstieg endet (siehe Thema 5.0 — Produktgeführte Arbeit).

6. Gestalten Sie Order-Sets, Alarme und Arbeitsabläufe so, dass sie Belastung verringern, und steuern Sie sie kontinuierlich. Im klinischen Bau spart eine EPR entweder kognitive Last oder fügt sie hinzu. Standardisieren Sie Order-Sets um gute Evidenz, stimmen Sie Alarme der Entscheidungsunterstützung so ab, dass Klinikpersonal die wenigen sieht, die zählen, statt in wertarmen Pop-ups zu ertrinken, und messen Sie Dokumentationsbelastung als erstklassiges Ergebnis. Richten Sie eine ständige Governance-Gruppe der klinischen Informatik ein, die den Bau über die Zeit verantwortet, Alarmauslösungs- und Übersteuerungsraten überprüft und Inhalt stilllegt, der sich seinen Platz nicht mehr verdient (siehe Thema 4.7 — Klinische Entscheidungsunterstützung und klinische Informatik).

7. Bauen Sie Ausfallzeit und Business Continuity von Anfang an in die Akte ein. Die EPR wird eines Tages nicht verfügbar sein – durch ein gescheitertes Upgrade, einen Netzwerkausfall oder einen Ransomware-Angriff –, und ein Krankenhaus, das in diesen Stunden nicht auf Papier funktionieren kann, ist ein Patientensicherheitsvorfall, der darauf wartet zu geschehen. Bieten Sie während Ausfällen schreibgeschützten Zugriff auf eine aktuelle Kopie der Akte, pflegen Sie geprobte papierbasierte klinische Arbeitsabläufe und üben Sie geplante wie ungeplante Ausfälle, damit Personal nicht unter Druck improvisiert. Vereinbaren Sie Recovery-Time- und Recovery-Point-Ziele für die klinische Akte ausdrücklich und testen Sie den Abgleich der Papierakten zurück ins System nach der Wiederherstellung (siehe Thema 3.9 — Business Continuity und Disaster Recovery).

8. Realisieren Sie Nutzen bewusst und messen Sie die versprochenen Ergebnisse. Ein EPR-Business-Case ruht auf Nutzen für Sicherheit, Qualität und Effizienz, die nicht automatisch erscheinen; sie müssen eingeplant, verantwortet und verfolgt werden. Legen Sie die Baseline der Kennzahlen vor dem Go-live fest, binden Sie jeden Nutzen an eine benannte Verantwortliche und eine Arbeitsablaufänderung und überprüfen Sie die Realisierung in definierten Abständen gegen den Fall, statt beim Umstieg den Sieg zu erklären (siehe Thema 6.2 — Nutzenrealisierung und Wertmanagement). Nutzen Sie einen anerkannten Reifegrad-Benchmark wie HIMSS EMRAM, um dem Vorstand ein externes, vergleichbares Maß für Fortschritt zu geben statt nur interner Anekdoten.

9. Steuern Sie Konvergenz und Interoperabilität als System, nicht nur als Trust-Programm. Über ein Integrated Care System (ICS) hinweg zieht die strategische Richtung zu weniger EPR-Instanzen und einer gemeinsamen Patientenakte, damit die Informationen einer Patientin ihr zwischen Organisationen folgen. Die Konvergenz auf eine gemeinsame EPR kann Kosten senken und den Patientenfluss glätten, konzentriert aber Risiko und verwässert lokale Kontrolle; wägen Sie sie daher gegen starke Interoperabilität zwischen eigenständigen Systemen ab (siehe Thema 4.3 — Interoperabilität und Datenstandards). Welche Form auch immer, bestehen Sie auf offenen Standards und einer realistischen Ausstiegsstrategie, um Vendor Lock-in zu begrenzen, denn eine EPR, aus der Sie Ihre Daten nicht herausbekommen, ist eine EPR, die Ihnen gehört (siehe Thema 6.3 — Beschaffung und Vertragsgestaltung).

Fragen zur Diskussion im Team#

1. Wer verantwortet das klinische Design unserer EPR wirklich – und haben sie die Befugnis, Zeit und Glaubwürdigkeit, harte Entscheidungen zu treffen, die die Front akzeptieren wird? Das ist wichtig, weil der stärkste einzelne Prädiktor für EPR-Erfolg echte klinische Verantwortung ist und das häufigste Versagen ein Programm, das technisch kompetent, aber klinisch hohl ist. Debattieren Sie, ob Ihr CCIO und Ihre CNIO geschützte Sitzungen, ein echtes Budget und Entscheidungsrechte haben oder respektierte Aushängeschilder sind, die von Lieferterminen und Herstellervoreinstellungen überstimmt werden. Bringen Sie die Spannung zwischen klinischer Variation und Standardisierung ans Licht: Jede Fachrichtung will ihren eigenen Bau, doch tausend lokale Varianten werden unwartbar und unsicher. Überlegen Sie, wie Streitigkeiten heute tatsächlich gelöst werden – durch klinischen Konsens, durch die lauteste Stimme oder durch den, der den Zeitplan kontrolliert. Schauen Sie, ob Champions an der Front in jedem Bereich existieren oder nur auf dem Papier. Eine gute, ehrliche Antwort benennt die rechenschaftspflichtigen klinischen Verantwortlichen, räumt ein, wo die Befugnis derzeit zu dünn ist, und beschreibt einen Governance-Weg, auf dem klinische Designentscheidungen von Klinikpersonal getroffen werden und halten.

2. Was wird uns der Produktivitätseinbruch tatsächlich kosten, und hat der Vorstand ihm mit offenen Augen zugestimmt? Fast jeder Go-live bremst die Organisation, bevor er sie beschleunigt, doch Business Cases und Vorstände nehmen routinemäßig eine glatte Kurve an und setzen das Programm so dazu auf, genau dann als gescheitert beurteilt zu werden, wenn es sich normal verhält. Besprechen Sie, wie weit Sie elektive Aktivität rund um den Go-live bewusst verringern, wie lange die Erholung für Ihre Fachrichtungsmischung realistisch dauert und was Sie Aufsichten und Patientinnen und Patienten über Wartezeiten in diesem Fenster sagen werden. Wägen Sie den Zielkonflikt zwischen einem kürzeren, schärferen Einbruch mit starker Vorabunterstützung und einem sanfteren, längeren ab – und wer das operative und finanzielle Risiko jedes trägt. Prüfen Sie, ob Schulungsstunden wirklich geschützt oder das Erste sind, das geopfert wird, wenn der Dienstplan eng ist. Überlegen Sie, welche Frühindikatoren Ihnen sagen würden, dass der Einbruch tiefer oder länger als geplant ist, und was Ihre Reaktion wäre. Eine gute Antwort nennt einen geplanten, finanzierten, vom Vorstand gebilligten Einbruch mit Erholungsverläufen, nicht die Hoffnung, dass Klinikpersonal ihn einfach aufnimmt.

3. Wenn die EPR ausfällt, können wir noch ein sicheres Krankenhaus betreiben – und wann haben wir es zuletzt bewiesen? Die Akte ist inzwischen so zentral, dass ihre Nichtverfügbarkeit ein klinischer Notfall ist, doch Ausfallverfahren sind oft der am wenigsten geprobte Teil des ganzen Programms. Besprechen Sie, welche klinischen Funktionen zu verlieren am gefährlichsten wären, ob Personal während eines Ausfalls tatsächlich eine aktuelle schreibgeschützte Kopie der Akte erreichen kann und ob die Papier-Rückfallabläufe existieren und geübt werden oder verstaubte Ordner sind, die niemand geöffnet hat. Bringen Sie das härteste Szenario ans Licht – einen langanhaltenden, ungeplanten Ausfall wie einen tagelangen Cyberangriff, nicht das ordentliche geplante Upgrade-Fenster – und ob Ihre Recovery-Time- und Recovery-Point-Ziele für die klinische Akte vereinbart und getestet sind. Bedenken Sie das Abgleichsproblem: wie während des Ausfalls erstellte Papierakten danach sicher in das System zurückkommen, ohne Information zu verlieren oder zu duplizieren. Eine gute Antwort verweist auf jüngere, realistische Ausfallübungen, benannte Ziele für die Akte und Personal, das weiß, was zu tun ist, statt auf einen Plan, der nur je auf dem Papier existierte.

4. Wo ziehen wir die Linie zwischen dem Konfigurieren des unterstützten Produkts und dem Bauen von etwas Eigenem, und wer ist für jede Ausnahme rechenschaftspflichtig? Jede maßgeschneiderte Anpassung fühlt sich im Moment gerechtfertigt an – eine starke Präferenz einer Klinikerin, ein Arbeitsablauf, den das alte System unterstützte, ein Bericht, auf dem jemand besteht –, doch jede ist eine bei jedem Upgrade zurückgezahlte Schuld und eine Sicherheitsfläche, die niemand neu testet. Besprechen Sie, ob Sie ein erklärtes Prinzip „auf das Unterstützte konfigurieren“ haben oder Anpassungsentscheidungen ad hoc, Modul für Modul, unter Lieferdruck fallen. Bringen Sie die echte Spannung ans Licht: Die getesteten Inhalte des Herstellers zu übernehmen ist sicherer und billiger zu warten, zwingt aber Klinikpersonal, seine Arbeitsweise zu ändern, und „das Produkt tut es nicht auf unsere Art“ ist eine mächtige Lobby. Prüfen Sie, wer eine Ausnahme freigibt, ob jede dokumentiert und risikobewertet ist und ob je jemand die bereits getragenen Anpassungen erneut betrachtet und stilllegt. Bedenken Sie, wie sich das über ein Jahrzehnt aufsummiert und wie es Ihre Fähigkeit prägt, künftige Upgrades sauber zu übernehmen. Eine gute, ehrliche Antwort beschreibt einen expliziten Standard, einen benannten Weg, Ausnahmen zu genehmigen und zu verantworten, und eine realistische Darstellung, wie viel maßgeschneiderten Bau Sie bereits zu warten verpflichtet sind.

5. Wer verbessert die EPR nach dem Go-live weiter – und ist das als dauerhafte Funktion finanziert oder als Gefallen erhofft? Der größte Teil des versprochenen Werts einer EPR wird in den Jahren nach dem Umstieg realisiert, durch iteratives Feinjustieren von Arbeitsabläufen, Order-Sets und Alarmen, doch Organisationen lösen das Programm routinemäßig beim Go-live auf und erwarten, dass Optimierung gratis geschieht. Besprechen Sie, ob Sie ein ständiges Team für klinische Informatik und Optimierung mit geschütztem Personal und Budget haben oder Verbesserung von Goodwill abhängt, sobald das Projektgeld ausläuft. Wägen Sie den Zielkonflikt zwischen dem Aufwand, diese Fähigkeit zu erhalten, und dem Druck ab, Einsparungen im Business Case sofort zu verbuchen. Prüfen Sie, wie Nutzen tatsächlich verfolgt wird: Werden sie vor dem Go-live mit Baseline versehen, an benannte Verantwortliche und konkrete Arbeitsablaufänderungen gebunden und in festen Abständen gegen den Fall überprüft, oder still als gelandet angenommen? Überlegen Sie, wie Sie entscheiden, welche Alarme stillzulegen, welche Order-Sets zu überarbeiten sind und wie die Front Änderungen anfordert und sieht. Eine gute Antwort benennt eine dauerhafte, ausgestattete Funktion mit klarem Rhythmus der Nutzenrealisierung, kein Projekt, das beim Umstieg endet.

6. Optimieren wir für unseren eigenen Trust oder für das weitere System, durch das sich eine Patientin tatsächlich bewegt? Der strategische Sog über ein Integrated Care System geht zu weniger EPR-Instanzen und einer gemeinsamen Patientenakte, sodass Informationen der Patientin zwischen Krankenhaus, Gemeinde, psychischer Gesundheit und Primärversorgung folgen, statt an jeder Eingangstür zu enden. Besprechen Sie, ob Ihre EPR-Wahlen das stärken oder untergraben: Bestehen Sie auf offenen Standards und sauberer Interoperabilität, oder bauen Sie eine gut betriebene Insel? Bringen Sie die echte Spannung ans Licht zwischen Konvergenz – die Kosten senken und Fluss glätten kann, aber Risiko konzentriert und lokale klinische Präferenz übergeht – und starker Interoperabilität zwischen eigenständigen Systemen, die Autonomie um den Preis von mehr Schnittstellen bewahrt. Prüfen Sie, wie stark Sie Vendor Lock-in ausgesetzt sind und ob Sie eine realistische Ausstiegsstrategie und die Fähigkeit haben, Ihre eigenen Daten herauszubekommen. Überlegen Sie, wer auf ICS-Ebene diese Entscheidungen trifft und ob Ihre lokalen Entscheidungen dazu passen. Eine gute Antwort zeigt eine explizite Position zu Konvergenz versus Interoperabilität, ein Bekenntnis zu offenen Standards und sicherem Ausstieg und eine ehrliche Sicht, wo lokale und Systeminteressen derzeit auseinanderziehen.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Die Brackenmoor NHS Foundation Trust, ein mittelgroßer Akut- und Gemeindeanbieter, ersetzt drei alternde Systeme – ein Patientenverwaltungssystem, ein separates Order-Comms-System und einen Flickenteppich abteilungsweiser Datenbanken – durch eine einzige Lieferanten-EPR, teilweise über das nationale Frontline-Digitisation-Programm finanziert. Ihre aktuelle HIMSS-EMRAM-Stufe ist niedrig, und ihr Business Case verspricht Sicherheits- und Effizienznutzen, auf die der Vorstand zählt. Die früh geäußerte Versuchung ist, die alten Arbeitsweisen in das neue System „hochzuheben und zu verschieben“, um Störung zu minimieren.

Das Programm widersteht. Ein CCIO (ein praktizierender Oberarzt) und eine CNIO (eine leitende Pflegekraft) werden mit geschützter Zeit ernannt und erhalten gemeinsame Freigabe über den klinischen Bau, gestützt auf ein Netz digitaler Champions, das jede Station und Klinik erreicht. Sie setzen ein festes Prinzip: auf das unterstützte Modell des Herstellers konfigurieren und seine getesteten Order-Sets überall dort übernehmen, wo klinisch sicher, angepasst nur dort, wo ein echter Bedarf anders nicht erfüllt werden kann, jede Ausnahme dokumentiert und über den Prozess der klinischen Sicherheit nach DCB0160 risikobewertet. Order-Sets und Alarme der Entscheidungsunterstützung werden mit den Fachrichtungen gestaltet, die sie nutzen werden, mit bewusster Neigung zu weniger, höherwertigen Alarmen, um das Personal nicht in Pop-ups zu begraben.

Die Datenmigration wird als klinische Übung geführt, nicht nur als technische. Die Klinikteams entscheiden, dass aktive Probleme, Allergien, aktuelle Medikation und Schlüsselergebnisse in die strukturierte Akte wandern; ältere Historie wird zusammengefasst oder in einem schreibgeschützten Archiv der Altsysteme belassen, mit einem Klick erreichbar. Klinikpersonal gleicht Stichproben migrierter Daten vor dem Go-live ab und gibt sie frei, und das Team fängt einen Zuordnungsfehler, der einige Allergieeinträge still abgeschnitten hatte – eine Korrektur, die vor, nicht nach dem Punkt erfolgt, an dem sie jemandem hätte schaden können. Der Vorstand vereinbart einen geplanten Produktivitätseinbruch: Elektive Aktivität wird sechs Wochen lang rund um den Go-live um ein vereinbartes Maß verringert, Schulungszeit abgegrenzt und Erholungsverläufe festgelegt, sodass der Einbruch ein gesteuertes Ereignis statt einer Überraschung ist.

Brackenmoor wählt einen phasenweisen Rollout nach Standort statt eines einzigen trustweiten Big Bang und nimmt zusätzliche Integration und Doppelbetrieb im Tausch gegen die Chance in Kauf, zwischen den Phasen zu lernen. Jeder Umstieg läuft über eine geprobte Einsatzzentrale mit starker Unterstützung durch Personal auf den Stationen in den ersten zwei Wochen. Vor dem ersten Go-live führt der Trust eine volle Ausfallübung durch – schreibgeschützter Aktenzugriff, Papierabläufe und Abgleich zurück in das System –, weil der Cybervorfall eines Nachbar-Trusts das Risiko lebendig gemacht hat. Nach dem Go-live löst sich das Programm nicht auf: Es wird zu einer ständigen Funktion für Optimierung und klinische Informatik, die Arbeitsabläufe und Alarme feinjustiert, die versprochenen Nutzen gegen den Business Case verfolgt und den Trust in den folgenden zwei Jahren bewusst die EMRAM-Skala hinaufführt.

Sektorperspektiven#

Startup#

Ein Startup der digitalen Gesundheit verkauft selten eine vollständige EPR, steht und fällt aber damit, wie gut es sich in eine einsteckt. Gestalten Sie für die Realität, dass Krankenhäuser auf einem klinischen Kernsystem laufen, das Sie nicht kontrollieren: Unterstützen Sie offene Standards wie HL7 und FHIR, integrieren Sie sich über die Integrations-Engine des Trusts, statt eine maßgeschneiderte Verbindung zu verlangen, und schreiben Sie sauber und sicher in die Akte zurück. Ihr schnellster Weg zur Annahme ist, die Klickbelastung der Klinikerin innerhalb der EPR, die sie bereits nutzt, zu verringern, nicht zu vergrößern. Behandeln Sie das Ökosystem des EPR-Herstellers und die Informationsgovernance des Trusts als Beschränkungen, um die herum man gestaltet, nicht als Hindernisse, über die man klagt.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim oder eine Einzelstandort-Klinik – kauft meist ein klinisches System, statt eines zu bauen, und trägt dieselben Pflichten zu Aktenführung, Sicherheit und Informationsgovernance wie ein großer Trust, ohne dessen IT-Ressourcen. Wählen Sie ein unterstütztes, gut integriertes Produkt und widerstehen Sie lokaler Anpassung, die Sie nicht pflegen können, denn es gibt kein hauseigenes Team, das diese Schuld bei jedem Upgrade zurückzahlt. Behandeln Sie die Datenmigration aus Ihrem alten System auch im kleinen Maßstab als Aufgabe der klinischen Sicherheit: Allergien, aktuelle Medikation und aktive Probleme müssen unversehrt ankommen und von einer Klinikerin geprüft werden, nicht als korrekt angenommen, weil der Ladelauf lief. Planen Sie auch den Produktivitätseinbruch – eine Handvoll Klinikpersonal, das ein neues System lernt, kann eine kleine Praxis lahmlegen; schützen Sie daher Schulungszeit und staffeln Sie die Änderung, statt alles kalt einzuschalten. Bestehen Sie vor allem auf Interoperabilität und einer gemeinsamen Patientenakte, damit die Informationen Ihrer Patientinnen und Patienten ihnen in das weitere System folgen, und auf einem realistischen Ausstieg, damit ein einzelner Lieferant nicht Ihre Daten besitzt.

Großunternehmen#

Ein großer NHS Trust oder ein ICS, der ein EPR-Programm führt, geht eine zehnjährige, Multimillionen-Pfund-Verpflichtung ein, die jeden klinischen Arbeitsablauf umgestaltet. Seine zentralen Herausforderungen sind klinische Verantwortung im großen Maßstab, disziplinierte Konfiguration statt ausufernder Anpassung, eine lieferbare Einführungsform und die Ausdauer, Optimierung und Nutzenrealisierung lange nach dem Go-live zu finanzieren. Konvergenz über das ICS auf weniger EPR-Instanzen bietet echte Gewinne – gemeinsame Akten, glatterer Patientenfluss, niedrigere Stückkosten –, konzentriert aber Risiko und kann lokale klinische Präferenz übergehen; sie muss daher mit echter Beteiligung und einem nüchternen Blick auf Vendor Lock-in geführt werden. In dieser Größenordnung kommen die größten Erträge aus wenigen konsequent gehaltenen Disziplinen – klinische Führung, unterstützte Konfiguration, geprobter Umstieg, kontinuierliche Optimierung –, nicht aus Heldentaten an einem einzelnen Modul.

Regierung#

Nationale Stellen prägen das Umfeld, in dem jedes EPR-Programm arbeitet. Über das Frontline-Digitisation-Programm von NHS England setzt die Regierung die Erwartung, dass jeder Anbieter eine Kern-EPR hat, koppelt Kapitalfinanzierung an digitale Reife und steuert den Markt über Konvergenz und Beschaffungsrahmen. Ihr Hebel ist, offene Standards, Interoperabilität und sicheren Ausstieg zu den Standardbedingungen des Marktes zu machen, damit einzelne Trusts nicht je aus Schwäche gegenüber einer kleinen Zahl großer Lieferanten verhandeln (siehe Thema 9.1 — Zusammenarbeit mit lokalen und nationalen Regierungen). Die Regierung trägt auch die Pflicht zum systemweiten Lernen: zu verbreiten, was zwischen Trusts funktioniert, Reife national zu vergleichen und sicherzustellen, dass eine gemeinsame Patientenakte die Versorgung über Organisationsgrenzen hinweg verbessert, statt an der Eingangstür jedes Trusts zu enden.

Häufige Fehlermuster#

• Das klinisch hohle Programm. Ein technisch gut geführtes Projekt, das Klinikpersonal als Konsultierte behandelt, erzeugt ein System, das niemand nutzen will. Geben Sie CCIO und CNIO echte Befugnis, geschützte Zeit und Entscheidungsrechte über den Bau.
• Trampelpfade pflastern. Alte Papierformulare und Altarbeitsabläufe in einer modernen EPR nachzubauen bezahlt neue Software und erbt alte Probleme. Übernehmen Sie die getesteten Inhalte des unterstützten Produkts und gestalten Sie Arbeitsabläufe neu, statt sie zu replizieren.
• Anpassungs-Wildwuchs. Jede maßgeschneiderte Änderung wird bei jedem Upgrade neu bezahlt und öffnet eine Sicherheitsfläche, die niemand neu testet. Konfigurieren Sie auf das unterstützte Modell; dokumentieren, bewerten und verantworten Sie jede echte Ausnahme.
• Die Migration, die „sauber lief“. Ein Ladelauf ohne technische Fehler kann dennoch Allergien verlieren oder Patientinnen verwechseln. Gleichen Sie migrierte Daten vor dem Go-live ab und geben Sie sie klinisch frei und halten Sie ein erreichbares Altarchiv.
• So tun, als gäbe es keinen Einbruch. Eine glatte Produktivitätskurve anzunehmen verwandelt eine normale Verlangsamung nach dem Go-live in eine wahrgenommene Katastrophe. Planen, finanzieren und billigen Sie ein Fenster verringerter Aktivität mit realistischer Erholung durch den Vorstand.
• Beim Go-live aufhören. Die EPR als Projekt zu behandeln, das beim Umstieg endet, lässt ihren Nutzen unrealisiert. Richten Sie eine dauerhafte Funktion für Optimierung und Nutzenrealisierung ein.
• Alarmüberlastung. Zu viele wertarme Alarme der Entscheidungsunterstützung zu feuern trainiert Klinikpersonal, an allen vorbeizuklicken, auch an denen, die zählen. Feinjustieren, Übersteuerungsraten messen und Rauschen stilllegen.
• Ungetestete Ausfallpläne. Ein Ausfall-Ordner, den niemand geöffnet hat, ist kein Plan. Proben Sie geplante und ungeplante Ausfälle, einschließlich des Abgleichs zurück in die Akte.

Reifegradmodell#

Checkliste#

• Ein CCIO und eine CNIO sind mit geschützter Zeit, Budget und echten Entscheidungsrechten über den klinischen Bau ernannt, gestützt auf ein Netz digitaler Champions.
• Das Programm konfiguriert standardmäßig auf das unterstützte Modell des Herstellers; jede Anpassung ist dokumentiert, risikobewertet und verantwortet.
• Die Einführungsform (Big Bang versus phasenweise/modular) ist bewusst gegen Risikobereitschaft und Integrationskomplexität gewählt, mit geprobtem Umstieg und Rückfallplan.
• Die Datenmigration wird als klinische Übung geführt: Migrationsumfang vereinbart, Daten abgeglichen und klinisch freigegeben und ein erreichbares Altarchiv bereitgestellt.
• Ein Produktivitätseinbruch ist geplant, finanziert und vom Vorstand gebilligt, mit verringerter Aktivität, geschützter Schulung und realistischen Erholungsverläufen.
• Order-Sets und Alarme der Entscheidungsunterstützung sind mit Klinikpersonal co-designt und kontinuierlich gesteuert, mit überwachten Alarmauslösungs- und Übersteuerungsraten.
• Ausfall- und Business-Continuity-Verfahren – schreibgeschützter Zugriff, Papierabläufe, vereinbartes RTO/RPO, Abgleich – existieren und werden für geplante und ungeplante Ausfälle geprobt.
• Nutzen sind vor dem Go-live mit Baseline versehen, an benannte Verantwortliche und Arbeitsablaufänderungen gebunden und nach dem Go-live gegen den Business Case überprüft.
• Digitale Reife wird verglichen (z. B. HIMSS EMRAM) und genutzt, um Fortschritt mit dem Vorstand zu verfolgen.
• Eine dauerhafte Funktion für Optimierung und klinische Informatik setzt sich nach dem Umstieg fort.
• Offene Standards, Interoperabilität und eine realistische Ausstiegsstrategie sind gesichert, um Vendor Lock-in zu begrenzen, abgestimmt mit ICS-Konvergenzplänen.

Zentrale Quellen#

• NHS England — Programm Frontline Digitisation und Reifegradrahmen What Good Looks Like / Who Pays for What für klinische Systeme von Anbietern.
• HIMSS — Electronic Medical Record Adoption Model (EMRAM), ein internationaler Benchmark von 0–7 für die digitale Reife klinischer Systeme.
• NHS England / NHS Digital — Standards zur klinischen Sicherheit DCB0129 (Herstellung) und DCB0160 (Einsatz) für Gesundheits-IT-Systeme einschließlich EPRs.
• Faculty of Clinical Informatics und CCIO/CNIO Network — berufliche Leitlinien für Rollen der klinischen Informationsführung.
• HL7 International — HL7-v2- und FHIR-Standards für Messaging und Integration zwischen klinischen Systemen.
• HM Treasury — The Green Book und Five Case Model für den EPR-Business-Case und die Nutzenrealisierung.
• Wachter Review (Making IT Work, 2016) und der Topol Review — nationale Überprüfungen zur Digitalisierung von NHS-Anbietern und des klinischen Personals.

Referenzen#

1. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
2. Hospital information system — Wikipedia — https://en.wikipedia.org/wiki/Hospital_information_system
3. Computerized physician order entry — Wikipedia — https://en.wikipedia.org/wiki/Computerized_physician_order_entry
4. Clinical decision support system — Wikipedia — https://en.wikipedia.org/wiki/Clinical_decision_support_system
5. Big bang adoption — Wikipedia — https://en.wikipedia.org/wiki/Big_bang_adoption
6. Chief medical informatics officer — Wikipedia — https://en.wikipedia.org/wiki/Chief_medical_informatics_officer
7. Health informatics — Wikipedia — https://en.wikipedia.org/wiki/Health_informatics
8. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
9. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
10. Health information exchange — Wikipedia — https://en.wikipedia.org/wiki/Health_information_exchange
11. Healthcare Information and Management Systems Society — Wikipedia — https://en.wikipedia.org/wiki/Healthcare_Information_and_Management_Systems_Society
12. NHS England — Frontline Digitisation — NHS England — https://www.england.nhs.uk/digitalhealth/connecting-frontline-digitisation/
13. NHS England — What Good Looks Like framework — NHS England — https://www.england.nhs.uk/digitalhealth/what-good-looks-like/
14. HIMSS — Electronic Medical Record Adoption Model (EMRAM) — HIMSS — https://www.himss.org/what-we-do-solutions/digital-health-transformation/maturity-models/electronic-medical-record-adoption-model-emram
15. NHS Digital — Clinical Safety standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
16. Robert Wachter — Making IT Work: Harnessing the Power of Health Information Technology to Improve Care in England — GOV.UK — https://www.gov.uk/government/publications/using-information-technology-to-improve-the-nhs
17. Faculty of Clinical Informatics — professional body for clinical informaticians — FCI — https://facultyofclinicalinformatics.org.uk/