Method for validating a medical application, end user device and medical system

Abstract

An inventive method for validating an end user device for use with a medical application. A medical application and a validation application are received in the end user device and the validation application is then executed, which includes: (i) determining the hardware and software environment of the end user device; (ii) providing a validation process compatible with the hardware and software environment; (iii) executing a test mode of the medical application; (iv) running the validation process during the test mode; and (v) determining from running the validation process whether the medical application is compatible with the end user device. When the medical application is determined to be compatible with the end user device, a validation report is generated and stored in the end user device and/or a server. When the medical application is determined to be incompatible with the end user device, the medical application is at least partially blocked.

Claims

1. A method for validating an end user device for use with a medical application, the method comprising: (a) receiving a medical application and a validation application in the end user device; (b) executing the validation application, comprising the following steps: (i) determining a hardware and software environment of the end user device; (ii) providing a validation process compatible with the hardware and software environment of the end user device; (iii) executing a test mode of the medical application; (iv) running the validation process during the test mode; (v) evaluating whether a baseline of the hardware and software environment has changed; (vi) determining from running the validation process whether the medical application is compatible with the hardware and software environment of the end user device; (c) when the medical application is determined to be compatible with the end user device, generating a validation report and storing the validation report in a non-editable data format in at least one of the end user device and a server; and (d) when the medical application is determined to be incompatible with the end user device, at least partially blocking the medical application from execution in the end user device.

2. The method according to claim 1, wherein step (d) includes outputting a notification to the end user device.

3. The method according to claim 1, wherein step (b)(ii) comprises selecting the validation process from a plurality of pre-defined validation processes, each pre-defined process being associated with a particular known hardware or software environment.

4. The method according to claim 1, wherein step (d) comprises blocking at least one functionality of the medical application.

5. The method according to claim 1, further comprising executing a second validation, comprising the following steps: determining at least one of a present software environment and a present hardware environment of the user device; and when one of the present software environment and the present hardware environment is determined to be different from the software and hardware environment, respectively, determined in step (b)(i), selecting a present validation process for testing the present software and/or the present hardware environment; and running the present validation process.

6. The method according to claim 1, further comprising: providing a white listing of at least one of software components and hardware components allowed for being provided in the software environment and the hardware environment, respectively, provided to the end user device; and determining whether at least one of a hardware component and a software component determined to be provided in the software environment and the hardware environment, respectively, is in the white listing.

7. The method according to claim 1, further comprising: providing a black listing of at least one of software components and hardware components not allowed for being provided in the software environment and the hardware environment, respectively, provided to the end user device; and determining whether at least one of a hardware component and a software component determined to be provided in the software environment and the hardware environment, respectively, is in the black listing.

8. The method according to claim 1, wherein step (b) comprises executing a user interaction routine configured to test a user interface of the end user device.

9. The method according to claim 1, wherein the executing of the validation application further comprises executing the medical application in demonstration mode.

10. An end user device for data communication with a medical device, comprising: a processor; a medical application configured to provide data communication between the end user device and a medical device; and a validation application configured to: (i) determine a hardware and software environment of the end user device; (ii) select a validation process compatible with the hardware and software environment of the end user device; (iii) execute a test mode of the medical application; (iv) run the validation process during the test mode; (v) evaluate whether a baseline of the hardware and software environment has changed; (vi) determine from running the validation process whether the medical application is compatible with the end user device; wherein when the medical application is determined to be compatible with the end user device, a validation report is generated and the validation report is stored in a non-editable data format in at least one of the end user device and a server; and when the medical application is determined to be incompatible with the end user device, the medical application is at least partially blocked from execution on the end user device.

