Version control for medical anesthesia devices

Abstract

A test system for a medical device (G) or for a group of medical devices (G), comprising a plurality of separate components (K), each component comprising a microprocessor and at least one executable program, wherein the programs can be installed in different versions on the respective component (K), and wherein the programs installed on the components (K) are independently interchangeable and / or modifiable, comprising: - an admissibility memory (MEM) formed on each or selected medical device(s) or for which an access module is provided on the respective medical device (G), wherein entries for all permissible combinations of versions of the programs of the plurality of components are stored in the admissibility memory (MEM); - a release and lock function (RSF);which is provided on each medical device (G) and controls the commissioning of the respective medical device (G) or individual functions of the device (G) - A test module (P) that is installed on each medical device (G) or accessible for each medical device (G) and is intended to automatically record all versions of all currently installed programs as the actual device state and that is further intended to access the admissibility memory (MEM) and check whether the recorded actual device state exists as an entry in the admissibility memory (MEM) and only if so, to activate the release function for the medical device (G).

Description

Field of the Invention:The present invention lies in the fields of medical technology and electronics or information. The invention relates in particular to a testing of medical devices, such as anesthesia devices, which comprise a plurality of components with programs, wherein the programs can be installed on the device in different versions.Medical devices, such as anesthesia devices, are nowadays generally controlled by software and comprise components with a specific information technology infrastructure, which are generally designed with a microprocessor and programs running thereon. A versioning of the software results in different software versions being able to be installed on the components of the device.It has proven to be problematic that not all combinations of program versions result in an operable device state. Certain combinations prove incompatible, defective and are therefore impermissible and have to be checked before the device is put into operation and / or before use.Prior Art:Due to legal regulations, it is necessary for the medical devices in use to be constantly monitored for compliance with safety regulations. This check is usually performed manually by a technician. In this case, it is also checked whether compatible software versions, for device control or for operation of the device, are always installed.In the field of automatic software updating, it is known to distribute current software versions controlled by a central location. DE 103 53 052 A1 describes an automation system having mutually communicating components and a central management system, wherein the software of the components is automatically updated provided that the current software is enabled for the respective component. U.S. Pat. No. 6,363,282 B1 describes a system and a method for providing an automatic software update for a programming device of an implantable medical device system, wherein the software for updating the programming device is provided by a remote expert data center and authorized software applications are transmitted to the programming device.It is known in the art that certain versions of the installed programs on the device may result in a malfunction or error. Therefore, one way to avoid impermissible combinations was to exchange the complete software package (i.e. thus the totality of all programs) during production and before startup, as well as each change to the device or to a device component. This procedure is time-consuming and cost-intensive on the one hand and error-prone on the other hand.Furthermore, it is known to carry out a check of the program versions installed (such as patches or other correction deliveries of the software) by a service technician on site. All new version deliveries must then be validated (generally by the device manufacturer). Only after the permissibility of the program could be checked could the device be delivered to the medical facility (e.g. hospital) or put into operation, which usually leads to considerable delay times.These approaches are time consuming and also prone to errors due to manual execution.Task:The present invention has therefore for its object to present a technical implementation with which the checking of programs, in particular the checking for permissibility of installed components of program versions, for operating a medical device can be accelerated, improved and executed without errors.DESCRIPTION OF THE INVENTIONThis object is achieved by the appended patent claims, in particular by a test system, a medical device, a computer-implemented method and by a computer program product.The invention is described below with reference to the method. Embodiments mentioned here, alternative solutions, further features and advantages are likewise also to be transferred to the other solutions of the aforementioned object (that is to say to the computer program product and to the test system and / or the device) and vice versa. Accordingly, the features claimed and / or described in connection with the system can also be applied to the method, the device or the computer program product and vice versa. In this case, the respective functional features of the method are implemented by corresponding microprocessor modules or hardware modules which are designed to assume the respective functionality.According to one aspect, the invention relates to a method for testing a medical device or a device group, comprising a plurality of replaceable, separate components, wherein in each case one component comprises a microprocessor and at least one executable program, wherein the programs can be installed on the respective component in different versions, having the following method steps:automatically acquiring all versions of all currently installed programs on all components of the medical device as an ACTUAL device stateaccessing an allowed memory in which all allowed combinations of versions for the programs of the device components are storedchecking whether the detected actual device state is permissible by accessing the permissibility memory and matching with the entries stored thereactivating a release function for enabling or starting up the medical device in total or individual device functions (if these can be activated separately), if the detected ACTUAL device state has been checked as being permissible (otherwise: activating or maintaining a blocking function, so that the device or the device function cannot be operated).The terminology used within the scope of this application is explained in more detail below.The method is computer-implemented and preferably runs fully automatically, i.e. without any user interaction of a user. The method may be partly or entirely software-based. In addition, it is possible to embed or integrate the method or system as an embedded system in the anesthesia device or the medical technology system and / or in a control computer (e.g. within the scope of a central server). The method serves for storing, processing and forwarding edited data (in the form of permissibility and validation signals and a release and blocking signal) using computer-based technical devices (network) to other entities. The input variables for calculation and / or processing (the components of the device) are addressed differently (version-specific) and are thus stored in a modified manner. The method thus also takes account of the circumstances of the data processing system by checking the components and their programs for the operation of the device.The method is generally computer-implemented. In this case, it may be that certain method sections are formed as part of a microprocessor solution and are thus hard-wired, while other sections of the method are formed as software. In this case, only individual sections or parts of the method would be software-implemented. As a rule, all or selected sections of the method are binary coded or they are present in digital form. All or individual sections of the method can be provided as source code (source code), as already completely compiled code (machine code) or as interpreted code (e.g. in the Python, PHP, Rugy) interpretive languages or can be interpreted by means of an interpreter (e.g. Jit compiler). For carrying out the method according to the invention and the products claimed further, it is immaterial in which programming language (e.g. C++, Java, Perl or PHP etc.) the software is present. It is essential that the software is directly incorporated into the technical device as part of a technical system and serves there for controlling version recordings. The parts of the method according to the invention, which are implemented as software, can be part of a so-called "embedded system", which is embedded in the surrounding medical technology system and interacts with it.The medical device is usually an anesthesia device comprising several processors with individual software or firmware, e.g. with a motherboard with two microprocessors, voltage supplies, etc. However, the invention is not limited to anesthesia devices, but can also be used for respirators, heat beds, surgical lights, etc. Typically, the boards (components) are configured with individual versions of firmware that entail different updates, patches, and / or changes. For example, if the firmware of a first component has been identified as faulty and therefore has to be replaced or changed, it may be quite possible that the other components do not have to be replaced with firmware as well and can be retained unchanged. This is carried out by the test or by the test module. The management effort for the device can thus advantageously be significantly reduced. Nevertheless, it can be ensured that a consistency check for the control programs is executed before each device startup. However, the invention can also be applied to other medical devices (e.g. laboratory devices, medical devices for diagnosis, devices for measuring physiological parameters of a patient), which likewise comprise components which are controlled and / or operated via at least one program. The programs are implemented on the individual components and can usually run fully automatically (without user interaction). Alternatively, the respective application comprises a user interface via which a user can operate, control and / or check the medical devices by means of the application.The components are electronic, computer-based components that are interchangeable independently of one another. The components are, for example, gas sensors, pressure sensors, physiological parameters, power supply unit, RFID antenna and / or tag analysis. The components are interconnected for data exchange by means of a network (or bus system, common resources, other interfaces and / or asynchronously by storage media). The components are operated with software or programs. These can be implemented as microprocessor programs in a non-volatile (non-volatile) electronic memory module (e.g. in an EPRROM or EEPROM and / or on mass storage devices, e.g. HHD or SSD drives) or provided as software application or applet. Each program is usually provided in multiple versions (e.g., through function changes or bug fixes) during the product life cycle. In addition to an original version, correction versions, patches or new, improved versions (releases) are created within the scope of a product development, which must then be installed on the respective components on the device. In the preferred embodiment of the invention, the components relate to individual components of an anesthesia device or of another medical device. Usually, a medical device comprises a plurality of separate components. It is essential that the components can also be provided with (new) software independently of one another. For example, there may be a download of software versions from a central server, which may be triggered selectively by the component or by the server. It is thus possible to exchange the components themselves (comprising device components) as well as to exchange the control software for the components. The replacement does not necessarily have to be carried out by the user, but can be carried out by a maintenance engineer during maintenance, so that a change or a change to the device does not have to be immediately visible to the device user and / or operator.The set of permissible combinations of programs is preferably stored in a database. In order to search for permissible combinations, a retrieval system according to the invention can be designed with a truncation function (e.g. by means of wildcards). The search for permissible version combinations can be carried out centrally (in the department, in the medical facility and / or else on a central server, for example in the case of Dragger Medical) or else locally by the respective device.Usually, a device component is controlled by a control program. Thus, a bijective (1:1) assignment between program and components is provided. Alternatively, other assignments are also possible, so that, on the one hand, different programs can also be installed on one device component, and that, on the other hand, a comprehensive control program for different device components is provided.The permissibility memory is a memory module, a memory card or a mobile data carrier (e.g. a USB stick). The memory is writable and / or programmable (e.g. flash (E) EPROM, EPROM, PROM etc.). The permissibility memory is preferably physically separate (to increase security) from a program memory. In an alternative embodiment of the invention, the permissibility memory is not physical but logically separate from the program memory. In an alternative, purely software-based variant of the invention, the permissibility memory can also be designed as a data structure or database (e.g. in the mass storage, e.g. HDD, EPROM, which can also contain the program code itself), which can be accessed by the device in order to carry out the version checking according to the invention. All permissible combinations of program versions of all device components are stored in the permissibility memory. The set of admissible program versions or software packages can also be referred to as "snapshot" and can usually be defined and / or dynamically adapted (changed) during production of the device and also during device operation. "Admissible" program combination therefore means a combination of program versions (of the activated components) which are functionally compatible and ensure error-free functional operation of the device. A set of permissible program version combinations is generated in preconfigurable tests. This set is dynamically adjustable (and can be reduced and expanded in particular). The tests are e.g. release tests. The tests can be carried out centrally, for example in a verification department at the device manufacturer. There, each combination (snapshot) is released by signature and then entered into a database for distribution to the devices. The tests can be automated. It is thus also possible to include external verification service providers and to feed their secured results into the database. The device manufacturer provides a master database for released combinations and ensures their adaptation or supplementation.A release function is provided (preferably as part of a release and barrier function). The release function is a setting of the device which can trigger the startup of the respective medical device or a separately activatable device function or prevent it (as a blocking function). The release function is dependent on the test result. In other words, the release function is activated when the version check has been successfully completed, otherwise the blocking function is activated, so that the respective device or the device function is not operational and a change of the component programs must first be executed. The release function thus serves for the direct control of the medical device. As a rule, it is provided that a blocking function is activated first, so that the device cannot be operated without a version check. Only after the version check could be successfully concluded can the release function be activated for starting up the device or enabling the device function. Depending on the embodiment, the release function (used synonymous with release and blocking function) has different extents. Thus, in a first variant, it can relate to the entire device and, in a second variant, it can relate only to individual device functions. In the second variant, individual device functions can then be enabled or disabled on the basis of the check. For example, in an anesthesia machine, another gas sensing component may be used (the replacement may also occur during operation, for example). The entire device then generally remains in operation, but individual device functions are no longer supported, for example the control to a specific gas concentration if the measured value has become too inaccurate. Checking and enabling or blocking is also possible after the entire device has been put into operation.The checking is preferably carried out fully automatically and comprises a comparison with entries from the permissibility memory. The check relates in particular to whether a combination of currently installed program versions is permissible. The check can be performed depending on the (geographical) location, since specific clearance procedures apply for some countries / regions, so that certain versions and their combinations must not operate at each location. In a further advantageous embodiment, the checking can be carried out as a function of the intended use ("intended use"). More complex refinements comprise further checking measures, such as a successful authorization, a check as to whether the respective program is also installed on the "matching" (after previous assignment) component, a check as to whether the version is also the most up-to-date in each case.According to a preferred embodiment of the invention, the permissibility memory may be updated dynamically. The updating of the permissibility memory can be carried out firstly before (the first) startup of the device and also later during (clinical or other) use of the medical device. The update can be carried out by synchronization with a central server and / or by incorporating updated entries (e.g. via a network connection, for example Internet). Alternatively, the medical device can also be connected to a service PC via a corresponding connection (wired or wireless). Further possible recordings relate to: storage media, data carriers and / or also components newly added to the device. Furthermore, it is also possible to place the medical device in data exchange with updated permissibility information via pluggable components (comprising memory cards or sticks, etc.). Likewise, the updated permissibility data can be stored directly on the pluggable components and can thus be read into the device. In addition, it is possible to place the replaceable components of the device and / or the sensors etc. themselves in data exchange with updated permissibility information, since their communication protocol must accordingly allow the updating. This can increase the flexibility of the version checking, since the incorporation of updated permissibility data is not limited to a specific form for the provision of the permissibility data.According to a further aspect of the invention, the checking can also be triggered by a central entity. This makes it possible to recall specific combinations, i.e. to withdraw releases again. This embodiment is used, among other things, when the central entity receives problem reports that signal that the implemented combination on the device is not permitted or cannot be verified.According to one aspect of the invention, operator data (i.e. data which are relevant for the operation and the functionality of the respective device) are stored separately from the permissibility data. In particular, the programs are stored in another memory (the program memory) or in another memory area which is separate from the permissibility memory and / or can be accessed separately from the permissibility memory. The term "separated" includes physical and logical separation of the respective memory (areas). This embodiment has the advantage that the version checking is difficult to corrode because of the separate storage. Another advantage is that the actual programs for clinical use (CE characters) can be released and the release need not be renewed by changes to the permissibility memory because the program is not changed. The security of the version checking and thus also the security of the medical device can thus be improved. Furthermore, it is thus possible to separate the device check (in particular version check) from the actual device operation.In order to be able to further increase the security of the version checking, it is provided in an advantageous development of the invention that the permissibility memory is secured. In particular, changes (comprising new entries, changes to existing entries, and deletions of entries) can only be carried out after a successful authentication (e.g. by a digital signature of the change data or by an encrypted transmission, the successful decryption of which authenticates the sender as trusted). In order to be able to further increase security, it can be provided that the entries in the permissibility memory are stored in encrypted form and are therefore also not readable by an authenticated user without decryption. For this purpose, for example, a symmetric or asymmetric encryption method (e.g. based on the RSA algorithm) can be applied.The version checking is preferably carried out in the checking module. The test module can be installed or implemented as a software tool on the device. Alternatively, it is also possible to provide the test module on a central computer-based entity and connect it to the respective devices. It is likewise possible to provide the test module only on selected devices, via which other devices (connected via a corresponding data connection) can then be indirectly tested. This has the advantage that not all medical devices have to be formed with a test module. This proves to be particularly expedient if a group of medical devices usually has to be combined. Depending on the embodiment, different scenarios for activating the test module may be implemented. It is usually provided that the test module is activated automatically before each startup of the medical device. Alternatively or cumulatively, the test module can also be activated automatically after detecting a change at the medical device and / or at preconfigurable time intervals and / or events. It is likewise possible that after a detected change at the medical device, the blocking function of the test module is preconfigured or activated. This advantageously ensures that a check of the program versions for permissibility is always and automatically carried out if a change to the device has been detected. If, for example, a device component was replaced or a new version of the control software was installed, the device can only be put into operation if the version check could be carried out successfully.According to one aspect of the invention, it is provided that an approval signal is output in the event of a successful version check. This can be displayed, for example, on a user interface of the medical device (if present) and / or it can be transmitted to a central server. The permissibility signal can also be implemented as a value (flag) or change of a memory cell. No physically independent design is required. If the check fails, an error signal can be output. Alternatively, the error signal may be transmitted to a control computer (e.g., central server) to initiate further steps. For example, the reinstallation of program versions can be triggered here or a service technician can be informed via an Internet connection.A further solution to the problem consists in a medical device on which the release and blocking function described above for version checking is implemented.The release and blocking function runs fully automatically (without user interaction) and is triggered in particular before the device is put into operation and in the event of changes (to components) in the device. In a further advantageous embodiment of the invention, the device comprises, in addition to the release and blocking function, the test module and / or the permissibility memory (however, this is not absolutely necessary and is only optional). In other words, the test module may also be installed on the device or on another computer-based entity that is in data communication with the device. This reduces the installation effort for the devices and increases the flexibility in implementing the test method according to the invention. More complex refinements of the device additionally comprise further modules (for example, as already described above in connection with the method: an authorization checking module, an assignment checking module, etc.).A further solution to the above object is a medical device testing system according to the appended claim. According to one aspect of the invention, the checking system comprises an permissibility memory in which permissible combinations of versions for the control programs of the components are stored, a release and blocking function and a checking module. It should be expressly pointed out that the scope of protection of this application is not restricted to all of the aforementioned modules or modules of the system (test module, permissibility memory, release and blocking function) having to be formed on the same entity (device and / or central server or further entities). In a preferred embodiment, the permissibility memory, the release and blocking function and the test module are formed on the respective device. Alternatively, it is also possible to form only the release and blocking function on the device and to provide the permissibility memory and the test module on connectable computer-based entities.With the test system or test module according to the invention, safety gaps can be closed, which arise due to inconsistent control versions for the device components and would compromise the device functionality overall.The test module is preferably embedded in the technical device or in the medical device. The test module is used for processing, storing and / or transmitting test data with respect to the medical device. The release and blocking function controls the activation and / or the startup of the medical device and thus relates to the direct interaction of the devices or connected computer-based entities. In this case, it can be ensured that a medical device is operated only if a version check could be successfully concluded. Both the device as a whole and the device components are thus operated in a modified manner. Up to now, the activation of the device (possibly after known authorization measures) led directly to the start-up of the device. The connection or integration of the device into the medical system (e.g. surgical system) leads to the automatic triggering of the test function or the test module. Device components are thus addressed differently. The data processing program used for version checking is in data exchange (in particular via the identifier of the versions of the components, and the release and blocking signal) with all device and / or hardware components of the medical device.According to one aspect, the check of the installed versions for permissibility can also be carried out within the framework of the automatic self-test of the device.In order to further increase security, it can be provided that the version checking is carried out automatically after configurable time intervals and / or after configurable events (in particular in the case of a detected device change or a change to other components of the more comprehensive system). The events mentioned above comprise, in a preferred embodiment:a switch-on of the devicereceiving a central instance test commanda change to a componenta change in the available componentsA change to the content of the permissibility memory.The version checking is fundamentally applied or implemented to two hierarchy levels. The version check is performed.for a device having a series of (identical or different) components, andon a system or device group in which each device plays the role of a component.If necessary, it is possible to display the detected actual state on a user interface (on the device to be checked, on a specific monitor device and / or on a central server). In this case, an assignment between the components and the program versions installed thereon can also be presented in order, for example, to display relevant maintenance data to a maintenance engineer.The allowed combinations of versions for the device component programs (snapshot) may be device specific, so that the set may differ from device to device. Alternatively, the snapshot can also be dependent on the respective operation of the device, i.e. thus application-specific.The checking module is intended to automatically detect all versions of all currently installed programs as an ACTUAL device state. This actual device state can then be compared (if necessary, in particular after detecting a change) with a target state as a set of permissible states. In this case, the set of all permissible states is stored in the permissibility memory. As soon as a new program version is installed for only one or more device components, the ACTUAL state changes and is automatically updated in order to be able to trigger the version check. It is taken into account here that a local change (e.g. expansion) on a component generally only has effects on very few further components, so that the insertion of a complete software package (for all components) is not necessary in order to be able to ensure the error-free operation of the device. Advantageously, the management effort for the operation checking of the device on the one hand and also on the other hand the effort associated with the provision of the update versions can thus be significantly minimized.The above-described embodiments of the method according to the invention can also be embodied as a computer program product with a computer program, wherein the computer is caused to carry out the above-described method according to the invention when the computer program is loaded or executed on the computer or on a processor of the computer.An alternative solution to the problem also consists in a computer program with computer program code for carrying out all method steps of the method claimed or described above when the computer program is executed on the computer. The computer program can also be stored on a machine-readable storage medium or downloaded from a computer instance via an interface.An alternative object solution provides a storage medium intended for storing the above-described computer-implemented method and readable by a computer.It is within the scope of the invention that not all steps of the method necessarily have to be executed on one and the same computer instance, but they can also be executed on different computer instances. The sequence of the method steps can also be varied if appropriate.Moreover, it is possible that individual sections of the above-described method can be executed in one saleable unit and the remaining components in another saleable unit-so to speak as a distributed system.Brief Description of the Figures:In the following detailed description of the figures, exemplary embodiments, which are to be understood as non-limiting, with the features thereof and further advantages thereof, are discussed with reference to the drawing. In these show: FIG. 1 shows an overview of a medical device according to a preferred embodiment of the invention, FIG. 2 shows a schematic illustration of a system comprising a plurality of medical devices according to one embodiment of the invention, and FIG. 3 is a data flow diagram of a version checking method according to a preferred embodiment of the invention.Detailed description of the Figures:FIG. 1 shows in schematic form the structure of an extended medical device, in particular an anesthesia device, which is identified in the figures with the reference symbol G. The anesthesia device G comprises several components and / or electronic components K that are controlled and / or operated via a computer program, such as, for example, those for measuring flow and pressure, for measuring the gas concentration of various gases (partially designed multiple times), for RFID reading and evaluation, for measuring physiological data of the patient, and / or a power supply unit. The technical teaching can furthermore be applied, for example, to the following components K: a flowmeter (rotameter) for determining the flow rate of gases, an ORC system (oxygen ratio controller) or further developments, such as a sensitive ORC and, depending on the orientation of the device G, also an electronically operating measurement sensor (flow sensor) for determining the respective gas components or for measuring the breathing stroke and breathing minute volume. Further applications relate, for example, to an electronic volumeter, an electronic manometer and further electronic components which are in data exchange via a bus system.In addition to the above-mentioned component parts, the device G also comprises further motherboards K, and further components K, which are generally supplied with individual firmware versions. The individual programs are subject to different update cycles. For example, if an error (bug) can be fixed to the PGM firmware, it is not necessary according to the invention to change the entire software for operating the device G or to change programs of other components if they are not affected by the error change (bugfix) of the PGM firmware.Moreover, the anesthesia device G comprises an permissibility memory MEM, a release and blocking function RSF and a test module P. The above-described exemplary embodiments of the anesthesia device G are to be understood, however, only as examples and can in alternative embodiments be combined and / or also comprise further components (also non-electronic) and components K.FIG. 2 shows an overview illustration (likewise schematically) of a plurality of devices and their incorporation into an overall system. Thus, a first device G 1, a second device G 2, a third device G 3 etc. are connected to a central server S via a network NW. The medical devices (in particular anaesthesia devices) G are extended to include the release and blocking function RSF, which, in the case of an unsuccessful version check, block the device and switch it inoperative, and which, in the case of a successful version check, release the respective device G for the start-up. The check for consistency of the program versions can be carried out within the device G, but also externally. In the latter case, the result of the test is passed on to the device G in order to be able to actuate the release and blocking function RSF accordingly.In the following, with reference to FIG. 3, the sequence of a test method according to the invention according to a preferred embodiment is described in more detail.The method is automatically started by preconfigurable trigger signals. If one of the trigger signals is detected on the device G and / or on the central server S, the check is started (automatically). According to a preferred embodiment, the following trigger signals are provided: A: switching on device G or switching on or activating a component K of device G B: at least one component K has been changed C: at least one configuration has been changed D: the content of an permissibility memory MEM has been changed.In alternative embodiments, further trigger signals can be defined here, which can relate, for example, to an event of the device group (power failure etc.)After the method has been started, an access to an permissibility memory MEM takes place in step 10. The permissibility memory MEM comprises entries for all the permissible combinations of versions for the component programs (i.e. for the control software of the components K of the device G involved). As already described above with reference to FIG. 1, the permissibility memory MEM is formed on the device G.In step 20, an ACTUAL device state is automatically detected. The IST device state can also be referred to as snapshot and includes all consistent program versions. This set comprises in particular all relevant components K of the device G (i.e. activated and required for operation / current use) and their control programs for the components K. All combinations of versions of component programs for which no error-free device function can be detected are not written to the permissibility memory MEM. According to the preferred embodiment of the invention, the admissible versions are thus stored in the permissibility memory MEM. Alternatively, the memory can also be written to with the logical opposite and then only comprises incompatible or inconsistent versions which would lead to a device fault (in the case of the test, the comparison between the ACTUAL state and the entries stored in the memory MEM then leads to the triggering of the blocking function if they match). In a preferred development, the combinations of programs for which errors have been detected are stored in an error memory. If such an (impermissible) version or combination has been detected upon detection of the ACTUAL device state, an alarm signal is automatically output.In the next method step 30, the actual version check takes place. Here, the detected device state, the ACTUAL device state, is compared with a set of permissible states. The set of permissible states is stored in the permission memory MEM. The test result basically has two outputs: 1. if the test runs successfully and it can be ensured that a permissible version of control programs is installed on the respective device G, the release function is activated in step 50 and the device G is put into operation or enabled for startup. 2. if the version test did not result in a successful test result, a blocking function 40 is activated. Preferably, the blocking function 40 is already preconfigured in the preferred embodiment, so that no further switching or no change is necessary here. In this case, the device remains locked and is inoperative. The method can then end or it is carried out iteratively for a new ACTUAL device state (this is to be identified in FIG. 3 by the reference numeral 60, which represents a state which is to be described with "wait for trigger signal"). As soon as a change has been detected at the device G, the method step can be executed again or branch to step 20 for detecting the actual device state and execute steps 20 and 30 iteratively if a trigger signal (e.g. a modified device state) could be detected.The basic idea of the invention is fundamentally independent of the type of control program. This may be embedded software (firmware) which is stored, for example, in a flash memory, in an (E)EPROM or ROM. The program is basically designed as a control program and is used for controlling the electronic component K. It comprises executable code and can also comprise data, data structures, configuration files and metadata.Through the central acquisition and / or storage of permissible program (version) combinations, it is advantageously possible to keep this experience always updated and also to make it locally available on all connected devices G. This allows the management effort for checking the operability of the devices G to be significantly reduced. Likewise, the cost and time required for executing software updates for specific components K are dispensed with if only other device components K have been changed which do not have any influence on the other components K. The acquisition of permissible programs or program versions can be collected at a central point for all connected devices G over the entire operating transit time of the respective device G. Advantageously, in the case of a singular change at a component K (e.g. by incorporating a functional extension, a so-called fix, a new patch, or a release), it is possible to analyze in a targeted manner which effect this has for the other components K. In particular, it is no longer necessary to re-enter the entire software package for all components K. It is thus advantageously possible to specifically check which components K require new control software.An alternative embodiment of the invention provides for no central server S to be provided. The test method is carried out locally on the devices G. The permissibility memory MEM is preferably maintained and updated locally on all devices G or it is read in in updated form via a data connection (e.g. memory stick or network connection), so that it is ensured that the current TARGET state of permissible version combinations is always stored on all devices G.In an advantageous development of the invention, a negative test result (i.e. if the test step 30 has shown that this is an impermissible combination of control programs) provides for a fallback function to be provided on the device G. The fallback function serves to restore a previous, permissible device state. This proves to be advantageous in particular if the anesthesia device G is used in clinical use for emergency scenarios (e.g. operating room) and the operation of the device G with old control programs is favored over a situation in which the latest version of control programs has been installed, but in which an admissible combination must first be determined. If the device G comprises a user interface, it can be provided to provide a plurality of selection entries for applying the fallback strategy, which the user can then select via input of a selection signal. In particular, the user can then select which permissible combination of program versions he would like to resort to.According to a further aspect of the invention, it is provided that a log file is maintained for each or for selected devices G, in which all test results are stored locally, in particular with further meta-data, such as the time of the test, the user, the clinic, the department, etc. This has the advantage that more information can be provided during device maintenance, even about past device states. In this way, in particular, the scenario can be modeled and covered with the check that clinics or clinic departments exchange their devices G. In this case, this data would be mapped into the metadata and the version check is automatically performed each time the device (new department) is used anew.Since the writing of the permissibility memory MEM is a safety-critical task, increased safety requirements are provided for the write access to the permissibility memory MEM. Thus, it is provided in particular that the access can be carried out only in signed form after successful authentication. Furthermore, only authorized users may execute a write access to the permissibility memory MEM.According to a preferred embodiment, the test module P is activated before each startup of the device G and after each maintenance operation or after each change to the device G.Finally, it should be pointed out that the description of the invention and the exemplary embodiments should in principle not be understood as restrictive with regard to a specific physical realization of the invention. It is in particular obvious to a person skilled in the art that the invention can be implemented partly or completely in soft and / or hardware and / or distributed over several physical products-in particular also computer program products.List of reference numbers:10 Access to permissibility memory 20 Capture ACTUAL state of device 30 Checking for permissible combination of program versions 40 Blocking function activate 50 Release function activate 60 End or wait for trigger signal G Anesthesia device K Component of anesthesia device MEM permissibility memory P Checking module RSF Release and blocking function NW Network S Central server A Switch-on B Component changed C Configuration changed D Permissibility memory (content) changed

