POCT1-A

Um die Kommunikationswege zwischen POCT-Geräten (Point of Care Testing, patientennahe Durchführung von Laboratoriumsuntersuchungen mit handlichen Messgeräten) und Krankenhausinformationssystemen (KIS) zu vereinfachen und eine lückenlose Qualitätssicherung, welche den gesetzlichen Anforderungen entspricht, zu gewährleisten wurde der medizinische Kommunikationsstandard POCT1-A ins Leben gerufen.

Weiteres empfehlenswertes Fachwissen

Empfindlichkeitsprüfung von Laborwaagen

Wie erhalten Sie Tag für Tag genaue Wägeresultate?

Leitfaden zu den grundlegenden Laborkenntnissen

Entstehung von POCT-1A

Der Standard ist in Folge dreier Spezifikationen entstanden. Als Grundlage diente die Spezifikation des Connectivity Industry Consortium CIC. Das CIC ist eine Vereinigung von 52 Organisationen, die aus Medizingeräteherstellern und -anbietern bestehen. Mitglieder in diesem Konsortium sind beispielsweise Philips Medical Systems, Bayer Diagnostics und Roche Diagnostics/AVL. Im ersten Entwurf wurde eine Beschreibung der Attribute eines Access Points, dem Kommunikationsprotokoll zwischen Gerät und AccessPoint und der Kommunikation zwischen einem Data Manager und dem KIS gegeben.

Aus diesen Anforderungen entwickelte sich in Zusammenarbeit mit Herstellern eine Spezifikation, welche eine Fusion der Interessen und Vorgaben von CIC, NCCLS, HL7, IEEE, Herstellern und gesetzlichen Vorschriften darstellt. Bei der NCCLS, die sich erst kürzlich in CLSI umbenannt hat, handelt es sich um eine globale, non-profit, ANSI akkreditierte Standardisierungsorganisation, welche medizinische Standards fördert und im speziellen POCT1-A veröffentlicht hat und mit der Weiterentwicklung des Standards beschäftigt ist. Die aktuelle Version des Standards wurde im Dezember 2001 verabschiedet und ist mittlerweile ein IEEE und NCCLS Standard. Es sind zudem Bestrebungen im Gange POCT1-A in HL7 zu integrieren.

Überblick POCT1-A

Der Standard besteht aus zwei Kommunikationsschnittstellen, zum einen das Device Interface und zum anderen das Observation Reporting (EDI) Interface. Die erste der beiden Schnittstellen, das Device Interface stellt den Weg vom Gerät zum POC Data Manager dar. In dieser wird die Übermittlung von Messdaten über eine vorhandene Infrastruktur beschrieben. Der zweite Teil befasst sich mit der Weitergabe dieser Daten ins KIS.

• Devices, Docking Stations: Diese Geräte werden normalerweise laut Standard durch physikalische POCT - Geräte repräsentiert. Nach aktuellem Stand existieren auf dem Markt jedoch noch keine Geräte, welche POCT1-A implementiert haben. • Access Points / Network: Damit das Gerät mit dem POC Data Manager kommunizieren kann, muss eine vorhandene Netzinfrastruktur des Krankenhauses genutzt werden. Eine drahtlose Anbindung von POCT Geräten birgt etliche Vorteile gegenüber einer kabelgebundenen oder Synchronisations-Lösung. Der wichtigste Vorteil neben der Mobilität ist wohl die sofortige Verfügbarkeit der Messwerte im KIS. • POC Data Manager: Der POC Data Manager besteht aus einem Observation Reviewer, welcher primär als Server fungiert. Mit Hilfe dieses Servers kann das POC Device konfiguriert, gewartet und abgefragt werden. Zudem bietet der Observation Reviewer auch die Möglichkeit die Daten weiter ins KIS zu verbreiten.

Aufbau von POCT1-A

