Medical device with condition-dependent dynamic control of light-emitting diodes

DE202025100022U1Active Publication Date: 2025-03-27SIEMENS HEALTHINEERS AG
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
DE202025100022
Authority / Receiving Office
DE · DE
Patent Type
Utility models
Current Assignee / Owner
Priority Date
2024-02-19
Filing Date
2025-01-03
Publication Date
2025-03-27
Estimated Expiration
2035-01-31

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

Medical device (1) comprising a number of light strips (3) each with a plurality of individually controllable light-emitting diodes (4) and a control unit (7) for controlling the light strips (3), wherein the control unit (7) dynamically determines a respective light state (Z*) by taking into account a state (ST) of the medical device (1) and / or by taking into account a state (ST) from the environment of the medical device (1), which comprises a partial state (z*) for each of the light-emitting diodes (4) according to which the respective light-emitting diode (4) is to be operated, and transmits the respective light state (Z*) to the light strips (3).
Need to check novelty before this filing date? Find Prior Art

Description

[0001] The present invention is based on a medical device, - wherein the medical device has a number of luminous strips, - wherein the light strips each have a plurality of individually controllable light-emitting diodes, - wherein the medical device has a control device for controlling the light strips.

[0002] Medical devices are well known.

[0003] In such medical devices, the light strips are usually controlled statically. A purely time-controlled control of the light strips is also conceivable. Regardless of the method of control, however, the control of the light strips does not provide any relevant information to the operator.

[0004] The object of the present invention is to create possibilities by means of which the light strips can be used to transmit information to an operator.

[0005] The object is achieved by a medical device having the features of claim 1. Advantageous embodiments of the medical device are the subject of dependent claims 2 to 6.

[0006] According to the invention, a medical device of the type mentioned at the outset is designed in that the control device, by utilizing a state of the medical device and / or by utilizing a state from the environment of the medical device, dynamically determines a respective lighting state, which for the light-emitting diodes each comprises a partial state according to which the respective light-emitting diode is to be operated, and transmits the respective lighting state to the light strips.

[0007] The partial state of an individual LED does not correspond to the control of the respective LED (i.e., its input), but rather to the light signal emitted by the respective LED (i.e., its output). Accordingly, the respective lighting state corresponds to the totality of the partial states of the LEDs.

[0008] A medical device state, for example, can be the extent to which the medical device has completed a startup during commissioning. Another state can be the detection of a malfunction or the detection of a component failure of the medical device. Such a malfunction can be detected directly through corresponding signals or indirectly through a frequency analysis of acoustic signals.

[0009] Another state of the medical device may, for example, be that the medical device is currently operating (as opposed to standby mode, where the medical device is ready for use but is not being used for therapy or to collect data for diagnosis or the like). Another possible state may, for example, be the extent to which a particular examination has progressed. For example, the control may be dependent on the couch position when a patient is pushed through an examination tunnel of the medical device.

[0010] A condition in the medical device's environment could, for example, be an acoustic signal. For example, it can be detected whether a patient, who is completely or partially within the medical device's examination area, is speaking or shouting. For example, the light strips can indicate a volume level. Another possible condition in the medical device's environment is patient movement. The latter can be particularly relevant if the patient cannot move in order to capture proper signals for a diagnosis.

[0011] Another possibility is to arrange the light strips within the patient's field of vision and control them based on instructions from the medical device operator. The operator's instructions can be, for example, inputs via a keyboard or mouse, or voice inputs. In the latter case, the permissible voice inputs are preferably limited to a few key phrases (e.g., "inhale," "hold breath," "continue breathing," and the like).

[0012] The type of control of the light strips can be determined as needed. Examples of possible controls include flashing, continuous patterns, color changes, light intensity, etc. Routines are typically stored on the control unit. The respective routine contains code that can be processed directly by the control unit and defines a sequence of lighting states determined by the respective routine that the LEDs of the respective light strip should assume. In this case, the control unit can determine which of the routines to execute based on the state of the medical device and / or the state of the medical device's environment.

[0013] In the current state of the art, routines are self-contained. This means that they are machine code that is executed when the respective routine is called, exactly as it is. The routine is therefore not further modified, parameterized, or otherwise altered or adapted. A comparison with conventional programming: You have a do loop from 1 to 100 with a step size of 1. In this case, the do loop is executed 100 times.

