Handbuch für Primär-Versorgungs-Einheiten

Die grundsätzliche Ausgangslage ist, dass in den Ordinationen möglichst viele vorhandene Komponenten weiterverwendet werden sollen, die (im allgemeinen Fall) von unterschiedlichen Herstellern geliefert und gewartet werden.

Damit dies möglich ist, müssen „Kommunikationsmodule“ geschaffen werden, die – unter Verwendung von anerkannten Standards – über ein Netzwerk mit den zur Verfügung gestellten „gemeinsamen Services“ kommunizieren und damit eine standortübergreifende Kommunikation ermöglichen.

Diese Kommunikationsmodule sind in den Ordinationen vom jeweiligen Hersteller der Arztsoftware zu entwickeln. Die Komponenten für das „gemeinsame Service“ werden von dort zu beauftragenden Herstellern geliefert.

Durch die Verwendung von Standards können die Entwicklungsaufwände und -kosten deutlich gesenkt werden.

Schichtenmodell der Datenspeicherung

Die Speicherung der patientenbezogenen Gesundheitsdaten wird in einer PVE nach folgendem Modell erfolgen. Damit wird auch der Tatsache Rechnung getragen, dass eine PVE üblicherweise schon aus einer bereits vorher existierenden Infrastruktur entstanden ist.

Auch für neueinsteigende Ordinationen ohne existierende Infrastruktur ist dieses Modell geeignet.

Ausformung als PVN

Eine zentrale Speicherung aller Daten ist NICHT angedacht.

Die Daten jeder Ordination verbleiben prinzipiell lokal in der Ordination, nur genau spezifizierte Daten werden (bei entsprechender Indikation und Berechtigung) an ein gemeinsames Service übermittelt.

Bei Bedarf werden Daten von außerhalb des PVN gelesen und in die Ordination importiert bzw. aus der Ordination exportiert und in der Außenwelt (z.B. ELGA) abgelegt.

Beispiele für die gespeicherten Daten in den einzelnen Schichten:

Ausformung als PVZ

Im PVZ wird eine gemeinsame Software verwendet. Diese muss mandantenfähig sein, um die Daten einzelner Ordinationen separieren zu können. Der Zugriff auf die relevanten Gesundheitsdaten der Patientinnen/Patienten muss für alle Ordinationen möglich sein, dies verbleibt im Wirkungsbereich der verwendeten Arztsoftware.

Bei Bedarf werden Daten von außerhalb des PVN gelesen und in die Ordination importiert bzw. aus der Ordination exportiert und in der Außenwelt (z.B. ELGA) abgelegt.

Beispiele für die gespeicherten Daten in den einzelnen Schichten:

Empfohlener Lösungsansatz

Dieses Kapitel ist nur für die „Ausformung als PVN“ interessant, da in einem PVZ typischerweise die Daten in einer gemeinsam benutzten Software abgespeichert sind. Soweit auch in einer PVZ unterschiedliche Softwareprodukte bei den involvierten Gesundheitsberufen zum Einsatz kommen, sind auch die folgenden Ausführungen zu beachten.

Die Organisation der gemeinsam genutzten Gesundheitsdaten wird als ein „PHC Datenspeicher“ gestaltet, der als gemeinsame, standardisierte Datenablage fungiert. Dazu wird eine eigene „affinity domain“ für das PVN geschaffen, in der Dokumente für die im PVN behandelten Patientinnen/Patienten gespeichert werden. Ein Zugriff von außerhalb der am PVN beteiligten Ordinationen sowie der Patientinnen/Patienten selbst ist nicht möglich.

Diese Vorgehensweise bietet den Vorteil, dass wesentliche Abläufe und Umsetzungen den beteiligten Arztsoftwareherstellern aus dem Umfeld von ELGA bereits bekannt und (zumindest teilweise) bereits getestet und umgesetzt sind. Eine Notwendigkeit einer kompletten Neuentwicklung wird sich daher in den seltensten Fällen stellen.