Der POCT1-A - Standard sieht für die Kommunikation zwischen einem POCT Gerät und Observation Reviewer die Verwendung von XML - Nachrichten vor. Zu der Zeit, als der Standard spezifiziert wurde, wollte man den damals aktuellen Stand in der Entwicklung der XML Funktionalität von HL7 Version 3.0 einbringen. Deshalb orientieren sich die POCT1-A XML Datentypen auch an den damaligen Entwürfen des HL7 Standards in der Version 3.0. Die POCT1-A Nachrichten setzen sich aus einzelnen POCT1-A-Objekten zusammen, welche wiederum aus einzelnen POCT1-A-Datentypen bestehen. Der Aufbau dieser Datentypen soll am Beispiel des CE Datentyps erklärt werden:

Dieser Datentyp verfügt über fünf Attribute. Wird eine neue Variable dieses Typs angelegt, können diese fünf Attribute individuell gesetzt bzw. ausgelesen werden. In diesem Beispiel ist das Feld observation_id aus dem Observation - Objekt dargestellt. Der V Wert, hält einen nach LOINC codierten Wert. Der Parameter SN verweist auf die Codierungsart und DN gibt einen Wert an, welcher zur Darstellung verwendet werden kann.

Exemplarisch an einer POCT1-A Nachricht, der Hello Nachricht (HEL.R01), soll nun der Aufbau von POCT1-A Nachrichten im Detail erklärt werden. Es handelt sich hierbei um die erste Nachricht, die von einem Gerät versendet wird. Sie ist mit einer Verbindungsanfrage gleichzusetzen.

Mit dieser Nachricht teilt das Gerät dem Observation Reviewer mit, welche individuellen Fähigkeiten es besitzt und welche Modi es beherrscht. Die HEL.R01 Nachricht besteht, wie man in der linken Abbildung sehen kann, aus drei POCT1-A Objekten, wovon ein Objekt zwei Unterobjekte besitzt, also streng genommen sogar fünf POCT1-A Objekten. Das erste Objekt, der Header, steht jeder Nachricht voran und beinhaltet den Typ der Nachricht, eine eindeutige Kontrollnummer und die Uhrzeit, zu der die Nachricht erstellt wurde. Das zweite Objekt hält Informationen, über das Gerät selbst und definiert in seinen beiden Unterobjekten technische Fähigkeiten des Gerätes. Hier werden die Informationen übermittelt über die Möglichkeiten Operator bzw. Patient Lists zu empfangen oder bestimmte Direktiven zu verarbeiten. Hierauf wird in diesem Kapitel noch detaillierter eingegangen. Im dritten und letzten Objekt sind noch Daten über die Verbindung zu sehen. Auf der linken Seite der Abbildung ist die aus den Objekten dynamisch generierte XML - Datei zu sehen, welche auch gesendet wird. Auf diese Weise lassen sich alle POCT1-A Nachrichten zusammenstellen. Eine detaillierte Auflistung der Nachrichten und Objekte ist im Anhang zu finden. Um eine Kommunikation mit Hilfe dieser Nachrichten zu realisieren, definiert der Standard Nachrichtenprofile.

Nachrichtenprofile

Es werden ein Standard Protokoll (Basic Message Flow) und zwei Erweiterungen für dieses beschrieben. Diese Erweiterungen werden im Standard Continuous Mode und Asynchronous Mode genannt. Auf den Standardablauf und die beiden Spezialfälle wird im folgenden Text näher eingegangen. Einem erfolgreichen Datenaustausch zwischen den beiden Geräten steht jedoch ein „Anmeldevorgang“ des Gerätes voran. Er wird vom Gerät initiiert, indem dieses eine Hello-Message (HEL.R01) an den Observation Reviewer sendet. Empfängt dieser diese Nachricht fehlerfrei, so sendet er eine positive Acknowledgement-Message zum Gerät. Die Hello-Message beinhaltet lediglich die Aufforderung eine Verbindung aufzubauen. In einem nächsten Schritt teilt das Gerät dem Observation Reviewer seine Fähigkeiten und verfügbaren Funktionen mit. Dies geschieht mit Hilfe der Device Status-Message. In dieser Nachricht wird auch eine Information über eventuelle noch nicht übermittelte Messungen gegeben. Hat der Observation Reviewer die Nachricht akzeptiert und mit einem positiven Acknowledgement quittiert, ist die Verbindung hergestellt. Dieser Nachrichtenfluss ist zwingend vorgeschrieben und darf weder in der Reihenfolge verändert werden noch darf ein Fehler auftreten. Ansonsten können sich die beiden Geräte nicht korrekt verbinden.