11. A medical system, comprising: a medical device; and an end user device comprising: a processor; a medical application configured to provide data communication between the end user device and the medical device; and a validation application configured to: (i) determine a hardware and software environment of the end user device; (ii) select a validation process compatible with the hardware and software environment of the end user device; (iii) execute a test mode of the medical application; (iv) run the validation process during the test mode; (v) evaluate whether a baseline of the hardware and software environment has changed; (vi) determine from running the validation process whether the medical application is compatible with the end user device; wherein when the medical application is determined to be compatible with the end user device, a validation report is generated and the validation report is stored in a non-editable data format in at least one of the end user device and a server; and when the medical application is determined to be incompatible with the end user device, the medical application is at least partially blocked from execution on the end user device.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The above-mentioned aspects of exemplary embodiments will become more apparent and will be better understood by reference to the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

(2) FIG. 1 a schematic representation of a medical system;

(3) FIG. 2 a flow diagram for steps of a method for validating a medical application;

(4) FIG. 3 a flow diagram for steps of another method for validating a medical application;

(5) FIG. 4 a flow diagram for steps of a further method for validating a medical application; and

(6) FIG. 5 a schematic illustration of a step of setting up a validation process for the method for validating a medical application.

DESCRIPTION

(7) The embodiments described below are not intended to be exhaustive or to limit the invention to the precise forms disclosed in the following detailed description. Rather, the embodiments are chosen and described so that others skilled in the art may appreciate and understand the principles and practices of this disclosure.

(8) FIG. 1 shows a schematic representation of a medical system 100 comprising an end user device 101 and a medical device 102. In the embodiment shown, the medical device 102 is a blood glucose meter for continuous glucose monitoring. In alternative embodiments, the medical device 102 may be an insulin pump or any other medical device that may be used with an end user device 101 to receive data from the medical device 102 in the end user device 101 or send data from the end user device 101 to the medical device 102.

(9) The end user device 101 may be a smart phone, personal computer, tablet computer, diabetes management device or any other end user device that may be communicatively coupled to a medical device 102 to transmit data to or receive data from the medical device 102. The end user device 101 comprises a processor 103 and a memory 104. In alternative embodiments, more than one processor 103 and/or more than one memory 104 may be provided. A medical application as well as a validation application may be stored in the memory 104 and may be retrieved from the memory 104 and executed by the processor 103.

(10) The end user device 101 further comprises a medical device communication interface 105 to receive data from and transmit data to the medical device 102. Medical device communication interface 105 may be configured to provide a connection to medical device 102 via a wire. Alternatively or additionally, medical device communication interface 105 may be configured to provide a wireless connection with medical device 102.

(11) Additionally, a user interface 106 is provided in end user device 101. The user interface 106 may comprise a single interface device or a plurality of interface devices. The plurality of interface devices may comprise input devices, output devices and combined input/output devices. For example, the user interface 106 may comprise a touchscreen, a display, a keyboard, a computer mouse, a display, a speaker, a microphone, and/or any other device via which an input may be received from a user or an output may be provided to a user.

(12) The end user device 101 may further be coupled, wirelessly or via a wire, to a server 107 or other external device by a further communication interface 108.

(13) FIG. 2 is a flow diagram that illustrates steps of a method for validating a medical application on an end user device 101 configured for data communication with a medical device 102 by the medical application. Stated another way, the method shown in FIG. 2 validates the end user device for use with the medical application.

(14) In step 201, a user prompts the end user device 101 to download the medical application. In step 202, in response to the user prompt, prior information on the compatibility of the end user device 101 for the medical application is determined by determining device parameters, such as device model number, location and/or platform version, and receiving a white listing and a black listing from a server 107. The black listing and the white listing contain values for the parameters and/or combinations of values of the parameters indicating whether the end user device 101 is compatible, in the case of the white listing, or not compatible, in the case of the black listing, for the medical application. Following, in step 203, it is determined by the end user device 101, whether each device parameter is compatible, based on the white listing, not compatible, based on the black listing, or whether compatibility cannot be determined based on the black listing and the white listing. Alternatively or additionally, device parameters may be transmitted to the server 107 and determination regarding compatibility based on the white listing and the black listing may be performed in the server 107.

