WO2020129008A1 - Dispositif médical sécurisé - Google Patents

Dispositif médical sécurisé Download PDF

Info

Publication number
WO2020129008A1
WO2020129008A1 PCT/IB2019/061197 IB2019061197W WO2020129008A1 WO 2020129008 A1 WO2020129008 A1 WO 2020129008A1 IB 2019061197 W IB2019061197 W IB 2019061197W WO 2020129008 A1 WO2020129008 A1 WO 2020129008A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
behavior
environment
medical system
request
Prior art date
Application number
PCT/IB2019/061197
Other languages
English (en)
Inventor
Stephan Proennecke
Joao Budzinski
Joël REY
Original Assignee
Debiotech S.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Debiotech S.A. filed Critical Debiotech S.A.
Publication of WO2020129008A1 publication Critical patent/WO2020129008A1/fr

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/63—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation

Definitions

  • the disclosure relates to a suitable device, system and / or method (s) for securely controlling a medical device. It may for example be a device, a system and / or a suitable method for detecting the behavior of a user in the use of his medical device, for securing his use and / or to identify / authenticate the user.
  • Medical devices are becoming more and more intelligent. These devices are sometimes designed to meet multiple needs and they offer many features to improve the patient's life and facilitate treatment.
  • current health models push the patient to become more and more involved in his therapy.
  • the patient is required to control / command his medical device himself. This has many advantages, but can be dangerous in several ways.
  • a medical device such as an insulin pump
  • Overdose can take place in different cases, for example:
  • a patient error for example a poor estimate of the carbohydrates ingested during a meal
  • the requests sent by the remote device to control the medical device are requests requested by the user (for example the patient)
  • a remote device for example his phone
  • the remote device is a cellular telephone which can be a market telephone, which is not configured as basic to communicate with a medical device.
  • the present document discloses a device, a system and / or a method adapted to overcome the drawbacks described above.
  • the disclosure relates to a medical system used by a user comprising at least one of the following: an input device (which may be a sensor), a memory device and a processor.
  • the processor is preferably operatively coupled to the input device and / or the memory device.
  • the processor is configured to perform at least one of the following actions:
  • a second piece of data or set of data from the memory device (for example a model or historical data),
  • One or more of these steps can be initialized upon receipt of a request, for example by the user.
  • the objective of these steps is to secure the use of the medical system and / or secure the patient's treatment.
  • the input device may or may include: One button, keyboard, man-machine interface,
  • An optical sensor (camera, infrared, brightness, %)
  • a sound sensor (microphone, sound level meter, ...
  • a displacement sensor (accelerometer, inertial, gyroscope, inclinometer, 7), A time sensor (clock, stopwatch, %)
  • a position sensor (geolocation, geofencing, altimeter, %), ...
  • a second piece of data or set of data for example from a memory device (for example a model or historical data),
  • a first aspect of the disclosure relates to a medical system adapted to identify a user comprising:
  • a memory device to store a behavior model
  • a sensor configured to observe user behavior (using the medical system) and
  • a processor operatively coupled to the memory device and the sensor
  • processor is configured to
  • the medical system may include an input device configured so that the user can order a request.
  • the processor can also be configured to receive a user-controlled request via the input device.
  • the medical system can be configured to initialize user identification as soon as a request is entered.
  • the medical system (for example the processor) can be configured to initialize the identification of the user after (or as soon as) reception of the data relating to a behavior of the user.
  • the medical system (for example the processor) can be configured to record at least one data transmitted by the sensor relating to the behavior of the user (for example in the memory device).
  • the medical system (for example the processor) can be configured to create or adapt the behavior model:
  • a computer program product for example of the machine learning type
  • one or more behavior records preferably by taking into account the results of at least one previous identification action.
  • the identity validation step depends on the result of the analysis step.
  • the result of the analysis can include Boolean data (true / false; yes, no), a score or a probability that the user is a user authorized to use the medical system.
  • the behavior model can include a set of data relating to the behavior of an authorized or unauthorized user. It can be a generic or user-defined template.
  • the behavior model can evolve over time and learn user behaviors thanks, for example, to the data transmitted by the sensor.
  • a behavior can be any data relating to a distinctive sign of the user (physical, behavioral, 7) which preferably can be measured by the sensor or a set of sensors.
  • a behavior can be the way to manipulate, use or place the medical system (its inclination, activity, ).
  • the user may be used to using their medical system at a fixed time, in this case when using it at a usual time slot, the system may conclude that the user is the authorized user.
  • the medical system is used at 3 am while the user does not usually use his medical system from midnight to 6 am, then the medical system will conclude that it is very unlikely that he is the authorized user.
  • the medical system can conclude that the user has not been identified as the authorized user.
  • the system can then request user authentication or validation.
  • the behavior can also be the way of holding the medical system (tilt, ...) and ordering a request, ... For example if the authorized user has the habit of ordering a certain request (for example ordering a bolus of 3U after a meal) but this time it is another request (30 U) then the system can conclude that the identification is not validated and it can request authentication or validation.
  • the medical system includes a smart watch and this smart watch is removed from the authorized user and then returned to a user (whose identity is still unknown).
  • the medical system can conclude that the identity of the authorized user is not validated and thus it can request an authentication (for example to enter a PIN code).
  • the behavior is the removal of the smart watch, the behavior model can include a recognizable action list (here removal and reinstallation on a user).
  • the sensor is suitable for measuring the user's heart rate
  • the user can be identified by his heart rate, the behavior here will then be the heart rate.
  • the medical system can use this data to identify the user.
  • Identity can also be done via an optical sensor (a camera), for example if the authorized user is used to having a certain facial expression.
  • the morphology of the face and / or the different expressions can be recognized by the system so as to identify the user with a certain level of probability. If the probability is greater than a certain threshold, for example 80%, then the identity can be validated, otherwise authentication may be required to validate the identity of the user.
  • the behavior model may include a set of data relating to the faces of the user or facial expression making it possible to recognize the user.
  • a second aspect of the disclosure relates to a method associated with the embodiment described above, for example a method for identifying a user of a medical system comprising the following steps:
  • the method can further comprise at least one of the following steps:
  • a third aspect of the disclosure relates to a medical system adapted to identify an environment in which the medical system is used by a user comprising:
  • a memory device for storing data relating to an environment model (for example a secure environment),
  • a sensor configured to acquire data relating to a current environment
  • a processor operatively coupled to the memory device and the sensor
  • processor is configured to
  • Receive data relating to the current environment transmitted by the sensor Analyze the current environment by taking into account the data (for example by comparing it with the data) relating to the environment model recorded in the memory device,
  • a secure environment can be a place or situation where the user can be safe to use their medical system.
  • an unsecured environment can be a place or a situation where the user would not be safe to use their medical system because they risk making a mistake or not being attentive enough to its handling.
  • a secure place can be a quiet place, a familiar place (the user's home, ...), a hospital, a doctor's office, a pharmacy or any similar place.
  • the medical system can use one or more sensors to identify this location or situation.
  • the medical system can measure:
  • noise for example in an environment that is too noisy the user may be distracted and he may therefore be mistaken as to the use of his system, ...
  • the brightness via an optical sensor: the brightness, ... (for example if there is too high a brightness the user can be dazzled, ...)
  • a communication device capable of determining the presence of a known known network (for example the SSID of the home wifi), here this type of device can be used as a sensor because it picks up, recognizes or measures a network signal,
  • time sensor clock, timer, ...
  • Analysis of the current environment can help determine the type of environment (secure or not) using sensor data and the environment model saved in the memory device.
  • the step of determining the type of environment depends on the result of the analysis step.
  • the analysis result can include Boolean data (true / false; yes, no), a score or a probability that the environment is identified as secure or not.
  • the environment model can include a set of data making it possible to identify a place or a situation (secure or not).
  • the environment model can be generic or adapted to the user.
  • the medical system can be configured to allow setting of the environment model (for example if decibel greater than 70 dB, then unsecured environment).
  • the medical system may include a computer program product which allows the position and movement of the system to be monitored and action to be taken if the position or movement deviates from certain predetermined values (e.g. home or office) hospital, medical office, .
  • the medical system may include an input device configured so that the user can order a request.
  • the processor can also be configured to receive a user-controlled request via the input device.
  • the medical system can be configured to initialize the environment identification as soon as a request is entered.
  • the medical system (for example the processor) can be configured to initialize the identification of the environment after (or as soon as) reception of the data relating to the environment.
  • the medical system (for example the processor) can be configured to record at least one data transmitted by the sensor relating to the environment (for example in the memory device).
  • the medical system (for example the processor) can be configured to create or adapt the environment model:
  • the medical system can request authentication or validation of the request. For example, the medical system may ask to validate the request, enter a pin code or re-enter the request so as to make the user more attentive to his request when he is in an unsecured environment.
  • the medical system may conclude that the situation or the environment is insecure because probably anxiety-provoking if the measured heart rate is unusually high.
  • the medical system includes a remote control and a medical device
  • the medical system must be able to conclude that this is an unsecured situation. Indeed, it is very likely that the remote control is placed on a table and that any request from the remote control under these conditions is certainly unintentional.
  • the medical system can conclude that it is an unsecure environment because it is very likely that the remote control is in a bag and that the request is unintentional.
  • a fourth aspect of the disclosure relates to a method associated with the embodiment described above, for example a method for identifying an environment in which a medical system is used by a user comprising the following steps:
  • Analyze the current environment by taking into account the data (for example by comparing it to the data) relating to an (secure) environment model, Determine whether the current environment is a secure environment or not depending on the result of the analysis.
  • the observation step may include a step of receiving data transmitted by a sensor relating to the current environment of the medical system.
  • the method can further comprise at least one of the following steps:
  • a fifth aspect of the disclosure relates to a secure medical system adapted to execute a request controlled by a user comprising:
  • a memory device to store a behavior model
  • An input device configured to allow the observation of a user's behavior (using the medical system) and
  • a processor operatively coupled to the memory device and the input device
  • processor is configured to:
  • Plausibility may be the probability that:
  • the processor can also be configured to:
  • the security level can force the user to perform one or more (additional) steps (enter PIN code, ...) and / or can include several steps.
  • additional steps entity PIN code, ...) and / or can include several steps.
  • the lower the level of plausibility the higher the level of security may be. For example, if the plausibility level is extremely low, the medical system could ask the user to re-enter the request and / or request a strict authentication step (facial recognition, fingerprint, personal question, 7) whereas if the level of plausibility is medium a simple PIN code could suffice.
  • the medical system will be able to assess the probability of this request based on a behavior model known by the medical system.
  • the medical system will be able to assess the probability that this behavior is habitual / routine or not, based on a model of behavior known by the medical system.
  • the input device can include:
  • a human-machine (user-system) interface such as buttons, a touch screen or actuators that can be configured to enter a request in the medical system,
  • a captor
  • a sound sensor (microphone, sound level meter, ...
  • a displacement sensor (accelerometer, inertial, gyroscope, inclinometer, %)
  • a position sensor (geolocation, geofencing, altimeter, %)
  • the medical system can be configured to set the level of plausibility as soon as a request is entered or as soon as the user performs unusual behavior.
  • the medical system (for example the processor) can be configured to initialize the determination of the level of plausibility after (or as soon as) reception of the data relating to a behavior of the user.
  • the medical system (for example the processor) can be configured to record at least one data transmitted by the input device relating to the behavior of the user (for example in the memory device).
  • the medical system (for example the processor) can be configured to create or adapt the behavior model:
  • a computer program product for example of machine learning type
  • behavior records preferably taking into account the results of at least one previous analysis step.
  • the step of determining the plausibility level depends on the result of the analysis step.
  • the result of the analysis can include Boolean data (true / false; yes, no), a score or a probability.
  • the behavior model can include a set of data relating to the behavior of an authorized or unauthorized user. It can be a generic or user-defined template. The behavior model can evolve over time and learn user behavior, for example through the data transmitted by the input device.
  • a behavior can be any data relating to a distinctive sign of the user (physical, behavioral, 7) which preferably can be measurable by the sensor or a set of sensors or recognizable by its action (command of a request or not ).
  • a behavior can be the way to manipulate, use or place the medical system (its inclination, activity, ).
  • the user may be used to using his medical system at a fixed time, in this case when he is used during a usual time slot, the system can conclude that the user has respected his treatment and thus he can agree to execute the request without asking for other actions or by minimizing the level of security
  • the medical system can assess the probability that it is an oversight and can consequently encourage (via an alarm or a display on a screen) the user to respect his treatment. If the medical system includes a screen, the system may display "you should think about doing " or "remember to move” or "it is time to do --- ...
  • the medical system is used at 3 am while the user does not usually use his medical system from midnight to 6 am, then the medical system will conclude that it is very unlikely that he is an intentional motion.
  • the medical system can conclude that there is a high probability that the user is not authorized (or not used to) order such a request or require a higher level of security or request confirmation to encourage the user to be aware of their request.
  • the medical system includes a remote control and a medical device
  • the medical system must be able to conclude that the plausibility that the user entered this request is low because it it is very likely that the remote control is placed on a table and that any request from the remote control under these conditions is certainly unintentional.
  • the medical system should refuse any request or require one or more additional steps to execute such a request because it is very likely that the remote control is in a bag and that the user has ordered an unintentional request.
  • the system can compare this command to the behavior model to check the plausibility of this command.
  • the system can then ask for confirmation by highlighting the order and requesting a PIN code or request to re-enter the order or by informing the user by displaying: "it is likely that you entered 33U by mistake instead 3U ”or“ please confirm that you want to order 3000mL and not 300mL ”...
  • a sixth aspect of the disclosure relates to a method associated with the embodiment described above, for example a method for validating the execution of a request ordered by a user according to his behavior comprising the following steps:
  • Analyze user behavior by taking into account a behavior model (for example by comparing it to a behavior model) and Define a level of plausibility of the request according to the result of the analysis.
  • the observation step may include a step of receiving data transmitted by an input device relating to user behavior.
  • the method can also comprise at least one of the following steps: Execute the user's request according to the plausibility level defined in the previous step,
  • a seventh aspect of the disclosure relates to a secure medical system adapted to define a level of security necessary to execute a request (controlled by a user) comprising:
  • a memory device to store a behavior model
  • An input device configured to observe user behavior and A processor operatively coupled to the memory device and the input device;
  • processor is configured to
  • Behavioral data may include a query entered by the user.
  • the system may request:
  • a trusted third party device such as a token, Facial recognition,
  • One or more authentications ...
  • the more the behavior analyzed is removed from the behavior model the more the level of security required will be important, restrictive or require a level of strict authentication. Conversely, the closer the behavior analyzed is to the behavior model, the lower the level of security required.
  • An eighth aspect of the disclosure relates to a method associated with the embodiment described above, for example a method for defining a level of security necessary for executing a request comprising the following steps:
  • User behavior may include a request entered by the user.
  • a ninth aspect of the disclosure relates to a secure medical system adapted to define a level of security according to the environment of the medical system comprising:
  • a memory device for storing data relating to an environment model
  • a sensor configured to acquire data relating to the current environment of the medical system
  • a processor operatively coupled to the memory device and the sensor
  • processor is configured to
  • Receive data relating to the current environment transmitted by the sensor Analyze the current environment by taking into account the data (for example by comparing it with the data) relating to the environment model recorded in the memory device and Define a level of security adapted to the adapted environment based on the result of the analysis.
  • the system may request:
  • a trusted third party device such as a token
  • One or more authentications ...
  • the more the environment analyzed is removed from the model of a secure environment the more the required level of security will be important, restrictive or will require a level of strict authentication. Conversely, the closer the environment analyzed is to the model of a secure environment, the lower the level of security required.
  • a secure environment can be a place or situation where the user can be safe to use their medical system.
  • an unsecured environment can be a place or a situation where the user would not be safe to use their medical system because they risk making a mistake or not being attentive enough to its handling.
  • a secure place can be a quiet place, a familiar place (the user's home, ...), a hospital, a doctor's office, a pharmacy or any similar place.
  • the medical system can use one or more sensors to identify this location or situation.
  • the medical system can measure:
  • noise for example in an environment that is too noisy the user may be distracted and he may therefore be mistaken as to the use of his system, ...
  • the brightness via an optical sensor: the brightness, ... (for example if there is too high a brightness the user can be dazzled, ...)
  • a communication device capable of determining the presence of a known known network (for example the SSID of the home wifi), here this type of device can be used as a sensor because it picks up, recognizes or measures a network signal,
  • time sensor clock, timer, ...
  • Analysis of the current environment can make it possible to determine the type of environment (secure or not) using the sensor data and the environment model saved in the memory device.
  • the result of the analysis can include Boolean data (true / false; yes, no), a score or a probability that the environment is identified as secure or not.
  • the environment model can include a set of data making it possible to identify a place or a situation (secure or not).
  • the environment model can be generic or adapted to the user.
  • the medical system can be configured to allow setting of the environment model (for example if decibel greater than 70 dB, then unsecured environment).
  • the medical system may include a computer program product which allows the position and movement of the system to be monitored and action to be taken if the position or movement deviates from certain predetermined values (e.g. home or office) hospital, medical office, .
  • the medical system may include an input device configured so that the user can order a request.
  • the processor can also be configured to receive a user-controlled request via the input device.
  • the medical system can be configured to initialize the environment identification as soon as a request is entered.
  • the medical system (for example the processor) can be configured to initialize the identification of the environment after (or as soon as) reception of the data relating to the environment.
  • the medical system (for example the processor) can be configured to record at least one data transmitted by the sensor relating to the environment (for example in the memory device).
  • the medical system (for example the processor) can be configured to create or adapt the environment model:
  • a computer program product for example of machine learning type
  • a computer program product for example of machine learning type
  • the medical system can request authentication or validation of the request. For example, the medical system may ask to validate the request, enter a pin code or re-enter the request in order to make the user more attentive to his request when he is in an insecure environment.
  • the medical system may conclude that the situation or the environment is insecure because probably anxiety-provoking if the measured heart rate is unusually high.
  • a secure environment can be a place or situation where the user can be safe to use their medical system.
  • an unsecured environment can be a place or a situation where the user would not be safe to use their medical system because they risk making a mistake or not being attentive enough to its handling.
  • a secure place can be a quiet place, a familiar place (the user's home, ...), a hospital, a doctor's office, a pharmacy or any similar place.
  • the medical system can use one or more sensors to identify this location or situation.
  • the medical system can measure:
  • noise for example in an environment that is too noisy the user may be distracted and he may therefore be mistaken as to the use of his system, ...
  • the brightness via an optical sensor: the brightness, ... (for example if there is too high a brightness the user can be dazzled, ...)
  • a communication device capable of determining the presence of a known known network (for example the SSID of the home wifi), here this type of device can be used as a sensor because it picks up, recognizes or measures a network signal,
  • time sensor clock, timer, ...
  • Analysis of the current environment can help determine the type of environment (secure or not) using sensor data and the environment model saved in the memory device.
  • the step of determining the type of environment depends on the result of the analysis step.
  • the analysis result can include Boolean data (true / false; yes, no), a score or a probability that the environment is identified as secure or not.
  • the environment model can include a set of data making it possible to identify a place or a situation (secure or not).
  • the environment model can be generic or adapted to the user.
  • the medical system can be configured to allow setting the environment model (for example if decibel greater than 70 dB, then unsecured environment).
  • the medical system may include a computer program product that monitors the position and movement of the system and takes action if the position or movement deviates from certain predetermined values (e.g. home or office). hospital, medical office, .
  • the medical system may include an input device configured so that the user can order a request.
  • the processor can also be configured to receive a user-controlled request via the input device.
  • the medical system can be configured to initialize the environment identification as soon as a request is entered.
  • the medical system (for example the processor) can be configured to initialize the identification of the environment after (or as soon as) reception of the data relating to the environment.
  • the medical system (for example the processor) can be configured to record at least one data transmitted by the sensor relating to the environment (for example in the memory device).
  • the medical system (for example the processor) can be configured to create or adapt the environment model:
  • a computer program product for example of machine learning type
  • a computer program product for example of machine learning type
  • the medical system can request authentication or validation of the request. For example, the medical system may ask to validate the request, enter a pin code or re-enter the request so as to make the user more attentive to his request when he is in an unsecured environment.
  • the medical system may conclude that the situation or the environment is insecure because probably anxiety-provoking if the measured heart rate is unusually high.
  • the medical system includes a remote control and a medical device
  • the medical system must be able to conclude that it is an unsecured situation and can therefore require a higher level of security. Indeed, it is very likely that the remote control is placed on a table and that any request from the remote control under these conditions is certainly unintentional.
  • the medical system conclude that it is an unsecured environment because it is very likely that the remote control is in a bag and that the request is unintentional, the medical system can then request a level of security in order to confirm the request or make the user attentive to the request. All or part of the functionalities, steps or characteristics described in the other aspects of the disclosure of this document can be understood in an embodiment of this aspect of the disclosure.
  • a tenth aspect of the disclosure relates to a method associated with the embodiment described above, for example a method for defining a level of security as a function of the environment of the medical system comprising the following steps:
  • Analyze the current environment by taking into account the data (for example by comparing it with the data) relating to an environment model and
  • An eleventh aspect of the disclosure relates to a computer program product comprising:
  • an observer agent configured to generate information relating to the current behavior of the user on the basis of data transmitted by at least one input device (for example a sensor);
  • a comparator agent configured to compare information relating to the user's current behavior with a behavior model
  • an evaluator configured to assign the observed behavior to a zone of confidence based on the result of the comparator or to determine the identity of the user based on the result of the comparator.
  • a twelfth aspect of the disclosure relates to a computer program product comprising:
  • an observer agent configured to generate information relating to the current environment of the user on the basis of data transmitted by at least one input device (for example a sensor);
  • a comparator agent configured to compare information relating to the user's current environment with one or more environment models; and an evaluator configured to assign the observed environment to a confidence zone based on the result of the comparator or to determine the type of environment of the user based on the result of the comparator.
  • Figure 1 shows schematically a medical system according to one embodiment.
  • Figure 2 shows schematically a medical system according to one embodiment.
  • Figure 3 shows schematically a medical system according to one embodiment.
  • Figure 4 shows schematically a flow diagram of the process according to one embodiment.
  • Figure 5 shows a flow diagram of the process according to one embodiment.
  • Figure 6 shows a flow diagram of the process according to one embodiment.
  • Figure 7 shows a flow diagram of the process according to one embodiment.
  • Figure 8 shows schematically a flow diagram of the process according to one embodiment.
  • Figure 9 shows schematically a flow diagram of the process according to one embodiment.
  • sensor is generally used in a broad sense including “device transforming the state of an observed quantity into a usable quantity, for example an electric voltage, a height of mercury, an intensity or the deviation of a needle” unless the context clearly indicates another meaning.
  • observed quantity does not mean that it is necessary observable by a human being, example of observed quantity (not observable by the human being) radiation, magnetic fields, waves, IR, ...
  • current user in this document means the user who is currently using / manipulating the system or when the input device observed the behavior of the user.
  • current environment in this document means the environment in which the system is currently located or at the time when the input device observed the environment of the system.
  • the term "identify” is generally used in a broad sense, including the action of establishing the identity of a user or a system.
  • the term “authenticate” is generally used in a broad sense including notably the action which allows the user or the system to provide proof of his identity, it is thus a security action stronger than the 'identification.
  • system (1) can comprise at least one of the following elements:
  • Figure 1 is only an illustration of the system, the lines and delimitations should not be understood in a strict sense for example all or part of the devices may be distinct from other devices but the whole forms the system. It is noted that an input device can be a sensor.
  • the input device (2) can include a keyboard, buttons, a tactile graphical interface, ...
  • the system can include one or more input devices operatively coupled to the analysis device (3) .
  • the sensor can be or include:
  • An optical sensor (camera, infrared, brightness, %)
  • a sound sensor (microphone, sound level meter, ...
  • a displacement sensor (accelerometer, inertial, gyroscope, inclinometer, %)
  • a time sensor (clock, stopwatch, %)
  • a biometric sensor fingerprint, sensor for measuring a patient's fluid (for example blood sugar, ...) and / or
  • a position sensor (geolocation, geofencing, altimeter, %), ...
  • the system may include one or more sensors operatively coupled to the analysis device (3).
  • the concept of sensor is general here, this term is used to lighten the reading. It may be a measurement and / or detection device which may include a circuit electronic and combining several sensors or type of sensor so as to detect / measure the type of data desired.
  • the input device (2) and / or the sensor (4) can be configured to inform the system (1) about the behavior of the user and / or the environment of the medical system.
  • the analysis device (3) may include a processor (5) and / or a memory device (6).
  • the processor (5) can be configured to operate an embedded computer program.
  • the memory device (6) can be configured to store a set of data such as security rules, a behavior model, processing parameters, data relating to the analysis of data sent by a sensor and / or the data entered by the input device.
  • the analysis device (3) can be configured to:
  • the system may further include a medical device (7) connected to the patient (8).
  • the medical device may be a delivery device (of a drug solution such as insulin, hormone, analgesic, ...) and / or a measurement device (blood sugar, blood pressure, %) and / or other device acting for the health or well-being of a patient (respiratory aid, dialysis, ).
  • the system can be configured to:
  • the analysis device when the user enters a request via the input device, the analysis device will analyze a certain number of parameters (such as: environmental, vital signs, or behavioral, etc. ) using data from the input device and / or the sensor in order to identify the user or the environment or determine a plausibility level or determine an appropriate security level. After this analysis, the medical system may or may not validate the request or request additional authentication to initialize the request.
  • a certain number of parameters such as: environmental, vital signs, or behavioral, etc.
  • the order can be sent to the medical device (which can be a delivery device) for execution with a low level of security (with or without confirmation and / or validation).
  • the order can only be sent to the delivery device for execution after an additional or more stringent authentication procedure.
  • Figure 2 shows a medical system (1) comprising a medical device (10) and a remote device (1 1).
  • the medical device (10) and the remote device (1 1) are configured to exchange data via wired / wireless communication (12).
  • the medical device (10) and / or the remote device (1 1) comprise at least one security device as described above and a communication device.
  • the remote device can be a device for controlling or commanding the medical device. It can be among others a remote control, a computer, a tablet, a phone, ...
  • the remote device can include an input device and / or all or part of the analysis device.
  • the medical device may include a delivery device, an input device and / or all or part of the analysis device.
  • the remote device (1 1) is a generic or standard device, that is to say not dedicated to the medical device (10).
  • the remote device can be a telephone, a remote control (wireless), a remote server, etc.
  • the remote device is suitable for exchanging data securely with the medical device (10) via wireless communication (12).
  • the remote device may include a processor (13), a memory device (14), a communication device (15) and / or one or more key (s) (or button (s)) (17).
  • the remote device (1 1) may further comprise a screen (16) configured to display data relating to the medical device (10), for example control instructions (bolus, suspension, basal, ...), information of state of the medical device, information concerning the activities of the system, ...
  • the screen can be a touch screen and the keys or buttons can be virtual.
  • the remote device (1 1) may further include one or more sensors (18).
  • This sensor can be at least the following sensors: motion sensor (gyroscope, accelerometer, inertial displacement sensor, inclinometer, linear displacement sensor), geolocation sensor (by triangulation of mobile phone antennas, wifi, GPS, ... ), a camera, a microphone, a biometric sensor, or any other sensor listed in this document.
  • the medical device (10) can be configured to deliver a substance to a patient (for example a drug, a pharmaceutical product, a medical liquid, protein, supplement, analgesics, anti-inflammatories, ...), to measure data relating to the patient (for example, blood sugar, blood pressure, heart rate, ...) and / or to perform other health actions (such as pacemaker, artificial organ ).
  • the medical device (10) may include a processor (13), a memory device (14), a communication device (15) and / or one or more key (s) (or button (s)) (17).
  • the medical device (10) may include a screen but if the remote device already has one then this screen is optional. However, the medical device may further include a visual, audible and / or vibrating indicator (16 ').
  • the medical device (10) may further include one or more sensors (18).
  • the processor (13) of the remote device or the medical device can be configured to execute all or part of the instructions of the computer program as described in the document.
  • the processor of the remote device can execute all or part of the instructions of the analysis device and the medical device can execute all or part of the instructions of the analysis device.
  • the medical system may include an environment sensor configured to measure data relating to the environment or the current situation in which the system is located and an analysis device configured to analyze / monitor the environment in which the system based on the data from the environment sensor is located.
  • the analysis device can also find an environment model saved in a memory device (in the medical system or in a remote server) and compare this environment model with data from the environment sensor.
  • the analysis device can also be configured to determine a security level based on the analysis result (s).
  • the environment sensor can be a geolocation sensor making it possible to geo-locate the system, a microphone making it possible to measure an ambient sound level (if the sound level is too high then the system can request authentication or confirmation from the user to alert the patient in the event of an order), a wifi sensor (for example a wifi antenna so as to determine whether the wifi antenna is connected to a usual router (home or office)), ...
  • the environment sensor can make it possible to determine whether or not the user is within a predefined perimeter (geofencing method).
  • the objective is to allow the system to know if the user's request (interrogation of the medical device, order for delivery or action, ...) was made in a reliable, secure, usual environment and where the the user is not likely to be distracted by his environment.
  • the medical system may include a sensor configured to detect manipulation of the medical system such as the remote device (Remote control / telephone) and an analysis device configured to analyze / monitor user behavior based on motion sensor data.
  • the analysis device can also find a behavior model recorded in a memory device (in the medical system or in a remote server) and compare this behavior model with motion sensor data.
  • the analysis device can also be configured to determine a security level as a function of the analysis result (s).
  • a generic behavior model can represent the average behavior of users, constructed from statistical data on a large group of users or constructed from heuristic methods.
  • the model to be loaded initially would be chosen according to the (automatic) classification of the user in one of its subgroups, according to data of inputs provided by the user during the initialization of the device (age, therapy, user experience level, type of patient (Type 1 or 2 for diabetes), ).
  • the recognition of behavior and the comparison of this behavior to a behavior model can be based on old behaviors of the user (or based on a generic model). It can be configured to detect atypical user behavior, that is to say different from usual behavior or generic behavior.
  • the medical system may include a device for learning the behavior of the patient so as to check whether a behavior of the patient conforms to his habits.
  • This learning system also makes it possible to adapt the behavior model or the environment model. Among other things, it can be a machine learning algorithm suitable for learning patient behavior.
  • the system may request additional validation to validate the behavior.
  • the concept of behavior can be broad, within the framework of the treatment of diabetes (but not only), it can be a question of meal schedule, quantity of meal, type of meal, time of an activity physical activity, duration of physical activity, intensity of physical activity, patient's blood sugar, amount of solution (such as insulin or other solution) ordered for a bolus, for a basal, a type of bolus (elongated, normal, dual wave, ...), or any other behavior relating to the manipulation of the system (For example: time spent in each step / menu page, rhythm of keyboard input, exact position of a "click" on a touch screen) or behavior related to processing ...
  • patient therapy data can be used to identify behavior and learn what the patient's habits are.
  • This data can be for example:
  • the learning device can also learn from previous patient errors. For example, if the patient makes a frequent input error, the system can ask the patient for confirmation each time this error is repeated.
  • the learning device can comprise a computer program product configured to recognize whether a manipulation of the medical system corresponds to a predefined manipulation and recorded in a memory of the system so as to define a level of conformity / plausibility with a model of behavior.
  • the computer program product can be adapted to compare new behavior with old behavior to define the level of security and / or to modify the behavior model.
  • the computer program product when loaded into the medical system, can execute at least one of the following steps:
  • update the behavior model from a new behavior record taking into account the result of a potential confirmation request.
  • the computer program product is suitable for retrieving in a memory the recording data of old behaviors or of the behavior model.
  • a machine learning based system can be used to detect behavior that is habitual or unusual for this patient.
  • the computer program can react to atypical demand by various means, for example
  • Request additional authentication e.g., “Unusual action detected: please confirm by entering your pin / with a fingerprint / recognition side, etc.).
  • FIG. 4 illustrates an example of the basic operation of such a system.
  • User actions are evaluated by a behavior model, which may have been created by machine learning methods from the history of user actions (or a generic behavior model), as plausible or not plausible. If the action is assessed as plausible, it is applied. If it is assessed as implausible, the system asks the user to confirm the action before applying it.
  • the device can access an evaluation of the quality of the treatment (either calculated by the device from measurements of the patient's physiological state, or provided by the patient himself or by the medical staff), this data could be used to enrich the behavior model with the notion of “risky” or “non-risky” behavior in addition to the notion of “plausibility”.
  • Failure to use the System can also be considered unusual behavior (a certain amount of time without use, failure to use on a certain time slot).
  • the device could manifest itself as an alarm or a notification to the user by another means of communication (smartphone).
  • FIG. 5 Another example of the operation of the system is shown in the diagram in FIG. 5, based on the same concept as in FIG. 4 but whose objective is the identification of the user.
  • FIG. 6 Another example of the operation of the system is shown in the diagram in FIG. 6, based on the same concept as in FIG. 4 but whose objective is the identification of the environment.
  • the system can be configured to adjust the security level as a function of this behavior (of the present behavior) or as a function of the result of the detection.
  • usual behavior will make it possible not to ask for authentication (PIN code, ...) or for confirmation (for example: “are you sure ! or “please confirm !) or to ask only confirmation but no authentication.
  • atypical behavior will encourage the system to ask for at least confirmation and / or authentication.
  • the security level can be gradual, so in the extreme case, the system could request several authentications and confirmation, for example a confirmation followed by a PIN and an authentication of the user's fingerprint.
  • the behavior detected is for example a PIN error
  • the system can request another type of authentication, for example a fingerprint.
  • An alternative implementation would be to always request authentication for dangerous actions, and additional confirmation for atypical actions, in this
  • the system could be configured to highlight the atypical behavior detected in order to expose the user to the atypical behavior detected and to ask for confirmation (via for example a single display or a succession of displays).
  • the system could display on the screen "you have configured ... then as usual you have configured " as well as "please confirm the parameter” or "please confirm the parameter by re-entering the desired parameter” . This can force the user to be aware of the potential error and have to rewrite if the parameter is the one desired.
  • the medical system and / or the learning device may comprise a processor coupled to a screen, an input device (for example a keyboard, buttons, sensors, a touch screen, etc. ) and a memory.
  • the processor is preferably configured to recognize and / or define behavior based on the data entered via the input device.
  • the processor can be configured to determine a level of plausibility for behavior and a level of security based on the level of plausibility.
  • the system can be configured to display an authentication or validation request on the screen.
  • FIG. 7 illustrates an example of the basic operation of such a system.
  • User actions are evaluated by a behavior model, which may have been created by machine learning methods from the history of user actions (or a generic model). The analysis makes it possible to determine a level of security necessary to apply the action. If the security level is low because it is a standard user behavior then (for example) no other action may be necessary to apply the action. If the security level is medium because it is a relatively standard behavior of the user then (for example) a simple validation step may be requested to apply the action. If the level of security is important because it is an unusual behavior of the user then the user will have to authenticate to apply the action (for example in addition to a validation step).
  • FIG. 8 Another example of the operation of the system is shown in the diagram in FIG. 8, based on the same concept as in FIG. 7 but whose objective is the identification of the environment.
  • the system is preferably portable, that is to say a self-powered device (by battery, solar collector or other) and whose size, weight and shape allows it to be manipulated by one hand of a user, which can for example entered the pocket of the user.
  • FIG. 9 Another example of system operation is shown in the diagram in Figure 9, based on the same concept as Figures 4, 5, 6, 7 and 8.
  • An initialization phase may be necessary for the system to create a model of typical user behavior. During this phase, all actions can be considered plausible or on the contrary potentially risky and require a high level of security. This initialization phase can be avoided by defining a generic behavior model as mentioned above. Several possibilities are possible for the model - Bayes Classifiers, Support vector machines, Gaussian mixture models, Artificial neural networks, etc.
  • an action if an action is considered plausible, it can be accepted (for example without asking for confirmation or with a weak authentication level) and it can enrich the behavior model.
  • additional validation may be requested from the user.
  • This validation can be a simple "yes / no” prompt, a PIN request, a fingerprint request, or other more advanced methods. If the additional validation fails (e.g., the user answers "no"), the action is not performed. Optionally, this action is taken into account in the model as a counterexample, in order to better detect false actions later.
  • the system can warn the patient that the planned dose is unusual. In this case, the patient has a better chance of seeing his error.
  • the system could ask the patient for confirmation that they want this type of bolus.
  • the system may request additional authentication, which would prevent a third party from executing therapy-related commands.
  • the system can detect an unusual action thanks to the behavior model, for example on the basis of an unusual schedule for using the remote control, unusual values of the input parameters or different handling (behavior, precise location of clicks, time spent on each screen), and may require additional authentication or validation.
  • the system can include a wireless communication device so as to be able to communicate with a remote server.
  • the system can be configured to perform data processing (behavior) by the system processor so that data processing is not dependent on the availability of a remote server or the connection to a server. distant.
  • the medical system may include a facial recognition device comprising an optical sensor (for example a camera) and a processor (for example the system processor) configured to perform treatment of the data sent by the optical sensor to recognize the user.
  • the user can be the patient himself or a caregiver (parent, doctor, nurse, ).
  • the system may include operating rules depending on the type of user. For example, a primary user can be a patient and another user can be a doctor with greater access rights. If the user is not the main user (for example the patient himself or the person who normally manages the treatment such as a parent, doctor, nurse, ...), then the system can ask additional authentication and / or confirmation as described above.
  • the system can additionally check the compliance with the treatment and the data of the patient before so as not to validate even in the event of strong plausibility.
  • the document also describes a security method for the execution of an order by a medical device, comprising the following steps:
  • an observation device including a sensor

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)

Abstract

Un système médical qui comprend un dispositif d'apprentissage des comportements du patient de manière à vérifier si un comportement du patient est conforme à ses habitudes. Préférentiellement si ce comportement n'est pas habituel ou atypique alors le système peut demander une validation supplémentaire pour valider le comportement. Il peut s'agir en autre d'un algorithme de machine learning adapté pour apprendre le comportement du patient.

Description

Dispositif médical sécurisé
Domaine de la divulgation
La divulgation concerne un dispositif, un système et/ou une méthode adapté(e)(s) pour contrôler de manière sécurisée un dispositif médical. Il peut s’agir par exemple d’un dispositif, d’un système et/ou d’une méthode adapté(e) pour détecter le comportement d’un utilisateur dans l’utilisation de son dispositif médical, pour sécuriser son utilisation et/ou pour identifier/authentifier l’utilisateur.
Etat de la technique
Les dispositifs médicaux deviennent de plus en plus intelligents. Ces dispositifs sont parfois conçus pour répondre à de multiple besoins et ils offrent nombreuses fonctionnalités permettant d’améliorer la vie du patient et faciliter son traitement. En outre, les modèles de santé actuelle poussent à ce que le patient devienne de plus en plus acteurs de sa thérapie. En particulier (mais pas uniquement), dans le cas de maladie chronique, le patient est amené à contrôler/commander son dispositif médical lui-même. Cela présente de nombreux avantages mais peut s’avérer dangereux sur plusieurs points.
Par exemple, un dispositif médical, comme une pompe à insuline, peut être dangereux pour le patient. Un surdosage peut avoir lieu dans différents cas, par exemple :
• Une fausse manipulation du dispositif,
• Une erreur du patient, par exemple une mauvaise estimation des glucides ingérés lors d’un repas,
• Une autre personne utilise la télécommande du patient,...
Pour pallier à ces problèmes, les solutions existantes sont :
• Limite des doses perfusées. Par exemple, dans le cas de l’insuline : limite maximale d’un bolus, du basal de la quantité journalière d’insuline, ... Toutefois, ces limites de doses perfusées ne sont pas suffisantes pour éviter une hypoglycémie. Mais imposer des limites plus strictes serait une solution trop limitante pour la thérapie du patient.
• Demande de confirmation de toutes les actions du patient. Toutefois, la confirmation des actions peut s’avérer insuffisante dans le cas où le patient fait une erreur, par exemple de la quantité de glucides ingérés : dans ce cas, le patient croit avoir besoin d’une dose trop importante alors que ce n’est pas le cas.
Ces solutions existantes imposent ainsi des barrières et des confirmations répétées pour parfois des actes mineurs sans grande importance. Cela conduit le patient à ne plus faire attention au message d’alerte ou de confirmation. Ainsi, le patient valide sans réellement vérifier. En plus d’avoir de nombreuses fonctionnalités liées au traitement, les dispositifs médicaux sont de plus en plus connectés à des dispositifs distants via une connexion sans fil. Que ce soit pour surveiller ou commander ces dispositifs médicaux, la communication entre ces deux dispositifs nécessite d’être sécurisé pour au moins deux raisons :
Garantir la confidentialité des données transmises et
S’assurer que les requêtes envoyées par le dispositif distant pour commander le dispositif médical sont bien des requêtes souhaitées par l’utilisateur (par exemple le patient)
Il y a dix ans, les dispositifs distants étaient simplement des télécommandes propriétaire, c’est- à-dire des télécommandes conçues et/ou fabriquées par la même société qui avait conçu et/ou fabriqué le dispositif médical. L’ensemble (dispositif médical et dispositif distant) formait un système médical sécurisé avec des protocoles de communication que seul le système pouvait connaître ou comprendre. De nos jours, les patients souhaitent limiter autant que possible les différents dispositifs de manière à limiter le nombre de dispositif à transporter ou pour limiter les risques liés à l’oubli, la perte ou la casse d’un de ces dispositifs. C’est pour cette raison que de nombreux systèmes médicaux comprennent des dispositifs distants génériques, tel qu’un téléphone de type smart phone. Toutefois, l’utilisation de dispositif distant générique engendre un problème de sécurisation de la transmission de données.
En effet, il est difficile de contrôler un dispositif médical avec un téléphone standard qui n’a pas été spécifiquement sécurisé ou adapté pour cette tâche, et qui peut se connecter au cloud pour échanger des données via une connexion internet, en se connectant aux réseaux sociaux ou en recevant des courriels. A travers ces échanges, le téléphone devient particulièrement vulnérable à des cyberattaques qui pourraient corrompre les données médicales et causer une programmation erronée du dispositif médical
Par contrôler de manière sécurisée, on entend au moins une des caractéristiques suivantes (liste non exhaustives) :
• Recevoir des données d’un dispositif qui sont authentiques et/ou qui correspondent aux valeurs figurant dans le mémoire du dispositif;
• Empêcher l’accès à ces données à toute personne, dispositif ou logiciel non-autorisé ;
• Afficher ces données sans qu’un tiers ait pu les modifier ou les corrompre ;
• Entrer une donnée et/ou être en mesure de la transmettre à la mémoire du dispositif sans qu’un tiers ait pu corrompre ou modifier cette donnée.
• S’assurer que c’est bien l’utilisateur du système (par exemple le patient) qui contrôle le dispositif médical depuis un dispositif distant (par exemple son téléphone), par exemple :
o Identifier l’utilisateur, et/ou
o authentifier l’utilisateur...
• S’assurer que la commande est intentionnelle et/ou non corrompue,...
Préférentiellement le dispositif distant est un téléphone cellulaire qui peut être un téléphone du marché, qui n’est pas configuré de base pour communiquer avec un dispositif médical.
Des solutions de sécurisation existent et sont décrites dans les demandes de brevet américain portant les numéros suivants : US 2014/0298022 A1 et US 2015/0207626 A1 . L’intégralité du contenu de ces demandes de brevet est intégrée par référence au présent document. Bien que ces solutions apportent une véritable sécurisation, elles imposent d’avoir une carte connectée au dispositif distant. L’objectif serait ainsi de parvenir à contrôler de manière sécurisé un dispositif médical via un dispositif distant avec un niveau de sécurisation au moins équivalent mais sans la carte.
Les constructeurs de téléphone ont également implémenté de couches de protection permettant de sécuriser les appareils depuis les couches basses des logiciels embarqués. Ces choix peuvent permettre l'utilisation de certains téléphones standards du marché pour le contrôle de dispositif tiers. Toutefois ces téléphones imposent à l’utilisateur d’importantes contraintes liées à la sécurité de leur utilisation, notamment l’utilisation de codes d’identification que le patient ne doit pas oublier. Si l’utilisateur oublie son code, il n’a plus accès au contrôle de son dispositif médical. Et enfin l’introduction d’un code faux peut bloquer temporairement l’accès au dispositif médical, voire définitivement dans certains cas. En outre, ces codes d’identification ne peuvent pas garantir parfaitement l’identité de l’utilisateur. Il suffit que le propriétaire du dispositif médical ait divulgué le code à un tiers pour que ce dernier puisse utiliser le code pour prendre le contrôle du système médical. En d’autres termes, l’utilisation de code de sécurité n’est pas satisfaisant.
Description générale de la divulgation
Le présent document divulgue un dispositif, un système et/ou une méthode adaptée pour pallier aux inconvénients décrits ci-avant.
De manière générale la divulgation se rapporte à un système médical utilisé par un utilisateur comprenant au moins un des éléments suivants : un dispositif d’entré (qui peut être un capteur), un dispositif de mémoire et un processeur. Le processeur est préférentiellement couplé de manière opérationnelle au dispositif d’entré et/ou au dispositif de mémoire. Selon certains modes de réalisation, le processeur est configuré pour effectuer au moins un des actions suivantes :
recevoir une première donnée ou ensemble de données en provenance du dispositif d’entré,
recevoir (ou récupérer) une deuxième donnée ou ensemble de données en provenance du dispositif de mémoire (par exemple un modèle ou des données historiques),
- Analyser la première donnée ou ensemble de données en prenant en compte la deuxième donnée ou ensemble de données (par exemple en comparant ces données), Identifier l’utilisateur et/ou l’environnement du système médical et/ou définir un niveau de sécuritaire adapté.
Une ou plusieurs de ces étapes peuvent peut être initialisée(s) lors de la réception d’une requête commandée par exemple par l’utilisateur. L’objectif de ces étapes est de sécuriser l’utilisation du système médical et/ou sécuriser le traitement du patient.
Le dispositif d’entré peut-être ou comprendre : Un bouton, clavier, interface homme-machine,
Un capteur optique (caméra, infra rouge, luminosité,...),
Un capteur sonore (microphone, sonomètre, ...
Un capteur de déplacement (accéléromètre, inertielle, gyroscope, inclinomètre,...), Un capteur temporel (horloge, chronomètre, ...)
Un capteur biométrique et/ou
Un capteur de position (géolocalisation, geofencing, altimètre, ...), ...
Une méthode associée à ce mode de réalisation peut comprendre les étapes suivantes :
recevoir une première donnée ou ensemble de données en provenance d’un dispositif d 'entré,
recevoir (ou récupérer) une deuxième donnée ou ensemble de données en provenance par exemple d’un dispositif de mémoire (par exemple un modèle ou des données historiques),
- Analyser la première donnée ou ensemble de données en prenant en compte la deuxième donnée ou ensemble de données (par exemple en comparant ces données), Identifier l’utilisateur et/ou l’environnement du système médical et/ou définir un niveau de sécuritaire adapté.
Un premier aspect de la divulgation porte sur un système médical adapté pour identifier un utilisateur comprenant :
Un dispositif de mémoire pour stocker un modèle de comportement,
Un capteur configuré pour observer un comportement de l’utilisateur (utilisant le système médical) et
Un processeur couplé de manière opérationnelle au dispositif de mémoire et au capteur ;
Dans lequel le processeur est configuré pour
Recevoir des données relatives à un comportement actuel de l’utilisateur transmises par le capteur,
Analyser le comportement actuel en prenant en compte le modèle de comportement (par exemple en le comparant au modèle de comportement) enregistré dans le dispositif de mémoire et
Valider ou non l’identité de l’utilisateur comme étant un utilisateur autorisé.
Le système médical peut comprendre un dispositif d’entré configuré pour que l’utilisateur puisse commander une requête. Le processeur peut également être configuré pour recevoir une requête commandée par l’utilisateur via le dispositif d’entré. Le système médical peut être configuré pour initialiser l’identification de l’utilisateur dès qu’une requête est entrée.
Le système médical (par exemple le processeur) peut être configuré pour initialiser l’identification de l’utilisateur après (ou dès) réception des données relatives à un comportement de l’utilisateur. Le système médical (par exemple le processeur) peut être configuré pour enregistrer au moins une donnée transmise par le capteur relative au comportement de l’utilisateur (par exemple dans le dispositif de mémoire).
Le système médical (par exemple le processeur) peut être configuré pour créer un ou adapté le modèle de comportement :
à partir d’un ou plusieurs enregistrements de comportement,
via un produit de programme informatique (par exemple de type machine learning), à partir d’un ou plusieurs enregistrements de comportement, préférentiellement en prenant en compte les résultats d’au moins une précédente action d’identification.
Préférentiellement, l’étape de validation de l’identité dépend du résultat de l’étape d’analyse. Le résultat de l’analyse peut comprendre une données booléennes (vrai/faux ; oui, non), un score ou une probabilité que l’utilisateur est un utilisateur autorisé à utiliser le système médical.
Le modèle de comportement peut comprendre un ensemble de données relatives aux comportements d’un utilisateur autorisé ou non. Il peut s’agir d’un modèle générique ou personnalisé à l’utilisateur. Le model de comportement peut évoluer dans le temps et apprendre les comportements de l’utilisateur grâce par exemple aux données transmises par le capteur.
Un comportement peut être toutes données relatives à un signe distinctif de l’utilisateur (physique, comportementale,...) qui préférentiellement peut être mesurable par le capteur ou un ensemble de capteur. Un comportement peut être la façon de manipuler, utiliser ou placer le système médical (son inclinaison, l’activité,...).
Par exemple, l’utilisateur peut avoir l’habitude d’utiliser son système médical à heure fixe, dans ce cas lors de son utilisation à une tranche horaire habituelle, le système peut conclure que l’utilisateur est l’utilisateur autorisé. Au contraire, le système médical est utilisé à 3 heures du matin alors que l’utilisateur n’utilise habituellement pas son système médical de minuit à 6 heures du matin, alors le système médical conclura qu’il est très peu probable qu’il s’agisse de l’utilisateur autorisé. Ainsi le système médical peut conclure que l’utilisateur n’est pas identifié comme étant l’utilisateur autorisé. Le système pourra alors demander une authentification de l’utilisateur ou une validation.
Le comportement peut être également la façon de tenir système médical (inclinaison,...) et de commander une requête,... Par exemple si l’utilisateur autorisé a l’habitude de commander une certaine requête (par exemple commander un bolus de 3U après un repas) mais que cette fois ci il s’agit d’une autre requête (30 U) alors le système peut conclure que l’identification n’est pas validé et il peut demander une authentification ou une validation.
Autre exemple, si le système médical comprend une smart Watch et que cette smart Watch est retirée de l’utilisateur autorisé puis remise sur un utilisateur (dont l’identité est encore inconnue). Le système médical peut conclure que l’identité de l’utilisateur autorisé n’est pas validé et ainsi il peut demander une authentification (par exemple d’entrer un code PIN). Le comportement ici est le retrait de la smart Watch, le modèle de comportement peut comprendre une liste d’action reconnaissable (ici retrait et réinstallation sur un utilisateur).
Autre exemple, si le capteur est adapté pour mesurer la fréquence cardiaque de l’utilisateur, l’utilisateur peut être identifié grâce à sa fréquence cardiaque, le comportement ici sera alors la fréquence cardiaque.
Autre exemple, si le système médical comprend un écran tactile et que l’utilisateur autorisé à l’habitude de toucher certaine(s) zone(s) de l’écran (par exemple à cause de la morphologie de sa main, ou de ses habitudes, s’il est gaucher, droitier,...), le système médical peut utiliser ces données pour identifier l’utilisateur.
L’identité peut également se faire via un capteur optique (une caméra), par exemple si l’utilisateur autorisé à l’habitude d’avoir une certaine expression du visage. La morphologie du visage et/ou les différentes expressions peuvent être reconnues par le système de manière à identifier l’utilisateur avec un certain niveau probabilité. Si la probabilité est supérieur à un certain seuil, par exemple 80%, alors l’identité peut être validé sinon une authentification peut être requise pour valider l’identité de l’utilisateur. Dans ce cas, le modèle de comportement peut comprendre un ensemble de données relatives aux visages de l’utilisateur ou expression de visage permettant de reconnaître l’utilisateur.
Tout ou partie des fonctionnalités, étapes ou caractéristiques décrites dans les autres aspects de la divulgation de ce document peuvent être comprise dans un mode de réalisation de cet aspect de la divulgation.
Un second aspect de la divulgation se porte sur une méthode associée au mode de réalisation décrit ci-avant, par exemple une méthode pour identifier un utilisateur d’un système médical comprenant les étapes suivantes :
Recevoir des données transmises par un capteur relatives à un comportement de l’utilisateur actuel utilisant le système médical,
Analyser le comportement de l’utilisateur actuel en prenant en compte un modèle de comportement (par exemple en le comparant à un modèle de comportement), Identifier ou non l’utilisateur comme étant un utilisateur autorisé à utiliser le système médical en fonction du résultat de l’analyse.
La méthode peut comprendre en outre au moins une des étapes suivantes :
Recevoir une requête de l’utilisateur,
Initialiser la méthode d’identification après (ou dès) réception des données relatives à un comportement de l’utilisateur ou après avoir reçu (ou suite à ou en conséquence de la réception d’) une requête de l’utilisateur,
Enregistrer au moins une donnée transmise par le capteur relative au comportement de l’utilisateur (par exemple dans un dispositif de mémoire),
Créer un ou adapté le modèle de comportement à partir d’un ou plusieurs enregistrements de comportement, Créer un ou adapté le modèle de comportement via une méthode de machine learning.
Créer un ou adapté le modèle de comportement à partir d’un ou plusieurs enregistrements de comportement, préférentiellement en prenant en compte les résultats d’au moins une précédente action d’identification ;
Exiger une étape d’authentification ou de validation en cas de défaut d’identification (utilisateur autorisé non identifié, utilisateur non autorisé identifié, ...).
Tout ou partie des fonctionnalités, étapes ou caractéristiques décrites dans les autres aspects de la divulgation de ce document peuvent être comprise dans la méthode de cet aspect de la divulgation.
Un troisième aspect de la divulgation porte sur un système médical adapté pour identifier un environnement dans lequel le système médical est utilisé par un utilisateur comprenant :
Un dispositif de mémoire pour stocker des données relatives à un modèle d’environnement (par exemple un environnement sécurisé),
Un capteur configuré pour acquérir des données relatives à un environnement actuel et
Un processeur couplé de manière opérationnelle au dispositif de mémoire et au capteur
Dans lequel le processeur est configuré pour
Recevoir des données relatives à l’environnement actuel transmises par le capteur, Analyser l’environnement actuel en prenant en compte les données (par exemple en le comparant aux données) relatives au modèle d’environnement enregistré dans le dispositif de mémoire,
Déterminer si l’environnement actuel est un environnement sécurisé.
Un environnement sécurisé peut être un lieu ou une situation où l’utilisateur peut être en toute sécurité pour utiliser son système médical. A l’inverse un environnement non sécurisé peut être un lieu ou une situation où l’utilisateur ne serait pas en sécurité pour utiliser son système médical car il risque de faire une erreur ou ne pas être suffisamment attentif à sa manipulation.
Par exemple, un lieu sécurisé peut être un lieu calme, un endroit familier (le domicile de l’utilisateur,...), un hôpital, un cabinet médical, une pharmacie ou tout lieu similaire. Le système médical peut utiliser un ou plusieurs capteurs pour identifier ce lieu ou situation. Le système médical peut mesurer :
via un capteur sonore : le bruit, le volume sonore,... (par exemple dans un environnement trop bruyant l’utilisateur peut être distrait et il peut ainsi se tromper quant à l’utilisation de son système, ...),
via un capteur optique : la luminosité, ... (par exemple s’il y a une trop forte luminosité l’utilisateur peut être ébloui, ...),
via un dispositif de communication (ou capteur de réseau) capable de déterminer la présence d’un réseau connu identifié (par exemple le SSID du wifi du domicile), ici ce type de dispositif peut être utilisé comme un capteur car il capte, reconnaît ou mesure un signal réseau,
via un capteur de localisation (géolocalisation,...),
via un capteur temporel : horloge, minuteur, ... (par exemple s’il est tard ou si l’utilisateur a reçu depuis peu une dose de médicament pouvant altérer son attention,...),
via d’autres capteurs...
L’analyse de l’environnement actuel peut permettre de déterminer le type d’environnement (sécurisé ou non) grâce aux données du capteur et au modèle d’environnement enregistré dans le dispositif de mémoire. Préférentiellement, l’étape de détermination du type d’environnement dépend du résultat de l’étape d’analyse. Le résultat de l’analyse peut comprendre une données booléennes (vrai/faux ; oui, non), un score ou une probabilité que l’environnement est identifié comme sécurisé ou non.
Le modèle d’environnement peut comprendre un ensemble de données permettant d’identifier un lieu ou une situation (sécurisé ou non). Le model d’environnement peut être générique ou adapté à l’utilisateur. Le système médical peut être configuré pour permettre de paramétrer le modèle d’environnement (par exemple si décibel supérieur à 70 dB, alors environnement non sécurisé).
Le système médical peut comprendre un produit de programme informatique qui permet de surveiller la position et le déplacement du système et de prendre des mesures si la position ou le déplacement s'écarte de certaines valeurs fixées d'avance (par exemple le domicile ou l’hôpital, le cabinet médical, ...).
Le système médical peut comprendre un dispositif d’entré configuré pour que l’utilisateur puisse commander une requête. Le processeur peut également être configuré pour recevoir une requête commandée par l’utilisateur via le dispositif d’entré. Le système médical peut être configuré pour initialiser l’identification de l’environnement dès qu’une requête est entrée.
Le système médical (par exemple le processeur) peut être configuré pour initialiser l’identification de l’environnement après (ou dès) réception des données relatives à l’environnement.
Le système médical (par exemple le processeur) peut être configuré pour enregistrer au moins une donnée transmise par le capteur relative à l’environnement (par exemple dans le dispositif de mémoire).
Le système médical (par exemple le processeur) peut être configuré pour créer un ou adapté le modèle d’environnement:
à partir d’un ou plusieurs enregistrements d’environnement identifié,
via un produit de programme informatique (par exemple de type machine learning), à partir d’un ou plusieurs enregistrements, préférentiellement en prenant en compte les résultats d’au moins une précédente action d’identification. Si l’environnement analysé est considéré comme non sécurisé alors le système médical peut demander une authentification ou une validation de la requête. Par exemple, le système médical peut demander à valider la requête, entrer un code pin ou à entrer une nouvelle fois la requête de manière à rendre l’utilisateur plus attentif à sa requête lorsqu’il se trouve dans un environnement non sécurisé.
Autre exemple, si le capteur est adapté pour mesurer la fréquence cardiaque de l’utilisateur, le système médical peut conclure que la situation ou l’environnement est non sécurisé car probablement anxiogène si la fréquence cardiaque mesurée est inhabituellement haute.
Autre exemple, si le système médical comprend une télécommande et un dispositif médical, si la télécommande est posée à plat immobile, écran vers le bas, le système médical doit pouvoir conclure qu’il s’agit d’une situation non sécurisé. En effet, il est très probable que la télécommande soit posée sur une table et que toute requête provenant de la télécommande dans ces conditions est certainement non intentionnelle. Autre exemple, si la télécommande est dans un environnement à faible luminosité et sur la tranche, le système médical peut conclure qu’il s’agit d’un environnement non sécurisé car il est très probable que la télécommande soit dans un sac et que le requête est non intentionnelle.
Tout ou partie des fonctionnalités, étapes ou caractéristiques décrites dans les autres aspects de la divulgation de ce document peuvent être comprise dans un mode de réalisation de cet aspect de la divulgation.
Un quatrième aspect de la divulgation porte sur une méthode associée au mode de réalisation décrit ci-avant, par exemple une méthode pour identifier un environnement dans lequel un système médical est utilisé par un utilisateur comprenant les étapes suivantes :
Observer l’environnement actuel du système médical,
Analyser l’environnement actuel en prenant en compte les données (par exemple en le comparant aux données) relatives à un modèle d’environnement (sécurisé), Déterminer si l’environnement actuel est un environnement sécurisé ou non en fonction du résultat de l’analyse.
L’étape d’observation peut comprendre une étape de réception des données transmises par un capteur relatives à l’environnement actuel du système médical.
La méthode peut comprendre en outre au moins une des étapes suivantes :
Recevoir une requête de l’utilisateur,
Initialiser la méthode d’identification après (ou dès) réception des données relatives à l’environnement actuel du système médical ou après avoir reçu (ou suite à ou en conséquence de la réception d’) une requête de l’utilisateur,
Enregistrer au moins une donnée transmise par le capteur relative à l’environnement du système médical (par exemple dans un dispositif de mémoire),
Créer un ou adapté le modèle d’environnement à partir d’un ou plusieurs enregistrements, Créer un ou adapté le modèle d’environnement via une méthode de machine learning.
Créer un ou adapté le modèle d’environnement à partir d’un ou plusieurs enregistrements d’environnement, préférentiellement en prenant en compte les résultats d’au moins une précédente action d’identification ;
Exiger une étape d’authentification ou de validation en cas d’identification d’un environnement non sécurisé.
Tout ou partie des fonctionnalités, étapes ou caractéristiques décrites dans les autres aspects de la divulgation de ce document peuvent être comprise dans un mode de réalisation de cet aspect de la divulgation.
Un cinquième aspect de la divulgation se porte sur un système médical sécurisé adapté pour exécuter une requête commandée par un utilisateur comprenant :
Un dispositif de mémoire pour stocker un modèle de comportement,
Un dispositif d’entré configuré pour permettre l’observation du comportement d’un utilisateur (utilisant le système médical) et
Un processeur couplé de manière opérationnelle au dispositif de mémoire et au dispositif d’entré
Dans lequel le processeur est configuré pour :
Recevoir des données relatives au comportement de l’utilisateur actuel transmises par le dispositif d’entré,
Analyser le comportement de l’utilisateur actuel en prenant en compte le modèle de comportement (par exemple en le comparant au modèle de comportement) enregistré dans le dispositif de mémoire, et
Définir un niveau de plausibilité du comportement en fonction du résultat de l’analyse.
La plausibilité peut être la probabilité que :
la requête ne soit pas entachée d’une erreur,
la requête soit intentionnelle,
la requête ait été commandée par un utilisateur autorisé,
l’utilisateur soit conscient de sa requête,
l’utilisateur respecte sa thérapie,
l’utilisateur a oublié d’effectuer une action (entré un requête),
l’utilisateur ne respecte pas son traitement (par exemple habituel), ...
En fonction du niveau de plausibilité défini lors de l’étape d’analyse, le processeur peut en outre être configuré pour :
Exécuter la requête de l’utilisateur,
Exécuter la requête de l’utilisateur sous condition,
Exécuter la requête sans demander de validation ou d’authentification de l’utilisateur (par exemple si le niveau de plausibilité est important, au-dessus d’un certain seuil), Exiger une ou plusieurs étapes de validation ou d’authentification de l’utilisateur pour que la requête puisse être exécutée (par exemple si le niveau de plausibilité est faible, au-dessous d’un certain seuil),
Définir un niveau de sécurité nécessaire pour exécuter la requête, par exemple dépendant du niveau de plausibilité,
Informer l’utilisateur d’un oubli,
Rappeler l’utilisateur qu’il effectue normalement une action (commande de requête, activité sportive, repos, ...), et/ou
Inciter l’utilisateur à respecter une certaine routine (par exemple un traitement, ou ensemble d’action de vérification, ...)...
Selon certains mode de réalisation, le niveau de sécurité peut contraindre l’utilisateur à effectuer une ou plusieurs étapes (supplémentaire) (entrer code PIN,...) et/ou peut comprendre plusieurs échelons. Plus le niveau de plausibilité est faible plus le niveau de sécurité pourra être important. Par exemple si le niveau de plausibilité est extrêmement bas le système médical pourrait demander à l’utilisateur d’entrer à nouveau la requête et/ou demander une étape d’authentification stricte (reconnaissance facial, empreinte digital, question personnelle,...) alors que si le niveau de plausibilité est moyen un simple code PIN pourrait suffire.
Selon certains modes de réalisation, en fonction du comportement de l’utilisateur, le système médical pourra évaluer la probabilité de cette requête en se basant sur un modèle de comportement connu par le système médical.
Selon certains modes de réalisation, en fonction du comportement de l’utilisateur, le système médical pourra évaluer la probabilité que ce comportement est habituel/routinier ou non en se basant sur un modèle de comportement connu par le système médical.
Le dispositif d’entré peut comprendre :
Une interface homme-machine (utilisateur-système) telle que des boutons, un écran tactile ou des actionneurs pouvant être configurés pour entrer une requête dans le système médical,
Un capteur :
o Un capteur optique (caméra, infra rouge, luminosité,...),
o Un capteur sonore (microphone, sonomètre, ...
o Un capteur de déplacement (accéléromètre, inertielle, gyroscope, inclinomètre, ...),
o Un capteur temporel (horloge, chronomètre, ...)
o Un capteur biométrique et/ou
o Un capteur de position (géolocalisation, geofencing, altimètre, ...)
Le système médical peut être configuré pour définir le niveau de plausibilité dès qu’une requête est entrée ou dès que l’utilisateur effectue un comportement inhabituel. Le système médical (par exemple le processeur) peut être configuré pour initialiser la détermination du niveau de plausibilité après (ou dès) réception des données relatives à un comportement de l’utilisateur.
Le système médical (par exemple le processeur) peut être configuré pour enregistrer au moins une donnée transmise par le dispositif d’entré relative au comportement de l’utilisateur (par exemple dans le dispositif de mémoire).
Le système médical (par exemple le processeur) peut être configuré pour créer un ou adapté le modèle de comportement :
à partir d’un ou plusieurs enregistrements de comportement,
via un produit de programme informatique (par exemple de type machine learning), à partir d’un ou plusieurs enregistrements de comportement, préférentiellement en prenant en compte les résultats d’au moins une précédente étape d’analyse.
Préférentiellement, l’étape de détermination du niveau de plausibilité dépend du résultat de l’étape d’analyse. Le résultat de l’analyse peut comprendre une données booléennes (vrai/faux ; oui, non), un score ou une probabilité.
Le modèle de comportement peut comprendre un ensemble de données relatives aux comportements d’un utilisateur autorisé ou non. Il peut s’agir d’un modèle générique ou personnalisé à l’utilisateur. Le model de comportement peut évoluer dans le temps et apprendre les comportements de l’utilisateur grâce par exemple aux données transmises par le dispositif d’entré.
Un comportement peut être toutes données relatives à un signe distinctif de l’utilisateur (physique, comportementale,...) qui préférentiellement peut être mesurable par le capteur ou un ensemble de capteur ou reconnaissable par son action (commande d’une requête ou non). Un comportement peut être la façon de manipuler, utiliser ou placer le système médical (son inclinaison, l’activité, ...).
Par exemple, l’utilisateur peut avoir l’habitude d’utiliser son système médical à heure fixe, dans ce cas lors de son utilisation durant une tranche horaire habituelle, le système peut conclure que l’utilisateur a respecté son traitement et ainsi il peut accepter d’exécuter la requête sans demander d’autres actions ou en minimisant le niveau de sécurité A l’inverse si l’utilisateur n’utilise pas son système médical alors qu’il a l’habitude ou qu’il devrait le faire pour respecter son traitement alors le système médical peut évaluer la probabilité qu’il s’agit d’un oubli et peut par conséquence inciter (via une alarme ou un affichage sur un écran) l’utilisateur à respecter son traitement. Si le système médical comprend un écran, le système peut afficher « vous devriez penser à faire... » ou « n’oubliez pas de bouger » ou « il est temps de faire... » ... Au contraire, le système médical est utilisé à 3 heures du matin alors que l’utilisateur n’utilise habituellement pas son système médical de minuit à 6 heures du matin, alors le système médical conclura qu’il est très peu probable qu’il s’agisse d’une requête intentionnelle. Ainsi le système médical peut conclure qu’il y a une forte probabilité que l’utilisateur n’est pas autorisé à (ou n’a pas l’habitude de) commander une telle requête ou exiger un niveau de sécurité supérieur ou demander une confirmation afin d’inciter l’utilisateur à être conscient de sa requête.
Par exemple, si le système médical comprend une télécommande et un dispositif médical, si la télécommande est posée à plat immobile, écran vers le bas, le système médical doit pouvoir conclure que la plausibilité que l’utilisateur est entré cette requête est faible car il est très probable que la télécommande soit posés sur une table et que toute requête provenant de la télécommande dans ces conditions est certainement non intentionnelle. Autre exemple, si la télécommande est dans un environnement à faible luminosité et sur la tranche, le système médical devrait refuser toute requête ou exiger une ou plusieurs étape supplémentaire pour exécuter une telle requête car il est très probable que la télécommande soit dans un sac et que l’utilisateur a commandé une requête non intentionnelle.
Si l’utilisateur a tendance à se tromper dans l’entrée d’une commande, par exemple si l’utilisateur doit commander une délivrance de 3 U alors qu’il a entré via le dispositif d’entrer 33 U par erreur ou que dans le domaine de la dialyse que l’utilisateur entre un volume de fill de 3000mL au lieu de 300mL. Le système peut comparer cette commande au modèle de comportement afin de vérifier la plausibilité de cette commande. Le système peut alors demander une confirmation en mettant en évidence la commande et en exigeant un code PIN ou demander d’entrer à nouveau la commande ou en informant l’utilisateur en affichant : « il est probable que vous ayez entré par erreur 33U au lieu de 3U » ou « veuillez confirmer que vous souhaitez commander 3000mL et non 300mL » ...
Tout ou partie des fonctionnalités, étapes ou caractéristiques décrites dans les autres aspects de la divulgation de ce document peuvent être comprise dans un mode de réalisation de cet aspect de la divulgation.
Un sixième aspect de la divulgation porte sur une méthode associée au mode de réalisation décrit ci-avant, par exemple une méthode pour valider l’exécution d’une requête commandée par un utilisateur en fonction de son comportement comprenant les étapes suivantes :
Observer un comportement de l’utilisateur,
Analyser le comportement de l’utilisateur en prenant en compte un modèle de comportement (par exemple en le comparant à un modèle de comportement) et Définir un niveau de plausibilité de la requête en fonction du résultat de l’analyse.
L’étape d’observation peut comprendre une étape de réception des données transmises par un dispositif d’entré relatives à un comportement de l’utilisateur.
La méthode peut en outre comprendre au moins une des étapes suivantes : Exécuter la requête de l’utilisateur en fonction du niveau de plausibilité défini lors de l’étape précédente,
Exiger qu’une étape de sécurité soit validée pour exécuter la requête,
Informer l’utilisateur que son comportement est inhabituel ou inapproprié Inciter l’utilisateur à prendre connaissance du comportement observé,
Informer l’utilisateur de la déviance de son comportement par rapport au modèle de comportement,
En cas de faible plausibilité, rendre attentif l’utilisateur au sujet de son comportement,
En cas de faible plausibilité, demander une confirmation ou une authentification,
En cas de faible plausibilité, augmenter le niveau de sécurité,
En cas de forte plausibilité, diminuer le niveau de sécurité, ou
Rappeler à l’utilisateur d’effectuer une action, ...
Tout ou partie des fonctionnalités, étapes ou caractéristiques décrites dans les autres aspects de la divulgation de ce document peuvent être comprise dans un mode de réalisation de cet aspect de la divulgation.
Un septième aspect de la divulgation porte sur un système médical sécurisé adapté pour définir un niveau de sécurité nécessaire pour exécuter une requête (commandée par un utilisateur) comprenant :
Un dispositif de mémoire pour stocker un modèle de comportement,
Un dispositif d’entré configuré pour observer le comportement d’un utilisateur et Un processeur couplé de manière opérationnelle au dispositif de mémoire et au dispositif d’entré ;
Dans lequel le processeur est configuré pour
Recevoir des données relatives à un comportement de l’utilisateur transmises par le dispositif d’entré,
Analyser le comportement de l’utilisateur en prenant en compte le modèle de comportement (par exemple en le comparant au modèle de comportement) enregistré dans le dispositif de mémoire,
Déterminer un niveau de sécurité nécessaire pour l’exécution de la requête en fonction du résultat de l’analyse et
Exiger que le niveau de sécurité nécessaire définie soit satisfait pour exécuter la requête.
Les données relatives à un comportement peuvent comprendre une requête entrée par l’utilisateur.
Pour que le niveau de sécurité soit satisfait, le système peut demander :
Une confirmation,
Une nouvelle entrée,
Un code secret,
Un dispositif tiers de confiance tel qu’un jeton, Une reconnaissance faciale,
Une empreinte digitale,
Une ou plusieurs authentifications, ...
Selon certains modes de réalisation, plus le comportement analysé sera éloigné du model de comportement, plus le niveau de sécurité exigé sera important, contraignant ou demandera un niveau d’authentification stricte. A l’inverse plus le comportement analysé sera proche du model de comportement, plus le niveau de sécurité exigé sera faible.
Tout ou partie des fonctionnalités, étapes ou caractéristiques décrites dans les autres aspects de la divulgation de ce document peuvent être comprise dans un mode de réalisation de cet aspect de la divulgation.
Un huitième aspect de la divulgation porte sur une méthode associée au mode de réalisation décrit ci-avant, par exemple une méthode pour définir un niveau de sécurité nécessaire pour exécuter une requête comprenant les étapes suivantes :
Observer un comportement d’un utilisateur,
Analyser le comportement en prenant en compte un modèle de comportement (par exemple en le comparant à un modèle de comportement) et
Définir un niveau de sécurité nécessaire pour l’exécution de la requête en fonction du résultat de l’analyse.
Un comportement d’un utilisateur peut comprendre une requête entrée par l’utilisateur.
Tout ou partie des fonctionnalités, étapes ou caractéristiques décrites dans les autres aspects de la divulgation de ce document peuvent être comprise dans un mode de réalisation de cet aspect de la divulgation.
Un neuvième aspect de la divulgation porte sur un système médical sécurisé adapté pour définir un niveau de sécurité en fonction de l’environnement du système médical comprenant :
Un dispositif de mémoire pour stocker des données relatives à un modèle d’environnement,
Un capteur configuré pour acquérir des données relatives à l’environnement actuel du système médical et
Un processeur couplé de manière opérationnelle au dispositif de mémoire et au capteur
Dans lequel le processeur est configuré pour
Recevoir des données relatives à l’environnement actuel transmises par le capteur, Analyser l’environnement actuel en prenant en compte les données (par exemple en le comparant aux données) relatives au modèle d’environnement enregistré dans le dispositif de mémoire et Définir un niveau de sécurité adapté à l’environnement adapté en se basant sur le résultat de l’analyse.
Pour que le niveau de sécurité soit satisfait, le système peut demander :
Une confirmation,
Une nouvelle entrée,
Un code secret,
Un dispositif tiers de confiance tel qu’un jeton,
Une reconnaissance faciale,
Une empreinte digitale,
Une ou plusieurs authentifications, ...
Selon certains modes de réalisation, plus l’environnement analysé sera éloigné du model d’un environnement sécurisé, plus le niveau de sécurité exigé sera important, contraignant ou demandera un niveau d’authentification stricte. A l’inverse plus l’environnement analysé sera proche du model d’un environnement sécurisé, plus le niveau de sécurité exigé sera faible.
Selon certains modes de réalisation, plus l’environnement analysé sera proche du model d’un environnement non-sécurisé, plus le niveau de sécurité exigé sera important, contraignant ou demandera un niveau d’authentification stricte. A l’inverse plus l’environnement analysé sera éloigné du model d’un environnement non-sécurisé, plus le niveau de sécurité exigé sera faible.
Un environnement sécurisé peut être un lieu ou une situation où l’utilisateur peut être en toute sécurité pour utiliser son système médical. A l’inverse un environnement non sécurisé peut être un lieu ou une situation où l’utilisateur ne serait pas en sécurité pour utiliser son système médical car il risque de faire une erreur ou ne pas être suffisamment attentif à sa manipulation.
Par exemple, un lieu sécurisé peut être un lieu calme, un endroit familier (le domicile de l’utilisateur,...), un hôpital, un cabinet médical, une pharmacie ou tout lieu similaire. Le système médical peut utiliser un ou plusieurs capteurs pour identifier ce lieu ou situation. Le système médical peut mesurer :
via un capteur sonore : le bruit, le volume sonore, ... (par exemple dans un environnement trop bruyant l’utilisateur peut être distrait et il peut ainsi se tromper quant à l’utilisation de son système, ...),
via un capteur optique : la luminosité, ... (par exemple s’il y a une trop forte luminosité l’utilisateur peut être ébloui, ...),
via un dispositif de communication (ou capteur de réseau) capable de déterminer la présence d’un réseau connu identifié (par exemple le SSID du wifi du domicile), ici ce type de dispositif peut être utilisé comme un capteur car il capte, reconnaît ou mesure un signal réseau,
via un capteur de localisation (géolocalisation,...),
via un capteur temporel : horloge, minuteur, ... (par exemple s’il est tard ou si l’utilisateur a reçu depuis peu une dose de médicament pouvant altérer son attention,...),
via d’autres capteurs... L’analyse de l’environnement actuel peut permettre de déterminer le type d’environnement (sécurisé ou non) grâce aux données du capteur et au modèle d’environnement enregistré dans le dispositif de mémoire. Le résultat de l’analyse peut comprendre une données booléennes (vrai/faux ; oui, non), un score ou une probabilité que l’environnement est identifié comme sécurisé ou non.
Le modèle d’environnement peut comprendre un ensemble de données permettant d’identifier un lieu ou une situation (sécurisé ou non). Le model d’environnement peut être générique ou adapté à l’utilisateur. Le système médical peut être configuré pour permettre de paramétrer le modèle d’environnement (par exemple si décibel supérieur à 70 dB, alors environnement non sécurisé).
Le système médical peut comprendre un produit de programme informatique qui permet de surveiller la position et le déplacement du système et de prendre des mesures si la position ou le déplacement s'écarte de certaines valeurs fixées d'avance (par exemple le domicile ou l’hôpital, le cabinet médical, ...).
Le système médical peut comprendre un dispositif d’entré configuré pour que l’utilisateur puisse commander une requête. Le processeur peut également être configuré pour recevoir une requête commandée par l’utilisateur via le dispositif d’entré. Le système médical peut être configuré pour initialiser l’identification de l’environnement dès qu’une requête est entrée.
Le système médical (par exemple le processeur) peut être configuré pour initialiser l’identification de l’environnement après (ou dès) réception des données relatives à l’environnement.
Le système médical (par exemple le processeur) peut être configuré pour enregistrer au moins une donnée transmise par le capteur relative à l’environnement (par exemple dans le dispositif de mémoire).
Le système médical (par exemple le processeur) peut être configuré pour créer un ou adapté le modèle d’environnement:
à partir d’un ou plusieurs enregistrements d’environnement identifié,
via un produit de programme informatique (par exemple de type machine learning), à partir d’un ou plusieurs enregistrements, préférentiellement en prenant en compte les résultats d’au moins une précédente action d’identification.
Si l’environnement analysé est considéré comme non sécurisé alors le système médical peut demander une authentification ou une validation de la requête. Par exemple, le système médical peut demander à valider la requête, entrer un code pin ou à entrer une nouvelle fois la requête de manière à rendre l’utilisateur plus attentif à sa requête lorsqu’il se trouve dans un environnement non sécurisé.
Autre exemple, si le capteur est adapté pour mesurer la fréquence cardiaque de l’utilisateur, le système médical peut conclure que la situation ou l’environnement est non sécurisé car probablement anxiogène si la fréquence cardiaque mesurée est inhabituellement haute.
Un environnement sécurisé peut être un lieu ou une situation où l’utilisateur peut être en toute sécurité pour utiliser son système médical. A l’inverse un environnement non sécurisé peut être un lieu ou une situation où l’utilisateur ne serait pas en sécurité pour utiliser son système médical car il risque de faire une erreur ou ne pas être suffisamment attentif à sa manipulation.
Par exemple, un lieu sécurisé peut être un lieu calme, un endroit familier (le domicile de l’utilisateur,...), un hôpital, un cabinet médical, une pharmacie ou tout lieu similaire. Le système médical peut utiliser un ou plusieurs capteurs pour identifier ce lieu ou situation. Le système médical peut mesurer :
via un capteur sonore : le bruit, le volume sonore, ... (par exemple dans un environnement trop bruyant l’utilisateur peut être distrait et il peut ainsi se tromper quant à l’utilisation de son système, ...),
via un capteur optique : la luminosité, ... (par exemple s’il y a une trop forte luminosité l’utilisateur peut être ébloui, ...),
via un dispositif de communication (ou capteur de réseau) capable de déterminer la présence d’un réseau connu identifié (par exemple le SSID du wifi du domicile), ici ce type de dispositif peut être utilisé comme un capteur car il capte, reconnaît ou mesure un signal réseau,
via un capteur de localisation (géolocalisation,...),
via un capteur temporel : horloge, minuteur, ... (par exemple s’il est tard ou si l’utilisateur a reçu depuis peu une dose de médicament pouvant altérer son attention,...),
via d’autres capteurs...
L’analyse de l’environnement actuel peut permettre de déterminer le type d’environnement (sécurisé ou non) grâce aux données du capteur et au modèle d’environnement enregistré dans le dispositif de mémoire. Préférentiellement, l’étape de détermination du type d’environnement dépend du résultat de l’étape d’analyse. Le résultat de l’analyse peut comprendre une données booléennes (vrai/faux ; oui, non), un score ou une probabilité que l’environnement est identifié comme sécurisé ou non.
Le modèle d’environnement peut comprendre un ensemble de données permettant d’identifier un lieu ou une situation (sécurisé ou non). Le model d’environnement peut être générique ou adapté à l’utilisateur. Le système médical peut être configuré pour permettre de paramétrer le modèle d’environnement (par exemple si décibel supérieur à 70 dB, alors environnement non sécurisé). Le système médical peut comprendre un produit de programme informatique qui permet de surveiller la position et le déplacement du système et de prendre des mesures si la position ou le déplacement s'écarte de certaines valeurs fixées d'avance (par exemple le domicile ou l’hôpital, le cabinet médical,...).
Le système médical peut comprendre un dispositif d’entré configuré pour que l’utilisateur puisse commander une requête. Le processeur peut également être configuré pour recevoir une requête commandée par l’utilisateur via le dispositif d’entré. Le système médical peut être configuré pour initialiser l’identification de l’environnement dès qu’une requête est entrée.
Le système médical (par exemple le processeur) peut être configuré pour initialiser l’identification de l’environnement après (ou dès) réception des données relatives à l’environnement.
Le système médical (par exemple le processeur) peut être configuré pour enregistrer au moins une donnée transmise par le capteur relative à l’environnement (par exemple dans le dispositif de mémoire).
Le système médical (par exemple le processeur) peut être configuré pour créer un ou adapté le modèle d’environnement:
à partir d’un ou plusieurs enregistrements d’environnement identifié,
via un produit de programme informatique (par exemple de type machine learning), à partir d’un ou plusieurs enregistrements, préférentiellement en prenant en compte les résultats d’au moins une précédente action d’identification.
Si l’environnement analysé est considéré comme non sécurisé alors le système médical peut demander une authentification ou une validation de la requête. Par exemple, le système médical peut demander à valider la requête, entrer un code pin ou à entrer une nouvelle fois la requête de manière à rendre l’utilisateur plus attentif à sa requête lorsqu’il se trouve dans un environnement non sécurisé.
Autre exemple, si le capteur est adapté pour mesurer la fréquence cardiaque de l’utilisateur, le système médical peut conclure que la situation ou l’environnement est non sécurisé car probablement anxiogène si la fréquence cardiaque mesurée est inhabituellement haute.
Autre exemple, si le système médical comprend une télécommande et un dispositif médical, si la télécommande est posée à plat immobile, écran vers le bas, le système médical doit pouvoir conclure qu’il s’agit d’une situation non sécurisé et peut donc exiger un niveau de sécurité plus important. En effet, il est très probable que la télécommande soit posée sur une table et que toute requête provenant de la télécommande dans ces conditions est certainement non intentionnelle. Autre exemple, si la télécommande est dans un environnement à faible luminosité et sur la tranche, le système médical conclure qu’il s’agit d’un environnement non sécurisé car il est très probable que la télécommande soit dans un sac et que le requête est non intentionnelle, le système médical peut alors demander une niveau de sécurité de manière à confirmer la requête ou rendre l’utilisateur attentif à la requête. Tout ou partie des fonctionnalités, étapes ou caractéristiques décrites dans les autres aspects de la divulgation de ce document peuvent être comprise dans un mode de réalisation de cet aspect de la divulgation.
Un dixième aspect de la divulgation porte sur une méthode associée au mode de réalisation décrit ci-avant, par exemple une méthode pour définir un niveau de sécurité en fonction de l’environnement du système médical comprenant les étapes suivantes :
Observer l’environnement actuel du système médical,
Analyser l’environnement actuel en prenant en compte les données (par exemple en le comparant aux données) relatives à un modèle d’environnement et
Définir un niveau de sécurité adapté à l’environnement adapté en se basant sur le résultat de l’analyse.
Tout ou partie des fonctionnalités, étapes ou caractéristiques décrites dans les autres aspects de la divulgation de ce document peuvent être comprise dans un mode de réalisation de cet aspect de la divulgation.
Un onzième aspect de la divulgation porte sur un produit de programme informatique comprenant :
un agent observateur configuré pour générer des informations relatives aux comportements actuels de l’utilisateur sur la base de données transmises par au moins un dispositif d’entré (par exemple un capteur);
un agent comparateur configuré pour comparer les informations relatives aux comportements actuel de l’utilisateur avec un modèle de comportement ; et
un agent évaluateur configuré pour affecter le comportement observé à une zone de confiance sur la base du résultat de l’agent comparateur ou pour déterminer l’identité de l’utilisateur sur la base du résultat de l’agent comparateur.
Tout ou partie des fonctionnalités, étapes ou caractéristiques décrites dans les autres aspects de la divulgation de ce document peuvent être comprise dans un mode de réalisation de cet aspect de la divulgation.
Un douzième aspect de la divulgation porte sur un produit de programme informatique comprenant :
un agent observateur configuré pour générer des informations relatives à l’environnement actuel de l’utilisateur sur la base de données transmises par au moins un dispositif d’entré (par exemple un capteur);
un agent comparateur configuré pour comparer les informations relatives à l’environnement actuel de l’utilisateur avec un ou plusieurs modèles d’environnement; et un agent évaluateur configuré pour affecter l’environnement observé à une zone de confiance sur la base du résultat de l’agent comparateur ou pour déterminer le type d’environnement de l’utilisateur sur la base du résultat de l’agent comparateur. Tout ou partie des fonctionnalités, étapes ou caractéristiques décrites dans les autres aspects de la divulgation de ce document peuvent être comprise dans un mode de réalisation de cet aspect de la divulgation.
Les différents aspects de la divulgation peuvent être combinés entre eux dans un même système ou une même méthode.
Liste des figures
La divulgation sera mieux comprise ci-après au moyen de quelques exemples illustrés.
Il va de soi que la divulgation ne se limite pas à ces modes de réalisation.
Figure 1 schématise un système médical selon un mode de réalisation.
Figure 2 schématise un système médical selon un mode de réalisation.
Figure 3 schématise un système médical selon un mode de réalisation.
Figure 4 schématise un diagramme de flux du processus selon un mode de réalisation.
Figure 5 schématise un diagramme de flux du processus selon un mode de réalisation.
Figure 6 schématise un diagramme de flux du processus selon un mode de réalisation.
Figure 7 schématise un diagramme de flux du processus selon un mode de réalisation.
Figure 8 schématise un diagramme de flux du processus selon un mode de réalisation.
Figure 9 schématise un diagramme de flux du processus selon un mode de réalisation.
Références numériques utilisées dans les figures
1 Système médical
2 Dispositif d'entré
3 Dispositif d'analyse
4 Capteur
5 Processeur
6 Dispositif de mémoire
7 Dispositif médical
8 Patient
10 Dispositif médical
11 Dispositif distant
12 Communication sans fil
13 Processeur
14 Dispositif de mémoire
15 Dispositif de communication 16 Ecran
16' Indicateur visuel, sonore ou vibrant
17 Touche/bouton
18 Capteur
Description détaillée de la divulgation
Dans le présent document, la description détaillée de la divulgation comporte des modes de réalisation de dispositifs, de systèmes et de méthodes présentés à titre d'illustration. Il est bien entendu que d'autres modes de réalisation sont envisageables et peuvent être apportées sans s'écarter de la portée ou l'esprit de la divulgation. La description détaillée qui suit, par conséquent, ne doit pas être prise dans un sens limitatif.
Sauf indication contraires, les termes scientifiques et techniques utilisé dans le présent document ont des significations couramment utilisés par l’homme du métier. Les définitions apportées dans ce document sont mentionnées afin de faciliter la compréhension des termes fréquemment utilisés et ne sont pas destinées à limiter la portée de la divulgation.
Les indications de direction utilisées dans la description et les revendications, telles que "haut", "bas", "gauche", "droite", "supérieur", "inférieur", et autres directions ou orientations sont mentionnées afin d’apporter plus de clarté en référence aux figures. Ces indications ne sont pas destinées à limiter la portée de la divulgation.
Les verbes « avoir », « comprendre », « inclure » ou équivalent sont utilisés dans le présent document dans un sens large et signifie de façon générale « inclut, mais sans s’y limiter.
Le terme“ou” est généralement employé dans un sens large comprenant“et/ou” à moins que le contexte indique clairement le contraire.
Le terme “capteur” est généralement employé dans un sens large comprenant “dispositif transformant l'état d'une grandeur observée en une grandeur utilisable, par exemple une tension électrique, une hauteur de mercure, une intensité ou la déviation d'une aiguille” à moins que le contexte indique clairement un autre sens. Ici « grandeur observé » se signifie pas qu’elle est nécessaire observable par un être humain, exemple de grandeur observé (non observable par l’être humain) radiation, champs magnétique, ondes, IR,...
Les expressions "au moins un de A, B et C", "au moins un de A, B ou C", "choisis dans le groupe constitué de A, B, C et leurs combinaisons" ou expressions équivalentes sont utilisées dans un sens large, y compris "seulement A, ou seulement B, ou seulement C, ou toutes combinaisons de A, B et C" à moins que le contenu n'indique clairement le contraire.
L’expression "utilisateur actuel" signifie dans ce document l’utilisateur qui utilise/manipule actuellement le système ou au moment où le dispositif d’entré observait le comportement de l’utilisateur. L’expression "environnement actuel" signifie dans ce document l’environnement dans lequel le système est actuellement localisé ou au moment où le dispositif d’entré observait l’environnement du système.
Le terme « identifier » est généralement employé dans un sens large comprenant notamment l’action qui consiste à établir l'identité d'un utilisateur ou d’un système. Le terme « authentifier » est généralement employé dans un sens large comprenant notamment l’action qui permet à l'utilisateur ou au système d'apporter la preuve de son identité, il s’agit ainsi d’une action de sécurité plus forte que l'identification.
La présente demande revendique les priorités de EP18215753.7 et de EP18215752.9, déposées le 21 décembre 2018 au nom de Debiotech SA, dont le contenu intégral doit être considéré comme faisant partie de la présente demande.
Selon certains modes de réalisation divulguée par la figure 1 , le système (1) peut comprendre au moins un des éléments suivants :
Un dispositif d’analyse(3)
Un dispositif d’entré (2), et/ou
Un capteur (4).
La figure 1 n’est qu’une illustration du système, les traits et délimitations ne doivent pas être comprises an sens stricte par exemple tout ou partie des dispositifs peut être distinct des autres dispositifs mais l’ensemble forme le système. Il est noté qu’un dispositif d’entré peut être un capteur.
Le dispositif d’entré (2) peut comprendre un clavier, des boutons, une interface graphique tactile,... Le système peut comprendre un ou plusieurs dispositifs d’entré couplé(s) de manière opérationnelle au dispositif d’analyse (3).
Le capteur peut être ou comprendre :
Un capteur optique (caméra, infra rouge, luminosité,...),
Un capteur sonore (microphone, sonomètre,...
Un capteur de déplacement (accéléromètre, inertielle, gyroscope, inclinomètre,...),
Un capteur temporel (horloge, chronomètre,...)
Un capteur biométrique (empreinte digital, capteur de mesure d’un fluide du patient (par exemple glycémie,...) et/ou
Un capteur de position (géolocalisation, geofencing, altimètre,...),...
Le système peut comprendre un ou plusieurs capteurs couplé(s) de manière opérationnelle au dispositif d’analyse (3). La notion de capteur est ici générale, ce terme est utilisé pour alléger la lecture. Il peut s’agir d’un dispositif de mesure et/ou de détection pouvant comprendre un circuit électronique et combinant plusieurs capteurs ou type de capteur de manière à détecter/mesurer le type de données souhaitées.
Le dispositif d’entré (2) et/ou le capteur (4) peuvent être configuré pour renseigner le système (1) sur le comportement de l’utilisateur et/ou l’environnement du système médical.
Le dispositif d’analyse (3) peut comprendre un processeur (5) et/ou un dispositif de mémoire (6). Le processeur (5) peut être configuré pour faire fonctionner un programme informatique embarqué. Le dispositif de mémoire (6) peut être configuré pour enregistrer un ensemble de données tel que des règles de sécurité, un modèle de comportement, des paramètres de traitement, des données relatives à l’analyse des données envoyé par un capteur et/ou les données renseignées par le dispositif d’entré.
Le dispositif d’analyse (3) peut être configuré pour :
• reconnaitre/analyser le comportement ou l’environnement de l’utilisateur renseigné par le dispositif d’entré (2) ou le capteur (4),
• optionnellement, définir un modèle de comportement basé sur au moins un précédent comportement ou environnement connu ou un modèle générique de comportement, et/ou
• Identifier l’utilisateur et/ou l’environnement du système médical et/ou définir un niveau de sécuritaire adapté.
Le système peut en outre comprendre un dispositif médical (7) connecté au patient (8). Le dispositif médical peut être un dispositif de délivrance (de solution médicamenteuse tel que insuline, hormone, antalgique,...) et/ou un dispositif de mesure (glycémie, pression artérielle,...) et/ou autre dispositif agissant pour la santé ou le bien être d’un patient (aide respiratoire, dialyse,...).
Le système peut être configuré de manière à :
identifier un utilisateur ou son environnement en fonction :
o de données transmisse par le dispositif d’entré ou capteur (géolocalisation (geofencing), microphone, optique (caméra), biométrique, accéléromètre, gyroscopes,...) et
o d’un modèle connu ; et/ou
Définir ou déterminer un niveau de plausibilité en fonction :
o de données transmisse par le dispositif d’entré ou capteur (géolocalisation (geofencing), microphone, optique (caméra), biométrique, accéléromètre, gyroscopes,...) et
o d’un modèle connu ; et/ou
déterminer un niveau de sécurité adapté en fonction :
o de données transmisse par le dispositif d’entré ou capteur (géolocalisation (geofencing), microphone, optique (caméra), biométrique, accéléromètre, gyroscopes,...) et
o d’un modèle connu ; et/ou Selon certains modes de réalisation, lorsque l’utilisateur entre un requête via le dispositif d’entrée, le dispositif d’analyse va analyser un certain nombre de paramètres (tel(s) que : environnementaux, signes vitaux, ou comportementaux, ...) grâce aux données du dispositif d’entrée et/ou du capteur de manière à identifier l’utilisateur ou l’environnement ou déterminer un niveau de plausibilité ou déterminer un niveau de sécurité adapté. Après cette analyse, le système médical peut valider ou non la requête ou demander une authentification supplémentaire pour initialiser la requête.
Par exemple, si la requête est une commande d’infusion (commande d’un bolus, d’un basal, suspension du basal, diminution ou augmentation temporaire de l’infusion,...), et si ce comportement est habituel alors la commande pourra être envoyé au dispositif de médical (qui peut être un dispositif de délivrance) pour exécution avec un niveau de sécurité faible (avec ou sans confirmation et/ou validation). Par contre, si ce comportement est inhabituel alors la commande ne pourra être envoyée au dispositif de délivrance pour exécution qu’après une procédure d’authentification supplémentaire ou plus stricte.
La figure 2 expose un système médical (1 ) comprenant un dispositif médical (10) et un dispositif distant (1 1 ). Le dispositif médical (10) et le dispositif distant (1 1 ) sont configurés pour échanger des données via une communication avec/sans fil (12). Le dispositif médical (10) et/ou le dispositif distant (1 1 ) comprennent au moins un dispositif de sécurité comme décrit ci- avant et un dispositif de communication. Le dispositif distant peut être un dispositif permettant de contrôler ou commander le dispositif médical. Il peut s’agir entre autres d’une télécommande, d’un ordinateur, une tablette, d’un téléphone,...
Le dispositif distant peut comprendre un dispositif d’entré et/ou tout ou partie du dispositif d’analyse. De même, le dispositif médical peut comprendre un dispositif de délivrance, un dispositif d’entré et/ou tout ou partie du dispositif d’analyse.
La figure 3 divulgue un exemple de système médical. Préférentiellement, le dispositif distant (1 1) est un dispositif générique ou standard, c’est-à-dire non dédié au dispositif médical (10). Le dispositif distant peut être un téléphone, une télécommande (sans fil), un serveur distant,... Le dispositif distant est adapté pour échanger des données de manière sécurisé avec le dispositif médical (10) via une communication sans fil (12). Le dispositif distant peut comprendre un processeur (13), un dispositif de mémoire (14), un dispositif de communication (15) et/ou une ou plusieurs touche(s) (ou bouton(s)) (17). Le dispositif distant (1 1) peut comprendre en outre un écran (16) configuré pour afficher des données relatives au dispositif médical (10), par exemple des instructions de commande (bolus, suspension, basal, ...), des informations d’état du dispositif médical, des informations concernant les activités du système,... L’écran peut être un écran tactile et les touches ou boutons peuvent être virtuels. Le dispositif distant (1 1 ) peut en outre comprendre un ou plusieurs capteurs (18). Ce capteur peut être au moins des capteurs suivant : capteur de mouvement (gyroscope, accéléromètre, capteur de déplacement inertiel, inclinomètre, capteur de déplacement linéaire), capteur de géolocalisation (par triangulation des antennes de téléphonie mobile, wifi, GPS, ...), une caméra, un microphone, un capteur biométrique, ou tout autre capteur listé dans ce document. Le dispositif médical (10) peut être configuré pour délivrer une substance à patient (par exemple un médicament un produit pharmaceutique, un liquide médicale, protéine, complément, antalgiques, anti-inflammatoires,...), pour mesurer une donnée relative au patient (par exemple, glycémie, pression artérielle, rythme cardiaque,...) et/ou pour effectuer d’autre action de santé (tel que pacemaker, organe artificiel...). Le dispositif médical (10) peut comprendre un processeur (13), un dispositif de mémoire (14), un dispositif de communication (15) et/ou une ou plusieurs touche(s) (ou bouton(s)) (17). Le dispositif médical (10) peut comprendre un écran mais si le dispositif distant en comprend déjà un alors cet écran est facultatif. Néanmoins, le dispositif médical peut comprendre en outre un indicateur visuel, sonore et/ou vibrant (16’). Le dispositif médical (10) peut en outre comprendre un ou plusieurs capteurs (18).
Le processeur (13) du dispositif distant ou du dispositif médical peuvent être configuré pour exécuter tout ou partie des instructions du programme informatique tel que décrit dans le document. Par exemple, le processeur du dispositif distant peut exécuter tout ou partie des instructions du dispositif d’analyse et le dispositif médical peut exécuter tout ou partie des instructions du dispositif d’analyse.
Selon certains modes de réalisation, le système médical peut comprendre un capteur d’environnement configuré pour mesurer une donnée relative à l’environnement ou ue situation actuelle dans lequel se situe le système et un dispositif d’analyse configuré pour analyser/surveiller l’environnement dans lequel se situe le système basé sur les données du capteur d’environnement. Le dispositif d’analyse peut en outre retrouver un modèle d’environnement enregistré dans un dispositif de mémoire (dans le système médical ou dans un serveur distant) et comparer ce modèle d’environnement aux données du capteur d’environnement. Le dispositif d’analyse peut en outre être configuré pour déterminer un niveau de sécurité en fonction du ou des résultats de l’analyse.
Le capteur d’environnement peut être un capteur de géolocalisation permettant de géo localiser le système, un microphone permettant de mesurer un niveau sonore ambiant (si le niveau sonore est trop important alors le système peut demander une authentification ou confirmation de l’utilisateur pour alerter le patient en cas de commande), un capteur wifi (par exemple une antenne wifi de manière à déterminer si l’antenne wifi est connectée à un routeur habituel (maison ou bureau)),... Le capteur d’environnement peut permettre de déterminer si l’utilisateur se trouve ou non dans un périmètre prédéfini (méthode de geofencing).
Ici l’objectif est de permettre au système de savoir si la requête de l’utilisateur (interrogation du dispositif médical, commande de délivrance ou d’action,...) a été faite dans un environnement fiable, sécurisé, habituel et où l’utilisateur ne risque pas d’être distrait par son environnement.
Selon certains modes de réalisation, le système médical peut comprendre un capteur configuré pour détecter une manipulation du système médical tel que le dispositif distant (Télécommande / téléphone) et un dispositif d’analyse configuré pour analyser/surveiller le comportement de l’utilisateur basé sur les données du capteur de mouvement. Le dispositif d’analyse peut en outre retrouver un modèle de comportement enregistré dans un dispositif de mémoire (dans le système médical ou dans un serveur distant) et comparer ce modèle de comportement aux données du capteur de mouvement. Le dispositif d’analyse peut en outre être configuré pour déterminer un niveau de sécurité en fonction du ou des résultats de l’analyse.
Selon certains modes de réalisation, un modèle de comportement générique peut représenter le comportement moyen des utilisateurs, construit à partir de données statistiques sur un large group d’utilisateurs ou construit à partir de méthodes heuristiques. Optionnellement il pourrait exister plusieurs modèles génériques pour plusieurs sous-groupes d’utilisateurs, et le modèle à charger initialement serait choisi en fonction de la classification (automatique) de l’utilisateur dans l’un de ses sous-groupes, en fonction de données d’entrés fournies par l’utilisateur lors de l’initialisation du dispositif (âge, thérapie, niveau expérience de l’utilisateur, type de patient (Type 1 ou 2 pour le diabète),...).
Selon certains modes de réalisation, la reconnaissance de comportement et la comparaison de ce comportement à un modèle de comportement peut être basé sur des anciens comportements de l’utilisateur (ou basé sur un modèle générique). Il peut être configuré de manière à détecter un comportement atypique de l’utilisateur c’est à dire différent du comportement habituel ou d’un comportement générique.
Selon certains modes de réalisation, le système médical peut comprendre un dispositif d’apprentissage des comportements du patient de manière à vérifier si un comportement du patient est conforme à ses habitudes. Ce système d’apprentissage permet en outre d’adapter le model de comportement ou le modèle d’environnement. Il peut s’agir entre autres d’un algorithme de machine learning adapté pour apprendre le comportement du patient.
Comme expliquer dans le document selon certains modes de réalisation, si ce comportement n’est pas habituel ou atypique alors le système peut demander une validation supplémentaire pour valider le comportement.
La notion de comportement peut être large, dans le cadre du traitement du diabète (mais pas seulement), il peut s’agir d’horaire de repas, de quantité de repas, de type de repas, de l’heure d’une activité physique, de la durée d’une activité physique, de l’intensité d’une activité physique, d’un taux de sucre dans le sang du patient, d’une quantité de solution (tel que de l’insuline ou autre solution) commandée pour un bolus, pour un basal, un type de bolus (allongé, normal, dual wave,...), ou tout autre comportement relatif à la manipulation du système (Par exemple : temps passé dans chaque étape/page du menu, rythme de saisie au clavier, position exacte d’un « click » sur un écran tactile) ou comportement lié au traitement...
Par exemple en ce qui concerne la thérapie du diabète, des données relatives à la thérapie du patient peuvent être utilisées pour identifier le comportement et apprendre quelles sont les habitudes du patient. Ces données peuvent être par exemple :
• L’horaire et quantité des repas
• Heure, durée et intensité des activités sportives
• Le taux de sucre dans le sang (mesuré par un BGM ou idéalement par un CGM)
• Le profil estimé de l’insuline présente dans le sang du patient (IOB)
• Horaire et volume des bolus
• Type de bolus (normal, extended, dual wave) De plus, des données non-relatives à la thérapie mais relative à la façon dont le patient utilise le dispositif peuvent aussi être utilisées pour identifier le comportement et apprendre quelles sont les habitudes du patient, par exemple :
• L’horaire et fréquence d’utilisation/consultation du dispositif
• L’interaction avec l’interface utilisateur
• temps passé dans chaque étape/page du menu
• rythme de saisie au clavier
• position exacte d’un « click » sur un écran tactile
Le dispositif d’apprentissage peut en outre apprendre des précédentes erreurs du patient. Par exemple, si le patient fait une erreur de saisie fréquente, le système peut demander au patient une confirmation à chaque fois que cette erreur est renouvelée.
Selon certains modes de réalisation, le dispositif d’apprentissage peut comprendre un produit de programme informatique configuré pour reconnaître si une manipulation du système médical correspond à une manipulation prédéfinie et enregistrée dans une mémoire du système de manière à définir un niveau de conformité/plausibilité avec un modèle de comportement. Le produit programme informatique peut être adapté pour comparer un nouveau comportement avec un ancien comportement pour définir le niveau de sécurité et/ou pour faire évoluer le modèle de comportement.
Selon certains modes de réalisation, le produit de programme informatique, lorsqu'il est chargé dans le un système médical, peut exécuter au moins une des étapes suivantes :
Définition d’un modèle de comportement basé sur au moins un comportement précédent ou sur un modèle pré chargé / générique / ancien,
Reconnaissance d’un / surveillance du / enregistrement d’un / prise en compte d’un comportement d’un utilisateur,
Evaluation de la plausibilité de ce comportement à l’aide du modèle de comportement, Définition / détermination d’un niveau de sécurité en fonction de la plausibilité de ce comportement,
En cas de plausibilité relativement faible (par exemple au-dessous d’un seuil définit ou en fonction d’un tableau ou d’un arbre de décision), augmenter le niveau de sécurité, par exemple demander une confirmation ou authentification supplémentaire),
En cas de plausibilité relativement haute (par exemple au-dessus d’un seuil définit ou en fonction d’un tableau ou d’un arbre de décision), diminuer le niveau de sécurité, par exemple ne pas demander de confirmation ou d’authentification, et/ou
Optionnellement, mise à jour du modèle de comportement à partir d’un nouvel enregistrement de comportement, prenant en compte le résultat d’une potentielle demande de confirmation.
Optionnellement, le produit programme informatique est adapté pour retrouver dans une mémoire les données d’enregistrement d’anciens comportements ou du modèle de comportement.
Selon certains modes de réalisation, un système basé sur le machine learning peut être utilisé pour détecter un comportement qui est habituel ou inhabituel pour ce patient. Dans ce cas, le programme informatique peut réagir à la demande atypique par différents moyens, par exemple
Demander une confirmation (e.g., « êtes-vous sûr de vouloir cette quantité d’insuline ?)
Demander une authentification supplémentaire (e.g., « Action inhabituelle détectée : veuillez confirmer en rentrant votre pin / avec un fingerprint / face récognition etc).
La figure 4 illustre un exemple de fonctionnement de base d’un tel système. Les actions de l’utilisateur sont évaluées par un modèle de comportement, qui peuvent avoir été créé par des méthodes de machine learning à partir de l’historique des actions de l’utilisateur (ou d’un modèle de comportement générique), comme étant plausibles ou non plausibles. Si l’action est évaluée comme étant plausible, elle est appliquée. Si elle est évaluée comme étant non plausible, le système demande à l’utilisateur de confirmer l’action avant de l’appliquer.
Si le dispositif peut accéder à une évaluation de la qualité du traitement (soit calculée par le dispositif à partir de mesures de l’état physiologique du patient, soit fournie par le patient lui- même ou par le personnel médical), cette donnée pourrait être utilisée pour enrichir le modèle de comportement avec la notion de comportement « risqué » ou « non-risqué » en plus de la notion de « plausibilité ».
Une absence d’utilisation du System peut également être considérée comme un comportement inhabituel (un certain lapse de temps sans utilisation, une absence d’utilisation sur une certaine tranche horaire). Dans ce cas, le dispositif pourrait se manifester par une alarme ou une notification à l’utilisateur par un autre moyen de communication (smartphone).
Un autre exemple de fonctionnement du système est représenté sur le diagramme de la figure 5, basé sur le même concept que la figure 4 mais dont l’objectif est l’identification de l’utilisateur.
Un autre exemple de fonctionnement du système est représenté sur le diagramme de la figure 6, basé sur le même concept que la figure 4 mais dont l’objectif est l’identification de l’environnement.
Selon certains modes de réalisation, le système peut être configuré pour ajuster le niveau de sécurité en fonction de ce comportement (du comportement présent) ou en fonction du résultat de la détection. Ainsi, un comportement habituel permettra de ne pas demander d’authentification (code PIN, ...) ou de confirmation (par exemple : « êtes-vous sûr de... » ou « veuillez confirmer ... ») ou de demander seulement une confirmation mais pas d’authentification. A l’inverse un comportement atypique incitera le système à demander au moins une confirmation et/ou une authentification. Le niveau de sécurité peut être graduel, ainsi dans le cas extrême, le système pourrait demander plusieurs authentifications et confirmation, par exemple une confirmation suivit d’un PIN et d’une authentification de l’empreinte digitale de l’utilisateur. Dans le même esprit, si le comportement détecté est par exemple une erreur du PIN, le système peut demander un autre type d’authentification par exemple une empreinte digitale. Une implémentation alternative serait de toujours demander authentification pour les actions dangereuses, et une confirmation supplémentaire pour les actions atypiques, dans ce cas le système pourrait être configuré pour mettre en évidence le comportement atypique détecté afin d’exposer à l’utilisateur le comportement atypique détecter et de demander une confirmation (via par exemple un seul affichage ou une succession d’affichages). Ainsi, le système pourrait afficher sur l’écran « vous avez paramétré ... alors que d’habitude vous paramétré ... » ainsi que « veuillez confirmer le paramètre » ou « veuillez confirmer le paramètre en entrant à nouveau le paramètre désiré ». Cela peut permettre de forcer l’utilisateur à prendre connaissance de l’erreur potentielle et de devoir réécrire si le paramètre est bien celui désiré.
Selon certains modes de réalisation, le système médical et/ou le dispositif d’apprentissage peut comprendre un processeur couplé à un écran, un dispositif d’entré (par exemple un clavier, des boutons, des capteurs, un écran tactile,...) et une mémoire. Le processeur est préférentiellement configuré pour reconnaître et/ou définir un comportement basé sur les données renseignées via le dispositif d’entré. Le processeur peut être configuré pour déterminer un niveau de plausibilité d’un comportement et un niveau de sécurité en fonction du niveau de plausibilité. En fonction du niveau de sécurité, le système peut être configuré pour afficher une requête d’authentification ou de validation sur l’écran.
La figure 7 illustre un exemple de fonctionnement de base d’un tel système. Les actions de l’utilisateur sont évaluées par un modèle de comportement, qui peuvent avoir été créé par des méthodes de machine learning à partir de l’historique des actions de l’utilisateur (ou d’un modèle générique). L’analyse permet de déterminer un niveau de sécurité nécessaire pour appliquer l’action. Si le niveau de sécurité est faible car il s’agit d’un comportement classique de l’utilisateur alors (par exemple) aucune autre action pourra être nécessaire pour appliquer l’action. Si le niveau de sécurité est moyen car il s’agit d’un comportement relativement classique de l’utilisateur alors (par exemple) une simple étape de validation pourra être demandé pour appliquer l’action. Si le niveau de sécurité est important car il s’agit d’un comportement inhabituel de l’utilisateur alors, l’utilisateur devra s’authentifier pour appliquer l’action (par exemple en plus d’une étape de validation).
Un autre exemple de fonctionnement du système est représenté sur le diagramme de la figure 8, basé sur le même concept que la figure 7 mais dont l’objectif est l’identification de l’environnement.
Selon certains modes de réalisation, le système est préférentiellement portatif, c’est-à-dire un dispositif autoalimenté (par batterie, capteur solaire ou autre) et dont la taille, le poids et la forme lui permette d’être manipulé par une main d’un utilisateur, pouvant par exemple entré dans la poche de l’utilisateur.
Un autre exemple de fonctionnement du système est représenté sur le diagramme de la figure 9, basé sur le même concept que les figures 4, 5, 6, 7 et 8. Une phase d’initialisation peut être nécessaire pour que le système puisse créer un modèle du comportement typique de l’utilisateur. Pendant cette phase, toutes les actions peuvent être considérées comme plausibles ou au contraire potentiellement risquées et nécessiter un niveau de sécurité important. Cette phase d’initialisation peut être évitée en définissant un modèle de comportement générique comme cité au-dessus. Plusieurs possibilités sont envisageables pour le modèle - Bayes Classifiers, Support vector machines, Gaussian mixture models, Artificial neural networks, etc.
Ensuite, une action de l’utilisateur et/ou le contexte dans lequel cette action est effectuée peuvent être prises en compte pour évaluer la plausibilité de l’action. Là aussi plusieurs données sont envisageables.
Selon certain mode de réalisation, si une action est considérée plausible, elle peut être acceptée (par exemple sans demander confirmation ou avec un niveau d’authentification faible) et elle peut enrichir le modèle de comportement.
Si l’action est considérée non plausible, une validation supplémentaire peut être demandée à l’utilisateur. Cette validation peut être un simple prompt « oui/non », une demande de PIN, une demande de fingerprint, ou d’autres méthodes plus avancés. Si la validation supplémentaire échoue (e.g., l’utilisateur répond « non »), l’action n’est pas effectuée. Optionnellement, cette action est prise en compte dans le modèle en tant que contre-exemple, afin de mieux détecter les fausses actions par la suite.
Lorsque le patient fait une erreur d’estimation de glucides de son repas par exemple, le système peut avertir le patient que la dose prévue est inhabituelle. Dans ce cas, le patient a une meilleure chance de voir son erreur. Autre exemple, si le patient a l’habitude de manger un repas important le dimanche midi et de commander un bolus de type dual wave ou allongé pour ce type de repas, alors dans le cas où le patient commanderait finalement un simple bolus un dimanche midi, le système pourrait demander confirmation au patient qu’il souhaite bien ce type de bolus.
Lorsque quelqu’un d’autre utilise la télécommande du patient (soit par erreur ou avec l’intention de nuire), le système peut demander une authentification supplémentaire, ce qui empêcherait une tierce personne d’exécuter des commandes liés à la thérapie. Par exemple, le système peut détecter une action inhabituelle grâce au modèle de comportement, par exemple sur la base d’un horaire inhabituel d’utilisation de la télécommande, de valeurs inhabituelles des paramètres d’entrés ou d’une manipulation différente (tenue, emplacement précis des clicks, temps passé sur chaque écran), et peut demander une authentification ou validation supplémentaire.
Selon certains modes de réalisation, le système peut comprendre un dispositif de communication sans fil de manière à pouvoir communiquer avec un serveur distant. Néanmoins, le système peut être configuré pour effectuer le traitement des données (de comportement) par le processeur du système de manière à ce que le traitement des données ne soit pas dépendant de la disponibilité d’un serveur distant ou de la connexion à un serveur distant.
Selon certains modes de réalisation, le système médical peut comprendre un dispositif de reconnaissance facial comprenant un capteur optique (par exemple une caméra) et un processor (par exemple le processeur du système) configuré pour effectuer un traitement des données envoyées par le capteur optique permettant de reconnaître l’utilisateur. L’utilisateur peut être le patient lui-même ou un soignant (parent, docteur, infirmier, ...). Le système peut comprendre des règles de fonctionnement en fonction du type d’utilisateur. Par exemple, un utilisateur principal peut être un patient et un autre utilisateur peut être un médecin ayant des droits d’accès plus important. Si l’utilisateur n’est pas l’utilisateur principal (par exemple le patient lui-même ou la personne qui gère normalement le traitement tel qu’un parent, un docteur, un infirmier, ...), alors le système peut demander une authentification et/ou une confirmation supplémentaire comme décrit ci-avant. Selon certains modes de réalisation, le système peut vérifier en plus la compliance au traitement et les données du patient avant afin de ne pas valider même en cas de forte plausibilité.
Selon certains modes de réalisation, le document décrit également un procédé de sécurité pour l’exécution d’une commande par un dispositif médical, comprenant les étapes suivantes :
réception d’une requête
identification d’un environnement ou un comportement par un dispositif d’observation comprenant un capteur
détermination d’un niveau de plausibilité de la requête en fonction de l’étape de l’identification,
détermination d’un niveau d’authentification nécessaire pour l’exécution d’une requête par un dispositif médical

Claims

Revendications
1. Système médical adapté pour identifier un utilisateur comprenant :
Un dispositif de mémoire pour stocker un modèle de comportement,
Un capteur configuré pour observer un comportement de l’utilisateur utilisant le système médical et
Un processeur couplé de manière opérationnelle au dispositif de mémoire et au capteur ;
Dans lequel le processeur est configuré pour
Recevoir des données relatives à un comportement actuel de l’utilisateur transmises par le capteur,
Analyser le comportement actuel en prenant en compte le modèle de comportement enregistré dans le dispositif de mémoire,
Valider ou non l’identité de l’utilisateur comme étant un utilisateur autorisé.
2. Système médical selon la revendication 1 dans lequel le modèle de comportement est un modèle de comportement générique.
3. Système médical selon la revendication 1 dans lequel le processeur est configuré pour créer ou adapter le modèle de comportement en fonction de données de comportements passés.
4. Système médical selon la revendication 2 dans lequel le modèle de comportement est adapté à l’utilisateur.
5. Système médical selon l'une quelconque des revendications précédentes, dans lequel le processeur est configuré pour définir un niveau de sécurité en fonction du résultat de l’étape d’analyse.
6. Système médical selon l'une quelconque des revendications précédentes, comprenant en outre un dispositif d’entré, dans lequel le processeur est en outre configuré pour recevoir des données transmises par le dispositif d’entré.
7. Système médical selon la revendication 6 dans lequel le dispositif d’entré est en outre configuré pour permettre à l’utilisateur d’entrer une requête à exécuter par le système médical.
8. Système médical selon la revendication 7 dans lequel le processeur est en outre configuré pour analyser la requête de l’utilisateur en fonction du modèle de comportement.
9. Système médical selon l'une quelconque des revendications précédentes comprenant en outre un capteur d’environnement configuré pour transmettre au processeur des données relative à l’environnement ou la situation dans lequel le système est utilisé.
10. Système médical selon la revendication 9 dans lequel le processeur est en outre configuré pour analyser l’environnement actuel en fonction d’un modèle d’environnement.
11 . Système médical selon l'une quelconque des revendications précédentes comprenant un écran configuré pour transmettre des informations à ou alerter l’utilisateur.
12. Système médical selon la revendication 11 dans lequel le processeur est en outre configuré pour informer l’utilisateur du résultat de la ou les analyses.
13. Système médical selon l'une quelconque des revendications précédentes dans lequel le processeur est en outre configuré pour exécuter ou non une requête en fonction du résultat de la ou les analyses.
14. Méthode pour identifier un utilisateur d’un système médical comprenant les étapes suivantes :
Recevoir des données transmises par un capteur relatives à un comportement de l’utilisateur utilisant le système médical,
Analyser le comportement de l’utilisateur en prenant en compte un modèle de comportement,
Identifier l’utilisateur comme étant un utilisateur autorisé à utiliser le système médical en fonction du résultat de l’analyse.
15. Système médical adapté pour identifier un environnement dans lequel le système médical est utilisé par un utilisateur comprenant :
Un dispositif de mémoire pour stocker des données relatives à un modèle d’environnement,
Un capteur configuré pour acquérir des données relatives à un environnement et Un processeur couplé de manière opérationnelle au dispositif de mémoire et au capteur
Dans lequel le processeur est configuré pour
Recevoir des données relatives à l’environnement actuel transmises par le capteur, Analyser l’environnement actuel en prenant en compte les données relatives au modèle d’environnement enregistré dans le dispositif de mémoire,
Déterminer si l’environnement actuel est un environnement sécurisé.
16. Méthode pour identifier un environnement dans lequel un système médical est utilisé par un utilisateur comprenant les étapes suivantes :
Observer l’environnement actuel du système médical,
Analyser l’environnement actuel en prenant en compte à des données relatives à un modèle d’environnement déterminé,
Déterminer si l’environnement actuel est un environnement sécurisé ou non en fonction du résultat de l’analyse.
17. Système médical adapté pour exécuter une requête commandée par un utilisateur comprenant :
Un dispositif de mémoire pour stocker un modèle de comportement,
Un dispositif d’entré configuré pour permettre l’observation du comportement d’un utilisateur et
Un processeur couplé de manière opérationnelle au dispositif de mémoire et au dispositif d’entré
Dans lequel le processeur est configuré pour
Recevoir des données relatives au comportement de l’utilisateur actuel transmises par le dispositif d’entré,
Analyser le comportement de l’utilisateur actuel en prenant en compte le modèle de comportement enregistré dans le dispositif de mémoire et
Définir un niveau de plausibilité du comportement.
18. Méthode pour valider l’exécution d’une requête commandée par un utilisateur en fonction de son comportement comprenant les étapes suivantes :
Observer un comportement de l’utilisateur,
Analyser le comportement de l’utilisateur en prenant en compte un modèle de comportement déterminé,
Définir un niveau de plausibilité de la requête en fonction du résultat de l’analyse et Exécuter la requête de l’utilisateur en fonction du niveau de plausibilité défini lors de l’étape précédente.
19. Système médical adapté pour définir un niveau de sécurité nécessaire pour exécuter une requête comprenant :
Un dispositif de mémoire pour stocker un modèle de comportement,
Un dispositif d’entré configuré pour observer le comportement d’un utilisateur et Un processeur couplé de manière opérationnelle au dispositif de mémoire et au dispositif d’entré;
Dans lequel le processeur est configuré pour Recevoir des données relatives à un comportement de l’utilisateur transmises par le dispositif d’entré,
Analyser le comportement de l’utilisateur en prenant en compte le modèle de comportement enregistré dans le dispositif de mémoire,
Déterminer un niveau de sécurité nécessaire pour l’exécution de la requête et Exiger que le niveau de sécurité nécessaire défini soit satisfait pour exécuter la requête.
20. Méthode pour définir un niveau de sécurité nécessaire pour exécuter une requête comprenant les étapes suivantes :
Observer un comportement d’un utilisateur actuel,
Analyser le comportement en prenant en compte un modèle de comportement déterminé et
Définir un niveau de sécurité nécessaire pour l’exécution de la requête en fonction du résultat de l’analyse.
21 . Système médical sécurisé adapté pour définir un niveau de sécurité en fonction de l’environnement du système médical comprenant :
Un dispositif de mémoire pour stocker des données relatives à un modèle d’environnement,
Un capteur configuré pour acquérir des données relatives à l’environnement du système médical et
Un processeur couplé de manière opérationnelle au dispositif de mémoire et au capteur
Dans lequel le processeur est configuré pour
Recevoir des données relatives à l’environnement actuel transmises par le capteur, Analyser l’environnement actuel en prenant en compte les données relatives au modèle d’environnement enregistré dans le dispositif de mémoire et
Définir un niveau de sécurité adapté à l’environnement en se basant sur le résultat de l’analyse.
22. Méthode pour définir un niveau de sécurité en fonction de l’environnement du système médical comprenant les étapes suivantes :
Observer l’environnement actuel du système médical,
Analyser l’environnement actuel en prenant en compte les données relatives à un modèle d’environnement déterminé et
Définir un niveau de sécurité adapté à l’environnement adapté en se basant sur le résultat de l’analyse.
23. Un produit de programme informatique comprenant :
un agent observateur configuré pour générer des informations relatives aux comportements actuels de l’utilisateur en fonction de données transmises par au moins un dispositif d’entré; un agent comparateur configuré pour comparer les informations relatives aux comportements actuel de l’utilisateur avec un modèle de comportement ; et un agent évaluateur configuré pour affecter le comportement observé à une zone de confiance sur la base du résultat de l’agent comparateur ou pour déterminer l’identité de l’utilisateur sur la base du résultat de l’agent comparateur.
24. Un produit de programme informatique comprenant :
un agent observateur configuré pour générer des informations relatives à l’environnement actuel de l’utilisateur en fonction de données transmises par au moins un dispositif d’entré;
un agent comparateur configuré pour comparer les informations relatives à l’environnement actuel de l’utilisateur avec un ou plusieurs modèles d’environnement; et
un agent évaluateur configuré pour affecter l’environnement observé à une zone de confiance sur la base du résultat de l’agent comparateur ou pour déterminer le type d’environnement de l’utilisateur sur la base du résultat de l’agent comparateur.
PCT/IB2019/061197 2018-12-21 2019-12-20 Dispositif médical sécurisé WO2020129008A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP18215753 2018-12-21
EP18215752.9 2018-12-21
EP18215752 2018-12-21
EP18215753.7 2018-12-21

Publications (1)

Publication Number Publication Date
WO2020129008A1 true WO2020129008A1 (fr) 2020-06-25

Family

ID=69165447

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2019/061197 WO2020129008A1 (fr) 2018-12-21 2019-12-20 Dispositif médical sécurisé

Country Status (1)

Country Link
WO (1) WO2020129008A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116861496A (zh) * 2023-09-04 2023-10-10 合肥工业大学 一种智慧医疗信息安全显示方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140298022A1 (en) 2011-10-28 2014-10-02 Debiotech S.A. Mobile virtualization platform for the remote control of a medical device
US20150207626A1 (en) 2012-07-09 2015-07-23 Debiotech S.A. Communication secured between a medical device and its remote control device
WO2018162318A1 (fr) * 2017-03-09 2018-09-13 Roche Diabetes Care Gmbh Commande d'accès d'utilisateur à un système médical

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140298022A1 (en) 2011-10-28 2014-10-02 Debiotech S.A. Mobile virtualization platform for the remote control of a medical device
US20150207626A1 (en) 2012-07-09 2015-07-23 Debiotech S.A. Communication secured between a medical device and its remote control device
WO2018162318A1 (fr) * 2017-03-09 2018-09-13 Roche Diabetes Care Gmbh Commande d'accès d'utilisateur à un système médical

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DANDACHI GHINA ET AL: "A novel identification/verification model using smartphone's sensors and user behavior", 2013 2ND INTERNATIONAL CONFERENCE ON ADVANCES IN BIOMEDICAL ENGINEERING, IEEE, 11 September 2013 (2013-09-11), pages 235 - 238, XP032777971, ISBN: 978-1-4799-0249-1, [retrieved on 20131028], DOI: 10.1109/ICABME.2013.6648891 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116861496A (zh) * 2023-09-04 2023-10-10 合肥工业大学 一种智慧医疗信息安全显示方法及系统

Similar Documents

Publication Publication Date Title
AU2021215191B2 (en) Systems and methods for remote and host monitoring communications
JP6901395B2 (ja) 連続的グルコースデータを配信するためのシステム及び方法
CN104885089B (zh) 分析物测量的远程监测
EP2761429B1 (fr) Accès à des données sécurisées basé sur l'observation des politiques
US20150135284A1 (en) Automatic electronic device adoption with a wearable device or a data-capable watch band
CN108334809B (zh) 用于虹膜识别的电子装置及其操作方法
US9811997B2 (en) Mobile safety platform
US20190328616A1 (en) Pill dispensing assembly
KR102365412B1 (ko) 전자 장치 및 전자 장치에서의 지문 인증을 위한 방법
US8805702B1 (en) Interactive medical card and method of processing medical information stored thereon
WO2020129008A1 (fr) Dispositif médical sécurisé
US9992327B1 (en) Interaction lock mode for mobile devices
US20170091415A1 (en) Medication adherence
US20220336096A1 (en) Global configuration service
FR3008509A1 (fr) Application medicale executee par un objet communicant, objet communicant et utilisation d'un objet communicant
WO2021050235A1 (fr) Traitement par utilisation de dispositif pour générer des états inférés d'utilisateur
WO2015073741A1 (fr) Adoption automatique de dispositif électronique avec un dispositif vêtement ou un bracelet-montre à fonction de communication de données
WO2019008296A1 (fr) Dispositif de mesure de parametres physiologiques d'un individu humain ou animal
US20220366027A1 (en) Using Continuous Biometric Information Monitoring For Security
US20240203584A1 (en) Continuous glucose monitoring follower and social support enhancements
WO2018057544A1 (fr) Systèmes et procédés de génération d'affects de conscience à l'aide d'une ou de plusieurs entrées non biologiques
FR3034599A1 (fr) Procede de commande securisee d’un telephone mobile par un dispositif electronique porte et dispositif electronique adapte a etre porte associe
US10516762B2 (en) System for remotely running a service program
KR20240125668A (ko) 생리학적 센서들을 이용한 웰니스 모니터링을 위한 시스템들, 디바이스들, 및 방법들
CN118510445A (zh) 利用生理传感器进行健康监测的系统、设备和方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19836585

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19836585

Country of ref document: EP

Kind code of ref document: A1