Durch die weitgehende Verwendung bereits etablierter nationaler und internationaler Standards können inhaltliche und technische Komponenten aus ELGA wiederverwendet werden. Eine kostengünstige Lösung für die einzelnen Ordinationen ist dadurch möglich, eine Auswahl aus mehreren Anbietern für die gemeinsamen Services kann zumindest angestrebt werden. Der Eingriff in die beteiligten Arztsoftwaresysteme bleibt in dieser Variante möglichst gering. Aus administrativer und wirtschaftlicher Sicht ist dies die bevorzugte Variante.

Eine Übersicht über die benötigten Komponenten:

Komponente ist in jeder Variante notwendig

Komponenten für zukünftige Bildspeicherung

Komponenten für Anschluss an einen „PHC-führenden ELGA-Bereich“

 

Erforderliche und gewünschte Funktionalitäten

Wir haben uns bemüht, die Funktionalitäten eines PVE-Datenspeichers auszuloten. Dabei können folgende Kategorien unterschieden werden:

  • Funktion ist gesetzlich gefordert
  • Hierbei ist zu beachten, dass die gesetzlichen Grundlagen nur allgemeine Funktionalitäten fordern, diese können nicht immer trennscharf in Einzelfunktionen des PHC Datenspeichers abgebildet werden.
  • Erweiterte Funktionalitäten, die zusätzlichen Nutzen versprechen
FunktionalitätGesetzlich
gefordert
Erweitert
Austausch von Gesundheitsdaten, die eine Weiterbehandlung
von Patienten innerhalb der PVE ermöglichen
 
Austausch von administrativen oder statistischen Daten 
Austausch von Gesundheitsdaten, die über die Notwendigkeit
der Weiterbehandlung von Patientinnen/Patienten innerhalb der PVE hinausgehen
 
Kommunikation mit den gemeinsamen Services per Softwareschnittstelle  nicht definiert
Kommunikation mit den gemeinsamen Services per Webinterfacenicht definiert
Patientinnen/Patienten mit e-card können erfasst werden (*) 
Alle Patientinnen/Patienten können erfasst werden (*) 

(*) In den gesetzlichen Grundlagen existiert keine exakte Definition. Da aber im Gesundheitstelematikgesetz 2012 die „ELGA-Teilnehmer“ im niedergelassenen Bereich verpflichtend mit e-card identifiziert werden müssen, ist in dem hier angeführten Zusammenhang dieselbe Verpflichtung anzunehmen.

Inhaltliche Standardisierung der gemeinsam verwendeten Gesundheitsdaten

Dieses Kapitel ist in erster Linie für die „Ausformung als PVN“ interessant, da in einem PVZ typischerweise die Daten in einer gemeinsam benutzten Software abgespeichert sind.

Die erste Definition gemeinsam verwendeter Daten wurde im Rahmen der ELGA CDA Normierungen erarbeitet. Die Ergebnisse sind im „PHC-Statusbericht“ zusammengefasst und werden im Folgenden überblicksweise aufgeführt.

Im Detail können die Definitionen unter:

https://wiki.hl7.at/index.php?title=ILF:Leitfaden_PHC_Statusbericht betrachtet werden.

Im Zuge der ersten Verwendungen der Definition können Erweiterungen bzw. Änderungen geplant werden, diese werden in Versionierungen der o.g. Definition abgebildet.

Grundsätzlich gilt, dass nur Gesundheitsdaten (und möglicherweise demografische Daten) ausgetauscht werden, administrative (wie z.B. Verrechnungsdaten) sind nicht enthalten. Über die Patientinnen/Patienten selbst sind detaillierte Informationen enthalten, die bei einer Übernahme in das eigene System selbstverständlich verwendet werden können.

Konsultations- oder Überweisungsgrund

Enthält eine kurze narrative Beschreibung des Hauptsymptoms der Patientin/des Patienten (eigene Beschreibung der Patientin/des Patienten) und/oder den Grund für den Patientenbesuch.

Die wichtigsten Angaben sind

  • Statuscode: „active“ oder „completed“. Bei „completed“ ist das Gesundheitsproblem als erledigt zu betrachten, ansonsten gilt immer „active“.
  • Zeitangaben: Auftreten und Dauer des Gesundheitsproblems/der Gesundheitsprobleme
  • Autorin/Autor
  • Quelle der Information
  • Gesundheitsproblem(e)
    • Art (Symptom, Abklärung, Diagnose)
    • Auftreten und Dauer
    • Bezeichnung (Code und Text)
    • Schweregrad
    • Gewissheit
    • Klinischer Status (aborted/active/completed/suspended)
    • Verweise auf Anhänge