(15) If it is determined, based on the black listing, that the end user device 101 is not compatible for the medical application, the user is informed in step 204 by an output via a user interface 106 of the end user device 101 that the device is not supported for the medical application and the method terminates in step 205. If it is determined, based on the white listing, that the end user device 101 is compatible for the medical application, the medical application and a validation application are received by the end user device 101 in step 206. If compatibility cannot be determined based on the black listing and the white listing, the user is informed in step 207, by an output via the user interface 106 of the end user device 101, of a validation procedure and pre-requisites for the validation procedures using the validation app. Based on the information provided to the user, the user decides in step 208 whether he would like to continue with the procedure and provides a corresponding input to the end user device 101 via user interface 106. If the user decides not to continue with the procedure, the method terminates in step 205. If the user decides to continue with the procedure, the medical application and the validation application are received by the end user device 101 in step 206.

(16) FIG. 3 is a flow diagram illustrating steps of another method for validating a medical application on an end user device 101 configured for data communication with a medical device 102 by the medical application.

(17) In step 301, the validation application is executed and the validation is started. Additionally, the user may be prompted to confirm starting the validation. If the user confirms, the validation may then be started. If the user does not confirm starting the validation, the execution of the validation application may be terminated.

(18) The end user device is taken to an isolation mode in step 302. In the isolation mode, any external influence on the user device, such as data transmissions to or from the device 101 via third-party applications, is blocked. Alternatively, step 302 may be omitted and the end user device 101 may not be taken to isolation mode.

(19) Following, in step 303, the software environment and the hardware environment provided to the end user device 101 are determined. For example it may be determined which hardware devices, such as a user interface or processor, and software applications are provided in the end user device. In step 304, in response to the software and hardware environment determined, a validation process for testing the software and hardware environment to be compatible with the execution requirements for executing the medical application is set up. The validation process may consist of several validation routines and may further be defined by the order of the validation routines in the validation process. The validation process may be selected from a plurality of predefined validation processes. Setting up the validation process may also, alternatively or in addition, include selecting one or more validation process modules, which may consist of one or more validation routines, from a plurality of predefined validation process modules and assembling a validation process, which may also be referred to as creating a validation map, from the routines.

(20) The end user device 101 is then baselined in step 305. Baselining comprises summarizing properties of the end user device 101, such as lists of configurations, binaries and their checksums. The results of baselining are stored in a Validation Baseline. In an alternative embodiment, step 305 may be omitted. In this case, no Validation Baseline is created.

(21) In step 306, the software and hardware environment are tested according to the validation process. For example, it may be determined, whether certain minimal requirement, such as a speed of a data connection or a processing power, are fulfilled. Based on the results of the testing, a device validation protocol or report is created. Following, in step 307, it is determined based on the results of testing whether the software and hardware environment of the end user device 101 are compatible with the execution requirements.

(22) If it is determined that the software and hardware environment of the end user device 101 are not compatible with the execution requirements, execution of the validation application is terminated in step 308 and receiving and executing the medical application is blocked. Additionally, a black listing, containing values for parameters and/or combinations of values for parameters indicating that the end user device 101 is not compatible for the medical application, may be updated and stored on a server repository based on the results of the testing.

(23) If, in step 307, it is determined that the software and hardware environment of the end user device 101 are compatible with the execution requirements, then, in step 309, the system is baselined again and the result is compared to the Validation Baseline created in step 305 to determine whether the baseline has changed. If the baseline has changed, the validation process returns to step 301 and validation starts over. As explained above with regard to step 301, the user may be prompted to confirm starting the validation process (again). If the user does not confirm starting the validation process, the validation application may be terminated. If it is determined that the baseline has not changed in step 309, step 310 is performed. In embodiments in which step 305 is omitted and no Validation Baseline is created, step 309 is omitted. In this case, if it is determined that the software and hardware environment of the end user device 101 are compatible with the execution requirements in step 307, step 310 is performed.