Basic Message Flow

Im Basic Message Flow Profile bietet das Gerät folgende Möglichkeiten der Kommunikation mit dem Observation Reviewer. Ein POCT1-A-fähiges Gerät kann eine Anfrage bzgl. einer Observation (Messung) mit der passenden Nachricht beantworten. Der Observation Reviewer sendet hierzu eine Request-Message. Nachdem das Gerät diese mit einer (oder auch mehreren) Observation-Messages beantwortet hat, sendet es noch eine End-Of-Topic-Message, um das Ende der Übertragung anzuzeigen. Empfängt der Observation Reviewer diese Nachricht, ist sichergestellt, dass keine weiteren Nachrichten mehr empfangen werden müssen. Jede gesendete Observation muss durch ein positives Acknowledgement quittiert werden.

Der Ablauf einer Anfrage nach einem (oder mehreren) Device Events (gerätespezifisches Ereignis, z. B. „leere Batterie“ oder ähnliches) verhält sich äquivalent zu der vorherigen Anfrage nach einer Observation.

Der Observation Reviewer kann dem Gerät sowohl Operator Lists als auch Patient Lists senden. Beide Listen existieren in zwei verschiedenen Varianten. Bevor eine solche Liste gesendet wird, muss jedoch sichergestellt sein, dass das Gerät einen Empfang dieser unterstützt. Eine etwaige Unterstützung teilt das Gerät bei dem Anfangs erklärten Anmeldevorgang dem Observation Reviewer mit. Es ist eine genaue Differenzierung zwischen den vorgenannten möglichen Typen anwendbar. Jede der beiden Listen kann entweder inkrementell versendet werden, um somit die neuen Daten nur an die bereits im Gerät vorhandenen anzufügen bzw. wieder zu löschen, oder auch als komplett neue Liste versendet werden, um somit die alten Daten zu löschen und durch neue komplett zu ersetzen.

Der Observation Reviewer kann durch sogenannte Direktiven dem Gerät Steuerungsbefehle senden. Mit Hilfe dieses Nachrichtentyps ist es auch möglich, das Gerät in den Continuous-Mode zu setzen. Die Nachricht kann jedoch nur verarbeitet werden, wenn das Gerät dies beherrscht. Ähnlich der Unterstützung von Patient / Operator Lists wird dies in der Anmeldesequenz dem Observation Reviewer mitgeteilt.

Um Störungen auch zu Zeitpunkten, in denen das Gerät keine Daten sendet, zu erkennen wird eine Keep Alive-Nachricht versendet. Diese kann sowohl vom Gerät selbst als auch vom Observation Reviewer gesendet werden. Bestätigt wird diese jeweils wieder mit einer positiven Acknowledgement-Nachricht.

Abschließend lässt sich noch sagen, dass eine feste Reihenfolge dieser Nachrichten nicht vorgeschrieben ist. Lediglich in sich müssen die Abläufe konsistent sein. Mit der Terminate-Message wird es dem Observation Reviewer ermöglicht, die Verbindung zu beenden. Jedoch schreibt der Standard noch eine Bestätigung seitens des Gerätes vor. Zudem ist auch die Möglichkeit vorgesehen, dass die Verbindung auf Anfrage des Gerätes beendet wird. Hierfür ist jedoch auch wieder eine Bestätigung des Observation Reviewers nötig.

Eine zum Basic Message Flow modifizierte Kommunikationsart stellt der Continuous Mode dar, der in folgendem Abschnitt vorgestellt wird.

Continuous Mode