Claims

Test system for a medical device (G) or for a group of medical devices (G) comprising a plurality of separate components (K), wherein in each case one component comprises a microprocessor and at least one executable program, wherein the programs can be installed in different versions on the respective component (K) and wherein the programs installed on the components (K) are interchangeable and / or changeable independently of one another, having: - an permissibility memory (MEM) which is formed on each or selected medical device(s) or for which an access module is provided on the respective medical device (G), wherein entries for all permissible combinations of versions of the programs of the plurality of components are stored in the permissibility memory (MEM) - a release and blocking function (RSF), A checking module (P) which is installed on each medical device (G) or is accessible to each medical device (G) and is intended to automatically detect all versions of all the currently installed programs as an ACTUAL device state and which is furthermore intended to access the permissibility memory (MEM) and to check whether the detected ACTUAL device state exists as an admissible state in the permissibility memory (MEM) as an entry and to activate the release function for the medical device (G) only if it is affirmative.Test system according to Claim 1, in which the test module (P) is preconfigured with the blocking function and the release function is enabled only after the test could be successfully ended.Test system according to one of the preceding claims, in which the permissibility memory (MEM) is updated dynamically by synchronization with a central server (S) and / or by entering updated entries via an interface and / or a network connection (NW).Test system according to one of the preceding claims, in which the permissibility memory (MEM) is separate from a memory for the programs of a medical device (G).Test system according to one of the preceding claims, in which the permissibility memory (MEM) is a secured memory and in which additions, changes and / or deletions can only be executed in an authenticated manner.Test system according to one of the preceding claims, in which the test module (P) is activated automatically after a trigger signal is detected, in particular after each change to the medical device (G), after each change to a component (K) of the device (G), after each configuration change, after each change to the permissibility memory (MEM) and / or before each startup of the medical device (G).Test system according to one of the preceding claims, in which an permissibility signal is generated if the test of the test module (P) reveals that the detected ACTUAL device state exists as an permissibility state in the permissibility memory (MEM) and / or that an permissibility signal is forwarded in signed form to other computer-based entities.Medical device (G) comprising a plurality of replaceable, separate components (K), wherein one component each comprises a microprocessor and at least one executable program, wherein the programs can be installed on the respective component (K) in different versions, wherein the medical device (G) is intended for use in a test system according to one of the preceding claims, having: - a release and locking function (RSF) which controls a startup of the medical device (G) or individual functions of the device (G).Method for testing a medical device (G) or a group of medical devices (G) comprising a plurality of replaceable, separate components (K), wherein in each case one component (K) comprises a microprocessor and at least one executable program, wherein the programs can be installed in different versions on the respective component (K), having the following method steps: - accessing (10) an permissibility memory (MEM) in which entries for all permissible combinations of versions for the component programs are stored - automatically capturing all versions of all currently installed programs on all components (K) of the medical device (G) as an ACTUAL device state (20) - testing (30), whether the detected ACTUAL device state is permitted by accessing the permission memory (MEM) and changing from a preconfigured blocking function (40) of the medical device (G) to a release function (50) for starting up the medical device (G) or for enabling a tested device function if the detected ACTUAL device state has been tested as permitted.A computer program product, the computer program product comprising a computer program stored on a data carrier or on a memory of a computer or which can be loaded via a network connection (NW) and which comprises computer readable instructions intended to perform the method according to the preceding method claim when the instructions are executed on the computer.

Images