(24) Step 310 comprises creating a Device State Signature. The Device State Signature may be a secured, for example encrypted, key that represents the checksum of the device validation report and, if applicable, the Validation Baseline. Hereby, the Device State Signature represents the state of the end user device 101 at the time of determining that the software and hardware environment are compatible with the execution requirements. The Device State Signature is stored on the end user device 101 and/or a server repository. Additionally, a white listing containing values for parameters and/or combinations of values for parameters indicating that the end user device 101 is compatible for the medical application, may be updated and stored on a server repository based on the results of the testing. The medical application is then downloaded and installed in the end user device 101. Additionally, the validation application may be amended in step 310. For example, software routines for monitoring the end user device 101 and/or the medical application and/or for triggering re-execution of the validation process may be downloaded and installed.

(25) In step 311, the medical application is then executed in a test mode which shall be broadly construed herein as covering a test mode, a demonstration mode, a validation mode or a preliminary mode. The software and hardware environment are tested to be compatible with execution requirements while the medical application is executed in test mode. The execution requirements may be any or all requirements with regard to which testing was performed in step 306. For example, if in step 306, a processing power was determined to meet minimum requirements for the medical application, it may be tested in step 311, whether processing power is sufficient while running the medical application. Alternatively or additionally, testing may be performed in step 311 with regard to one or more execution requirements with regard to which testing was not performed in step 306. For example, a speed for performing certain software routines specific to the medical application may be determined and compared to a minimum speed requirement. Based on the results of the testing, an application validation protocol or report is created. Following, in step 312, it is determined based on the results of testing, whether the software and hardware environment of the end user device 101 are compatible with the execution requirements while the medical application is executed in demonstration or validation mode.

(26) If it is determined that the software and hardware environment of the end user device 101 are not compatible with the execution requirements, the medical application is marked as unusable and/or is uninstalled from the end user device 101 in step 313. Following, the method proceeds to step 308 in which execution of the validation application is terminated and receiving and executing the medical application is blocked. Additionally, a black listing, containing values for parameters and/or combinations of values for parameters indicating that the end user device 101 is not compatible for the medical application, may be updated and stored on a server repository based on the results of the testing.

(27) If, in step 312, it is determined that the software and hardware environment of the end user device 101 are compatible with the execution requirements, then, in step 314, the system is once again baselined and the result is compared to the Validation Baseline created in step 305 to determine whether the baseline has changed. If the baseline has changed, the validation process returns to step 301 and validation starts over. As explained above with regard to step 301, the user may be prompted to confirm starting the validation process (again). If the user does not confirm starting the validation process, the validation application may be terminated. If it is determined that the baseline has not changed in step 314, step 315 is performed. In embodiments in which step 305 is omitted and no Validation Baseline is created, step 314 is omitted. In this case, if it is determined that the software and hardware environment of the end user device 101 are compatible with the execution requirements in step 312, step 315 is performed.

(28) In step 315, an Application State Signature is created. The Application State Signature may be a secured, for example encrypted, key that represents the checksum of the application validation report and the Device State Signature. The Device State Signature may be included in the Application State Signature entirely, in part, or in a summary such as a checksum. Alternatively, the Device State Signature may not be included in the Application State Signature. Thereby, the Application State Signature represents the state of the end user device 101 at the time of determining that the software and hardware environment are compatible with the execution requirements while the medical application is executed in demonstration or validation mode. The Application State Signature is stored on the end user device 101 and/or a server repository. In an alternative embodiment, the Device State Signature is not stored on a server repository in step 310 and the Device State Signature and the Application State Signature are stored on a server repository, separately or in consolidated form, in step 315. Additionally, a white listing containing values for parameters and/or combinations of values for parameters indicating that the end user device 101 is compatible for the medical application, may be updated and stored on a server repository based on the results of the testing.

(29) Execution of the medical application is then allowed in step 316 and the validation process ends.

(30) The flow diagram in FIG. 4 illustrates steps of a further method for validating a medical application. In the embodiment shown, a present hardware and software environment provided to the end user device 101 are determined every time the medical application is executed.

(31) The medical application is started in step 401. Following, in step 402, the present hardware and software environment provided to the user device 101 are determined. To determine the present hardware and software environment, the end user device 101 is baselined. In step 403, a Device State Signature and/or an Application State Signature are retrieved from the memory 104 of the end user device 101 and/or from a server repository. To compare the present hardware and software environment to the hardware and software environment determined in a validation that was previously performed, the baseline determined in step 402 is compared in step 404 to the Device State Signature and/or the Application State Signature retrieved in step 403.

