DE102011083887A1

DE102011083887A1 - Automatisches Selbsttestverfahren für medizinische Geräte

Info

Publication number: DE102011083887A1
Application number: DE201110083887
Authority: DE
Inventors: Dr. Moritzen Klaus; Dieter Ortlam
Original assignee: Siemens AG
Current assignee: Siemens Healthcare GmbH
Priority date: 2011-09-30
Filing date: 2011-09-30
Publication date: 2014-02-27
Also published as: US20130086573A1; US9003390B2

Abstract

Die Erfindung betrifft ein computerimplementiertes Verfahren zur Validierung eines Betriebssystem-Patches (P), ein Computerprogrammprodukt und ein Patchmodul (PM). Nach Ausgabe eines Betriebssystem-Patches (P) wird auf dem medizinischen Gerät (30) auf Anwendungsebene ein automatischer Selbsttest ausgeführt, der überprüft, ob der installierte Betriebssystem-Patch (P) erfolgreich installiert werden konnte. In diesem Fall wird ein Validierungssignal (V) ausgegeben. Der Selbsttest wird unmittelbar auf dem Applikationssystem (AS) ausgeführt.

Description

Die vorliegende Erfindung liegt auf den Gebieten der Medizintechnik und der Elektronik bzw. Informatik. Die Erfindung betrifft insbesondere einen Ansatz, um medizinische Geräte, die in ihrer Gesamtheit oder modulweise durch Software gesteuert werden, sicherheitstechnisch zu überprüfen bzw. Sicherheitslücken zu schließen, die das Gerät angreifbar machen und die Gerätefunktionalität kompromittieren würden.
Medizinische Geräte, wie beispielsweise Medizingeräte für diagnostisch bildgebende Verfahren oder Geräte im Rahmen einer Koloskopie, Laborgeräte, Ultraschallgeräte, Magnetresonanztomographen oder andere bildgebende medizintechnische Geräte sind heutzutage in der Regel durch Software gesteuert und umfassen ein Betriebssystem oder eine bestimmte Schicht einer informationstechnologischen Infrastruktur, die als Verteilungsplattform für anwendungsbezogene Dienste dient (z.B. eine Middleware wie CORBA, .NET oder RPC).
Im Stand der Technik ist eine Dreiteilung hinsichtlich der grundlegenden Systeme vorgesehen:
Zum ersten gibt es den Hersteller des Betriebssystems oder der jeweiligen Middleware, der üblicherweise kommerzielle Softwareprodukte vertreibt. Zum zweiten gibt es den Hersteller medizintechnischer Geräte (Siemens, GE etc.), die die Geräte herstellen und mit Software auf Basis des Betriebssystems ausrüsten und an klinische Einrichtungen liefern. Zum dritten gibt es die klinischen Einrichtungen, die dann die medizinischen Geräte anwenden (Krankenhäuser, Arztpraxen, etc.).
Aufgrund von in der Regel gesetzlich basierten Vorschriften (z.B. in den USA: FDA, Food and Drug Administration) ist es erforderlich, dass die im Einsatz befindlichen medizinischen Geräte ständig auf Einhaltung von Sicherheitsvorschriften überwacht werden. Dazu ist es notwendig, dass immer sichergestellt werden kann, dass stets die neueste Softwareversion des Betriebssystems aufgespielt ist. Dafür ist es vorgesehen, dass der Betriebssystemhersteller sogenannte Patches, also Korrekturauslieferungen der Software, erstellt und ausliefert. Diese Patch-Auslieferungen müssen dann vom Gerätehersteller validiert werden. Bisher lieferte der Betriebssystemhersteller die Patches an den Gerätehersteller aus, der diese auf Zulässigkeit validiert. Erst nachdem die Zulässigkeit des Patches geprüft werden konnte, konnte der Patch an die medizinische Einrichtung (z.B. Krankenhaus) ausgeliefert werden, was üblicherweise zu deutlichen Verzögerungszeiten führt. Nachteiligerweise erfolgte dies von Hand durch Systemingenieure seitens der Hersteller der medizintechnischen Geräte. Nach der manuellen Überprüfung war der Gerätehersteller verpflichtet, alle Kunden über einen neuen Patch zu informieren und diesen an die Kunden (also Krankenhäuser) auszugeben. Ein wesentlicher Nachteil des bisherigen Vorgehens ist demnach seine durchaus beträchtliche Zeitdauer und die Befassung von unterschiedlichen Institutionen (was wiederum einen zusätzlichen Datenaustauschbedarf nach sich zieht). Nach Ausgabe des Patches war es erforderlich, zunächst darauf zu warten, dass der Gerätehersteller den Patch validiert. Desweiteren musste gewartet werden, bis der Gerätehersteller den Patch an seine Kunden weiterleitet, die dann eine manuelle Überprüfung und ein Bestätigungssignal an den Hersteller senden, der daraufhin insbesondere im Fehlerfall möglicherweise seinerseits wieder den Betriebssystemhersteller informieren konnte. Es liegt auf der Hand, dass es hier zu Zeitverzögerungen kommt, wenn ein Verzug bei einem Glied der vorstehend genannten Kette auftritt.
Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, eine technische Umsetzung zu unterbreiten, mit dem das Testen von Betriebssystem-Patches für medizintechnische Geräte beschleunigt, verbessert und fehlerfreier ausgeführt werden kann.
Diese Aufgabe wird durch die beiliegenden Patentansprüche gelöst, insbesondere durch ein computerimplementiertes Verfahren, durch ein Computerprogrammprodukt und durch ein Patchmodul.
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 das Patchmodul). Demnach können auch die Unteransprüche, die zum Verfahren formuliert und beschrieben sind, auch auf die Anordnung und das Computerprogrammprodukt zu übertragen sein 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 computerimplementiertes Verfahren zur Validierung zumindest eines Betriebssystem-Patches für eine Applikation, die auf einem medizintechnischen Gerät implementiert ist, umfassend:

– Bereitstellen eines Patchmoduls auf dem medizintechnischen Gerät, wobei dieser Schritt auch im Vorfeld, in einer Konfigurationsphase, ausgeführt werden kann
– Ausgabe eines Betriebssystem-Patches seitens eines Betriebssystemherstellers
– Empfang des Betriebssystem-Patches seitens des Patchmoduls
– Seitens des Patchmoduls: Ausführen eines automatischen Selbsttests auf dem medizintechnischen Gerät auf Basis des empfangenden Betriebssystem-Patches und Senden eines Validierungssignals bei erfolgreichem Selbsttestergebnis.