[0014] The creation of such routines and the associated determination of the lighting states of the individual LEDs of the light strip by a programmer or a similar person requires very detailed knowledge of the specific control unit used and also of the specific LEDs used and also requires a great deal of effort.

[0015] Preferably, therefore, a program file is stored on the control unit—in addition to the routines. In this case, the program file contains a sequence of instructions that can be processed by the control unit through interpretation using an interpreter stored on the control unit. The instructions specify at least which of the routines are to be processed. In this case, the control unit can determine, based on the state of the medical device and / or the state of the medical device's environment, at which of the instructions in the program file the control unit begins interpreting the instructions.

[0016] This results in considerably greater flexibility.

[0017] Firstly, by simply modifying the program file, it is possible to subsequently change which routine is executed in a particular state. This allows the user to change the mapping between the possible states and the corresponding executed routines.

[0018] Furthermore—this is common practice when interpreting instructions in a program—the interpreter moves on to the next instruction after executing each instruction (except if the instruction is a stop instruction). The instructions in the program file are thus processed step by step and sequentially by the interpreter.

[0019] This allows a single state to call a sequence of routines defined by the program file. For example, five instructions (the number 5 is purely exemplary) can be executed consecutively, each calling a different routine, and these five instructions can be followed by a stop instruction. Furthermore, loops, conditions, and more can be implemented, particularly through conditional instructions (if ... then ... else ...) and jump instructions (goto ...).

[0020] The program file can be written in a high-level language, i.e., in a code format that is (somewhat) understandable to humans. Here again, a comparison with conventional programming: For example, a programming language similar to BASIC can be used.

[0021] As already mentioned, in the prior art, the routines are self-contained. This approach is also possible within the scope of the present invention. In this case, the corresponding state in the present invention does not directly specify the routine to be executed. Instead, it specifies the section of the program file instructions at which the control unit begins interpreting the instructions. The routines can, however, be retained unchanged compared to the prior art. However, it is possible to specify which routine is executed in which state. The sequence in which the routines are executed, for example, can also be specified.

[0022] On the other hand, it is possible that the routines are designed as routines that can be parameterized with parameters and that the instructions in the program file include specifications for the parameters of the routines, so that the routines, when executed, are executed in accordance with the specifications for the parameters of the routines given by the instructions in the program file.

[0023] In this case, an option is created to subsequently parameterize the routines. The respective lighting state is generated by the control unit by executing the correspondingly parameterized routine. This means that it is also possible to specify how a specific routine is executed. For example, in the "Flashing" routine, the intensity, frequency and / or duty cycle of the flashing can be specified, or the number of flashes can be specified. In the "Run Through" routine, for example, the size of the illuminated area of ​​a light strip and the speed at which the area should move along the light strip can be specified. Other parameterizations are also possible.

[0024] The procedure is analogous to the procedure generally known in conventional programming for subroutines.

[0025] Here again, a comparison with conventional programming: A "rigid" routine of the state of the art might, for example, contain a loop in which a specific arithmetic rule is to be executed for each of the numbers 1 to 100. The corresponding loop would therefore be "do n=1, 100, 1 ..... enddo." In this instruction, the leading 1 represents the initial value of index n with which the loop is to be executed for the first time, the middle 100 represents the final value of index n with which the loop is to be executed for the last time, and the trailing 1 represents the increment by which index n is to be incremented after each iteration of the loop. The dots (".....") indicate the arithmetic rule to be executed.

[0026] In the context of "conventional" programming, it is common practice to implement the above-mentioned and explained instruction "do n=1, 100, 1 ..... enddo" in parameterized form, i.e., in the form "do n = initial value, final value, increment ..... enddo." In this case, the initial value, final value, and increment parameters can be specified at a later time, i.e., not at the time the program itself is created. In particular, they can even be specified at runtime. Values ​​used within the loop can also be specified as parameters.

[0027] The first instruction, when applied to the control unit, would correspond to a state-of-the-art routine. The last instruction, when applied to the control unit, would correspond to a parameterizable routine.