(32) If it is determined that the present hardware and software environment is the same as the hardware and software environment determined in a previous validation, the medical application is executed in step 405.

(33) If, in step 404, it is determined that the present hardware and software environment is different from the hardware and software environment determined in a previous validation, the medical application is blocked from execution in step 406. The end user device 101 may then return to a normal mode of operation.

(34) Blocking the medical application from execution may comprise suppressing execution of any code of the medical application. Hereby, the medical application may not be started in the end user device 101. Alternatively, blocking the medical application from execution may comprise suppressing execution of only parts of the code of the medical application. For example, when execution of the medical application is blocked, a graphical user interface of the medical application may load, but all data transmission from and to the medical device 102 and other external devices 107 may be blocked by suppressing all execution of the respective elements of the code of the medical application.

(35) Whenever the medical application is blocked from execution, the user may be notified of the blocking. For example, a message may be displayed on a display of the end user device 101 informing the user that the medical application has been blocked from execution. The notification may also comprise the reasons for blocking the medical application from execution and/or the extent of the blocking, such as which functionalities of the medical application have been blocked when the medical application itself is not blocked from loading altogether.

(36) Alternatively, the user may be prompted to start a present validation comprising a present validation process. The present validation may comprise all steps of the previous validation. The previous validation may, for example, comprise all steps described with regard to the embodiment of the method of FIG. 3. Alternatively, steps may be added to and/or deleted in comparison to the previous validation or the present validation may be separate and different from the previous validation.

(37) In a further alternative, the user may not be prompted to start the present validation in step 406. The present validation may be performed automatically.

(38) FIG. 5 is a schematic illustration of a step of setting up a validation process for the method for validating a medical application on the end user device 101. The end user device 101 comprises a platform 500 which may also be referred to as a software domain. The platform 500 may be essentially comprised of an operating system. Several software components run on the platform 500. Software components include the medical application 501, the validation application 502 as well as several software components 503a, . . . , 503c that may form part of the platform 500 itself or may be provided as third-party applications. Additionally, data, such as validation routines 504, may be stored in association with the platform 500 or software components provided thereon. The end user device 101 further comprises a hardware domain 505. The hardware domain comprises hardware components such as different interface devices 506a, . . . , 506d. For example, the interface device 506a may be an optical disk drive and the interface device 506b may be a wireless data communication interface such as a Bluetooth module. Other software components 507a, . . . , 507c may be associated with the hardware domain 500 and not with the platform 500. For example, software components 507a, . . . , 507c may be firmware components.

(39) For setting up a validation process, hardware interface devices and software interface devices provided in the end user device 101 are analyzed. The validation process may be set up based on which components the medical application 501 will interact with. In the embodiment shown in FIG. 5, the medical application 501 interacts with software components 503b, 503c and 507c and with hardware components 506b and 506c. The medical application 501 interacts with hardware component 506b via software component 507c in the hardware domain. Medical application 501 interacts with hardware component 506c via software component 503c and the platform 500.

(40) When the components the medical application interacts with have been determined, the validation process may be set up accordingly. For example, in an embodiment of the method in which the validation process is assembled from predefined validation process modules, for the embodiment of the end user device 101 shown in FIG. 5, validation process modules associated with software components 503b, 503c and 507c and with hardware components 506b and 506c may be chosen to assemble the validation process, but validation process modules associated with software components 503a, 507a, 507b and 507d and with hardware components 506a and 506d may not exist or may exist but may not be included in the validation process.

(41) While exemplary embodiments have been disclosed hereinabove, the present invention is not limited to the disclosed embodiments. Instead, this application is intended to cover any variations, uses, or adaptations of this disclosure using its general principles. Further, this application is intended to cover such departures from the present disclosure as come within known or customary practice in the art to which this invention pertains and which fall within the limits of the appended claims.