Allergien und Intoleranzen

Angegeben werden die Art der Reaktion (Hautausschlag, Anaphylaxie, Erbrechen, ...), vorzugsweise die auslösende Substanz, die Kritikalität sowie eine Angabe, wie gesichert die Information ist. Grundsätzlich sollen nur relevante Allergien und Intoleranzen angeführt werden.

Grundsätzlich gilt: Auch wenn keine relevanten Allergien oder Intoleranzen vorliegen oder keine Information verfügbar ist, soll das klar erkennbar dokumentiert werden. Diese Vorgehensweise ist mit dem „Internationalen Patient Summary“ abgestimmt und wird in viele Teilbereiche der Datendarstellung Einzug halten.

Die wichtigsten Angaben sind

  • Autorin/Autor
  • Informantin/Informant
  • Bezeichnung (Code und Text)

Empfohlene Medikation

Enthält die im Rahmen des Patientenkontakts empfohlene oder verschriebene Medikation, kann auch die bestehende Medikation enthalten.

Die wichtigsten Angaben sind

  • Autorin/Autor
  • Datum
  • Medikament(e)
    • Typ (Abgabe oder Verordnung)
    • Bezeichnung des Medikamentes
    • Packungsanzahl
    • Einnahmeregeln und -dauer
    • Anzahl der Einlösungen
    • Art der Anwendung

Die Medikamentendefinitionen sind aus dem Leitfaden für den ärztlichen Entlassungsbrief entnommen, die weiteren Definitionen aus dem Projekt „e-Medikation“.

Auch Magistraliter können erfasst werden.

Wichtige Hinweise

Erfassung als Freitext

Weitere Informationen

Erfassung als Freitext

Beilagen

Beilagen müssen im Dokument eingebettet sein, eine Referenz auf ein externes Dokument ist nicht möglich.

Empfohlene technische Standards

Dieses Kapitel ist in erster Linie für die „Ausformung als PVN“ interessant, da in einem PVZ typischerweise die Daten in einer gemeinsam benutzten Software abgespeichert sind.

Die technischen Standards für den Zugriff auf die im vorigen Kapitel angeführten Gesundheitsdaten sind aus dem Projekt ELGA entnommen.

Ein genauer Einblick in die Architektur und die Überlegungen der Umsetzung in ELGA selbst ist unter: https://www.elga.gv.at/fileadmin/user_upload/Dokumente_PDF_MP4/Technisches/ELGA_Gesamtarchitektur_2.30b.pdf verfügbar.

Möchten Sie Dokumente, die in einem PHC gespeichert werden, für ELGA freigeben, so ist dafür der jeweilige Mechanismus auszulösen, der in der Arztsoftware implementiert ist.
Ein direkter Weg vom „PHC Datenspeicher“ nach oder von ELGA ist nicht vorgesehen.

Dokumentenaustausch innerhalb des PVN

Diese Aufgabe wird durch das „IHE XDS Profil“ beschrieben.

Das Profil definiert, wie Dokumente von einer Dokumentenquelle (Document Source) in einem Datenspeicher (Document Repository) abgelegt werden, in einem Verweisregister (Document Registry) registriert werden und wie ein Konsument (Document Consumer) die Dokumente suchen und abrufen kann. Weiters definiert das Profil, wie die Patienten in diesem Zusammenhang identifiziert werden, und berücksichtigt daher auch einen Akteur, der „Patient Identity Source“ bezeichnet wird. Dieser liefert Informationen zu den Identifikatoren, mit denen Dokumente registriert werden.[2]

Identifikation von Benutzern

Diese Aufgabe wird durch die IHE-Profile „Patient Demographics Query HL7 V3 (PDQV3)“ beschrieben. Eine grundlegende Frage betrifft die technische Identifikation von Benutzerinnen/Benutzern des PHC Datenspeichers.

