A METHOD FOR GENERATING A MONITORING SIGNAL USING A SUPERVISING ENTITY OR SAFETY MODULE

Abstract

The present invention relates to method for generating a monitoring signal by monitoring laboratory values of a patient using a medical app (122). The medical app (122) is executed on a mobile device (102) of the patient, wherein the execution of the medical app (122) on the mobile device (102) of the patient is supervised by a supervising entity or safety module (106, 128), the supervising entity or safety module (106, 128) comprising at least executable program instructions (130). The medical app (122) comprises executable instructions for executing at least one sequence of processes for generating the monitoring signal. The processes comprise safety critical processes. The sequence of processes is triggered by the measurement of the blood glucose level of the patient. The method comprises executing a first process of the sequence of processes, wherein the execution results in the generation of an information, forwarding the information of the executed process to the supervising entity or safety module (106, 128), evaluating the received information by the supervising entity or safety module (106, 128) and executing a second process of the sequence of processes depending on the result of the evaluation.

Claims

1. A method for generating a monitoring signal by monitoring laboratory values of a patient using a medical app, the medical app being executed on a mobile device of the patient, wherein the execution of the medical app on the mobile device of the patient is supervised by a supervising entity or safety module, the supervising entity or safety module comprising at least executable program instructions, the medical app comprising executable instructions for executing at least one sequence of processes for generating the monitoring signal, the processes comprising safety critical processes, the sequence of processes being triggered by the measurement of the laboratory values, such as the blood glucose level of the patient, the method comprising: executing a first process of the sequence of processes, wherein the execution results in the generation of an information, forwarding the information of the executed process to the supervising entity or safety module, evaluating the received information by the supervising entity or safety module executing a second process of the sequence of processes depending on the result of the evaluation.

2. The method of claim 1, the sequence of processes comprising processes for measuring or determining at least one laboratory value of the patient, comparing the measured values to predefined ranges of permitted values, and in response to determining that at least one of the measured or determined values is beyond the predefined range, generating the monitoring signal

3. The method of claim 1, wherein the monitoring signal is adapted to trigger the mobile device to make an emergency call.

4. The method of claim 1, wherein the mobile device is connected to a medical device of the patient, wherein the monitoring signal is adapted to trigger the medical device to apply medication such that the laboratory values of the patient are moved into the perimeters of the predefined range.

5. The method of claim 1, wherein the monitoring signal is adapted to trigger the mobile device to emit a perceivable alarm signal.

6. The method of claim 1, wherein the execution of the first process results in the generation of an intermediate result, wherein the intermediate result is passed on to the second process for further processing, wherein the information comprises the intermediate result, wherein the supervising entity or safety module verifies whether the intermediate result is within a defined range of results, wherein the second process of the sequence is only executed if the result has been determined to be within the defined range of results.

7. The method of claim 6, wherein in response to determining that the result is within the predefined range, the supervising entity or safety module generates a trigger signal and transmits the trigger signal to the mobile device, wherein the trigger signal when received by the mobile device triggers the mobile device to execute the second process.

8. The method of claim 6, wherein in response to determining that the intermediate result is not within the defined range of results, the supervising entity or safety module brings the mobile device into a safe state.

9. The method of claim 1, wherein identifiers are assigned to the processes of the sequence, wherein the supervising entity or safety module is operable to access a sequence table, wherein the sequence table comprises entries specifying allowed sequences of processes, wherein the information comprises the identifier of the second process, wherein the supervising entity or safety module verifies whether the second process may be executed subsequent to the first process by looking up the sequence table, and wherein in response to determining that the second process is not allowed to be executed subsequent to the first process the supervising entity or safety module interrupts the execution of the sequence.

10. The method of claim 9, wherein the supervising entity or safety module is adapted to create a log file during execution of the sequence of processes, the log file comprising the identifiers of processes which have already been executed in course of the execution of the sequence of processes.

11. The method of claim 10, wherein the sequence table further comprises information specifying a set of processes which have to be executed prior to the execution of the second process, wherein supervising entity or safety module further verifies whether the set of processes has been executed by looking up the sequence table and comparing the identifiers of the set of processes with the identifiers comprised in the log file.

12. The method of claim 10, wherein the supervising entity or safety module deletes the log file if the sequence of processes has been completed successfully.