[0028] Using such parameters, the respective routine can be specified, for example, how strongly certain LEDs should be controlled, with which duty cycle the LEDs should be controlled, with which clock rate the LEDs should be controlled and much more.

[0029] The parameterizations mentioned are possible in addition to specifying which of the routines should be processed.

[0030] According to the invention, the control device is designed, in particular programmed, in such a way that it operates the medical device according to an operating method.

[0031] The above-described properties, features, and advantages of this invention, as well as the manner in which they are achieved, will become clearer and more readily understood in connection with the following description of the embodiments, which are explained in more detail in conjunction with the drawings. Herein, in schematic representation: Fig. 1 a medical device, Fig. 2 a block diagram of a light strip and a control unit, Fig. 3 a flow chart, Fig. 4 a storage device, Fig. 5 a flow chart, Fig. 6 a sequence of instructions, Fig. 7 a routine, Fig. 8 a sequence of instructions and Fig. 9 a group of light-emitting diodes.

[0032] Fig. 1 schematically shows a medical device 1. The medical device 1 has a tunnel 2 through which a patient (not shown) can be pushed while lying on a patient couch. The tunnel 2 is typically present when the medical device 1 is a CT system or an MRI system. In other embodiments of the medical device 1, the tunnel 2 need not be present.

[0033] The device 1 has (at least) one light strip 3. According to Fig. 1, there are even several such light strips 3. The light strips 3 can be straight or - as in Fig. 1 - be bent or curved. Their length and width can be determined as required. The basic circuit design of a light strip 3 is described below in connection with Fig. 2 explained.

[0034] According to Fig. 2, the light strip 3 comprises a plurality of LEDs 4 and a controller 5 for the LEDs 4. The LEDs 4 can be individually controlled by the controller 5. The LEDs 4 can, as far as the data communication between the controller 5 and the LEDs 4 is concerned, be configured as shown in Fig. 2 can be controlled directly by controller 5. Alternatively, a serial arrangement is possible. Combinations of these approaches are also possible.

[0035] The controller 5 has an interface 6. Via the interface 6, the controller 5 dynamically receives a requested lighting state Z* from a control unit 7 of the medical device 1. The control unit 7 thus specifies the requested lighting state Z* to the controller 5 and thereby controls (albeit only indirectly) the LEDs 4. The respective requested lighting state Z* comprises, as in Fig. 2 is indicated by a summation symbol, for each of the LEDs 4 of the respective light strip 3, a partial lighting state z* is defined. The interface 6 is typically a serial interface. The respective partial lighting state z* corresponds to the state that the respective LED 4 should assume, i.e., the luminous flux (= output) that the respective LED 4 should emit. The respective partial lighting state z* is the result of a respective control c* (= input) of the respective LED 4.

[0036] If necessary, the controller 5 can have a further interface 8, to which the interface 6 of the controller 5 of a further light strip 3 can be connected. The further light strip 3 and its components are in Fig. 2 not shown.

[0037] The controller 5 can be embodied as a microcontroller that executes a program. Regardless of the specific design of the controller 5, however, the controller 5 always dynamically receives the respective requested lighting state Z* via the interface 6, determines the respective control c* for the LEDs 4 of the respective light strip 3 using the respective partial lighting state z*, and controls the LEDs 4 of the respective light strip 3 according to the respectively determined control c*. The control c* is determined in such a way that an actual lighting state z of the respective LED 4 corresponds to the partial lighting state z* of the respective LED 4.

[0038] The light strip 3 is further connected to a power supply unit, via which the LEDs 4 and the controller 5, and thus the light strip 3 as a whole, are supplied with electrical energy. The power supply unit is in Fig. 2 not shown.

[0039] The control unit 7 is also a component of the medical device 1. According to the above explanations, it serves to control the light strips 3. The control unit 7 is designed such that it operates the medical device 1 according to an operating method which is described below in connection with Fig. 3. The control unit 7 can, in particular, as shown in Fig. 2 is indicated by the designation "µP" within the control unit 7, be microprocessor-controlled and execute a control program 9 with which the control unit 7 is programmed. In this case, the control program 9 comprises machine code 10 that can be processed by the control unit 7. Furthermore, in this case, the control unit 7 is designed by programming with the control program 9.