Dem Continuous Mode ist immer das Basic Message Profile vorangestellt, oder zumindest ein Verbindungsaufbau in Folge einer Direktive. Wird das Gerät in den Continuous Mode geschaltet, verändert sich der Nachrichtenfluss. Die möglichen Kommunikationsarten werden in diesem Abschnitt kurz vorgestellt. Der Hauptunterschied zum Basic Message Profile liegt vor allem darin, dass ein Gerät nun nicht mehr auf eine Request-Nachricht warten muss bis es die Observation schickt, sondern diese kontinuierlich verschicken kann. Eine Observation-Nachricht muss nach wie vor durch ein Acknowledgement bestätigt werden. Vergleicht man den Fluss der Nachrichten mit dem Basic Profile, so erkennt man, dass sowohl die Request-Nachricht als auch die End-Of-Topic-Nachricht fehlt. Diese sind bei diesem Profil nicht mehr nötig. Somit ist es möglich die Daten sofort nach der Messung zu übertragen.

Genau wie eine Observation-Nachricht kann eine Device Event-Nachricht ohne vorherige Anforderung verschickt werden. Da in diesem Modus das Gerät für längere Zeit an den Observation Reviewer angebunden ist, handelt es sich hierbei um eine wichtige Funktion. Dadurch kann beispielsweise der Observation Reviewer über eine schwache Batterie oder andere gerätespezifischen Informationen in Kenntnis gesetzt werden.

Im Continuous Mode muss sichergestellt sein, dass das Gerät sowohl Operator- als auch Patient-Nachrichten empfangen kann, sofern weder Gerät noch Observation Reviewer andere Nachricht versenden bzw. empfangen oder auf diese warten und diese Nachrichtenarten auch unterstützt werden.

Sind zwei Geräte für längere Zeit miteinander verbunden, so kann es durchaus zu einem ungewollten Verbindungsabbruch kommen. Um eine solche Störung auch zu Zeitpunkten, in denen das Gerät keine Daten sendet, zu erkennen, wird eine Keep Alive-Nachricht versendet. Das Gerät kann wie im Basic Profile auch Direktive-Nachrichten und eine Terminate-Nachricht empfangen. Auch die Einbindung von herstellerspezifischen Nachrichten und Direktiven sollte sowohl im Basic Mode als auch um Continuous Mode vorgesehen werden. Generell sollte es immer möglich sein eine Terminate-Nachricht versenden zu können. Dieser Modus ist vor allem für Geräte gedacht, die permanent über einen langen Zeitraum mit einem Observation Reviewer verbunden sind. Um den maximalen Nutzen aus einer Übertragung der Daten per WLAN zu ziehen sollte dieser Modus verwendet werden. Somit kann eine sofortige Verfügung der Daten im KIS erreicht werden. Denn im Gegensatz zum Basic Profile wird die Zeit, welche zwischen den Abfragen verstreicht, eingespart, da die Daten sofort nach der Messung gesendet werden können.

Asynchronous Mode

Durch eine Unterstützung des Asynchronous Mode lässt sich der Nachrichtenfluss optimieren. Es wird versucht den Durchsatz der Datenübertragung zu erhöhen, indem das Versenden der jeweiligen Acknowledegement-Nachrichten nicht direkt im Anschluss an den Empfang geschehen muss. So entfallen eventuelle Wartezeiten bei einer Verarbeitung der Nachrichten.

Dem Gerät ist es also möglich, sofern der asynchrone Modus unterstützt wird, eine Folge von Observation-Nachrichten zu versenden ohne auf die jeweilige positive Bestätigung über den Empfang zu warten. Das Ende der Übertragung wird hier mit einer End-Of-Topic-Nachricht angezeigt. Festzuhalten ist hier jedoch, dass eine auf Observation Reviewer-Seite empfangene Observation Nachricht für das Gerät erst korrekt versendet wurde, wenn das passende Acknowledgement zurückgesendet wurde. Bleibt dies aus, ist von einem Fehler auszugehen und die gesendete, jedoch nicht bestätigte Nachricht als nicht bearbeitet zu betrachten. Auch für Fehlerfälle sieht der POCT1-A Standard Vorgehensweisen vor.

Fehlerbehandlung

