WO2023208775A1 - Résolution d'incertitude de jumeau numérique - Google Patents

Résolution d'incertitude de jumeau numérique Download PDF

Info

Publication number
WO2023208775A1
WO2023208775A1 PCT/EP2023/060462 EP2023060462W WO2023208775A1 WO 2023208775 A1 WO2023208775 A1 WO 2023208775A1 EP 2023060462 W EP2023060462 W EP 2023060462W WO 2023208775 A1 WO2023208775 A1 WO 2023208775A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
computer
information
type
indirectly
Prior art date
Application number
PCT/EP2023/060462
Other languages
English (en)
Inventor
Lieke Gertruda Elisabeth Cox
Murtaza Bulut
Valentina LAVEZZO
Cornelis Petrus Hendriks
Elise Claude Valentine TALGORN
Vincentius Paulus Buil
Monique Hendriks
Original Assignee
Koninklijke Philips N.V.
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 Koninklijke Philips N.V. filed Critical Koninklijke Philips N.V.
Publication of WO2023208775A1 publication Critical patent/WO2023208775A1/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/67—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 remote operation
    • 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
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • 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
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/50—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for simulation or modelling of medical disorders
    • 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
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records

Definitions

  • a digital twin is an example type of a predictive model, which includes a digital representation of one or more aspects of physiology of a person, and is used to predict a suspected physiological state of the user.
  • the digital twin receives input data specific to the person from physical counterparts, such as through sensor measurements or via manual inputs.
  • the digital representation may be or include a computational simulation, and may be or include a biophysical model and/or one or more artificial intelligence (Al) algorithm(s).
  • Digital twins offer clinicians advanced interactive visualization and physical insights of relevant health information of the person.
  • CDS clinical decision support
  • a digital twin may constantly or intermittently screen for health issues. When the digital twin notices changes that may indicate deterioration of health, and determines possible underlying causes, the determinations may sometimes be inconclusive. The digital twin may be used to alert the person that something might be wrong, but such warnings may cause unnecessary stress if they result from false positives.
  • a computer includes a memory and a processor.
  • the memory stores instructions.
  • the processor executes the instructions.
  • the instructions cause the computer to: obtain output from a predictive model that digitally represents physiology of a user and that predicts states of the physiology of the user; determine, based on the output from the predictive model, a type of information to indirectly, i.e. without requiring an action or awareness from the user, collect from the user; transmit an instruction to a counterpart device to indirectly collect the type of information from the user; receive, from the counterpart device, the type of information collected from the user; and input, to the predictive model, the type of information indirectly collected from the user to update a prediction for the physiology of the user.
  • a method for implementing a predictive model includes: obtaining, via a computer having a memory that stores instructions and a processor that executes the instructions, output from a predictive model that digitally represents physiology of a user and that predicts states of the physiology of the user; determining, based on the output from the predictive model, a type of information to indirectly collect from the user; transmitting an instruction to a counterpart device to indirectly collect the type of information from the user; receiving, from the counterpart device, the type of information collected from the user; and inputting, to the predictive model, the type of information indirectly collected from the user to update a prediction for the physiology of the user.
  • a system for implementing a predictive model includes a computer and a counterpart device.
  • the computer has a memory that stores instructions and a processor that executes the instructions.
  • the instructions When executed by the processor, the instructions cause the computer to: obtain output from a predictive model that digitally represents physiology of a user and that predicts states of the physiology of the user; determine, based on the output from the predictive model, a type of information to indirectly collect from the user; transmit an instruction to the counterpart device to indirectly collect the type of information from the user; receive, from the counterpart device, the type of information collected from the user; and input, to the predictive model, the type of information indirectly collected from the user to update a prediction for the physiology of the user.
  • FIG. 1A illustrates a system for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • FIG. IB illustrates a network for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • FIG. 1C illustrates a device for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • FIG. ID illustrates a controller for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • FIG. 2A illustrates a progression for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • FIG. 2B illustrates a system for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • FIG. 3 illustrates a method for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • FIG. 4 illustrates another progression for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • FIG. 5 illustrates a computer system, on which a method for digital twin uncertainty resolution is implemented, in accordance with another representative embodiment.
  • digital twin predictions may be improved by capturing user perception data in an unobtrusive way.
  • the capture of user perception data may be triggered by digital twin predictions which do not meet criteria such as certainty thresholds.
  • Perception data is a form of data indirectly collected from patients, though other forms of data that do not specifically reflect a patient perception may also be indirectly collected and input to a predictive model using the teachings herein.
  • sensors may collect data from a patient while the patient is sleeping, and such data is not particularly perception data that reflects a perception of the user but which is still input and processed by the predictive models described herein.
  • sleep data which may be collected may include audio data from snoring, movement data from movement sensors, and so on.
  • perception data may reflect both conscious and unconscious perceptions, such as unconscious perceptions reflected subtly by patient speech and actions, and which is collected without the patient being disturbed.
  • inventive concepts also encompass a tangible, non-transitory computer readable medium that stores instructions that cause a processor to execute the methods described herein.
  • a computer readable medium is defined to be any medium that constitutes patentable subject matter under 35 U.S.C. ⁇ 101 and excludes any medium that does not constitute patentable subject matter under 35 U.S.C. ⁇ 101. Examples of such media include non-transitory media such as computer memory devices that store information in a format that is readable by a computer or data processing system. More specific examples of non-transitory media are noted below.
  • certain “modules” described herein comprise computer-executable instructions (“instructions”) stored in a tangible, non-transitory computer- readable medium as contemplated herein, and executed by a processor.”
  • FIG. 1A illustrates a system for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • the system 100 in FIG. 1A is a system for digital twin uncertainty resolution and includes components that may be provided together or that may be distributed.
  • the system 100 includes a computer 110, a display 180, an Al training system 195, a first counterpart device 101A, a second counterpart device 10 IB and a third counterpart device 101C. While an Al training system 195 is shown in FIG. 1A, predictive models described herein may be implemented also without artificial intelligence in some embodiments, and therefore without requiring an Al training system 195.
  • the computer 110 includes a memory that stores instructions, and a processor that executes the instructions.
  • the computer 110 may be a server computer that implements digital twins for multiple patients, such as for a hospital or for a health care system.
  • An example of a computer system that can be used to implement the computer 110 is shown by and explained with respect to the computer system 500 in FIG. 5.
  • the computer 110 may include at least a controller 150 as shown in and explained with respect to FIG. ID.
  • Functionality attributed to the computer 110 herein may be performed by multiple computers, such as by multiple servers at a data center in a network cloud 140 as shown in and explained with respect to FIG. IB.
  • the computer 110 is used to implement a predictive model such as a digital twin model that digitally represents physiology of a user such as a patient. As described herein, the computer 110 is also used to implement one or more additional software programs which obtain output from the predictive model such as a digital twin model, which perform logical operations, and which initiate electronic communications between the computer 110 and the first counterpart device 101 A, the second counterpart device 101B and the third counterpart device 101C. The electronic communications are initiated by the computer 110 based on the output from the predictive model such as a digital twin model.
  • references to a digital twin model may be understood as pertaining more generally to a predictive model.
  • the display 180 may be local to the computer 110 or may be remotely connected to the computer 110.
  • the display 180 may be connected to the computer 110 via a local wired interface such as an Ethernet cable or via a local wireless interface such as a Wi-Fi connection.
  • the display 180 may be interfaced with other user input devices by which users can input instructions, including mouses, keyboards, thumbwheels and so on.
  • the display 180 may be a monitor such as a computer monitor, a display on a mobile device, an augmented reality display, a television, an electronic whiteboard, or another screen configured to display electronic imagery.
  • the display 180 may also include one or more input interface(s) that may connect other elements or components to the computer 110.
  • the display 180 may also or alternatively include an interactive touch-sensitive input screen or pad configured to display prompts to users and collect touch input from users.
  • the Al training system 195 provides trained artificial intelligence models.
  • the Al training system 195 may develop and provide digital twin models trained to predict whether corresponding users have conditions such as diseases.
  • the Al training system 195 may be provided by the same entity that provides the computer 110, such as when the computer 110 is provided by a hospital system or other large enterprise.
  • the Al training system 195 may be provided by a third- party service that develops software such as trained artificial intelligence models for customers. Data input to a digital twin that is specific to a user may be used to predict the actual or future (health) state of the user as well as health risks.
  • One or more of the first counterpart device 101A, the second counterpart device 101B and the third counterpart device 101C may be provided by the same entity that provides the computer 110.
  • the computer 110 and one or more of the first counterpart device 101A, the second counterpart device 10 IB and the third counterpart device 101C may be provided by a hospital system or other large enterprise.
  • One or more of the first counterpart device 101A, the second counterpart device 10 IB and the third counterpart device 101C may be (medical) equipment that includes sensors that sense physiological characteristics of patients.
  • one or more of the first counterpart device 101 A, the second counterpart device 10 IB and the third counterpart device 101C may be personal equipment used by the patient, such as a wearable fitness monitor, a smart phone, a tablet, laptop computer or desktop computer, or another type of electronic communication device configured to communicate over an electronic communication network.
  • FIG. IB illustrates a network for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • the network 102 in FIG. IB includes a network cloud 140, the first counterpart device 101A, the second counterpart device 101B and the third counterpart device 101C.
  • the network cloud 140 is representative of a distributed cloud network in which multiple computers such as servers in one or more data centers provide the functionality otherwise attributed to the computer 110 in FIG. 1A.
  • digital twins and digital twin uncertainty resolution may be provided as a service in the network cloud 140 for multiple distributed facilities such as hospitals or other medical facilities.
  • the digital twin uncertainty resolution may be provided in parallel as a service for multiple users each corresponding to their own digital twin.
  • FIG. 1C illustrates a device for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • the device 103 includes a controller 150 and a display 180.
  • the device 103 is connected to the first counterpart device 101A, the second counterpart device 101B and the third counterpart device 101C.
  • the device 103 may be a dedicated device that is dedicated to providing one or more digital twin to one or more patients, such as in a home or office.
  • the device 103 is also used to implement the digital twin uncertainty resolution described herein.
  • An example of a computer system that can be used to implement the device 103 is shown by and explained with respect to the computer system 500 in FIG. 5.
  • the device 103 may include at least a controller 150 as shown in and explained with respect to FIG. ID.
  • FIG. ID illustrates a controller for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • the controller 150 includes a memory 151, a processor 152, a first interface 156, a second interface 157, a third interface 158, and a fourth interface 159.
  • the memory 151 stores instructions which are executed by the processor 152.
  • the first interface 156, the second interface 157 and the third interface 158 may include ports, disk drives, wireless antennas, or other types of receiver circuitry that interface the controller 150 to other devices such as the display 180.
  • the fourth interface 159 may include a user interface to user input devices such as a keyboard, mouse or other input device by which a user may input instructions to the computer 110 in FIG. 1A or the device 103 in FIG. 1C.
  • the controller 150 may perform some of the operations described herein directly and may implement other operations described herein indirectly.
  • the controller 150 may perform logical operations described herein directly, and the controller 150 may indirectly control other operations such as by generating and transmitting content to be displayed on the display 180. Accordingly, the processes implemented by the controller 150 when the processor 152 executes instructions from the memory 151 may include steps not directly performed by the controller 150.
  • FIG. 2A illustrates a progression for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • the progression in FIG. 2A includes the digital twin model 299, a data request algorithm 211, a data collection trigger unit 220, patient perception analysis module 230, patient perception data collection module 240, and a user interface 250.
  • the elements of the progression in FIG. 2A may include artificial intelligence models implemented by the computer 110 in FIG. 1A, the network cloud 140 in FIG. IB or the device 103 in FIG. 1C.
  • the digital twin model 299 is a digital representation or computational simulation of some or all of the physiology of a user.
  • the digital twin model 299 predicts states of the physiology of the user, and updates predictions based on the digital twin uncertainty resolution described herein.
  • the digital twin model 299 receives input data from the user, such as through sensor measurements or manual inputs. The input data is used to predict the actual or future health state of the user as well as health risks.
  • the digital twin model 299 may comprise a biophysical model and/or one or more artificial intelligence algorithm(s). Output from the digital twin model 299 is provided as a simulated health state to the data request algorithm 211. Output from the digital twin model 299 is also provided as a simulated health state and a risk prediction to the user interface 250.
  • the digital twin uncertainty resolution described herein provides selectively-collected data as feedback for the digital twin model 299, so that the digital twin model 299 can update a prediction for the physiology of the user.
  • the data request algorithm 211 takes as its input the simulated/ predicted health state of the user from the digital twin model 299.
  • the simulated/predicted health state may include a suspected disease or medical condition.
  • the data request algorithm 211 outputs perception data requirements to the data collection trigger unit 220 and to the patient perception analysis module 230.
  • the output from the data request algorithm 211 may include control parameters such as settings and specifications that indicate what user data is to be collected, when, and in what conditions.
  • the data request algorithm 211 may derive symptoms associated with the suspected disease or medical condition, such as by using knowledge-based or data driven approaches. Depending on the disease and associated symptoms the perception data requirements are then generated.
  • the perception data requirements may be or include a list or description which contains instructions on measurements to be indirectly collected from a user in order to improve a risk prediction for a given health state.
  • the indirect collection of data from a user may be unobtrusive, such that the user may not notice the data that is being collected, or such that the collection of data is noticeable but not particularly intrusive or conspicuous. Indirect, unobtrusive collection of data may not require action from the user or awareness by the user.
  • Perception data requirements may specify which data to collect, which mode to use to collect the data, granularity of the data to be collected, measurement ranges for the data to be collected, duration of the data collection, conditions to be satisfied in order to trigger the data collection, thresholds and more.
  • perception data requirements output by the data request algorithm 211 may specify audio such as speech or breathing, video such as facial expression or skin complexion, and/or heart rate and/or galvanic skin response.
  • Perception data requirements may specify the measurement range, resolution, and/or duration for collecting the perception data.
  • Perception data requirements may specify conditions for triggering indirect collection of a type of perception data from the user, such as after a period where a certain activity threshold was reached, after a certain trigger word is heard, during sleep, at a specific time of the day, or when an arrhythmia episode is suspected.
  • trigger words may include (variations of) the symptoms themselves, which are then used to detect from audio whether the patient is talking about experiencing a symptom or for example is searching online on such symptoms.
  • Perception data requirements may also specify which patient perception data is to be derived from specified measured variables. As an example, when data should be collected during or after an active period, activity data derived from a fitness tracker or smartphone application may be used as trigger data.
  • the data collection trigger unit 220 receives trigger data, such as from the counterpart devices in FIG. 1A, FIG. IB and FIG. 1C.
  • the data collection trigger unit 220 also receives the perception data requirements from the data request algorithm 211.
  • the data collection trigger unit 220 provides the trigger data to the patient perception data collection module 240.
  • the data collection trigger unit 220 takes as input the perception data requirements from the data request algorithm 211 to determine whether the requested data collection condition is met so as to initiate additional patient perception data collection in accordance with perception data requirements.
  • the data collection trigger unit 220 may also be instructed when to collect data.
  • a user may experience stress/ anxiety unrelated to the suspected medical condition, such that stress analysis may be triggered after physical activity when the suspected disease includes a condition that generates symptoms with physical activity.
  • the data collection trigger unit 220 may be instructed to collect data after hearing a trigger word related to the suspected condition.
  • the patient perception data collection module 240 provides a collection of the patient perception data from the data collection trigger unit 220 to the patient perception analysis module 230. Examples of the collection of the patient perception data provided to the patient perception analysis module 230 include speech, heart rate variability, video, audio, respiration rate, blood pressure, and other evidence of physiological characteristics of the user.
  • the patient perception data collection module 240 provides data collected from sensors and controllers in accordance with perception data requirements. While the data collection trigger unit 220 determines when data are collected, the patient perception data collection module 240 controls what data is provided to the digital twin model 299.
  • the patient perception data collection module 240 may select sensor modalities, but may also influence sensor settings such as measurement range, resolution, sampling frequency, and more.
  • the patient perception analysis module 230 provides indications of symptoms and stress to the digital twin model 299, and indications of awareness and stress to the user interface 250 for output to the user.
  • the patient perception analysis module 230 may analyze the variables measured according to the perception data requirements and received via the patient perception data collection module 240. For example, the patient perception analysis module 230 may analyze stress level, or occurrence of certain words related to expected symptoms, such as pain or dizziness.
  • the patient perception analysis module 230 may extract the requested patient perception information from the perception data, as specified by the perception data requirements. Different algorithms may be selectively used depending on the perception data provided as input and the data to be extracted from the perception data. For example, when speech is input to derive whether a patient is experiencing specific symptoms or worrying about their health, natural language processing (NLP) may be used. When video is input to derive stress/anxiety levels, facial expression analysis may be performed.
  • the patient perception analysis module 230 may serve both to improve predictions by the digital twin model 299 and to determine how to communicate.
  • the level of detail for data that is to be collected may also be determined, and this may influence the analysis of the collected data. For example, if the current health state to be determined is whether the patient perceives pain or not, the analysis may be performed by a binary classifier. If the current health state to be determined requires information on the level of pain, then the analysis of the same data may require a more complex analysis.
  • the user interface 250 is used to interact with and communicate with the patient.
  • the user interface 250 may vary depending on the analysis by the patient perception analysis module 230. For example, different messages and different user interfaces may be used when a patient is already experiencing symptoms and feeling stress than when the patient appears unaware that anything might be wrong.
  • the perception data collected according to the progression in FIG. 2A may be used as supporting data to improve the confidence level of a prediction by the digital twin model 299.
  • the ability of the digital twin model 299 to determine when to recommend that a user contact a medical provider for further health assessment may thus be improved.
  • the progression in FIG. 2A is used to improve digital twin predictions by capturing user perception data in a manner that is selective and unobtrusive.
  • the progression in FIG. 2A may be used to determine which data should be collected and under what circumstances, so that any of the counterpart devices may be triggered to begin collecting the requested data.
  • the digital twin model 299 may predict that a patient may be suffering from a specific medical condition, but the certainty level may be below a defined confidence threshold required before a patient can be alerted.
  • the data request algorithm 211 may reference a database of medical literature to determine which symptoms are associated with the suspected disease. Using the symptom information, additional data collection may be initiated to verify if the corresponding symptoms are being experienced by the patient. For example, counterpart devices may be instructed to listen for trigger words, similar to how trigger words are used to activate virtual assistants.
  • the counterpart devices may include general-purpose user devices, or devices such as audio sensors which are dedicated for use with the digital twin model. After a trigger word is detected, audio data may be collected and then provided for analysis to the digital twin model 299 using natural language processing (NLP) to detect if the patient is experiencing these symptoms.
  • NLP natural language processing
  • FIG. 2B illustrates a system for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • the system 200 in FIG. 2B includes a computer 210, a digital twin model 299 and a first counterpart device 201A, a second counterpart device 201B and a third counterpart device 201C.
  • the computer 210 interacts with the digital twin model 299 and the first counterpart device 201A, the second counterpart device 201B and the third counterpart device 201C.
  • the computer 210 may include a controller comprising a memory that stores instructions and a processor that executes instructions, such as the controller 150 in FIG. 1C.
  • the instructions may comprise a data collection algorithm and a translation algorithm.
  • the computer may translate output from the digital twin model 299 using the translation algorithm, and determine instructions to send to the first counterpart device 201A, the second counterpart device 201B and the third counterpart device 201C using the data collection algorithm.
  • the link between the digital twin model 299 and the computer 210 as a translation device is bi-directional.
  • the computer 210 may receive feedback from the first counterpart device 201A, the second counterpart device 20 IB and the third counterpart device 201C as collection devices.
  • the computer 210 may communicate to the digital twin model 299 that collections of requested types of data may not be possible. For example, if sensors are not available and would be the types of equipment to collect requested types of data, the computer may inform the digital twin model 299 and the digital twin model 299 may update its output to account for the unavailable sensors. Accordingly, the computer 210 may operate as a feedback mechanism that uses a predictive algorithm to assist the digital twin model 299 in optimizing output from the digital twin.
  • the link between the computer 210 and the first counterpart device 201 A, the second counterpart device 20 IB and the third counterpart device 201C as data collection devices is bidirectional.
  • the bi-directional relationship between the computer and the data collection devices enhances functionality for the data collection devices.
  • Some data collection devices may have smartness and predictive capabilities as it is the case with some intelligent hubs and sensors used in homes.
  • the data collection devices may communicate back to the computer 210 that requirements for granularity, triggers etc. communicated by the translation device cannot be implemented, and then both the computer 210 and the data collection devices may execute algorithms to identify mechanisms to resolve such issues.
  • one of the first counterpart device 201A, the second counterpart device 201B and the third counterpart device 201C may be connected with other types of data collection devices via a wireless local area network such as WiFi.
  • the counterpart device may possess or be configured to obtain information used to determine whether the other types of data collection devices are capable of collecting certain types of data which are otherwise uncollectable by the counterpart device, and may communicate such capabilities back to the computer 210 to resolve issues.
  • FIG. 3 illustrates a method for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • the method of FIG. 3 may be performed by the computer 110, by the system 100 including the computer 110, by the controller 150, and/or by the device 103 including the controller 150.
  • the method of FIG. 3 may be performed by or using the data request algorithm 211 and other elements of the progression in FIG. 2A.
  • the data request algorithm 211 outputs the perception data requirements required to resolve uncertainty as to whether a patient has a disease.
  • the perception data requirements may comprise a list or description which contains instructions on unobtrusive measurements to be performed regarding how patients perceive their health state, in order to improve a risk prediction from the digital twin model 299 for a given health state.
  • the method of FIG. 3 starts at S305 by obtaining output from a digital twin model.
  • the output may be obtained by the data request algorithm 211 as determinations of suspected disease from the digital twin model 299.
  • the output may include an indication of the level of suspicion (e.g., certainty) and the type of suspected disease.
  • the output may be used to trigger a determination of whether the level of suspicion (e.g., certainty) is above a predetermined threshold. Thresholds may be used to delineate certainty of whether the patient has the suspected disease.
  • the data request algorithm 211 may initiate a process to collect data that can resolve the uncertainty. Therefore, output of a prediction from the digital twin model may trigger the data request algorithm 211 to initiate unobtrusive capture of user perception data.
  • Output from the digital twin model may be input to the data request algorithm 211 at S305.
  • the input may be or include a text or code indicating a state/condition linked to the user.
  • This state may be a health condition, but may also conditions such as tiredness, pain, dizziness.
  • the state may represent a predicted future condition of the user, though the state may also or alternatively represent past or current user conditions.
  • the user condition may be physiological and/or psychological.
  • the output from the digital twin model 299 may be “a question” or “a statement” linked to the user or the environment of the user and requiring validation.
  • An example of a question input to the data request algorithm 211 may be “is the user likely to have side effects from medication A?”, or “what is the CO2 level in the user environment”.
  • the output from the digital twin model 299 may be normalized or standardized after being obtained, such as to meet a format required by data request algorithm 211.
  • the method of FIG. 3 includes determining symptoms associated with the suspected disease.
  • the data request algorithm 211 may refer to a digital table that stores associations of symptoms with suspected diseases.
  • the output from the digital twin model 299 may be mapped to a data collection specification using, for example, a mathematical function, or a database using a look up table or conditional rules.
  • the output from the digital twin model 299 may be processed using a probabilistic function, such as information retrieval, question answering, or in general machine learning algorithms such as neural networks. Machine learning algorithms may be trained using rules provided by experts, and relational databases linking different types of health conditions and measurement parameters.
  • the method of FIG. 3 includes determining a type of information to collect.
  • types of information may include online information, voice information, video information.
  • the types of information to collect may also depend on which types of counterpart devices are available for a patient, and this may depend on the context of whether the patient is at home or in a hospital or other medical facility.
  • a hospital or other medical facility may have a variety of medical sensors from which information can be collected, whereas a patient at home may mostly have only personal wearable devices, personal communications devices, and communication hubs available to collect information.
  • the output is a measurement type (e.g. skin temperature).
  • the measurement type determined at S315 may be qualitative such as data derived from answering questionnaires, emotions/mood/pain recognized from speech, from images, from video, from movements, from signals, from sentiments recognized from speech and signals.
  • answers to questionnaires may still be a form of indirectly- collected data when the questionnaires are not specifically targeted to collecting the types of data used herein.
  • a questionnaire may relate to financial situations or neighborhood situations, and answers to such a questionnaire may still reflect that the patient may be suffering from an illness.
  • the measurement type determined at S315 may also or alternatively be quantitative such as signal or data such as heart rate or weight.
  • An indicator such as a name of the measurement may be a minimal requirement.
  • additional specifications indicating quality, amount, environment, frequency, and annotations of the measurement may also be specified by the data request algorithm 211.
  • Modes may include audio, video or text, and may also include a type of device to be used to indirectly collect the type of information.
  • stress levels may be derived unobtrusively based on sensor data such as heart rate variability and electrodermal activity.
  • Speech analysis may be performed to analyze whether a person is talking about certain symptoms. Facial expression analysis may be performed to detect for example pain.
  • Internet searches and social media activity may be analyzed for symptoms or diseases. Available measurement modalities may vary for different patients. For example, some, but not all, users have fitness trackers which may be used as counterpart devices to collect data.
  • Smartphones are used by a large majority of the population in places such as at least the United States, and may include any of a variety of applications and functions enabling the smartphones to serve as counterpart devices.
  • the digital twin model, the computer 210 and the data collection devices may all be implemented in a single device such as a smartphone, or otherwise in fewer than 3 separate devices.
  • a first application on a smartphone may implement the digital twin model and provide output to a second application also on the smartphone, and the second application may coordinate data collection from the smartphone as well as from other devices.
  • the digital twin model, the computer 210 and/or the data collection models may be implemented in cloudbased applications.
  • one of these types of devices and applications may be implemented locally, and others of these devices and applications may be implemented in cloud-based applications.
  • the computer 210 may be implemented locally to coordinate data collection, and the digital twin model and the data collection devices may be implemented in the cloud.
  • the mode determined at S320 may indicate a type of data, a time, a location, an environment, context, duration, minimum quality, and more characteristics of the context in which data is to be collected.
  • types of data include audio such as speech, image, sleep, etc.
  • time include in the morning, after lunch etc.
  • location include at home, in the neighborhood, in mountains, above a certain altitude etc.
  • environment include when air quality is below certain level, when temperature is above certain degree etc.
  • Examples of context include in social gatherings, at work, when the patient is biking or running etc.
  • An example of duration is 10 minutes of data collection every 20 minutes.
  • minimum quality include sampling frequency greater than certain thresholds or with certain minimum amounts of missing data etc.
  • the method of FIG. 3 includes determining a level of granularity of the type of information to be collected from the user.
  • the level of granularity may specify the level of detail of the information to be collected, such as an average of a complete set of physiological measurements or a periodic sampling of physiological measurements.
  • a condition may include detection of the patient entering a keyword in an internet search or on a social media website or another website such as a review left on a healthcare website via a keyboard or voice input.
  • a condition may also or alternatively include simply visiting a healthcare website, or a personal health record or electronic medical record such as at an insurance company website.
  • a condition may also include detection of the patient using a keyword or expression that reflects concern about the suspected disease.
  • monitoring for the condition may include monitoring speech of others around the patient, such as a family member using a keyword or expression that reflects concern about the suspected disease.
  • the condition may be sent to any of the first counterpart device 101A, the second counterpart device 101B and the third counterpart device 101C, so that these counterpart devices may monitor for the condition.
  • patient perceptions of health may be derived.
  • the patient perceptions of health to be derived may include the types of behavior and/or expressions that reflect perceptions of health and which may evidence concern that the patient has the suspected disease.
  • Derivation of patient perceptions may be obtained for determining a mode to collect data, determining a granularity of data to collect, and determining triggers to use to invoke collection of data.
  • the predictive model such as a digital twin model may determine how to analyze collected data, and the types of information (e.g., including patient perceptions) from the collected data.
  • the method of FIG. 3 includes transmitting an instruction to a counterpart device.
  • the instruction may include the type of information to collect, any condition for triggering collection of the type of information, the granularity of the type of information to be collected, and other information by which an electronic communication device may assist in resolving whether a patient has the suspected disease.
  • Types of data collected from patients and other users may include a variety of types of information.
  • collected information may include sounds produced, facial expressions, eye movements, breathing changes, posture changes, gate changes, activities of daily living, hand movements, leg movements, and physiological changes.
  • physiological changes may include sweating, skin/body temperature changes, heart rate changes etc.
  • data may be indirectly collected from users via devices operated by a user or otherwise associated with a user.
  • a device operated by or in association with a user may provide data collected for a predictive model.
  • a vehicle, a keyboard, TV remote, kitchen equipment, or another type of device linked to an operation resulting from the action of the individual or another user may provide data collected for a predictive model.
  • the method of FIG. 3 includes receiving the type of information from the counterpart device.
  • a counterpart device may provide information to the computer 110 that indicates the patient has performed an internet search for keywords indicating that the patient is concerned about the suspected disease.
  • the counterpart device may also provide other types of information, such as indicating that they patient is actively checking for symptoms, making purchases that reflect a concern about the suspected disease, sending emails or text messages indicating concern about the suspected disease, and more.
  • the type of information received at S345 is input to the digital twin model.
  • the digital twin model may use the type of information to resolve the uncertainty as to whether the patient has the suspected disease.
  • the digital twin model updates a prediction for the physiology of the user based on the type of information received at S345 and input at S350.
  • the selectively-collected data which is input to the digital twin model is used as feedback to update a previous prediction.
  • the previous prediction may have not met a threshold for certainty that would support an affirmative recommendation to present the user with information and/or an option to address a physiological condition.
  • the digital twin uncertainty resolution described herein enhances the certainty of the prediction by selectively collecting additional information. In some embodiments, if the updated prediction still does not meet a predetermined threshold, the process of selective collection of additional information may be performed again.
  • the collected data may be used to retrain and update a predictive model. That is, a predictive model may be updated by changing the input data without changing the trained predictive model, by retraining the predictive model without changing the input data, or by changing input and retraining the predictive model.
  • the updated predictive model is used to update the prediction for the physiology of the user.
  • the method of FIG. 3 includes determining the type of user interface to use to interface with the user, such as to directly inform the patient that the patient has or does not have the suspected disease, or to inform the patient to arrange a visit with a medical professional to check for the suspected disease.
  • user perception data may be collected unobtrusively in order to enhance certainty for a prediction from a digital twin model.
  • Example methods for unobtrusively obtaining targeted health data from a user include methods developed to derive stress levels unobtrusively based on sensor data such as heart rate variability and electrodermal activity. Other methods use speech analysis to analyze whether the person is talking about certain symptoms, facial expression analysis to detect for example pain, or internet searches for symptoms or diseases.
  • FIG. 4 illustrates another progression for digital twin uncertainty resolution, in accordance with a representative embodiment.
  • the progression of FIG. 4 is based on the progression of FIG. 2A, but includes an expanded level of detail for the digital twin 401.
  • the progression in FIG. 4 includes the digital twin 401, a data request algorithm 410, a data collection trigger unit 420, patient perception analysis 430, patient perception data collection 440, and a user interface 450. Teachings of the elements in FIG. 4 corresponding to the elements in FIG. 2A is not repeated for the sake of brevity.
  • a digital twin 401 may be used to process numerous types of information in order to predict whether a patient suffers from any of a variety of diseases.
  • the digital twin 40 may receive and process as inputs information such as a genomic profde, imaging studies, results from lab tests, clinical and behavioral studies, family history, population health data, and data from personal devices.
  • In-silico intelligence is used to process the various data for the patient.
  • Expert knowledge is applied to assess current status and predict future status.
  • the teachings herein may be applied when the prediction of future status is uncertain as to one or more diseases.
  • trigger words for a virtual assistant may be selected based on the output of a digital twin.
  • the predictions from the digital twin may be used to select trigger words to activate an audio device or virtual assistant to start listening and collect data.
  • the digital twin may predict that the user may have a certain condition.
  • the data request algorithm 211 derives the symptoms associated with the disease or medical condition.
  • the symptoms are then translated into trigger words such that the audio device or virtual assistant may capture when the user is talking about such symptoms.
  • Patient perception analysis may then be performed using natural language processing to determine whether the user is experiencing the symptoms.
  • Information may be contextualized based on, for example, when the symptoms occur.
  • chest pain after exercise may be contextualized as a trigger
  • dizziness when getting up from a chair may be contextualized as a trigger
  • severity of chest pain or dizziness may be contextualized.
  • the information may then be fed back to the digital twin model 299 to improve the confidence level of predictions.
  • the information fed back to the digital twin model 299 may be as simple as counts of how often trigger words have been detected, or more sophisticated information such as the likelihood that a user is concerned about certain symptoms or health in general. Both the learned information about the symptoms the user is experiencing as well as perceived emotions about the potential symptoms (e.g. anxiety, stress) may be taken into account by the digital twin model 299 for tailoring communication to the user.
  • the analysis by the digital twin model 299 may result in reassurance when no reason is found to worry, or recognition that the symptoms being experienced are a cause for concern and the user should follow up with a general practitioner.
  • predictions of coronary artery disease may be improved. Severe stenosis in the coronary arteries may lead to a heart attack when left untreated.
  • Predictive models for high-risk CAD may be provided. With such models, risk of CAD may be predicted for a patient such as based on family history.
  • CAD predictive models may be run as part of a digital twin. When new model input data (e.g. blood pressure) become available the model may be run again to give an updated prediction.
  • the data request algorithm 211 may be employed to resolve the uncertainty.
  • the input on whether or not the patient is experiencing symptoms may be gathered.
  • Typical symptoms of CAD are chest pain, shortness of breath, heart palpitations, dizziness and sweating, especially after activity.
  • the digital twin model 299 may already use algorithms to analyze heart rate, sweat and respiration to detect symptoms such as shortness of breath, heart palpitations or sweating.
  • Heart rate may be derived, for example, from a wearable PPG device. Sweat may be measured from a sweat sensor, from skin conductance, and/or from photos or video). Respiration may be measured from a wearable sensor or audio recordings.
  • the digital twin model 299 may detect increased sweating and increased respiration rate, but at a level that is elevated but not conclusively excessive. This may then trigger additional data collection to determine stress level from the user or audio data collection to analyze whether the user is complaining about symptoms or noticing increased sweating.
  • the data request algorithm 211 may generate CAD-related trigger words to start speech analysis such as ‘pain’, ‘dizziness’, ‘chest’, ‘heart’, ‘unwell’ etc. to detect whether the patient is experiencing any symptoms or noticing something to be wrong.
  • trigger words are not necessarily limited to after an activity, as a person may be alone at that moment and not speaking, but discussing it with a friend at a later time point. Defining these specific trigger words based on the predicted condition limits the amount of data collected and analyzed, and allows for the relevant data to be collected as input for the digital twin model 299, without too much confounding information.
  • the results from the patient perception analysis are fed back to the digital twin and used to improve the risk prediction and make a decision on if and how to communicate the risk to the patient. Examples of the results from the patient perception analysis may include a number of symptoms mentioned or searched for online, or stress level after activity.
  • predictions of diabetes onset may be improved.
  • such screening may lead to additional data collection for input to the digital twin, to detect symptoms such as weight loss, increased thirst, frequent urination, extreme hunger, fatigue, irritability and blurred vision. In the case of diabetes this may mostly involve generating trigger words related to these symptoms to start speech analysis.
  • predictions of arrhythmia may be improved.
  • Current arrhythmia detection algorithms automatically detect arrhythmia from ECG but also PPG.
  • PPG is promising for this purpose as such sensors are used in many wearable fitness trackers nowadays. With an accuracy of 0.957 the same risk of many false positives applies as for the diabetes case in terms of using PPG for arrhythmia screening purposes in the general population.
  • the teachings herein may be used to improve accuracy by requesting additional data to check whether the user is experiencing any symptoms, such as fatigue, dizziness, fainting, shortness of breath and anxiety.
  • a trigger to start additional data collection for arrhythmia uncertainty may be detection of a suspected arrhythmia.
  • Natural language processing may be used to detect if the user is experiencing symptoms.
  • Voice pitch and facial expression analysis may be performed to detect stress/ anxiety for example.
  • Arrhythmia may be asymptomatic, and the absence of perception of symptoms should not be used as a reason to discard the possibility of arrhythmia is present. However, the detection of the symptoms will strengthen the suspicion and can therefore help in determining the need for follow-up and the need to communicate the need for follow-up to the user.
  • monitoring of a social network may be used to improve disease detection by digital twins.
  • Perception data may be collected from people interacting with the user. This may involve using trigger words to also collect data from speakers other than the user. This may also involve detecting someone asking about the user’s weight loss, or looking tired.
  • One example use case for monitoring a social network is for Parkinson’s disease (PD). Approximately 75-90% of individuals with Parkinson disease have speech and voice disorders at some time in the course of the disease. The most common perceptual speech characteristics include reduced loudness, monotonous pitch, hoarseness, a breathy voice quality and/or imprecise articulation.
  • Parkinson’s disease may not be aware that they are getting softer in their speech and more difficult to understand.
  • the digital twin may pick up on the speech and voice changes but it may be uncertain whether something is really off and whether the user is aware of this.
  • direct feedback to the user regarding the user’s speech being unclear or having changed over time may be used by the digital twin to improve certainty that there is a problem.
  • other trigger words related to Parkinson’s disease can also be used to collect perception data from either the user him/herself or other people. Examples of other trigger words related to Parkinson’s disease include Parkinson, shaking, tremor, imbalance, etc.
  • the teachings herein may be used to help confirm the digital twin’s suspicion of Parking’s disease, and the analysis of perception data from other users may also inform the digital twin that the user has already been confronted with concerns and observations from others, and therefore may already be aware something is wrong. This can be used for the communication with the user.
  • Information collected from other users may also be collected directly or indirectly, as long as the target user (e.g., the patient) is not disturbed. For example, information may be indirectly collected for a patient, but directly from the other people around the patient such as family, friends, caregivers, nurses, clinicians etc.
  • the data collected and input to a digital twin model from other users may be information collected from the other users both directly and indirectly.
  • FIG. 5 illustrates a computer system, on which a method for digital twin uncertainty resolution is implemented, in accordance with another representative embodiment.
  • the computer system 500 includes a set of software instructions that can be executed to cause the computer system 500 to perform any of the methods or computer-based functions disclosed herein.
  • the computer system 500 may operate as a standalone device or may be connected, for example, using a network 501, to other computer systems or peripheral devices.
  • a computer system 500 performs logical processing based on digital signals received via an analog-to-digital converter.
  • the computer system 500 operates in the capacity of a server or as a client user computer in a server-client user network environment, or as a peer computer system in a peer-to-peer (or distributed) network environment.
  • the computer system 500 can also be implemented as or incorporated into various devices, such as a workstation that includes a controller, a stationary computer, a mobile computer, a personal computer (PC), a laptop computer, a tablet computer, or any other machine capable of executing a set of software instructions (sequential or otherwise) that specify actions to be taken by that machine.
  • the computer system 500 can be incorporated as or in a device that in turn is in an integrated system that includes additional devices.
  • the computer system 500 can be implemented using electronic devices that provide voice, video or data communication. Further, while the computer system 500 is illustrated in the singular, the term “system” shall also be taken to include any collection of systems or sub-systems that individually or jointly execute a set, or multiple sets, of software instructions to perform one or more computer functions.
  • the computer system 500 includes a processor 510.
  • the processor 510 may be considered a representative example of a processor of a controller and executes instructions to implement some or all aspects of methods and processes described herein.
  • the processor 510 is tangible and non-transitory.
  • the term “non-transitory” is to be interpreted not as an eternal characteristic of a state, but as a characteristic of a state that will last for a period.
  • the term “non- transitory” specifically disavows fleeting characteristics such as characteristics of a carrier wave or signal or other forms that exist only transitorily in any place at any time.
  • the processor 510 is an article of manufacture and/or a machine component.
  • the processor 510 is configured to execute software instructions to perform functions as described in the various embodiments herein.
  • the processor 510 may be a general -purpose processor or may be part of an application specific integrated circuit (ASIC).
  • the processor 510 may also be a microprocessor, a microcomputer, a processor chip, a controller, a microcontroller, a digital signal processor (DSP), a state machine, or a programmable logic device.
  • the processor 510 may also be a logical circuit, including a programmable gate array (PGA), such as a field programmable gate array (FPGA), or another type of circuit that includes discrete gate and/or transistor logic.
  • the processor 510 may be a central processing unit (CPU), a graphics processing unit (GPU), or both.
  • any processor described herein may include multiple processors, parallel processors, or both. Multiple processors may be included in, or coupled to, a single device or multiple devices.
  • the term “processor” as used herein encompasses an electronic component able to execute a program or machine executable instruction. References to a computing device comprising “a processor” should be interpreted to include more than one processor or processing core, as in a multi-core processor. A processor may also refer to a collection of processors within a single computer system or distributed among multiple computer systems. The term computing device should also be interpreted to include a collection or network of computing devices each including a processor or processors. Programs have software instructions performed by one or multiple processors that may be within the same computing device or which may be distributed across multiple computing devices.
  • the computer system 500 further includes a main memory 520 and a static memory 530, where memories in the computer system 500 communicate with each other and the processor 510 via a bus 508.
  • main memory 520 and the static memory 530 may be considered representative examples of a memory of a controller, and store instructions used to implement some or all aspects of methods and processes described herein.
  • Memories described herein are tangible storage mediums for storing data and executable software instructions and are non-transitory during the time software instructions are stored therein. As used herein, the term “non-transitory” is to be interpreted not as an eternal characteristic of a state, but as a characteristic of a state that will last for a period.
  • the term “non-transitory” specifically disavows fleeting characteristics such as characteristics of a carrier wave or signal or other forms that exist only transitorily in any place at any time.
  • the main memory 520 and the static memory 530 are articles of manufacture and/or machine components.
  • the main memory 520 and the static memory 530 are computer-readable mediums from which data and executable software instructions can be read by a computer (e.g., the processor 510).
  • Each of the main memory 520 and the static memory 530 may be implemented as one or more of random access memory (RAM), read only memory (ROM), flash memory, electrically programmable read only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, a hard disk, a removable disk, tape, compact disk read only memory (CD-ROM), digital versatile disk (DVD), floppy disk, blu-ray disk, or any other form of storage medium known in the art.
  • RAM random access memory
  • ROM read only memory
  • EPROM electrically programmable read only memory
  • EEPROM electrically erasable programmable read-only memory
  • registers a hard disk, a removable disk, tape, compact disk read only memory (CD-ROM), digital versatile disk (DVD), floppy disk, blu-ray disk, or any other form of storage medium known in the art.
  • the memories may be volatile or non-volatile, secure and/or encrypted, unsecure and/or unencrypted.
  • Memory is an example of a computer-readable storage medium.
  • Computer memory is any memory which is directly accessible to a processor. Examples of computer memory include, but are not limited to RAM memory, registers, and register files. References to “computer memory” or “memory” should be interpreted as possibly being multiple memories. The memory may for instance be multiple memories within the same computer system. The memory may also be multiple memories distributed amongst multiple computer systems or computing devices.
  • the computer system 500 further includes a video display unit 550, such as a liquid crystal display (LCD), an organic light emitting diode (OLED), a flat panel display, a solid-state display, or a cathode ray tube (CRT), for example.
  • a video display unit 550 such as a liquid crystal display (LCD), an organic light emitting diode (OLED), a flat panel display, a solid-state display, or a cathode ray tube (CRT), for example.
  • the computer system 500 includes an input device 560, such as a keyboard/virtual keyboard or touch-sensitive input screen or speech input with speech recognition, and a cursor control device 570, such as a mouse or touch-sensitive input screen or pad.
  • the computer system 500 also optionally includes a disk drive unit 580, a signal generation device 590, such as a speaker or remote control, and/or a network interface device 540.
  • the disk drive unit 580 includes a computer- readable medium 582 in which one or more sets of software instructions 584 (software) are embedded.
  • the sets of software instructions 584 are read from the computer-readable medium 582 to be executed by the processor 510.
  • the software instructions 584 when executed by the processor 510, perform one or more steps of the methods and processes as described herein.
  • the software instructions 584 reside all or in part within the main memory 520, the static memory 530 and/or the processor 510 during execution by the computer system 500.
  • the computer-readable medium 582 may include software instructions 584 or receive and execute software instructions 584 responsive to a propagated signal, so that a device connected to a network 501 communicates voice, video or data over the network 501.
  • the software instructions 584 may be transmitted or received over the network 501 via the network interface device 540.
  • dedicated hardware implementations such as application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), programmable logic arrays and other hardware components, are constructed to implement one or more of the methods described herein.
  • ASICs application-specific integrated circuits
  • FPGAs field programmable gate arrays
  • programmable logic arrays and other hardware components are constructed to implement one or more of the methods described herein.
  • One or more embodiments described herein may implement functions using two or more specific interconnected hardware modules or devices with related control and data signals that can be communicated between and through the modules. Accordingly, the present disclosure encompasses software, firmware, and hardware implementations. None in the present application should be interpreted as being implemented or implementable solely with software and not hardware such as a tangible non-transitory processor and/or memory.
  • the methods described herein may be implemented using a hardware computer system that executes software programs. Further, in an exemplary, non-limited embodiment, implementations can include distributed processing, component/object distributed processing, and parallel processing. Virtual computer system processing may implement one or more of the methods or functionalities as described herein, and a processor described herein may be used to support a virtual processing environment.
  • digital twin uncertainty resolution combines unobtrusive detection of patient health perception with digital twin modeling to improve diagnosis accuracy. Adding unobtrusively-obtained patient perception of their health status and any symptoms they may be experiencing to the digital twin analysis may improve analysis accuracy without alarming or bothering the patient and over longer timeframe than is afforded from a typical visit to a doctor.
  • Smart (selective) sampling of data helps minimize storage and processing burdens, such as for speech and facial expression data.
  • digital twin uncertainty resolution has been described with reference to several exemplary embodiments, it is understood that the words that have been used are words of description and illustration, rather than words of limitation. Changes may be made within the purview of the appended claims, as presently stated and as amended, without departing from the scope and spirit of digital twin uncertainty resolution in its aspects.
  • digital twin uncertainty resolution has been described with reference to particular means, materials and embodiments, digital twin uncertainty resolution is not intended to be limited to the particulars disclosed; rather digital twin uncertainty resolution extends to all functionally equivalent structures, methods, and uses such as are within the scope of the appended claims.
  • teachings herein may be applicable to healthy individuals, and are not specifically limited to individuals who are already medical patients. For example, an individual who is not a patient may experience one or more symptoms linked to health and may benefit from the teachings herein.
  • inventions of the disclosure may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any particular invention or inventive concept.
  • inventions merely for convenience and without intending to voluntarily limit the scope of this application to any particular invention or inventive concept.
  • specific embodiments have been illustrated and described herein, it should be appreciated that any subsequent arrangement designed to achieve the same or similar purpose may be substituted for the specific embodiments shown.
  • This disclosure is intended to cover any and all subsequent adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the description.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Public Health (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Primary Health Care (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Pathology (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

Un ordinateur (110) comprend une mémoire (151) et un processeur (152). La mémoire (151) stocke des instructions. Le processeur (152) exécute les instructions. Lorsqu'elles sont exécutées par le processeur (152), les instructions amènent l'ordinateur (110) : à obtenir des donnés de sortie auprès d'un modèle prédictif qui représente numériquement la physiologie d'un utilisateur ; à déterminer, sur la base des données de sortie du modèle prédictif, un type d'informations à collecter indirectement auprès de l'utilisateur ; à transmettre une instruction à un dispositif homologue (103) pour collecter indirectement le type d'informations auprès de l'utilisateur ; à recevoir du dispositif homologue (103), le type d'informations collectées auprès de l'utilisateur ; et à entrer, dans le modèle prédictif, le type d'informations collectées indirectement auprès de l'utilisateur pour mettre à jour une prédiction pour la physiologie de l'utilisateur.
PCT/EP2023/060462 2022-04-29 2023-04-21 Résolution d'incertitude de jumeau numérique WO2023208775A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263336699P 2022-04-29 2022-04-29
US63/336,699 2022-04-29

Publications (1)

Publication Number Publication Date
WO2023208775A1 true WO2023208775A1 (fr) 2023-11-02

Family

ID=86330543

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/060462 WO2023208775A1 (fr) 2022-04-29 2023-04-21 Résolution d'incertitude de jumeau numérique

Country Status (1)

Country Link
WO (1) WO2023208775A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190005200A1 (en) * 2017-06-28 2019-01-03 General Electric Company Methods and systems for generating a patient digital twin

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190005200A1 (en) * 2017-06-28 2019-01-03 General Electric Company Methods and systems for generating a patient digital twin

Similar Documents

Publication Publication Date Title
KR102116664B1 (ko) 온라인 기반의 건강 관리 방법 및 장치
US20230410166A1 (en) Facilitating integrated behavioral support through personalized adaptive data collection
Ani et al. Iot based patient monitoring and diagnostic prediction tool using ensemble classifier
Jeddi et al. Remote patient monitoring using artificial intelligence
US10162940B2 (en) System and method of applying state of being to health care delivery
US20180350455A1 (en) Sensor-enabled mobile health monitoring and diagnosis
US20210294946A1 (en) Selecting and applying digital twin models
WO2017147552A1 (fr) Système et procédé de méta-apprentissage multiformat, multi-domaine et multi-algorithme permettant de surveiller la santé humaine et de dériver un état et une trajectoire de santé
US20210015415A1 (en) Methods and systems for monitoring user well-being
Goyal et al. Automation of stress recognition using subjective or objective measures
US20220192556A1 (en) Predictive, diagnostic and therapeutic applications of wearables for mental health
US20210407633A1 (en) System and method for tracking informal observations about a care recipient by caregivers
US20220059238A1 (en) Systems and methods for generating data quality indices for patients
US11640858B2 (en) Digital therapeutic platform
WO2022087116A1 (fr) Systèmes et procédés d'évaluation de santé mentale
Ogbuabor et al. Context-aware system for cardiac condition monitoring and management: a survey
Lima et al. Discovering behavioural patterns using conversational technology for in-home health and well-being monitoring
Belmin et al. Real-world implementation of an eHealth system based on artificial intelligence designed to predict and reduce emergency department visits by older adults: pragmatic trial
Vargiu et al. Context-aware based quality of life telemonitoring
Yang et al. DrHouse: An LLM-empowered Diagnostic Reasoning System through Harnessing Outcomes from Sensor Data and Expert Knowledge
Jeong et al. Visual scheme monitoring of sensors for fault tolerance on wireless body area networks with cloud service infrastructure
Hu et al. An ensemble classification model for depression based on wearable device sleep data
Kumar et al. A PHR-based system for monitoring diabetes in mobile environment
US20240285205A1 (en) Devices, Systems, and Methods for Mental Health Assessment
WO2023208775A1 (fr) Résolution d'incertitude de jumeau numérique

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: 23722492

Country of ref document: EP

Kind code of ref document: A1