[0040] According to Fig. 3, the control unit 7 accepts a state ST in a step S1. The state ST is determined by means of a sensor 11 (see Fig. 1) recorded.

[0041] Sensor 11 can, for example, be an acoustic sensor. In this case, an acoustic signal is detected. The acoustic signal can be a sound uttered by the patient or a word spoken by an operator. In these cases, a state ST from the environment of medical device 1 is detected. Using sensor 11, an operating noise generated by medical device 1 during operation can also be detected as an acoustic signal. In this case, too, a state ST from the environment of medical device 1 is detected.

[0042] Furthermore, the sensor 11 can be, for example, a motion detector or the like, by means of which a motion signal is detected. This can be used, for example, to detect whether a patient being treated using the medical device 1 is moving. The term "treat" in this context also encompasses pure data acquisition prior to a diagnosis, for example, the acquisition of X-ray images or MRI signals. "Critical" areas can also be monitored to determine whether a person is moving into such a critical area. In this case, too, a state ST from the environment of the medical device 1 is detected as a result.

[0043] Alternatively, the sensor 11 can be, for example, a displacement sensor, by means of which the position of a patient bed (not shown) is detected, which is conveyed manually or by motor through the tunnel 2 of the medical device 1. Likewise, the sensor 11 can detect an electrical or magnetic signal, for example a voltage, a current, or a magnetic field. The actuation of an actuator can also be detected. It is even possible for the sensor 11 to be designed as a data interface that receives a status message from a control unit of the medical device 1. In these cases, a state ST of the medical device 1 is detected.

[0044] In a step S2, the control unit 7 dynamically determines a lighting state Z*. The determination in step S2 is performed using the state ST detected in step S1. The lighting state Z* includes a partial state z* for each of the LEDs 4, which in turn indicates which output signal should be delivered by the respective LED 4.

[0045] In a step S3, the control unit 7 transmits the lighting state Z* to the light strips 3. In the case of several light strips 3, the control unit 7 transmits - at least in some cases - to the light strips 3 only the part of the lighting state Z* that concerns them.

[0046] Control unit 7 repeatedly processes steps S1 to S3. Control unit 3 thus repeatedly detects a state ST, repeatedly determines a lighting state Z* based on the respectively detected state ST, and transmits the respectively determined lighting state Z* to light strips 3. The lighting states Z* can thus change dynamically. Furthermore, the transmission of the lighting states Z* to light strips 3 occurs sequentially one after the other.

[0047] The control unit 7 further comprises a memory device 12. The memory device is in Fig. 4 is shown again separately.

[0048] In the storage device 11, as shown in Fig. 4, the control program 9 is initially stored. Furthermore, routines R are usually stored in the memory device 11. The routines R each contain code that can be directly processed by the control unit 7. The respective routine R defines a fixed sequence of lighting states Z* that the LEDs 4 of the respective light strip 3 are to assume. Such routines R are known to those skilled in the art. The routines R are in Fig. 4 are each supplemented by a number, i.e. designated as R1, R2, etc., in order to be able to distinguish them from each other if necessary.

[0049] In the simplest case, the control unit 7 determines which of the routines R it executes by using the state ST of the medical device 1 and / or by using the state ST from the environment of the medical device 1.

[0050] However, a program file 13 is preferably still stored in the memory device 12. The program file 13 contains a sequence of instructions A that can be processed by the control unit 7. The instructions A are in Fig. 3 - analogous to the routines R - each supplemented by a number, i.e. designated as A1, A2, etc., in order to be able to distinguish them from each other if necessary.

[0051] In contrast to the routines R, which contain machine code, the instructions A must first be interpreted by the control unit 7 before the respective instruction A is executed. For this purpose, a corresponding interpreter 14 is stored on the control unit 7. The processing of the instructions A by the control unit 7 is therefore carried out by interpretation using the interpreter 14. The interpreter 14 is designed according to Fig. 4 is also stored in the storage device 12. It can alternatively be stored independently or be a component of the control program 9.

[0052] As far as the control program 9, the routines R, and possibly the interpreter 14 are concerned, the memory device 12 is typically a fixed component of the control unit 7. For example, a processor and associated memory of the control unit 7 can be components of an ASIC. As far as the program file 13 is concerned, this can also be the case. As far as the program file 13 is concerned, however, the memory device 12 can also be an independent component of the control unit 7. This independent component can, if necessary, be permanently connected to the control unit 7 or be a unit detachably connected to the control unit 7.

[0053] If the program file 13 and the interpreter 14 are present, the control device 7 is designed such that it operates the medical device 1 according to an operating method which is described below in connection with Fig. 5 is explained in more detail. If the control unit 7 is microprocessor-controlled, the control unit 7 is designed by programming with the control program 9.

[0054] According to Fig. 4, the control unit 7 accepts the state ST in a step S11.

[0055] In a step S12, the control unit 7 determines at which of the instructions A of the program file 13 the control unit 7 begins interpreting the instructions A. The determination is made using the state ST. Depending on the state ST, the control unit 7 can thus determine, for example, the instruction A1 or the instruction A3 or another instruction A in step S12.

[0056] In a step S13, the control unit 7 interprets the instruction A determined in step S3 by means of the interpreter 14. The control unit 7 thus determines the associated executable code.

[0057] The following explanations of the further sequence are somewhat simplified, but show the principle.

[0058] After step S14, control unit 7 checks in step S14 whether the interpreted instruction A is a stop instruction. If this is the case, control unit 7 terminates the processing of instructions A and returns to step S11. It therefore accepts the next state ST. Otherwise, control unit 7 proceeds to step S15. In step S15, control unit 7 executes the last interpreted instruction A. Step S15 also determines the lighting states Z* and transmits them to the light strips 3.

[0059] Then, in a step S15, control unit 7 selects another instruction A. Typically, this is—according to the sequence of instructions A in program file 13—the next instruction A. However, it is also possible that the just-interpreted instruction A is a jump instruction. In this case, the program jumps to the instruction A specified in the jump instruction. It is also possible that the just-interpreted instruction A is a test. In this case, which instruction A is selected may depend on the result of the test. Control unit 7 then returns to step S13.

[0060] Independently of other facts, the instructions A at least specify which of the routines R are to be processed. This is exemplified below in connection with Fig. 6 is explained in more detail.

[0061] According to Fig. 6, the program file 12 comprises (among other things) instructions A14 to A20. Instructions A14 to A19 each specify which routine R is to be executed. Instruction A20 is a stop instruction. If control unit 7 determines the value 3 due to the state ST, instruction A14 is executed first. Thus, instructions A14 to A20, and thus routines R1, R4, R3, R1, R2, and R3, are executed one after the other. If, on the other hand, control unit 7 determines the value 4 due to the state ST, instruction A18 is executed first. Thus, only instructions A18 to A20, and thus routines R3 and R2, are executed one after the other.

[0062] As part of the procedure according to Fig. 6, the instructions A only specify which of the routines R are to be processed. The routines R as such are not changed. However, it is also possible to parameterize the routines R. This is shown below as an example in connection with the Fig. 7 and Fig. 8 for routine R1. Analogous explanations apply to the other R routines.

[0063] According to Fig. 7, the routine R1 is parameterizable with parameters P. Such parameterization is generally known to experts in the field of conventional programming.

[0064] According to Fig. 8, the A instructions of program file 13 include (among other things) specifications for the parameters P of routine R1. Therefore, if the state ST causes instructions A31 and A32 to be executed (alone or among other things), the parameters P (or at least one of the P parameters) can be specified, for example, within instruction A31. When routine R1 is subsequently called in instruction A32, the P parameters are also passed to routine R1. Thus, when routine R1 is executed, it is executed according to the specifications for the P parameters as defined by instruction A31.

[0065] The inventive manner of controlling the light-emitting diodes 4 of the light strips 3 is particularly advantageous when, as shown in Fig. 9, several light-emitting diodes 4 are combined to form a respective group 15 of light-emitting diodes 4. The light-emitting diodes 4 of the respective group 15 emit light in different wavelengths. This is shown in Fig. 9 by the letters R, G, B, which stand for the colors red, green, and blue. A control logic 16 is also generally assigned to the respective group 15. The light-emitting diodes 4 of the respective group 15 are arranged—usually including the control logic 16—in a common housing 17. In the context of the present invention, "housing" refers to the respective mounting unit arranged on the respective light strip 3.

[0066] A supply voltage U is supplied to the control logic 16 and the LEDs 4 of the respective group 15. The control logic 16 is also connected to a base potential GND. Control signals D are supplied to the control logic 16, which comprise the controls c* for the LEDs 4 of the respective group 15. The control logic 16 then controls the LEDs 4 of the respective group 15 accordingly.

[0067] If necessary, the control logic 16 also emits further control signals D' which are intended for other groups 15 of light-emitting diodes 4.

[0068] In the case of the formation of groups 15 of light-emitting diodes 4, the Fig. 2 and provided with the reference number 4 (for the light-emitting diodes) each for such a group 15 of light-emitting diodes 4.

[0069] In summary, the present invention relates to the following: A medical device 1 has a number of light strips 3, each with a plurality of individually controllable LEDs 4, and a control unit 7 for controlling the light strips 3. The control unit 7 dynamically determines a respective light state Z* by utilizing a state ST of the medical device 1 and / or a state ST from the environment of the medical device 1. This state Z* comprises a partial state z* for the LEDs 4, according to which the respective LED 4 is to be operated. The control unit 7 transmits the respective light state Z* to the light strips 3.

[0070] The present invention has many advantages. In particular, the light strips 3 can be used efficiently to convey information to an operator and / or a patient.

[0071] Although the invention has been illustrated and described in detail by the preferred embodiment, the invention is not limited to the disclosed examples and other variations may be derived therefrom by those skilled in the art without departing from the scope of the invention. List of References 1 medical device 2 tunnels 3 light strips 4 LEDs 5 controllers 6 Interface 7 Control unit 8 additional interfaces 9 Control program 10 Machine code 11 Sensor 12 Storage device 13 Program file 14 interpreters 15 group of LEDs 16 Control logic 17 housings A Instructions c* Controls D, D' control signals GND base potential P parameters R routines S1 to S16 steps U supply voltage V Specification Z* requested lighting state z* partial luminous states z actual lighting conditions

Claims

[1] Medical device (1) comprising a number of light strips (3), each having a plurality of individually controllable light-emitting diodes (4), and a control unit (7) for controlling the light strips (3), wherein the control unit (7) dynamically determines a respective light state (Z*) by utilizing a state (ST) of the medical device (1) and / or by utilizing a state (ST) from the environment of the medical device (1), which for the light-emitting diodes (4) each comprises a partial state (z*) according to which the respective light-emitting diode (4) is to be operated, and transmits the respective light state (Z*) to the light strips (3). [2] Medical device (1) according to claim 1, characterized by that the control device (7) evaluates a state (ST) from the environment of the medical device (1) and that this state (ST) is an acoustic signal or a movement signal. [3] Medical device (1) according to claim 1 or 2, characterized by, - that routines (R) are stored on the control unit (7), - that the respective routine (R) contains code which can be processed directly by the control unit (7) and defines a sequence of lighting states (Z*) determined by the respective routine (R) which the light-emitting diodes (4) of the respective light strip (3) are to assume, and - that the control device (7) determines which of the routines (R) it executes by utilizing the state (ST) of the medical device (1) and / or by utilizing the state (ST) from the environment of the medical device (1). [4] Medical device (1) according to claim 3, characterized by , - that a program file (13) is also stored on the control unit (7), - that the program file (13) contains a sequence of instructions (A) which can be processed by the control unit (7) by interpreting them using an interpreter (14) stored on the control unit (7), - that the instructions (A) specify at least which of the routines (R) are to be processed, and - that the control device (7) determines, by utilizing the state (ST) of the medical device (1) and / or by utilizing the state (ST) from the environment of the medical device (1), at which of the instructions (A) of the program file (12) the control device (7) begins to interpret the instructions (A). [5] Medical device (1) according to claim 4, characterized by that the instructions (A) only specify which of the routines (R) are to be processed. [6] Medical device (1) according to claim 4, characterized bythat the routines (R) are designed as routines (R) that can be parameterized with parameters (P) and that the instructions (A) of the program file (13) comprise specifications for the parameters (P) of the routines (R), so that the routines (R) are executed during their execution in accordance with the specifications for the parameters (P) of the routines (R) made by the instructions (A) of the program file (13).