13. The method any of claim 9, wherein in response to determining that the second process is not allowed to be executed subsequent to the first process the supervising entity or safety module brings the mobile device into a safe state.

14. The method of claim 8, wherein in the safe state the functionality of the mobile device is reversibly reduced, such that the mobile device is no longer operable to make an emergency call and/or trigger a medical device to apply medication and/or emit a perceivable alarm signal while in the safe state.

15. The method of claim 1 wherein the supervising entity or safety module is operable to address the mobile device to conduct a data processing algorithm, wherein the supervising entity or safety module further provides the mobile device with data for processing using the data processing algorithm, wherein the mobile device in response to being addressed by the supervising entity or safety module conducts the data processing algorithm thereby generating a result, wherein the supervising entity or safety module in response to the mobile device generating the result, verifies the result and in response to successfully verifying the result triggers the mobile device to execute the second process.

16. The method of claim 15, wherein the supervising entity or safety module addresses the mobile device to conduct the data processing algorithm if no allowed range for the intermediate result received with the information is defined.

17. The method of claim 1, wherein the mobile device is connected to a measurement entity, wherein the mobile device when executing the process of measuring at least one laboratory value of the patient addresses the measurement entity to conduct a corresponding measurement and return corresponding measurement values.

18. A system comprising a mobile device being connected to a supervising entity or safety module, wherein the mobile device is operable to execute at least one medical app, wherein the execution of the medical app on the mobile device is supervised by the supervising entity or safety module, the supervising entity or safety module comprising at least executable program instructions, the medical app comprising executable instructions for executing at least one sequence of processes for generating the monitoring signal, the processes comprising safety critical processes, the sequence of processes being triggered by the measurement of laboratory values of the patient, the mobile device being operable to execute a first process of the sequence of processes, wherein the execution results in the generation of an information and to forward the information to the supervising entity or safety module, wherein the supervising entity or safety module is adapted to evaluate the information, wherein the mobile device is further adapted to execute the second process of the sequence of processes depending on the result of the evaluation.

19. The system of claim 18, wherein the supervising entity or safety module comprises at least one processor, a telecommunication interface and a memory, wherein the memory comprises at least executable instructions for evaluating the information, wherein the processor of the supervising entity or safety module is adapted to execute the executable instructions comprised in the memory, and wherein the supervising entity or safety module is adapted to communicate with the mobile device using the communication interface.

20. A medical system comprising an infusion pump for the delivery of a fluid, such as a nutrient and/or medication, into a patient's body, the rate of fluid delivery of the infusion pump being controllable by a control parameter, a sensor for sensing at least one physiological parameter of the patient, a mobile device for execution of a medical app, and a testing module for testing the mobile device, the mobile device being configured to a receive a sensed value of the physiological parameter from the sensor for entry of the value of the physiological parameter into the medical app, b in response to receipt of the value of the physiological parameter, execution of the medical app for determining the control parameter for controlling the infusion pump, the medical app implementing a control algorithm that uses the physiological parameter as an input value, c sending the control parameter to the infusion pump for adjusting the rate of fluid delivery, whereby the medical app is configured to transmit a testing request to the testing module and whereby the medical app is configured such that step c is only executed if the testing module returns a response to the medical app that indicates a positive testing result.

21. The medical system of claim 20, wherein the testing module is a separate hardware entity, wherein the mobile device and the testing module have respective wireless interfaces for transmission of the testing request, the testing result and messages that are interchanged between the mobile device and the testing module for execution of the testing.

22. The medical system of claim 21, wherein the infusion pump is a continuous subcutaneous insulin infusion pump, the fluid containing insulin, and the sensor is a subcutaneous sensor, wherein the physiological parameter sensed by the sensor is the blood glucose level of the patient.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0076] In the following, embodiments of the invention are explained in greater detail by way of example only, making reference to the drawings in which:

[0077] FIG. 1 is a block diagram of a system comprising a mobile device, a supervising entity or safety module and a medical device,

[0078] FIG. 2 is a schematic of a sequence of processes being supervised by the supervising entity or safety module using identifiers of the processes,

[0079] FIG. 3 is a schematic of a sequence of processes wherein the correct execution of the sequence is verified by a supervising entity or safety module by verifying the results of the individual processes,

[0080] FIG. 4 is a block diagram of a system comprising a smartphone client and a supervising entity or safety module server;

