This disclosure relates generally to improved patient modeling and, more particularly, to improved systems and methods to generate a patient digital twin.
A variety of economic, technological, and administrative hurdles challenge healthcare facilities, such as hospitals, clinics, doctors' offices, etc., to provide quality care to patients. Economic drivers, evolving medical science, less and skilled staff, fewer staff, complicated equipment, and emerging accreditation for controlling and standardizing radiation exposure dose usage across a healthcare enterprise create difficulties for effective management and use of imaging and information systems for examination, diagnosis, and treatment of patients.
Healthcare provider consolidations create geographically distributed hospital networks in which physical contact with systems is too costly. At the same time, referring physicians want more direct access to supporting data in reports and other data forms along with better channels for collaboration. Physicians have more patients, less time, and are inundated with huge amounts of data, and they are eager for assistance.
Certain examples provide an apparatus including a processor and a memory. The example processor is to configure the memory according to a patient digital twin of a first patient. The example patient digital twin is to include a data structure created from a combination of patient medical record data, image data, genetic information, and historical information, the combination extracted from one or more information systems and arranged in the data structure to form a digital representation of the first patient. The example patient digital twin is to be arranged for query and simulation via the processor. The example patient digital twin is to be combinable with one or more rules to generate, using the processor, a recommendation for a patient health outcome based on modeling the patient digital twin as instructed by the one or more rules.
Certain examples provide a computer-readable storage medium including instructions. The example instructions, when executed, cause a machine to implement at least a patient digital twin of a first patient, the patient digital twin including a data structure created from a combination of patient medical record data, image data, genetic information, and historical information, the combination extracted from one or more information systems and arranged in the data structure to form a digital representation of the first patient, the patient digital twin arranged for query and simulation. The example patient digital twin is combinable with one or more rules to generate, using the processor, a recommendation for a patient health outcome based on modeling the patient digital twin as instructed by the one or more rules.
Certain examples provide a method including extracting, using a processor, information for a first patient from one or more information systems to form a combination of patient medical record data, image data, genetic information, and historical information. The example method includes arranging, using the processor, the combination in a data structure in a memory to form a patient digital twin, the patient digital twin forming a digital representation of the first patient, the patient digital twin combinable with one or more rules to generate, using the processor, a recommendation for a patient health outcome based on modeling the patient digital twin as instructed by the one or more rules. The example method includes providing, using the processor, access to the patient digital twin in the memory via a graphical user interface for query and simulation.
Certain examples provide a system including a means for configuring a memory according to a digital twin of a physical patient. The example digital twin includes a first data structure including medical record data; a second data structure including image data; a third data structure including genetic information; and a fourth data structure including historical information. The example first data structure, second data structure, third data structure, and fourth data structure are related in combination in the memory to form the digital twin providing a digital representation of the physical patient, the digital twin arranged for query and simulation.
The figures are not scale. Wherever possible, the same reference numbers will be used throughout the drawings and accompanying written description to refer to the same or like parts.
In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific examples that may be practiced. These examples are described in sufficient detail to enable one skilled in the art to practice the subject matter, and it is to be understood that other examples may be utilized and that logical, mechanical, electrical and other changes may be made without departing from the scope of the subject matter of this disclosure. The following detailed description is, therefore, provided to describe an exemplary implementation and not to be taken as limiting on the scope of the subject matter described in this disclosure. Certain features from different aspects of the following description may be combined to form yet new aspects of the subject matter discussed below.
When introducing elements of various embodiments of the present disclosure, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.
As used herein, the terms “system,” “unit,” “module,” “engine,” etc., may include a hardware and/or software system that operates to perform one or more functions. For example, a module, unit, or system may include a computer processor, controller, and/or other logic-based device that performs operations based on instructions stored on a tangible and non-transitory computer readable storage medium, such as a computer memory. Alternatively, a module, unit, engine, or system may include a hard-wired device that performs operations based on hard-wired logic of the device. Various modules, units, engines, and/or systems shown in the attached figures may represent the hardware that operates based on software or hardwired instructions, the software that directs hardware to perform the operations, or a combination thereof.
While certain examples are described below in the context of medical or healthcare systems, other examples can be implemented outside the medical environment. For example, certain examples can be applied to non-medical imaging such as non-destructive testing, explosive detection, etc.
A digital representation, digital model, digital “twin”, or digital “shadow” is a digital informational construct about a physical system. That is, digital information can be implemented as a “twin” of a physical device/system/person and information associated with and/or embedded within the physical device/system. The digital twin is linked with the physical system through the lifecycle of the physical system. In certain examples, the digital twin includes a physical object in real space, a digital twin of that physical object that exists in a virtual space, and information linking the physical object with its digital twin. The digital twin exists in a virtual space corresponding to a real space and includes a link for data flow from real space to virtual space as well as a link for information flow from virtual space to real space and virtual sub-spaces.
For example,
Sensors connected to the physical object (e.g., the patient 110) can collect data and relay the collected data 120 to the digital twin 130 (e.g., via self-reporting, using a clinical or other health information system such as a picture archiving and communication system (PACS), radiology information system (RIS), electronic medical record system (EMR), laboratory information system (LIS), cardiovascular information system (CVIS), hospital information system (HIS), and/or combination thereof, etc.). Interaction between the digital twin 130 and the patient 110 can help improve diagnosis, treatment, health maintenance, etc., for the patient 110, for example. An accurate digital description 130 of the patient 110 benefiting from a real-time or substantially real-time (e.g., accounting from data transmission, processing, and/or storage delay) allows the system 100 to predict “failures” in the form of disease, body function, and/or other malady, condition, etc.
In certain examples, obtained images overlaid with sensor data, lab results, etc., can be used in augmented reality (AR) applications when a healthcare practitioner is examining, treating, and/or otherwise caring for the patent 110. Using AR, the digital twin 130 follows the patient's response to the interaction with the healthcare practitioner, for example.
Thus, rather than a generic model, the digital twin 130 is a collection of actual physics-based, anatomically-based, and/or biologically-based models reflecting the patient 110 and his or her associated norms, conditions, etc. In certain examples, three-dimensional (3D) modeling of the patient 110 creates the digital twin 130 for the patient 110. The digital twin 130 can be used to view a status of the patient 110 based on input data 120 dynamically provided from a source (e.g., from the patient 110, practitioner, health information system, sensor, etc.).
In certain examples, the digital twin 130 of the patient 110 can be used for monitoring, diagnostics, and prognostics for the patient 110. Using sensor data in combination with historical information, current and/or potential future conditions of the patient 110 can be identified, predicted, monitored, etc., using the digital twin 130. Causation, escalation, improvement, etc., can be monitored via the digital twin 130. Using the digital twin 130, the patient's 110 physical behaviors can be simulated and visualized for diagnosis, treatment, monitoring, maintenance, etc.
In contrast to computers, humans do not process information in a sequential, step-by-step process. Instead, people try to conceptualize a problem and understand its context. While a person can review data in reports, tables, etc., the person is most effective when visually reviewing a problem and trying to find its solution. Typically, however, when a person visually processes information, records the information in alphanumeric form, and then tries to re-conceptualize the information visually, information is lost and the problem-solving process is made much less efficient over time.
Using the digital twin 130, however, allows a person and/or system to view and evaluate a visualization of a situation (e.g., a patient 110 and associated patient problem, etc.) without translating to data and back. With the digital twin 130 in common perspective with the actual patient 110, physical and virtual information can be viewed together, dynamically and in real time (or substantially real time accounting for data processing, transmission, and/or storage delay). Rather than reading a report, a healthcare practitioner can view and simulate with the digital twin 130 to evaluate a condition, progression, possible treatment, etc., for the patient 110. In certain examples, features, conditions, trends, indicators, traits, etc., can be tagged and/or otherwise labeled in the digital twin 130 to allow the practitioner to quickly and easily view designated parameters, values, trends, alerts, etc.
The digital twin 130 can also be used for comparison (e.g., to the patient 110, to a “normal”, standard, or reference patient, set of clinical criteria/symptoms, etc.). In certain examples, the digital twin 130 of the patient 110 can be used to measure and visualize an ideal or “gold standard” value state for that patient, a margin for error or standard deviation around that value (e.g., positive and/or negative deviation from the gold standard value, etc.), an actual value, a trend of actual values, etc. A difference between the actual value or trend of actual values and the gold standard (e.g., that falls outside the acceptable deviation) can be visualized as an alphanumeric value, a color indication, a pattern, etc.
Further, the digital twin 130 of the patient 110 can facilitate collaboration among friends, family, care providers, etc., for the patient 110. Using the digital twin 130, conceptualization of the patient 110 and his/her health can be shared (e.g., according to a care plan, etc.) among multiple people including care providers, family, friends, etc. People do not need to be in the same location as the patient 110, with each other, etc., and can still view, interact with, and draw conclusions from the same digital twin 130, for example.
Thus, the digital twin 130 can be defined as a set of virtual information constructs that describes (e.g., fully describes) the patient 110 from a micro level (e.g., heart, lungs, foot, anterior cruciate ligament (ACL), stroke history, etc.) to a macro level (e.g., whole anatomy, holistic view, skeletal system, nervous system, vascular system, etc.). In certain examples, the digital twin 130 can be a reference digital twin (e.g., a digital twin prototype, etc.) and/or a digital twin instance. The reference digital twin represents a prototypical or “gold standard” model of the patient 110 or of a particular type/category of patient 110, while one or more reference digital twins represent particular patients 110. Thus, the digital twin 130 of a child patient 110 may be implemented as a child reference digital twin organized according to certain standard or “typical” child characteristics, with a particular digital twin instance representing the particular child patient 110. In certain examples, multiple digital twin instances can be aggregated into a digital twin aggregate (e.g., to represent an accumulation or combination of multiple child patients sharing a common reference digital twin, etc.). The digital twin aggregate can be used to identify differences, similarities, trends, etc., between children represented by the child digital twin instances, for example.
In certain examples, the virtual space 135 in which the digital twin 130 (and/or multiple digital twin instances, etc.) operates is referred to as a digital twin environment. The digital twin environment 135 provides an integrated, multi-domain physics- and/or biologics-based application space in which to operate the digital twin 130. The digital twin 130 can be analyzed in the digital twin environment 135 to predict future behavior, condition, progression, etc., of the patient 110, for example. The digital twin 130 can also be interrogated or queried in the digital twin environment 135 to retrieve and/or analyze current information 140, past history, etc.
In certain examples, the digital twin environment 135 can be divided into multiple virtual spaces 150-154. Each virtual space 150-154 can model a different digital twin instance and/or component of the digital twin 130 and/or each virtual space 150-154 can be used to perform a different analysis, simulation, etc., of the same digital twin 130. Using the multiple virtual spaces 150-154, the digital twin 130 can be tested inexpensively and efficiently in a plurality of ways while preserving patient 110 safety. A healthcare provider can then understand how the patient 110 may react to a variety of treatments in a variety of scenarios, for example.
When a user (e.g., the patient 110, patient family member (e.g., parent, spouse, sibling, child, etc.), healthcare practitioner (e.g., doctor, nurse, technician, administrator, etc.), other provider, payer, etc.) and/or program, device, system, etc., inputs data in a system such as a picture archiving and communication system (PACS), radiology information system (RIS), electronic medical record system (EMR), laboratory information system (LIS), cardiovascular information system (CVIS), hospital information system (HIS), population health management system (PHM) etc., that information is reflected in the digital twin 130. Thus, the patient digital twin 130 can serve as an overall model or avatar of the patient 110 and can also model particular aspects of the patient 110 corresponding to particular data source(s) 210-260. Data can be added to and/or otherwise used to update the digital twin 130 via manual data entry and/or wired/wireless (e.g., WiFi™, Bluetooth™, Near Field Communication (NFC), radio frequency, etc.) data communication, etc., from a respective system/data source, for example. Data input to the digital twin 130 is processed by an ingestion engine and/or other processor to normalize the information and provide governance and/or management rules, criteria, etc., to the information. In addition to building the digital twin 130, some or all information can also be aggregated for population-based health analytics, management, etc.
As modeled with the digital twin 130 in the example of
In certain examples, a solutions architecture of collaboration connecting workflows driven by analytics running on a cloud and/or on-premise platform can facilitate determination of health outcomes using the patient digital twin 130 and Equation 1.
Thus, as recited in Equation 1, a combination of the patient digital twin 130 modeled with digital medical knowledge 310 and access to care 320, bounded by behavioral choices 340, social/physical environment 330 and cost 350, provides a prediction, estimation, and/or other determination of health outcome for the patient 110. Such a combination represents a technological improvement in computer-aided diagnosis and treatment of patients, as the patient digital twin 130 represents a new and improved data structure and automated, electronic correlation with digital medical knowledge 310 and access to care 320, bounded by behavioral choices 340, social/physical environment 330 and cost 350, enables modeling, simulation, and identification of potential issues and possible solutions not feasible when done manually by a clinician or by prior computing systems, which were unable to model and simulate as the patient digital twin 130 disclosed and described herein.
The patient digital twin 130 can be used to help drive a continuous loop of patient care such as shown in the example of
At block 920, a care system (e.g., care system 1020 shown in
At block 930, the patient digital twin 130 is accessed. For example, the patient digital twin 130 can be stored on the care system 1020 and/or otherwise can be accessed via the care system 1020 (e.g., via a graphical user interface 1025 display of the care system 1020, etc.) to communicate the change and/or other scheduling of the follow-up event. Thus, a change in exam time and/or other scheduling of a follow-up exam can be incorporated in the digital twin 130 (e.g., to model patient 110 behavior leading up to the event, process information obtained/changed after the event, etc.) and ingested as part of the digital twin 130 avatar or model.
At block 940, an intelligent care ecosystem associated with the digital twin 130 is notified. The care ecosystem (e.g., care ecosystem 1030 of the example of
At block 960, a follow-up monitoring system is notified (e.g., monitoring system 1040 of the example of
The process 900 can then loop upon the next change to allow the patient digital twin 130 to be updated and associated care plan, care systems, and care team members to react to the new notification. Thus, the digital twin 130 can be dynamically updated, receiving new information and driving associated health systems to monitor and treat the patient 110.
At block 1104, machine- and human-based diagnosis is leveraged to improve the patient digital twin 130. For example, healthcare software applications, medical big data, neural networks, other machine learning and/or artificial intelligence, etc., can be leveraged to diagnose, identify issue(s), propose solution(s) (e.g., medication, diagnosis, treatment, etc.) with respect to the digital twin 130. In certain examples, a remote human specialist can be consulted. The clinician can see results of the patient digital twin 130 and machine-based analysis and provide a final diagnosis and next steps for the patient 110, for example.
At block 1106, feedback can be obtained based on user experience to augment the digital twin 130. User experience with conditions, procedures, etc., similar to those of the patient 110 can be provided to the digital twin 130. Feedback regarding user experience with the digital twin 130 can also be provided. Feedback from user experience can be used to generate tips/suggestions, instructions, etc., that can be incorporated in the digital twin 130, provided to a user, etc.
At block 1108, a medical event (e.g., surgery, image acquisition, real or virtual office visit, other procedure, etc.) is processed with respect to the patient digital twin 130. For example, image data, sensor data, observations, test results, etc., from a medical event is processed with respect to information and/or modeling of the patient digital twin 130. Image data can be processed to form image analysis, computer aided detection, image quality determination, etc. Sensor data can be processed to identify a value, change, difference with respect to a threshold, etc. Test results can be processed in comparison to a threshold, etc., based on the digital twin 130.
At block 1110, post-event feedback is generated, received, and incorporated to update the patient digital twin 130. Feedback generated from image analysis, sensor data evaluation, test results, human feedback, etc., can represent post-event feedback to be provided to the digital twin 130 for improved modeling, parameter modification, etc. Once the digital twin 130 has been updated, the process 1000 reverts to block 1104 to await further diagnosis.
Thus, the digital twin 130 can evolve over time based on available health data, machine-learning, human feedback, medical event processing, new or updated digital medical knowledge, and post-event feedback. The digital twin 130 provides an evolving model of the patient 110 that can learn and absorb information to reflect patient body systems and health information systems, rules, norms, best practices, etc. Using the patient digital twin 130, a healthcare practitioner may not need to consult with the patient 110. When a new piece of data comes in, the information is automatically analyzed and used to update the digital twin 130 and provide one or more recommendations and/or further actions based on the twin 130 modeled interactions.
In certain examples, as the digital twin 130 updates and evolves/improves over time, prior states of the digital twin 130 are saved. Thus, a prior state of the digital twin 130 can be retrieved and reviewed. For example, a physician can review digital twin 130 states over time to understand changes in the patient's 110 bodily function.
As described above, the patient digital twin 130 can be created (block 1102) by leveraging available patient information such as EMR 210, images 220, genetics 230, laboratory results 240, demographics 250, social history 260, etc. Machine learning and/or other artificial intelligence can be leveraged along with human diagnosis of the patient 110 to improve the digital twin 130 (block 1104). For example, applied knowledge 310, access to care 320, social determinants 330, personal choices 340, costs 350, etc., can be leveraged to improve the digital twin 130. Tips and/or instructions from user experience can also be incorporated to improve the digital twin 130 (block 1106). For example, digital medical knowledge 310 such as rules 410, guidelines 420, medical science 430, molecular science 440, chemical science 450, etc., can be used to improve the digital twin 130 as the knowledge relates to the patient information in the digital twin 130. The digital twin 130 is a new, improved data structure stored in memory that can then be used to respond to and/or anticipate a particular medical event (e.g., surgery, heart attack, diabetes, etc.) (block 1108). For example, digital medical knowledge 310 and access to care 320 can be used with the patient digital twin 130 to help a healthcare practitioner predict and/or respond to a medical event for the patient 110. After the event, feedback can be provided to the patient digital twin 130 and/or to a user via the digital twin 130 (block 1110), for example. In certain examples, algorithms, score cards, patient-defined communication preferences, etc., can be used to evolve the patient digital twin 130 and provide feedback regarding performance indicators and predictions for the patient 110 and/or group of patients (e.g., with same condition, same provider, same location, other commonality, etc.).
At block 1214, one or more images and/or other body scans of the patient 110 can be provided to form the patient digital twin 130. For example, one or more medical images such as x-ray, ultrasound, computed tomography (CT), magnetic resonance (MR), nuclear (NUC), position-emission tomography (PET), and/or other image can help to create the model of the patient digital twin 130. Airport body scans and/or other image data can also be added to create the digital twin 130. Imaging data can be used to form an avatar of the patient 110 for the patient digital twin 130 and/or can be used in combination with other patient data for simulation, diagnosis, etc.
At block 1216, one or more additional data sources can combine with the patient-related information (block 1202) and image information (block 1214) to create the digital twin 130 for the patient 110. For example, at block 1218, information from EMR and/or other medical records (e.g., EHR records, PHR records, etc.) for the patient 110 can be extracted to create the digital twin 130. At block 1220, medication/prescription history can be extracted to create the patient digital twin 130. For example, prescription information can be extracted from a pharmacy system and/or other medication information (e.g., dosage, frequency, reactions, etc.) can be extracted from another information source (e.g., EMR, EHR, PHR, etc.) to supplement the patient digital twin 130. At block 1222, demographic data can be extracted to create the patient digital twin 130. For example, population health information, patient demographics, family and/or friend demographics, neighborhood information, access to care data, etc., can be provided to form the patient digital twin 130 (e.g., from an EMR, EHR, PHR, enterprise archive, etc.). At block 1224, one or more additional sources can provide information to help create the patient digital twin 130.
At block 1226, data submitted and/or otherwise extracted to form the patient digital twin 130 is verified for accuracy. At block 1228, for example, input data is verified with respect to “true” data. For example, multiple instances of data are compared to evaluate the accuracy of the data. For example, a submitted piece of data can be compared against a previously verified piece of data to determine whether the submitted data matches and/or is consistent with the previously verified data. If the same information is provided from multiple sources, the information can be compared to help ensure its consistency. For example, information may have been mis-entered in the EMR but correctly provided in the patient interview. The patient 110 may have guessed at an answer, but the data may have been mathematically verified by the nurse before entry into the patient's chart, for example.
At block 1230, provided data is verified with respect to possible, “normal”, and/or reference data. For example, information can be evaluated to determine whether the information is reasonable, feasible, possible, etc. For example, a data entry indicating the patient 110 is 110 feet tall is determined not to be reasonable and is discarded from the patient digital twin 130. If another data source indicates the patient 110 is six feet tall, then that measurement can be used and the 110-feet measurement discarded, for example.
At block 1232, data quality can be evaluated. For example, patient image data can be evaluated according to a calculated image quality index. If the image data is not of sufficient quality (e.g., image quality index greater than or equal to a quality threshold, etc.), then the data can be discarded as not useful, unreliable, etc., for the patient digital twin 130, for example. As another example, form data may be incomplete, and if less than a certain percentage, number of fields, etc., has been completed, the information may be unable to drive reliable correlations. In certain examples, if input information does not satisfy a quality evaluation, a request can be generated to obtain another sample, another image, a higher quality of data, etc.
Based on the entered and verified information regarding the patient 110 and/or related to the patient 110, the digital twin 130 is created. For example, a neural network and/or other machine- and/or deep-learning construct is populated with inputs corresponding to the verified information and trained to become a deployable model of the patient 110. As another example, a new data structure is created to represent the patient 110 in various aspects. For example, a data structure can be formed representing the patient 110 digitally, and the data structure can include fields representing various body systems (e.g., nervous system, vascular system, muscular system, skeletal system, immune system, etc.) and/or other aspects of the patient 110. Alternatively or in addition, the data structure can be divided according to body system, patient history, environmental/social information, etc. (e.g., as shown in
In certain examples, a neural network, data structure, and/or other digital information construct can include multiple subsystems and/or other sub-instances forming part of the overall digital twin 130. For example, different patient 110 body systems (e.g., vascular, neural, musculoskeletal, immune, etc.) can be structured and modeled as separate networks, data structures, etc. In certain examples, the digital twin 130 can be implemented as a nested series of learning networks, data structures, etc., including an umbrella construct and subsystem constructs formed within the umbrella. Thus, the overall digital twin 130 and subsystems within the digital twin 130 can be stored, processed, modeled, and/or otherwise used with respect to patient 110 diagnosis, treatment, prediction, etc.
At block 1234, after information has been entered (blocks 1202, 1204, 1214, 1216) and verified (block 1226) to create the patient digital twin 130, the patient digital twin 130 can be leverage to create visualization(s) of patient 110 information. For example, the digital twin 130 can be used in simulation/emulation of the patient 110 and conditions experienced and/or likely to be experienced by the patient 110. In certain examples, the patient digital twin 130 can be visualized to a user as an avatar or other visual representation (e.g., two-dimensional, three-dimensional, four-dimensional (e.g., including a time component to simulate, navigate, etc., backward and/or forward in time), etc.) including patient information overlaid on human anatomy visualization, made available upon drilling down into a particular anatomy, etc.
The patient digital twin 130 and risk profile 1302 can be used with rules and analytics 1304 to drive health outcomes for the patient 110. For example, the digital twin 130 and/or associated system (e.g., an EMR system, RIS/PACS system, etc.) can be programmed with rules and/or analytics 1304 to leverage the information, modeling, etc., provided by the digital twin 130 to make a decision, inform a decision, and/or otherwise drive a health outcome for the patient 110 (and/or a population including the patient 110, etc.). For example, at block 1306, the rules and analytics 1304 can be applied to the patient digital twin 130 and associated risk profile 1302 to generate an automated diagnosis recommendation. At block 1308, the rules and analytics 1304 can be applied to the patient digital twin 130 and associated risk profile 1302 to generate specific recommended actions to be taken (e.g., by the patient 110 and/or healthcare practitioner, etc.). Thus, rules and analytics 1304 can be put around the patient digital twin 130 to model probabilities, risks, and likely outcomes for the patient 110. A computer-assisted diagnosis (CAD) 1306 and recommended course of action (e.g., care plan, etc.) can be generated for the patient 110 and/or healthcare practitioner (e.g., care team, primary physician, surgeon, nurse, etc.) to follow. The course of action can be customized for that particular patient 110 given the patient digital twin 130.
Thus, certain examples provide the creation, use, and storage of the patient digital twin 130. The patient digital twin 130 can be used with a plurality of application including electronic medical records, revenue cycle, scheduling, image analysis, etc. The patient digital twin 130 can be used to drive a workflow engine, rules engine, etc. The patient digital twin 130 can be used in conjunction with a data capture engine with digital devices (e.g., edge devices for a cloud network, etc.), Web applications, social media, etc. Knowledge sources such as medical, chemical, genetic, etc., can be leveraged with and/or incorporated into the digital twin 130, for example. A data ingestion engine can operate based on information in and/or missing from the patient digital twin 130, for example. The patient digital twin 130 can be used in conjunction with an analytics engine to drive health outcomes, for example. The patient digital twin 130 is “the system of record” about the patient 110. The patient digital twin 130 includes clinical, genetic, family history, financial, environmental, and social data associated with the patient 110, for example. The patient digital twin 130 can be used by artificial intelligence (e.g., machine learning, deep learning, etc.) and/or other algorithms expressing scientific and medical knowledge to help the patient 110 maximize his or her health.
The patient digital twin 130 thus improves existing modeling of patient information. The patient digital twin 130 provides a new, improved representation of patient information and construct for simulation of patient health outcomes. The patient digital twin 130 improves health information systems and analytics processors by providing such systems with a new twin or model for data retrieval, data update, modeling, simulation, prediction, etc., not previously available from a static table of patient data. The patient digital twin 130 helps solve the problem of static, disjointed patient data and lack of ties between patient information, medical knowledge, access to care, cost, social context, and personal choices for proactive patient care and improved health outcomes.
The patient digital twin 130 provides a new, beneficial representation improving patient records and interaction technology as well as a new, innovative data structure for patient information modeling. For example, the patient digital twin 130 serves as a data set driving artificial intelligence algorithms. Rather than merely providing a table or data record to be queried for a search result, the patient digital twin 130 provides a shared augmented reality experience for the patient 110 and his/her care providers, for example. The patient digital twin 130 serves as a data set to drive planning and delivery of care to the patient 110 by care professionals, for example. The patient digital twin 130 also facilitates communicating care instructions to the patient 110 and his/her care team, as well as modeling those instructions and monitoring their progress, for example.
Thus, patient information and medical knowledge can be digitized together and combined in the patient digital twin 130 to provide an infrastructure to examine and process the data in an organized way to make valid medical decisions. Additional data such as family history, social determinants of health, etc., can also be incorporated into the digital twin 130 and leveraged to diagnose and treat the patient 110, for example. When data flows into a healthcare system, data associated with the patient 110 can be represented through the patient digital twin 130, and the digital twin 130 can provide a mechanism for diagnosis and modeling without even seeing the actual patient 110, for example. Information can be taken from an ambulatory EMR, RIS, PACS, etc., and incorporated in the digital twin 130 to improve, update, etc., the model of the patient 110. At certain times (e.g., pre- and post-operation, pre-exam, etc.), medical knowledge can be applied to the patient digital twin 130, which has different behavior characteristics in different circumstances based on the patient's 110 condition, setting, etc. The patient digital twin 130 expresses a digital version of the patient 110 that forms the center point of a rules/algorithm-driven care management system combining digital patient knowledge, digital medical knowledge, and social knowledge to improve patient health outcomes.
In certain examples, the patient digital twin 130 forms a model that can be used with a transfer function to mathematically represent or model inputs to and outputs from the patient 110 (e.g., physical changes, mental changes, symptoms, etc., and resulting conditions, effects, etc.). The transfer function helps the digital twin 130 to generate and model patient 110 attributes and/or evaluation metrics, for example. In certain examples, variation can be modeled based on analytics, etc., and modeled variation can be used to evaluate possible health outcomes for the patient 110 via the patient digital twin 130.
Machine Learning Example
Machine learning techniques, whether deep learning networks or other experiential/observational learning system, can be used to model information in the digital twin 130 and/or leverage the patient digital twin 130 to analyze and/or predict a patient 110 outcome, for example. Deep learning is a subset of machine learning that uses a set of algorithms to model high-level abstractions in data using a deep graph with multiple processing layers including linear and non-linear transformations. While many machine learning systems are seeded with initial features and/or network weights to be modified through learning and updating of the machine learning network, a deep learning network trains itself to identify “good” features for analysis. Using a multilayered architecture, machines employing deep learning techniques can process raw data better than machines using conventional machine learning techniques. Examining data for groups of highly correlated values or distinctive themes is facilitated using different layers of evaluation or abstraction.
Deep learning is a class of machine learning techniques employing representation learning methods that allows a machine to be given raw data and determine the representations needed for data classification. Deep learning ascertains structure in data sets using backpropagation algorithms which are used to alter internal parameters (e.g., node weights) of the deep learning machine. Deep learning machines can utilize a variety of multilayer architectures and algorithms. While machine learning, for example, involves an identification of features to be used in training the network, deep learning processes raw data to identify features of interest without the external identification.
Deep learning in a neural network environment includes numerous interconnected nodes referred to as neurons. Input neurons, activated from an outside source, activate other neurons based on connections to those other neurons which are governed by the machine parameters. A neural network behaves in a certain manner based on its own parameters. Learning refines the machine parameters, and, by extension, the connections between neurons in the network, such that the neural network behaves in a desired manner.
Deep learning that utilizes a convolutional neural network (CNN) segments data using convolutional filters to locate and identify learned, observable features in the data. Each filter or layer of the CNN architecture transforms the input data to increase the selectivity and invariance of the data. This abstraction of the data allows the machine to focus on the features in the data it is attempting to classify and ignore irrelevant background information.
Alternatively or in addition to the CNN, a deep residual network can be used. In a deep residual network, a desired underlying mapping is explicitly defined in relation to stacked, non-linear internal layers of the network. Using feedforward neural networks, deep residual networks can include shortcut connections that skip over one or more internal layers to connect nodes. A deep residual network can be trained end-to-end by stochastic gradient descent (SGD) with backpropagation, such as described above.
Deep learning operates on the understanding that many datasets include high level features which include low level features. While examining an image, for example, rather than looking for an object, it is more efficient to look for edges which form motifs which form parts, which form the object being sought. These hierarchies of features can be found in many different forms of data such as speech and text, etc.
Learned observable features include objects and quantifiable regularities learned by the machine during supervised learning. A machine provided with a large set of well classified data is better equipped to distinguish and extract the features pertinent to successful classification of new data.
A deep learning machine that utilizes transfer learning may properly connect data features to certain classifications affirmed by a human expert. Conversely, the same machine can, when informed of an incorrect classification by a human expert, update the parameters for classification. Settings and/or other configuration information, for example, can be guided by learned use of settings and/or other configuration information, and, as a system is used more (e.g., repeatedly and/or by multiple users), a number of variations and/or other possibilities for settings and/or other configuration information can be reduced for a given situation.
An example deep learning neural network can be trained on a set of expert classified data, for example. This set of data builds the first parameters for the neural network, and this would be the stage of supervised learning. During the stage of supervised learning, the neural network can be tested whether the desired behavior has been achieved.
Once a desired neural network behavior has been achieved (e.g., a machine has been trained to operate according to a specified threshold, etc.), the machine can be deployed for use (e.g., testing the machine with “real” data, etc.). During operation, neural network classifications can be confirmed or denied (e.g., by an expert user, expert system, reference database, etc.) to continue to improve neural network behavior. The example neural network is then in a state of transfer learning, as parameters for classification that determine neural network behavior are updated based on ongoing interactions. In certain examples, the neural network can provide direct feedback to another process. In certain examples, the neural network outputs data that is buffered (e.g., via the cloud, etc.) and validated before it is provided to another process.
Deep learning machines using convolutional neural networks (CNNs) can be used for data analysis. Stages of CNN analysis can be used for facial recognition in natural images, computer-aided diagnosis (CAD), etc.
Deep learning machines can provide computer aided detection support to improve image analysis, as well as computer aided diagnosis for the patient 110. Supervised deep learning can help reduce susceptibility to false classification, for example. Deep learning machines can utilize transfer learning when interacting with physicians to counteract the small dataset available in the supervised training. These deep learning machines can improve their computer aided diagnosis over time through training and transfer learning.
The layer 1420 is an input layer that, in the example of
Of connections 1430, 1450, and 1470 certain example connections 1432, 1452, 1472 may be given added weight while other example connections 1434, 1454, 1474 may be given less weight in the neural network 1400. Input nodes 1422-1426 are activated through receipt of input data via inputs 1412-1416, for example. Nodes 1442-1448 and 1462-1468 of hidden layers 1440 and 1460 are activated through the forward flow of data through the network 1400 via the connections 1430 and 1450, respectively. Node 1482 of the output layer 1480 is activated after data processed in hidden layers 1440 and 1460 is sent via connections 1470. When the output node 1482 of the output layer 1480 is activated, the node 1482 outputs an appropriate value based on processing accomplished in hidden layers 1440 and 1460 of the neural network 1400.
Example Healthcare Systems and Environments
Health information, also referred to as healthcare information and/or healthcare data, relates to information generated and/or used by a healthcare entity. Health information can be information associated with health of one or more patients, for example. Health information may include protected health information (PHI), as outlined in the Health Insurance Portability and Accountability Act (HIPAA), which is identifiable as associated with a particular patient and is protected from unauthorized disclosure. Health information can be organized as internal information and external information. Internal information includes patient encounter information (e.g., patient-specific data, aggregate data, comparative data, etc.) and general healthcare operations information, etc. External information includes comparative data, expert and/or knowledge-based data, etc. Information can have both a clinical (e.g., diagnosis, treatment, prevention, etc.) and administrative (e.g., scheduling, billing, management, etc.) purpose.
Institutions, such as healthcare institutions, having complex network support environments and sometimes chaotically driven process flows utilize secure handling and safeguarding of the flow of sensitive information (e.g., personal privacy). A need for secure handling and safeguarding of information increases as a demand for flexibility, volume, and speed of exchange of such information grows. For example, healthcare institutions provide enhanced control and safeguarding of the exchange and storage of sensitive patient protected health information (PHI) between diverse locations to improve hospital operational efficiency in an operational environment typically having a chaotic-driven demand by patients for hospital services. In certain examples, patient identifying information can be masked or even stripped from certain data depending upon where the data is stored and who has access to that data. In some examples, PHI that has been “de-identified” can be re-identified based on a key and/or other encoder/decoder.
A healthcare information technology infrastructure can be adapted to service multiple business interests while providing clinical information and services. Such an infrastructure may include a centralized capability including, for example, a data repository, reporting, discrete data exchange/connectivity, “smart” algorithms, personalization/consumer decision support, etc. This centralized capability provides information and functionality to a plurality of users including medical devices, electronic records, access portals, pay for performance (P4P), chronic disease models, and clinical health information exchange/regional health information organization (HIE/RHIO), and/or enterprise pharmaceutical studies, home health, for example.
Interconnection of multiple data sources helps enable an engagement of all relevant members of a patient's care team and helps improve an administrative and management burden on the patient for managing his or her care. Particularly, interconnecting the patient's electronic medical record and/or other medical data can help improve patient care and management of patient information. Furthermore, patient care compliance is facilitated by providing tools that automatically adapt to the specific and changing health conditions of the patient and provide comprehensive education and compliance tools to drive positive health outcomes.
In certain examples, healthcare information can be distributed among multiple applications using a variety of database and storage technologies and data formats. To provide a common interface and access to data residing across these applications, a connectivity framework (CF) can be provided which leverages common data and service models (CDM and CSM) and service oriented technologies, such as an enterprise service bus (ESB) to provide access to the data.
In certain examples, a variety of user interface frameworks and technologies can be used to build applications for health information systems including, but not limited to, MICROSOFT® ASP.NET, AJAX®, MICROSOFT® Windows Presentation Foundation, GOOGLE® Web Toolkit, MICROSOFT® Silverlight, ADOBE®, and others. Applications can be composed from libraries of information widgets to display multi-content and multi-media information, for example. In addition, the framework enables users to tailor layout of applications and interact with underlying data.
In certain examples, an advanced Service-Oriented Architecture (SOA) with a modern technology stack helps provide robust interoperability, reliability, and performance. Example SOA includes a three-fold interoperability strategy including a central repository (e.g., a central repository built from Health Level Seven (HL7) transactions), services for working in federated environments, and visual integration with third-party applications. Certain examples provide portable content enabling plug 'n play content exchange among healthcare organizations. A standardized vocabulary using common standards (e.g., LOINC, SNOMED CT, RxNorm, FDB, ICD-9, ICD-10, CCDA, etc.) is used for interoperability, for example. Certain examples provide an intuitive user interface to help minimize end-user training. Certain examples facilitate user-initiated launching of third-party applications directly from a desktop interface to help provide a seamless workflow by sharing user, patient, and/or other contexts. Certain examples provide real-time (or at least substantially real time assuming some system delay) patient data from one or more information technology (IT) systems and facilitate comparison(s) against evidence-based best practices. Certain examples provide one or more dashboards for specific sets of patients. Dashboard(s) can be based on condition, role, and/or other criteria to indicate variation(s) from a desired practice, for example.
Example Healthcare Information System
An information system can be defined as an arrangement of information/data, processes, and information technology that interact to collect, process, store, and provide informational output to support delivery of healthcare to one or more patients. Information technology includes computer technology (e.g., hardware and software) along with data and telecommunications technology (e.g., data, image, and/or voice network, etc.).
Turning now to the figures,
As illustrated in
Example input 1510 may include a keyboard, a touch-screen, a mouse, a trackball, a track pad, optical barcode recognition, voice command, etc. or combination thereof used to communicate an instruction or data to system 1500. Example input 1510 may include an interface between systems, between user(s) and system 1500, etc.
Example output 1520 can provide a display generated by processor 1530 for visual illustration on a monitor or the like. The display can be in the form of a network interface or graphic user interface (GUI) to exchange data, instructions, or illustrations on a computing device via communication interface 1550, for example. Example output 1520 may include a monitor (e.g., liquid crystal display (LCD), plasma display, cathode ray tube (CRT), etc.), light emitting diodes (LEDs), a touch-screen, a printer, a speaker, or other conventional display device or combination thereof
Example processor 1530 includes hardware and/or software configuring the hardware to execute one or more tasks and/or implement a particular system configuration. Example processor 1530 processes data received at input 1510 and generates a result that can be provided to one or more of output 1520, memory 1540, and communication interface 1550. For example, example processor 1530 can take user annotation provided via input 1510 with respect to an image displayed via output 1520 and can generate a report associated with the image based on the annotation. As another example, processor 1530 can process imaging protocol information obtained via input 1510 to provide an updated configuration for an imaging scanner via communication interface 1550.
Example memory 1540 can include a relational database, an object-oriented database, a Hadoop data construct repository, a data dictionary, a clinical data repository, a data warehouse, a data mart, a vendor neutral archive, an enterprise archive, etc. Example memory 1540 stores images, patient data, best practices, clinical knowledge, analytics, reports, etc. Example memory 1540 can store data and/or instructions for access by the processor 1530 (e.g., including the patient digital twin 130). In certain examples, memory 1540 can be accessible by an external system via the communication interface 1550.
Example communication interface 1550 facilitates transmission of electronic data within and/or among one or more systems. Communication via communication interface 1550 can be implemented using one or more protocols. In some examples, communication via communication interface 1550 occurs according to one or more standards (e.g., Digital Imaging and Communications in Medicine (DICOM), Health Level Seven (HL7), ANSI X12N, etc.), or proprietary systems. Example communication interface 1550 can be a wired interface (e.g., a data bus, a Universal Serial Bus (USB) connection, etc.) and/or a wireless interface (e.g., radio frequency, infrared (IR), near field communication (NFC), etc.). For example, communication interface 1550 may communicate via wired local area network (LAN), wireless LAN, wide area network (WAN), etc. using any past, present, or future communication protocol (e.g., BLUETOOTH™, USB 2.0, USB 3.0, etc.).
In certain examples, a Web-based portal or application programming interface (API), may be used to facilitate access to information, protocol library, imaging system configuration, patient care and/or practice management, etc. Information and/or functionality available via the Web-based portal may include one or more of order entry, laboratory test results review system, patient information, clinical decision support, medication management, scheduling, electronic mail and/or messaging, medical resources, etc. In certain examples, a browser-based interface can serve as a zero footprint, zero download, and/or other universal viewer for a client device.
In certain examples, the Web-based portal or API serves as a central interface to access information and applications, for example. Data may be viewed through the Web-based portal or viewer, for example. Additionally, data may be manipulated and propagated using the Web-based portal, for example. Data may be generated, modified, stored and/or used and then communicated to another application or system to be modified, stored and/or used, for example, via the Web-based portal, for example.
The Web-based portal or API may be accessible locally (e.g., in an office) and/or remotely (e.g., via the Internet and/or other private network or connection), for example. The Web-based portal may be configured to help or guide a user in accessing data and/or functions to facilitate patient care and practice management, for example. In certain examples, the Web-based portal may be configured according to certain rules, preferences and/or functions, for example. For example, a user may customize the Web portal according to particular desires, preferences and/or requirements.
Example Healthcare Infrastructure
The RIS 1606 stores information such as, for example, radiology reports, radiology exam image data, messages, warnings, alerts, patient scheduling information, patient demographic data, patient tracking information, and/or physician and patient status monitors. Additionally, RIS 1606 enables exam order entry (e.g., ordering an x-ray of a patient) and image and film tracking (e.g., tracking identities of one or more people that have checked out a film). In some examples, information in RIS 1606 is formatted according to the HL-7 (Health Level Seven) clinical communication protocol. In certain examples, a medical exam distributor is located in RIS 1606 to facilitate distribution of radiology exams to a radiologist workload for review and management of the exam distribution by, for example, an administrator.
PACS 1608 stores medical images (e.g., x-rays, scans, three-dimensional renderings, etc.) as, for example, digital images in a database or registry. In some examples, the medical images are stored in PACS 1608 using the Digital Imaging and Communications in Medicine (DICOM) format. Images are stored in PACS 1608 by healthcare practitioners (e.g., imaging technicians, physicians, radiologists) after a medical imaging of a patient and/or are automatically transmitted from medical imaging devices to PACS 1608 for storage. In some examples, PACS 1608 can also include a display device and/or viewing workstation to enable a healthcare practitioner or provider to communicate with PACS 1608.
The interface unit 1610 includes a hospital information system interface connection 1616, a radiology information system interface connection 1618, a PACS interface connection 1620, and a data center interface connection 1622. Interface unit 1610 facilities communication among imaging modality 1604, RIS 1606, PACS 1608, and/or data center 1612. Interface connections 1616, 1618, 1620, and 1622 can be implemented by, for example, a Wide Area Network (WAN) such as a private network or the Internet. Accordingly, interface unit 1610 includes one or more communication components such as, for example, an Ethernet device, an asynchronous transfer mode (ATM) device, an 802.11 device, a DSL modem, a cable modem, a cellular modem, etc. In turn, the data center 1612 communicates with workstation 1614, via a network 1624, implemented at a plurality of locations (e.g., a hospital, clinic, doctor's office, other medical office, or terminal, etc.). Network 1624 is implemented by, for example, the Internet, an intranet, a private network, a wired or wireless Local Area Network, and/or a wired or wireless Wide Area Network. In some examples, interface unit 210 also includes a broker (e.g., a Mitra Imaging's PACS Broker) to allow medical information and medical images to be transmitted together and stored together.
Interface unit 1610 receives images, medical reports, administrative information, exam workload distribution information, and/or other clinical information from the information systems 1604, 1606, 1608 via the interface connections 1616, 1618, 1620. If necessary (e.g., when different formats of the received information are incompatible), interface unit 1610 translates or reformats (e.g., into Structured Query Language (“SQL”) or standard text) the medical information, such as medical reports, to be properly stored at data center 1612. The reformatted medical information can be transmitted using a transmission protocol to enable different medical information to share common identification elements, such as a patient name or social security number. Next, interface unit 1610 transmits the medical information to data center 1612 via data center interface connection 1622. Finally, medical information is stored in data center 1612 in, for example, the DICOM format, which enables medical images and corresponding medical information to be transmitted and stored together.
The medical information is later viewable and easily retrievable at workstation 1614 (e.g., by their common identification element, such as a patient name or record number). Workstation 1614 can be any equipment (e.g., a personal computer) capable of executing software that permits electronic data (e.g., medical reports) and/or electronic medical images (e.g., x-rays, ultrasounds, MRI scans, etc.) to be acquired, stored, or transmitted for viewing and operation. Workstation 1614 receives commands and/or other input from a user via, for example, a keyboard, mouse, track ball, microphone, etc. Workstation 1614 is capable of implementing a user interface 1626 to enable a healthcare practitioner and/or administrator to interact with healthcare system 1600. For example, in response to a request from a physician, user interface 1626 presents a patient medical history. In other examples, a radiologist is able to retrieve and manage a workload of exams distributed for review to the radiologist via user interface 1626. In further examples, an administrator reviews radiologist workloads, exam allocation, and/or operational statistics associated with the distribution of exams via user interface 1626. In some examples, the administrator adjusts one or more settings or outcomes via user interface 1626.
Example data center 1612 of
Example data center 1612 of
Certain examples can be implemented as cloud-based clinical information systems and associated methods of use. An example cloud-based clinical information system enables healthcare entities (e.g., patients, clinicians, sites, groups, communities, and/or other entities) to share information via web-based applications, cloud storage and cloud services. For example, the cloud-based clinical information system may enable a first clinician to securely upload information into the cloud-based clinical information system to allow a second clinician to view and/or download the information via a web application. Thus, for example, the first clinician may upload an x-ray imaging protocol into the cloud-based clinical information system, and the second clinician may view and download the x-ray imaging protocol via a web browser and/or download the x-ray imaging protocol onto a local information system employed by the second clinician.
In certain examples, users (e.g., a patient and/or care provider) can access functionality provided by system 1600 via a software-as-a-service (SaaS) implementation over a cloud or other computer network, for example. In certain examples, all or part of system 1600 can also be provided via platform as a service (PaaS), infrastructure as a service (IaaS), etc. For example, system 1600 can be implemented as a cloud-delivered Mobile Computing Integration Platform as a Service. A set of consumer-facing Web-based, mobile, and/or other applications enable users to interact with the PaaS, for example.
Industrial Internet Examples
The Internet of things (also referred to as the “Industrial Internet”) relates to an interconnection between a device that can use an Internet connection to talk with other devices and/or applications on the network. Using the connection, devices can communicate to trigger events/actions (e.g., changing temperature, turning on/off, providing a status, etc.). In certain examples, machines can be merged with “big data” to improve efficiency and operations, provide improved data mining, facilitate better operation, etc.
Big data can refer to a collection of data so large and complex that it becomes difficult to process using traditional data processing tools/methods. Challenges associated with a large data set include data capture, sorting, storage, search, transfer, analysis, and visualization. A trend toward larger data sets is due at least in part to additional information derivable from analysis of a single large set of data, rather than analysis of a plurality of separate, smaller data sets. By analyzing a single large data set, correlations can be found in the data, and data quality can be evaluated.
As shown in the example of
Thus, machines 1710-1712 within system 1700 become “intelligent” as a network with advanced sensors, controls, analytical based decision support and hosting software applications. Using such an infrastructure, advanced analytics can be provided to associated data. The analytics combines physics-based analytics, predictive algorithms, automation, and deep domain expertise. Via cloud 1720, devices 1710-1712 and associated people can be connected to support more intelligent design, operations, maintenance, and higher server quality and safety, for example.
Using the industrial internet infrastructure, for example, a proprietary machine data stream can be extracted from a device 1710. Machine-based algorithms and data analysis are applied to the extracted data. Data visualization can be remote, centralized, etc. Data is then shared with authorized users, and any gathered and/or gleaned intelligence is fed back into the machines 1710-1712.
While progress with industrial equipment automation has been made over the last several decades, and assets have become ‘smarter,’ the intelligence of any individual asset pales in comparison to intelligence that can be gained when multiple smart devices are connected together. Aggregating data collected from or about multiple assets can enable users to improve business processes, for example by improving effectiveness of asset maintenance or improving operational performance if appropriate industrial-specific data collection and modeling technology is developed and applied.
In an example, data from one or more sensors can be recorded or transmitted to a cloud-based or other remote computing environment. Insights gained through analysis of such data in a cloud-based computing environment can lead to enhanced asset designs, or to enhanced software algorithms for operating the same or similar asset at its edge, that is, at the extremes of its expected or available operating conditions. For example, sensors associated with the patient 110 can supplement the modeled information of the patient digital twin 130, which can be stored and/or otherwise instantiated in a cloud-based computing environment for access by a plurality of systems with respect to the patient 110.
Systems and methods described herein can include using a “cloud” or remote or distributed computing resource or service. The cloud can be used to receive, relay, transmit, store, analyze, or otherwise process information for or about the patient 110 and his/her digital twin 130, for example. In an example, a cloud computing system includes at least one processor circuit, at least one database, and a plurality of users or assets that are in data communication with the cloud computing system. The cloud computing system can further include or can be coupled with one or more other processor circuits or modules configured to perform a specific task, such as to perform tasks related to patient monitoring, diagnosis, treatment, scheduling, etc., via the digital twin 130.
Data Mining Examples
Imaging informatics includes determining how to tag and index a large amount of data acquired in diagnostic imaging in a logical, structured, and machine-readable format. By structuring data logically, information can be discovered and utilized by algorithms that represent clinical pathways and decision support systems. Data mining can be used to help ensure patient safety, reduce disparity in treatment, provide clinical decision support, etc. Mining both structured and unstructured data from radiology reports, as well as actual image pixel data, can be used to tag and index both imaging reports and the associated images themselves. Data mining can be used to provide information to the patient digital twin 130, for example.
Example Methods of Use
Clinical workflows are typically defined to include one or more steps or actions to be taken in response to one or more events and/or according to a schedule. Events may include receiving a healthcare message associated with one or more aspects of a clinical record, opening a record(s) for new patient(s), receiving a transferred patient, reviewing and reporting on an image, executing orders for specific care, signing off on orders for a discharge, and/or any other instance and/or situation that requires or dictates responsive action or processing. The actions or steps of a clinical workflow may include placing an order for one or more clinical tests, scheduling a procedure, requesting certain information to supplement a received healthcare record, retrieving additional information associated with a patient, providing instructions to a patient and/or a healthcare practitioner associated with the treatment of the patient, radiology image reading, dispatching room cleaning and/or patient transport, and/or any other action useful in processing healthcare information or causing critical path care activities to progress. The defined clinical workflows may include manual actions or steps to be taken by, for example, an administrator or practitioner, electronic actions or steps to be taken by a system or device, and/or a combination of manual and electronic action(s) or step(s). While one entity of a healthcare enterprise may define a clinical workflow for a certain event in a first manner, a second entity of the healthcare enterprise may define a clinical workflow of that event in a second, different manner. In other words, different healthcare entities may treat or respond to the same event or circumstance in different fashions. Differences in workflow approaches may arise from varying preferences, capabilities, requirements or obligations, standards, protocols, etc. among the different healthcare entities.
In certain examples, a medical exam conducted on a patient can involve review by a healthcare practitioner, such as a radiologist, to obtain, for example, diagnostic information from the exam. In a hospital setting, medical exams can be ordered for a plurality of patients, all of which require review by an examining practitioner. Each exam has associated attributes, such as a modality, a part of the human body under exam, and/or an exam priority level related to a patient criticality level. Hospital administrators, in managing distribution of exams for review by practitioners, can consider the exam attributes as well as staff availability, staff credentials, and/or institutional factors such as service level agreements and/or overhead costs.
Additional workflows can be facilitated such as bill processing, revenue cycle mgmt., population health management, patient identity, consent management, etc.
While example implementations are illustrated in conjunction with
Flowcharts representative of example machine readable instructions for implementing components disclosed and described herein are shown in conjunction with
As mentioned above, the example data structures and/or processes of at least
The processor platform 1800 of the illustrated example includes a processor 1812. The processor 1812 of the illustrated example is hardware. For example, the processor 1812 can be implemented by integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer.
The processor 1812 of the illustrated example includes a local memory 1813 (e.g., a cache). The example processor 1812 of
The processor platform 1800 of the illustrated example also includes an interface circuit 1820. The interface circuit 1820 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface.
In the illustrated example, one or more input devices 1822 are connected to the interface circuit 1820. The input device(s) 1822 permit(s) a user to enter data and commands into the processor 1812. The input device(s) can be implemented by, for example, a sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.
One or more output devices 1824 are also connected to the interface circuit 1820 of the illustrated example. The output devices 1824 can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, and/or speakers). The interface circuit 1820 of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip or a graphics driver processor.
The interface circuit 1820 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 1826 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.).
The processor platform 1800 of the illustrated example also includes one or more mass storage devices 1828 for storing software and/or data. Examples of such mass storage devices 1828 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.
The coded instructions 1832 of
From the foregoing, it will be appreciated that the above disclosed methods, apparatus, and articles of manufacture have been disclosed to create and dynamically update a patient digital twin that can be used in patient simulation, analysis, diagnosis, and treatment to improve patient health outcome.
Although certain example methods, apparatus and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent.