DE102012001456B4 - Versionskontrolle für medizinische Anästhesiegeräte - Google Patents

Abstract

Prüfsystem für ein medizinisches Gerät (G) oder für einen Verbund von medizinischen Geräten (G), umfassend mehrere separate Komponenten (K), wobei jeweils eine Komponente einen Mikroprozessor und zumindest ein ausführbares Programm umfasst, wobei die Programme in unterschiedlichen Versionen auf der jeweiligen Komponente (K) installiert sein können und wobei die Programme, die auf den Komponenten (K) installiert sind, unabhängig voneinander austauschbar und/oder änderbar sind, mit:
- Einem Zulässigkeitsspeicher (MEM), der auf jedem oder ausgewählten medizinischen Gerät(en) ausgebildet ist oder für den ein Zugriffsmodul auf dem jeweiligen medizinischen Gerät (G) bereitgestellt wird, wobei in dem Zulässigkeitsspeicher (MEM) Einträge für alle zulässigen Kombinationen von Versionen der Programme der mehreren Komponenten abgelegt sind
- Einer Release- und Sperrfunktion (RSF), die auf jedem medizinischen Gerät (G) bereitgestellt wird und die Inbetriebnahme des jeweiligen medizinischen Gerätes (G) oder einzelner Funktionen des Gerätes (G) steuert
- Einem Prüfmodul (P), das auf jedem medizinischen Gerät (G) installiert ist oder für jedes medizinische Gerät (G) zugreifbar und dazu bestimmt ist, alle Versionen aller aktuell installierten Programme automatisch als IST-Gerätezustand zu erfassen und das weiter dazu bestimmt ist, auf den Zulässigkeitsspeicher (MEM) zuzugreifen und zu prüfen, ob der erfasste IST-Gerätezustand als zulässiger Zustand in dem Zulässigkeitsspeicher (MEM) als Eintrag existiert und nur bejahendenfalls die Releasefunktion für das medizinische Gerät (G) zu aktivieren.

Description