[0081] FIG. 5 is a schematic illustrating the data flow between the smartphone client and the supervising entity or safety module server;

[0082] FIG. 6 is a sequence diagram illustrating the starting of the medical app and the pairing of a mobile device and the supervising entity or safety module;

[0083] FIG. 7 is a sequence diagram illustrating the verification the correct operation of the mobile device by the supervising entity or safety module;

[0084] FIG. 8 is a flow diagram of the medical app;

[0085] FIG. 9 is a flow chart of a scan process for BLE modules;

[0086] FIG. 10 is a flow chart of a validation process;

[0087] FIG. 11 is a sequence diagram for the startup of the medical app and the scanning for supervising entity or safety modules

[0088] FIG. 12 is a sequence diagram illustrating the request of an identifier;

[0089] FIG. 13 is a sequence diagram illustrating the execution of a critical code sequence; and

[0090] FIG. 14 is a sequence diagram illustrating the validation by the supervising entity or safety module.

[0091] Like numbered elements in these Figs. are either equivalent elements or perform the same function. Elements which have been discussed previously will not necessarily be discussed in later Figs. if the function is equivalent.

DETAILED DESCRIPTION

[0092] FIG. 1 illustrates an example of a system 100 comprising a mobile device 102, a medical device 104 and a supervising entity or safety module 106. The mobile device 102 comprises a central processing unit 108 and a communication interface 110. Via the communication interface 110 the mobile device 102 can be connected to the medical device 104. The medical device 104 comprises an interface 112 for communicating with the mobile device 102 and further comprises a central processing unit 114. The mobile device 102 is further connected via the communication interface 110 to the supervising entity or safety module 106.

[0093] The supervising entity or safety module 106 comprises a memory 116 as well as a communication interface 118 and a central processing unit 120.

[0094] For monitoring the laboratory values of a patient the central processing unit 108 of the mobile device 102 comprises a program module further referred to as medical app 122. The medical app 122 is operable to demand laboratory values of a patient using the communication interface 110 from a medical device 104. The medical device 104 when being addressed by the medical app 122 of the mobile device 102 may then execute a program module 124 for measuring laboratory values of the patient. The execution of the program module 124 by the central processing unit 114 of the medical device 104 may then result in the collection of data representative of for example blood values of the patient like the blood glucose level or the oxygen saturation or other data specifying the current condition of the patient. Once this data has been collected by medical device 104 the medical device 104 forwards the collected data to the mobile device 102 using the interfaces 112 and 110. The medical app 122 may then process the received data in order to verify whether the laboratory value calculated from the received data is within a predefined range. For example the medical app 122 may verify whether the blood glucose level of the patient is too high or too low.

[0095] If the medical application 122 determines that the blood glucose level is outside the predefined ranges, the medical app 122 may then address the medical device 104 to initiate counter measures by generating a corresponding monitoring signal and forwarding the signal to the medical device 104. Upon receiving the monitoring signal the medical device 104 may then execute a further program module 126 using the central processing unit 114. The execution of the program module 126 may then cause the medical device 104 to apply a medication to the patient in order to affect the patient such that the laboratory value shifts into the predefined range. For example if the medical app 122 determined that the blood glucose level of the patient is too high the execution of the program module 126 may cause the medical device 104 to inject insulin into the patient's tissue.

[0096] It is also possible that the medical app 122 upon determining that a laboratory value of the patient is outside the predefined range triggers the mobile device 102 to make an emergency call. To this end the mobile device 102 may be programmed such that when making this emergency call the mobile device 102 automatically includes information on the patient, the laboratory value which is outside the predefined ranges and the location of the patient.

[0097] Yet another possibility is that the medical app 122 upon determining that the laboratory value, which has been monitored, is outside the predefined range causes the mobile device 102 to emit a perceivable alarm, for example an alarm sound, vibration or a flashing light in order to inform the patient of his current condition.

[0098] Usually the execution of the medical app 122 will include the execution of a sequence of individual processes. For example, the execution of the sequence of processes may include a first process for determining the laboratory value of the patient, a second process for determining whether the laboratory value is within the predefined range, a third process for displaying the laboratory value to the patient, a fourth process for demanding a confirmation to initiate counter measures and a fifth process to actually initiate these counter measures. In this case the step of initiating counter measures should not be executed unless the step of demanding a confirmation from the patient has already been executed. To make sure that the individual processes of the medical app 122 are executed in a correct way, the central processing unit 108 of the mobile device 102 may further comprise a supervising entity or safety module 128. In this case the supervising entity or safety module 128 is embodied in a task, which is executed by the central processing unit 108 of the mobile device 102.

[0099] In accordance with embodiments of the invention the individual processes of the medical app 122, upon being executed by the central processing unit 108, create information which is forwarded to the supervising entity or safety module 128. Using this information the supervising entity or safety module 128 can then verify whether the medical app 122 is executed correctly and in case the supervising entity or safety module 128 determines that the medical app 122 is not working correctly, the supervising entity or safety module 128 is operable to interrupt the execution of the medical app 122.

[0100] As shown in FIG. 1 it is also possible to embody the supervising entity or safety module 106 in a separate module comprising a memory 116, a communication interface 118 and a central processing unit 120, wherein the central processing unit 120 is operable to execute a program module 130 for evaluating the information produced during execution of the medical app 122. Once the supervising entity or safety module 106 determines by evaluating the information received from the mobile device 102 that the execution of the medical app 122 is flawed, the supervising entity or safety module 106 is operable to interrupt the execution of the medical app 122. To this end it is necessary that the supervising entity or safety module 106 can directly influence the execution or the functionality of the central processing unit 108.

[0101] In accordance with embodiments of the invention the medical device 104 may be an infusion pump for the delivery of a fluid into a patient's body, such as an insulin pump for the delivery of insulin for diabetes treatment. The medical device 104 may be coupled to a sensor for sensing at least one physiological parameter of the patient, i.e. a laboratory value such as the blood glucose level of the patient.

[0102] The sensor and/or the medical device 104 may be implemented as a single or two separate implants such as for subcutaneous implantation into the patient's body. The signals delivered by the sensor are evaluated by the program module 124 which results in the determination of the physiological parameter which is then communicated to the mobile device 102 via the communication interface 112 of the medical device 104. The mobile device 102 may be implemented as a mobile telecommunication device, such as a smartphone.

[0103] The mobile device 102 executes the medical app 122 into which the value of the physiological parameter is entered. The medical app 122 implements a control algorithm that uses the physiological parameter as an input value for determining a value of the control parameter for controlling the rate of fluid delivery by the infusion pump. For example, in the case of a diabetes application for diabetes care, the control algorithm may implement any suitable prior art control algorithm for controlling the rate of insulin delivery into a patient's body depending on the measured blood glucose level and/or other additional parameters that may have been received or entered and stored on the mobile device 102.

[0104] The mobile device 102 sends the value of the control parameter to the medical device 104. The value of the control parameter is entered into the program module 126 for controlling the infusion pump in accordance with the value of the control parameter for adjusting the rate of fluid delivery correspondingly.

[0105] In order to improve the safety of the medical system considered here the correct functioning of the mobile device 102 is supervised by a testing module, that may be implemented as a supervising entity 128 that is implemented as a program module, or a safety module 106 that is implemented as a separate hardware unit.

[0106] Alternatively, there may both be a software implemented supervising entity 128 and a hardware implemented safety module 106 for maximum safety. In the following the hardware implemented safety module 106 is considered here by way of example.

[0107] Before the medical app 122 sends the value of the control parameter to the medical device 104, the medical app 122 sends ‘information’ to the safety module 106 that signals a testing request. In response to receipt of the testing request, execution of the program module 130 is invoked for execution of a testing routine.

[0108] Execution of the testing routine may encompass the interchange of several testing messages between the mobile device 102 and the safety module 106 for testing whether the mobile device 102 is in a functional state. In particular, the program module 130 may implement a validation service as described below in particular with respect to FIGS. 4 and 10.

[0109] In case execution of the program module 130 results in a positive testing result that indicates a functional state of the mobile device 102, a respective response is returned from the safety module 106 to the mobile device 102. The medical app 122 only sends the value of the control parameter to the medical device 104 for adjusting the rate of delivery of the infusion pump, if the safety module 106 returns a positive testing result.

[0110] If the testing result is negative, the safety module 106 may return an ‘interrupt’ for interrupting the execution of the medical app 122 and/or for causing the mobile device 102 for outputting a visual, acoustic and/or tactile alert signal for informing the patient as regards the malfunctioning of the mobile device and/or for putting the mobile device 102 into a safe state, such as by disabling the communication interface 111 such that the mobile device 102 is prevented from sending the value of the control parameter to the medical device 104.