Verwendet man die in ELGA existierenden Mechanismen, ist eine einfache, schnelle und sichere Umsetzung möglich. Dabei werden die e-cards der Patientinnen/Patienten und die Adminkarten der Ordinationen verwendet. Allerdings bleiben alle Patientinnen/Patienten, die keine e-card besitzen oder diese nicht vorlegen können, von dem Datenaustausch innerhalb des PHC ausgesperrt. Dies wird in erster Linie Touristen und ausländische Arbeitskräfte betreffen.

Eine Alternative liegt in der Bildung einer eindeutigen Patientenidentifikation durch die beteiligten Arztsoftwaresysteme und in der Hinterlegung dieser ID im PHC Datenspeicher.

Dazu müssen aber einige Umbauarbeiten an der Standardinfrastruktur vorgenommen werden.

Erforderliche Softwarekomponenten

Dieses Kapitel ist in erster Linie für die „Ausformung als PVN“ interessant, da in einem PVZ typischerweise die Daten in einer gemeinsam benutzten Software abgespeichert sind.

Um – wie bereits angeführt – sich möglichst nah an der bereits vorhandenen ELGA-Infrastruktur zu halten, hier eine Übersicht der wichtigsten Komponenten in ELGA:

Softwarekomponenten für gemeinsame Services

Abhängig von der Integrationstiefe (siehe Kapitel über ELGA plus) mit der existierenden ELGA-Infrastruktur können 2 Varianten angeführt werden.

 

Variante 1: Maximale Integration mit ELGA

In dieser Variante werden möglichst viele Komponenten von ELGA (und ELGA plus) genutzt, eigene Erweiterungen werden nicht implementiert.

Damit ist eine schnelle Inbetriebnahme zu geringeren Kosten als in Variante 2 möglich.

Eine schematische Darstellung der erforderlichen Komponenten:

Variante 2: Integration mit ELGA und eigene Erweiterungen

In dieser Variante wird Wert auf eine maximal verfügbare Funktionalität gelegt, Komponenten von ELGA werden soweit wie möglich verwendet, ansonsten werden eigene Komponenten entwickelt. Damit können alle gewünschten Funktionalitäten umgesetzt werden.

Eine schematische Darstellung der erforderlichen Komponenten:

Softwarekomponenten für die Anbindung in den Ordinationen

In einer Einzelordination ist üblicherweise vorhanden:

  • Arztsoftware
  • Anbindung an das e-card System
  • Anbindung an lokale Geräte (Drucker, Scanner, EKG, …)
  • Einbindung von externen Befundquellen (ELGA, Befundübertragung)

Diese Komponenten werden auch in einem PVN weiterhin lokal betrieben.

Zusätzliche Funktionen werden durch gemeinsam PVE-weit genutzte Software ergänzt.

Dafür wird ein „Kommunikationsmodul“ benötigt, das vom Hersteller der Arztsoftware bereitgestellt werden muss. Die gewählte Variante und die gewünschten Funktionen werden die Komplexität (und damit letztendlich den Preis) bestimmen.

Für die Einbindungen von Teilnehmern ohne Arztsoftware (Wahlärzte, nichtärztliche Teilnehmer) wird es notwendig sein, das gemeinsame Service mit einer Weboberfläche auszustatten. Damit können diese Teilnehmer mittels eines Browsers die Daten bereitstellen bzw. auf die Daten zugreifen.

Die damit verbundenen Nebenbedingungen (beispielsweise die Identifikation von Teilnehmern und Patienten) müssen dabei beachtet werden.

Die ersten Erfahrungen mit dem Einsatz in Ärztenetzwerken haben gezeigt, dass die erforderlichen Arbeitsschritte großteils von der Arztsoftware vorbereitet werden und sich damit der erforderliche Zeitaufwand im täglichen Betrieb als minimal ergibt.

Die geplanten Schritte in der Arztsoftware:

  • Beim Eintreffen der Patientin/des Patienten in der Ordination werden evtl. vorhandene Daten aus dem PHC-Datenspeicher geladen und angezeigt bzw. importiert.
  • In der Patientenkartei ergibt sich keine Änderung zum Status quo.
  • Während der (meist täglichen) Journalarbeit werden bei den behandelten Patientinnen/Patienten Vorschläge gemacht, welche Daten in den PHC-Datenspeicher exportiert werden sollen. Man kann die Vorschläge akzeptieren oder adaptieren.
  • Nach der letzten Patientin/dem letzten Patienten werden alle Daten in den PHC-Datenspeicher übertragen.