• Gebiet der Erfindung:
• Die vorliegende Erfindung liegt auf den Gebieten der Medizintechnik und der Elektronik bzw. Informatik. Die Erfindung betrifft insbesondere eine Prüfung von medizinischen Geräten, wie beispielsweise Anästhesiegeräten, die mehrere Komponenten mit Programmen umfassen, wobei die Programme in unterschiedlichen Versionen auf dem Gerät installiert sein können.
• Medizinische Geräte, wie beispielsweise Anästhesiegeräte, sind heutzutage in der Regel durch Software gesteuert und umfassen Komponenten mit einer bestimmten informationstechnologischen Infrastruktur, die in der Regel mit einem Mikroprozessor und darauf laufenden Programmen ausgebildet sind. Eine Versionierung der Software führt dazu, dass unterschiedliche Software-Versionen auf den Komponenten des Gerätes installiert sein können.
• Als problematisch erweist es sich, dass nicht alle Kombinationen von Programmversionen zu einem betriebsfähigen Gerätezustand führen. Bestimmte Kombinationen erweisen sich als inkompatibel, als fehlerhaft und sind deshalb unzulässig und müssen vor Inbetriebnahme und/oder vor Einsatz des Gerätes überprüft werden.
• Stand der Technik:
• Aufgrund von gesetzlichen Vorschriften ist es erforderlich, dass die im Einsatz befindlichen medizinischen Geräte ständig auf Einhaltung von Sicherheitsvorschriften überwacht werden. Diese Prüfung wird meistens manuell durch einen Techniker vorgenommen. Dabei wird auch geprüft, ob stets kompatible Softwareversionen, zur Gerätesteuerung oder zum Betrieb des Gerätes, aufgespielt sind.
• Im Bereich der automatischen Aktualisierung von Software ist es bekannt, aktuelle Software-Versionen, gesteuert von einer zentralen Stelle, zu verteilen. Die DE 103 53 052 A1 beschreibt eine Automatisierungsanlage mit untereinander kommunizierenden Komponenten und einem zentralen Verwaltungssystem, wobei die Software der Komponenten automatisch aktualisiert wird, sofern die aktuelle Software für die jeweilige Komponente freigegeben ist. Die US 6,363,282 B1 beschreibt ein System und ein Verfahren zur Bereitstellung einer automatischen Softwareaktualisierung für ein Programmiergerät eines implantierbaren medizinischen Gerätesystems, wobei die Software zur Aktualisierung des Programmiergerätes von einem entfernten Expertendatenzentrum bereitgestellt und genehmigte Softwareanwendungen an das Programmiergerät übertragen werden.
• Im Stand der Technik ist es bekannt, dass bestimmte Versionen der installierten Programme auf dem Gerät zu einer Störung oder zu einem Fehler führen können. Deshalb bestand ein Weg, um unzulässige Kombinationen zu vermeiden, darin, bei Herstellung und vor Inbetriebnahme, sowie bei jeder Änderung an dem Gerät oder an einer Gerätekomponente, das vollständige Software-Paket (also damit die Gesamtheit aller Programme) auszutauschen. Dieses Vorgehen ist zum einen zeitaufwändig und kostenintensiv und zum anderen fehleranfällig.
• Des Weiteren ist es bekannt, durch einen Servicetechniker vor Ort eine Überprüfung der aufgespielten Programmversionen (wie z.B. Patches oder andere Korrekturauslieferungen der Software) vorzunehmen. Alle neuen Versionsauslieferungen müssen dann (in der Regel vom Gerätehersteller) validiert werden. Erst nachdem die Zulässigkeit des Programms geprüft werden konnte, konnte das Gerät an die medizinische Einrichtung (z.B. Krankenhaus) ausgeliefert werden oder in Betrieb genommen werden, was üblicherweise zu deutlichen Verzögerungszeiten führt.
• Diese Ansätze sind zeitaufwändig und aufgrund der manuellen Ausführung auch fehleranfällig.
• Aufgabe:
• Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, eine technische Umsetzung vorzustellen, mit der das Prüfen von Programmen, insbesondere das Prüfen auf Zulässigkeit von installierten Komponenten von Programmversionen, zum Betreiben eines medizintechnischen Gerätes beschleunigt, verbessert und fehlerfrei ausgeführt werden kann.
• Beschreibung der Erfindung:
• Diese Aufgabe wird durch die beiliegenden Patentansprüche gelöst, insbesondere durch ein Prüfsystem, ein medizinisches Gerä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 das Prüfsystem und/oder das Gerät) und umgekehrt. Demnach können auch die Merkmale, die im Zusammenhang mit dem System 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 zur Prüfung eines medizinischen Gerätes oder eines Geräteverbundes, umfassend mehrere austauschbare, separate Komponenten, wobei jeweils eine Komponente einen Mikroprozessor und zumindest ein ausführbares Programm umfasst, wobei die Programme in unterschiedlichen Versionen auf der jeweiligen Komponente installiert sein können, mit folgenden Verfahrensschritten:
• - Automatisches Erfassen aller Versionen aller aktuell installierten Programme auf allen Komponenten des medizinischen Gerätes als IST-Gerätezustand
• - Zugreifen auf einen Zulässigkeitsspeicher, in dem alle zulässigen Kombinationen von Versionen für die Programme der Gerätekomponenten abgelegt sind
• - Prüfen, ob der erfasste IST-Gerätezustand zulässig ist durch Zugriff auf den Zulässigkeitsspeicher und Abgleich mit den dort hinterlegten Einträgen
• - Aktivieren einer Releasefunktion zur Freischaltung oder Inbetriebnahme des medizinischen Gerätes insgesamt oder einzelner Gerätefunktionen (sofern diese separat aktivierbar sind), falls der erfasste IST-Gerätezustand als zulässig geprüft wurde (andernfalls: Aktivieren oder Beibehalten einer Sperrfunktion, so dass das Gerät oder die Gerätefunktion nicht betrieben werden kann).
• Im Folgenden werden die im Rahmen dieser Anmeldung verwendeten Begrifflichkeiten näher erläutert.
• Das Verfahren ist computer-implementiert und läuft bevorzugt vollautomatisch ab, das heißt ohne jegliche Benutzerinteraktion eines Anwenders. Das Verfahren kann teilweise oder vollständig software-basiert sein. Darüber hinaus ist es möglich, das Verfahren bzw. System als embedded system in das Anästhesiegerät oder die medizintechnische Anlage und/oder in einen Steuerrechner (z.B. im Rahmen eines zentralen Servers) einzubetten bzw. zu integrieren. Das Verfahren dient der Speicherung, Verarbeitung und Weiterleitung von aufbereiteten Daten (in Form von Zulässigkeits- und Validierungssignalen und eines Release- und Sperrsignals) anhand computerbasierter technischer Geräte (Netzwerk) an andere Instanzen. Die Eingangsgrößen zur Berechnung und/oder Verarbeitung (die Komponenten des Gerätes) werden abweichend adressiert (versionsspezifisch) und sind somit modifiziert gespeichert. Damit berücksichtigt das Verfahren auch die Gegebenheiten der Datenverarbeitungsanlage, indem für den Betrieb des Gerätes die Komponenten und deren Programme geprüft werden.
• 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 Versionseinspielungen 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 Gerät handelt es sich üblicherweise um ein Anästhesiegerät, umfassend mehrere Prozessoren mit individueller Software oder Firmware, z.B. mit einem Motherboard mit zwei Mikroprozessoren, Spannungsversorgungen etc. Die Erfindung ist jedoch nicht nur auf Anästhesiegeräte beschränkt, sondern kann auch für Beatmungsgeräte, Wärmebetten, OP-Leuchten etc. angewendet werden. In der Regel sind die Platinen (Komponenten) mit individuellen Versionen von Firmware ausgebildet, die unterschiedliche Updates, Patches und/oder Änderungen nach sich ziehen. Wenn beispielsweise die Firmware einer ersten Komponente als fehlerhaft identifiziert worden ist und deshalb ausgetauscht oder verändert worden muss, so kann es durchaus sein, dass die anderen Komponenten mit Firmware aus diesem Grund nicht ebenfalls ausgetauscht werden müssen und unverändert beibehalten werden können. Dies wird durch das Prüfen bzw. durch das Prüfmodul ausgeführt. Damit kann vorteilhafterweise der Verwaltungsaufwand für das Gerät deutlich verringert werden. Dennoch kann sichergestellt werden, dass vor jeder Geräte-Inbetriebnahme ein Konsistenzcheck für die Steuerprogramme ausgeführt wird. Die Erfindung kann jedoch auch auf andere medizinische Geräte (z.B. Laborgeräte, Medizingeräte zur Diagnose, Geräte zur Messung von physiologischen Parametern eines Patienten) angewendet werden, die ebenfalls Komponenten umfassen, die über zumindest ein Programm gesteuert und/oder betrieben werden. Die Programme sind auf den einzelnen Komponenten implementiert und können üblicherweise vollautomatisch ablaufen (ohne Benutzerinteraktion). Alternativ umfasst die jeweilige Applikation eine Benutzeroberfläche, über die ein Benutzer mittels der Applikation das medizintechnische Geräte bedienen, steuern und/oder überprüfen kann.
• Bei den Komponenten handelt es sich um elektronische, Computer-basierte Komponenten, die unabhängig voneinander austauschbar sind. Bei den Komponenten handelt es sich beispielsweise um Gassensoren, Drucksensoren, physiologische Parameter, Netzteil, RFID-Antenne und/oder Tag-Analyse. Die Komponenten sind mittels Netzwerk (oder Bus-System, gemeinsamer Ressourcen, anderer Schnittstellen und/oder asynchron durch Speichermedien) zum Datenaustausch miteinander verbunden. Die Komponenten werden mit Software oder Programmen betrieben. Diese können als Microprozessorprogramm in einem non-volatilen (nicht-flüchtigen) elektronischen Speicherbaustein implementiert sein (z.B. in einem EPRROM oder EEPROM und/oder auf Massenspeichern, z.B. HHD oder SSD-Laufwerken) oder als Software-Applikation oder Applet bereitgestellt werden. Jedes Programm wird im Laufe des Produktlebenszyklus' üblicherweise in mehreren Versionen (z.B. durch Funktionsänderungen oder Fehlerbehebungen) bereitgestellt. Neben einer Originalversion werden im Rahmen einer Produktweiterentwicklung Korrekturversionen, Patches oder neue, verbesserte Versionen (releases) erstellt, die dann auf die jeweilige Komponenten auf dem Gerät aufgespielt werden müssen. In der bevorzugten Ausführungsform der Erfindung betreffen die Komponenten einzelne Bauteile eines Anästhesiegerätes oder eines anderen medizintechnischen Gerätes. Üblicherweise umfasst ein medizintechnisches Gerät eine Vielzahl von separaten Komponenten. Wesentlich ist, dass die Komponenten auch unabhängig voneinander mit (neuer) Software versehen werden können. Beispielsweise kann hier ein Download von Software-Versionen von einem zentralen Server vorgesehen sein, der wahlweise von der Komponente oder vom Server ausgelöst werden kann. Es ist somit sowohl ein Austausch der Komponenten an sich (umfassend Geräte-Komponenten), als auch ein Austausch der Steuerungssoftware für die Komponenten möglich. Der Austausch muss nicht zwangsläufig durch den Anwender ausgeführt werden, sondern kann im Rahmen einer Wartung von einem Wartungsingenieur durchgeführt werden, so dass ein Wechsel bzw. eine Änderung am Gerät für den Geräte-Anwender und/oder -Betreiber nicht unmittelbar sichtbar sein muss.
• Die Menge von zulässigen Kombinationen von Programmen ist vorzugsweise in einer Datenbank vorgehalten. Zur Suche nach zulässigen Kombinationen kann ein erfindungsgemäßes Retrievalsystem mit einer Trunkierungsfunktion (z.B. mittels wildcards) ausgebildet sein. Die Suche nach zulässigen Versionskombinationen kann zentral (in der Abteilung, in der medizinischen Einrichtung und/oder auch auf einem zentralen Server, z.B. bei Dräger Medical) oder auch lokal von dem jeweiligen Gerät ausgeführt werden.
• Üblicherweise wird eine Geräte-Komponente jeweils durch ein Steuerungsprogramm gesteuert. Somit ist eine bijektive (1:1) - Zuordnung zwischen Programm und Komponenten vorgesehen. Alternativ sind auch andere Zuordnungen möglich, so dass einerseits auf einer Geräte-Komponente auch unterschiedliche Programme installiert sein können, und dass andererseits ein umfassendes Steuerprogramm für unterschiedliche Geräte-Komponenten bereitgestellt wird.
• Bei dem Zulässigkeitsspeicher handelt es sich um ein Speichermodul, eine Speicherkarte oder um einen mobilen Datenträger (z.B. einen USB-Stick). Der Speicher ist beschreibbar und/oder programmierbar (z.B. Flash-(E)EPROM, EPROM, PROM etc.). Der Zulässigkeitsspeicher ist vorzugsweise (um die Sicherheit zu erhöhen) physikalisch getrennt von einem Programmspeicher. In einer alternativen Ausführungsform der Erfindung ist der Zulässigkeitsspeicher nicht physikalisch, aber logisch getrennt vom Programmspeicher. In einer alternativen, rein Software-basierten Variante der Erfindung kann der Zulässigkeitsspeicher auch als Datenstruktur oder Datenbank ausgebildet sein (z.B. in dem Massenspeicher, z.B. HDD, EPROM, der auch den Programmcode selbst enthalten kann), auf die von dem Gerät zugegriffen werden kann, um die erfindungsgemäße Versionsprüfung durchzuführen. In dem Zulässigkeitsspeicher sind alle zulässigen Kombinationen von Programmversionen aller Geräte-Komponenten abgelegt. Die Menge von zulässigen Programmversionen bzw. Software-Paketen kann auch als „Snapshot“ bezeichnet werden und kann üblicherweise bei Herstellung des Gerätes und auch während des Geräte-Betriebs definiert und/oder dynamisch angepasst (geändert) werden. „Zulässige“ Programmkombination bedeutet also eine Kombination von Programmversionen (der aktivierten Komponenten), die funktional kompatibel sind und einen fehlerfreien funktionalen Betrieb des Gerätes sicherstellen. Eine Menge von zulässigen Programmversionskombinationen wird in vorkonfigurierbaren Tests generiert. Diese Menge ist dynamisch anpassbar (und kann insbesondere verkleinert und erweitert werden). Bei den Tests handelt es sich z.B. um Freigabe-Tests. Die Tests können zentral, z.B. in einer Verifikations-Abteilung bei dem Gerätehersteller, ausgeführt werden. Dort wird jede Kombination („snapshot“) per Unterschrift freigegeben und dann in eine Datenbank zur Distribution auf die Geräte eingetragen. Die Tests sind automatisierbar. So ist es auch möglich, externe Verifikationsdienstleister einzubinden und deren gesicherten Ergebnisse in die Datenbank einzuspeisen. Der Gerätehersteller stellt eine Master-Datenbank für freigegebene Kombinationen bereit und sichert deren Anpassung bzw. Ergänzung ab.
• Es wird eine Releasefunktion bereitgestellt (vorzugsweise als Teil einer Release- und Sperrfunktion). Bei der Releasefunktion handelt es sich um eine Einstellung des Gerätes, die die Inbetriebnahme des jeweiligen medizinischen Gerätes oder einer separat aktivierbaren Gerätefunktion auslösen oder (als Sperrfunktion) verhindern kann. Die Releasefunktion ist abhängig vom Prüfergebnis. Mit anderen Worten wird die Releasefunktion dann aktiviert, wenn die Versionsprüfung erfolgreich beendet worden ist, anderenfalls wird die Sperrfunktion aktiviert, so dass das jeweilige Gerät oder die Gerätefunktion nicht einsatzfähig ist und zunächst eine Änderung der Komponentenprogramme ausgeführt werden muss. Die Releasefunktion dient somit zur unmittelbaren Steuerung des medizintechnischen Gerätes. In der Regel ist es vorgesehen, dass zunächst eine Sperrfunktion aktiviert ist, so dass das Gerät ohne eine Versionsprüfung nicht betrieben werden kann. Erst nachdem die Versionsprüfung erfolgreich abgeschlossen werden konnte, kann die Releasefunktion zur Inbetriebnahme des Gerätes oder Freischaltung der Gerätefunktion aktiviert werden. Je nach Ausführungsform hat die Releasefunktion (synonym verwendet zu Release- und Sperrfunktion) unterschiedlichen Umfang. So kann sie in einer ersten Variante das gesamte Gerät betreffen und in einer zweiten Variante kann sie nur einzelne Gerätefunktionen betreffen. In der zweiten Variante können dann einzelne Gerätefunktionen aufgrund der Überprüfung freigeschaltet bzw. gesperrt werden. Zum Beispiel kann bei einem Anästhesiegerät eine andere Gasmess-Komponente verwendet werden (der Austausch kann beispielsweise auch während des Betriebs erfolgen). Dann bleibt das gesamte Gerät in der Regel in Betrieb, aber einzelne Gerätefunktionen werden nicht mehr unterstützt, z.B. die Regelung auf eine bestimmte Gaskonzentration, wenn der Messwert zu ungenau geworden ist. Die Überprüfung und Freischaltung bzw. Sperrung ist auch möglich, nachdem das Gesamtgerät in Betrieb genommen worden ist.
• Das Prüfen erfolgt vorzugsweise vollautomatisch und umfasst einen Abgleich mit Einträgen aus dem Zulässigkeitsspeicher. Die Prüfung bezieht sich insbesondere darauf, ob eine Kombination von aktuell installierten Programmversionen zulässig ist. Die Prüfung kann in Abhängigkeit vom (geographischen) Standort ausgeführt werden, da für einige Länder / Regionen spezifische Freigabeprozeduren gelten, so dass bestimmte Versionen und deren Kombinationen nicht an jedem Standort in Betrieb gehen dürfen. In einer weiteren vorteilhaften Ausführungsform kann das Prüfen in Abhängigkeit vom Einsatzzweck („intended use“) ausgeführt werden. Komplexere Weiterbildungen umfassen weitere Prüfungsmaßnahmen, wie eine erfolgreiche Autorisierung, eine Prüfung, ob das jeweilige Programm auch auf der „passenden“ (nach vorheriger Zuordnung) Komponente installiert ist, eine Prüfung ob die Version auch die jeweils aktuellste ist.
• Gemäß einer bevorzugten Ausführungsform der Erfindung kann der Zulässigkeitsspeicher dynamisch aktualisiert werden. Die Aktualisierung des Zulässigkeitsspeichers kann zum einen vor (der ersten) Inbetriebnahme des Gerätes und auch später während des (klinischen oder sonstigen) Einsatzes des medizinischen Gerätes ausgeführt werden. Die Aktualisierung kann durch Synchronisierung mit einem zentralen Server und/oder durch Einspielen von aktualisierten Einträgen (z.B. über eine Netzwerkverbindung, beispielsweise Internet) ausgeführt werden. Alternativ kann das medizinische Gerät auch über eine entsprechende Verbindung (kabelgebunden oder kabellos) mit einem Service-PC erfolgen. Weitere Einspielmöglichkeiten betreffen: Speichermedien, Datenträger und/oder auch zum Gerät neu hinzugefügte Komponenten. Des Weiteren ist es auch möglich, das medizinische Gerät über steckbare Komponenten (umfassend Speicherkarten oder Sticks etc.) in Datenaustausch mit aktualisierten Zulässigkeitsinformationen zu bringen. Ebenso können die aktualisierten Zulässigkeitsdaten unmittelbar auf den steckbaren Komponenten abgelegt sein und so in das Gerät eingelesen werden. Darüber hinaus ist es möglich, die austauschbaren Komponenten des Gerätes und/oder die Sensoren etc. selbst in Datenaustausch mit aktualisierten Zulässigkeitsinformationen zu bringen, da deren Kommunikationsprotokoll entsprechend die Aktualisierung erlauben muss. Damit kann die Flexibilität der Versionsüberprüfung erhöht werden, da die Einspielung von aktualisierten Zulässigkeitsdaten nicht auf eine bestimmte Form für die Bereitstellung der Zulässigkeitsdaten beschränkt ist.
• Gemäß einem weiteren Aspekt der Erfindung kann das Prüfen auch von zentraler Instanz ausgelöst werden. Damit besteht die Möglichkeit, bestimmte Kombinationen zu widerrufen, also Freigaben wieder zu entziehen. Diese Ausführung wird u.a. genutzt, wenn die zentrale Instanz Problemberichte erhält, die signalisieren, dass die implementierte Kombination auf dem Gerät nicht zulässig ist bzw. nicht verifiziert werden kann.
• Gemäß einem Aspekt der Erfindung sind Betreiberdaten (also Daten, die für den Betrieb und die Funktionalität des jeweiligen Gerätes relevant sind) getrennt von den Zulässigkeitsdaten abgelegt. Insbesondere sind die Programme in einem anderen Speicher (dem Programmspeicher) oder in einem anderen Speicherbereich abgelegt, der getrennt vom Zulässigkeitsspeicher ist und/oder getrennt vom Zulässigkeitsspeicher zugreifbar ist. Der Begriff „getrennt“ umfasst eine physikalische und eine logische Trennung der jeweiligen Speicher(bereiche). Diese Ausführungsform birgt den Vorteil, dass die Versionsüberprüfung aufgrund der getrennten Speicherung nur schwer korrumpierbar ist. Ein weiterer Vorteil liegt darin, dass die eigentlichen Programme für eine klinische Verwendung (CE-Zeichen) freigegeben werden können, und die Freigabe nicht erneuert werden muss durch Änderungen am Zulässigkeitsspeicher, da das Programm nicht geändert wird. Damit kann die Sicherheit der Versionsüberprüfung und damit auch die Sicherheit des medizinischen Gerätes verbessert werden. Des Weiteren wird es damit möglich, die Geräte-Überprüfung (insbesondere Versionsüberprüfung) von dem eigentlichen Geräte-Betrieb zu trennen.
• Um die Sicherheit der Versionsüberprüfung weiter erhöhen zu können, ist es in einer vorteilhaften Weiterbildung der Erfindung vorgesehen, dass der Zulässigkeitsspeicher gesichert ist. Insbesondere sind Änderungen (umfassend Neueinträge, Änderungen an bestehenden Einträgen, sowie Löschungen von Einträgen) nur nach einer erfolgreichen Authentisierung ausführbar (z.B. durch eine digitale Signatur der Änderungsdaten oder durch eine verschlüsselte Übertragung, deren erfolgreiche Entschlüsselung den Sender als vertrauenswürdig authentisiert). Um die Sicherheit noch weiter erhöhen zu können, kann es vorgesehen sein, dass die Einträge in dem Zulässigkeitsspeicher verschlüsselt abgelegt sind und somit auch von einem authentisierten User ohne Entschlüsselung nicht lesbar sind. Dazu kann beispielsweise ein symmetrisches oder asymmetrisches Verschlüsselungsverfahren (z.B. basierend auf dem RSA-Algorithmus) angewendet werden.
• Die Versionsüberprüfung wird vorzugsweise in dem Prüfmodul ausgeführt. Das Prüfmodul kann dabei als Software-Tool auf dem Gerät installiert bzw. implementiert sein. Alternativ ist es auch möglich, das Prüfmodul auf einer zentralen Computer-basierten Instanz bereitzustellen und an die jeweiligen Geräte anzuschließen. Ebenso ist es möglich, das Prüfmodul nur auf ausgewählten Geräten bereitzustellen, über die dann mittelbar andere (über eine entsprechende Datenverbindung angeschlossene) Geräte geprüft werden können. Dies hat den Vorteil, dass nicht alle medizinischen Geräte mit einem Prüfmodul ausgebildet werden müssen. Dies erweist sich insbesondere dann als sinnvoll, falls üblicherweise eine Gruppe von medizinischen Geräten kombiniert werden muss. Je nach Ausführungsform können unterschiedliche Szenarien zur Aktivierung des Prüfmoduls implementiert werden. Üblicherweise ist es vorgesehen, dass das Prüfmodul automatisch vor jeder Inbetriebnahme des medizinischen Gerätes aktiviert wird. Alternativ oder kumulativ kann das Prüfmodul auch nach Erfassen einer Änderung an dem medizinischen Gerät und/oder in vorkonfigurierbaren Zeitintervallen und/oder Ereignissen automatisch aktiviert werden. Ebenso ist es möglich, dass nach einer erfassten Änderung an dem medizinischen Gerät die Sperrfunktion des Prüfmoduls vorkonfiguriert ist bzw. aktiviert wird. Damit kann vorteilhafterweise sichergestellt werden, dass immer und automatisch eine Überprüfung der Programmversionen auf Zulässigkeit ausgeführt wird, falls eine Änderung am Gerät erkannt wurde. Wurde beispielsweise eine Gerätekomponente ausgetauscht oder eine neue Version der Steuerungssoftware eingespielt, so kann das Gerät nur in Betrieb genommen werden, falls die Versionsprüfung erfolgreich ausgeführt werden konnte.
• Gemäß einem Aspekt der Erfindung ist es vorgesehen, dass bei erfolgreicher Versionsprüfung ein Zulässigkeitssignal ausgegeben wird. Dies kann beispielsweise auf einer Benutzeroberfläche des medizinischen Gerätes (soweit vorhanden) dargestellt werden und/oder es kann an einen zentralen Server übermittelt werden. Das Zulässigkeitssignal kann auch implementiert werden als Wert (Flag) bzw. Änderung einer Speicherzelle. Es bedarf keiner physikalisch eigenständigen Ausbildung. Bei fehlgeschlagener Überprüfung kann ein Fehlersignal ausgegeben werden. Alternativ kann das Fehlersignal an einen Steuerungsrechner (z.B. zentraler Server) übermittelt werden, um weitere Schritte anzustoßen. Beispielsweise kann hier die Neuinstallation von Programmversionen getriggert werden oder über eine Internet-Verbindung ein Service-Techniker informiert werden.
• Eine weitere Aufgabenlösung besteht in einem medizinischen Gerät, auf dem die vorstehend beschriebene Release- und Sperrfunktion zur Versionsprüfung implementiert ist.
• Die Release- und Sperrfunktion läuft vollautomatisch (ohne Benutzerinteraktion) ab und wird insbesondere vor Inbetriebnahme des Gerätes und bei Änderungen (an Komponenten) des Gerätes ausgelöst. In einer weiteren vorteilhaften Ausführungsform der Erfindung umfasst das Gerät neben der Release- und Sperrfunktion das Prüfmodul und/oder den Zulässigkeitsspeicher (dies ist jedoch nicht zwingend erforderlich und nur optional). Mit anderen Worten kann das Prüfmodul ebenfalls auf dem Gerät oder auf einer anderen Computer-basierten Instanz installiert sein, die in Datenaustausch mit dem Gerät steht. Dies verringert den Installationsaufwand bei den Geräten und erhöht die Flexibilität bei der Umsetzung des erfindungsgemäßen Prüfverfahrens. Komplexere Weiterbildungen des Gerätes umfassen darüber hinaus noch weitere Module (etwa wie vorstehend bereits im Zusammenhang mit dem Verfahren beschrieben: ein Modul zur Autorisierungsüberprüfung, ein Zuordnungsüberprüfungsmodul etc.).
• Eine weitere Lösung der vorstehend genannten Aufgabe besteht in einem Prüfsystem für ein medizinisches Gerät nach dem beiliegenden Patentanspruch. Gemäß einem Aspekt der Erfindung umfasst das Prüfsystem einen Zulässigkeitsspeicher, in dem zulässige Kombinationen von Versionen für die Steuerungsprogramme der Komponenten abgelegt sind, eine Release- und Sperrfunktion und ein Prüfmodul. Es sei ausdrücklich darauf hingewiesen, dass der Schutzumfang dieser Anmeldung nicht darauf beschränkt ist, dass alle der vorstehend genannten Module bzw. Bausteine des Systems (Prüfmodul, Zulässigkeitsspeicher, Release- und Sperrfunktion) auf derselben Instanz (Gerät und/oder zentraler Server oder weiteren Instanzen) ausgebildet sein müssen. In einer bevorzugten Ausführungsform sind der Zulässigkeitsspeicher, die Release- und Sperrfunktion und das Prüfmodul auf dem jeweiligen Gerät ausgebildet. Alternativ ist es auch möglich, nur die Release- und Sperrfunktion auf dem Gerät auszubilden und den Zulässigkeitsspeicher und das Prüfmodul auf zuschaltbaren Computer-basierten Instanzen bereitzustellen.
• Mit dem erfindungsgemäßen Prüfsystem bzw. Prüfmodul können Sicherheitslücken geschlossen werden, die durch inkonsistente Steuerungsversionen für die Geräte-Komponenten entstehen und die Geräte-Funktionalität insgesamt kompromittieren würden.
• Vorzugsweise ist das Prüfmodul in die technische Einrichtung bzw. in das medizintechnische Gerät eingebettet. Das Prüfmodul dient der Verarbeitung, Speicherung und/oder Übermittlung von Prüfdaten in Bezug auf das medizintechnische Gerät. Die Release- und Sperrfunktion steuert die Freischaltung und/oder die Inbetriebnahme des medizintechnischen Gerätes und betrifft somit das unmittelbare Zusammenwirken der Geräte bzw. angeschlossenen Computer-basierten Instanzen. Dabei kann sichergestellt werden, dass ein medizintechnisches Gerät nur dann betrieben wird, falls eine Versionsüberprüfung erfolgreich abgeschlossen werden konnte. Damit werden sowohl das Gerät als Ganzes als auch die Geräte-Komponenten modifiziert betrieben. Bisher führte das Anschalten des Gerätes (evtl. nach bekannten Autorisierungsmaßnahmen) unmittelbar zur Inbetriebnahme des Gerätes. Das Anschalten oder Einbinden des Gerätes in das medizintechnische System (z.B. OP-System) führt zur automatischen Auslösung der Prüffunktion bzw. des Prüfmoduls. Damit werden Geräte-Komponenten abweichend adressiert. Das zur Versionsprüfung verwendete Datenverarbeitungsprogramm steht in Datenaustausch (insbesondere über die Kennung der Versionen der Komponenten, sowie das Release- und Sperrsignal) mit allen Geräte- und/oder Hardware-Komponenten des medizintechnischen Gerätes.
• Gemäß einem Aspekt kann die Prüfung der installierten Versionen auf Zulässigkeit auch im Rahmen des automatischen Selbsttests des Gerätes ausgeführt werden.
• Um die Sicherheit weiter zu erhöhen, kann es vorgesehen sein, dass die Versionsüberprüfung automatisch nach konfigurierbaren Zeitintervallen und/oder nach konfigurierbaren Ereignissen (insbesondere bei einer erfassten Geräte-Änderung oder einer Änderung an anderen Komponenten des umfassenderen Systems) ausgeführt wird. Die vorstehend genannt Ereignisse umfassen in einer bevorzugten Ausführungsform:
• - Ein Anschalten des Gerätes
• - Ein Empfang eines Prüfbefehls einer zentralen Instanz
• - Eine Änderung an einer Komponente
• - Eine Änderung der verfügbaren Komponenten
• - Eine Änderung am Inhalt des Zulässigkeitsspeichers.
• Die Versionsüberprüfung wird grundsätzlich auf zwei Hierarchieebenen angewendet bzw. implementiert. Die Versionsprüfung wird
• - für ein Gerät mit einer Reihe (identischer oder unterschiedlicher) Komponenten und
• - auf einem System bzw. Geräteverbund, in dem jedes Gerät die Rolle einer Komponente spielt, ausgeführt.
• Bedarfsweise ist es möglich, den erfassten IST-Zustand auf einer Benutzeroberfläche (auf dem zu überprüfenden Gerät, auf einem spezifischen Monitorgerät und/oder auf einem zentralen Server) darzustellen. Dabei kann auch eine Zuordnung zwischen den Komponenten und den darauf installierten Programmversionen dargestellt werden, um beispielsweise einem Wartungsingenieur relevante Wartungsdaten anzuzeigen.
• Die zulässigen Kombinationen von Versionen für die Geräte-Komponentenprogramme (Snapshot) können Geräte-spezifisch sein, so dass sich die Menge von Gerät zu Gerät unterscheiden kann. Alternativ kann der Snapshot auch abhängig von dem jeweiligen Betrieb des Gerätes sein, also somit Applikations-spezifisch.
• Das Prüfmodul ist dazu bestimmt, alle Versionen aller aktuell installierten Programme automatisch als IST-Gerätezustand zu erfassen. Dieser IST-Gerätezustand kann dann (bei Bedarf, insbesondere nach Erfassen einer Änderung) mit einem SOLL-Zustand als einer Menge von zulässigen Zuständen verglichen werden. Dabei ist die Menge aller zulässigen Zustände in dem Zulässigkeitsspeicher abgelegt. Sobald also eine neue Programmversion für nur eine oder mehrere Gerätekomponenten aufgespielt wird, ändert sich der IST-Zustand und wird automatisch aktualisiert, um die Versionsprüfung auslösen zu können. Dabei wird berücksichtigt, dass eine lokale Änderung (z.B. Erweiterung) an einer Komponente in der Regel nur Auswirkungen auf sehr wenige weitere Komponenten hat, so dass das Einspielen eines kompletten Software Packages (für alle Komponenten) nicht erforderlich ist, um den fehlerfreien Betrieb des Gerätes sicherstellen zu können. Vorteilhafterweise lässt sich damit der Verwaltungsaufwand zur Betriebsprüfung des Gerätes einerseits und auch andererseits der Aufwand, der mit der Bereitstellung der Update-Versionen verbunden ist, deutlich minimieren.
• 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 oder über eine Schnittstelle von einer Computerinstanz heruntergeladen werden.
• 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.
• Kurzbeschreibung der Figuren:
• 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 entsprechend einer bevorzugten Ausführungsform der Erfindung,
• 2 eine schematische Darstellung eines Systems, umfassend mehrere medizintechnische Geräte gemäß einer Ausführungsform der Erfindung und
• 3 ein Datenflussdiagramm eines Versionsüberprüfungsverfahrens entsprechend einer bevorzugten Ausführungsform der Erfindung.
• Detaillierte Figurenbeschreibung:
• 1 zeigt in schematischer Form den Aufbau eines erweiterten medizintechnischen Gerätes, insbesondere eines Anästhesiegerätes, das in den Figuren mit den Bezugszeichen G gekennzeichnet ist. Das Anästhesiegerät G umfasst mehrere Bauteile und/oder elektronische Komponenten K, die über ein Computerprogramm gesteuert und/oder betrieben werden, wie z.B. solche zur Messung von Flow und Druck, zur Messung der Gaskonzentration verschiedener Gase (zum Teil mehrfach ausgelegt), zur RFID-Lesung und -Auswertung, zur Messung von physiologische Daten des Patienten und/oder ein Netzteil. Die technische Lehre kann weiterhin z.B. auf folgende Komponenten K angewendet werden: auf ein Flowmeter (Rotameter) zur Bestimmung der Durchflussmenge von Gasen sein, auf ein ORC-System (Oxygen Ratio Controller) oder Weiterentwicklungen, wie ein sensitiver ORC und - je nach Ausrichtung des Gerätes G - auch auf einen elektronisch arbeitenden Messfühler (Flowsensor) zur Bestimmung der jeweiligen Gasanteile bzw. zur Messung des Atemhub- und Atemminutenvolumens. Weitere Anwendungen betreffen beispielsweise einen elektronischen Volumeter, ein elektronisches Manometer und weitere elektronische Komponenten, die über ein Bussystem in Datenaustausch stehen.
• Neben den oben erwähnten Bauteilekomponenten umfasst das Gerät G noch weitere Motherboards K, und weitere Komponenten K, die in der Regel mit individuellen Firmware-Versionen ausgeliefert werden. Die einzelnen Programme unterliegen dabei unterschiedlichen Update Zyklen. Wenn beispielsweise ein Fehler (bug) an der PGM-Firmware fixiert werden kann, so ist es erfindungsgemäß nicht notwendig, die gesamte Software zum Betreiben des Gerätes G zu ändern oder Programme anderer Komponenten zu ändern, falls diese von der Fehleränderung (bugfix) der PGM-Firmware nicht betroffen sind.
• Darüber hinaus umfasst das Anästhesiegerät G einen Zulässigkeitsspeicher MEM, eine Release- und Sperrfunktion RSF und ein Prüfmodul P. Die vorstehend beschriebenen Ausführungsbeispiele des Anästhesiegerätes G sind jedoch nur exemplarisch zu verstehen und können in alternativen Ausbildungen kombiniert und/oder auch noch weitere Bauteile (auch nicht elektronische) und Komponenten K umfassen.
• 2 zeigt eine Übersichtsdarstellung (ebenfalls schematisch) mehrerer Geräte und deren Einbindung in ein Gesamtsystem. So ist ein erstes Gerät G₁, ein zweites Gerät G₂, ein drittes Gerät G₃ etc. über ein Netzwerk NW mit einem zentralen Server S verbunden. Die medizintechnischen Geräte (insbesondere Anästhesiegeräte) G sind dahingehend erweitert, dass sie die Release- und Sperrfunktion RSF umfassen, die bei nicht erfolgreicher Versionsprüfung das Gerät sperren und nicht betreibbar schalten und die bei erfolgreicher Versionsüberprüfung das jeweilige Gerät G für die Inbetriebnahme freischalten. Die Prüfung auf Konsistenz der Programmversionen kann innerhalb des Gerätes G, aber auch extern ausgeführt werden. Im letzteren Fall wird das Ergebnis der Prüfung an das Gerät G weitergeleitet, um die Release- und Sperrfunktion RSF entsprechend ansteuern zu können.
• Im Folgenden wird unter Bezugnahme auf 3 der Ablauf eines erfindungsgemäßen Prüfverfahrens gemäß einer bevorzugten Ausführungsform näher beschrieben.
• Das Verfahren wird automatisch gestartet durch vorkonfigurierbare Triggersignale. Falls eines der Triggersignale auf dem Gerät G und/oder auf dem zentralen Server S erfasst wird, wird die Überprüfung (automatisch) gestartet. Gemäß einer bevorzugten Ausführungsform sind folgende Triggersignale vorgesehen:
1. A: Anschalten des Gerätes G oder Anschalten bzw. Aktivieren einer Komponente K des Gerätes G
2. B: Zumindest eine Komponente K wurde geändert
3. C: Zumindest eine Konfiguration wurde geändert
4. D: Der Inhalt eines Zulässigkeitsspeichers MEM wurde geändert.
• In alternativen Ausführungsformen sind hier noch weitere Triggersignale definierbar, die z.B. ein Ereignis des Geräteverbundes betreffen können (Stromausfall etc.)
• Nach dem Start des Verfahrens erfolgt in Schritt 10 ein Zugriff auf einen Zulässigkeitsspeichers MEM. Der Zulässigkeitsspeicher MEM umfasst Einträge für alle zulässigen Kombinationen von Versionen für die Komponentenprogramme (also für die Steuersoftware der beteiligten Komponenten K des Gerätes G). Der Zulässigkeitsspeicher MEM ist - wie vorstehend bereits unter Bezugnahme auf 1 beschrieben - auf dem Gerät G ausgebildet.
• In Schritt 20 erfolgt das automatische Erfassen eines IST-Geräte-Zustandes. Der IST-Geräte-Zustand kann auch als Snapshot bezeichnet werden und umfasst alle konsistenten Programmversionen. Diese Menge umfasst insbesondere alle relevanten (also für den Betrieb/die aktuelle Verwendung aktivierten und benötigen) Komponenten K des Gerätes G und deren Steuerprogramme für die Komponenten K. Alle Kombinationen von Versionen von Komponentenprogrammen, für die keine fehlerfreie Geräte-Funktion nachgewiesen werden kann, werden nicht in den Zulässigkeitsspeicher MEM geschrieben. Gemäß der bevorzugten Ausführungsform der Erfindung sind in dem Zulässigkeitsspeicher MEM somit die zulässigen Versionen gespeichert. Alternativ kann der Speicher auch mit dem logischen Gegenteil beschrieben werden und umfasst dann nur inkompatible oder inkonsistente Versionen, die zu einem Gerätefehler führen würden (bei der Prüfung führt dann der Vergleich zwischen IST-Zustand und den im Speicher MEM abgelegten Einträgen bei Übereinstimmung zur Auslösung der Sperrfunktion). In einer bevorzugten Weiterbildung werden die Kombinationen von Programmen, für die Fehler erfasst wurden, in einen Fehlerspeicher gespeichert. Falls bei Erfassen des IST-Geräte-Zustandes eine solche (unzulässige) Version bzw. Kombination erkannt worden ist, wird automatisch ein Alarmsignal ausgegeben.
• Im nächsten Verfahrensschritt 30 erfolgt die eigentliche Versionsprüfung. Hier wird der erfasste Gerätezustand, der IST-Geräte-Zustand, mit einer Menge von zulässigen Zuständen verglichen. Die Menge von zulässigen Zuständen ist im Zulässigkeitsspeicher MEM abgespeichert. Das Prüfergebnis hat grundsätzlich zwei Ausgänge:
1. 1. Falls der Test erfolgreich verläuft und sichergestellt werden kann, dass auf dem jeweiligen Gerät G eine zulässige Version von Steuerprogrammen installiert ist, wird in Schritt 50 die Release-Funktion aktiviert und das Gerät G wird in Betrieb genommen bzw. zur Inbetriebnahme freigeschaltet.
2. 2. Falls die Versionsprüfung nicht zu einem erfolgreichen Testergebnis führte, wird eine Sperrfunktion 40 aktiviert. Vorzugsweise ist die Sperrfunktion 40 in der bevorzugten Ausführungsform bereits vorkonfiguriert, so dass hier keine weitere Schaltung bzw. kein Wechsel notwendig ist. In diesem Fall bleibt das Gerät gesperrt und ist nicht betriebsfähig. Daraufhin kann das Verfahren enden oder es wird iterativ für einen neuen IST-Geräte-Zustand ausgeführt (dies soll in 3 mit dem Bezugszeichen 60 gekennzeichnet sein, das einen Zustand repräsentiert, der mit „Warte auf Triggersignal“ zu beschreiben ist). Sobald eine Änderung an dem Gerät G erfasst wurde, kann der Verfahrensschritt nochmals neu ausgeführt werden oder zu Schritt 20 zur Erfassung des IST-Geräte-Zustandes verzweigen und die Schritte 20 und 30 iterativ auszuführen, falls ein Triggersignal (z.B. ein modifizierter Gerätezustand) erfasst werden konnte.
• Die Grundidee der Erfindung ist grundsätzlich unabhängig von der Art des Steuerprogramms. Dabei kann es sich um eingebettete Software (Firmware) handeln, die beispielsweise in einem Flash-Speicher, in einem (E)EPROM oder ROM gespeichert ist. Das Programm ist grundsätzlich als Steuerprogramm ausgelegt und dient zur Steuerung der elektronischen Komponente K. Es umfasst ausführbaren Code und kann darüber hinaus noch Daten, Datenstrukturen, Konfigurationsdateien und Metadaten umfassen.
• Durch die zentrale Erfassung und/oder Speicherung von zulässigen Programm(versions)kombinationen wird es vorteilhafterweise möglich, dieses Erfahrungswissen immer aktualisiert zu halten und auf allen angeschlossenen Geräten G auch lokal zur Verfügung zu stellen. Damit kann der Verwaltungsaufwand zur Prüfung auf Betriebsfähigkeit der Geräte G deutlich verringert werden. Ebenso entfällt der Kosten- und Zeitbedarf zur Ausführung von Software-Updates für bestimmte Komponenten K, falls nur andere Geräte-Komponenten K verändert worden sind, die keinerlei Einfluss auf die anderen Komponenten K haben. Das Erfassen von zulässigen Programmen bzw. Programmversionen kann über die gesamte Betriebslaufzeit des jeweiligen Gerätes G an zentraler Stelle für alle angeschlossenen Geräte G gesammelt werden. Vorteilhafterweise kann bei einer singulären Änderung an einer Komponente K (z. B. durch Einspielen einer funktionalen Erweiterung, eines sogenannten Fixes, eines neuen Patches, oder eines Releases) zielgerichtet analysiert werden, welche Auswirkungen dies für die anderen Komponenten K hat. Insbesondere ist es nicht mehr notwendig, das gesamte Software-Paket für alle Komponenten K neu einzuspielen. Somit kann vorteilhafterweise gezielt geprüft werden, welche Komponenten K eine neue Steuersoftware benötigen.
• Eine alternative Ausführungsform der Erfindung sieht vor, keinen zentralen Server S bereitzustellen. Das Prüfverfahren wird lokal auf den Geräten G ausgeführt. Der Zulässigkeitsspeicher MEM wird vorzugsweise auf allen Geräten G lokal gewartet und aktualisiert oder er wird in jeweils aktualisierter Form über eine Datenverbindung (z.B. Memory Stick oder Netzwerkverbindung) eingelesen, so dass sichergestellt ist, dass auf allen Geräten G stets der aktuelle SOLL-Zustand von zulässigen Versionskombinationen hinterlegt ist.
• In einer vorteilhaften Weiterbildung der Erfindung ist es bei einem negativen Prüfergebnis (also falls der Prüfschritt 30 ergeben hat, dass es sich um eine unzulässige Kombination von Steuerprogrammen handelt) vorgesehen, dass eine Fallback-Funktion auf dem Gerät G bereitgestellt wird. Die Fallback-Funktion dient dazu, einen vorherigen, zulässigen Geräte-Zustand wiederherzustellen. Dies erweist sich insbesondere dann als vorteilhaft, falls das Anästhesiegerät G im klinischen Einsatz für Notfallszenarien (z.B. Operationssaal) verwendet wird und der Betrieb des Gerätes G mit veralteten Steuerprogrammen favorisiert wird gegenüber einer Situation, in der zwar die neueste Version von Steuerprogrammen aufgespielt ist, aber in der zunächst eine zulässige Kombination ermittelt werden muss. Falls das Gerät G eine Benutzeroberfläche umfasst, kann es vorgesehen sein, mehrere Auswahleinträge zur Anwendung der Fallback-Strategie bereitzustellen, die der Benutzer dann über Eingabe eines Auswahlsignals auswählen kann. Insbesondere kann der Benutzer dann auswählen, auf welche zulässige Kombination von Programmversionen er zurückgreifen möchte.
• Gemäß einem weiteren Aspekt der Erfindung ist es vorgesehen, dass ein Log-file für jedes oder für ausgewählte Geräte G geführt wird, in dem lokal alle Prüfergebnisse gespeichert werden, insbesondere mit weiteren Meta-Daten, wie z.B. den Zeitpunkt der Prüfung, den Anwender, die Klinik, die Abteilung, etc. Dies hat den Vorteil, dass bei einer Gerätewartung mehr Informationen bereitgestellt werden können, auch über zurückliegende Gerätezustände. Damit kann insbesondere das Szenario modelliert und mit der Prüfung abgedeckt werden, dass Kliniken oder Klinikabteilungen ihre Geräte G austauschen. In diesem Fall würde diese Daten in den Metadaten abgebildet werden und die Versionsprüfung wird automatisch bei jedem neuen Einsatz des Gerätes (neue Abteilung) ausgeführt.
• Da das Beschreiben des Zulässigkeitsspeichers MEM eine sicherheitskritische Aufgabe ist, sind erhöhte Sicherheitsanforderungen für den Schreibzugriff auf den Zulässigkeitsspeicher MEM vorgesehen. So ist es insbesondere vorgesehen, dass der Zugriff nur in signierter Form nach erfolgreicher Authentisierung durchführbar ist. Des Weiteren dürfen nur autorisierte Benutzer einen Schreibzugriff auf den Zulässigkeitsspeicher MEM ausführen.
• Gemäß einer bevorzugten Ausführungsform wird das Prüfmodul P vor jeder Inbetriebnahme des Gerätes G und nach jedem Wartungsvorgang bzw. nach jeder Änderung an dem Gerät G 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

Zugriff auf Zulässigkeitsspeicher

20

Erfasse IST-Zustand des Gerätes

30

Prüfen auf zulässige Kombination von Programmversionen

40

Sperrfunktion aktivieren

50

Releasefunktion aktivieren

60

Ende oder Warten auf Triggersignal

G

Anästhesiegerät

K

Komponente des Anästhesiegerätes

MEM

Zulässigkeitsspeicher

P

Prüfmodul

RSF

Release- und Sperrfunktion

NW

Netzwerk

S

zentraler Server

A

Anschalten

B

Komponente geändert

C

Konfiguration geändert

D

Zulässigkeitsspeicher(inhalt) geändert

Claims (10)

1. Prüfsystem für ein medizinisches Gerät (G) oder für einen Verbund von medizinischen Geräten (G), umfassend mehrere separate Komponenten (K), wobei jeweils eine Komponente einen Mikroprozessor und zumindest ein ausführbares Programm umfasst, wobei die Programme in unterschiedlichen Versionen auf der jeweiligen Komponente (K) installiert sein können und wobei die Programme, die auf den Komponenten (K) installiert sind, unabhängig voneinander austauschbar und/oder änderbar sind, mit: - Einem Zulässigkeitsspeicher (MEM), der auf jedem oder ausgewählten medizinischen Gerät(en) ausgebildet ist oder für den ein Zugriffsmodul auf dem jeweiligen medizinischen Gerät (G) bereitgestellt wird, wobei in dem Zulässigkeitsspeicher (MEM) Einträge für alle zulässigen Kombinationen von Versionen der Programme der mehreren Komponenten abgelegt sind - Einer Release- und Sperrfunktion (RSF), die auf jedem medizinischen Gerät (G) bereitgestellt wird und die Inbetriebnahme des jeweiligen medizinischen Gerätes (G) oder einzelner Funktionen des Gerätes (G) steuert - Einem Prüfmodul (P), das auf jedem medizinischen Gerät (G) installiert ist oder für jedes medizinische Gerät (G) zugreifbar und dazu bestimmt ist, alle Versionen aller aktuell installierten Programme automatisch als IST-Gerätezustand zu erfassen und das weiter dazu bestimmt ist, auf den Zulässigkeitsspeicher (MEM) zuzugreifen und zu prüfen, ob der erfasste IST-Gerätezustand als zulässiger Zustand in dem Zulässigkeitsspeicher (MEM) als Eintrag existiert und nur bejahendenfalls die Releasefunktion für das medizinische Gerät (G) zu aktivieren.
2. Prüfsystem nach Anspruch 1, bei dem das Prüfmodul (P) mit der Sperrfunktion vorkonfiguriert ist und die Releasefunktion erst dann freigeschaltet wird, nachdem die Prüfung erfolgreich beendet werden konnte.
3. Prüfsystem nach einem der vorstehenden Ansprüche, bei dem der Zulässigkeitsspeicher (MEM) dynamisch aktualisiert wird durch Synchronisierung mit einem zentralen Server (S) und/oder durch Einspielen von aktualisierten Einträgen über eine Schnittstelle und/oder eine Netzwerkverbindung (NW).
4. Prüfsystem nach einem der vorstehenden Ansprüche, bei dem der Zulässigkeitsspeicher (MEM) getrennt ist von einem Speicher für die Programme eines medizinischen Gerätes (G).
5. Prüfsystem nach einem der vorstehenden Ansprüche, bei dem der Zulässigkeitsspeicher (MEM) ein gesicherter Speicher ist und bei dem Hinzufügungen, Änderungen und/oder Löschungen nur authentisiert ausführbar sind.
6. Prüfsystem nach einem der vorstehenden Ansprüche, bei dem das Prüfmodul (P) automatisch nach Erfassen eines Triggersignals aktiviert wird, insbesondere nach jeder Änderung an dem medizinischen Gerät (G), nach jeder Änderung an einer Komponente (K) des Gerätes (G), nach jeder Konfigurationsänderung, nach jeder Änderung am Zulässigkeitsspeicher (MEM) und/oder vor jeder Inbetriebnahme des medizinischen Gerätes (G).
7. Prüfsystem nach einem der vorstehenden Ansprüche, bei dem ein Zulässigkeitssignal erzeugt wird, falls die Prüfung des Prüfmoduls (P) ergibt, dass der erfasste IST-Gerätezustand als zulässiger Zustand in dem Zulässigkeitsspeicher (MEM) existiert und/oder dass ein Zulässigkeitssignal in signierter Form an andere Computer-basierte Instanzen weitergeleitet wird.
8. Medizinisches Gerät (G), umfassend mehrere austauschbare, separate Komponenten (K), wobei jeweils eine Komponente einen Mikroprozessor und zumindest ein ausführbares Programm umfasst, wobei die Programme in unterschiedlichen Versionen auf der jeweiligen Komponente (K) installiert sein können, wobei das medizinische Gerät (G) zur Verwendung in einem Prüfsystem nach einem der vorstehenden Patentansprüche bestimmt ist, mit: - Einer Release- und Sperrfunktion (RSF), die eine Inbetriebnahme des medizinischen Gerätes (G) oder einzelner Funktionen des Gerätes (G) steuert.
9. Verfahren zur Prüfung eines medizinischen Gerätes (G) oder eines Verbundes von medizinischen Geräten (G), umfassend mehrere austauschbare, separate Komponenten (K), wobei jeweils eine Komponente (K) einen Mikroprozessor und zumindest ein ausführbares Programm umfasst, wobei die Programme in unterschiedlichen Versionen auf der jeweiligen Komponente (K) installiert sein können, mit folgenden Verfahrensschritten: - Zugreifen (10) auf einen Zulässigkeitsspeicher (MEM), in dem Einträge für alle zulässigen Kombinationen von Versionen für die Komponentenprogramme abgelegt sind - Automatisches Erfassen aller Versionen aller aktuell installierten Programme auf allen Komponenten (K) des medizinischen Gerätes (G) als IST-Gerätezustand (20) - Prüfen (30), ob der erfasste IST-Gerätezustand zulässig ist durch Zugriff auf den Zulässigkeitsspeicher (MEM) und - Wechsel von einer vorkonfigurierten Sperrfunktion (40) des medizinischen Gerätes (G) auf eine Releasefunktion (50) zur Inbetriebnahme des medizinischen Gerätes (G) oder zur Freischaltung einer geprüften Gerätefunktion, falls der erfasste IST-Gerätezustand als zulässig geprüft wurde.
10. Computerprogrammprodukt, wobei das Computerprogrammprodukt ein Computerprogramm umfasst, das auf einem Datenträger oder auf einem Speicher eines Computers 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.