[0111] In the following, two possible approaches for supervising the execution of a sequence of processes will be discussed. A first possible embodiment of supervising a sequence of processes is depicted in FIG. 2. The process shown in FIG. 2 comprises four process steps. In this case the medical device 104 may be an insulin pump, which also has the functionality of monitoring the blood glucose level of a patient. In a first process step the blood glucose value is determined for example by demanding corresponding data from medical device 104 by the medical app 122. Once the blood glucose level has been input a second step of the process is to re-display the blood glucose value to the patient. In course of this re-displaying the medical app may demand a confirmation from the patient that appropriate counter measures may be executed. Only after obtaining this confirmation the blood glucose value may then further be processed in a fourth step for example such that in the end insulin shall be applied.

[0112] As described before, the execution of these four processes is supervised by the supervising entity or safety module 106. The supervising entity or safety module comprises a table 132, wherein the table is representative of the correct sequence of processing steps. To this end, table 132 may comprise the ID of a currently executed process, the ID of a next expected process and the values of IDs of processes which are not allowed to be executed subsequent to the current process.

[0113] In the situation depicted in FIG. 2 the process step of processing the blood glucose value, which is ID number 4, may not be executed until the confirmation of the patient has been obtained by executing the process with ID number 3. During execution the individual processes forward the ID of the currently executed process to the supervising entity or safety module 106. The supervising entity or safety module 106 then verifies whether the currently executed process is actually allowed to be processed. If the supervising entity or safety module 106 determines for example that the process with ID 3 is executed after the process with ID 1, the supervising entity or safety module interrupts the execution of the process.

[0114] In general it is possible to create the table 132 such that it contains information on the exact sequence of IDs or rules for IDs, which are not allowed to be executed after a certain ID of a prior process. The table 132 may also comprise the ID of a currently executed process and the process which has to be executed next. In general the approach depicted in FIG. 2 can be used to verify the correct sequence of processes during execution of the medical app.

[0115] In the approach depicted in FIG. 3 the supervising entity or safety module 106 as well comprises a table 134, but this time the supervising entity or safety module 106 is also operable to verify the intermediate results which are generated by the execution of the individual processes. For example, the process number 1, upon being executed by the central processing unit 108 of the mobile device 102, creates a result number 1. The supervising entity or safety module 106 may then access the table 134 and verify whether the result of process number 1 is within the allowed range of results that is in this case between values a and b. If this is the case, supervising entity or safety module 106 may then forward the result of process number 1 to process 2, such that process number 2 can be executed by the central processing unit. However, it is also possible that the process number 1 forwards the results of its execution to process number 2 by itself. Once process number 2 has been executed and created a result number 2, this result 2 is again forwarded to the supervising entity or safety module 106, wherein the supervising entity or safety module 106 verifies the result of process number 2 by looking up table 134. As described before, if the result number 2 is within the allowed range of results, supervising entity or safety module 106 forwards the result of process number 2 to process number 3 and so forth.

[0116] Note that in the situation depicted in FIG. 2, the sequence of processes will keep running until the supervising entity or safety module determines that a process is about to be executed, which is not allowed to be executed and then interrupts the execution of the sequence of processes. In the situation depicted in FIG. 3, the execution of a process depends on the confirmation of the correct execution of the prior process by the supervising entity or safety module 106. Thus, in the situation depicted in FIG. 2 the supervising entity or safety module only observes and intervenes if something goes wrong, wherein the supervising entity or safety module 106 depicted in FIG. 3 is directly involved in the sequence of processes of the medical app.

[0117] Note that it is also possible to design the supervising entity or safety module 106 depicted in FIG. 1, such that it also supervises the execution of the supervising entity or safety module 128 executed by the central processing unit 108 of the mobile device 102.

[0118] FIG. 4 depicts a block diagram of a system 200 comprising a smartphone 202 as a mobile device and a supervising entity or safety module 204. The smartphone has a medical app 206 installed therein, which can be operated by a user 208 via a touch sensitive display of the smartphone 202. Via the touch sensitive display of the smartphone 202 the user 208 can call functions of the app 206 and receives a response about the status of the started functions. The app 206 is operable to communicate with the supervising entity or safety module 204 via a Bluetooth Low Energy (BLE) interface. The supervising entity or safety module 204 is a device which is physically separated from the smart phone 202 and thus gives a number of boundary conditions which have to be obeyed when constructing the supervising entity or safety module 204. The supervising entity or safety module 202 has its own power supply causing limited energy resources. For this reason a BLE interface is used.

[0119] The supervising entity or safety module 204 acts like a server, while the smart phone 202 can be understood as a client. As a client, the smart phone 202 is operable to connect to a plurality of BLE servers. This way the smart phone 202 does not occupy a physical interface. As a client, the smart phone 202 initiates the connection procedure sends request to the connected server. This way the smart phone 202 may inquire an identifier or can start the validation service of the supervising entity or safety module 204. The identifier serves as an entry into the BLE communication. The identifier is a single characteristic, which can be inquired and whose value is displayed to the user 208 in case of a successful data transfer.

[0120] The validation service is the main function of the supervising entity or safety module 204 and is meant to test the application 206 for correct execution. To this end the supervising entity or safety module 204 is operable to interfere with the activity of the application 206 in case the application 206 intends to execute a critical code sequence. The application 206 does not have the authorization to execute such a critical code sequence and has to request such an authorization from the supervising entity or safety module 204. To this end the supervising entity or safety module 204 may send a validation problem, which has to be solved by the smart phone 202. In case the result of the validation problem is correct, the application 206 will receive the authorization to execute the critical code sequence from the supervising entity or safety module 204. In case the result is not correct, the supervising entity or safety module 204 rejects the execution of the critical code sequence. The corresponding data flow between the smartphone client 202 and the supervising entity or safety module server 204 is illustrated in FIG. 5.

[0121] FIG. 6 is a sequence diagram illustrating a method for starting the app 206, scanning for a supervising entity or safety module 204 and providing an identifier. The method starts with the user 208 starting the app 206 provided on the smart phone 202. The system 200 is then in a loop waiting for a user entry. Once the user 208 presses a button for starting a scanning procedure the application 206 starts a search for BLE devices. The fund BLE device then returns a name and address to the application 206 whereupon the application 206 displays this information to the user 208 via a display of the smart phone 202 the app 206 is running on. The user 208 then selects a detected module which is then returned to the user 208. Subsequently the application 206 is in a loop waiting for further user input. One the user 208 presses a button of the application 206 indicating that a request for an identifier shall be sent to the security module 204 the application 206 establishes a connection to the supervising entity or safety module 204 and receives a characteristic from the supervising entity or safety module 204. Further the application 206 request the identifier which is then returned by the supervising entity or safety module 204. The application 206 then displays the identifier and disconnects from the supervising entity or safety module 204. The application 206 returns to a loop waiting for further user input.

[0122] FIG. 7 is a sequence diagram of a method for verifying the correct operation of the mobile device 102 by the supervising entity or safety module 106 once a critical sequence of the medical app run 122 on the mobile device 102 is to be started. A critical sequence may for example be a sequence of method steps during which a critical medication has to be applied to the patient. To prevent the medical device 104 which is controlled by the medical app 122 run on the mobile device 102 from applying for example an incorrect dose rate due to a malfunctioning of the mobile device 102, the correct function of the medical app 122 should be validated prior to the execution of critical sequences.

[0123] In the initial state depicted in FIG. 7, the medical 122 is in a loop waiting for a user entry. If the user of the medical app 122 decides to start a critical sequence of a medical app 122, like for example the application of medicine, he may activate the corresponding function of the medical app 122 by pressing a corresponding button on the interface of the medical app 122. The medical app when addressed by the user may then check whether the sequence the user intends to use is a critical sequence. The medical app 122 may be configured not to run sequences which are marked as “critical” without permission of the supervising entity or safety module 106.

[0124] Thus if the medical app 122 determines, that the sequence activated by the user is critical, the medical app 122 or the mobile device 102 establishes a telecommunication connection with the supervising entity or safety module 106, for example via Bluetooth™ Low Energy. The medical app 122 then addresses the supervising entity or safety module to validate the medical app 122 thereby requesting the authorization to start the critical sequence activated by the user.

[0125] Upon being addressed by the medical app 122, the supervising entity or safety module 106 provides the medical app 122 with an arithmetic problem. This may for example be a simple addition of two numbers. The supervising entity or safety module 106 may then comprise a table comprising a plurality of number pairs and the corresponding result of their addition. Once the medical app 122 received the arithmetic problem, the medical app 122 solves the arithmetic problem using the CPU 108 of the mobile device 102 and returns the solution thus determined to the supervising entity or safety module 106. The supervising entity or safety module 106 then verifies, whether the arithmetic problem has been solved correctly.

[0126] If the supervising entity or safety module 106 determines, that the solution returned by the medical app 122 is correct, the supervising entity or safety module 106 authorizes the medical app 122 to execute the critical sequence activated by the user. The medical app 122 then executes the critical sequence and returns results of the critical sequence to the user if there are any results to be returned. Once the execution of the critical sequence has finished, the medical app 122 may then cause the mobile device 102 to disconnect from the supervising entity or safety module 106 and wait for further user entries.

[0127] If however the supervising entity or safety module 106 determines, that the solution returned by the medical app 122 is incorrect, the supervising entity or safety module 106 denies authorization of the medical app 122 to execute the critical sequence. The medical app 122 in response to receiving the denial may then display an error message to the user. Further the medical app 122 may cause the mobile device 102 to disconnect from the supervising entity or safety module 106 and to terminate the medical app 122, as the correct execution of sequences can no longer guaranteed.

[0128] It has to be noted that the user input of the diagrams depicted in FIGS. 6 and 7 is to be understood as an example for the exemplary application which is described. Other applications may have other inputs and outputs without departing from the scope of the claimed invention.

[0129] FIG. 8 depicts a flow diagram of the main activity of the medical app 206. The main activity is the start activity and is meant to lead the user 208 for selecting functions of the application 206. Upon starting the application 206, the application 206 first checks, whether the BLE interface of the smart phone 202 is activated and in case the BLE interface is not activated asks user 208 whether the BLE interface shall be activated. Subsequently the user 208 may for example start the search for BLE modules by selecting the corresponding push-button. The search process for BLE modules will then be executed in another activity which is called when the user 208 presses the corresponding button. This BLE scan activity will later be described with reference to FIG. 9. Further the user 208 may start the inquiry for the identifier or the validation activity for a code sequence which is declared as being critical by pressing the corresponding button of the main activity. The validation activity will be described with reference to FIG. 10. It has to be noted that the flow chart of FIG. 8 only shows the part of the application 206 which is relevant for safeguarding the critical code sequences.

[0130] FIG. 9 depicts a flow diagram of the BLE scan activity. In the BLE scan activity a user 208 may conduct the searching procedure for BLE modules like a supervising entity or safety module 204. For example the BLE scan activity may be a list activity providing the plurality of functionalities for the displaying of data in the form of a list. Found BLE modules may be displayed with name and address and can be selected by the user 208 after the search for BLE modules has finished. The name and the address of the selected BLE module are then stored. In case the BLE scan activity is left during a search procedure, the search is stopped. A user 208 may himself stop the search procedure at any time using the corresponding button and may also restart the search procedure. For example the search procedure may have a time limit of 2 seconds.

[0131] FIG. 10 depicts a flow diagram illustrating the validation activity for verifying the correct performance of the smart phone 202. The activity for validation is being called by the main activity in case the code sequence marked as being critical is meant to be executed. Once the validation activity has been called the validation activity takes further steps in order to contact the supervising entity or safety module 204 and start the validation service of the supervising entity or safety module 204. To this end a characteristic is descried on the supervising entity or safety module 204. The changing of this characteristic is interpreted by the supervising entity or safety module 204 as a starting signal for starting the validation service. The validation problem is then received in two steps. The supervising entity or safety module 204 equips the corresponding characteristics with values from a validation table comprised in the supervising entity or safety module 204. The value which is initialized second is set to “notification” upon starting the validation. As a result the application 206 will recognize the amended value of the characteristic.

[0132] In case the value has changed and this change has been submitted to the application 206, the second value is being read and the validation problem is solved by the smart phone 202. Upon sending the result of the validation problem the supervising entity or safety module 204 sends an integer value to the application, wherein the application is operable to interpret said integer value as an authorization or denial for executing the critical code sequence. In case of an authorization the activity of the code sequence marked as critical is started. In case of a denial the user is informed 208 that the request for executing has been denied and the application 206 is closed.

[0133] The validation problem described in FIG. 10 is a simple example of a validation problem only comprising a summation of two summands. It may however also be possible to use way validation problems which are more complex to solve.