Aus den ähnlich gelagerten Szenarien der Einführung von e-Medikation und e-Befund ist davon auszugehen, dass die Hersteller der Arztsoftware auch hier maximale Rücksicht auf die Bedienbarkeit der Module und Sinnhaftigkeit der Vorschläge legen werden. Wir erwarten eine hochgradig automatisierte, aber dennoch kontrollierbare Funktionalität.

Erforderliche Hardware

Die Hardware in den einzelnen Ordinationen wird wie bisher verwaltet werden. Für die einzelnen gemeinsamen Services wird möglicherweise eine eigene Hardware anzuschaffen sein. Die Anschaffung, Inbetriebnahme, Betrieb, Garantieabwicklungen und dergleichen sollen durch den Gesamt-IT-Verantwortlichen durchgeführt werden.

Zu beachten ist, dass für einen reibungsfreien Betrieb die Garantieverlängerungen und Reaktionszeiten der Lieferanten entsprechend vereinbart werden müssen.

Kommunikation zwischen den Standorten

An einem zentralen Punkt (dieser kann entweder in einer Ordination des PVN oder in einer gemeinsam genutzten Lokation gelegen sein) werden für das gesamt PVN gemeinsame Services vorgehalten. Diese dienen der technischen Abwicklung der organisatorischen Anforderungen. Eine hochwertige und störungsfreie Breitbandverbindung ist die Grundlage, elektronische Informationen zwischen den PVN-Standorten auszutauschen.

Sollten keine (oder nur wenige) Bilddaten ausgetauscht werden, ist vorläufig die Kapazität des e-card Netzwerkes ausreichend. Über einen sogenannten „Mehrwertdienst“ können Ordinationen zusammengeschaltet werden, eventuell ist eine derartige Option auch über „ELGA plus“ verfügbar.

Alternativ können kommerzielle Internetanbindungen errichtet und mittels VPN sicher zusammengeschaltet werden. Damit können deutlich höhere Bandbreiten erreicht werden.

Notwendige organisatorische Maßnahmen und Dienstleistungen

Durch die dezentrale Struktur des PVE-Netzwerkes müssen Soft- und Hardwarekomponenten geschaffen werden, die einen Betrieb von „gemeinsamen Services“ garantieren. Wesentliche Aufgaben für das PVE-Netzwerk sind dabei:

  • Auswahl und Beschaffung der Soft- und Hardware
  • Inbetriebnahme
  • Anbindung der einzelnen Ordinationen
  • Betrieb, Sicherung, Wartung, Notfallmanagement
  • Sicherstellung der IT-Sicherheit und des Datenschutzes
  • Ansprechstelle für Fragen

Daher wird es unumgänglich sein, dass das PVE-Netzwerk einen „Gesamt-IT-Verantwortlichen“ bestimmt, der für die Erfüllung der Aufgaben verantwortlich ist. Möglicherweise wird dieser ein Unternehmen sein oder Subdienstleister beschäftigen, für die weiteren Betrachtungen spielt dies jedoch keine Rolle.

Die Einbindung von ELGA plus

Derzeit (Herbst 2018) werden Umbaupläne für ELGA evaluiert. Diese werden durch die Notwendigkeit, Primärversorgungseinheiten zu unterstützen, beschleunigt.

„ELGA plus“ bedeutet (grob vereinfacht), dass die monolithischen Dienste von ELGA in kleine Services und Prozeduren aufgespalten werden, um so eine E-Health-Szene in Österreich besser unterstützen zu können.

Für die Unterstützung einer PVE ist vorgesehen:

  • Anbindung eines PHC-Datenbereiches an einen offiziell anerkannten ELGA-Bereich
  • Der PHC-Datenbereich kommuniziert nur per Zugriffsfassade.
  • Wesentlich Teile der ELGA-Infrastruktur werden verwendet (Patientenindex, Kontaktbestätigung, Zugriffsberechtigung, Protokollsystem).

[1] Quelle: Muster eines Versorgungskonzeptes für eine Primärversorgungseinheit (PVE) – DI Michael Nöhammer

[2] ELGA Gesamtarchitektur, Version 2.30b