Kommt es während der Kommunikation zwischen einem Gerät und einem Observation Reviewer zu einem Fehler, bietet der Standard zwei Nachrichten an, die diesen Fehlerfall behandeln können. Für die Fälle, dass eine Nachricht unvollständig oder falsch angenommen wurde, sieht der Standard ein negatives Acknowledgement vor. Tritt ein solches Acknowledgement bei der Übertragung von Observations oder Device Events auf, gibt es drei verschiedene Möglichkeiten einer Weiterverarbeitung. • Es kann versucht werden dieselbe Nachricht noch einmal zu senden, wenn vermutet wird, dass es sich nur um ein temporäres Problem handelt. • Das Gerät kann mit der nächsten Nachricht fortfahren. • Eine End-Of-Topic-Nachricht kann gesendet werden.

In den Fällen nicht unterstützter oder empfangener Nachrichten, welche im derzeitigen Kommunikationszustand nicht möglich sind, wird eine Escape-Nachricht versendet. Verschickt das Gerät eine solche Nachricht, muss sichergestellt sein, dass es wieder in einen Kommunikationszustand versetzt wird, in dem es alle Nachrichten verarbeiten kann. Der Observation Reviewer muss jedoch mit dem nächsten abzuarbeitenden Punkt fortfahren.

Bewertung von POCT1-A

Vorteile von POCT1-A

Mit dem Einsatz von POCT1-A in POCT Geräten erreicht man in vielen Bereichen eine deutliche Verbesserung. Durch einen effizienteren Einsatz von Hard- und Software können enorme Einsparungen realisiert werden. Die Geräte lassen sich ohne weitere Anpassungen direkt ins KIS einbinden, unabhängig von Herstellern. Der Datenaustausch zwischen den Geräten und dem KIS ist kontrollierbar und die Nachrichten können validiert werden. Es besteht so auch die Möglichkeit eventuelle Fehler bei der Datenübertragung zu erkennen und auszuschließen. Hard- und Software lassen sich beliebig kombinieren und austauschen. Eine Onlinewartung der POCT Geräte ist mit Hilfe des Standards durchführbar. Neu kalibrierte und gewartete Geräte können von einer zentralen Stelle bzgl. ihres Statuses abgefragt werden. So behält man ständig den Überblick über den Wartungsstand der Geräte und verfügt über die Möglichkeit einer Qualitätskontrolle, welche nach der MPBetreibV auch gesetzlich gefordert ist.

Vergleich zu HL7

Unter dem Begriff HL7 verbirgt sich ein großes Werkzeug für Krankenhausinformationssysteme, mit dem nahezu alle Aufgaben in einem solchen System zu lösen sind. Es stellt sich demnach die Frage, warum die Entwicklung und Beschreibung von POCT1-A überhaupt notwendig war. Prinzipiell lässt sich sagen, dass die gesamte Funktionalität von POCT1-A durchaus mit Hilfe von HL7 durchführbar ist, jedoch muss man hierfür bestimmte Restriktionen und Anforderungen, die POCT Geräte an einen Standard stellen, berücksichtigen. HL7 bietet einen viel zu umfangreichen Funktionsumfang, und ist für POCT Anwendungen klar überdimensioniert. Bei der Entwicklung solcher Anwendungen müsste man sich erst Gedanken machen, welche Teile von HL7 Verwendung finden. Bei POCT Geräten handelt es sich um eigenständige Geräte, die über eine begrenzte Hardware verfügen und die eine reibungslose Kommunikation zur Verfügung stellen müssen.

Bewertung von POCT1-A

Der Speicherplatz für eine komplette POCT1-A Implementierung auf Geräteseite beschränkt sich auf weniger als ein Megabyte. Durch die klare Definition des Nachrichtenaustausches ist gewährleistet, dass eine eindeutige Interpretation des Standards gegeben ist. POCT1-A ist somit nicht als „Konkurrenzprodukt“ zu HL7 zu sehen, sondern vielmehr als eine Erweiterung. Darum befasst sich der zweite Teil des Standards auch mit der Weiterverarbeitung der gemessenen Werte und der Umwandlung von POCT1-A Nachrichten in HL7-konforme Nachrichten.