[0134] FIG. 11 is a sequence diagram illustrating the start-up of the main activity of the application 206 as well as the scanning for BLE modules like the supervising entity or safety module 204. Upon starting the application 206 the status of the BLE interface of the smart phone 202 is checked and in case the interface is not yet activated the user 208 is asked whether the BLE interface shall be activated. In case the BLE interface of the smart phone 202 is activated, the user may initiate the search for BLE modules by activating the corresponding button for “start scan”. Upon selection of one of the displayed BLE modules the corresponding data is passed on to the main activity for further processing and for displaying the data to the user 208.

[0135] FIG. 12 depicts a sequence diagram illustrating the requesting of an identifier from the supervising entity or safety module 204. Upon activation of the button “request identifier” of the application 206 by the user 208 the selected BLE module is contacted using the BLE service and the characteristic “identification” is requested from the BLE module. This serves as an entry into the BLE communication. The value of the characteristic is displayed to the user 208 upon successful transmission of the characteristic. The identification is only provided by a supervising entity or safety module 204. In case the connected BLE module does not provide the identification, the connected BLE module is not a supervising entity or safety module 204. In this case the application 206 is closed with displaying a message indicating “supervising entity or safety module not found” has to be started all over again.

[0136] FIG. 13 depicts a sequence diagram illustrating the execution of a critical code sequence. Upon activating the button for “start code sequence” the validation activity is started. The validation activity conducts a validation of the application 206 using the supervising entity or safety module 204. The validation is meant to verify whether the smart phone 202 and the application 206 work as expected. The validation procedure as such is illustrated in FIG. 14 and will be discussed in the following. In the first case depicted in FIG. 13 the validation leads to the supervising entity or safety module 204 returning an authorization to execute the critical code sequence. The result of the critical code sequence is then displayed to the user 208. In the second case the supervising entity or safety module 204 returns a denial which is provided to the user. In this case the critical code sequence is not executed.

[0137] FIG. 14 depicts a sequence diagram illustrating the validation process as performed by the supervising entity or safety module 204. As illustrated in FIG. 14 the validation procedure is triggered by the main activity of the application 206. To this end the validation activity upon being called by the main activity initializes the establishing of a connection with the supervising entity or safety module 204. Once the connection has been successfully established, the characteristics “summand one” and “permission” are set to “notification” in order to receive their corresponding value as soon as they are altered. Subsequently the validation process is being started by setting the characteristic “validation_start”. To this end the supervising entity or safety module 204 creates the validation problem and initializes for example the two summands “summand_one” and “summand_two”. First “summand_two” is written into the corresponding characteristic and subsequently “summand_one” is written. This writing procedure is recognized by the application 206 because of the notification functionality of BLE and as a result the application 206 retrieves the second summand via read-request. As a result the smart phone 202 retrieved the validation problem. This validation problem as to be solved by the smart phone 202 and the result has to be returned to the supervising entity or safety module 204 in a characteristic “calculation_result”. The supervising entity or safety module 204 verifies the result using a look-up table and depending on the result of this verification sends an authorization or a denial in the characteristic “permission”. The characteristic “permission” is set to “notification” as well and as a result is passed on to the validation activity for further processing. In case an authorization is received the code sequence is executed. In case a denial has been received the user is informed about the denial by a corresponding message and the activity is closed.

[0138] It has to be noted that the user input of the diagrams depicted in FIGS. 12, 13 and 14 is to be understood as an example for the exemplary application which is described. Other applications may have other inputs and outputs without departing from the scope of the claimed invention.

[0139] Further embodiments related to the invention are described in the attached scientific annex.

LIST OF REFERENCE NUMERALS

[0140] 100 System [0141] 102 Mobile Device [0142] 104 Medical Device [0143] 106 safety module (Supervising Entity) [0144] 108 CPU [0145] 110 Communication Interface [0146] 112 Interface [0147] 114 CPU [0148] 116 Memory [0149] 118 Communication Interface [0150] 120 CPU [0151] 122 Medical App [0152] 124 Program Module [0153] 126 Program Module [0154] 128 Supervising entity [0155] 130 Program Module [0156] 132 Table [0157] 134 Table [0158] 200 System [0159] 202 Smartphone Client [0160] 204 Supervising entity or safety module Server [0161] 206 Application [0162] 208 User