DE102012023412A1

DE102012023412A1 - Pumpenkompatibilitätstest

Info

Publication number: DE102012023412A1
Application number: DE102012023412.0A
Authority: DE
Inventors: Markus Strähle; Jürgen Manigel
Original assignee: Draeger Medical GmbH
Current assignee: Draegerwerk AG and Co KGaA
Priority date: 2012-11-30
Filing date: 2012-11-30
Publication date: 2014-06-05
Also published as: CN103845776A; US9623176B2; US20140163919A1; CN103845776B

Abstract

Die Erfindung betrifft eine Testvorrichtung (10), ein Funktionstestverfahren, ein Anästhesie- oder Beatmungsgerät (AB) und ein Computerprogrammprodukt zum Funktionstesten einer Infusionspumpe (G). Die Testvorrichtung (10) ist vorzugsweise auf dem Anästhesie- oder Beatmungsgerät (AB) implementiert und umfasst einen Speicher (MEM), ein Testmodul (T) und einen Controller (C). Das Testmodul (T) sendet einen Testbefehl (20) an die Infusionspumpe (G), die nach Befehlsausführung eine Antwort (30) an den Controller (C) zurücksendet. Der Controller (C) kann daraufhin die empfangene Antwort (30) mit einer Referenzantwort (30') auf Übereinstimmung vergleichen, um ein erfolgreiches Funktionstestergebnis auszugeben.

Description

Die vorliegende Erfindung liegt auf den Gebieten der Medizintechnik und der Elektronik. Die Erfindung betrifft insbesondere ein technisches Verfahren zur nachträglichen Freigabe von Gerätekombinationen in einem Verbund von medizintechnischen Geräten, insbesondere auf den Gebieten der Intensivmedizin und der Anästhesie.
Bei modernen medizintechnischen Systemen interagiert in der Regel eine Vielzahl von unterschiedlichen technischen Geräten über ein Netzwerk, die zu einem Verbund zusammengeschlossen sind. Der Verbund kann beispielsweise aus Patientenmonitoren, Infusionspumpen, Anästhesie- oder Beatmungsgeräten und/oder weiteren medizintechnischen Modulen und Systemen (ebenfalls umfassend Softwaresystemen, wie Patientendatenmanagementsystemen) bestehen.
Die einzelnen Geräte und Komponenten des medizintechnischen Verbundes (z. B. Patientenmonitor, Infusionspumpe, Anästhesie- und/oder Beatmungsgerät etc.) tauschen Daten über spezifische Kommunikationsschnittstellen aus. Des Weiteren können Schnittstellen zu externen Verarbeitungssystemen bereitgestellt sein, beispielsweise zu Patientendatenmanagementsystemen. Bekannt ist es, die Kompatibilität von zwei Kommunikationspartnern sicherzustellen. Dazu ist es vorgesehen, im Vorfeld spezifizierte Testfälle auf dem jeweils zu testenden Gerät auszuführen. Dies erfolgte bisher manuell durch einen Systemingenieur, der das jeweilige Gerät bedienen musste.
Dieses Vorgehen erweist sich jedoch aus unterschiedlichen Gründen als nachteilig, da damit ein enormer Wartungsaufwand und hohe Kosten verbunden sind. Sobald ein neues Software-Update auf einem der Geräte installiert worden ist, ist es aus regulatorischen Gründen notwendig, die Kompatibilität im Kontext des Gesamtsystems nachzuweisen.
Eine weitere Schwierigkeit ist darin zu sehen, dass die jeweiligen Komponenten und Geräte von unterschiedlichen Herstellern zu einem medizinischen Gesamtverbund kombiniert werden. Sobald eines der Geräte des Verbundes modifiziert worden ist (entweder durch Änderung der Software, Firmware oder durch anderweitige Änderungen), hat dies zur Folge, dass möglicherweise nicht verifizierte Gerätekombinationen im Verbund existieren. Dies muss sicher ausgeschlossen werden. Das bisherige manuelle Vorgehen birgt das Risiko, dass der Verbundbetreiber bzw. der Kunde (z. B. das Krankenhaus) die jeweilige Gerätekombination ohne Verifikation und auf eigene Verantwortung betreibt. Des Weiteren ist ein Nachteil darin zu sehen, dass der jeweilige Gerätehersteller keine Kenntnis über die jeweils betriebenen und möglicherweise nicht verifizierten Gerätekombinationen besitzt. Damit steigt der Aufwand zur Testung des Gesamtsystems.
Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, eine technische Umsetzung vorzustellen, mit der das Testen von unterschiedlichen medizintechnischen Geräten, insbesondere Infusionspumpen, die in einem Geräteverbund betrieben werden, automatisiert, verbessert und fehlerfreier ausgeführt werden kann. Dabei sollen auch unterschiedliche Programmversionen, die auf den einzelnen Geräten aufgespielt sein können, berücksichtigt werden, so dass das Gesamtsystem – auch nach der Auslieferung – auf Kompatibilität geprüft werden kann, ohne dass Änderungen an dem zu testenden Gerät notwendig sind.
Diese Aufgabe wird durch die beiliegenden Patentansprüche gelöst, insbesondere durch eine Testvorrichtung, ein medizinisches Gerät (insbesondere ein Anästhesie- oder Beatmungsgerät), ein computerimplementiertes Verfahren und durch ein Computerprogrammprodukt.
Im Folgenden wird die Erfindung anhand des Verfahrens beschrieben. Hierbei erwähnte Ausführungsformen, alternative Lösungen, weitere Merkmale und Vorteile sind ebenso auch auf die anderen Lösungen der vorstehend genannten Aufgabe zu übertragen (also auf das Computerprogrammprodukt und auf die Testvorrichtung und/oder das Gerät) und umgekehrt. Demnach können auch die Merkmale, die im Zusammenhang mit der Testvorrichtung beansprucht und/oder beschrieben sind, auch auf das Verfahren, das Gerät oder das Computerprogrammprodukt angewendet werden und umgekehrt. Dabei sind die jeweiligen funktionalen Merkmale des Verfahrens durch entsprechende Mikroprozessormodule oder Hardwaremodule implementiert, die dazu ausgebildet sind, die jeweilige Funktionalität zu übernehmen.
Gemäß einem Aspekt bezieht sich die Erfindung auf ein Verfahren zum Testen der Funktion einer Infusionspumpe, einer Dosierpumpe, einer Perfusionseinrichtung oder eines anderen medizintechnischen Gerätes, das in einem medizintechnischen Geräteverbund betrieben wird. Der Geräteverbund kann beispielsweise einen Patientenmonitor, ein Anästhesie- und/oder Beatmungsgerät und/oder weitere medizintechnische Applikationen umfassen. Die Geräte des Geräteverbundes interagieren über ein Kommunikationsprotokoll. Zumindest ein Teil der medizinischen Geräte des Geräteverbundes umfasst einen Speicher, in dem ein Programm (z. B. Firmware) abgelegt ist. Das Programm kann in unterschiedlichen Versionen installiert sein. Somit kann das Gerät mit unterschiedlichen Programmversionen betrieben werden, so dass der Geräteverbund auch unterschiedlich konfiguriert sein kann.
Das Verfahren umfasst folgende Verfahrensschritte:

– Bereitstellen einer Menge von Testbefehlen. Die Testbefehle werden vorzugsweise auf einer Testvorrichtung bereitgestellt und sind dazu bestimmt, auf der Infusionspumpe oder auf dem zu testenden medizinischen Gerät ausgeführt zu werden. Dabei ist der Testbefehl so ausgelegt, dass bei korrekter und fehlerfreier Funktion eine eindeutige Antwort als Referenzantwort zugeordnet werden kann. Mit anderen Worten ist der jeweilige Testbefehl so ausgelegt, dass bei korrektem Betrieb des medizinischen Gerätes auf den Testbefehl eine Referenzantwort erwartet werden kann. Die Zuordnung zwischen dem jeweiligen Testbefehl und der erwarteten Referenzantwort wird vorzugsweise in der Testvorrichtung gespeichert.
– Nach Abschluss einer Vorbereitungsphase kann die eigentliche Testphase eingeleitet werden, indem ein Testzustand auf dem medizinischen Gerät aktiviert wird.
– Nach Aktivieren des Testzustandes wird zumindest ein Testbefehl aus der bereitgestellten Menge von Testbefehlen von der Testvorrichtung über das Kommunikationsprotokoll an die Infusionspumpe oder an das zu testende medizintechnische Gerät gesendet.
– Der versendete Testbefehl wird daraufhin auf der Infusionspumpe oder auf dem zu testenden medizinischen Gerät ausgeführt. Nach vollständiger Ausführung des Testbefehls erzeugt die Infusionspumpe oder das medizinische Gerät ein Antwortsignal bzw. eine Antwortnachricht, die über das Kommunikationsprotokoll an die Testvorrichtung zurückgesendet wird. Die Antwortnachricht umfasst die Antwort auf den Testbefehl und kann darüber hinaus noch weitere Metainformationen umfassen (z. B. Zeitangaben, Versionsangaben, Positionsangaben etc.).
– Daraufhin kann auf der Testvorrichtung die empfangene Antwort aus der Antwortnachricht entpackt werden (z. B. entschlüsselt und von anderen Datensätzen getrennt) und mit der jeweiligen Referenzantwort auf Übereinstimmung verglichen werden. Falls die empfangene Antwort mit der, dem Testbefehl zugeordneten Referenzantwort übereinstimmt, kann ein erfolgreiches Funktionstestergebnis ausgegeben werden, das gegebenenfalls auch an weitere Instanzen des Geräteverbundes und/oder an weitere externe Instanzen weitergeleitet werden kann.

Im Folgenden werden die im Rahmen dieser Anmeldung verwendeten Begrifflichkeiten näher erläutert.
Der Begriff „Funktionstest” ist umfassend zu verstehen und schließt ein Testen des jeweiligen zu testenden Gerätes auf fehlerfreien Betrieb mit ein. Darüber hinaus umfasst das Testen einen Versionstest der angeschlossenen Komponenten des Geräteverbundes und überprüft somit die Zulässigkeit von unterschiedlichen Geräteversionen. Darüber hinaus ist auch ein Kompatibilitätstest umfasst. Ein vorteilhafter Aspekt der erfindungsgemäßen Lösung ist darin zu sehen, dass der Funktionstest auch einen Schnittstellentest umfasst. Damit kann auch die Schnittstelle zwischen dem Gerät, auf dem die Testvorrichtung installiert, und angeschlossenen, zu testenden Geräten überprüft werden. Falls beispielsweise die Kommunikationsschnittstelle unterbrochen ist (z. B. durch eine fehlerhafte oder fehlende Netzwerkverbindung) wird dies auf der Testvorrichtung erfasst, da auf den versendeten Testbefehl kein entsprechendes Antwortsignal empfangen werden kann. Um hier kurzfristige Bandbreitenschwankungen des Netzwerkes abbilden zu können, ist es in einer bevorzugten Ausführungsform der Erfindung vorgesehen, dass hier ein zeitlicher Schwellenwert vorkonfiguriert werden kann, innerhalb dessen die Antwort auf den jeweiligen Testbefehl auf der Testvorrichtung empfangen werden muss. Sobald dieser Schwellenwert überschritten wird, wird ein entsprechendes Fehlersignal ausgegeben.
Bei dem medizinischen Gerät handelt es sich vorzugsweise um eine Infusions- oder Dosierpumpe. Es liegt jedoch ebenso im Rahmen der Erfindung, hier andere elektronische, medizintechnische Geräte bereitzustellen, die in den Geräteverbund integriert werden sollen. Neben der Infusionspumpe können dies beispielsweise ein Patientenmonitor, ein Anästhesiegerät, ein Beatmungsgerät, ein Patientendatenmanagementgerät und/oder weitere medizintechnische Applikationen sein.
Vorzugsweise ist die Testvorrichtung auf einem der Geräte des Geräteverbundes installiert, z. B. auf einem Anästhesie- oder Beatmungsgerät. Es kann jedoch auch sein, dass die Testvorrichtung auf einem anderen Gerät installiert ist, oder auf einem externen Gerät, das in Datenaustausch mit den anderen Geräten des Geräteverbundes steht.
Bei dem Kommunikationsprotokoll kann es sich um ein standardisiertes Protokoll eines lokalen Netzwerkes (LAN – Lokal Area Network) oder eines WAN-Netzwerkes (Wide Area Network) handeln. Des Weiteren können hier spezifische Protokolle zum Datenaustausch verwendet werden. Darüber hinaus ist es möglich, eine drahtlose Kommunikation vorzusehen, so dass die jeweiligen Geräte beispielsweise über Bluetooth oder über andere drahtlose Protokolle interagieren.
Ein „Testbefehl” kann ein einzelner Testbefehl sein, der beispielsweise eine Datenanfrage an ein anderes medizinisches Gerät anfordert (z. B. ein Request-Befehl). Darüber hinaus ist es möglich, dass der Testbefehl seinerseits mehrere Testkommandos umfasst, die auf der Infusionspumpe oder auf dem zu testenden medizinischen Gerät ausgeführt werden sollen. In einem vereinfachten Beispiel könnte ein Testbefehl beispielsweise lauten: „Der Biomed soll an der Infusionspumpe eine Flussrate von 10 ml/h einstellen”. Für diesen Testbefehl kann eine bestimmte Referenzantwort erwartet werden. Die Referenzantwort kennzeichnet sich in diesem Fall beispielsweise dadurch, dass die am Gerät erfassten Daten im richtigen Format, in der richtigen Reihenfolge und/oder in der korrekten zeitlichen Abfolge eintreffen und an die Testvorrichtung übertragen werden. Des Weiteren wird damit überprüft, ob überhaupt Antwortsignale von dem zu testenden medizinischen Gerät an die Testvorrichtung zurückübertragen werden. Somit kann analysiert werden, ob sich der jeweilige Gegenspieler des Testbefehls. (also der Empfänger des Testbefehls) auch „wie erwartet” verhält. Falls der jeweilige Testbefehl kein Antwortsignal im eigentlichen Sinne erwartet, kann es eingestellt sein, dass bei erfolgreicher Datenübertragung zumindest ein Verifikationssignal als Antwortnachricht an die Testvorrichtung übertragen wird, um eine erfolgreiche Datenübertragung und Befehlsausführung zu signalisieren. Üblicherweise handelt es sich bei einem Testbefehl um eine Datenanfrage, die als Antwort eine bestimmte Abfolge von erfassten Daten umfasst. Alternativ können hier andere Kommandos bereitgestellt werden, die auf dem zu testenden Gerät ausgeführt werden sollen. Dabei kann es sich um Kommandos handeln, die voll automatisch ausgeführt werden (das Abgreifen von Signalen und/oder Werten), oder die manuell von einem Anwender unmittelbar an dem zu testenden medizinischen Gerät ausgeführt werden.
Der Testbefehl kann in einer vorteilhaften Ausführungsform der Erfindung einen Simulationsbefehl umfassen. Der Simulationsbefehl dient dazu, die Befehlsausführung auf dem zu testenden Gerät nicht auszuführen, sondern lediglich zu simulieren und simulierte Ergebniswerte als Antwortsignal zu erfassen, die dann dem Controller zur Überprüfung zugeleitet werden.
Werden z. B. mit Hilfe von pharmakokinetischen Modellen basierend auf der Dosierrate des Medikaments die Medikamentenkonzentration im Blut berechnet, so ist es für die Fehlerbetrachtung entscheidend, wie lange es dauert, bis die tatsächliche Dosierrate über das Protokoll übermittelt wird. Bei üblichen Dosierraten von max. 1600 ml/h wäre der Fehler durch eine Verzögerung im Übertragungsprotokoll bedingt durch eine nicht beliebig große Abtastrate max. 0,44 ml/s. Bei einem Wechsel der Dosierrate von z. B. 1600 ml/h auf null und einer Übertragungsverzögerung von z. B. 10 s würde der Volumenfehler mehr als 4 ml betragen, was in vielen Fällen nicht mehr akzeptabel wäre. So beeinflusst das dynamische Verhalten des Übertragungsprotokolls, die Berechnungsfehler der pharmakokinetischen Modelle.
Gemäß einer Variante der Erfindung kann ein Simulationsbefehl auf dem zu testenden Gerät ausgeführt werden, um die Dosierrate auf ein Kommando vom Testgerät hin zu reduzieren. Die neue simulierte Dosierrate wird über den normalen Daten-Übertragungsweg zum Testgerät zurück übertragen. Aus der Zeitdifferenz zwischen dem Kommando zur Verstellung der Dosierrate und der Befehlsausführung kann abgeleitet werden, wie groß der maximale Berechnungsfehler werden kann. Daraus wiederum kann eine Entscheidung auf dem Testgerät abgeleitet werden, ob die Qualität bzw. das Verhalten des Übertragungsprotokolls für die Art der Verwendung geeignet ist (bzw. fehlerfrei betrieben werden kann).
In einer Vorbereitungsphase können unterschiedliche Konfigurationen eingestellt werden. Insbesondere können hier die Testbefehle erzeugt werden. Desweiteren können die Referenzantworten auf den jeweiligen Testbefehl definiert und diesem zugeordnet werden (die Zuordnung wird vorzugsweise in einem Speicherbaustein abgelegt). In einer bevorzugten Weiterbildung der Erfindung ist es vorgesehen, dass die Zuordnung zwischen Testbefehl und Referenzantwort die gesamte Konfiguration des Geräteverbundes berücksichtigt. Insbesondere kann also die Zuordnung zwischen Testbefehl und Referenzantwort verbundspezifisch sein. Ebenso ist es möglich, dass die Zuordnung zwischen Testbefehl und Referenzantwort gerätezustandsspezifisch (insbesondere versionsspezifisch) und/oder konfigurationsspezifisch ist. „Konfigurationsspezifisch” meint in diesem Zusammenhang die Konfiguration des Gesamtsystems und berücksichtigt auch die unterschiedlichen Versionen der Geräte. Damit werden auch unterschiedliche Versionen von Firmware berücksichtigt, die auf den einzelnen Komponenten bzw. Geräten des Geräteverbundes installiert sind. Ist beispielsweise die Infusionspumpe in einer ersten Version in den Geräteverbund eingebunden, so kann es sein, dass der Testbefehl X eine Referenzantwort Y erzeugt, während die Referenzantwort Y² erwartet wird, wenn die Infusionspumpe in einer anderen Version betrieben wird. Die unterschiedlichen Versionen bzw. Konfigurationen werden in diesem Fall bei dem Funktionstest berücksichtigt.
Nach Ausführung des jeweiligen Testbefehls auf dem zu testenden medizinischen Gerät sendet das Gerät eine Antwortnachricht an die Testvorrichtung. Die Antwortnachricht umfasst die Antwort. Die Antwort kann ein Signal, eine Signalfolge (z. B. eine Folge von Parameterwerten oder eine Folge von akquirierten Messwerten, wie z. B. der Sauerstoffsättigung etc.) sein. Die Antwort kann jedoch auch nur ein binäres Signal sein, das beispielsweise als Flag implementiert ist und den Gut- bzw. Fehlerfall der Testbefehlausführung signalisieren soll. In einer vorteilhaften Weiterbildung der Erfindung umfasst die Antwortnachricht zusätzlich zu der eigentlichen Antwort noch weitere Daten, die in ein Paket als Antwortnachricht (z. B. in verschlüsselter Form und/oder mit zusätzlichen Metadaten) über das Kommunikationsprotokoll an die Testvorrichtung versendet werden.
Alternativ ist es möglich, dass die Antwort mit der Antwortnachricht identisch ist. In diesem Fall wird die auf dem zu testenden Gerät erzeugte Antwort auf den jeweiligen Testbefehl unmittelbar und unverändert als Antwortnachricht an die Testvorrichtung zurückgesendet.
Das „Funktionstestergebnis” kann im einfachsten Fall binär kodiert sein und im Wesentlichen zwei Zustände signalisieren: Fehlerfreie Testbefehlausführung und fehlerhafte Testbefehlausführung. Darüber hinaus kann das Funktionstestergebnis noch weitere Metadaten umfassen, wie beispielsweise den Zeitpunkt der Testausführung, die Dauer der Testausführung, Anzeige der jeweiligen Funktionen, Anzeige der aktiven Geräte des Geräteverbundes etc.
Wie vorstehend bereits erwähnt, gliedert sich das Funktionstestverfahren vornehmlich in zwei Phasen: Eine Konfigurations- bzw. Vorbereitungsphase, in der unterschiedliche Konfigurationen eingestellt werden können und in eine Testphase, in der die eigentliche Testung des Gerätes oder der Infusionspumpe erfolgt.
Gemäß einem Aspekt wird der Funktionstest voll automatisiert ausgeführt, so dass keine weiteren Benutzerinteraktionen notwendig sind. Alternativ ist es auch möglich, den Funktionstest semi-automatisch auszuführen, so dass beispielsweise auf der Infusionspumpe Aktionen seitens des Anwenders als Reaktion auf den Testbefehl ausgeführt werden müssen. Dabei können dann entsprechende Signale als Antwort erfasst und an die Testvorrichtung zurückgesendet werden.
In einer vorteilhaften Weiterbildung der Erfindung ist es vorgesehen, dass das Funktionstestergebnis automatisch auf anderen Instanzen zur Verfügung gestellt wird. Dies erweist sich insbesondere dann als vorteilhaft, wenn mehrere Infusionspumpen oder medizinische Geräte derselben Bauart in den Geräteverbund integriert sind. Falls der Funktionstest für eines der Geräte ein positives Testergebnis erzielen konnte, kann dieses Testergebnis automatisch auch für die anderen medizinischen Geräte derselben Bauart bereitgestellt werden, so dass die Testung auf den anderen Geräten dann nicht mehr erforderlich ist und vorteilhafterweise entfallen kann bzw., dass die anderen in konstruktiver und funktionaler Hinsicht identischen Geräte automatisch als verifiziert gelten. Damit kann dann auch eine Freigabe für die anderen Geräte derselben Bauart erreicht werden. Des Weiteren ist es möglich, auch nachträglich Gerätefreigaben bereitzustellen, falls medizinische Geräte derselben Bauart zu einem späteren Zeitpunkt an den Geräteverbund angeschlossen werden. Dann ist es nicht mehr notwendig, die neu angeschlossenen Geräte zu testen, falls bereits erfolgreiche Funktionstestergebnisse für diese Geräteart akquiriert werden konnten.
Gemäß einem Aspekt der Erfindung ist die Testvorrichtung auf einem Gerät des Geräteverbundes installiert, beispielsweise als elektronisches Zusatzmodul, das auch nachträglich auf dem Gerät installiert bzw. implementiert werden kann. Alternativ kann die Testvorrichtung jedoch auch als zentraler Dienst auf einem Server installiert sein, der von den medizinischen Geräten – beispielsweise über ein Netzwerk – zugreifbar ist. Ebenso ist es möglich, dass die Testvorrichtung auf einem gesonderten Testmodul bereitgestellt wird, das zur Testung vorgesehen ist.
Gemäß einem Aspekt der Erfindung sind die zu testenden medizinischen Geräte ohne weitere Änderungen bzw. Anpassungen oder Zusatzinstallationen in den Geräteverbund eingebunden. Die zu testenden medizinischen Geräte werden also wie in dem jeweiligen Anwendungsfall vorgesehen betrieben. Die dabei erfassten Daten bzw. Signale werden als Antwortsignale an die Testvorrichtung weitergeleitet. Vorteilhafterweise müssen also keine zusätzlichen Installationen auf dem zu testenden medizinischen Gerät ausgeführt werden.
In einer alternativen Ausführungsform der Erfindung ist es jedoch auch möglich, dass auf zumindest einem der zu testenden medizinischen Geräte eine zusätzliche Testroutine implementiert wird. Die Testroutine dient als Gegenspieler für die Testvorrichtung, die auf einem jeweils anderen medizinischen Gerät des Geräteverbundes installiert ist. Die Testvorrichtung sendet Testbefehle an die Testroutine, die zum einen dazu ausgebildet sein kann, die empfangenen Testbefehle auszuführen und entsprechende Antwortsignale an die Testvorrichtung zurückzusenden und die desweiteren dazu ausgebildet sein kann, zusätzliche Testmaßnahmen in Beantwortung des Testbefehls auf dem zu testenden medizinischen Gerät auszuführen. Das Ergebnis (erfolgreich oder nicht erfolgreich) kann ebenfalls an die Testvorrichtung übertragen werden.
Üblicherweise wird der Funktionstest von der Testvorrichtung initiiert. Die Testvorrichtung kann auf einem Anästhesie- oder Beatmungsgerät oder auf einem anderen medizinischen Gerät installiert sein (z. B. eine Workstation, auf der ein Patientendatenmanagementsystem installiert ist, Gerät, auf dem ein Expertensystem zur Entscheidungsunterstützung während des Gerätebetriebs installiert ist).
In dem vorher geschilderten Ausführungsbeispiel geht die Initiative des Funktionstestes von dem Gerät aus, auf dem die Testvorrichtung installiert ist (z. B. von einem Patientenmonitor oder einem Anasthesiegerät). Alternativ kann es jedoch auch sein, dass der Funktionstest durch das zu testende Gerät selbst initiiert wird. Beispielsweise kann es vorgesehen sein, dass automatisch dann ein Funktionstest initiiert wird, falls der Geräteverbund erkennt, dass ein neues Gerät in den Geräteverbund eingebunden wird. Ebenso ist es möglich, dass eine zentrale Steuerstelle den Funktionstest auslöst. Dabei kann das Auslösen des Funktionstestes ereignisgesteuert und/oder zeitgesteuert ausgeführt werden.
Um den Hersteller der jeweiligen medizinischen Geräte auch über den Ausgang des Funktionstestes zu informieren, ist es in einer bevorzugten Weiterbildung der Erfindung vorgesehen, dass das jeweilige Funktionstestergebnis auch automatisch an andere Computer-basierte Instanzen (insbesondere an den Gerätehersteller) weitergeleitet wird, um diesen über den aktuellen Stand der betriebenen und als zulässig geprüften Kombinationen zu informieren.
Gemäß einem Aspekt der Erfindung werden die Testbefehle auf dem medizinischen Gerät bereitgestellt, auf dem die Testvorrichtung installiert ist, während der Testbefehl an sich auf dem Kommunikationspartner, insbesondere dem Testbefehlempfänger und somit dem zu testenden medizinischen Gerät ausgeführt werden. Der eigentliche Test erfolgt durch Vergleich der empfangenen Antwort mit der jeweiligen Referenzantwort auf der Testvorrichtung. Somit kann der Funktionstest als verteiltes System, und insbesondere als Client-Server-System ausgeführt werden, das teilweise auf der Testvorrichtung und teilweise auf dem zu testenden medizinischen Gerät ausgeführt wird.
Der Funktionstest überprüft somit das funktionale Zusammenwirken der medizinischen Geräte, die innerhalb des Geräteverbundes zusammengeschlossen sind.
Gemäß einem weiteren Aspekt der Erfindung wird die vorstehende Aufgabe durch eine Testvorrichtung gelöst, die zum Funktionstesten einer Infusionspumpe oder eines anderen medizinischen Gerätes innerhalb eines Geräteverbundes ausgebildet ist. Der Geräteverbund umfasst neben dem zu testenden medizinischen Gerät (das im Folgenden als Infusionspumpe bezeichnet wird, darauf aber nicht beschränkt ist) optional noch einen Monitor, ein Anästhesiegerät oder ein Beatmungsgerät oder andere medizintechnische Geräte, die über ein Kommunikationsprotokoll in Datenaustausch stehen. Die jeweiligen medizinischen Geräte können in unterschiedlichen Versionen oder Konfigurationen in den Geräteverbund eingebunden sein (z. B. in unterschiedlichen Firmwareversionen).
Die Testvorrichtung umfasst einen Speicher, zumindest ein Testmodul und zumindest einen Controller. Der Speicher dient zur Speicherung von einer Menge von Testbefehlen und einer Menge von Referenzantworten. Dabei ist jeweils einem Testbefehl genau eine Antwort als Referenzantwort zugeordnet. Die Referenzantwort ist vorzugsweise verbundspezifisch und/oder konfigurationsspezifisch. Bei dem Speicher handelt es sich vorzugsweise um einen nicht flüchtigen Speicher (z. B. EEPROM). Der Speicherinhalt kann auch während des Betriebs der Testvorrichtung modifiziert werden.
Das Testmodul ist dazu bestimmt, zumindest einen Testbefehl aus der bereitgestellten Menge von Testbefehlen (aus dem Speicher) über das Kommunikationsprotokoll an die jeweils zu testende Infusionspumpe zur Bearbeitung zu senden. Das Testmodul kann noch weitere Schnittstellen zu externen Instanzen haben, um beispielsweise ein Initiations- oder ein Testaktivitätssignal zu empfangen (letzteres dient zur Triggerung des Tests).
Der Controller ist dazu ausgebildet, eine Antwort auf den auf dem zu testenden Gerät ausgeführten Testbefehl zu empfangen und die empfangene Antwort mit der Referenzantwort auf Übereinstimmung zu vergleichen, die den jeweiligen Testbefehl zugeordnet ist. Bei Übereinstimmung zwischen Antwort und Referenzantwort kann ein erfolgreiches Funktionstestergebnis ausgegeben werden.
In einer alternativen Ausführung der Testvorrichtung sind das Testmodul und der Controller in einem gemeinsamen Test- und Controller-Modul ausgebildet. Damit kann die Testvorrichtung einfacher und kostengünstiger konstruiert sein.
Die Testvorrichtung ist auf einem Befehlssender ausgebildet, während das zu testende Gerät als Befehlsempfänger dient. Befehlssender und/oder Befehlsempfänger können durch medizintechnische Module und Geräte ausgebildet sein, umfassend Patientenmonitore, komplexe medizintechnische Systeme, wie Patientendatenmanagementsysteme, Anästhesiegeräte, Beatmungsgeräte und einzelne Module, wie Infusionspumpen oder dergleichen.
Alternativ kann die Testvorrichtung auch auf einem zentralen Server ausgebildet sein, der mit einem Testbefehl-Repository in Datenaustausch steht.
Gemäß einer bevorzugten Ausführungsform sind grundsätzlich zwei Betriebszustände vorgesehen:

1. Ein normaler Betriebszustand und
2. Ein Testzustand. Der Testzustand kann durch das Testaktivierungssignal aktiviert bzw. initiiert werden. In diesem Fall ist der Controller vorzugsweise dazu ausgebildet, die Testvorrichtung nach Erhalt des Testaktivierungssignals zu aktivieren. Üblicherweise befinden sich die medizinischen Geräte im funktionalen Betriebsmodus und der Controller ist deaktiviert.

Ein besonderer Vorteil an der erfindungsgemäßen Lösung ist darin zu sehen, dass der Speicher jederzeit modifiziert beschrieben werden kann. Falls beispielsweise ein zu testendes Gerät in seinem Funktionsumfang erweitert wird und somit auf einen bestimmten Testbefehl zusätzliche Daten als Antwort auf den jeweiligen Testbefehl erfasst, so wird die Referenzantwort auf den jeweiligen Testbefehl automatisch angepasst. Die zulässigen Referenzantworten umfassen somit die neu erfassten Daten und können bei allen zukünftigen Funktionstests unmittelbar berücksichtigt werden.
In einer vorteilhaften Weiterbildung der Erfindung ist die Testvorrichtung zusätzlich mit einer Kontrolleinheit ausgebildet, die Sensoren und/oder Aktuatoren umfasst, die zur Ausführung des Testbefehls auf demjenigen medizinischen Gerät ausgebildet sind, auf dem die Testvorrichtung installiert ist. Die Kontrolleinheit erzeugt eine Kontrollantwort auf den Testbefehl und leitet diese an den Controller weiter. Der Controller kann daraufhin einen zusätzlichen Vergleich durchführen. Die empfangene Antwort des zu testenden medizinischen Gerätes wird somit nicht nur mit der Referenzantwort auf Übereinstimmung verglichen, sondern zusätzlich noch mit der auf den Controller bereitgestellten Kontrollantwort, die auf der Kontrolleinheit bereitgestellt wird. Damit kann die Testsicherheit erhöht werden und weiterhin ist es möglich, das aktuelle, zeitliche Verhalten zu berücksichtigen.
Eine weitere Aufgabenlösung besteht in einem medizintechnischen Gerät, insbesondere in einem Patientenmonitor oder einem Anästhesie- oder Beatmungsgerät, das mit einer Testvorrichtung ausgebildet ist, die vorstehend beschrieben wurde.
Ein wesentlicher Vorteil ist darin zu sehen, dass die Testvorrichtung auch nachrüstbar ist, und auch nach Auslieferung des medizintechnischen Gerätes auf demselben installiert werden kann.
Ein wesentlicher Aspekt der vorliegenden Erfindung ist darin zu sehen, dass das zu testende medizinische Gerät ohne weitere Änderungen am Gerät oder am Kommunikationsprotokoll getestet werden kann. Insbesondere ist es nicht notwendig, einen zusätzlichen Kontrollkanal zwischen Testvorrichtung und zu testender Infusionspumpe bereitzustellen. Der Funktionstest wird über das übliche Kommunikationsprotokoll abgewickelt. Mit anderen Worten sind die Schnittstelle, die zum Betrieb des zu testenden medizinischen Gerätes verwendet wird und die Schnittstelle, die zum Testen des medizinischen Gerätes verwendet wird, identisch. Bei beiden handelt es sich über das ohnehin bereitgestellte Kommunikationsprotokoll. Dies hat den wesentlichen Vorteil, dass kein zusätzlicher Installationsaufwand und keine zusätzlichen Einstellungen an dem zu testenden Gerät ausgeführt werden müssen.
Die vorstehend beschriebenen, erfindungsgemäßen Ausführungsformen des Verfahrens können auch als Computerprogrammprodukt mit einem Computerprogramm ausgebildet sein, wobei der Computer zur Durchführung des oben beschriebenen, erfindungsgemäßen Verfahrens veranlasst wird, wenn das Computerprogramm auf dem Computer bzw. auf einem Prozessor des Computers geladen oder ausgeführt wird.
Eine alternative Aufgabenlösung besteht auch in einem Computerprogramm mit Computer-Programmcode zur Durchführung aller Verfahrensschritte des beanspruchten oder oben beschriebenen Verfahrens, wenn das Computerprogramm auf dem Computer ausgeführt wird. Dabei kann das Computerprogramm auch auf einem maschinenlesbaren Speichermedium gespeichert sein.
Eine alternative Aufgabenlösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, Computer-implementierten Verfahrens bestimmt ist und von einem Computer lesbar ist.
Es liegt im Rahmen der Erfindung, dass nicht alle Schritte des Verfahrens zwangsläufig auf ein und derselben Computerinstanz ausgeführt werden müssen, sondern sie können auch auf unterschiedlichen Computerinstanzen ausgeführt werden. Auch kann die Abfolge der Verfahrensschritte gegebenenfalls variiert werden.
Darüber hinaus ist es möglich, dass einzelne Abschnitte des vorstehend beschriebenen Verfahrens in einer verkaufsfähigen Einheit und die restlichen Komponenten in einer anderen verkaufsfähigen Einheit – sozusagen als verteiltes System – ausgeführt werden können.
In der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen. In dieser zeigen:
1 eine übersichtsartige Darstellung eines medizintechnischen Gerätes mit einer Testvorrichtung und einer zu testenden Infusionspumpe entsprechend einer bevorzugten Ausführungsform der Erfindung,
Im Folgenden wird die Erfindung anhand der 1 näher erläutert.
1 zeigt übersichtsartig auf schematische Weise Bestandteile eines medizinischen Geräteverbundes, die über zumindest ein Kommunikationsprotokoll P in Datenaustausch stehen.
Das hauptsächliche Anwendungsgebiet der Erfindung liegt auf den Gebieten der Intensivmedizin und der Anästhesie und bezieht sich auf einen Geräteverbund, der unter anderem ein Anästhesiegerät oder ein Beatmungsgerät AB und andere medizinische und elektronische Einheiten auf dem Gebiet der Intensivmedizin und der Anästhesie umfasst, wie beispielsweise eine Infusionspumpe G. Typischerweise sind in den Geräteverbund noch weitere elektronische Geräte eingebunden, wie beispielsweise ein Patientenmonitor: In einer bevorzugten Ausführungsform kann es sich beispielsweise um den Patientenmonitor der Anmelderin handeln, der zum stationären Monitoring für Vitaldaten eines Patienten ausgebildet ist und mit integriertem Netzteil und Flachbildschirm zur Anzeige der Daten bereitgestellt werden kann. Je nach Ausführungsform ist der Patientenmonitor dazu ausgebildet, mehrere physiologische Daten des Patienten zu erfassen und anzuzeigen, darunter beispielsweise: EKG-Daten mit einer Arrhythmieerkennung, Atmungsdaten, die beispielsweise mit einer Impedanz-Pneumographie erfasst werden, Pulsoxymetrie-Daten, Daten zur Sauerstoffsättigung des Blutes (insbesondere des Anteils des Oxyhämoglobins am funktionellen Hämoglobin), Pulsdaten, die beispielsweise mit einer Transmissionsspektrophotometrie gemessen werden, nicht-invasive Blutdruckdaten.
Je nach Ausführung ist es jedoch auch möglich, anstatt der Infusionspumpe oder der Perfusionseinrichtung G oder zusätzlich zur Pumpe G noch weitere medizintechnische Geräte oder Module in den Verbund einzubinden, beispielsweise einen Adapter für ein Gerät zur invasiven Messung des Blutdrucks, der Temperatur, des Gasmonitorings, zur Messung von neurologischen Werten, insbesondere EEG-Daten etc. In den Geräteverbund können des Weiteren Geräte eingebunden sein, die die erfassten Geräte weiter auswerten und verarbeiten, insbesondere ein Patientendatenmanagementgerät und weitere Computerbasierte Applikationen.
In der bevorzugten Ausführungsform besteht der Geräteverbund zumindest aus einer Quelle, an der Daten akquiriert werden und einer Senke, die dazu bestimmt ist, die an den Datenquellen akquirierten Daten zu verarbeiten. Die Quelle und/oder die Senke sind technische Geräte, die über entsprechende Schnittstellen zum Datenaustausch verfügen und sind in der Regel Computer-basiert. Die Quelle und/oder Senke verfügen üblicherweise über integrierte Schaltkreise (z. B. FGPA, Field Programmable Gate Array), um spezifische Funktionen zu implementieren.
In den meisten Anwendungsfällen und in der auch in der Figur dargestellten, bevorzugten Ausführungsform der Erfindung wird ein Patientenmonitor AB an zumindest eine Infusionspumpe G gekoppelt. In 1 ist nur eine Pumpe G dargestellt; es liegt jedoch ausdrücklich ebenso im Rahmen der Erfindung, eine parallele Testung von mehreren Pumpen oder anderen Geräten G auszuführen.
In 1 ist oben ein Patientenmonitor dargestellt, der in diesem Ausführungsbeispiel das Anästhesie- oder Beatmungsgerät AB ersetzen soll. Der. Patientenmonitor AB kommuniziert über das Kommunikationsprotokoll P mit der Infusionspumpe G (unten dargestellt). Des Weiteren können noch weitere medizinische Geräte G in den Verbund eingebunden sein.
In der Praxis zeigt es sich, dass die jeweiligen elektronischen bzw. Computerbasierten Geräte (Patientenmonitor, Pumpe, Messgerät etc.) mit unterschiedlichen Software-/Firmware- oder (konstruktiv unterschiedlichen) Geräteversionen betrieben werden, die in Kombination verifiziert bzw. freigegeben werden müssen. So ist es beispielsweise möglich, dass die Pumpe G mit einer ersten Softwareversion des Patientenmonitors AB betrieben werden kann und funktioniert, während sie mit einer zweiten Softwareversion des Patientenmonitors AB nicht mehr funktioniert. Der Kontext ist somit entscheidend für einen fehlerfreien Betrieb des Gesamtverbundes. Dabei sind alle angeschlossenen Sub-Systeme mit deren Softwareversionen und Konfigurationen zu berücksichtigen. Erschwerend kommt hinzu, dass die einzelnen Geräte G von unterschiedlichen Herstellern stammen und somit erst nach Auslieferung des jeweiligen Gerätes feststeht, mit welchen weiteren Geräten die Geräte G interagieren müssen.
Die hier vorgeschlagene Testvorrichtung und das Testverfahren ermöglicht es, dass auch nachträglich, insbesondere nach Auslieferung der jeweiligen Geräte G eine Freigabe bzw. ein Überprüfen einer fehlerfreien Funktion im Geräteverbund sichergestellt werden kann. Dieses Testen kann voll automatisiert ausgeführt werden.
Um die Daten, die an der Infusionspumpe G generiert werden, auf dem Patientenmonitor AB zu verarbeiten, ist das Kommunikationsprotokoll P vorgesehen. Von der Infusionspumpe G werden über das Kommunikationsprotokoll P, z. B. der Medikamentenname und die Verdünnung des Medikamentes sowie das applizierte Volumen und die laufende Dosisrate übertragen. Das Kommunikationsprotokoll P ist herstellerspezifisch in der Infusionspumpe G implementiert.
Erfindungsgemäß werden über genau denselben Kommunikationskanal P nun zusätzliche Datenpakete zum Testen des Gerätes G gesendet. Wie in 1 dargestellt, sendet der Patientenmonitor AB zumindest einen Testbefehl 20 an die Infusionspumpe G. Der Testbefehl kann auch mehrere Kommando-Sequenzen umfassen. Es kann sich jedoch alternativ auch um einen monolithischen Befehlsblock handeln. Dazu wird auf den Patientenmonitor AB eine Menge von möglichen Testbefehlen bereitgestellt, die dann anwendungsspezifisch ausgewählt werden können. Der Testbefehl wird jedoch nicht unmittelbar auf dem Patientenmonitor AB ausgeführt oder auf dem Gerät, auf dem eine Testvorrichtung 10 installiert ist, sondern wird zunächst über das Kommunikationsprotokoll P an die Infusionspumpe G übertragen, um dort (auf der Pumpe) ausgeführt zu werden. Die Befehlsausführung hat zur Folge, dass auf der Pumpe G Ergebnisdaten akquiriert werden. Bei den Ergebnisdaten kann es sich um Messdaten handeln (wie beispielsweise EEG-Daten, EKG-Daten, Puls, Temperatur oder weitere Vitaldaten des Patienten, Daten zur Narkosetiefe oder pharmakokinetische oder pharmakodynamische Daten etc.). Alternativ können die Ergebnisdaten auch nur ein Signal sein, die eine fehlerfreie Ausführung des Testbefehls oder eine fehlerhafte Ausführung signalisieren. Als Antwort auf den Testbefehl 20 wird somit auf der Infusionspumpe G eine Referenzantwort 30 erzeugt, die über das Kommunikationsprotokoll P an den Patientenmonitor AB zurückübertragen wird, um dort in der Testvorrichtung 10 verarbeitet zu werden.
In dem in 1 dargestellten Ausführungsbeispiel ist die Testvorrichtung 10 auf einem Patientenmonitor AB implementiert. Andere Ausführungsbeispiele sehen jedoch vor, das die Testvorrichtung 10 auch auf einem Anästhesiegerät oder einem Beatmungsgerät AB installiert sein kann. Ebenso ist es möglich, dass die Testvorrichtung 10 auf einem zentralen Server installiert ist, der ebenso über ein Netzwerk NW mit den Geräten G in Datenaustausch steht.
Die Testvorrichtung 10 umfasst einen Speicher MEM, ein Testmodul T und einen Controller C. Der Speicher ist dazu ausgelegt, eine Menge von vorkonfigurierten Testbefehlen 20 zu speichern. Dabei ist ebenfalls in einer Konfigurationsphase bestimmt worden, welche Antwort auf den Testbefehl 20 jeweils erwartet wird. Diese erwartete Antwort ist als Referenzantwort dem jeweiligen Testbefehl 20 zugeordnet.
In dem Speicher liegen also Zuordnungen von Testbefehlen und Referenzantworten. Schematisch lässt sich dies wie folgt beschreiben:

– Erster Testbefehl – Erste Referenzantwort
– Zweiter Testbefehl – Zweite Referenzantwort
– ...
– N-ter Testbefehl – N-te Referenzantwort.

Ein besonderer Vorteil der Erfindung ist darin zu sehen, dass die jeweiligen Testbefehle 20, die Referenzantworten und/oder die Zuordnungen zwischen Testbefehl und Referenzantwort in einer Konfigurationsphase dynamisch an den jeweiligen Anwendungsfall angepasst werden können. Somit ist die bei einem fehlerfreien Betrieb erwartete Referenzantwort verbundspezifisch. „Verbundspezifisch” bedeutet in diesem Kontext, dass die erwartete Referenzantwort die in dem Geräteverbund eingebundenen Geräte G mit deren jeweiligen Softwareversionen berücksichtigt. Desweiteren kann die Zuordnung zwischen Referenzantwort und Testbefehl 20 auch konfigurationsspezifisch sein, was bedeutet, dass die jeweilige Konfiguration des Gerätes G und/oder des gesamten Geräteverbundes berücksichtigt wird. Mit anderen Worten kann eine andere Referenzantwort erwartet werden, wenn das jeweilige Gerät G mit anderen Funktionen aktiviert bzw. betrieben werden soll oder in einem anderen Geräteverbund gekoppelt ist, der noch zusätzliche Geräte umfasst oder wenn das jeweilige Gerät G mit einer anderen Softwareversion betrieben wird.
Das Testmodul T ist in einer bevorzugten Ausführungsform als Sendeeinheit ausgebildet und dient dazu, den ausgewählten Testbefehl 20 über das Kommunikationsprotokoll P an die Infusionspumpe G zu senden.
Der Controller C ist als Empfangs- und Verarbeitungseinheit ausgebildet und ausgelegt, um die von der Infusionspumpe G empfangene Antwort 30 auf den jeweiligen Testbefehl 20 zu empfangen. Die Antwort wird dann mit der, dem Testbefehl 20 zugeordneten Referenzantwort auf Übereinstimmung verglichen. Bei Übereinstimmung kann ein erfolgreiches Funktionstestergebnis ausgegeben werden. Damit kann sichergestellt werden, dass sich die Infusionspumpe G auf den jeweiligen Testbefehl 20 genauso wie erwartet verhält und die erwartete und vorgesehene Antwort 30 liefert (die mit der Referenzantwort übereinstimmt).
Unter Bezugnahme auf die 1 wird im Folgenden ein Ablauf gemäß einer bevorzugten Ausführungsform näher beschrieben.
Das Funktionstestverfahren gliedert sich in zwei Phasen: In eine Konfigurationsphase und in eine Testphase, die sich an die Konfigurationsphase anschließt, aber zeitlich entkoppelt ausgeführt werden kann.
In der Konfigurationsphase werden unterschiedliche Testbefehle für unterschiedliche Geräte G mit unterschiedlichen Softwareversionen und den unterschiedlichen Konfigurationen im Gesamtgeräteverbund erzeugt. Ebenso werden erwartete Referenzantworten auf die jeweiligen Testbefehle 20 erzeugt und diesen zugeordnet. Die Zuordnung zwischen dem jeweiligen Testbefehl 20 und der erwarteten Referenzantwort wird gespeichert. In komplexeren Ausführungsformen der Erfindung können hier noch weitere Verfahrensschritte ausgeführt werden. So ist es beispielsweise möglich, noch zu konfigurieren, in welchem Zeitintervall die Antwort eingehen muss, um eine zu hohe Latenzzeit als Fehler werten zu können. Falls mehrere Geräte parallel getestet werden sollen, kann hier noch konfiguriert werden, von welchem Gerät G die erhaltene Antwort 30 kommt.
Zu Beginn der Testphase muss das zu testende Gerät G von einem Betriebsmodus in einen Testmodus überführt werden, um den Testzustand auf dem medizinischen Gerät G zu aktivieren. Dazu kann es vorgesehen sein, dass der Patientenmonitor AB oder die Testvorrichtung 10 ein Aktivierungssignal an das Gerät G sendet. Das Senden des Aktivierungssignals kann zeitabhängig und/oder ereignisabhängig (z. B. beim Einbinden von zusätzlichen Geräten G in den Geräteverbund, beim Erkennen von neuen Softwareversionen, bei Erkennen eines vorhergehenden Fehlerfalls etc.) ausgelöst werden. Der Zustandsübergang ist insbesondere bei medizinischen Geräten der Intensivmedizin und der Anästhesie relevant, um einen funktionsfehlerfreien Betrieb des Gerätes sicher gewährleisten zu können.
In einem zweiten Schritt der Testphase wird der Testbefehl 20 auf der Testvorrichtung 10 ausgewählt und an die Infusionspumpe G zur Ausführung gesendet. Dieser Schritt wird auf der Testvorrichtung 10 oder auf dem Patientenmonitor AB ausgeführt.
In einem dritten Schritt der Testphase wird der Testbefehl 20 auf der zu testenden Infusionspumpe G ausgeführt. Nach Befehlsausführung wird die Antwort 30 auf der Pumpe erfasst und daraus eine Antwortnachricht generiert. Die Antwortnachricht kann zusätzlich zur Antwort 30 noch weitere Daten umfassen, wie beispielsweise Zeitangaben, Versionsangaben, Netzwerkangaben, Adressangaben (z. B. eine IP-Adresse oder eine sonstige Netzwerkprotokolladresse des Gerätes G, falls mehrere Geräte G parallel und zeitgleich getestet werden und um den Eingang von deren Antworten 30 eineindeutig auf der Testvorrichtung 10 identifizieren zu können). Es ist jedoch auch möglich, dass die Antwort 30 unverändert als Antwortnachricht an die Testvorrichtung 10 zurückgesendet wird.
Nach Erhalt der Antwortnachricht mit der Antwort 30 auf der Testvorrichtung 10 kann die empfangene Antwort 30 mit der Referenzantwort, die dem jeweiligen Testbefehl 20 zugeordnet ist, verglichen werden.
Bei Übereinstimmung wird ein erfolgreiches Testergebnis ausgegeben. Bei fehlender Übereinstimmung kann ein Fehlersignal ausgegeben werden (optisch und/oder akustisch und/oder in anderen Datenformaten).
Da Verfahren kann nach dem Vergleich oder nach Ausgabe des Funktionstestergebnisses nochmal einen weiteren Testdurchlauf ausführen. Damit kann das Verfahren repetitiv für weitere Testbefehle 20 für dasselbe Gerät G ausgeführt werden. Ebenso ist es möglich, dass sequenziell und/oder parallel mehrere Geräte G getestet werden.
Im Folgenden werden unterschiedliche Anwendungsszenarien für die erfindungsgemäße Testung beschrieben.
Ein Patientenmonitor AB eines ersten Herstellers erhält beispielsweise Daten über die Schnittstelle P der Infusionspumpe G, wobei die Infusionspumpe G von einem zweiten Hersteller gefertigt ist. Aus den Daten soll der Patientenmonitor AB dann weitere Daten berechnen. Die Kombination aus Patientenmonitor AB und Infusionspumpe G ist vom ersten Hersteller verifiziert und zugelassen. Falls nun ein Software-Upgrade auf der Infusionspumpe G durch den zweiten Hersteller erfolgt, ist die Kombination von Patientenmonitor AB und Infusionspumpe G nicht mehr verifiziert. Grundsätzlich hat der zweite Hersteller keine Kenntnis darüber, in welchem konkreten Anwendungsfall seine Infusionspumpe G betrieben wird, insbesondere mit welchem Monitor sie betrieben wird.
In einem ersten Anwendungsbeispiel erkennt die Testvorrichtung 10 des Patientenmonitors AB automatisch eine geänderte Softwareversion der Pumpe G und ermöglicht eine nachträgliche automatische Verifizierung der Pumpenschnittstelle P. Dazu wird eine, in der Testvorrichtung 10 definierte und vorkonfigurierbare Testroutine durchgeführt. Dazu kann auf der Testvorrichtung 10 eine Folge von Testbefehlen 20 implementiert sein, die über bestimmte Anweisungen entweder automatisch und/oder manuell durch einen Anwender ausgeführt werden. Dabei kann der Anwender beispielsweise Einstellwerte an der Infusionspumpe G einstellen. Die Pumpe G übermittelt anschließend nach Ausführung der Testbefehle 20 die Einstellwerte über das unveränderte und integrierte Pumpenexportprotokoll P an den angeschlossenen Patientenmonitor AB. Daraufhin kann die Testvorrichtung 10, die auf dem Patientenmonitor AB installiert ist, die empfangenen Werte verarbeiten. Sobald Akzeptanzkriterien erfüllt sind und ein erfolgreicher Funktionstest bestätigt ist, kann die Kompatibilität zwischen dem Patientenmonitor AB und der aktualisierten Pumpenversion G erklärt werden.
In einer vorteilhaften Weiterbildung der Erfindung kann die Testvorrichtung 10 durch ein zusätzliches Testhilfsmittel erweitert werden. Beispielsweise kann das Testhilfsmittel eine Kontrolleinheit K und insbesondere ein Flusssensor sein. Der Flusssensor dient somit als Referenzmodul für das zu testende Gerät G, in diesem Fall die Infusionspumpe G. Der Flusssensor kann ebenfalls mit dem Testbefehl 20 gespeist werden und daraufhin eine Kontrollantwort generieren. Damit wird es möglich, die tatsächlich von der zu testenden Infusionspumpe G empfangene Antwort 30 mit zwei Referenzwerten zu vergleichen: Zum einen mit der Referenzantwort, die ohnehin im Speicher M der Testvorrichtung 10 hinterlegt ist und zusätzlich mit der Kontrollantwort, die das Testhilfsmittel ausgibt. Der Flusssensor kann zusätzlich noch weitere Werte als Kontrollantwort generieren, um beispielsweise die Dynamik des Systems mit ihrem Zeitverhalten besser auswerten zu können. Ein wesentlicher Vorteil ist darin zu sehen, dass die Kontrolleinheit K temporär installiert wird und unmittelbar nach Beendigung des Testdurchlaufs auch wieder vom Gerät AB entfernt werden kann. Die Kontrolleinheit K dient zur zusätzlichen Überprüfung und damit zur Erhöhung der Testsicherheit.
In einem weiteren Ausführungsbeispiel kann das zu testende Gerät G ein zusätzliches Simulationsmodul umfassen. Das Simulationsmodul umfasst eine Aktuatorik, eine Steuerungssoftware für die Aktuatorik, Schnittstelle(n) für den Datenexport und für Einspeisung von Simulationsdaten zum Export der Daten. Die Simulationsdaten können dabei entweder fest in die Infusionspumpe G integriert sein. Alternativ können die Simulationsdaten auch durch eine externe Ansteuerung gesetzt werden. Sobald der Patientenmonitor AB mit der Infusionspumpe G gekoppelt wird, startet die Testvorrichtung 10 die Simulation auf der Infusionspumpe G und lässt entweder ein spezifisches Datenprofil exportieren oder setzt gezielt simulierte Werte. Damit entfällt das manuelle Bedienen der Infusionspumpe G. Diese Rolle übernimmt die Simulationssoftware. Damit kann die Funktionstestung voll automatisch ausgeführt werden. Die exportierten Daten werden dann an dem Patientenmonitor AB empfangen und mit einem vorkonfigurierten Simulationsprofil auf Übereinstimmung verglichen. Bei Übereinstimmung wird ein erfolgreiches Funktionstestergebnis ausgegeben.
In einem weiteren Beispiel kann ein erfolgreiches Funktionstestergebnis für weitere Geräteinstallationen verwendet werden. Sobald die Kompatibilität einer angeschlossenen Infusionspumpe G durch ein erfolgreiches Funktionstestergebnis erklärt wird, kann der Patientenmonitor AB diese Daten an eine zentrale Kompatibilitätsdatenbank übertragen. Die Kompatibilitätsdatenbank kann auch als Repository auf einem Server ausgebildet sein. Das Repository übermittelt die Kompatibilitätsdaten entweder auf Anfrage an anfragende Patientenmonitore AB oder übermittelt die Kompatibilitätsdaten aktiv an alle zurzeit registrierten Patientenmonitore AB. Ist keine Kompatibilitätsdatenbank ausgebildet, können die Testergebnisse manuell von einem ersten Patientenmonitor zu einem zweiten Patientenmonitor übertragen werden. Der Hersteller des Patientenmonitors AB kann im Vorfeld natürlich auch das Repository mit verifizierten Kompatibilitätsdaten speisen. Darüber hinaus ist es vorgesehen, dass der jeweilige Hersteller des Gerätes (z. B. Patientenmonitor AB) die Kompatibilitätsdaten jederzeit aktualisieren, verändern oder löschen kann.
Wie vorstehend beschrieben ist die Testvorrichtung 10 üblicherweise unmittelbar auf einem Patientenmonitor AB integriert. Alternativ ist es jedoch auch möglich, die Testvorrichtung 10 zentral auf einem Server abzulegen, der in Datenaustausch mit einem Patientenmonitor, einem Patientendatenmanagementsystem oder anderweitigen medizinischen Geräten AB steht. Das jeweilige Gerät AB kann dann bei Bedarf die funktionalen Bestandteile der Testvorrichtung 10, insbesondere das Testprogramm vom Server laden und auf dem Gerät zur Ausführung bringen.
Die Testvorrichtung kann in Software- und/oder in Hardware implementiert sein. Vorzugsweise ist die Testvorrichtung 10 als embedded system in den Patientenmonitor bzw. in das Anästhesie- und/oder Beatmungsgerät integriert bzw. eingebettet. Das Testverfahren dient der Speicherung, Verarbeitung und Weiterleitung von Antwortdaten auf den jeweiligen Testbefehl, die zwischen zu testenden Gerät G und Testvorrichtung 10 ausgetauscht werden. Das Testverfahren berücksichtigt insbesondere einen modifizierten Funktionsablauf des jeweils zu testenden Gerätes G, indem für den Betrieb des Gerätes G die weiteren, an dem Patientenmonitor AB angeschlossenen Komponenten, Versionen und Konfigurationen der jeweiligen Programme geprüft werden. Einzelne Verfahrensabschnitte oder auch das gesamte Verfahren kann Teil einer Mikroprozessorlösung sein, die auf der Testvorrichtung 10 fest verdrahtet ist. Alle oder ausgewählte Abschnitte des Verfahrens sind binär codiert und liegen in digitaler Form vor. Dabei können alle oder einzelne Abschnitte des Verfahrens als Quellcode (Source Code), als kompilierter Code (Maschinencode) oder als interpretierter Code (z. B. in unterschiedlichen Interpretersprachen, wie Ruby, PHP etc.) bereitgestellt werden oder durch einen Interpreter (z. B. Jit-Compiler) interpretiert werden.
Der Patientenmonitor oder das Anästhesie- oder Beatmungsgerät AB können beispielsweise mehrere Prozessoren mit individueller Firmware umfassen.
Vorstehend beschrieben umfasst die Testvorrichtung 10 den Speicher MEM, der in der bevorzugten Ausführungsform direkt in die Testvorrichtung 10 integriert ist. Alternativ kann der Speicher MEM auch durch ein Speichermodul, eine Speicherkarte oder einen mobilen Datenträger (z. B. in Form eines USB-Sticks) ausgebildet sein, um die Flexibilität der Zuordnung zwischen Testbefehl 20 und Referenzantwort zu erhöhen.
In einer bevorzugten Ausführungsform wird die Testvorrichtung 10 grundsätzlich vor jeder Inbetriebnahme eines Gerätes G und nach Erfassen einer Änderung an dem Geräteverbund aktiviert.
Abschließend sei darauf hingewiesen, dass die Beschreibung der Erfindung und die Ausführungsbeispiele grundsätzlich nicht einschränkend in Hinblick auf eine bestimmte physikalische Realisierung der Erfindung zu verstehen sind. Für einen Fachmann ist es insbesondere offensichtlich, dass die Erfindung teilweise oder vollständig in Soft- und/oder Hardware und/oder auf mehrere physikalische Produkte – dabei insbesondere auch Computerprogrammprodukte – verteilt realisiert werden kann.
Bezugszeichenliste

10: Testvorrichtung
G: zu testende Infusionspumpe oder medizinisches Gerät
AB: Patientenmonitor oder Anästhesie- oder Beatmungsgerät
P: Kommunikationsprotokoll
MEM: Speicher
T: Testmodul
C: Controller
20: Testbefehl
30: Antwort

Claims

Testvorrichtung (10) zum Funktionstesten einer Infusionspumpe oder eines anderen medizinischen Gerätes (G) innerhalb eines Geräteverbundes (V), zumindest umfassend ein Anästhesie- oder Beatmungsgerät (AB), wobei die Geräte des Geräteverbundes (V) über ein Kommunikationsprotokoll (P) in Datenaustausch stehen und wobei unterschiedliche Konfigurationen des Geräteverbundes (V) bestehen, umfassend: – Einen Speicher (MEM), in dem eine Menge von Testbefehlen gespeichert ist, wobei zu jedem Testbefehl (20) zumindest eine Referenzantwort (30') zugeordnet und gespeichert ist und wobei die Referenzantwort (30') verbundspezifisch und/oder konfigurationsspezifisch ist – Zumindest ein Testmodul (T), das dazu bestimmt ist, zumindest einen Testbefehl (20) aus der bereitgestellten Menge von Testbefehlen über das Kommunikationsprotokoll (P) an die zu testende Infusionspumpe oder an das medizinische Gerät (G) zur Bearbeitung zu senden – Zumindest einen Controller (C), wobei der Controller (C) dazu ausgebildet ist, eine Antwort (30) auf den ausgeführten Testbefehl (20) zu empfangen und diese mit der jeweils dem Testbefehl (20) zugeordneten Referenzantwort (30') auf Übereinstimmung zu vergleichen und bei Übereinstimmung ein erfolgreiches Funktionstestergebnis (40) auszugeben.
Testvorrichtung (10) nach Anspruch 1, bei der die Testvorrichtung (10) auf dem Anästhesie- oder Beatmungsgerät (AB) ausgebildet ist.
Testvorrichtung (10) nach einem der vorstehenden Ansprüche, bei der der Controller (C) dazu ausgebildet ist, die Testvorrichtung (10) nach Erhalt eines Testaktivierungssignals (40) zu aktivieren.
Testvorrichtung (10) nach einem der vorstehenden Ansprüche, bei der der Testbefehl (20) einen Simulationsbefehl umfasst.
Testvorrichtung (10) nach einem der vorstehenden Ansprüche, bei der der Speicher (MEM) jederzeit modifiziert mit anderen Testbefehlen (20) und/oder Referenzantworten (30') beschrieben werden kann.
Testvorrichtung (10) nach einem der vorstehenden Ansprüche, wobei die Testvorrichtung (10) zusätzlich eine Kontrolleinheit (K) umfasst, die Sensoren und/oder Aktuatoren umfasst, die zur Ausführung des Testbefehls (20) und zum Erzeugen einer Kontrollantwort (30'') auf den Testbefehl (20) ausgebildet sind, und wobei die Kontrolleinheit (K) die jeweils erzeugte Kontrollantwort (30'') an den Controller (C) weiterleitet, so dass der Controller (C) die empfangene Antwort (30) mit der Kontrollantwort (30'') und mit der Referenzantwort (30') auf Übereinstimmung zu vergleichen.
Anästhesie- oder Beatmungsgerät (AB) zur Verwendung in einem Geräteverbund (V), umfassend mehrere Module, mit: – Einer Testvorrichtung (10) nach einem der vorstehenden Ansprüche, wobei die Testvorrichtung (10) nachrüstbar ist.
Verfahren zum Funktionstesten einer Infusionspumpe oder eines anderen medizinischen Gerätes (G) innerhalb eines Geräteverbundes (V), zumindest umfassend ein Anästhesie- oder Beatmungsgerät (AB), wobei die Geräte des Geräteverbundes (V) über ein Kommunikationsprotokoll (P) in Datenaustausch stehen und wobei unterschiedliche Konfigurationen des Geräteverbundes (V) bestehen, mit folgenden Verfahrensschritten: – Bereitstellen einer Menge von Testbefehlen, die dazu bestimmt sind, auf der Infusionspumpe oder auf dem medizinischen Gerät (G) ausgeführt zu werden, wobei jeweils jedem Testbefehl (20) zumindest eine Referenzantwort (30') zugeordnet ist und wobei die Referenzantwort (30') verbundspezifisch und/oder konfigurationsspezifisch ist – Aktivieren eines Testzustandes auf dem medizinischen Gerät (G) – Senden zumindest eines Testbefehls (20) aus der bereitgestellten Menge von Testbefehlen über das Kommunikationsprotokoll (P) an die Infusionspumpe oder an das medizinische Gerät (G) – Ausführen des Testbefehls (20) auf der Infusionspumpe oder auf dem medizinischen Gerät (G) und Versenden zumindest einer Antwortnachricht über das Kommunikationsprotokoll (P) und Entpacken einer Antwort (30) aus der Antwortnachricht – Vergleich der empfangenen Antwort (30) mit der jeweiligen Referenzantwort (30'), die dem Testbefehl (20) zugeordnet ist, und bei Übereinstimmung: Ausgabe eines erfolgreichen Funktionstestergebnisses (40).
Computerprogrammprodukt, wobei das Computerprogrammprodukt ein Computerprogramm umfasst, das auf einem Datenträger oder auf einem Speicher (MEM) eines Computers (AB, G) gespeichert ist oder das über eine Netzwerkverbindung (NW) geladen werden kann und das von dem Computer lesbare Befehle umfasst, die zur Ausführung des Verfahrens nach dem vorstehenden Verfahrensanspruch bestimmt sind, wenn die Befehle auf dem Computer ausgeführt werden.