Im Folgenden werden die im Rahmen dieser Anmeldung verwendeten Begrifflichkeiten näher erläutert.
Das Verfahren ist in der Regel computerimplementiert. Dabei kann es sein, dass bestimmte Verfahrensabschnitte als Teil einer Mikroprozessorlösung und somit fest verdrahtet sind, während andere Abschnitte des Verfahrens als Software ausgebildet sind. In diesem Fall wären nur einzelne Abschnitte oder Teile des Verfahrens softwareimplementiert. In der Regel sind alle oder ausgewählte Abschnitte des Verfahrens binär codiert oder sie liegen in digitaler Form vor. Dabei können alle oder einzelne Abschnitte des Verfahrens als Quellcode (Source Code), als bereits fertig kompilierter Code (Maschinencode) oder als interpretierter Code (z.B. in den Interpretersprachen Python, PHP, Ruby) bereitgestellt werden oder mittels eines Interpreters (z.B. Jit-Compilers) interpretiert werden. Für die Durchführung des erfindungsgemäßen Verfahrens und der weiter beanspruchten Produkte ist es unerheblich, in welcher Programmiersprache (z.B. C++, Java, Perl oder PHP etc.) die Software vorliegt. Wesentlich ist, dass die Software als Teil eines technischen Systems in das technische Gerät unmittelbar eingebunden ist und dort zur Steuerung von Korrektureinspielungen dient. Die Teile des erfindungsgemäßen Verfahrens, die als Software implementiert sind, können Teil eines sogenannten „embedded systems“ sein, das in das umgebende medizintechnische System eingebettet ist und mit diesem in Wechselwirkung steht.
Bei dem medizintechnischen System handelt es sich üblicherweise um ein medizinisches Gerät (z.B. Laborgerät, Medizingerät für diagnostisch bildgebende Verfahren, aber auch einfachere Geräte wie z.B. Geräte zur Messung von physiologischen Parametern eines Patienten), das über eine Applikation gesteuert wird. Üblicherweise umfasst die Applikation eine Benutzeroberfläche, über die der Benutzer mittels der Applikation das medizintechnische Geräte bedienen, steuern und/oder überprüfen kann.
Erfindungsgemäß wird zwischen zwei grundsätzlich separaten Instanzen unterschieden:
Eine Instanz des Betriebssystemherstellers und eine Instanz des Applikationssystems. Die Instanzen sind zumindest teilweise computerbasiert ausgebildet.
Die erste Instanz ist üblicherweise der Betriebssystemhersteller (z.B. ein Hersteller von sogenannten Off-the-shelf-Systemen, wie z.B. Betriebssystemen wie UNIX oder UNIX-Derivaten, wie Solaris etc.). Die „Instanz“ des Betriebssystemherstellers soll auch als ein Computernetzwerk verstanden werden, das unterschiedliche computerbasierte Einheiten, Bausteine und Module umfasst, insbesondere ein computerbasiertes Modul, das zur Herausgabe von Betriebssystem-Patches dient. Die Art des Betriebssystems ist grundsätzlich unabhängig für die Implementierung der erfindungsgemäßen Lösung. So können Betriebssysteme wie z.B. UNIX, MacOS, Windows-Systeme, JavaOS – oder Netware – oder andere Middleware-Systeme zur Anwendung kommen. Dabei ist es möglich, dass der Betriebssystem-Patch von einem Betriebssystemhersteller (wie z.B. HP, IBM, Sun-Microsystems, Apple, Microsoft) herausgegeben wird oder es ist ebenso möglich, dass der Betriebssystem-Patch von mehreren Betriebssystemherstellern und somit von einem Zusammenschluss mehrerer Betriebssystemhersteller oder von einer dem Betriebssystemhersteller zugeordneten Instanz herausgegeben wird.
Auf der anderen Seite befindet sich das Applikationssystem. Darunter wird ebenfalls ein computerbasiertes System verstanden, das aus mehreren Instanzen aufgebaut ist und bei dem das Betriebssystem mit den jeweiligen Patches zur Anwendung kommt. Im Rahmen dieser Erfindung handelt es sich bei dem Applikationssystem um ein medizintechnisches System, das aus interagierenden Komponenten besteht und unter anderem eine Vielzahl von technischen Geräten umfasst. An dieser Stelle sei ausdrücklich darauf hingewiesen, dass es sich bei den im Folgenden auch als „medizinisches Gerät“ bezeichneten Geräten ausnahmslos um technische Geräte oder Anlagen (z.B. um Perfusoren, bildgebende Anlagen, Post-Processingsysteme etc.) handelt. Je nach Anwendung ist es möglich, dass das medizinische Gerät, das an den Kunden (z.B. an die klinische Einrichtung) ausgeliefert wird, nicht für alle Kunden übereinstimmt, sondern vor Ort an die jeweiligen Bedürfnisse konfiguriert wird. Der Hersteller des jeweiligen medizinischen Gerätes führt dazu Anpassungen (Konfigurationen) an der Software und an der Hardware aus, so dass das medizinische Gerät für den jeweiligen Anwendungsfall maßgeschneidert bereitgestellt werden kann. Wesentlich ist, dass die Betriebssysteme auch nach Auslieferung immer noch an aktuelle Gegebenheiten, insbesondere an Sicherheitslücken für Angriffe über das Internet, angepasst werden müssen. Dazu ist es vorgesehen, dass Korrekturauslieferungen an die Kunden des Betriebssystems ausgeliefert werden, um Sicherheitslücken zu schließen. Dabei wird nicht das vollständige, komplette Betriebssystem ausgewechselt, sondern es werden nur die Teile neu implementiert, die zur Schließung der Sicherheitslücken dienen.
Die Betriebssystem-Patches liegen in der Regel als ausführbarer Code vor und können zu fest konfigurierten Zeitintervallen oder bedarfsweise vom Betriebssystemhersteller bereitgestellt werden.
Grundsätzlich unterscheidet man die vom Betriebssystemhersteller bereitgestellten Updates bzw. Aktualisierungen hinsichtlich ihrer Funktionalität. Erfindungsgemäß umfassen die Betriebssystem-Patches all solche Betriebssystem-Updates, die dazu dienen, Sicherheitslücken bei Anwendung des Betriebssystems in dem medizinischen Gerät (z.B. als embedded system) zu beheben. Umfasst sind dabei sogenannte Hotfixes, die dazu dienen, wichtige und eilbedürftige Fehler zu reparieren. In einer alternativen Ausführung der Erfindung kann der Betriebssystem-Patch sich auch auf solche Updates beziehen, die eine Erweiterung der Funktionalität des bisher ausgelieferten Betriebssystems betreffen (z.B. ein erweiterter Schutz gegen Malware, umfassend Viren, Würmer und sonstige Internetattacken). In einer weiteren vorteilhaften Ausführung der Erfindung umfassen die Betriebssystem-Patches auch sogenannte Bug fixes, die bisherige Fehler im Betriebssystem korrigieren sollen, die ihrerseits im medizintechnischen Gerät Fehlfunktionen auslösen könnten. Der Betriebssystem-Patch kann auf dem System des Betriebssystemherstellers zum Download (über eine entsprechende Kommunikationsverbindung, z.B. über das Internet) bereitgestellt werden oder sie werden unmittelbar vom System des Betriebssystemherstellers an seine Kunden und erfindungsgemäß direkt an das das medizinische Gerät umfassende Applikationssystem (z.B. eine klinische Einrichtung oder ein Zusammenschluss von Arztpraxen etc.) weitergeleitet (und nicht mehr – wie im Stand der Technik – zunächst an den Gerätehersteller, der dann den Patch validieren muss und diesen erst nach erfolgreicher Validierung an das Applikationssystem weiterleiten kann).
Gemäß einer Ausführung wird ein Betriebssystem-Patch als einzelnes Modul bereitgestellt. Alternativ ist es möglich, mehrere Betriebssystem-Patches zusammenzufassen und als Patch-Paket weiterzuleiten. Umgekehrt können – insbesondere bei umfangreichen Patches – die Patches auch auf mehrere Pakete aufgeteilt werden.
Die Erfindung ist grundsätzlich nicht darauf beschränkt, dass der Betriebssystem-Patch unmittelbar von dem Betriebssystemhersteller ausgegeben wird. Es ist durchaus denkbar, dass die Ausgabe von Betriebssystem-Patches an andere Instanzen ausgegliedert ist. Die Herausgabe des Betriebssystem-Patches erfolgt jedoch stets von einem System, das dem Betriebssystemhersteller zugeordnet ist. Üblicherweise werden das Betriebssystem selbst und die Betriebssystem-Patches von derselben Instanz bereitgestellt.
Bei dem medizinischen Gerät handelt es sich um ein technisches Gerät, das in einem medizinischen Umfeld eingesetzt wird, wie z.B. ein Laborgerät, ein Medizingerät für diagnostische Verfahren, insbesondere für bildgebende Verfahren, medizinische Geräte mit elektronischen Bausteinen, die ihrerseits auf dem Betriebssystem basieren. Je nach Anwendung kann das medizinische Gerät auch ein Apparat sein, auf dem ein Betriebssystem implementiert ist, wie z.B. ein Röntgenapparat, nuklearmedizinische Anlagen, aber auch umfassendere Systeme, wie PACS-Systeme und darauf basierende Produkte (PACS – Picture Archiving and Communications System). Das medizinische Gerät dient zur Ausführung von unterschiedlichen Maßnahmen, wie der Erhebung von Messdaten, der Erfassung von physiologischen Daten oder zur Akquisition von Bilddaten bei bildgebenden Geräten (z.B. Computertomographie-, Magnetresonanztomographie-, Positronen-Emissionstomographie-, Ultraschallgeräten etc.). Ebenso kann das Verfahren auch gezielter für solche medizinischen Geräte verwendet werden, die für eine eingeschränkte medizinische Datenerfassung ausgelegt sind, etwa zur Erfassung von Bilddaten zur Diagnose von Koronar-Arterienerkrankungen (coronary artery disease – CAD), sowie zur Darstellung der erfassten Daten, etwa zur Darstellung von Plaque oder anderen Ablagerungen in Blutbahnen etwa zur Erkennung von arteriosklerotischen Gefäßverschlüssen. Weitere spezielle Anwendungen sind hier beispielsweise die virtuelle Koloskopie zur Erfassung von Schnittaufnahmen des Dickdarms, um daraus zwei- oder dreidimensionale Bilddaten des Darmes zu erstellen, um davon ausgehend Erkrankungen (z.B. Polypen, Divertikel oder Tumore etc.) zu diagnostizieren. Eine weitere Anwendung betrifft die Magnetresonanz, z.B. das syngo.via-System der Firma Siemens zur bildgestützten Diagnose in der Neurologie, umfassend eine quantitative Verarbeitung neurologischer Daten, insbesondere Perfusionsdaten, Bilder hinsichtlich der zerebralen Blutverteilung (z.B. cerebral blood flow – CBF, cerebral blood volume – CBV und weiterer Messdaten bzw. Bilder).
Unter dem Begriff „Patchmodul“ soll eine Einheit verstanden werden, die als Software implementiert sein kann oder alternativ als Teil eines embedded systems und die auf dem medizinischen Gerät zum Empfang des Betriebssystem-Patches bestimmt ist. Das Patchmodul steht im Datenaustausch mit anderen Einheiten des medizinischen Gerätes, etwa Input-/Output-Einheiten, Messdatenaufnehmern, Prozessoreinheiten, wie der CPU (central processing unit), Speichereinheiten etc., sowie im Datenaustausch mit dem System des Betriebssystemherstellers. Optional ist auch eine Kommunikationsverbindung (üblicherweise eine bidirektionale) mit dem Hersteller des medizinischen Gerätes bereitgestellt. Das Patchmodul dient zum einen zum Empfang des Betriebssystem-Patches und zur Implementierung des Patches in das installierte Betriebssystem auf dem medizinischen Gerät. Eine weitere Funktionalität des Patchmoduls liegt darin, den empfangenen Betriebssystem-Patch automatisch auf dem Gerät zu implementieren. Vorzugsweise kann dies auch zur Laufzeit des Gerätes, also auch während des Betriebs des medizinischen Gerätes ausgeführt werden. Zum anderen dient das Patchmodul zur Ausführung des automatischen Selbsttests. Das Patchmodul kann im Vorfeld in einer Konfigurationsphase auf dem Applikationssystem bereitgestellt werden.
Der Begriff „automatischer Selbsttest“ bezieht sich auf einen Überprüfungsmechanismus, der üblicherweise mehrere Stufen und Abschnitte umfasst. Der Selbsttest wird auf dem medizinischen Gerät und auf Basis des empfangenen und installierten Betriebssystem-Patch ausgeführt. Er wird auch – über das dort installierte Patchmodul- direkt auf dem medizinischen Gerät initiiert, aufgerufen oder angestoßen. Vorzugweise ist es vorgesehen, dass der Selbsttest vollautomatisch, also ohne jegliche Benutzerinteraktion mit einem Systemadministrator, ausgeführt wird. Sobald erkannt wird, dass das Betriebssystem auf dem Applikationssystem / auf dem medizinischen Gerät verändert worden ist, wird die Ausführung des Selbsttestes automatisch veranlasst. Alternativ kann vorgesehen sein, dass hier noch ein Bestätigungssignal des Anwenders/Administrators erforderlich ist. Dies kann dann sinnvoll sein, wenn das medizinische Gerät auch zum Einsatz von lebenserhaltenden Maßnahmen (z.B. Beatmungsmaschine) verwendet wird. Dann ist es erforderlich, dass der Anwender durch ein Bestätigungssignal bestätigt, dass jetzt eine Überprüfung des neu installierten Betriebssystem-Patches ausgeführt werden kann, ohne dass die Leistungsfähigkeit bzw. Funktionalität des medizinischen Gerätes beschränkt wird. Damit soll sichergestellt werden, dass der medizinische Ablauf unter Verwendung des jeweiligen medizinischen Gerätes (etwa bei lebenserhaltenden Maßnahmen) nicht beeinträchtigt wird.
Gemäß einer bevorzugten Ausführungsform der Erfindung ist es vorgesehen, dass der automatische Selbsttest einen „Probebetrieb“ des jeweiligen medizinischen Gerätes implementiert. „Probe“ bedeutet, dass das Gerät, wie beim üblichen Betrieb von Anwender auch betrieben wird, allerdings nur mit Probe- oder Testdaten. Der Betrieb an sich unterscheidet sich nicht zwischen Betrieb des Gerätes im realen Einsatz und Probebetrieb. Wichtig ist dabei, dass das medizinische Gerät genau so, wie es der klinische Einsatz vorsieht, betrieben wird, also auch mit dort bereitgestellten spezifischen Konfigurationen und applikationsspezifischen Anpassungen. Die einzige Änderung besteht darin, dass Testdaten verwendet werden. Bei den Testdaten kann es sich um vorverarbeitete oder aufbereitete Bilddaten, vorverarbeitete Messdaten oder um sonstige Testdaten handeln. Ansonsten stimmt der Ablauf des medizinischen Gerätes während des Selbsttestes identisch mit dem üblichen Ablauf im realen, klinischen Umfeld überein. Der Vorteil dieses Ansatzes ist darin zu sehen, dass nicht nur Standardfälle getestet werden, sondern dass der Selbsttest möglich „nah“ an dem realen Ablauf bzw. klinischen Einsatz liegt. Der automatische Selbsttest ist so ausgelegt, dass das medizinische Gerät mit den jeweiligen Applikationen (es können auch mehrere Applikationen auf einem medizinischen Gerät implementiert und ablauffähig sein) ausgeführt wird. Handelt es sich beispielsweise bei dem medizinischen Gerät um einen Computertomographen zur Ausführung einer virtuellen Koloskopie und zur Darstellung der jeweiligen Bilder, so werden während des Selbsttests Testbilder als Input (Eingangsgrößen) für die Applikation bereitgestellt. Die Applikation zur Darstellung der Bilder wird dann auf Basis der Testbilder ausgeführt. Das Ergebnis des jeweiligen Probe- oder Testbetriebes, das durch den Selbsttest erhalten wird, wird mit einem Referenzergebnis auf Übereinstimmung verglichen. Bei Übereinstimmung des Selbsttestergebnisses mit dem Referenzergebnis gilt der Selbsttest als erfolgreich. In diesem Fall wird ein Validierungssignal generiert, das einen erfolgreichen Selbsttest indizieren soll. Das Validierungssignal kann ein digitales Signal (z.B. ein Flag bei einem transferierten Datensatz) oder ein akustisches und/oder optisches Signal sein. Das Validierungssignal kann an weitere Instanzen zur Weiterverarbeitung weitergeleitet werden, z.B. an das System des Betriebssystemherstellers und/oder an das System des Geräteherstellers. Damit entsteht ein wichtiger Vorteil, dass der Selbsttest im aktuellen Umfeld des medizinischen Gerätes ausgeführt werden kann, also auch in der Form, in der das medizinische Gerät in das Applikationssystem eingebunden ist. Dabei werden auch applikationsspezifische Parameter berücksichtigt, die nur vor Ort (also im Applikationssystem) relevant sind (wie z.B. Netzwerkverbindungen / Bandbreite der Datenübertragung, Rechnerkapazitäten, technische Ressourcen, Parallelbetrieb von mehreren Applikationen auf dem medizinischen Gerät, Parallelbetrieb mehrerer medizinischer Geräte in dem Applikationssystem, Datenvolumen der erzeugten Bilddaten bei bildgebenden Geräten etc.).
Gemäß einer bevorzugten Ausführungsform der Erfindung wird der automatische Selbsttest unter Verwendung einer Benutzerschnittstelle des medizinischen Gerätes ausgeführt. Damit entsteht der weitere Vorteil, dass der Selbsttest auch im realen Umfeld mit typischen Eingaben und Befehlssequenzen ausgeführt werden kann und dieselbe Benutzerschnittstelle wie die jeweilige Applikation verwendet.
Ein wichtiges Merkmal kennzeichnet sich dadurch, dass der automatische Selbsttest auf Anwendungsebene ausgeführt wird. Dadurch können spezielle Parameter und Bedingungen des Applikationssystems berücksichtigt werden. Falls die Applikation auf dem medizinischen Gerät für einen konkreten, speziellen Anwendungsfall konfiguriert worden ist, ist automatisch sichergestellt, dass der automatische Selbsttest in demselben konfigurierten Anwendungsumfeld ausgeführt wird. Damit kann die Qualität des Testergebnisses verbessert werden. Der Test umfasst eine Folge von Verarbeitungsschritten, die üblicherweise auf dem medizinischen Gerät ausgeführt werden. Beispiele für Testschritte sind:
Laden von Bilddaten, Verarbeiten von Bilddaten, Darstellung der Bilddaten und Ausführen von Benutzerinteraktionen auf der Benutzerschnittstelle zur modifizierten Darstellung der Bilddaten und/oder zur Änderung der dargestellten Bilddaten (z.B. Annotieren, Löschen, Verändern, Speichern etc.). Die Benutzerinteraktionen können auch simuliert werden. Für die Simulation von User-Interkationen kann das Überprüfungsprotokoll Tastatureingaben und Mausklicks in Art und Weise eines realen Benutzers simulieren.
Üblicherweise wird das Patchmodul gleichzeitig mit der Applikation auf dem medizinischen Gerät implementiert. Alternativ ist es möglich, dass das Patchmodul zu einem späteren Zeitpunkt oder separat zur Applikation auf dem medizinischen Gerät implementiert wird.
Ein weiterer Aspekt der Erfindung ist darin zu sehen, dass alle oder ausgewählte Zustände der Applikation auf dem medizinischen Gerät nachgehalten bzw. gespeichert werden. Dafür kann ein Audit-Log-File bereitgestellt werden. Somit kann sichergestellt werden, dass immer der Zustand vor einer Installation des Betriebssystem-Patches gespeichert ist. Dies hat den Vorteil, dass ein „roll back“, also eine Wiederherstellung des alten Systemzustandes vor Installation des Betriebssystem-Patches, ausgeführt werden kann, falls der automatische Selbsttest nicht erfolgreich validiert werden konnte (kein Validierungssignal). Damit kann sichergestellt werden, dass der normale Betrieb des medizinischen Gerätes durch die Ausführung des Betriebssystem-Patches nicht beeinträchtigt wird. Falls die Installation des Patches bei dem medizinischen Gerät auf einem Fehler läuft, so kann automatisch der Zustand vor Installation des Patches wiederhergestellt werden. Damit wird die Sicherheit des medizinischen Gerätes erhöht.
Wie vorstehend bereits erwähnt, ist es vorgesehen, dass der automatische Selbsttest direkt in dem Applikationssystem und unmittelbar unter Ausführung der Applikation ausgeführt wird, mit der das medizinische Gerät gesteuert und/oder betrieben wird. Dies hat den Vorteil, dass auch applikationsspezifische und/oder geräte-spezifische Parameter (die für die Funktion des medizinischen Gerätes und/oder der Applikation relevant sind) bei dem Selbsttest mit berücksichtigt werden können. Damit wird es möglich, dass auch geräte- und/oder applikationsspezifische Konfigurationstests abgedeckt sind. Üblicherweise ist es nämlich vorgesehen, dass ein Gerätehersteller bei Auslieferung eines medizinischen Gerätes (mit der oder den jeweiligen Applikation(en)) applikationsspezifische Konfigurationen vornimmt (z.B. einen größeren Speicherbaustein einbaut, falls hochvolumige Datensätze zu speichern sind oder eine schnellere Datenverbindung vorsieht, falls ein hohes Datenvolumen transferiert werden muss oder eine grafische Benutzeroberfläche bereitstellt, falls eine textuelle Ein-/Ausgabe nicht ausreichend ist). Mit dem erfindungsgemäß bereitgestellten automatischen Selbsttest können auch diese applikationsspezifischen und/oder gerätespezifischen Konfigurationen und Anpassungen mit dem Selbsttest überprüft werden.
In einer bevorzugten Ausführungsform wird der Betriebssystem-Patch von dem System des Betriebssystemherstellers (entweder von dem Betriebssystemhersteller direkt oder von einer dritten Instanz, die dem Betriebssystemhersteller zugeordnet ist) direkt an das medizinische Gerät weitergeleitet. Das Bereitstellen oder Weiterleiten des Betriebssystem-Patches kann nach dem PUSH-Prinzip oder nach dem PULL-Prinzip ausgeführt werden. Beim PUSH-Prinzip schiebt der Betriebssystemhersteller aktiv neu generierte Betriebssystem-Patches zum Applikationssystem, während bei dem PULL-Prinzip das Applikationssystem durch Anfragen an das System des Betriebssystemherstellers erfasst, ob neue Betriebssystem-Patches vorliegen und diese aktiv abruft. Vorzugsweise wird der Betriebssystem-Patch direkt an das Patchmodul des medizinischen Gerätes gesendet. In diesem Fall wird jedes medizinische Gerät, auf dem eine Applikation implementiert ist, mit einem Patchmodul ausgestattet. Alternativ ist es auch möglich, dass das Patchmodul an eine zentrale Instanz des Applikationssystems gesendet wird, von der es an die einzelnen Applikationen und/oder medizinischen Geräte verteilt wird. Die letztere Variante ist dann sinnvoll, wenn das Applikationssystem einen zentralen Administrator hat, der diese Aufgaben für eine Vielzahl von angeschlossenen medizinischen Geräten eines umfassenden Applikationssystems (z.B. einer Klinik oder eines Klinikverbundes) übernehmen kann. Der Selbsttest wird von dem Patchmodul initiiert und gesteuert. Der Selbsttest ist vorzugsweise als Softwaretest ausgebildet. Er umfasst patchmodulseitige Abschnitte (also Verfahrensabschnitte, die auf dem Patchmodul ausgeführt werden) und geräteseitige Abschnitte (also Verfahrensabschnitte, die auf dem medizinischen Gerät ausgeführt werden) und kann nach dem Client-Server-Prinzip aufgebaut sein.
In einer komplexeren Ausführungsform ist es vorgesehen, dass der automatische Selbsttest, der auf dem Patchmodul und auf dem medizinischen Gerät ausgeführt wird, noch weitere Funktionalitäten umfasst. Dabei kann es vorgesehen sein, dass automatisch eine Fehlermeldung ausgegeben und gegebenenfalls an weitere Instanzen weitergeleitet wird, falls der Selbsttest nicht erfolgreich abgeschlossen werden konnte (falls also kein Validierungssignal ausgegeben werden kann. In solchen Fällen kann es eingestellt sein, dass automatisch ein roll back, also eine Wiederherstellung des Zustands vor Installation des Betriebssystem-Patches vorgenommen wird. Anderenfalls kann der roll back auch erst auf ein roll back-Signal ausgeführt werden, das vom Benutzer über eine Benutzerschnittstelle eingegeben wird. Weiterhin ist es möglich, dass der Selbsttest für den jeweiligen Anwendungsfall konfiguriert werden kann. Beispielsweise können hier Repetitionen vorgesehen sein, so dass der Selbsttest wiederholt zu unterschiedlichen Zeitpunkten unter unterschiedlichen Anwendungsbedingungen wiederholt wird. Alternativ können parallele Tests oder zeitversetzte Tests auf medizinischen Geräten ausgeführt werden, die dem Applikationssystem zugeschaltet sind. Desweiteren ist es möglich, dass ein Umfang des Selbsttests im Vorfeld konfiguriert werden kann. So ist es beispielsweise denkbar, dass bei minimaler Einstellung nur ein stark reduzierter Test auf gravierende Sicherheitsmängel durchgeführt wird, während bei maximaler Einstellung umfangreichere Tests ausgeführt werden.
Ein wichtiger Vorteil ist darin zu sehen, dass der automatische Selbsttest zur Validierung eines Betriebssystem-Patches auf die unterschiedlichen medizinischen Geräte abgestellt werden kann. Es liegt auf der Hand, dass ein Laborgerät andere Testschritte erforderlich macht, als eine MRT-Anlage oder Antriebssteuerungen für den Patiententisch einer SPECT-Anlage. Gemäß einem Aspekt der Erfindung ist eine Signalverarbeitungseinrichtung auf dem Patchmodul vorgesehen. Die Signalverarbeitungseinrichtung dient dazu, automatisch zu erkennen, ob Änderungen an der Applikation und/oder an dem Betriebssystem ausgeführt wurden. Diese Signale werden dann ausgewertet und dahingehend verarbeitet, um ereignisgesteuert und/oder zeitgesteuert den Selbsttest zu initiieren.
Ein Vorteil ist auch darin zu sehen, dass der Selbsttest bzw. die Validierung der Betriebssystem-Patches einheitlich für alle Betriebssystem-Anwendungssysteme (also z.B. alle klinischen Einrichtungen, die Geräte verwenden, die auf dem Betriebssystem basieren) ausgeführt werden kann, da ein einheitliches Patchmodul auf den Geräten implementiert ist. Damit kann ausgeschlossen werden, dass ein erstes Applikationssystem andere Validierungsmaßnahmen bzw. Testmaßnahmen ausführt als ein zweites Applikationssystem (das beispielsweise strengere oder schwächere Testvorschriften hat).
Ein Vorteil ist auch darin zu sehen, dass das reguläre Laufzeitverhalten des medizinischen Gerätes durch den Selbsttest nicht beeinträchtigt wird.
Um alle Betriebssystem-Patches mit deren Validierungen nachhalten zu können, ist ein Audit-Prozess bzw. ein Log-File vorgesehen, in dem alle Ergebnisse der ausgeführten Selbsttests abgelegt sind. Zusätzlich sind auch alle Betriebssystem-Patches (bzw. die unterschiedlichen Betriebssystemversionen) abgelegt. Damit kann zu jedem Zeitpunkt ein früherer Zustand des Systems wiederhergestellt werden. Desweiteren kann auch der Ablauf der Betriebssystem-Patches über die Zeit verfolgt und ausgewertet werden.
Das Validierungssignal, die Fehlermeldung und/oder andere Signale, die im Rahmen der Validierung des Betriebssystem-Patches anfallen, können über unterschiedliche Kommunikationskanäle weitergeleitet werden, umfassend eine E-Mailbenachrichtigung an einen vorbestimmbaren Empfängerkreis oder über elektronische Nachrichten, die nicht über E-Mail versendet werden, sowie über andere Kommunikationsprotokolle (neben dem http-Protokoll des Internets) auch via Bluetooth, Mobilfunk, proprietäre Schnittstellen etc.
Gemäß einem Aspekt kann es auch konfiguriert werden, zu welchem Zeitpunkt und in welcher Form der Selbsttest des Patchmoduls ausgeführt wird, sobald erkannt wurde, dass ein neuer Betriebssystem-Patch installiert ist. Zum einen ist es möglich, dass der Selbsttest unmittelbar nach Installation des Betriebssystem-Patches ausgeführt wird. Alternativ können hier auch konfigurierbare Ereignisse definiert werden, die zur automatischen Initiierung des Selbsttests führen. Alternativ können auch Zeitintervalle definiert werden, nach deren Ablauf ein Selbsttest ausgeführt werden soll (hier wäre es beispielsweise denkbar, dass der Selbsttest möglichst zu Zeiten ausgeführt wird, in denen das medizinische Gerät wenig in Anspruch genommen ist, z.B. nachts). Darüber hinaus können auch Ereignisse konfiguriert werden, die zur Auslösung des Selbsttests führen sollen.
Dies bietet eine weitere Flexibilität und erhöht die Qualität des Applikationssystems, indem der Selbsttest sehr spezifisch auf die jeweiligen Anwendungsgegebenheiten abgestellt werden kann.
Die Erfindung betrifft auch ein Computerprogrammprodukt, das in einen Speicher eines digitalen Computers geladen werden kann und Softwareroutinen umfasst, mit denen die Schritte gemäß den vorstehend erwähnten Aspekten ausgeführt werden, die im Zusammenhang mit dem Verfahren beschrieben sind.
Desweiteren betrifft die Erfindung ein Patchmodul für ein medizinisches Gerät, auf dem eine Applikation zur Steuerung des medizinischen Gerätes implementiert ist, wobei das Patchmodul zur Ausführung eines automatischen Selbsttests bestimmt ist, falls auf dem medizinischen Gerät oder auf einem Applikationssystem ein Betriebssystem-Patch installiert worden ist und wobei das Patchmodul zur Validierung des Betriebssystem-Patches und zur Ausgabe eines Validierungssignals bei erfolgreichem Selbsttestergebnis bestimmt ist.
Die oben beschriebenen Merkmale, bevorzugten und alternativen Ausführungsformen, Eigenschaften und Vorteile der Erfindung werden im Zusammenhang mit der folgenden Beschreibung der Ausführungsbeispiele, die im Zusammenhang mit den Zeichnungen zu lesen sind, näher erläutert. Dabei zeigen:
1 eine Übersicht über unterschiedliche Systeme im Rahmen einer bevorzugten Ausführungsform der Erfindung,
2 eine schematische Darstellung eines medizinischen Gerätes mit einem Patchmodul und
3 ein Ablaufdiagramm gemäß einem Verfahren nach einer bevorzugten Ausführungsform der Erfindung.
Im Folgenden wird das grundlegende System zur Implementierung des erfindungsgemäßen computerimplementierten Verfahrens zur Validierung zumindest eines Betriebssystem-Patches anhand von 1 näher erläutert.
1 zeigt drei unterschiedliche computerbasierte Systeme: Ein System 10 eines Betriebssystemherstellers, wie z.B. Sun Microsystems, Microsoft, IBM, Apple, Samsung etc. Das System 10 kann als Netzwerksystem oder als Cloud-System organisiert sein und eine Vielzahl von untergeordneten Instanzen umfassen, die über ein Netzwerk im Datenaustausch stehen. Das System 10 dient zur Herausgabe des Betriebssystems, das an eine Vielzahl von unterschiedlichen Kunden verteilt wird. Das zweite System betrifft ein Geräteherstellersystem 12. In dem Geräteherstellersystem 12 werden medizinische Geräte 30 entwickelt und produziert, wie z.B. von der Anmelderin. Es umfasst auch Computersysteme, die im Datenaustausch mit anderen Systemen, unter anderem den Betriebssystemhersteller 10 und Kunden des Geräteherstellers 12 stehen. Der Gerätehersteller 12 liefert seine medizinischen Geräte 30 an klinische Einrichtungen, Arztpraxen oder anderweitige Kunden. Die medizinischen Geräte 30 sind einem Applikationssystem AS zugeordnet, das in dem Ausführungsbeispiel in 1 auf der rechten Seite dargestellt ist. Ein Applikationssystem AS kann beispielsweise eine klinische Einrichtung sein, in der eine Vielzahl von unterschiedlichen medizinischen Geräten 30 eingebunden ist, die üblicherweise über ein Netzwerk 40 mit in der Regel mehreren Rechnern 50 und/oder sonstigen computerbasierten Apparaten und/oder sonstigen Geräten in Datenaustausch stehen.
Üblicherweise passt der Gerätehersteller 12 die medizinischen Geräte 30 für den jeweiligen Anwendungsfall bzw. für das jeweilige Applikationssystem AS spezifisch an. Dazu rüstet er das medizinische Gerät 30 mit unterschiedlichen Komponenten aus, die für den jeweiligen Anwendungsfall erforderlich sind. Beispielsweise erfordert es einen ersten Anwendungskontext, dass das medizinische Gerät 30 mit einem deutlich vergrößertem Speicher ausgerüstet ist, während ein zweiter Anwendungskontext das medizinische Gerät 30 mit einer Vielzahl von Mehrkern-Prozessoren ausrüstet, um eine möglichst hohe Rechenleistung bereitstellen zu können. Diese Konfigurationen und Anpassungen des medizinischen Gerätes 30 sind jedoch nur beispielhaft zu verstehen und es liegt auf der Hand, dass auch andere Hardware-Module des medizinischen Gerätes 30, andere elektronische Bauteile oder andere Software-Module für das medizinische Gerät 30 implementiert werden können.
Das medizinische Gerät 30 wird über eine Applikation gesteuert und/oder betrieben. Die Applikation basiert auf einem Betriebssystem BS oder einer Middlewareplattform. Üblicherweise gibt der Betriebssystemhersteller 10 das Betriebssystem BS direkt an das Applikationssystem AS aus. Dies ist in 1 mit dem Pfeil dargestellt, der von dem mit dem Bezugszeichen 10 tragenden Kasten auf das Applikationssystem AS verweist und mit dem Bezugszeichen „BS“ (dargestellt in einem Oval) beschriftet ist.
Bei allen heutigen Betriebssystem BS ist es erforderlich, das Betriebssystem BS an aktuelle Sicherheitsattacken anzupassen und deshalb Korrektureinheiten des Betriebssystems BS fortlaufend herauszugeben und an die Applikationssysteme AS zu verteilen. Diese Korrekturmaßnahmen werden im Folgenden als Betriebssystem-Patch P zusammengefasst. Üblicherweise gibt der Betriebssystemhersteller 10 auch den Betriebssystem-Patch P heraus.
Erfindungsgemäß ist es nun (und im Unterschied zum Stand der Technik) vorgesehen, dass der Betriebssystemhersteller 10 den Betriebssystem-Patch P unmittelbar an das Applikationssystem AS sendet und nicht mehr (wie gehabt) den Betriebssystem-Patch P zunächst an den Gerätehersteller 12 sendet.
Erfindungsgemäß ist das Applikationssystem AS auch dahingehend erweitert worden, dass es zum direkten Empfang der Betriebssystem-Patches P seitens des Betriebssystemherstellers 10 ausgebildet ist. Gemäß einer bevorzugten Ausführungsform der Erfindung wird dazu jedes medizinische Gerät 30 des Applikationssystems AS mit einem Patchmodul PM ausgebildet. Das Patchmodul PM dient zum Empfang des Betriebssystem-Patches P.
Gemäß einer ersten Variante der Erfindung ist das Patchmodul PM auf jedem medizinischem Gerät 30 ausgebildet (nicht dargestellt). Alternativ ist es möglich, nicht jedes einzelne medizinische Gerät 30 zu verändern und mit einem Patchmodul PM zu erweitern, sondern das Patchmodul PM separat von den einzelnen medizinischen Geräten 30 derart bereitzustellen, dass die Applikation A, mit der das jeweilige medizinische Gerät 30 betrieben bzw. gesteuert wird, auf das Patchmodul PM zugreifen kann. Beispielsweise kann das Patchmodul PM auf einem zentralen Rechner 50 ausgebildet sein, der über das Netzwerk 40 mit dem jeweiligen medizinischen Gerät 30 (oder den mehreren medizinischen Geräten 30), auf dem/denen die Applikation A läuft, die ihrerseits auf dem Betriebssystem BS basiert, in Datenaustausch steht. Diese Ausführungsform ist in 1 dadurch angedeutet, dass das Patchmodul PM auf dem Rechner 50 angeordnet ist. Hier sind unterschiedliche Implementierungsalternativen denkbar. So ist es auch möglich, dass das Patchmodul PM nur auf dem Rechner 50 implementiert wird, auf dem die Applikation A läuft, mit der das medizinische Gerät 30 bedient wird. Dabei kann auch eine Gruppe von medizinischen Geräten 30 von ein und derselben Applikation A bedient werden. Alternativ kann es auch notwendig sein, dass ein medizinisches Gerät 30 von mehreren Applikationen A betrieben wird.
Das Patchmodul PM kann bei Auslieferung des medizinischen Gerätes 30 gemeinsam mit dem medizinischen Gerät 30 an das Applikationssystem AS geliefert werden. Alternativ kann das Patchmodul PM auch zu einem anderen Zeitpunkt oder separat vom medizinischen Gerät 30 bereitgestellt werden. Das Patchmodul PM kann einerseits vom Gerätehersteller 12 und/oder andererseits vom Betriebssystemhersteller 10 bereitgestellt werden.
Das Patchmodul PM dient zum Empfang des Betriebssystem-Patches P. Darüber hinaus dient das Patchmodul PM zur Ausführung eines automatischen Selbsttest auf dem jeweiligen medizinischen Gerät 30 auf Basis des empfangenen Betriebssystem-Patches P (der zum Zeitpunkt der Selbsttestausführung bereits installiert sein muss, damit er getestet bzw. validiert werden kann). Der automatische Selbsttest wird auf dem jeweiligen medizinischen Gerät 30 unter Anwendungsbedingungen und auf Anwendungsebene ausgeführt.
Sobald eine Detektionseinheit (nicht dargestellt) innerhalb des Applikationssystems AS erkennt, dass das Betriebssystem BS (oder die Middleware) geändert worden ist, nämlich durch Installation eines Betriebssystem-Patches P, wird der Selbsttest automatisch initiiert. Je nach Konfiguration wird der Selbsttest zu einem vorbestimmbaren Zeitpunkt oder zu einem vorbestimmbaren Ereignis auf dem medizinischen Gerät 30 ausgeführt. Der Selbsttest kennzeichnet sich durch einen Probebetrieb des jeweiligen medizinischen Gerätes 30. Handelt es sich beispielsweise bei dem medizinischen Gerät 30 um eine Anästhesieanlage, die ein Narkosegerät, eine Ein-/Ausgabeschnittstelle (z.B. einen Monitor und/oder eine Tastatur, Mouse), einen Rechner 50 zur Steuerung des Narkosegerätes und in der Regel noch weitere Bauteile umfasst, so ist es für ein fehlerfreies Funktionieren des Anästhesiesystems unabdingbar, dass das Betriebssystem BS, auf dem die Steuerungsapplikation zur Steuerung des Narkosegerätes basiert, auch gegen aktuelle Sicherheitsattacken (z.B. in Form von Würmern oder Viren) geschützt ist. Dazu wird (in der Regel in regelmäßigen Abständen) vom Betriebssystemhersteller 10 der Betriebssystem-Patch P an das Patchmodul PM weitergeleitet. Nun ist es ebenfalls unabdingbar, sicherzustellen, dass das medizinische Gerät 30 (in diesem Fall das Anästhesiesystem) auch nach Implementierung des Betriebssystem-Patches P unter den gegebenen Anwendungsbedingungen nach wie vor fehlerfrei funktioniert. Dazu kann das Patchmodul PM auf dem Narkosegerät unmittelbar unter Anwendungsbedingungen den Selbsttest initiieren und ausführen. Vorteilhafterweise wird der Selbsttest unmittelbar auf dem medizinischen Gerät 30 (z.B. Narkosegerät) unter Anwendungsbedingungen (mit Testdaten, insbesondere mit simulierten Patienten-Anästhesie-Daten) ausgeführt. Bei dem Selbsttest werden dabei auch gerätespezifische Parameter, in diesem Fall also narkosegerätespezifische Parameter berücksichtigt. Der Selbsttest wird auf dem Narkosegerät selbst ausgeführt und dabei über die Benutzerschnittstelle des medizinischen Gerätes 30 (hier: der Monitor des Narkosegerätes) bedient. In diesem Fall simuliert der Selbsttest quasi einen Probebetrieb des medizinischen Gerätes 30. Dies geschieht üblicherweise mit vorbereiteten, einheitlichen Testdaten. Der automatische Selbsttest führt zu einem Selbsttestergebnis. Beispielsweise werden unterschiedliche Narkosegase gemischt oder in einem anderen Anwendungsfall werden akquirierte Bilddaten auf einem Monitor 80 zur Befundung dargestellt. Eine andere Anwendung für das medizinische Gerät 30 kann beispielsweise die Steuerung zur Positionierung des Patiententisches bei einer SPECT-Anlage 60 oder einer anderen bildgebenden Anlage betreffen. Dieses Beispiel ist in 2 schematisch dargestellt. In diesem Fall umfasst das Applikationssystem AS eine SPECT-Anlage 60, einen Monitor 80 und Tastatur bzw. eine Computermaus 90, sowie einen Rechner 50. In dem in 2 schematisch dargestellten Ausführungsbeispiel sind nur ausgewählte Module des Applikationssystems AS dargestellt, um das grundlegende Prinzip zu erklären. Auf dem Rechner 50 ist eine Applikation A installiert, über die die Mechanik zur Positionierung des Patiententisches gesteuert wird. Die Applikation A basiert auf dem Betriebssystem BS. Wenn für das Betriebssystem BS ein neuer Betriebssystem-Patch P auf dem ebenfalls zugeordneten Patchmodul PM installiert ist, wird automatisch ein Selbsttest für die jeweilige Applikation A ausgeführt. In diesem Fall ist das medizinische Gerät 30 eine Positionierungsmechanik zur Positionierung des Patiententisches. Alternativ zu dem in 2 dargestellten Beispiel ist es ebenso möglich, dass die Applikation A als „embedded system“ bereitgestellt wird. Dann ist die Applikation A als elektronisches Modul in der Regel in die Positionierungsmechanik 30 eingebettet bzw. eingebaut.
In dem in 2 dargestellten Beispiel einer Positionierungsmechanik 30 zur Steuerung des Patiententisches wird der Selbsttest ausgeführt, in dem für unterschiedliche Workflows des SPECT-Systems 60 der Patiententisch an die korrekte Position verfahren wird. Das Ergebnis ist hier somit die Positionierung des Patiententisches.
Grundsätzlich wird das Ergebnis des Selbsttest mit einem Referenzergebnis auf Übereinstimmung verglichen. Das Referenzergebnis ist in diesem Fall die korrekte Position des Tisches, die manuell oder durch Positionssensoren erfasst werden kann. Falls also der ausgeführte Selbsttest mit dem korrekten Referenzergebnis übereinstimmt, wird ein Validierungssignal V von dem Patchmodul PM ausgegeben. Dies ist in 1 mit dem Pfeil dargestellt, der von dem Applikationssystem AS ausgehend auf den Gerätehersteller 12 verweist. Alternativ kann das Validierungssignal V auch von dem Applikationssystem AS an den Betriebssystemhersteller 10 gesendet werden. Dies ist in 1 mit der gestrichelten Linie dargestellt, die mit dem Bezugszeichen V gekennzeichnet ist.
Falls der Selbsttest auf einem Fehler läuft oder nicht erfolgreich beendet werden konnte, wird eine Fehlermeldung F ausgegeben. Auch die Fehlermeldung F wird analog zum Validierungssignal V an weitere Instanzen weitergereicht, entweder an den Gerätehersteller 12 und/oder an den Betriebssystemhersteller 10.
Im Folgenden wird unter Bezugnahme auf 3 ein typischer Ablauf gemäß einer bevorzugten Ausführungsform der Erfindung näher dargestellt.
Das Verfahren beginnt mit dem Schritt START. In diesem Schritt wird ein neuer Betriebssystem-Patch P auf das Applikationssystem AS aufgespielt. Das sich daran anschließende Verfahren, das im Folgenden durch die Verfahrensschritte A, B, C, ... dargestellt ist, bezieht sich auf die Validierung des aufgespielten Betriebssystem-Patches P.
In Schritt A wird automatisch erfasst, ob Änderungen an dem Betriebssystem BS vorliegen. Falls keine Änderungen erkannt werden, müssen keine weiteren Schritte eingeleitet werden.
Anderenfalls, falls also Änderungen am Betriebssystem BS erkannt wurden, wird in Schritt B das Patchmodul PM aufgerufen.
In Schritt C erfolgt eine Meldung auf dem medizinischen Gerät 30, dass Selbsttests ausgeführt werden müssen. Die Meldung kann entweder über ein, auf der Bildschirmoberfläche erscheinendes Popup-Fenster oder über E-Mail oder über sonstige Nachrichten und Kommunikationswege erfolgen.
Nach der Ausführung des Schrittes C kann das Verfahren direkt mit Schritt E fortgesetzt werden. Alternativ ist jedoch auch die Ausführung des Schrittes D möglich. In Schritt D wird das automatische Selbsttestverfahren konfiguriert. Die Konfiguration des automatischen Selbsttests kann entweder manuell, halbautomatisch oder vollautomatisch ausgeführt werden. Bei der manuellen Konfiguration gibt der Systemadministrator bestimmte Voreinstellungen über die Benutzerschnittstelle der Applikation A ein. Bei der automatischen Konfiguration werden voreingestellte Konfigurationen des Patchmoduls PM eingelesen. Hier ist es beispielsweise einstellbar, dass der automatische Selbsttest nach einem konfigurierten Zeitintervall (z. B. Nachts) oder nach Eintreten von konfigurierbaren Ereignissen (z.B. hohes oder niedriges Datenvolumen) ausgeführt wird. Der Schritt D der Konfigurierung kann auch vorgezogen werden und in einer vorlagerten Konfigurationsphase ausgeführt werden.
In Schritt E werden die Testdaten zur Ausführung des automatischen Selbsttestes geladen.
In Schritt F wird der Selbsttest auf dem medizinischen Gerät 30 ausgeführt.
In Schritt F wird ebenfalls ein Testergebnis für den automatischen Selbsttest erfasst. Das Testergebnis hängt von dem jeweiligen medizinischen Gerät 30 bzw. von der Applikation A ab. Handelt es sich bei dem medizinischen Gerät 30 um eine CT-Anlage zur Darstellung von Schichtbildaufnahmen, so dient also die Applikation A zur Darstellung von Schichtbildaufnahmen. Dementsprechend bezieht sich auch das Testergebnis auf die Darstellung von Schichtbildaufnahmen. In einem anderen Anwendungsfall dient die Applikation A mit dem medizinischen Gerät 30 zur Darstellung von Bildern, die im Rahmen einer Koloskopie erfasst wurden. Dementsprechend bezieht sich dann das Testergebnis des automatischen Selbsttestes auf die Darstellung von Koloskopiebildern, die allerdings mit Testdaten simuliert wurden. Eine andere Anwendung kann sich auf das Postprocessing von akquirierten Bilddaten beziehen. In diesem Fall wäre das Ergebnis der Applikation und auch das Ergebnis des Selbsttestes die erfolgreiche Darstellung der Bilddaten auf einem Monitor.
In Schritt G wird dann die eigentliche Validierung durchgeführt. Dabei wird überprüft, ob die Applikation – wie vorgesehen – in der bereitgestellten Funktionalität auch mit dem neuen Betriebssystem-Patch P funktioniert. Dies wird erreicht, in dem das Testergebnis des automatischen Selbsttestes, das in Schritt F erfasst worden ist, mit einem Referenzergebnis auf Übereinstimmung verglichen wird. Hier wird quasi überprüft, ob die Applikation auf dem jeweiligen medizinischen Gerät 30 auch dann fehlerfrei funktioniert und ausgeführt werden kann, wenn der neue Betriebssystem-Patch P installiert worden ist.
Falls der in Schritt G ausgeführte Vergleich eine Übereinstimmung ergeben hat (Ja-Fall) wird das Validierungssignal V ausgegeben. Anderenfalls (keine Übereinstimmung zwischen Testergebnis und Referenzergebnis) wird eine Fehlermeldung F ausgegeben. Diese Fehlermeldung F kann bedarfsweise noch an weitere Instanzen weitergereicht werden. Dies ist in 3 mit dem nach rechts weisenden Pfeil und den angedeuteten drei Punkten dargestellt. Zusätzlich zur Ausgabe der Fehlermeldung F wird in Schritt H ein roll back veranlasst. Üblicherweise umfasst der roll back eine Deinstallation des Betriebssystem-Patches P und die Wiederherstellung des Zustandes des Betriebssystems BS vor Installation des Betriebssystem-Patches P, so dass die Applikation A und das medizinische Gerät 30 weiterhin fehlerfrei ausgeführt werden können und somit auch weiterhin im klinischen Einsatz verwendbar sind. Das vorstehend vorgestellte Verfahren wird repetitiv immer wieder durchlaufen. Dabei kann es auch eingestellt sein, dass das Validierungsverfahren stets bei Hochlaufen des Applikationssystems AS ausgeführt wird. Anderenfalls kann eingestellt werden, dass das Verfahren nur dann ausgeführt wird, falls eine Meldung eingegangen ist, die die Ausgabe eines neuen Betriebssystem-Patches P signalisieren soll.
Es sei ausdrücklich darauf hingewiesen, dass die Reihenfolge der Schritte, wie sie im Ausführungsbeispiel im Zusammenhang mit 3 erwähnt wurden oder wie sie in Anspruch 1 beansprucht sind, auch variiert werden kann. So ist es beispielsweise möglich, dass das Patchmodul PM bereits in einer Installationsphase zu einem vorhergehenden Zeitpunkt an das Applikationssystem AS bzw. an das medizinische Gerät 30 ausgeliefert werden kann. Üblicherweise wird das Patchmodul PM zeitgleich mit dem medizinischen Gerät 30 dem Applikationssystem AS zur Verfügung gestellt. Im Anschluss an diese Konfigurationsphase wird die eigentliche Validierungsphase des Verfahrens ausgeführt. In der Validierungsphase wird der Betriebssystem-Patch P seitens des Betriebssystemherstellers 10 ausgegeben und auf dem Patchmodul PM des medizinischen Gerätes 30 empfangen. Nach Empfang des Betriebssystem-Patches P kann dann der automatische Selbsttest ausgeführt werden, woraufhin im Erfolgsfall ein Validierungssignal V oder im Fehlerfall eine Fehlermeldung F ausgegeben wird.
Zusammenfassend kann die Erfindung wie folgt beschrieben werden:
Mit der Erfindung wird es möglich, auf Anwendungsebene und direkt auf dem medizinischen Gerät 30 unter Verwendung der Benutzeroberfläche des medizinischen Gerätes 30 bzw. der Applikation zu prüfen, ob ein neuer Betriebssystem-Patch P erfolgreich auf dem Zielsystem bzw. Applikationssystem AS, mit dem das medizinische Gerät 30 betrieben wird, installiert werden konnte. Dabei wird auf einem Patchmodul PM, das direkt auf dem medizinischen Gerät 30 bereitgestellt wird, ein Selbsttest ausgeführt. Der Selbsttest wird auf Applikationsebene über die Benutzerschnittstelle der Applikation A betrieben und betrifft somit quasi einen Probebetrieb des medizinischen Gerätes 30 im realen Umfeld unter realen Konfigurationsbedingungen.
Die Erfindung ist grundsätzlich nicht auf eine bestimmte Klasse oder einem bestimmten Typ von medizinischen Geräten 30, Betriebssystemen, Patches und/oder Applikationssystemen beschränkt. Das medizinische Gerät 30 kann z.B. ein Perfusor, ein Anästhesieperfusor, insbesondere ein doppelläufiger Zweikanal-Perfusor für anästhetische Anwendungen, ein Medizingerät für bildgebende Verfahren oder für Postprocessing Verfahren sein. Auch weniger komplexe Geräte, wie z.B. Laborgeräte, Blutdruckmessgeräte liegen im Rahmen der Erfindung. Dementsprechend ist die Applikation zur Bedienung oder Steuerung des medizinischen Gerätes 30 ausgelegt. Die Applikation kann zusätzlich noch weitere Funktionalitäten aufweisen. In diesem Zusammenhang ist darauf hinzuweisen, dass der Grundgedanke der Erfindung nicht auf die vorstehend beschriebenen Beispiele beschränkt ist und ebenso Varianten der offenbarten Beispiele vom Fachmann abgeleitet werden können, ohne den Schutzumfang der Erfindung zu verlassen.

Claims

Verfahren zur Validierung zumindest eines Betriebssystem-Patches (P) für eine Applikation, die auf einem medizinischen Gerät (30) eines Applikationssystems (AS) implementiert ist, umfassend folgende Verfahrensschritte: – Ausgabe eines Betriebssystem-Patches (P) seitens eines Betriebssystemherstellersystems (10) – Bereitstellen eines Patchmoduls (PM) auf dem medizinischen Gerät (30) – Empfang des Betriebssystem-Patches (P) seitens des Patchmoduls (PM) – Ausführen eines automatischen Selbsttests auf dem medizinischen Gerät (30) seitens des Patchmoduls (PM) auf Basis des empfangenen Betriebssystem-Patches (P) und Senden eines Validierungssignals (V) bei erfolgreichem Selbsttestergebnis.
Verfahren nach Anspruch 1, bei dem automatisch der Zustand vor Installation des Betriebssystem-Patches (P) wiederhergestellt wird, falls der Selbsttest nicht erfolgreich abgeschlossen wurde.
Verfahren nach einem der vorstehenden Ansprüche, bei dem der Betriebssystem-Patch (P) seitens des Betriebssystemherstellersystems direkt an das medizinische Gerät (30) gesendet wird.
Verfahren nach einem der vorstehenden Ansprüche, bei dem automatisch eine Fehlermeldung ausgegeben wird, falls der Selbsttest nicht erfolgreich abgeschlossen wurde.
Verfahren nach einem der vorstehenden Ansprüche, bei dem die Ausgabe und/oder der Empfang des Betriebssystem-Patches (P) nach konfigurierbaren Zeitintervallen oder nach konfigurierbaren Ereignissen ausgeführt werden.
Verfahren nach einem der vorstehenden Ansprüche, bei dem der automatische Selbsttest das medizinische Gerät (30) auf Sicherheitslücken testet, die die Gerätefunktionalität kompromittieren würden.
Verfahren nach einem der vorstehenden Ansprüche, bei dem der automatische Selbsttest unter Anwendung der Applikation für das medizinische Gerät (30) mit Testdaten, insbesondere mit medizinischen Bilddaten, ausgeführt und einen Probebetrieb des medizinischen Gerätes (30) simuliert wird.
Verfahren nach einem der vorstehenden Ansprüche, bei dem der automatische Selbsttest unter Verwendung des medizinischen Gerätes (30) und/oder unter Verwendung einer Benutzerschnittelle des medizinischen Gerätes (30) ausgeführt wird.
Verfahren nach einem der vorstehenden Ansprüche, bei dem mit dem automatischen Selbsttest auch geräte- und/oder applikationsspezifische Konfigurationen testabgedeckt sind.
Verfahren nach einem der vorstehenden Ansprüche, bei dem das Patchmodul (PM) gemeinsam mit der Applikation auf dem medizinischen Gerät (30) installiert wird.
Verfahren nach einem der vorstehenden Ansprüche, bei dem eine Änderung an dem Betriebssystem (BS) für die Applikation automatisch durch das Patchmodul (PM) erfasst und ausgewertet wird, um zeit- oder ereignisgesteuert einen Selbsttest zu initiieren.
Patchmodul (PM) für eine Applikation, über die ein medizinisches Gerät (30) gesteuert wird, wobei das Patchmodul (PM) zur Ausführung eines automatischen Selbsttestes bestimmt ist, falls auf dem medizinischen Gerät (30) oder auf einem Applikationssystem (AS) ein Betriebssystem-Patch (P) installiert worden ist und wobei das Patchmodul (PM) zur Validierung eines Betriebssystem-Patches (P) dient.
Computerprogrammprodukt, das in einen internen Speicher eines digitalen Computers geladen werden kann und Softwareroutinen umfasst, mit denen die Schritte gemäß den vorstehenden Verfahrensansprüchen ausgeführt werden, wenn die Softwareroutinen auf dem digitalen Computer ausgeführt werden.