Methods and systems for decision maker focus and therapy planning using longitudinal patient timelines

Abstract

Medical decision makers are important to healthcare. Systems and methods are presented herein for providing a focused decision maker user interface (UI). The systems and methods also allow for treatment planning and decision maker learning via an innovative UI by employing a longitudinal patient timeline (510, 600). Decision points of the patient timeline are identified, and learning content is provided based on events and based on decision-based outcomes. These learning content includes comparisons with other similar patients, decisions made by other renowned medical decision makers, and aha moments.

Description

Background Technology

[0001] This disclosure relates to the use of generative artificial intelligence (AI) and user interface (UI) for medical treatment of patients, and more specifically to systems and methods for using longitudinal patient timelines for decision-maker focus and treatment planning.

[0002] Clinicians make treatment decisions for complex medical conditions such as cancer or rare diseases, but medical guidance is constantly evolving and may not always have all the information to make the best decision for a particular patient at a given time. Patients frequently seek second opinions due to a relatively high rate of unsatisfactory treatment plans and new, cutting-edge potential treatments. Improved technologies are needed to provide better diagnoses, offer clinicians better information, including review views to help them make improvements as decision-makers, and treatment insights. Intuitive UIs are also needed to make this information easily digestible for humans. Summary of the Invention

[0003] The following summary is provided to offer a basic understanding of one or more embodiments described herein. This summary is not intended to identify key or essential elements, nor to depict the scope of specific embodiments or the claims. Its sole purpose is to present concepts in a simplified form as a preamble to the more detailed description that follows. In one or more embodiments described herein, systems, computer-implemented methods, apparatuses, and / or computer program products supporting generative AI-based solutions for evaluating treatment options for patients are discussed.

[0004] According to an embodiment, a system is provided. The system may include a memory capable of storing computer-executable components. The system may also include a processor executable on the computer-executable components stored in the memory, wherein the computer-executable components may include a data access component that accesses first data, including first patient data associated with a patient, second patient data associated with one or more additional patients, a set of clinical rules, and treatment information related to the patient's medical condition. The data access component may also access second data, including one or more outcomes resulting from clinical decisions associated with the medical condition. The computer-executable components may further include a data generation component that identifies one or more cohorts of the patient's medical history based on analysis of the first and second data. The data generation component may generate third data, including at least two alternative treatment plans that can be used for subsequent treatment of the medical condition, based at least on the first data, the second data, and the one or more cohorts of the patient's medical history. The computer-executable components may further include a display component that can display a patient timeline on a device's user interface (UI), the patient timeline including a chronological view of the patient's medical condition-specific history. The display component may highlight clinical decisions and the one or more outcomes on the UI via bounding boxes. The display component can also show a visual connection between clinical decisions and the one or more outcomes on the UI to highlight the progress of the patient's medical course based on the clinical decisions. The display component can also show visualizations of the one or more cohorts of the patient's medical course on the UI, wherein the visualizations can be influential in evaluating the at least two alternative treatment plans in reference cohort outcomes, and wherein the visualizations can be used by the medical device to automatically execute actions related to subsequent treatment of the medical condition based on at least one cohort of the one or more cohorts of the patient's medical course, provided that the at least one cohort meets a defined set of criteria.

[0005] According to another embodiment, a computer-implemented method is provided. The computer-implemented method may include system access to first data operatively coupled to a processor, the first data including first patient data associated with a patient, second patient data associated with one or more additional patients, a set of clinical rules, and treatment information related to the patient's medical condition. The computer-implemented method may also include system access to second data, the second data including one or more outcomes arising from clinical decisions associated with the medical condition. The computer-implemented method may further include system analysis of the first and second data via generative AI. The computer-implemented method may further include system identification of one or more cohorts of the patient's medical history based on the analysis of the first and second data via generative AI. The computer-implemented method may further include system generation of third data via generative AI based at least on the first data, the second data, and the one or more cohorts of the patient's medical history, the third data including at least two alternative treatment plans that can be used for subsequent treatment of the medical condition. The computer-implemented method may further include system displaying a patient timeline on a device's UI, the patient timeline including a chronological view of the patient's medical condition-specific medical history. The computer-implemented method may also include visualization of the patient’s medical history in one or more cohorts displayed by the system on a UI, wherein the visualization may be influential in assessing the at least two alternative treatment plans in reference cohort results.

[0006] According to another embodiment, a computer program product is provided. The computer program product may include a non-transitory computer-readable storage device having program instructions embodied therein, the program instructions being executable by a processor to cause the processor to access first data, the first data including first patient data associated with a patient, second patient data associated with one or more additional patients, a set of clinical rules, and treatment information related to the patient's medical condition. The program instructions are also executable by the processor to cause the processor to access second data, the second data including one or more results generated by clinical decisions associated with the medical condition. The program instructions are also executable by the processor to cause the processor to analyze the first and second data via generative AI. The program instructions are also executable by the processor to cause the processor to identify one or more queues of the patient's medical history based on the analysis of the first and second data via generative AI. The program instructions are also executable by the processor to cause the processor to generate third data via generative AI at least based on the first data, the second data, and the one or more queues of the patient's medical history, the third data including at least two alternative treatment plans that can be used for subsequent treatment of the medical condition. The program instructions are also executable by the processor to cause the processor to display a patient timeline on a device's UI, the patient timeline including a chronological view of the patient's medical condition-specific medical history. The program instructions can also be executed by the processor to display a visualization of the patient’s medical history in one or more queues on the UI, wherein the visualization may have an impact on the evaluation of the at least two alternative treatment plans in reference queue results. Attached Figure Description

[0007] One or more embodiments are described below with reference to the following figures in the Detailed Description section:

[0008] Figure 1A A diagram illustrating an example non-limiting system according to one or more embodiments described herein is provided for patient history analysis and timeline segmentation using an electronic health record (EHR) display system.

[0009] Figure 1B A diagram illustrating an example non-limiting method according to one or more embodiments described herein is provided for timeline segmentation and display of a patient's electronic health record (EHR) on a display device.

[0010] Figure 1C A diagram illustrating an example non-limiting method according to one or more embodiments described herein is provided for timeline segmentation and display of a patient's EHR on a display device.

[0011] Figure 1DA diagram illustrating an example non-limiting process according to one or more embodiments described herein, which can be used to utilize... Figure 1A The system aims to improve data access and integration for multidisciplinary teams.

[0012] Figure 1E A diagram illustrating an example non-limiting process according to one or more embodiments described herein, the process being used to utilize Figure 1A The system generates longitudinal data elements of patients to display to users.

[0013] Figure 2A A block diagram of an example non-limiting system according to one or more embodiments described herein is illustrated, which can employ software and AI to present decision-maker-specific visualizations of a patient’s medical history and generate alternative treatment plans that can be used for subsequent treatment of the disease.

[0014] Figure 2B Another block diagram illustrating an example non-limiting system according to one or more embodiments described herein is shown, which can present a visualization of a patient’s medical history, including decision-maker-specific visualizations, and can have the ability to generate alternative treatment plans that can be used for subsequent treatment of the disease.

[0015] Figure 3 A diagram illustrating an example non-limiting UI according to one or more embodiments described herein, showing a timeline view of a patient's medical history.

[0016] Figure 4 A diagram illustrating an example non-limiting UI according to one or more embodiments described herein, showing a timeline view of a patient's medical history specific to their medical condition.

[0017] Figure 5 Examples are illustrated according to one or more embodiments described herein. Figure 3 and Figure 4 The illustrated example is a non-restricted patient timeline plot to show a comparison between two patient timelines.

[0018] Figure 6 An example non-restrictive patient timeline diagram illustrating a portion of a patient's medical history is shown according to one or more embodiments described herein.

[0019] Figure 7 A diagram illustrating an example non-limiting UI according to one or more embodiments described herein, which can be used to visualize medical research related to a patient's medical condition.

[0020] Figure 8A diagram illustrating an example non-limiting UI according to one or more embodiments described herein is provided, which can be used to visualize treatment plans adopted by medical practitioners specializing in treating patients' medical conditions.

[0021] Figure 9 A diagram illustrating an example non-limiting UI according to one or more embodiments described herein, which can be used to mark moments of insight in a patient's medical journey.

[0022] Figure 10 An example non-restrictive patient timeline diagram is illustrated according to one or more embodiments described herein, showing a parallel view of moments of insight and the medical history of multiple patients.

[0023] Figure 11 A flowchart illustrating an example non-limiting process according to one or more embodiments described herein is provided, which generates an AI-based report to summarize a patient's medical history.

[0024] Figure 12 A flowchart illustrating an example non-limiting method according to one or more embodiments described herein is provided, which detects decision points in a patient's medical course.

[0025] Figure 13 A flowchart illustrating an example non-limiting method according to one or more embodiments described herein is provided, which detects events and outcomes arising from decision points in a patient's medical history.

[0026] Figure 14 A flowchart illustrating an example non-limiting method according to one or more embodiments described herein is provided, which identifies a cohort of a patient's medical history.

[0027] Figure 15 A flowchart illustrating an example non-limiting method according to one or more embodiments described herein is provided, which generates a ranked list of medical practitioners specializing in treating medical conditions and generates additional data corresponding to the respective medical practitioners in the ranked list.

[0028] Figure 16 and Figure 17 A diagram illustrating an example non-limiting UI according to one or more embodiments described herein, which can display a patient's medical history.

[0029] Figure 18 A diagram illustrating an example non-limiting UI according to one or more embodiments described herein, which can display a decision-maker-specific view of a patient's medical course.

[0030] Figure 19An example non-limiting patient timeline diagram is illustrated according to one or more embodiments described herein, which can display a cancer-specific view of a patient's medical history.

[0031] Figure 20 A diagram illustrating an example non-restricted queue analysis visualization representation according to one or more embodiments described herein is provided.

[0032] Figure 21 An example of an unrestricted patient timeline diagram is shown, which can display various aspects of a patient's medical history.

[0033] Figure 22 A flowchart illustrating an example non-limiting method according to one or more embodiments described herein is provided, which can present a decision-maker-specific visualization of a patient’s medical history and generate alternative treatment plans that can be used for subsequent treatment of the disease.

[0034] Figure 23 A flowchart illustrating an example non-limiting method according to one or more embodiments described herein is provided, which may employ software and AI to present decision-maker-specific visualizations of a patient’s medical history and generate alternative treatment plans that can be used for subsequent treatment of the disease.

[0035] Figure 24 A block diagram illustrating an example non-limiting operating environment in which one or more embodiments described herein may be facilitated.

[0036] Figure 25 Example networking environments are illustrated that can operate to perform the various specific implementations described herein. Detailed Implementation

[0037] The following specific embodiments are merely illustrative and are not intended to limit the implementation and / or application or use of the embodiments. Furthermore, they are not intended to be construed as being bound by any express or implied information presented in the foregoing "Background Art" or "Summary of the Invention" or "Detailed Description" sections.

[0038] One or more embodiments will now be described with reference to the accompanying drawings, wherein the same reference numerals are used to denote the same elements throughout. In the following description, numerous specific details are set forth for purposes of explanation in order to provide a more thorough understanding of the one or more embodiments. However, it will be apparent, in various cases, that one or more embodiments may be practiced without these specific details.

[0039] In medical practice, physicians often face dilemmas due to the equivalence of treatment options. For example, a physician may try multiple solutions for a patient, but even when solutions appear equivalent, each may produce different results. That is, treatment options may be equivalent in terms of eligibility, but they are often not equivalent in terms of outcomes. Furthermore, medical practitioners often expect to know about the treatment options used by other medical practitioners. For example, a primary physician may want to know whether a secondary physician used specific drugs, radiation therapy, etc., to treat the patient, and which of the treatment options used by the secondary physician yielded the best results, and so on. For instance, a primary oncologist may benefit from knowing whether a secondary oncologist used popular drugs for cancer treatment, or whether the secondary oncologist used a treatment procedure that the primary oncologist could replicate at different institutions. Similarly, hospital medical practitioners may want to know the results of treatment plans used by another medical practitioner in the same facility. For example, a doctor may begin practice at a different hospital and introduce new drugs into the prescription set, or a new surgeon may join the hospital and introduce new solutions in their practice, and other medical practitioners may want to know how they can utilize the new drugs or new solutions.

[0040] Information typically develops very rapidly, and new data is constantly being generated in the medical field. For example, in oncology, new cancers are frequently discovered, or new updates to cancer guidance become available. However, local physicians often do not have easy access to this information to make informed clinical decisions for their patients. In fact, due to a lack of information, physicians may choose the wrong treatment for their patients up to one-third of the time. As a result, patients frequently seek second opinions. Some existing solutions to the problems discussed in this article include outcome tracking solutions for cancer that analyze clinical outcomes and explore potential future clinical trials to aid in clinical decision-making. However, such solutions typically do not involve learning from past data (such as past clinical decisions, the outcomes of past clinical decisions, etc.) or access to third-party recommendations. Therefore, solutions that provide healthcare practitioners with access to the latest information may be expected to assist them in making better decisions.

[0041] Various embodiments of this disclosure can be implemented to produce solutions to these problems. The embodiments described herein include systems, computer-implemented methods, and computer program products that can provide generative AI-based solutions and interactive UIs for evaluating treatment options for patients. For example, in one or more embodiments, techniques are provided for generating a patient timeline (i.e., a patient timeline) that can display several decision-making-specific events in a patient's medical history. In some embodiments, this may be referred to as a longitudinal patient timeline.

[0042] For example, decision-maker-specific events may include imaging scans, the discovery of suspicious masses, biopsies for further investigation of suspicious masses, etc. The implementation described herein can also generate additional data, such as reports of biopsy events, which can be digitally appended to the biopsy events on the patient's timeline. The patient timeline and additional data can be displayed by the system via a display component on a UI within existing software tools on a device (e.g., desktop computer, laptop computer, tablet, smartphone, etc.). Using the UI, physicians can traverse the patient timeline to study the patient's medical journey over time. Specifically, the implementation described herein allows physicians / clinicians / healthcare workers to explore their past decision-making to consider how they can continuously improve and learn from various situations to achieve optimal healthcare for patients and diseases. Existing software tools can be those capable of generating generic / default patient timelines that are not disease-specific and cannot generate additional data types that AI models can generate. Therefore, the implementation described herein makes existing software tools more valuable to both decision-makers and patients. Additionally, the generated data can be presented on the UI in a highly visual manner by display components, for example, through colored, patterned, and / or otherwise emphasized shapes (such as dashed rectangles, glitter, etc.) to distinguish data points, results, and other types of information. Display components can also outline relevant segments of the patient's timeline, showing views from the first to the second most important clinical decisions in the patient's medical history, illustrating visual connections between points representing significant clinical decisions on the patient's timeline, and presenting additional visual cues to aid in clinical decision-making.

[0043] In one or more implementations, the system can generate disease-specific patient timelines by accessing information from a larger dataset via a data access component and developing a more focused view. For example, a cancer patient's medical history may include events related to immunology, oncology interventions, cardiology visits, regular checkups, diabetes monitoring visits with an endocrinologist, outpatient visits, etc., of which only some events may be relevant to the patient's cancer-specific medical history. In one or more implementations, the system can identify oncology interventions or oncology-related events within a larger dataset to generate a patient timeline that can display the patient's cancer-specific medical history and specific decisions made by decision-makers.

[0044] In one or more embodiments, the implementations described herein can generate alternative treatment plans for cancer patients via a data generation component based on the patient's specific cancer medical history and other factors discussed herein. For example, the data generation component can identify the optimal next steps in a cancer patient's cancer treatment. For instance, the data generation component can evaluate five potential treatment options incorporating the cancer patient's personal preferences and select the first two or three as the optimal treatment options for the cancer patient. In one or more embodiments, the data generation component can present alternative treatment options in a non-invasive manner. For example, during practice, physicians frequently interact with a large amount of dynamic information (e.g., information related to oncology, cardiology, internal medicine, and other multidisciplinary situations), such as inputs, outputs, and updates. Therefore, instead of suggesting alternative treatment plans that intrude into the physician's routine practice, the data generation component can present data-driven solutions that the physician can use to determine the patient's subsequent treatment. For example, data generation components can identify potential follow-up steps in patient treatment, clinicians who can provide specialized services within the hospital, and the allocation of specific types of medications or surgeries. This data can help physicians determine whether clinical decisions will produce outcomes that fall within or deviate from a set of expected outcomes, which may correspond to a cohort of patients whose medical conditions follow a predictable trajectory. If the outcomes produced by clinical decisions begin to deviate from this set of expected outcomes, physicians can conclude that the disease has become heterogeneous or has changed form, and can adjust the treatment process accordingly. For example, physicians can review treatments implemented by other clinicians to determine the best course of action.

[0045] In one or more implementations, the embodiments described herein can also generate second opinions (e.g., a second opinion view on a UI) within existing software tools via a data generation component to assist oncologists in identifying optimal treatment solutions specific to cancer patients. These second opinions can be applied to current and past clinical decisions associated with treatment planning to help decision-makers learn from their past clinical decisions.

[0046] The implementation described in this paper illustrates data density-related visualizations that allow human users to more clearly see and understand patient journeys, medical decisions made, adherence to treatment plans (e.g., whether treatment plans are followed), and to review medical decisions and their outcomes. The implementation also provides automatic spatial and temporal scaling based on patient status (e.g., pre-treatment, active treatment, survival). In one or more implementations, data filtering and interaction with the data can be performed via innovative algorithms and technologies for decision-making and potential recommendations.

[0047] In one or more implementations, the data generation component may employ artificial intelligence, including neural networks, machine learning, generative AI, or other data science techniques, to provide relevant and accurate data, scores, predictions, etc., that can assist oncologists in producing desired outcomes in patients, rather than allowing the disease to guide the patient's treatment course toward outcomes that cannot be accurately predicted. In some cases, two patients may have the same type of cancer, but one patient may also have diabetes, while the other may have heart disease. Therefore, the outcomes of cancer treatment for the two patients may differ due to each patient's unique attributes, treatment profiles, etc. In such cases, the data generation component may tailor treatment for each patient based on historical data (e.g., solutions used for patients with diabetes versus those with heart disease), obesity, age, race, frailty, and other patient-specific factors. Additionally, the data generation component may consider these factors when comparing past clinical decisions made for a patient with clinical decisions made for other patients with similar characteristics.

[0048] Physicians often make clinical decisions based on data from a cluster of patients rather than the experience of a single patient. For example, neurofibromatosis type 1 (NF-1) is a complex and highly variable disease, making it difficult to draw conclusions from the experience of a single patient. In one or more implementations, the system can identify cohorts of patients' medical histories via a data generation component, thereby providing physicians with contextual information about past treatment plans implemented for other patients. For example, based on a patient's medical background, the data generation component can identify cohorts of patients' medical histories to ensure the cohorts are relevant to the patient. For example, the data generation component can record patient outcome metrics, experience, toxicity, etc., access guidance applicable to literature data, employ generative AI to extract the correct contextual elements from the literature data, and identify a group of patients with medical histories similar to the patient's. The medical histories of patients in this group can assist physicians in decision-making. For example, the cohort can inform physicians of past guidance or second opinions recommended by other physicians, the source of the second opinion, guidance regarding previous cohort outcomes (e.g., favorable outcomes in 60% of patients receiving a treatment plan), improvements in outcome metrics (such as progression-free survival), etc.

[0049] In one or more implementations, the reporting component can generate a visual report by arranging, normalizing, and streamlining the overall information available to the cancer patient, where the report can summarize the cancer patient's medical history, learning content from past data, and other relevant data. The summaries included in the report can save cancer patients' oncologists valuable time by efficiently presenting information that oncologists would otherwise need to read through numerous reports for learning. In one or more implementations, such reports can be presented in a longitudinal patient timeline view.

[0050] In summary, the embodiments of this disclosure can generate specific views of a patient timeline (including disease-specific views and decision-maker-specific views) that include events from a patient's medical history, employ AI to present various analyses based on the disease-specific views, and provide graphical updates on the patient timeline to assist decision-makers in exploring alternative clinical pathways for past and future implementation.

[0051] Furthermore, embodiments of this disclosure can provide commercial and economic benefits to organizations by offering improved diagnostics, providing more accurate information to healthcare practitioners, and generating higher sales through improved use and visual statistics for decision-makers (e.g., physicians, surgeons, and / or other end-user entities). In one or more embodiments, the techniques described herein can provide decision-makers with a useful and interactive user interface that helps them review past clinical decisions, learn from comparable data and overlays, and potentially make continuously optimal clinical decisions. Such embodiments can also save patients time and money because the system can overlay second opinions and other helpful decision-making information on the patient's timeline, thus reducing the need for second opinions regarding treatment. The techniques described in the various embodiments can be powerful tools for improving patient clinical outcomes and reducing costs resulting from poor clinical decisions for both patients and healthcare facilities. It should be understood that although the examples discussed throughout this specification focus on oncology, embodiments of this disclosure can be applied to a wide range of types of medical decision-making and to other fields such as cardiology, neurology, pulmonology, orthopedic surgery, etc.

[0052] For the sake of simplicity, the computer-implemented and non-computer-implemented methods provided herein are depicted and / or described as a series of actions. It should be understood that the invention is not limited to the illustrated actions and / or the order of actions; for example, actions may occur in one or more sequences and / or simultaneously, and may include other actions not presented and described herein. Furthermore, it is possible that not all illustrated actions are utilized to implement the computer-implemented and non-computer-implemented methods according to the described subject matter. Additionally, the computer-implemented methods described below and throughout the specification can be stored on an article of writing to enable the transfer and transfer of the computer-implemented methods to a computer. As used herein, the term "article of writing" is intended to cover a computer program that can be accessed from any computer-readable device or storage medium and executed by a computer processing unit.

[0053] This document has (and / or will further describe) systems and / or devices relating to interactions between one or more components. Such systems and components may include one or more of those components or sub-components specified herein, the specified components and / or sub-components, and / or additional components. Sub-components may be implemented as components communicatively coupled to other components rather than being included within a parent component. One or more components and / or sub-components may be combined into a single component that provides aggregate functionality. Components may interact with one or more other components that are not specifically described herein for the sake of brevity but are known to those skilled in the art.

[0054] The embodiments depicted in one or more of the accompanying drawings described herein are for illustrative purposes only, and therefore, the architecture of the embodiments is not limited to the systems, devices, and / or components depicted herein, nor is it limited to any particular order, connection, and / or coupling of the systems, devices, and / or components depicted herein. For example, in one or more embodiments, the non-limiting systems described herein (such as...) Figure 2A The illustrated non-limiting system 200) and / or its system may also include, be associated with and / or coupled to the operating environment referenced herein (such as... Figure 24 The illustrated operating environment 2400 describes one or more computer- and / or computing-based elements. For example, the non-limiting system 200 may be related to the following reference. Figure 24 The described computing environment 2400 is associated with (e.g., accessible via this computing environment) such that aspects of processing can be distributed between the non-limiting system 200 and the computing environment 2400. In one or more of the described embodiments, computer-based and / or computing elements may be incorporated into the implementation described herein. Figure 2A Used in combination with one or more of the operations implemented by the systems, devices, components and / or computers shown and / or described in the accompanying drawings and / or other figures.

[0055] Figures 1A to 1E This is intended to describe the technical background applicable to one or more embodiments of this disclosure. In this respect, at least... Figures 1A to 1C Systems and methods that can correspond to existing software tools and UI 300 referenced in paragraph

[0042] are described. Additionally, one or more systems and methods disclosed herein can be used in conjunction with references to... Figures 1A to 1E The described systems and methods interact to achieve the decision-maker-specific view described in various implementation schemes.

[0056] Figure 1A A diagram illustrating an example non-limiting system 100 according to one or more embodiments described herein, the system being used for patient history analysis and timeline segmentation using an EHR display system.

[0057] Figure 1AA system (100) for patient history analysis and timeline segmentation using an EHR display system is illustrated. According to one aspect of this disclosure, the system (100) may include a display (101) configured to display a patient's EHR (102). The patient's EHR may be stored in the memory of a computer system (107) or server, or in any other electronic format known in the art or developed in the future. The computer system may be connected to a start-end marker detection module (106). The start-end marker detection module (106) may be configured to identify the start and end of a specific action or event associated with the patient, and to mark the start and end boundaries of that action or event. In a non-limiting example, the starting event or action may be patient admission for diagnosis. Additionally, the patient may have undergone magnetic resonance imaging (MRI) of a cranial region. If no tumor is seen in the initial MR image, the patient may be discharged at a later time point. This marks the end of the imaging action and the patient's discharge. Such past scan information of the patient may be timestamped and stored in computer memory or any other suitable electronic storage medium. The start-end marker detection module (106) can be configured to access scan information from an electronic storage medium. Based on the information stored on the electronic storage medium, the start-end marker detection module (106) can also be configured to identify a scan timeline including the patient's admission date, examination duration, and display the discharge date for patients with the primary conclusion that no tumor was initially detected. The start-end marker detection module (106) can be configured to identify all such actions or events associated with the patient throughout the entire duration of treatment. In one aspect of this disclosure, the start-end marker detection module (106) can be configured to read text information stored in the electronic storage medium and convert that information into a user-visible view.

[0058] The system (100) also includes a segment start-end detection module (103). The segment start-end detection module (103) can be configured to segment various actions or events identified by the start-end marker detection module (106). Segmenting the actions or events identified by the start-end marker detection module (106) includes identifying timeline boundaries of the actions or events and arranging the segmented actions or events according to the timeline of the actions or events. In a non-limiting example, the patient may have received treatment for various unrelated medical conditions, such as brain tumor, chest infection, spinal dislocation, and cirrhosis. According to one aspect of this disclosure, the segment start-end detection module (103) can be configured to segment all actions taken for these medical conditions and indicate the corresponding drug treatments provided for them. The segment start-end detection module (103) associates the medical conditions with various other parameters, including, for example, the timeline of the medical condition and the drug treatments provided for the medical condition. The segment start-end detection module (103) also creates a visual graph showing the timeline of drug treatment and overlaps within the treatment timeline. However, if specific data related to the end of a treatment timeline is unavailable, or if there are interruptions and restarts during treatment, the boundaries of the graph used for such treatment become uncertain and may be mixed with other graphs. The system may also include a segment sorting / grading module (104). The segment sorting / grading module (104) can be configured to arrange segments in chronological order. Gap or uncertain boundaries between segments need to be identified in order to sort the segments in chronological order.

[0059] The gap processing module (105) can be connected to the grading module to identify and mitigate gaps between two segments along the timeline wherever timeline data is available. Furthermore, clinicians can be given the option to manually populate the data and update the timeline based on available medical records. This minimizes timeline gaps and provides a more accurate picture to users viewing the patient's timeline. The segmented segments can be transmitted to a display (101) by the segment sorting / grading module (104) for displaying a timeline sequence of actions or events relevant to the patient.

[0060] Figure 1B A figure illustrating an example non-limiting method 120 according to one or more embodiments described herein is provided for timeline segmentation and display of a patient's EHR on a display device.

[0061] Figure 1BA method (120) for timeline segmentation of patient medical history analysis and EHR, and for displaying the segmented health record of a patient on a display device, is illustrated. The method (120) includes acquiring (122) a patient's health record over a period of time and storing these records for future recording. The health records may be EHRs or physical health records, which may be manually entered into the EHR system. Although a single patient is referenced, it will be apparent to those skilled in the art that the health records of many such patients may be acquired and stored simultaneously. A patient's EHR may be stored in the memory of a computer system (not shown) or a server, or in any other electronic format known in the art or developed in the future. The method (120) also includes identifying (124) the start and end of a specific action or event associated with the patient, and marking the start and end boundaries of that action or event. Identifying (124) the start and end of a specific action or event may be performed using a start-end marker detection module (106). Various treatments for a patient may begin at different times and continue for a specific duration before the treatment ends. Treatment processes may include medication, consultations, scans, therapies, hospital admissions, blood and other tests, discharge, and post-discharge medication. The start-end marker detection module (106) can be configured to access scan information from an electronic storage medium. Based on the information stored on the electronic storage medium, the start-end marker detection module (106) can also be configured to identify a scan timeline including the patient's admission date and examination duration, and to display the patient's discharge date with a major outcome or conclusion (e.g., no serious disease was initially detected). The start-end marker detection module (106) can be configured to identify all such actions or events associated with the patient throughout the entire duration of treatment.

[0062] The method (120) also includes segmenting (126) various actions or events, including identifying timeline boundaries of the actions or events. Segmenting (126) various actions or events can be performed using a segment start-end detection module (103). The segment start-end detection module (103) can be configured to segment various actions or events identified by the start-end marker detection module (106). Segmenting the actions or events identified by the start-end marker detection module (106) by the segment start-end detection module (103) includes identifying timeline boundaries of the actions or events. In a non-limiting example, the patient may have received treatment for various unrelated medical conditions, such as a brain tumor, chest infection, spinal dislocation, and cirrhosis. According to one aspect of this disclosure, segmentation (126) using the segment start-end detection module (103) can be performed to segment all the different actions taken for these medical conditions and to show the corresponding drug treatment provided for each medical condition. The segment start-end detection module (103) associates the medical condition with various other parameters, including, for example, the timeline of the medical condition and the medication provided for the medical condition. If the end time of an action or event cannot be correctly identified, fuzzy boundaries may occur. Fuzzy boundaries are where two segments overlap (e.g., ...). Figure 1C (As shown) and it is impossible to divide into segments. If specific data related to the end of an action or event timeline is unavailable, or if there are interruptions and restarts during treatment, the boundaries of the graph used for such treatment become indeterminate and may be mixed with other graphs.

[0063] Method (120) further includes delimiting (128) segment boundaries and arranging the segments in chronological order. Delimiting (128) segment boundaries includes separating the segments from each other and creating identifiable boundaries. Arranging the segments in chronological order includes identifying sequences of various actions or events related to the patient and arranging the sequences of actions or events along a timeline. According to one aspect of this disclosure, a segment sorting / grading module (104) may be provided. The segment sorting / grading module (104) may be configured to arrange the segments in chronological order along clearly defined boundaries. Arranging the segments in a sequential or chronological order creates a time series of actions or events related to the patient. Arranging the segments in chronological order (128) may also include generating a visual map showing the timeline of actions or events and overlaps in the action timeline.

[0064] The method (120) also includes displaying (130) a visual diagram showing a segmented timeline of actions or events that constitute the boundaries of the divisions of actions or events contained in the timeline. The segmented segments can be transmitted by a segment sorting / grading module (104) to a display device (101) for displaying a timeline sequence of patient-related actions or events. The display (101) can be configured to display a timeline sequence of patient-related actions or events, along with clinically significant actions from each segment of the timeline. The display (130) can include displaying action or event segments in various user-friendly display formats, such as bars indicating the start and end of a specific treatment. When different treatments are administered simultaneously, the display will show two distinct segmentation bars with overlapping portions on the timeline. The method (120) can be used... Figure 1C Let's use an example to explain.

[0065] Figure 1C A figure illustrating an example non-limiting method 140 according to one or more embodiments described herein, for timeline segmentation and display of a patient's EHR on a display device.

[0066] According to one aspect of this disclosure, Figure 1C An example method (140) for timeline segmentation and displaying a patient's EHR on a display device is shown. According to one aspect of this disclosure, the method (140) may include a display (not shown) configured to display the patient's EHR (141). The patient's EHR (141) may be stored in the memory of a computer system (not shown) or a server or in any other electronic format known in the art or developed in the future.

[0067] The computer system can be connected to the start-end marker detection module (142). The start-end marker detection module (142) can be configured to identify the start and end of a specific action or event related to the patient, and to mark the start and end boundaries of that action or event. Various color schemes and shapes can be used to represent the type of disease, the treatment provided, and the duration of the patient's illness.

[0068] In a non-limiting example, the initiating event or action could be a patient's admission for diagnosis. A color-coded marker sequence corresponding to various EHRs can be generated by the start-end marker detection module. Additionally, the patient may have undergone magnetic resonance imaging (MRI) of the skull region. If no tumor is seen in the initial image, the patient can be discharged at a later time point. This marks the end of the imaging action and the patient's discharge. This past scan information of the patient can be timestamped and stored in computer memory or any other suitable electronic storage medium. The start-end marker detection module (142) can be configured to access scan information from the electronic storage medium. Based on the information stored on the electronic storage medium, the start-end marker detection module (142) can also be configured to identify a scan timeline including the patient's admission date, the duration of the examination, and display the patient's discharge date with the primary conclusion that no tumor was initially detected. The start-end marker detection module (142) can be configured to identify all such actions or events associated with the patient throughout the entire duration of treatment. In one aspect of this disclosure, the start-end marker detection module (142) can be configured to read text information stored in an electronic storage medium and convert that information into a user-visible view.

[0069] The computer system also includes a segment start-end detection module (146). The segment start-end detection module (146) can be configured to segment various actions or events identified by the start-end marker detection module (142). Segmenting the actions or events identified by the start-end marker detection module (142) includes identifying the timeline boundaries of the actions or events and arranging the segmented actions or events according to the timeline of the actions or events. In a non-limiting example, the patient may have received treatment for various unrelated medical conditions, such as brain tumor, chest infection, spinal dislocation, and cirrhosis. The segment start-end detection module (146) can be configured to segment all actions taken for these medical conditions and show the corresponding drug treatments provided for them. The segment start-end detection module (146) can generate segments (143, 145, 144, 147, 148) with fuzzy boundaries. Although only five segments (143, 145, 144, 147, 148) are shown in this example, it is understood that more or fewer segments may exist. The segment start-end detection module (146) associates the medical condition with various other parameters, including, for example, the timeline of the medical condition and the drug treatment provided for the medical condition. The segment start-end detection module (146) also creates a visual graph showing the timeline of drug treatment and the overlaps in the treatment timeline. However, if specific data related to the end of the treatment timeline is unavailable, or if there is an interruption and restart in the treatment, the boundaries of the graph used for such treatment become uncertain and may be mixed with other graphs. The system may also include a segment sorting / grading module (151). The segment sorting / grading module (151) can be configured to sort the segments (149, 150, 152, 153, 154) in chronological order. The segment sorting / grading module (151) can be connected to the gap processing module (105) to generate clearly defined boundaries. The segmented segments (149, 150, 152, 153, 154) can be transmitted by the grading module (151) to a display (not shown) for illustrating a timeline sequence of patient-related actions or events. The segment start-end detection module (146) can also be configured to highlight clinically important information associated with each segment. This helps clinicians identify relevant information from each segment over a short period, compared to manually identifying relevant information from different treatments administered over time.

[0070] Figure 1D A diagram illustrating an example non-limiting process 160 according to one or more embodiments described herein, which can be used to utilize Figure 1A A system (or another suitable system) to improve data access and integration for multidisciplinary teams.

[0071] In the context of dedication to cancer treatment and such Figure 1D The process 160 is visually depicted and can be used with NLP to aggregate and analyze patient medical reports from a period of time (e.g., the past few years). Clinical knowledge-based inferences can be applied. Automated organization and periodic summaries can be generated.

[0072] Figure 1E A diagram illustrating an example non-limiting process 170 according to one or more embodiments described herein, the process being used to utilize Figure 1A The system (or another suitable system) is used to generate longitudinal data elements of the patient for display to the user.

[0073] Figure 1E An example overview 170 is provided, illustrating how system 100, or other systems described in the various figures, can be used to generate timelines and associated display elements that may contribute to the provision of patient care. Overview 170 may represent a method for generating the timeline, which can be based on data stored on a computing device (e.g., Figure 1A The system executes instructions from the memory of the system 100. For example... Figure 1E As shown, system 100 can acquire patient data 171, as mentioned above regarding... Figure 1AThe patient data can be in various formats and obtained from different sources. System 100 can perform NLP on the patient data using an NLP module, as shown at point 172. As described above, NLP can include Named Entity Recognition (NER), entity parsing, assertions, code parsing, etc. At point 173, medical ontology inference can be performed on the processed data using a medical knowledge graph. In this way, relevant clinical markers and information in the medical data can be identified and extracted, and then used for downstream display elements / overlays, as explained herein. For example, at point 174, the processed patient data can be used to generate an oncology knowledge overlay based on cancer care guidance, enabling the display of guidance relevant to the current patient status / condition. At point 175, period segmentation can be performed on the processed patient data according to period segmentation rules, and period segmentation can be used to temporally sort and segment events in the patient data for display in a timeline. At point 176, treatment response tracking can be performed on the patient data using response-related elements, and any identified treatment response can be displayed. Response-related elements can include entities specific to treatment responses. For example, for cancer, response elements could include "stable response," "no response," etc., which can be determined based on response assessment criteria specific to a given condition or treatment. This allows clinicians to know whether the treatment has been effective. At point 177, per-report and multi-report summaries can be generated based on relevant / extracted patient data (including treatment response) and summarization rules, and the summaries can be displayed on a timeline. At point 178, patient data can be used to identify similar patients from a patient database, and information about similar patients can be retrieved and used to generate comparative summaries or other information that can be displayed.

[0074] Figure 2A A block diagram of an example non-limiting system 200 according to one or more embodiments described herein is illustrated. This system can employ software and AI to present decision-maker-specific visualizations of a patient’s medical history and generate alternative treatment plans that can be used for subsequent treatment of the disease.

[0075] The unrestricted system 200 and / or components of the unrestricted system 200 can be used with hardware and / or software to solve inherently highly technical problems (e.g., related to medical information processing, generative AI, etc.) that are not abstract concepts and cannot be performed by humans through a series of thought processes. Furthermore, some processes in the execution can be performed by a dedicated computer for implementing defined tasks related to generative AI solutions for evaluating treatment options for patients. The unrestricted system 200 and / or components of the unrestricted system 200 can be used to solve new problems arising from advancements in the aforementioned technologies and / or similar technologies. The unrestricted system 200 can provide technological improvements to medical information processing systems by increasing the accuracy and efficiency of processing and analyzing clinical data and generating alternative treatment plans based on that analysis. The unrestricted system 200 can provide additional improvements by reducing the financial costs to patients and healthcare facilities resulting from incorrect clinical decisions made by healthcare practitioners.

[0076] Figure 2A Further illustrations include system 202, processor 204, memory 206, bus 208, AI model 210, first data 212, second data 214, queue 216, third data 218, ranking list 220, visualization 222, and AI-based report 224. System 202 may include processor 204 (e.g., computer processing unit, microprocessor, classical processor, and / or similar processor). In one or more embodiments, as described herein with or without reference to one or more accompanying drawings of one or more embodiments, components associated with system 202 may include one or more computer and / or machine-readable, writable, and / or executable components and / or instructions that can be executed by processor 204 to enable the execution of one or more processes defined by such components and / or instructions.

[0077] In one or more embodiments, system 202 may include a computer-readable storage device (e.g., memory 206) operatively connected to processor 204. Memory 206 may store computer-executable instructions that, when executed by processor 204, cause processor 204 and / or one or more other components of system 202 (e.g., artificial intelligence (AI) model 210, data access component 232, data generation component 234, display component 236, first artificial intelligence (AI) component 238, second artificial intelligence (AI) component 240, planning search component 242, detection component 244, evaluation component 246, merging component 248, selection component 250, prompt generation component 252, reporting component 254, and training component 256) to perform one or more actions. In one or more embodiments, memory 206 may store computer-executable components (e.g., AI model 210, data access component 232, data generation component 234, display component 236, first AI component 238, second AI component 240, plan search component 242, detection component 244, evaluation component 246, merging component 248, selection component 250, prompt generation component 252, report component 254, and training component 256). In one or more embodiments, one or more components of system 202 may reside in the cloud and / or may reside locally in a local computing environment (e.g., at a designated location).

[0078] The non-limiting system 200 and / or its components described herein may be communicatively coupled, electrically coupled, operatively coupled, optically coupled, and / or otherwise coupled to each other via bus 208. Bus 208 may include one or more buses of another type, such as a memory bus, memory controller, peripheral bus, external bus, local bus, and / or one or more buses employing one or more bus architectures. One or more of these examples of bus 208 may be employed. In one or more embodiments, the non-limiting system 200 may be coupled, such as via a network (e.g., communicatively coupled, electrically coupled, operatively coupled, optically coupled, and / or coupled via similar functions) to one or more external systems (e.g., an electrical output generating system not illustrated, one or more output targets, output target controllers, and / or similar systems), sources, and / or devices (e.g., classical computing devices, communication devices, and / or similar devices).

[0079] In one or more embodiments, system 202 may include AI model 210. In one or more embodiments, AI model 210 may include data access component 232, data generation component 234, display component 236, first AI component 238, second AI component 240, planning search component 242, detection component 244, evaluation component 246, merging component 248, selection component 250, prompt generation component 252, reporting component 254, and training component 256, such as... Figure 2B As illustrated. In one or more embodiments, system 202 may also include one or more software programs in memory 206 that can execute a set of algorithms or method steps to generate technical and medical outputs and output them to the UI.

[0080] In one or more implementations, AI model 210 may employ software steps and AI algorithms to present an interactive visualization of a patient's medical history at a UI, and generate alternative treatment plans that can be adopted by end-user entities (e.g., hardware, software, machines, AI, neural networks, and / or users) such as healthcare practitioners (e.g., doctors, surgeons, clinicians, etc.) to treat the patient's medical condition (e.g., disease). The interactive visualization may be time-based, and healthcare practitioners may review past decisions (e.g., review history) via the interactive visualization with further assistance from the decision-maker's view discussed herein.

[0081] In one or more embodiments, data access component 232 may access first data 212 and second data 214, wherein the first data 212 and second data 214 may be stored in memory (e.g., memory 206) accessible to AI model 210. First data 212 may include first patient data associated with a patient, second patient data associated with one or more additional patients, a set of clinical rules, and treatment information related to the patient's medical condition. Second data 214 may include one or more results generated by clinical decisions associated with the medical condition. First data 212 and second data 214 may be input to system 202 by an end entity (e.g., hardware, software, machine, AI, neural network, and / or user) via a device's UI (e.g., computer, laptop, tablet, smartphone, etc.). In one or more embodiments, the UI may include a command-line interface (CLI), a graphical user interface (GUI), a voice user interface (VUI), and / or a touch interface.

[0082] In one or more embodiments, data generation component 234 may analyze first data 212 and second data 214 via specifically coded algorithmic steps in AI, software rule engines, or medical software programs (e.g., source code written by humans or machines). Based on the analysis of first data 212 and second data 214, data generation component 234 may identify one or more cohorts (i.e., cohort 216) of a patient's medical history. Subsequently, based at least on first data 212, second data 214, and cohort 216, data generation component 234 may generate third data 218 via generative AI, which includes at least two alternative treatment plans that can be used for subsequent treatment of the medical condition.

[0083] In one or more embodiments, display component 236 (e.g., display module) can display a patient timeline, including a time view of the patient's medical story, on the UI of a device (e.g., computer, laptop, tablet, smartphone, etc.). This view can have a disease-specific view and a decision-maker-specific view. The view can be a longitudinal patient timeline. Display component 236 can also extend the time view to future dates to display clinical decisions that can be used for the patient's subsequent treatment. Furthermore, display component 236 can display visualizations (i.e., visualizations 222) of the patient's medical story in one or more cohorts (i.e., cohort 216) on the UI. Visualization 222 can be influential in evaluating the at least two alternative treatment plans based on the results of the reference cohorts. Additionally, visualization 222 can be adopted by a medical device to automatically perform actions related to the subsequent treatment of the medical condition based on at least one cohort of the patient's medical story, provided that the at least one cohort meets a defined set of criteria. For example, in one or more embodiments, visualization 222 may be accessed by a medical device (e.g., a medical imaging device or another type of medical device), and the medical device may be programmed by an end entity (e.g., hardware, software, machine, AI, neural network, and / or user) to compare data from visualization 222 with a defined set of criteria (e.g., 90% prediction success rate of a queue, lowest cost option, fastest response time, etc.), and to automatically perform one or more actions if at least one queue included in queue 216 matches the defined set of criteria. For example, the medical device may be programmed to execute instructions to obtain medical images, obtain test results, etc., if one or more queues in queue 216 match the defined set of criteria. Thus, treatment for the patient can continue seamlessly, and some human interventions can be automated and reduced. In one or more embodiments, display component 236 may serve as an interactive module that enables the end entity (e.g., hardware, software, machine, AI, neural network, and / or user) to select options, decision points, drop-down menus, etc., on the UI via a cursor, touchscreen, voice commands, or other suitable functions.

[0084] In one or more embodiments, the first AI component 238 can detect multiple decision points within a time view based on first patient data and treatment information, wherein each decision point can represent a corresponding clinical decision for the patient, and wherein the clinical decision can correspond to a decision point within the time view. In some embodiments, the first AI component 238 can detect these multiple decision points when a healthcare practitioner inputs a treatment plan (e.g., via a UI) into the non-restricted system 200 or specifies a particular treatment to be input into the non-restricted system 200. The treatment plan may include, for example, decisions made by a healthcare practitioner related to a specific treatment action for the patient, wherein the treatment action may include medical examinations, medication, surgery, and other types of treatment actions performed by a healthcare professional.

[0085] The first AI component 238 may employ an AI agent system (or a critical decision moment detection agent system) comprising various agents (e.g., a plan search component 242, a detection component 244, an evaluation component 246, and a merging component 248), wherein different agents may employ different methods to detect the multiple decision points. For example, the plan search component 242 may identify a first set of decision points based on modifications within a treatment plan associated with the patient's medical condition; the detection component 244 may identify a second set of decision points based on inputs associated with treatment decisions included in the treatment plan; and the evaluation component 246 may identify a third set of decision points based on a set of clinical rules, wherein the set of clinical rules may include rules configured to detect defining clinical patterns. Finally, the merging component 248 may generate a list comprising the multiple decision points by merging the first, second, and third sets of decision points. In this respect, the corresponding decision points included in the list may represent critical decision moments or key clinical decisions made by a physician for treating a patient's medical condition, and detecting the corresponding decision points may be important for a decision-maker's view of the patient's timeline as described in one or more embodiments.

[0086] In one or more implementations, the first AI component 238 may also detect one or more of the plurality of decision points based on the corresponding clinical decision as corresponding key moments (also known as insight moments) indicating non-standard insights identified by the first AI component 238.

[0087] In one or more embodiments, the second AI component 240 may detect the one or more outcomes included in the second data 214 by employing a selection component 250, a prompt generation component 252, and a merging component 248. For example, the selection component 250 may select decision points associated with clinical decisions corresponding to the one or more outcomes; the prompt generation component 252 may generate a summary set of prompts to identify a set of events representing the consequences of the clinical decision; the prompt generation component 252 may input the summary set of prompts into a large language model (LLM); and the merging component 248 may analyze the results generated by the LLM in processing the summary set of prompts to detect the one or more outcomes associated with the decision point. The second AI component 240 may detect the corresponding set of outcomes for a given decision point in a similar manner. In one or more embodiments, the display component 236 may, in response to selection, highlight the decision point and the one or more outcomes via a bounding box on the patient timeline. In one or more embodiments, the first AI component 238, the second AI component 240, and the display component 236 may include a decision labeling module that can identify and present prominent points (e.g., data points) on the patient's timeline that represent important clinical decisions or medical treatment plan decisions related to the patient's medical condition.

[0088] Recall that data generation component 234 can identify one or more queues (i.e., queues 216) of a patient's medical history via AI. To identify queue 216, data generation component 234 can aggregate the patient's medical history prior to the decision point, compare the patient's medical history with corresponding medical history of corresponding patients among the one or more additional patients, and select a set of medical history from the corresponding medical history as the one or more queues (i.e., queues 216) of the patient's medical history based on relevant clinical criteria. In this regard, display visualization 222 may include, by display component 236, outputting first results and outcome metrics of different choices of a first treatment plan associated with the corresponding queues in queue 216 on the UI of a device (e.g., a computer, laptop, tablet, smartphone, etc.). In one or more embodiments, display component 236 may also display queue filters that can be used by a physician to specify / input additional details that data generation component 234 may consider when identifying queue 216.

[0089] In one or more embodiments, the data generation component 234 may further generate a ranking list of healthcare practitioners (i.e., ranking list 220) based on the first patient data and treatment information, wherein the ranking list 220 may be adopted by an end entity (e.g., hardware, software, machine, AI, neural network and / or user) to explore a second treatment plan used by the healthcare practitioner to treat the medical condition, explore a second outcome associated with the second treatment plan, and contact the healthcare practitioner.

[0090] In one or more embodiments, the reporting component 254 may generate an AI-based report 224 based on outcomes associated with corresponding clinical decisions and recommendations for subsequent treatment of the medical condition. This AI-based report includes interpretations of the information learned by the data generation component 234. In one or more embodiments, the display component 236 may highlight the results via visual indicators and scores displayed on the patient's timeline on the UI.

[0091] In one or more implementations, the training component 256 can train the data generation component 234 to iteratively analyze the first data 212 and the second data 214 to obtain new information, and based on the new information to identify new cohorts most relevant to the patient’s medical history at a given point in time.

[0092] The functionality of the components included in AI model 210 is described in more detail with reference to the following examples given at least in paragraphs

[0094] to

[00117] . It should be understood that, in addition to the data analysis and AI-based implementations described in this disclosure, the decision-maker views described in the various implementations of this disclosure can assist decision-makers (e.g., physicians, surgeons, nurses, etc.) in making clinical decisions for treating patients, and provide decision-makers with opportunities to learn from past clinical decisions (e.g., through comparisons of treatment plans by different specialists, medical histories of patients with similar treatment histories, moments of insight, etc.). In this regard, the following examples may refer to… Figures 1A to 1E All aspects described.

[0093] Example:

[0094] In one implementation, patient A may be a cancer patient treated by oncologist A. The first patient data included in the first data 212 may include information such as patient A's age, sex, race, medical history, and other relevant details. The second patient data included in the first data 212 may include the age, sex, race, medical history, and other relevant details of one or more additional patients, for example, patients within the same medical facility (e.g., a hospital, cancer institute, etc.) responsible for treating patient A. The treatment information included in the first data 212 may include details of a treatment plan developed by oncologist A for patient A. The set of clinical rules included in the first data 212 may include rules configured by the medical facility to detect defined clinical patterns in patients.

[0095] In one implementation, data access component 232 can access first patient data and treatment information related to patient A, and based on this, display component 236 can display an initial patient timeline (e.g., Figure 5The initial patient timeline 500 includes a time view of patient A's medical history and a treatment plan developed by oncologist A. The initial patient timeline can extend from a specific point in the past (e.g., a specific date) to a future point in time (e.g., a specific date). The initial patient timeline can be displayed on the UI of an accessible device of oncologist A (e.g., a computer, laptop, tablet, smartphone, etc.). Additionally, the initial patient timeline can be displayed along with an interactive toggle switch, allowing an end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user) to activate the toggle switch to generate a disease-specific view. For example, oncologist A can activate the toggle switch by selecting it via a cursor, touchscreen, or other suitable function. Therefore, display component 236 can display a patient timeline with a cancer-specific view showing only the cancer-specific medical history corresponding to patient A (e.g., Figure 5 A non-restricted patient timeline (510). For example, patient A may also have diabetes, and the initial patient timeline may show events related to patient A's diabetes treatment and cancer treatment, such as laboratory tests, biomarkers, etc., while a patient timeline with a cancer-specific view may show events only related to patient A's cancer treatment, such as laboratory tests, imaging data, biomarkers, etc. Furthermore, each event on the initial patient timeline and the patient timeline including the cancer-specific view may be displayed as a point (e.g., a data point), and different events may be highlighted using different colors and / or visual indicators. For example, in the initial patient timeline, events in the same category may be displayed with the same color, and events in different categories may be displayed with different colors.

[0096] In one or more implementations, the first AI component 238 may employ a plan search component 242, a detection component 244, an evaluation component 246, and a merging component 248 to detect multiple decision points on the patient's timeline. Recall that corresponding decision points on the patient's timeline can represent corresponding critical decision moments. To detect decision points (i.e., critical decision moments), the plan search component 242 (e.g., agent 1) can access and read medical notes for patient A stored in memory (e.g., memory 206) and identify when oncologist A planned treatment for patient A. Each plan identified or modified in the treatment plan developed by oncologist A for patient A can represent a critical decision moment. Furthermore, the detection component 244 (e.g., agent 2) can apply a trained model that can identify critical decision moments. The trained model can be trained (e.g., by training component 256) on physician-annotated data to identify events representing critical decision moments based on physician identification. For example, in one implementation, each line of treatment and dosage or adjustment based on tolerability or comorbidities can be a clinical decision made by a physician, and key decision moments can be inputs used to make those decisions. In one or more implementations, detection component 244 can be a decision moment detection model based on deep learning (DL). Evaluation component 246 (e.g., agent 3) can be a rule-based model that monitors the patient timeline according to a set of clinical rules, which can include a set of rules configured by the hospital / physician that can detect well-defined patterns. For example, evaluation component 246 can be configured to alert oncologist A if patient A experiences a weight loss greater than 5 percent (5%). Finally, merging component 248 can access / collect key decision moments detected by the agents (i.e., planning search component 242, detection component 244, and evaluation component 246), merge the key decision moments, and return a list including decision points.

[0097] In one or more embodiments, the first AI component 238 may also detect one or more of the plurality of decision points as moments of insight. A moment of insight represents a critical moment when a non-standard insight is identified by an end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user). For example, a moment of insight could be a moment when a physician suddenly understands or recognizes a piece of information, comes up with a good idea, or finds the answer to a question. In one embodiment, the first AI component 238 may detect decision points and determine that a decision point represents a moment of insight. In another embodiment, oncologist A or another caregiver of patient A may determine that a decision point represents a moment of insight while reviewing the patient's timeline, and oncologist A or the other caregiver may indicate to the first AI component 238 that the decision point represents a moment of insight by selecting a button / option on the UI via a cursor, touchscreen, or other suitable function. Software capable of identifying moments of insight may typically include user behavior analysis tools, such as Mixpanel. ® Fullstory ® Highlight, Pendo ® ClickUp ® and UserGuiding ® This allows end-user entities (e.g., hardware, software, machines, AI, neural networks, and / or users) to track user interactions within a product to identify specific actions or features that trigger sudden understanding or realization of value, where such actions or features can be considered moments of insight for the end-user entity. Key features of such software tools that can identify moments of insight include:

[0098] User Session Logs: Watch video replays of user sessions to see exactly how users navigate and interact with the company's products.

[0099] Event tracking: Monitor specific user actions, such as button clicks, form submissions, or feature usage, to identify patterns associated with moments of insight.

[0100] Heatmaps: Visualize where users click or hover on the interface to understand areas of interest and potential insight triggers.

[0101] Funnels and queues: Analyze user flow to identify drop-off points and where users might be experiencing moments of epiphany.

[0102] In-app surveys and feedback mechanisms: Gather direct feedback from users about their experience to understand when and how they perceive value.

[0103] Additional techniques for detecting moments of insight may include:

[0104] Establish tracking of key actions: Identify potential moments of insight in the product and track user interactions associated with them.

[0105] Analyze user behavior patterns: Look for patterns in user data that indicate a significant shift in engagement or understanding, thus hinting at moments of insight.

[0106] Segmenting users: Analyzing data based on different user demographics or behaviors to understand whether moments of insight vary across different user types.

[0107] Iterate and refine user data: Use insights from user data to optimize product onboarding processes and user experience to more effectively guide users toward their moments of epiphany.

[0108] In one or more implementations, the first AI component 238 may employ one or more of these features to detect the one or more decision points as moments of insight that can be marked on a navigator on the patient's timeline.

[0109] In one or more embodiments, data access component 232 may further access second data 214 including one or more outcomes arising from clinical decisions, wherein the clinical decisions may correspond to decision points detected by first AI component 238 within a time view of the patient's timeline. For example, a decision point may be a past decision made by oncologist A to administer medication to patient A, and the one or more outcomes may represent the consequences of the medication on patient A. In one or more embodiments, second AI component 240 may detect the one or more outcomes included in the second data 214 by employing selection component 250, prompt generation component 252, and merging component 248. For example, selection component 250 may select decision points. Based on the decision points, prompt generation component 252 may develop summary prompts describing a list or summary of events originating from the decision points. For example, the prompt generation component 252 can develop a first prompt for summarizing based on decision points, a second prompt for selecting events (i.e., corresponding clinical decisions) as consequences of decision points, a third prompt for summarizing the potential consequences of different / alternative clinical decisions, a fourth prompt for selecting events or data points (e.g., surgery, medication, diet, etc.) and summarizing the causes and / or clinical decisions responsible for the events, a fifth prompt for response tracking to help create critical decision moments, and additional prompts including additional questions.

[0110] Response tracking refers to the process of monitoring, storing, and analyzing responses generated by systems such as LLMs and AI models. For example, an LLM detecting toxicity could be a negative response, an LLM detecting efficacy could be a positive response, and so on. Input parameters for the response can include clinical, biochemical, and radiological response parameters. The prompt generation component 252 can combine these details to generate a fifth prompt. Additionally, the prompt generation component 252 can employ Retrieval Enhanced Generation (RAG) to develop second and additional prompts. RAG combines a retrieval mechanism with a generative model, allowing the generative model to use relevant information from an external knowledge base to generate responses.

[0111] In one or more embodiments, data generation component 234 may analyze first data 212 and second data 214 via generative AI. Based on the analysis of first data 212 and second data 214, data generation component 234 may identify queue 216 via generative AI, wherein queue 216 may include one or more queues of patient A's medical history. For example, data generation component 234 may include an algorithm that can identify patients with the same medical condition as patient A within the same institution (e.g., hospital, cancer institute, etc.) responsible for treating patient A. In embodiments, data generation component 234 may employ existing queueing algorithms and / or systems. In another embodiment, data generation component 234 may employ a decision-making-based algorithm (i.e., a decision-making algorithm). For example, an end entity (e.g., hardware, software, machine, AI, neural network, and / or user) may select a decision point on a UI via a cursor, touchscreen, or other suitable function. For example, oncologist A may select a decision point for patient A.

[0112] Based on this selection, the decision-making algorithm can aggregate the medical history of patient A up to the decision point, and for each patient in the institution, the decision-making algorithm can (e.g., from the second patient data included in the first data 212) detect the decision moment most similar to the decision point selected for patient A (if such a decision moment exists) (e.g., the most similar decision moment). When the most similar decision moment for a patient (e.g., patient B) is detected, the decision-making algorithm can aggregate the medical history of patient B up to the most similar decision moment. The decision-making algorithm can repeat this process for patients for whom the most similar decision moment can be detected (e.g., patient C, patient D, etc.). The decision-making algorithm can compare the medical history of patient A with the corresponding medical history of patients B, C, D, etc., and select the first N matches as queue 216, where N represents a positive integer.

[0113] In one or more embodiments, display component 236 may display (e.g., output, present) on a UI the results of the respective cohorts included in cohort 216, along with outcome metrics for the corresponding treatment choices (e.g., overall survival (OS), disease-free survival (DFS) / progression-free survival (PFS), radiographic progression-free survival (rPFS), prostate-specific antigen progression-free survival (pPFS), etc.) as visualizations 222 (e.g., parallel views of other patients). In embodiments, display component 236 may display visualizations 222 in response to selections made by oncologist A on the UI to visualize patient A's medical history and cohort 216. In one or more embodiments, an end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user) may select the most appropriate outcome metric based on visualizations 222. For example, oncologist A may select the optimal outcome metric based on OS, DFS, PFS, etc., to determine subsequent treatment for patient A. Additionally, in one or more embodiments, the data generation component 234 can generate at least two alternative treatment plans for patient A based on the first data 212, the second data 214, and the cohort 216, and the visualization 222 can be influential when evaluating the alternative treatment plans in reference to the cohort results. That is, in addition to using visualization 222 to determine subsequent treatment for patient A, oncologist A can use visualization 222 to compare the alternative treatment plans with cohort 216 and the corresponding cohort results.

[0114] In one or more embodiments, the data generation component 234 may further generate a ranking list 220 based on the first patient data and treatment information. This ranking list includes a ranking list of medical practitioners specializing in treating the disease (e.g., renowned physicians), where the practitioners can be ranked according to various criteria such as recent citations, positive outcomes, guidance, age, ethnicity, etc. For example, the ranking list 220 may include a ranking list of oncologists specializing in treating cancer (e.g., Dr. John Doe of Ohio Hospital M, Dr. Jane Doe of Chinese Hospital N, etc.). In one embodiment, the data generation component 234 may generate the ranking list 220 in response to a selection made by oncologist A on the UI for generating the ranking list 220. In one or more embodiments, the display component 236 may display the ranking list 220 on the UI, allowing an end entity (e.g., hardware, software, machine, AI, neural network, and / or user) to select the names of medical practitioners included in the ranking list 220 to generate a parallel view of the medical history of patients treated by those practitioners. For example, oncologist A can select the names of one or more healthcare practitioners included in the ranking list 220 on the UI via a cursor, touchscreen, or other suitable function, and display component 236 can display the medical history of patients associated with a healthcare practitioner, decisions made by the healthcare practitioner during the patient's treatment, and parallel / overlapping views of the corresponding results. Therefore, oncologist A can view decisions that other healthcare practitioners may have made for patients similar to patient A and / or for situations similar to patient A's experience. Display component 236 can also display "Contact Specialist" buttons, "Video Call Specialist" buttons, and / or "Send My Patient History to Specialist" buttons, which oncologist A can use to obtain further assistance from one or more healthcare practitioners at a given time for the treatment of patient A.

[0115] In one or more implementations, reporting component 254 can generate AI-based report 224, which includes interpretations of information learned by data generation component 234. For example, reporting component 254 can employ a generative AI model that can provide LLM-based outputs, including what data generation component 234 has learned during the period from the decision point to the corresponding outcome (e.g., the final stage), information about patient A, industry trends, patient A's electronic medical record (EMR), guidance, data available to oncologist A, interpretations of one or more outcomes related to the decision point, etc. Therefore, AI-based report 224 can describe, for example, whether patient A followed a treatment plan developed by oncologist A, and whether the clinical decision made by oncologist A was a good decision, a bad decision, or a neutral decision based on effectiveness (e.g., 80% effective, 90% effective, etc.). The AI-based report 224 may further include recommendations from the data generation component 234 to improve future decisions based on past decisions, and clickable hyperlinks that allow oncologist A to directly view specific visual points on the patient's timeline related to specific discussions or summaries in the AI-based report 224. In one or more embodiments, the report component 254 may also employ algorithms to detect patient A's adherence to a treatment plan, for example, determining the extent to which patient A's actions / adherence affect the outcome of the treatment plan, determining how and why patient A's costs compare to the average patient in the same category, and identifying the similarity of known patient parameters (e.g., viewing patient parameters as 80% similar, 90% similar, etc., via sliders displayed on the UI). Such additional information may also be included in the AI-based report 224 to provide oncologist A with multi-layered information, which can guide oncologist A toward higher-level decision-making or higher-level knowledge.

[0116] Generally, the AI-based report 224 can assist end-user entities (e.g., hardware, software, machines, AI, neural networks, and / or users) in learning from good decisions and using the learned content to make future clinical decisions. In one implementation, the reporting component 254 can generate the AI-based report 224 in response to a selection made by oncologist A on the UI. In one or more implementations, the display component 236 can display the AI-based report 224 on the UI.

[0117] In one or more embodiments, the data generation component 234 may also employ generative AI to perform continuous / high-frequency monitoring of the first data 212 and the second data 214 to ensure that the treatment plan recommended by the data generation component 234 remains within desired medical constraints. Contrary to existing methods of patient monitoring, such as those where a physician examines a patient at defined time intervals (e.g., every six hours), the generative AI employed by the data generation component 234 can provide a more efficient method of patient monitoring. For example, the data generation component 234 can continuously parse the first patient data and determine whether patient A should be included in a different cohort, allowing another oncologist to benefit from the clinical decisions made by oncologist A for patient A.

[0118] Continuous monitoring can also help healthcare professionals determine how frequently they should monitor patients. For example, in medical practice, the Eastern Cooperative Oncology Group Performance Status (ECOG) is a clinical tool commonly used in oncology to assess a patient's functional status on a scale from zero (0) to five (5). ECOG can be used in conjunction with factors such as a patient's organ function, existing comorbidities, overall health status, and drug safety to guide treatment decisions. For instance, a patient's ECOG results, combined with their organ function, existing comorbidities, etc., can be matched with certain guidelines, results from other patients, and label warnings on the medication to determine whether a drug can be administered. For example, a healthcare professional can determine if a drug might cause anemia, escalate medical conditions, or cause dizziness. Furthermore, a drug may itself have toxicity or undesirable side effects.

[0119] In one or more implementations, the data generation component 234 can perform concurrency comparisons of different patients' ECOG results, medical history, medical background, organ function, non-commerciality, etc., to determine a patient's specific medical condition and how different patients respond to different treatments. Based on this comparison, the data generation component 234 can employ a filtering process to exclude patients with medical conditions that may make them unsuitable for drug treatment. For example, the data generation component 234 can determine that a patient cannot be given medication for anemia because drug treatment may worsen the patient's health and cause a return to the emergency room. Furthermore, the data generation component 234 can output the determination on a UI, which can be viewed by the patient's physician. Based on this determination, the patient's physician can determine how frequently the patient's condition should be monitored, because while the medication for anemia is not suitable for the patient, it may be necessary to administer it in certain situations. However, by monitoring the patient more frequently, the physician can prepare for intervention rather than prematurely administering anemia medication without accurate evidence.

[0120] In medical practice, physicians typically make clinical decisions by combining information received from multiple sources, such as radiology, laboratory test results, genomic reports, and patient preferences (e.g., preferences for avoiding side effects such as further hair loss, weight loss, loss of taste, burning sensation in the esophagus, etc.), and by correlating the combined information with the patient's clinical symptoms and clinical response, rather than relying on information from a single source. Additionally, certain legal factors may prevent physicians from intervening prematurely, for example, without solid evidence. By determining to monitor patients more closely based on the data generation component 234, physicians can review past data related to multiple patients, overlay this data onto available treatment options via AI model 210, and determine the most appropriate clinical decision by weighing risks and trade-offs. For example, physicians can administer supportive medications and monitor patients frequently, allowing them to prepare for intervention rather than administering medications unsuitable for the patient.

[0121] Additional embodiments of this disclosure are described with reference to the following figures.

[0122] Figure 2B Another block diagram of an example non-limiting system 230 according to one or more embodiments described herein is illustrated. This system can present visualizations of a patient's medical history, including decision-maker-specific visualizations, and can have the ability to generate alternative treatment plans that can be used for subsequent treatment of the disease. For brevity, repeated descriptions of similar elements and / or processes employed in the corresponding embodiments are omitted.

[0123] Non-limiting system 230 illustrates an exemplary system of AI model 210. (See reference...) Figure 2A The AI ​​model 210 discussed may include a data access component 232, a data generation component 234, a display component 236, a first AI component 238, a second AI component 240, a plan search component 242, a detection component 244, an evaluation component 246, a merging component 248, a selection component 250, a prompt generation component 252, a reporting component 254, and a training component 256.

[0124] In one or more embodiments, training component 256 can train data generation component 234 to iteratively analyze first data 212 and second data 214. For example, as treatment for a patient progresses over time, new information can be added to first data 212 and second data 214, and some of this new information can become training data for data generation component 234. For example, one or more outcomes of clinical decisions can be added as feedback to the training dataset adopted by training component 256 to train data generation component 234. Based on such iterative training, data generation component 234 can identify the most relevant cohorts (e.g., cohort 216) and generate alternative treatment plans based on the latest information relevant to the patient. Furthermore, in one or more embodiments, relevant cohorts can be visualized in a decision-maker's view via display component 236 to compare past treatment decisions related to similar patients (i.e., patients with similar medical conditions, characteristics, etc.) and the outcomes of those past treatment decisions. Such embodiments can further assist decision-makers in improving their decision-making and learning from past decisions.

[0125] Training component 256 can iteratively train the first AI component 238 and the second AI component 240 by using new relevant information as training data for the first AI component 238 and the second AI component 240.

[0126] In one or more implementations, training component 256 may also train data generation component 234 to mitigate hallucinations. In machine learning, hallucinations refer to the situation where a model generates incorrect or biased outputs. Hallucinations often occur when a model is trained on biased or incorrect data. For example, some training data used to train data generation component 234 may include sparse datasets that may be biased. For instance, a first demographic group may be more likely to have a greater number of immune problems than a second demographic group. If the training dataset includes a disproportionate amount of data from the first demographic group, data generation component 234 may become trained on features or correlations that are overrepresented by the first demographic group. Therefore, when data generation component 234 is applied to patients from the second demographic group, it may generate results that reflect the skewed pattern.

[0127] To prevent such scenarios, training component 256 can train data generation component 234 to incorporate real-world evidence when generating results. For example, if the hospital lacks a sufficient dataset for a specific group (e.g., the first demographic), data generation component 234 can access publications from external sources (e.g., online publications, publications from other institutions, etc.) to include more relevant data and supporting information for the end-user entity (e.g., hardware, software, machines, AI, neural networks, and / or users). To achieve this, data generation component 234 can employ LLM and one or more methods to suggest the most accurate questions to the LLM based on the context of the patient's medical condition and the context available to the patient (e.g., first-patient data). By fanning out a search of publications, data generation component 234 can provide real-world evidence, for example, when identifying patient cohort 216.

[0128] Data generation component 234 can also be trained by training component 256 to inform end entities (e.g., hardware, software, machines, AI, neural networks, and / or users) of the availability of sparse data. For example, data generation component 234 can inform a physician that the search for cohort 216 has been expanded to a publication search due to the availability of sparse evidence in the patient's context, and data generation component 234 can direct the physician to one or more publications. Thus, while the physician can make the final decision on how the patient's treatment should proceed, data generation component 234 can present the most relevant, accurate, and unbiased data (e.g., data on how previous clinicians arrived at clinical decisions, whether based on guidance, second opinions, multidisciplinary teams, oncology committees, cohort results, etc.) to assist the physician in the decision-making process. As described elsewhere herein, the data presented by data generation component 234 may include past clinical decisions made by the physician for the patient and the results of those past clinical decisions, as well as clinical decisions and corresponding results associated with other patients in similar situations. In one or more embodiments, such information may be overlaid or otherwise displayed on the UI as a comparative view relative to the current patient's medical history. Based on the information displayed on the UI, physicians can make data-driven clinical decisions to treat patients.

[0129] For example, continue to refer to the references involved Figure 2AIn the exemplary scenario discussed for patient A and oncologist A, data generation component 234 can identify cohort 216 as having a 90% success rate on treatment T1 and a 30% success rate on treatment T2. Therefore, oncologist A can choose treatment T1 (the popular choice) to determine subsequent treatment for patient A. However, oncologist A may also decide to abandon treatment T1 due to contradictions related to patient A. For example, due to patient A's preference for a certain quality of life, oncologist A may abandon treatment T1 if it might decrease patient A's quality of life. Similarly, oncologist A may abandon treatment T1 due to contradictions. For example, treatment T1 may be suitable for patient A in the short term, but the treatment T1 regimen might worsen some of patient A's conditions, potentially leading to patient A's withdrawal from cancer treatment. For example, patient A may have a weak liver, and although liver problems may be within acceptable clinical limits, they may affect the lower quartile of liver function. Therefore, administering treatment T1 to patient A may increase the likelihood of patient A's liver failure. Therefore, oncologist A may decide to treat T2 to determine the next course of treatment for patient A because the liver is one of the most vital organs in the body, and liver failure could severely impair the next course of treatment for patient A. In oncology, surgery is often the only curative solution. Non-surgical alternatives typically involve extending life with some defined quality of life. For example, while associated with the intention to cure cancer, non-surgical alternatives often involve a recurring cycle of cancer treatment, recurrence, and diagnosis, and the oncologist attempts to keep their patient disease-free for a longer period before another diagnosis is needed. Therefore, oncologist A may choose to treat T2 (e.g., in rare cases) because it may be more suitable for patient A.

[0130] In one or more embodiments, the data accessed by the data generation component 234 for purposes such as identifying queue 216, generating alternative treatment plans, etc., may include a controlled dataset with high accuracy and be anonymized or de-identified to ensure the data is unbiased relative to the diagnosis. For example, the data generation component 234 may also be trained by the training component 256 to access real-world data from hospital networks, renowned universities, etc., to mitigate hallucination instances. In doing so, the data generation component 234 may be restricted to searching data within a defined knowledge space or a defined parameter space based on context applicable to a specific patient. For example, in one or more embodiments, the first AI component 238 may employ generative AI and natural extraction to parse the patient's medical history at a granular level and create a set of data points for the patient. Based on the data points, the data generation component 234 may perform multidimensional queries or multiparameter searches, and then relax the search filters used for the multidimensional queries or multiparameter searches based on the patient's context.

[0131] In one or more implementations, to extract data that is not easily obtained as discrete data elements, the data generation component 234 may employ a generative AI model, as such data extraction involves knowledge of the data to be extracted to prevent asymptotic data search. For example, the generative AI model employed by the data generation component 234 may access knowledge sources, such as a set of guidelines or prior data, to define the data extraction process. For instance, the guidelines may instruct the generative AI model that it should expand the parameters if the patient exhibits certain parameters or attributes of certain parameters. For example, if the patient has stage 2 lung cancer, the guidelines may restrict the generative AI model's search to parameters, treatments, diagnostic content, etc., related to stage 2 and stage 3 lung cancer. Restricting the generative AI model's search in this way ensures that the generative AI model searches for data within an oncology context while adhering to the patient-relevant context. For example, the generative AI model may begin searching for data related to stage 2 and stage 3 lung cancer, and subsequently relax the filters used for the search based on discrete data elements characterizing stage 2 and stage 3 lung cancer. Such knowledge-supported searches can reduce the illusion to a very small non-zero percentage.

[0132] Recall that data generation component 234 can use first data 212, second data 214, and cohort 216 to generate at least two alternative treatment plans that can be used to treat the patient. In one or more embodiments, data generation component 234 can also employ utility-based analysis to consider the costs of incorrect recommendations versus the benefits of correct recommendations as factors. For example, patient A could be a 90-year-old individual, and data generation component 234 could conclude that although a particular treatment plan generated positive results in 90% of cohort 216, the treatment plan is unsuitable for patient A due to patient A's frailty and could lead to patient A's death. When generating treatment plan recommendations, data generation component 234 can consider a tuple with two parameters as factors, one of which could be the cost associated with different treatment plans, and the other parameter could be quality of life (QOL). Costs can be measured based on the financial costs of different treatments or based on the cost of lost life, where lost life is defined by disability-adjusted life years (DALYs). DALYs can be the number of years of patient life lost due to incorrect decisions as a parameter for evaluating treatment plans. QOL can be measured based on toxicity, quality-adjusted life years (QALY), and other similar parameters. QALY determines disease progression-free survival, or overall survival, which is the length of time a patient remains disease-free before disease recurrence. DALY and QALY are commonly used in medical practice, and data generation component 234 can incorporate DALY, QALY, and / or additional parameters when recommending treatment plans.

[0133] In one or more implementations, the data generation component 234 can be trained by the training component 256 to ensure that the patient's condition remains within a narrow lane, rather than oscillating / swinging widely between extremes, as such oscillations / movements can harm the patient's immune system. For example, wide oscillations can cause the patient's organs to experience high levels of toxicity, leading to a natural shortening of organ lifespan and ultimately a natural shortening of the patient's lifespan. Parameters such as DALY and QALY can assist the data generation component 234 in determining whether the patient's condition is oscillating / swinging widely between extremes, for example, whether the patient is showing a good or poor response due to clinical decisions, even in treatment plans involving trial-and-error solutions. By considering parameters such as cost, DALY, and QALY as factors, the data generation component 234 can recommend treatment plans that can be tailored to the patient, as even if two patients may be very similar in many ways, they can still respond differently to treatment plans. For example, a patient may have poor appetite, low weight, and anemia. Data generation component 234 can determine that potential treatments for the patient may affect the patient's salivary glands and prevent the patient from producing saliva, a condition known as xerostomia. Patients in this condition may experience difficulty swallowing food and may require the use of artificial saliva. Therefore, recommending treatment to the patient may worsen their condition, when in fact the patient could benefit from a protein-rich diet and some dietary restrictions.

[0134] In one or more implementations, an end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user) can select a treatment plan on the UI via a cursor, touchscreen, or other suitable function to view additional information about the parameters considered by the data generation component 234 when recommending the treatment plan. For example, a healthcare practitioner can view the financial costs associated with the treatment plan.

[0135] Figure 3 A diagram illustrating an example non-limiting UI 300 according to one or more embodiments described herein, showing a timeline view of a patient's medical history. For brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments have been omitted.

[0136] The non-restrictive UI 300 can be an interactive UI that can be displayed on a device accessible to healthcare practitioners, clinicians, physicians, nurses, and other healthcare professionals who may influence patient care (e.g., computers, laptops, tablets, smartphones, etc.). The non-restrictive UI 300 may include the patient's name and information such as date of birth (DOB), gender, and other relevant patient details in the top edge, as illustrated in box 302.

[0137] UI 300 may also include an initial patient timeline, as illustrated in box 304, which can be displayed on the UI by display component 236 based on treatment information included in the first patient data and first data 212. The initial patient timeline may include a longitudinal view of the patient's medical history over time and a treatment plan developed by the physician responsible for treating the patient. Additionally, the initial patient timeline can extend from a specific point in the past (e.g., January 1, 2023) to a future point in time (e.g., January 1, 2027). The initial patient timeline can display events, such as imaging data, biomarker data, treatment and planning data, medical visits, pathology and laboratory tests, unclassified events, etc., as part of the patient's healthcare journey, where each event on the initial patient timeline can be displayed as a point (e.g., a data point), and different events can be displayed in different colors. For example, events in the same category can be displayed in the same color, and events in different categories can be displayed in different colors. Information about events displayed in the initial patient timeline can be extracted from various data sources, such as EMR data, smartphone data, radiology information systems, urology and oncology information systems, and others. Furthermore, information can be extracted from various healthcare providers, different institutions, physicians, and other sources with different technological systems. Therefore, the embodiments of this disclosure can provide a single, viewable patient history based on information from multiple different data sources, a technological outcome useful to both patients and clinicians.

[0138] UI 300 may also include an extended view based on the initial patient timeline, as illustrated in box 308, where the extended view can provide detailed information about specific events displayed on the initial patient timeline. For example, in one or more embodiments, a terminal entity (e.g., hardware, software, machine, AI, neural network, and / or user) may interact with the non-limiting UI 300 to select one or more events to view additional details related to the selected events in the extended view. When an event is selected, a bounding box 312 may appear around the selected event to highlight it. The extended view may also include a date display, as illustrated in 306.

[0139] UI 300 may be generated by a software tool (e.g., an existing software tool referenced in paragraph

[0042] ) stored on a computer-readable medium and executed via one or more computer processing units. In one or more embodiments, in addition to such Figure 3In addition to the illustrated menus, icons, and other visual cues, the UI 300 can also be updated via a toggle switch 310. In one or more embodiments, an end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user) can interact with the toggle switch 310 to generate specific views (which may include disease-specific views, decision-maker views, or other updated views). For example, a physician can activate the toggle switch via a cursor, touchscreen, or other suitable function. Therefore, the display component 236 can generate a patient timeline that only shows the decision-maker view, including the patient's specific medical history and treatment plan, which will be referenced... Figure 4 Further description. Additionally, in one or more embodiments, UI300 may include additional toggle switches 310, such as an oncology focusing toggle switch, a cardiology focusing toggle switch, a neurology focusing toggle switch, etc. Figure 3 In this embodiment, the toggle switch 310 is illustrated as being in an inactive or "off" position. In one or more embodiments, the non-limiting UI 300 may be viewed via a slider button instead of the toggle switch 310.

[0140] Figure 4 A diagram illustrating an example non-limiting UI 400 according to one or more embodiments described herein, showing a timeline view of a patient's medical history specific to their medical condition. For brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments have been omitted.

[0141] Continue to refer to at least Figure 1 and Figure 3 The non-restricted UI 400 exemplifies the decision-maker view of the non-restricted UI 300, where the decision-maker view can be a vertical view including multiple rows of medical information corresponding to different categories. For example, in addition to the patient's name, box 302, the date display illustrated at 306, toggle switch 310 (here, in the active or "on" position), and other elements... Figure 3Beyond the illustrated menus, icons, and other visual cues, the non-limiting UI 400 may include the patient timeline illustrated in box 404, which can display events specific to the patient's medical condition, such as imaging data, biomarker data, treatment and planning data, medical visits, pathology and laboratory tests, unclassified events, etc. For example, in the previously discussed exemplary scenario, where patient A can be a cancer patient treated by oncologist A, the patient timeline illustrated in box 404 can display cancer-specific events related to patient A. For example, patient A may undergo scans, take medications, receive chemotherapy, receive injections, etc., over a period of time as part of a cancer treatment plan prescribed by oncologist A. Oncologist A or another terminal entity (e.g., hardware, software, machine, AI, neural network, and / or user) can monitor patient A's cancer treatment plan and input details of cancer-specific events into system 202 using the non-limiting UI 400, based on which display component 236 can display events as points on the patient timeline included in the non-limiting UI 400. Oncologist A can use a cancer-specific view to navigate backward and forward along the patient's timeline to different events and decision points made over time (i.e., key decision moments). In some implementations, the non-limiting UI 400 may include a vertical view or another type of view opposite to the portrait view.

[0142] As discussed elsewhere in this article, the first AI component 238 can detect... Figure 4 The illustrated decision points on the patient's timeline can represent corresponding clinical decisions for patient A. These decision points can also represent key decision moments in patient A's medical history. Decision points can be moments when a physician makes clinical decisions regarding the patient's treatment, such as approved prescriptions, treatment plans entered into software programs, the sequencing of specific tests or procedures to be performed, and other key decision moments in disease treatment. A patient's timeline may include multiple decision points, and multiple decision-makers may exist for the patient (e.g., radiologists, primary care physicians, oncologists, etc.). Display component 236 can highlight / emphasize corresponding decision points on the patient's timeline via visual indicators (e.g., flashing dots, colored dots, dots larger than other dots, color variations of dots, etc.).

[0143] Additionally, the second AI component 240 can detect one or more outcomes (e.g., patient journey points, events, clinical outcomes) generated by the decision point. For example, in one embodiment, oncologist A can interact with the non-limiting UI 400 to select a decision point of interest. In another embodiment, the second AI component 240 can select a decision point automatically or based on instructions provided by oncologist A through interaction with the non-limiting UI 400. When selecting a decision point, the second AI component 240 can detect the one or more outcomes (e.g., patient journey points, events, clinical outcomes) generated by the decision point. The display component 236 can also highlight the one or more outcomes (e.g., patient journey points, events, clinical outcomes) via visual indicators. In one or more embodiments, the display component 236 can highlight the selected decision point and the one or more outcomes (e.g., patient journey points, events, clinical outcomes) generated by the selected decision point via a bounding box 412, and show the visual connection (e.g., edges, lines) between the decision point and the outcome generated by the decision point. In other words, display component 236 can highlight key decision moments in patient A's medical history, and when a key decision moment is clicked or selected, display component 236 can frame the relevant treatment. In one or more embodiments, display component 236 can also update the data displayed in box 408 based on bounding box 412 to show more detailed information (e.g., expanded view) only relevant to the selected key decision moment, including visual connections. For example, box 408 can display the selected key decision moment within bounding box 412 and a magnified (e.g., more detailed) view of the corresponding outcome.

[0144] exist Figure 4 In this context, each circle exemplified on the patient's timeline can represent information that oncologist A can select to learn more about an event, related outcomes, patient A's adherence to the event, and other information related to the event, such as information about chemotherapy, surgery, medications, diet, etc. Such details can be reviewed by oncologist A in a highly visual and useful manner via a non-restrictive UI 400. The extended view exemplified by box 408 can provide detailed information about a specific event displayed on the patient's timeline in conjunction with specific decision points. For example, oncologist A can interact with UI 400 to select a decision point (i.e., a key decision moment) to view additional details related to the selected decision point in the extended view. In one or more implementations, once a decision point is selected (e.g., by selection component 250 or oncologist A), other parts of the patient's timeline (e.g., events) can disappear or gray out to allow oncologist A to focus on the outcomes resulting from the decision point.

[0145] The non-limiting UI 400 may also include interactive components that can be used by an end entity (e.g., hardware, software, machine, AI, neural network, and / or user) to generate visualizations 222, ranking lists 220, and AI-based reports 224. For example, the non-limiting UI 400 may include a dropdown menu, as illustrated in box 402, which can be used by an oncologist A to select options for simultaneously visualizing patient A's medical history with the medical history of other cancer patients who have previously undergone cancer treatment. In one embodiment, the dropdown menu may indicate a default selection to visualize patient A's medical history when toggle switch 310 is activated, such as... Figure 4 and Figure 5 As illustrated. The non-restrictive UI 400 may also include the option to generate a report (e.g., AI-based report 224) via the “What did we learn?” option and the option to mark moments of insight via the “Mark moments of insight” option, as illustrated in box 406.

[0146] In one or more implementations, the non-limiting UI 400 may additionally include a second toggle switch or dropdown menu (not illustrated) that allows an end entity (e.g., hardware, software, machine, AI, neural network, and / or user) to view second opinions. For example, oncologist A may select a second toggle switch to view second opinions previously received by other cancer patients, where such second opinions could assist oncologist A in determining subsequent treatment for patient A. Second toggle switches can be particularly useful in oncology and other fields where patients typically receive second, third, or even fourth opinions. Publications such as the Wall Street Journal indicate that decision-makers (e.g., medical practitioners) often do not possess all the knowledge, such as knowledge of decisions made by other decision-makers or of the latest medical guidance, as medical guidance often changes rapidly. Therefore, a second toggle switch can act as a tool that allows physicians to view second opinions based on the latest guidance. In general, the non-limiting UI 400 can be used to view various types of focused views.

[0147] These implementations benefit decision-makers by allowing them to gain a better understanding of alternative approaches they might have taken when making previous or upcoming clinical decisions, and to think more thoroughly about their clinical decisions based on more information presented in an easily digestible manner. Furthermore, the decision-maker view can be useful for healthcare payers, payers, healthcare institutions, and others who review the quality of decision-making and patient care outcomes. If hospital leaders are seeking to improve clinical outcomes, they can use the implementations of this disclosure to learn specific details based on general benchmarks. For example, the implementations of this disclosure can assist hospital leaders in reviewing specific decisions and decision-makers. This can also be done at the national or international level. The systems and methods disclosed herein can also be used to train and improve primary healthcare professionals, such as medical residents. Attempting to understand how physicians made past clinical decisions and comparing those past decisions with specific outcomes can provide significant value in improving healthcare, as such analyses can be achieved through the systems and methods disclosed herein.

[0148] Figure 5 Example non-limiting patient timelines 500 and 510 are illustrated according to one or more embodiments described herein to illustrate a comparison between the two patient timelines. For the sake of brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments have been omitted.

[0149] The timeline of 500 non-restricted patients shows the data from... Figure 3 The patient timeline, and the non-restricted patient timeline of 510 cases, shows the timelines from... Figure 4 Patient timeline. Non-restricted patient timeline 500 ( Figure 3 ) and non-restrictive patient timeline 510 ( Figure 4 This aims to illustrate a comparison between a general / default view of the patient timeline and a decision-maker-specific view of the patient timeline. Decision points 512 and 514 are highlighted in the unrestricted patient timeline 510; these may be decision points detected on the unrestricted patient timeline 510 by the first AI component 238. (See reference...) Figure 4As described, display component 236 can display visual connections (e.g., edges, lines) between decision points and the outcomes generated by those decision points, such as, for example, the visual connection between decision point 514 and outcomes 514A and 514B. The outcomes generated by the decision points can be any event, patient journey communication, data collection, protocol, and other specific outcomes related to the patient's medical / healthcare journey. Visual connections can originate from decision point 512 and proceed toward other decision points and their outcomes to highlight the sequence of decisions made by oncologist A after decision point 512 as part of patient A's medical journey. In one or more embodiments, the non-limiting patient timeline 510 can also, for example, be based on cohort 216 to show a stack of outcome metrics for other patients at certain decision points. See reference... Figure 4 As discussed, once a decision point is selected (e.g., by oncologist A), other events on the unrestricted patient timeline 510 can disappear or become grayed out to allow oncologist A to focus on the outcomes resulting from the decision point. Reference Figure 6 This concept is illustrated in more detail.

[0150] Figure 6 A diagram illustrating an example non-limiting patient timeline 600 according to one or more embodiments described herein, showing a portion of a patient's medical history, is provided. For brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments are omitted.

[0151] Continue to refer to at least Figure 1 and Figures 3 to 5The unrestricted patient timeline 600 is intended to illustrate some aspects of the patient timeline 510 in more detail. In the patient timeline 600, event 602 can represent a decision point, additional events illustrated by patterned circles can represent the outcome of the decision point, and events illustrated by hollow circles can represent grayed-out events. For example, the unrestricted patient timeline 600 can illustrate the major developments in patient A's medical course. Event 602 can be the decision made by oncologist A to prescribe chemotherapy for patient A. Thus, event 604 can represent a blood test performed on patient A, for example, to check tubular phosphorus reuptake (TRP) levels, event 606 can represent a scan or imaging performed on patient A, event 608 can represent the administration of the first dose of chemotherapy to patient A, and event 610 (and other events immediately adjacent to event 610) can represent corresponding dietary checks performed by oncologist A via oncologist A's smartphone. Event 612 could represent the administration of a second dose of chemotherapy to patient A, event 614 could represent a second scan or imaging performed on patient A to monitor the effectiveness of chemotherapy, and event 616 could be the next decision point based on the results of previous events. In the implementation, oncologist A could select event 602 to view a stack of outcome metrics related to clinical decisions made for other patients. It should be understood that in Figure 6 In this context, hollow circles that are not connected to other events or are connected to each other via lines can represent additional parts of the patient's medical history, such as parts unrelated to event 602.

[0152] Figures 7 to 11 Additional aspects of the unrestricted UI 400 and the unrestricted patient timeline 510 are illustrated.

[0153] Figure 7A diagram illustrating an example non-limiting UI 700 according to one or more embodiments described herein is provided, which can be used to visualize medical research related to a patient's medical condition. Non-limiting UI 700 can be similar to non-limiting UI 400, where toggle switch 310 is in the "on" position. Additionally, in box 704, a visualization dropdown menu can be configured to view other medical research (e.g., cancer research) similar to patient A's medical history, which can allow for viewing separate visualizations related to other medical research in box 706. Alternatively, one or more other medical studies can be visually overlaid or superimposed with the current patient information to obtain a direct comparative view. In addition to information that can be generated via the "What did we learn?" feature, clinicians can also investigate why certain clinical decisions may have led to certain outcomes by examining the similarities and differences between the current patient's clinical decisions and outcomes and those of patients with similar conditions identified via the "Other Studies" option. Bounding box 702 can highlight decision points (e.g., different from decision point 514) and the results of decision points, where decision points can be selected by oncologist A or by selection component 250, and box 706 can represent an extended view that can display additional details of one or more events selected by oncologist A on the patient timeline.

[0154] Figure 8 A diagram illustrating an example non-limiting UI 800 according to one or more embodiments described herein, which can be used to visualize treatment plans adopted by a medical practitioner specializing in treating a patient's medical condition. For the sake of brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments have been omitted.

[0155] The non-limiting UI 800 may resemble UI 400, where toggle switch 310 is in the "on" position, and the visual dropdown menu in box 804 is configured to view treatment plans adopted by medical practitioners (e.g., specialists or renowned physicians) in a medical field related to the patient's disease (e.g., in the field of oncology treating the type of cancer suffered by patient A). Bounding box 802 may highlight the results of the decision point selected by oncologist A or selection component 250. As illustrated in box 804, the non-limiting UI 800 may include a second dropdown menu that can display a ranking list 220, which may be generated by data generation component 234. Oncologist A can select a specialist's name in the second dropdown menu to view one or more treatment plans adopted by the specialist and their corresponding results. In one or more implementations, when selecting a specialist's name, additional options may be displayed on the non-limiting UI 800, which oncologist A may use to contact the specialist for additional details.

[0156] The ability of data generation component 234 to present the most relevant, accurate, and unbiased data can be particularly useful for healthcare practitioners who lack extensive experience in treating specific medical conditions or cases of those conditions. For example, a general oncologist practicing in a rural area might develop a treatment plan with a 72% best outcome for an uncommon form of cancer, while data generation component 234 could identify that leading physicians in the field have developed treatment plans with 89% or even 93% best outcomes. The information learned by data generation component 234 can be visually displayed on non-restrictive UI 800 by display component 236 to assist general oncologists in adjusting treatment plans based on those adopted by leading physicians. In one or more implementations, in addition to ranking list 220, display component 236 may also display alerts generated by data generation component 234 for general oncologists on non-restrictive UI 800 to assist them in making better clinical decisions. Reference Figure 10 The details of the example output that can be generated by using the "Other Famous Doctors" option in box 804 are discussed, and although in Figure 8 Not illustrated, but such example output can be displayed within box 806. It should be understood that... Figure 8 In the middle, box 806 is intended to represent an extended view of UI 800, similar to... Figure 4 The extended view illustrated in box 408.

[0157] Generally speaking, at least Figure 7 and Figure 8 The illustrated visual dropdown menu can be adopted by an end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user) to view additional data that can be used to determine subsequent treatment for the patient. In one or more embodiments, when a desired option is selected via the dropdown menu, the data generation component 234 can employ the patient's digital twin and other technologies that can be used to display the suggested path forward (e.g., alternative treatment plans) based on factors relevant to decision-making recommendations. For example, the data generation component 234 can consider various factors such as cancer guidance, relevant laws and regulations, data from other experts in the field (where experts can be ranked or assigned ratings (e.g., based on a specific form of cancer in the patient)), the outcomes of treatment plans adopted by other experts (e.g., in the form of actual data, stories, online data, medical trials, etc.), past errors made by clinicians, data from the patient (e.g., test data, scans, experience, or other relevant data), moments of insight, etc. Additionally, the data generation component 234 can rank these factors via a weighted neural network to identify alternative treatment plans.

[0158] In one or more implementations, the visual dropdown menu can also be adopted by an end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user) to view recommendations from an institution or exemplary case based on evolving and improving guidance for a particular type of cancer and related drug treatments. For example, oncologist A could use the dropdown menu to select an organization, such as the National Comprehensive Cancer Network (NCCN), a nationally managed healthcare institution, etc. When an organization is selected, data generation component 234 can access relevant guidance from the organization based on factors such as patient A's medical condition, and display component 236 can display the guidance on a UI that can be viewed by oncologist A. Typically, clinical decisions are based on relevant guidance. Therefore, the ability of data generation component 234 to access various types of guidance can be highly valuable to healthcare practitioners.

[0159] Figure 9 A diagram illustrating an example non-limiting UI 900 according to one or more embodiments described herein, which can be used to mark moments of insight in a patient's medical journey. For the sake of brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments have been omitted.

[0160] Unrestricted UI 900 can be similar to unrestricted UI 400, where toggle switch 310 is in the "on" position, and the visualization dropdown in box 904 is selected to view treatment plans adopted by medical practitioners (e.g., specialists or experts) in the field of oncology treating the type of cancer suffered by patient A. Figure 9 In the middle, box 806 indicates Figure 8 Box 806.

[0161] In the unrestricted UI 900, events (e.g., procedures, outcomes, follow-ups, tests, etc.) resulting from a decision point (e.g., a decision point chosen by oncologist A) are highlighted via bounding box 902 on the patient timeline. Box A is also illustrated in the patient timeline. Figure 9An expanded view of box A is illustrated at 910, showing insight moment 908. Recall that in one or more implementations, first AI component 238 can detect one or more decisions as insight moments, where insight moments represent critical moments when non-standard insights are identified by an end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user). An "insight moment" can be understood as a breakthrough in thinking achieved by a chess player during a game due to deviating from the conventional move. For example, oncologist A can select a decision point and then select the "Mark Insight Moment" button illustrated in box 906 to capture a good decision made during patient A's medical course, or oncologist A might suddenly have an idea to change patient A's treatment plan and mark the insight moment based on this sudden idea. Thus, insight moments can include captured good decisions and moments that may be valuable to oncologist A and to the medical profession (e.g., in treating a specific type of cancer) in patient A's cancer treatment. Insight moments marked by oncologist A can also become available for other medical practitioners to practice oncology, handle queues similar to queue 216, etc. Insight moments can also be interesting or unique learning content, and they can be collected together with other insight moments identified by other decision-makers working on treatments for the same disease, in order to potentially detect new drugs or treatments for that disease.

[0162] In one or more implementations, insight moments can also be automatically detected and labeled by the first AI component 238. For example, the first AI component 238 can employ software / algorithms to detect sudden decision points that a physician considers, anomalies, actions taken by a physician that deviate from typical practice, etc., and label such decision points as key moments or insight moments that may be useful to oncologist A or other physicians. Thus, insight moments can be described as a collection or record of knowledge over time. Insight moments may include dialogues detected via voice input between a decision-maker and a patient or between a decision-maker and a nurse, for example, where the decision-maker's responses are verbally conveyed and include non-standard insights related to the patient, disease, treatment plan, and / or healthcare. Furthermore, the closer a patient and their medical condition are to another patient and their medical condition, the greater the likelihood that an insight moment from another healthcare professional or another patient is relevant to that patient. In such scenarios, the UI 900 can display potentially relevant insight moments on the screen (with a faded view or other highlight) for the decision-maker to review. Therefore, the individual moments of insight detected by the first AI component 238, and the patterns discovered in those moments of insight, through analysis or artificial intelligence, may be useful to decision-makers.

[0163] Figure 10A diagram illustrating an example non-limiting UI 1000 according to one or more embodiments described herein shows moments of insight and parallel views of the medical histories and moments of insight for multiple patients. For brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments have been omitted.

[0164] Continue to refer to at least Figure 1. Figure 8 and Figure 9 The unrestricted UI 1000 is designed to illustrate some aspects of the unrestricted UIs 800 and 900 in more detail. In the unrestricted UI 1000, the patient timeline 1002 displays a parallel view of alternative medical histories of patients treated by different specialists. For example, medical history 1002A could represent the medical history of patient A, medical history 1002B could represent the medical history of patient B, and medical history 1002C could represent the medical history of patient C, where patient B could be a patient of Dr. Jane Doe 1, and patient C could be a patient of Dr. John Doe 1. The corresponding medical histories of patients A, B, and C can be distinguished by different colors, patterns, and / or other visual indicators. In response to a choice made by oncologist A, display component 236 can display medical histories 1002B and 1002C on the patient timeline 1002 to visualize decision points and corresponding outcomes in patients treated by other specialists in cancer treatment, such as... Figure 10 Example 1004 is shown in the diagram. For instance, oncologist A can select "Other Specialists" in a first dropdown menu to view a ranking list 220, which includes the names of cancer specialists identified by data generation component 234 based on factors similar to patient A, factors similar to their condition, and other relevant factors. Oncologist A can then select (e.g., by clicking checkboxes) the names of cancer specialists Dr. John Doe 1 and Dr. Jane Doe 1 in a second dropdown menu to generate a view displayed by the patient timeline 1002. In one or more embodiments, oncologist A can also manually rank specialists by interacting with a non-limiting UI 1000. In one or more embodiments, oncologist A can use a visual dropdown menu to view the medical histories of cancer patients previously treated by oncologist A.

[0165] In one or more embodiments, oncologist A can select decision points in medical courses 1002B and 1002C to view additional details, such as the outcome of the corresponding medical course, the progress of the corresponding treatment, etc., in an expanded view of the non-restrictive UI 1000. In one or more embodiments, the patient timeline 1002 can further display an outcome review, including scores for the outcomes of medical courses 1002A, 1002B, and 1002C. In one or more embodiments, oncologist A can select scores to see how each score is calculated. In one or more embodiments, the corresponding score for the corresponding medical course can be calculated by another component of data generation component 234 or AI model 210, where the corresponding score can indicate the success rate of the corresponding medical course. For example, data generation component 234 can calculate a 72% best outcome score for medical course 1002A, a 98% best outcome score for medical course 1002B, and an 89% best outcome score for medical course 1002C. In one or more embodiments, data generation component 234 can generate percentile scores or other types of scores to indicate the success rate of the corresponding medical course.

[0166] Therefore, the unrestricted UI 1000 can assist terminal entities (e.g., hardware, software, machines, AI, neural networks, and / or users) in visualizing the medical histories of multiple patients by overlaying medical histories across patient timelines 1002. For example, oncologist A can select an option from a visualization dropdown menu to view medical histories 1002B and 1002C, and deselect the option to remove medical histories 1002B and 1002C from the patient timeline 1002. The overlaid medical histories can help oncologist A view the causal relationships and correlations between parameters of different patient groups.

[0167] In one or more implementations, as a patient's medical history progresses, the generative AI employed by the data generation component 234 can continuously index the patient timeline 1002 with new data, differential data, connection / relevance data, or suggestive data from the first data 212 and the second data 214. As described elsewhere herein, the overlay of different patients' medical histories can present physicians with various treatment options to determine subsequent treatment for the patient, and physicians can interact with the non-restrictive UI 1000 to further explore individual treatment options and the probabilities associated with those options. For example, to ensure that patient A can remain in remission, oncologist A can review fundamental outcome metrics associated with each treatment option, such as DALY, QALY, etc. For instance, the first treatment option might be associated with two years of progression-free survival, the second with one year and eight months, and the third with three years. Progression-free survival can refer to the duration a patient can survive without clinical intervention. Oncologist A can choose the third treatment option with the longest progression-free survival, or physician A can choose different treatment options based on other factors. For example, patient A may have experienced six emergencies during a two-year progression-free survival period, resulting in a poor quality of life (QOL), and QOL information can be one of the basic outcome metrics displayed by display component 236 on the non-restricted UI 1000 along with each treatment option. Based on patient A's QOL information and / or patient A's preference for a particular QOL, oncologist A can determine that a second treatment option is more suitable for patient A, even though a third treatment option is associated with the longest progression-free survival. Therefore, generative AI can operate continuously in the background to extract information from first data 212 and second data 214, calculate relevant outcome metrics, and visually overlay the data onto the non-restricted UI 1000 using these outcome metrics.

[0168] In one or more implementations, the option to mark moments of insight can also be adopted by an end entity (e.g., hardware, software, machine, AI, neural network, and / or user) to mark decision points that occur in other patients' medical histories as moments of insight. For example, oncologist A can select Figure 9 The illustrated “Mark Insight Moment” button marks a decision point in patient C’s medical history as Insight Moment 908 to capture a decision made by Dr. John Doe 1 that differs from that made by oncologist A.

[0169] In some implementations, UI 1000 and other UIs illustrated in the accompanying drawings may include options for generating cost information. For example, such as... Figure 10As illustrated at location 1006, UI 1000 may include a button that can be selected by a terminal entity (e.g., hardware, software, machine, AI, neural network, and / or user) to view cost information related to different treatment plans. When the terminal entity (e.g., hardware, software, machine, AI, neural network, and / or user) selects the button, data generation component 234 can generate cost information, and display component 236 can visually display the cost information on UI 1000, wherein cost information can be displayed for various types of visualizations that can be generated by embodiments of this disclosure and for corresponding medical events included in the queue. The cost information may indicate the cost billed for corresponding events (e.g., scans, medication, doctor visits, etc.) in the patient's medical course, as well as the total treatment cost for the patient. For example, the cost information may indicate the cost associated with each event on the patient's timeline 1002 and the cost of the entire segment of the patient's timeline 1002 from the first decision point to the second decision point. In some scenarios, renowned physicians can use cost information to develop treatment plans that produce the same results as another treatment plan developed by a different physician, but at a significantly lower cost (e.g., $100,000 less). Therefore, cost information can be highly valuable to decision-makers (e.g., oncologist A) and other end-user entities that may require it (e.g., hardware, software, machines, AI, neural networks, and / or users). For example, cost information can be valuable to leaders of healthcare facilities and institutions (e.g., managers, heads, etc.) when making large-scale equipment purchases and designing healthcare facilities (e.g., hospitals, clinics, medical research institutions, etc.). In general, cost information can assist end-user entities (e.g., hardware, software, machines, AI, neural networks, and / or users) in making decisions large and small, help healthcare systems (e.g., healthcare facilities and institutions) reduce costs and save money, and help decision-makers achieve better clinical outcomes.

[0170] In one or more implementations, the data generation component 234 can recommend treatment pathways or plans with high (e.g., highly positive) outcomes and lower costs based on cost information (e.g., to decision-makers). For example, software algorithms and / or AI models employed by the data generation component 234 can analyze data points on the patient timeline 1002 and synthesize recommendations / recommendation actions or clinical decisions for decision-makers. If decision-makers wish to understand the reasons behind the actions recommended by the data generation component 234, they can evaluate the decision-maker view described herein to understand the specific events and clinical decisions that led to lower costs and higher outcomes. For example, oncologist A may need to choose treatment options from surgery, therapy, transplantation, treatment diagnosis, drug therapy, etc., and comparing cost information and outcome analyses associated with different medical courses included in cohort 216, as well as clinical decisions made by other specialists, may be valuable in selecting treatment options. In one or more implementations, the data generation component 234 may also analyze other quality metrics to perform comparative analyses of costs and outcomes associated with different treatment plans, wherein such quality metrics may include time to diagnosis, time to treatment initiation, disease-free interval, progression-free survival, overall survival, etc.

[0171] An additional technical feature of the system and method described herein is the comparison of treatment plans associated with different patients within UI 1000, and the determination of whether a treatment plan for a patient at the primary hospital can be used for another patient at the secondary hospital (e.g., a local patient). For example, when performing a comparative analysis of cost information and outcomes associated with different treatment plans, data generation component 234 can answer questions such as, “Is the patient eligible for certain discounts that another patient receives?” or “Does our hospital have the specific medical equipment used at the location of the renowned physician to implement the treatment plan developed by that physician, or will different equipment be needed?” Such assessments can be beneficial to decision-makers because even if a medical course is known to have produced positive results, a patient’s medical course cannot typically be fully replicated for another patient. In one or more embodiments, data generation component 234 can also assign flags or other visual indicators to decision-makers on a comparative or overlay view of relevant information. For example, data generation component 234 can assign flags to events on the patient timeline 1002, such as the flag illustrated at 1008, with a note stating, “This scan was performed using a new treatment diagnostic machine not available at our hospital.” In response to a decision-maker clicking a notification icon or decision point on UI 1000, display component 236 can display a flag, and in response to the decision-maker further hovering the cursor over the flag or otherwise selecting the flag via UI 1000, display component 236 can display a note. Such flags and associated notes can be very valuable because different treatment plans may already be implemented in various medical facilities in different ways and with different technologies. Additionally, some medical facilities may lack access to certain drug treatments and equipment. For example, some rural hospitals or hospitals in low-income areas may lack access to medical professionals or equipment, and the implementation methods disclosed herein can assist such medical facilities in making optimal decisions given the availability of facilities and personnel.

[0172] Figure 10 The document demonstrates the clear benefits of improved technology in certain implementations. Instead of flying internationally and paying thousands of dollars to speak with a renowned physician, or waiting three months to be added to a physician's schedule, UI 1000 can display helpful information relevant to a physician's clinical decisions and insights on a useful screen. This is beneficial for both patients and decision-makers. The visualization tool can also allow for dialogue between physicians, where they can digitally communicate with each other about timelines of certain patients and why relevant decisions were made, and share thoughts and ideas. Based on the visual and technical aspects of the implementations of this disclosure, such functionality can be implemented in a way that is easily understood by the end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user).

[0173] Figure 11A flowchart illustrating an example non-limiting process 1100 according to one or more embodiments described herein is provided, which generates an AI-based report summarizing a patient's medical history. For brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments are omitted.

[0174] Continue to refer to Figure 2A The non-limiting process 1100 illustrates how an AI-based report 224 (e.g., a generative AI report) can be generated. For example, at 1102, an end entity (e.g., hardware, software, machine, AI, neural network, and / or user) can select a "What did we learn?" button. In response, the reporting component 254 can generate the AI-based report 224 at 1104 based on the results associated with the corresponding clinical decision and recommendations for subsequent treatment of the medical condition. This AI-based report includes an interpretation of the information learned by the data generation component 234. For example, the reporting component 254 can act as an outcome interpretation module that uses generative AI to interpret the results of a clinical decision made by oncologist A for patient A in the AI-based report 224. For example, the AI-based report 224 may include an interpretation of information learned by the data generation component 234 in patient A's previous round of chemotherapy, how chemotherapy affects subsequent treatment for patient A, whether chemotherapy was a good or bad decision, and whether the decision to change the treatment plan midway through treatment based on complaints from patient A was a good decision, etc.

[0175] Typically, oncologists and other specialists possess extremely high levels of professional competence, and their compensation is substantial, which may lead some to highly value their opinions. However, specialists can sometimes make erroneous treatment decisions, and feedback from AI-based reports 224 can prevent such misguidance. For example, AI-based reports 224 can inform oncologists treating rare forms of cancer that past clinical decisions made by the oncologist were not optimal. For instance, report component 254 can mine relevant data and determine that the clinical decision made by oncologist A to change the treatment plan for patient A midway through treatment was an undesirable decision.

[0176] In one or more implementations, the AI-based report 224 may include a summary that can be generated by the reporting component 254 via generative AI by aggregating and combining various parts of a patient's medical history. Such reports can reduce the cognitive footprint of healthcare practitioners because, in some cases, physicians are unaware of the various types of information available to patients, and patients are unaware of information that might be useful to physicians. In such cases, the AI-based report 224 can provide physicians with useful information, including, for example, a summary of the patient's medical history during previous clinical visits, and also including keywords, the source of the keywords, sources of other types of data, events that have occurred since the previous clinical visits (e.g., two imaging scans, two blood tests, tumor marker tests, visits to the emergency department, visits to the endocrinology clinic, etc.). For example, oncologist A can determine the medication treatment for patient A based on the AI-based report 224.

[0177] In one or more implementations, the AI-based report 224 can generate a coarse summary and a fine summary, wherein the coarse summary describes a patient overview, and the fine summary describes the patient overview at a more granular level of detail, such as events related to patient A's medical history that may have occurred since patient A's last visit to oncologist A. For example, the fine summary could describe events that occurred within three weeks, one month, two months, etc., prior to patient A's planned visit to oncologist A. In this way, the AI-based report 224 can allow oncologist A to prepare for each future medical visit of patient A, and the details of each medical visit between oncologist A and patient A can also be summarized in the AI-based report 224 by the reporting component 254. Therefore, the AI-based report 224 can be updated iteratively, which allows oncologist A to closely monitor how patient A responds to each clinical decision made by oncologist A.

[0178] Generally, AI-based reports 224 can allow end-user entities (e.g., hardware, software, machines, AI, neural networks, and / or users) to observe the causal relationship between clinical decisions and outcomes, ask specific questions, identify good clinical decisions, and even generate additional work outputs (e.g., papers, publications, etc.). Because AI-based reports 224 can also describe the basis of clinical decisions, they can be used for educational purposes, such as by senior clinicians to teach junior clinicians. In one or more implementations, report component 254 can combine textual data and visual representations from AI-based reports 224 to enhance the usability of AI-based reports 224.

[0179] AI model 210 and AI-based report 224 can be powerful tools for clinical trials. Clinical trials often involve a large number of discovery and analysis patterns and are constrained by defined standards of care. For example, clinical trials have a broader scope than the treatment process for a single patient. For instance, researchers involved in clinical trials tend to look for known clinical effects, known responses, known interventions, correlations, causes, potential drug descriptions that can be used to label drugs, the percentage of hypertensive patients in the cohort, the outcomes of the corresponding patients in the cohort, etc. Therefore, employing AI model 210 in clinical trials can allow for further discoveries, for example, via AI-based report 224 and / or other results that can be generated by AI model 210.

[0180] Continue to refer to Figure 2A , Figures 12 to 15 It describes how AI model 210 can detect decision points and outcomes in a patient's medical journey, identify cohorts of the patient's medical journey, and generate a ranked list of specialist doctors who can treat the patient's medical condition.

[0181] Figure 12 A flowchart illustrating an example non-limiting method 1200 according to one or more embodiments described herein is provided, which detects decision points in a patient's medical course. For brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments are omitted.

[0182] In one or more embodiments, the first AI component 238 can detect multiple decision points within a time view of the patient's decision-making process as displayed on the patient's timeline. To detect these multiple decision points, the first AI component 238 can employ an AI agent system including a plan search component 242, a detection component 244, an evaluation component 246, and a merging component 248. For example, patient data 1202 may include first data 212 and second data 214. At 1206, the plan search component 242 can employ an LLM service to identify a first set of decision points within the patient's timeline based on determinations and / or modifications within a treatment plan associated with the patient's medical condition. At 1208, the detection component 244 can employ a deep learning (DL) model to identify a second set of decision points within the patient's timeline based on inputs associated with events within the patient's medical history. The DL model can extract features from images and text. At 1210, the evaluation component 246 can employ rule configuration based on a set of clinical rules, wherein the set of clinical rules may include rules configured to detect defining clinical patterns. Finally, the merging component 248 can generate a list 1204 that includes the multiple decision points by merging the first set of decision points, the second set of decision points, and the third set of decision points. (See reference...) Figure 2AAs described, the corresponding decision points included in List 1204 may represent critical decision moments or key clinical decisions made by end entities (e.g., hardware, software, machines, AI, neural networks, and / or users) for the treatment of a patient's medical condition.

[0183] Figure 13 A flowchart illustrating an example non-limiting method 1300 according to one or more embodiments described herein is provided, which detects events and outcomes arising from decision points in a patient's medical course. For brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments are omitted.

[0184] Continue to refer to Figure 1. Figure 4 and Figure 12 In one or more embodiments, the second AI component 240 can detect one or more outcomes included in the second data 214. To detect these outcomes, the second AI component 240 can employ an event and outcome determination system including a selection component 250, a prompt generation component 252, and a merging component 248. For example, the selection component 250 can select a decision point 1302, which can be detected by the first AI component 238 on the patient's timeline. For example, decision point 1302 can represent a first chemotherapy event (chemo1), a second chemotherapy event (chemo2), surgery, hormone testing, adjuvant radiotherapy (adj RT), etc. Subsequently, at 1304, the prompt generation component 252 can generate a summary prompt set based on decision point 1302 and patient data 1202 to identify a set of events representing the consequences of a clinical decision. For example, the prompt generation component 252 can generate summary prompts to filter data based on criteria such as patient parameters (box 1310) and medication instructions (box 1312) at each decision time. The prompt generation component 252 can input a summary prompt set into the LLM (e.g., LLM-based module 1306), and the merging component 248 can analyze the results generated by the LLM when processing the summary prompt set to detect relevant events and results 1308 produced by decision point 1302. The second AI component 240 can detect the corresponding result set for the corresponding decision point in a similar manner.

[0185] In one or more embodiments, the prompt generation component 252 may also employ a computer-aided diagnostic (CAD) model to generate summary prompts. For example, the CAD model may access knowledge sources (such as decision points 1302) and patient-related medical context (such as patient data 1202) and automatically generate questions pointing to specific outcomes. These questions may be summary prompts, which may be processed by the LLM-based module 1306 to generate responses to the questions. In one or more embodiments, the LLM-based module 1306 may also provide prompts from summary prompts generated by the prompt generation component 252, as well as prompts generated by end-user entities (e.g., hardware, software, machines, AI, neural networks, and / or users). For example, the prompt generation component 252 may automatically generate several summary prompts, and the UI (e.g., non-limiting UI 400) may include text boxes where oncologist A can manually enter additional questions to prompt the LLM-based module 1306. The prompt generation component 252 can access questions from oncologist A and use automatically generated summary prompts and questions entered by oncologist A to prompt the LLM-based module 1306, while remaining within the knowledge base and the medical context relevant to patient A. This functionality allows end-user entities (e.g., hardware, software, machines, AI, neural networks, and / or users) to reach the desired endpoint based on the response generated by the LLM-based module 1306.

[0186] In some cases, treatment for a patient may become palliative, meaning the attack level of a previously administered treatment may change. In such situations, the provision of a text box allows the end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user) to switch the treatment plan to palliative care. For example, a physician can upload new guidance documents, papers, publications, additional knowledge sources, and / or other data via the text box, prompting the LLM-based module 1306 to determine how the physician can switch the patient's treatment plan to one suitable for palliative care.

[0187] Therefore, in one or more embodiments, the first AI component 238 and the second AI component 240 can enhance the clinical insights provided to healthcare practitioners by the AI ​​model 210 by identifying causal relationships among parameters related to a patient's medical condition, where parameters can be continuously monitored. The enhanced clinical insights can assist healthcare practitioners in providing improved healthcare to patients by examining the consequences of clinical decisions and subsequently making better clinical decisions.

[0188] Figure 14 A flowchart illustrating an example non-limiting method 1400 according to one or more embodiments described herein is provided, which identifies a cohort of a patient's medical history. For brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments are omitted.

[0189] In one or more implementations, the data generation component 234 may identify a queue 216 of patients of interest via generative AI. To identify the queue 216, the data generation component 234 may summarize the patient’s medical history up to decision point 1302 at 1416 and generate a history summary 1410 based on the summary.

[0190] Subsequently, the data generation component 234 can compare the course summary 1410 with the corresponding medical course of the corresponding patient in one or more additional patients (e.g., patients in the same medical facility responsible for treating the patient). For example, at 1418, the data generation component 234 can access second patient data including data related to the one or more additional patients, and at 1408, the data generation component 234 can identify the decision point (i.e., the critical decision moment) (i.e., the most similar decision point) included in the second patient data that is most similar to decision point 1302. In this regard, the arrow at 1402 can represent a first decision point (e.g., Pt. #1) included in the second patient data, the arrow at 1404 can represent a second decision point (e.g., Pt. #2) included in the second patient data, the arrow at 1406 can represent the Mth decision point (e.g., Pt. #M) included in the second patient data, and so on, where M represents a positive integer. One or more decision points included in the second patient data can be most similar to decision point 1302.

[0191] At point 1412, data generation component 234 can perform summary matching, whereby data generation component 234 can compare the course summary 1410 with the most similar decision point. At point 1414, data generation component 234 can select a set of patients as patient queues based on the summary matching. Specifically, data generation component 234 can select a set of medical courses from the second patient data as the first N queues of patient medical courses, where N represents a positive integer. The first N queues may include queue 216.

[0192] In one or more implementations, the data generation component 234 may employ existing cohort algorithms and / or system-specific, decision-making-based algorithms to identify cohort 216. For example, to identify cohort 216 of cancer patients, the data generation component 234 may employ a cancer-specific data model to perform aggregated matching based on cancer type and subtype, patient age, sex, weight, molecular profile, tumor, nodule, metastatic (TNM) stage of cancer, neoadjuvant (NeoAdj) therapy, adjuvant (Adj) therapy, first-line, second-line, patient comorbidities, and allergies.

[0193] In some cases, data generation component 234 can consider new disease outbreaks as a factor when identifying cohort 216. For example, most cancer patients are typically immunosuppressed and at high risk of infection, including infections acquired in healthcare facilities. Infections can have profound effects on cancer patients. For example, any infection can further weaken a cancer patient's immune system and cause the patient's immune system to deviate from cancer treatment, for example, due to the administration of drugs to treat infections. If a cancer patient contracts a relatively new disease (e.g., a week-old illness), new data can be added to the patient's timeline (e.g., Figure 5 The new data becomes available to cancer patients on the non-restricted patient timeline 510. For example, the new data may become available in the form of events, such as for infection testing, treatment, etc. In one or more embodiments, the data generation component 234 may employ generative AI to determine whether the new data for cancer patients includes enough information to identify cohort 216, since the infection is relatively new. If the new data does not include enough information, the data generation component 234 may exclude / filter the new data when identifying cohort 216 until enough decision points related to the infection become available to cancer patients.

[0194] In one or more embodiments, cancer patients may be associated with a cohort, and the data generation component 234 may continuously update the cohort as additional decision points become available in the cancer patient's cancer-specific medical course. For example, at some times, the data generation component 234 may include the cancer patient's medical course in a large cohort, and at other times, it may include the cancer patient's medical course in a smaller cohort. In such cases, if any patient associated with the cohort develops an infection, the data generation component 234 may apply a new disease code to the patient and alert / warn the relevant oncologist regarding the new disease code. Thus, the relevant oncologist can monitor the condition of infected patients to determine if the infection is prevalent and whether it may potentially spread to other patients associated with that cohort, as some aspects of the cancer patients associated with that cohort may be immunosuppressed, making them susceptible to infection. In other words, in one or more embodiments, the data generation component 234 may consider a new disease outbreak as a factor and only alert patients treated by the relevant oncologist if they are in a group of other patients who have contracted the new disease. Because a cohort can highly match several shared characteristics among patients associated with it, oncologists can benefit from being alerted by the data generation component 234 if one or more patients associated with the cohort acquire an infection. For example, oncologists can attempt to determine why the one or more patients acquired the infection, whether the infection is an isolated issue or an immune modulatory condition, and how to prevent the spread of the infection to other patients associated with the cohort.

[0195] Figure 15 Flowcharts of example non-limiting methods 1500 and 1510 according to one or more embodiments described herein are illustrated, which generate a ranked list of medical practitioners specializing in treating medical conditions and generate additional data corresponding to the respective medical practitioners in the ranked list.

[0196] In one or more embodiments, the data generation component 234 may generate a ranking list 220 based on the first patient data and the treatment information included in the first data 212, wherein the ranking list 220 may be adopted by an end entity (e.g., hardware, software, machine, AI, neural network and / or user) to explore treatment plans (e.g., a second treatment plan) adopted by a medical practitioner (e.g., a specialist or expert) who specializes in treating the patient's medical condition, explore the results associated with the treatment plan (e.g., a second result), and contact the medical practitioner.

[0197] In one or more implementations, the data generation component 234 may use a non-limiting method 1500 to generate a ranking list 220 by listing the names of experts and ranking them. For example, at 1502, the data generation component 234 may perform a global search to find renowned doctors based on the type of cancer a patient has. For example, the data generation component 234 may identify potential oncology experts from online sources, databases, etc., who frequently publish research papers, are frequently consulted, etc. For example, for certain cancers or diagnoses, sometimes a very clear list of renowned doctors can be accessed from online sources.

[0198] At 1504, data generation component 234 can rank top physicians based on inputs such as recent citations of their work, positive cancer outcomes for their patients, and guidance provided by the physicians responsible for treating those patients. Additionally, when end-users compare their decision-maker view on their patient timeline with other physicians, data generation component 234 can identify physicians selected more frequently by the end-user (e.g., more times than other physicians) and recommend those physicians more significantly, for example, by listing their names higher in the ranking list 220. Furthermore, surveys completed by clinicians can also identify who are top physicians in the medical field for a specific disease. For example, third parties (e.g., institutions), independent groups (e.g., medical professional associations), or even government entities (e.g., the Ministry of Health) may have preferences or rankings of top medical professionals for certain diseases and patient conditions. In one or more embodiments, data generation component 234 can employ a rules engine or AI model to identify top physicians based on the factors listed herein and / or other factors. The ranking adopted by data generation component 234 can be similar to how a magazine ranks top lawyers in different legal fields, or similar to how best professionals in a particular profession are recognized. At 1506, data generation component 234 can re-rank the renowned doctors based on factors such as the patient's age, gender, and ethnicity to generate a ranking list 220. At 1508, display component 236 can display the ranking in the "Expert Name" field on the UI.

[0199] In some implementations, for legal and privacy reasons, such as if patients treated by a renowned physician come from a different medical facility than the one currently treating the patient, their names can be hidden from the physician via display component 236. In other implementations, for example, if patients come from the same medical facility currently treating the patient, their names can be displayed to the physician via display component 236. In one or more implementations, the names of medical professionals can also be hidden. For example, the names of medical professionals can be hidden based on their country of residence, geographical reasons, and / or legal reasons.

[0200] Non-limiting method 1510 can describe a process that can be performed (e.g., by display component 236) when a physician selects a physician's name on the UI via a cursor, touchscreen, or other suitable function. For example, at 1512, the physician can select a physician's name from a ranking list 220. In some embodiments, the physician's name can be automatically selected by display component 236 based on audio instructions received from the physician, for example, via the device's microphone. At 1514, display component 236 can display on the UI a parallel view of the patient's medical history and overlapping medical histories of patients treated by the selected physician. At 1516, display component 236 can display on the UI options that allow the physician to delve deeper to explore the decision-making processes, methodologies, etc., adopted by the physician and to contact the physician (e.g., a "Delve Deeper" option). The “In-Depth Exploration” option may include options for reading notes, EMR records, or other information that a specialist may have specifically entered into the medical records of different patients, as well as research papers or scientific papers written by specialists, which may be related to the clinical decisions made by the specialists at the time of writing and the patient’s condition (e.g., disease state, gender, age, and / or other factors).

[0201] The ranking list 220 can provide physicians with an efficient method for analyzing alternative treatment plans, for example, as opposed to attending conferences or other complex methods. In one or more implementations, physicians can contact leading physicians who can describe specific cases or methodologies in more detail, or physicians can forward patient-related segments along with one or more questions to leading physicians via secure chat or communication lines. Thus, physicians can access offline multidisciplinary input from different leading physicians (e.g., offline oncology committees) based on the ranking list 220.

[0202] Figure 16 and Figure 17 Figures illustrating example non-limiting UIs 1600 and 1700 according to one or more embodiments described herein, which can display a patient's medical history. Figure 18 A diagram illustrating an example non-limiting UI 1800 according to one or more embodiments described herein, which displays a decision-maker-specific view of a patient's medical journey. For brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments have been omitted.

[0203] Unrestricted UI 1600 and unrestricted UI 1700 can be similar to Figure 3 The non-restrictive UI 300. The toggle switch 1610 allows terminal entities (e.g., hardware, software, machines, AI, neural networks, and / or users) to... Figure 16 and Figure 17The default view of the patient's medical history shown is switched to Figure 18 The illustrated cancer-specific view (e.g., "Oncology Focus"). For example, an unrestricted UI 1800 could display sections of patient A's medical history that focus on oncology-related events and clinical decisions. Clearly, the default view could display numerous data points that might confuse oncologist A, who is only concerned with patient A's cancer treatment. In contrast, a cancer-specific view can provide a user experience (UX) focused on oncology by highlighting the most useful aspects of cancer treatment, and help oncologist A learn from past clinical decisions and make more informed clinical decisions in the future.

[0204] Figure 19 A diagram illustrating an example non-limiting UI 1900 according to one or more embodiments described herein, which displays a cancer-specific view of a patient's medical history. For brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments have been omitted.

[0205] Continue to refer to at least Figure 1 and Figure 18 The non-limiting UI 1900 is intended to illustrate additional aspects of the non-limiting UI 1800. In one or more embodiments, event 1902 may be a decision point detected by the first AI component 238, and event 1904 may be a result of event 1902, wherein event 1904 may be detected by the second AI component 240. Events 1904 and 1906 may describe the main progress of event 1902. For example, event 1904 may describe whether patient A adheres to the clinical decision of event 1902, and event 1906 may describe another clinical decision made by oncologist A for patient A based on event 1904. In this respect, Figure 19A diagram also illustrates a non-restrictive process 1920 that oncologist A can use to assess the progress of event 1902. For example, at 1922, oncologist A can assess the clinical decision associated with event 1902; at 1924, oncologist A can assess how the clinical decision progresses based on event 1904 (e.g., whether patient A adhered to the clinical decision); and at 1926, oncologist A can identify valuable learning content based on events 1902 and 1904. Events 1908 and 1910 can represent clinical decisions associated with the medical history of other patients (e.g., cohort 216), clinical decisions made by a specialist (e.g., a cancer expert) for their patients, clinical decisions from previously performed medical research, etc. For example, event 1908 can represent a clinical decision associated with a first medical history included in cohort 216, and event 1908 can represent a clinical decision associated with a second medical history included in cohort 216. Events 1908 and 1910 can be displayed on the unrestricted UI 1900 via a branch path by display component 236, as shown below. Figure 19 As illustrated, the branching paths can be generated by a suitable algorithm. Generally, display component 236 can display the corresponding medical history of the relevant patient included in queue 216 on UI 1900 via branching paths branching from decision points associated with the patient's medical history, such that the branching paths highlight alternative progressions of the patient's medical history resulting from alternative clinical decisions rather than those associated with the decision points. Events 1908 and 1910 can assist oncologist A in seeing how patient A's medical history might progress differently if oncologist A made different clinical decisions.

[0206] As described elsewhere in this document, display component 236 can visually distinguish decision points from other points on the patient's timeline, for example, by making decision points larger than other points, applying different colors to decision points, or otherwise emphasizing decision points. Therefore, UI 1900 can show the actual past path of the patient's timeline as well as other potential paths that the decision-maker might have taken. Figure 19 In the diagram, solid lines highlight a patient's medical history based on clinical decisions made by decision-makers, while dashed lines highlight other potential clinical decision and medical history options.

[0207] As described elsewhere in this document, the dropdown menu 1912 can be used by the end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user) to generate visualizations 222, view ranking lists 220, compare a patient's medical history with past research, view guidance from the institution, etc. Additionally, the end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user) can select the "What We Learned" button at 1914 to view an AI-based report 224, and the end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user) can select the "Mark Insight Moments" button at 1916 to mark valuable decision points as insights for future reference. (See reference...) Figure 2A As described, display component 236 can be used as an interactive module that enables an end entity (e.g., hardware, software, machine, AI, neural network, and / or user) to select options, decision points, drop-down menus, etc., on the UI via a cursor, touchscreen, voice command, or other suitable function. In one or more embodiments, a generative AI model employed by the first AI component 238 can automatically suggest anticipated moments of insight to the end entity (e.g., hardware, software, machine, AI, neural network, and / or user).

[0208] Figure 20 Examples of non-restrictive queue analysis visualizations of 2000 and 2010 based on one or more embodiments described herein are illustrated. For brevity, repeated descriptions of similar elements and / or processes employed in the respective embodiments have been omitted.

[0209] The Unrestricted Cohort Analysis Visualization Representation 2000 shows a queue screen, which is also shown in the Unrestricted Cohort Analysis Visualization Representation 2010 along with a second queue screen. Such queue screens can display information about multiple patients, such as how patient behavior may deviate from standard expected behavior. (Continue to reference...) Figure 2A In one or more embodiments, display component 236 may display a queue screen similar to the queue screen shown in the non-limiting queue analysis visualization representations 2000 and 2010 on the UI, for example, as a pop-up screen or window that can be adopted by an end entity (e.g., hardware, software, machine, AI, neural network, and / or user) to determine normal patient behavior when comparing a patient’s medical history with oncology guidance or with the healthcare outcomes of other patients treated by various renowned physicians.

[0210] Figure 21 Examples of non-limiting patient timelines 2100, 2110, and 2120 are illustrated, showing various aspects of a patient's medical history. For brevity, repeated descriptions of similar elements and / or processes used in the corresponding embodiments have been omitted.

[0211] Unrestricted patient timelines 2100, 2110, and 2120 are intended to illustrate patient timelines presented by existing software. Clearly, unrestricted patient timelines 2100, 2110, and 2120 do not show decision-maker-specific views or toggles, such as those presented by embodiments of this disclosure, to assist a physician or another end-user entity (e.g., hardware, software, machine, AI, neural network, and / or user) in switching from a default view to a more focused view of the patient's medical history.

[0212] Figure 22 A flowchart illustrating an example non-limiting method 2200 according to one or more embodiments described herein is provided, which can present a decision-maker-specific visualization of a patient's medical history and generate alternative treatment plans that can be used for subsequent treatment of the disease. For the sake of brevity, repeated descriptions of similar elements and / or processes used in the respective embodiments are omitted.

[0213] At 2202, the non-limiting method 2200 may include access to first data by a system operatively coupled to the processor (e.g., by data access component 232), the first data including first patient data associated with a patient, second patient data associated with one or more additional patients, a set of clinical rules, and treatment information related to the patient's medical condition.

[0214] At 2204, the non-limiting method 2200 may include access to second data by a system (e.g., by data access component 232), the second data including one or more results generated by clinical decisions associated with a medical condition.

[0215] At 2206, the non-limiting method 2200 may include one or more cohorts of a patient’s medical history identified by a system (e.g., by a data generation component 234) based on analysis of the first and second data.

[0216] At 2208, the non-limiting method 2200 may include generating third data by a system (e.g., by data generation component 234) based at least on the first data, the second data, and the patient’s medical history, the third data including at least two alternative treatment plans that can be used for subsequent treatment of the medical condition.

[0217] At 2210, the non-limiting method 2200 may include displaying a patient timeline on the UI of a device by a system (e.g., by display component 236), the patient timeline including a time view of the patient's medical condition-specific medical history.

[0218] At 2212, the non-limiting method 2200 may include highlighting the clinical decision and the one or more results on the UI via a bounding box by the system (e.g., by display component 236).

[0219] At 2214, the non-limiting method 2200 may include displaying a visual connection between a clinical decision and one or more outcomes on a UI by a system (e.g., by display component 236) to highlight the progress of a patient’s medical course based on the clinical decision.

[0220] At 2216, the non-limiting method 2200 may include a visualization of one or more cohorts of a patient’s medical history displayed on a UI by a system (e.g., by display component 236), wherein the visualization is influential in evaluating the at least two alternative treatment plans in reference cohort results, and wherein the visualization can be adopted by a medical device to automatically perform actions related to subsequent treatment of the medical condition based on at least one cohort of the patient’s medical history, provided that the at least one cohort meets a defined set of criteria.

[0221] Figure 23 A flowchart illustrating an example non-limiting method 2300 according to one or more embodiments described herein is provided. This method may employ software and AI to present a decision-maker-specific visualization of a patient's medical history and generate alternative treatment plans that can be used for subsequent treatment of the disease. For the sake of brevity, repeated descriptions of similar elements and / or processes used in the respective embodiments are omitted.

[0222] At 2302, the non-limiting method 2300 may include access to first data by a system operatively coupled to the processor (e.g., by data access component 232), the first data including first patient data associated with a patient, second patient data associated with one or more additional patients, a set of clinical rules, and treatment information related to the patient's medical condition.

[0223] At 2304, the non-limiting method 2300 may include access to second data by a system (e.g., by data access component 232), the second data including one or more results generated by clinical decisions associated with a medical condition.

[0224] At 2306, the non-limiting method 2300 may include analyzing the first and second data by a system (e.g., by a data generation component 234) via generative AI.

[0225] At 2308, the non-limiting method 2300 may include one or more cohorts of a patient’s medical history identified by a system (e.g., by a data generation component 234) via generative AI based on analysis of first and second data.

[0226] At 2310, the non-limiting method 2300 may include generating third data by a system (e.g., by a data generation component 234) via generative AI based at least on the first data, the second data, and the patient’s medical history, the third data including at least two alternative treatment plans that can be used for subsequent treatment of the medical condition.

[0227] At 2312, the non-limiting method 2300 may include displaying a patient timeline on the UI of a device by a system (e.g., by display component 236), the patient timeline including a time view of the patient's medical condition-specific medical history.

[0228] At 2314, the non-limiting method 2300 may include visualization of the patient’s medical history in one or more cohorts displayed on a UI by a system (e.g., by display component 236), wherein the visualization is influential in assessing the at least two alternative treatment plans in reference cohort outcomes.

[0229] At 2316, the non-limiting method 2300 may include determining by the system (e.g., by the display component 236) whether a new queue (i.e., a queue of patients’ medical histories) has been identified / available.

[0230] If so, then at 2318, non-restrictive method 2300 may include updating the visualization by the system (e.g., by display component 236) to include the new queue.

[0231] If not, then at 2320, the non-limiting method 2300 may include monitoring of new queues by the system (e.g., by display component 236).

[0232] In various instances, machine learning algorithms or models may be implemented in any suitable manner to facilitate any suitable aspect described herein. To facilitate some of the machine learning aspects described above in various implementations, consider the following discussion of artificial intelligence (AI). The various implementations described herein may employ AI to facilitate the automation of one or more features or functionalities. These components may employ various AI-based schemes to perform the various implementations / examples disclosed herein. To provide or contribute to the numerous determinations described herein (e.g., determination, detection, inference, accounting, prediction, prognosis, estimation, derivation, forecasting, detection, computation), the components described herein may examine the entirety or a subset of the data to which they have been granted access and may provide inference about or determine the state of a system or environment from a set of observations captured via events or data. For example, determination may be used to identify a particular context or action, or to generate a probability distribution of states. These determinations may be probabilistic; that is, the calculation of the probability distribution of states of interest is based on consideration of data and events. Determination may also refer to techniques used to compose higher-level events from a collection of events or data.

[0233] Such determinations can lead to the construction of new events or actions from observed events or a collection of stored event data, regardless of whether the events are closely related in time, and regardless of whether the events and data come from one or more event and data sources. The components disclosed herein can be combined to perform automatic or deterministic actions related to the claimed subject matter using various classification schemes or systems (e.g., explicitly trained (e.g., via training data) and implicitly trained (e.g., via observed behavior, preferences, historical information, received external information, etc.)) to employ. Therefore, classification schemes or systems can be used to automatically learn and perform multiple functions, actions, or determinations.

[0234] The classifier can take the input attribute vector z=(z1, z2, z3, z4, z) as an input vector. nThis maps the input to a confidence level that it belongs to a certain category, as shown by f(z) = confidence level (category). Such classification can employ probability-based or statistical analysis (e.g., analyzing utility and cost considerations) to determine the action to be automated. Support Vector Machines (SVMs) are an example of a usable classifier. SVMs operate by finding a hypersurface in the space of possible inputs, where the hypersurface attempts to separate triggering criteria from non-triggering events. Intuitively, this makes the classification correct for test data that is close to but different from the training data. Other directed and undirected model classification methods include, for example, Naive Bayes, Bayesian networks, decision trees, neural networks, fuzzy logic models, or any of the probabilistic classification models that provide different independent patterns. Classification, as used in this paper, also includes statistical regression for developing priority models.

[0235] To provide additional context for the various implementation schemes described herein, Figure 24 The following discussion is intended to provide a brief general description of a suitable computing environment 2400 in which the various embodiments described herein can be implemented. While the embodiments have been described above in the general context of computer-executable instructions that can run on one or more computers, those skilled in the art will recognize that these embodiments may also be implemented in combination with other program modules or as a combination of hardware and software.

[0236] Typically, program modules include routines, programs, components, data structures, etc., that perform specific tasks or implement specific abstract data types. Furthermore, those skilled in the art will understand that the methods of this invention can be practiced with other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframe computers, Internet of Things (IoT) devices, distributed computing systems, and personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, each operatively coupled to one or more associated devices.

[0237] The embodiments illustrated in this paper can also be practiced in a distributed computing environment where a specific task is performed by a remote processing device linked via a communication network. In a distributed computing environment, program modules can reside on both local and remote memory storage devices.

[0238] Computing devices typically include a variety of media, which may include computer-readable storage media, machine-readable storage media, or communication media, wherein the two terms are used interchangeably herein, as described below. A computer-readable storage medium or a machine-readable storage medium can be any available storage medium accessible by a computer, and includes volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, a computer-readable storage medium or a machine-readable storage medium can be implemented in conjunction with any method or technology used for storing information, such as computer-readable or machine-readable instructions, program modules, structured data, or unstructured data.

[0239] Computer-readable storage media may include, but is not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, optical disc read-only memory (CD-ROM), digital versatile disc (DVD), Blu-ray disc (BD) or other optical disc storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, solid-state drives or other solid-state storage devices, or other tangible or non-transitory media that can be used to store desired information. In this regard, the terms “tangible” or “non-transitory” used herein to describe storage devices, memories, or computer-readable media should be understood to exclude only the propagation of transient signals themselves as a modifier, and do not waive any rights enjoyed with respect to all standard storage devices, memories, or computer-readable media other than the propagation of transient signals themselves.

[0240] Computer-readable storage media can be accessed by one or more local or remote computing devices, for example, via access requests, queries or other data retrieval protocols, to perform various operations with respect to the information stored on the media.

[0241] Communication media typically contain computer-readable instructions, data structures, program modules, or other structured or unstructured data in a data signal, such as a modulated data signal, a carrier wave, or other transmission mechanism, and include any information transmission or delivery medium. The terms "modulated data signal" or "signal" refer to a signal whose one or more characteristics are set or altered to encode information in one or more signals. By way of example and not limitation, communication media include wired media (such as wired networks or direct wired connections) and wireless media (such as acoustic, RF, infrared, and other wireless media).

[0242] Refer again Figure 24Example environment 2400 for implementing various embodiments of the aspects described herein includes a computer 2402, which includes a processing unit 2404, system memory 2406, and a system bus 2408. The system bus 2408 couples system components, including but not limited to system memory 2406, to the processing unit 2404. The processing unit 2404 can be any of a variety of commercially available processors. Dual microprocessors and other multiprocessor architectures may also be used as the processing unit 2404.

[0243] System bus 2408 can be any of several types of bus structures that can be further interconnected to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. System memory 2406 includes ROM 2410 and RAM 2412. The basic input / output system (BIOS) can be stored in non-volatile memory such as ROM, erasable programmable read-only memory (EPROM), or EEPROM, where the BIOS contains basic routines that facilitate, for example, transferring information between components within computer 2402 during startup. RAM 2412 may also include high-speed RAM, such as static RAM for caching data.

[0244] Computer 2402 also includes an internal hard disk drive (HDD) 2414 (e.g., EIDE, SATA), one or more external storage devices 2416 (e.g., floppy disk drive (FDD) 2416, memory stick or flash drive reader, memory card reader, etc.), and drives 2420 (e.g., solid-state drives, optical disc drives) capable of reading from or writing to disks 2422 (such as CD-ROMs, DVDs, BDs, etc.). Alternatively, in cases involving solid-state drives, disks 2422 are not included unless separate. Although the internal HDD 2414 is illustrated as being located within computer 2402, the internal HDD 2414 may also be configured for use outside of suitable infrastructure (not shown). Additionally, although not shown in environment 2400, solid-state drives (SSDs) may be used as a supplement to or replacement for HDD 2414. HDD 2414, external storage device 2416, and drive 2420 can be connected to system bus 2408 via HDD interface 2424, external storage interface 2426, and drive interface 2428, respectively. Interface 2424 for a specific implementation of the external drive may include at least one or both of Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 1394 interface technologies. Other external drive connection technologies are contemplated in the embodiments described herein.

[0245] The drive and its associated computer-readable storage medium provide non-volatile storage of data, data structures, computer-executable instructions, etc. For computer 2402, the drive and storage medium are adapted to store any data in a suitable digital format. Although the above description of computer-readable storage media refers to a corresponding type of storage device, those skilled in the art will understand that other types of computer-readable storage media (whether currently existing or developed in the future) can also be used in the example operating environment, and furthermore, any such storage medium may contain computer-executable instructions for performing the methods described herein.

[0246] Multiple program modules may be stored in the drive and RAM 2412, including an operating system 2430, one or more application programs 2432, other program modules 2434, and program data 2436. All or part of the operating system, application programs, modules, or data may also be cached in RAM 2412. The systems and methods described herein can be implemented using various commercially available operating systems or combinations of operating systems.

[0247] Computer 2402 may optionally include emulation technology. For example, a hypervisor (not shown) or other intermediate device may emulate the hardware environment of operating system 2430, and the emulated hardware may optionally be different from that of computer 2430. Figure 24 The hardware illustrated herein. In this implementation, operating system 2430 may include one of a plurality of virtual machines (VMs) hosted at computer 2402. Furthermore, operating system 2430 may provide a runtime environment, such as the Java Runtime Environment or the .NET Framework, to application 2432. A runtime environment is a consistent execution environment that allows application 2432 to run on any operating system that includes that runtime environment. Similarly, operating system 2430 may support containers, and application 2432 may be in the form of containers of lightweight, standalone, executable software packages, including, for example, application code, runtime, system tools, system libraries, and settings.

[0248] Users can input commands and information into computer 2402 through one or more wired / wireless input devices (e.g., keyboard 2438, touchscreen 2440, and pointing devices such as mouse 2442). Other input devices (not shown) may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls or other remote controls, joysticks, virtual reality controllers or virtual reality headsets, gamepads, styluses, image input devices (e.g., cameras), gesture sensor input devices, visual motion sensor input devices, emotion or face detection devices, biometric input devices (e.g., fingerprint or iris scanners), etc. These and other input devices are often connected to processing unit 2404 through input device interface 2444, which may be coupled to system bus 2408, but these and other input devices may also be connected through other interfaces (e.g., parallel ports, IEEE 1394 serial ports, game ports, USB ports, IR interfaces, BLUETOOTH). ® (Interfaces, etc.) connections.

[0249] Monitor 2446 or other types of display devices can also be connected to system bus 2408 via an interface such as video adapter 2448. In addition to monitor 2446, the computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc.

[0250] Computer 2402 can operate in a networked environment using a logical connection to one or more remote computers (such as remote computer 2450) via wired or wireless communication. Remote computer 2450 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer-to-peer device, or other public network node, and typically includes many or all of the elements described relative to computer 2402, but for simplicity, only memory / storage device 2452 is illustrated. The depicted logical connection includes wired / wireless connectivity to a local area network (LAN) 2454 or a larger network (e.g., a wide area network (WAN) 2456). Such LAN and WAN networking environments are common in offices and companies and facilitate enterprise-wide computer networks (such as intranets), all of which can be connected to global communications networks (e.g., the Internet).

[0251] When used in a LAN networking environment, computer 2402 can connect to local network 2454 via a wired or wireless communication network interface or adapter 2458. Adapter 2458 facilitates wired or wireless communication with LAN 2454, which may also include a wireless access point (AP) configured thereon for communication with adapter 2458 in wireless mode.

[0252] When used in a WAN networking environment, computer 2402 may include modem 2460, or may be connected to a communication server on WAN 2456 via other components (such as via the Internet) for establishing communication over WAN 2456. Modem 2460, which may function as an internal or external device and as a wired or wireless device, may be connected to system bus 2408 via input device interface 2444. In a networking environment, program modules depicted relative to computer 2402 or parts thereof may be stored in remote memory / storage device 2452. It should be understood that the network connections shown are examples, and other components for establishing communication links between computers may be used.

[0253] When used in a LAN or WAN networking environment, computer 2402 can access cloud storage systems or other network-based storage systems, such as, but not limited to, network virtual machines that provide one or more aspects of information storage or processing, as a supplement to or alternative to external storage device 2416 as described above. Typically, the connection between computer 2402 and the cloud storage system can be established, for example, via adapter 2458 or modem 2460 through LAN 2454 or WAN 2456. When computer 2402 is connected to an associated cloud storage system, external storage interface 2426 can manage the storage provided by the cloud storage system by means of adapter 2458 or modem 2460, just as with other types of external storage devices. For example, external storage interface 2426 can be configured to provide access to cloud storage sources as if those cloud storage sources were physically connected to computer 2402.

[0254] Computer 2402 is operable to communicate with any wireless device or entity located wirelessly, such as a printer, scanner, desktop or portable computer, portable data assistant, communications satellite, any equipment or location associated with a wirelessly detectable tag (e.g., telephone booth, newsstand, store shelf, etc.), and telephone. This may include Wi-Fi and BlueTouch. ® Wireless technology. Therefore, communication can be a predefined structure like a regular network, or simply self-organizing communication between at least two devices.

[0255] Figure 25This is a schematic block diagram of a sample computing environment 2500 to which the disclosed subject matter can interact. The sample computing environment 2500 includes one or more clients 2510. Clients 2510 can be hardware or software (e.g., threads, processes, computing devices). The sample computing environment 2500 also includes one or more servers 2530. Servers 2530 can also be hardware or software (e.g., threads, processes, computing devices). For example, server 2530 can accommodate threads to perform transformations by employing one or more embodiments as described herein. One possible communication between client 2510 and server 2530 can be in the form of data packets suitable for transfer between two or more computer processes. The sample computing environment 2500 includes a communication framework 2550 that can be used to facilitate communication between client 2510 and server 2530. Client 2510 is operatively connected to one or more client data repositories 2520, which can be used to store information local to client 2510. Similarly, server 2530 is operatively connected to one or more server data repositories 2540, which can be used to store information locally on server 2530.

[0256] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, or a wireless network). The network may include copper transmission cables, optical fiber transmission, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them for storage in a computer-readable storage medium within the suitable computing / processing device. The computer-readable program instructions used to implement the various embodiments can be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​(including object-oriented programming languages ​​such as Smalltalk, C++, etc.) and procedural programming languages ​​such as the "C" programming language or similar programming languages. Computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the internet through an internet service provider). In some implementations, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions by utilizing state information from the computer-readable program instructions to personalize the electronic circuits to perform various aspects.

[0257] The various aspects described herein are illustrated by flowchart illustrations or block diagrams of methods, apparatus (systems), and computer program products according to various embodiments. It should be understood that each block of the flowchart illustrations or block diagrams, and combinations of blocks in the flowchart illustrations or block diagrams, can be implemented by computer-readable program instructions. These computer-readable program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executable via the processor of the computer or other programmable data processing apparatus, create components for implementing the functions / actions specified in one or more blocks of the flowchart or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that instructs a computer, programmable data processing apparatus, or other device to function in a particular manner, such that the computer-readable storage medium having the instructions stored therein includes an article of manufacture comprising instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart or block diagram. Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operations to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the instructions that execute on the computer, other programmable apparatus or other device implement the functions / actions specified in one or more boxes of a flowchart or block diagram.

[0258] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible specific implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions indicated in the blocks may not occur in the order shown in the figures. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or sometimes they may be executed in reverse order, depending on the functionality involved. It will also be noted that each block illustrated in a block diagram or flowchart, and combinations of blocks illustrated in a block diagram or flowchart, may be implemented by a dedicated hardware-based system that performs the specified function or action or implements a combination of dedicated hardware and computer instructions.

[0259] Although the subject matter has been described above in the general context of computer-executable instructions of a computer program product running on one or more computers, those skilled in the art will recognize that this disclosure may also be implemented in conjunction with other program modules. Typically, program modules include routines, programs, components, data structures, etc., that perform a specific task or implement a specific abstract data type. Furthermore, those skilled in the art will understand that various aspects can be practiced using other computer system configurations, including single-processor or multi-processor computer systems, small computing devices, mainframe computers, and computers, handheld computing devices (e.g., PDAs, telephones), microprocessor-based or programmable consumer or industrial electronics, etc. The illustrated aspects can also be practiced in a distributed computing environment in which tasks are performed by remote processing devices linked via a communication network. However, some (if not all) aspects of this disclosure can be practiced on a standalone computer. In a distributed computing environment, program modules may reside on both local and remote memory storage devices.

[0260] As used herein, the terms “component,” “system,” “platform,” “interface,” etc., may refer to or include computer-related entities or entities associated with an operator having one or more specific functionalities. Entities disclosed herein may be hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to, a process, processor, object, executable file, execution thread, program, or computer running on a processor. By way of example, both an application running on a server and the server itself can be components. One or more components may reside within a process or execution thread, and components may be located on a single computer or distributed across two or more computers. In another example, a corresponding component may execute on various computer-readable media on which various data structures are stored. Components may communicate via local or remote processes, such as based on signals having one or more data packets (e.g., data from one component that interacts with another component in a local system, a distributed system, or a network (such as the Internet with other systems) via signals). As another example, a component may be a device having specific functionalities provided by mechanical parts operated by electrical or electronic circuitry, which is operated by software or firmware applications executed by a processor. In such cases, the processor may be internal or external to the device and may execute at least a portion of a software or firmware application. As another example, a component may be a means of providing specific functionality through electronic components rather than mechanical parts, wherein the electronic components may include a processor or other components for executing software or firmware that at least partially endows the electronic components with functionality. In one aspect, the component may be emulated, for example, via a virtual machine within a cloud computing system.

[0261] Furthermore, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless otherwise specified or explicitly stated from the context, "X adopts A or B" is intended to mean any natural inclusive permutation. That is, if X adopts A; X adopts B; or X adopts both A and B, then "X adopts A or B" is satisfied in any of the foregoing cases. As used herein, the term "and / or" is intended to have the same meaning as "or". Furthermore, unless otherwise specified or explicitly stated from the context as to be directed to the singular form, the articles "a" and "an" used in this specification and figures should generally be understood to mean "one or more". As used herein, the terms "example" or "exemplary" are used to mean used as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited to such examples. Additionally, any aspect or design described herein as an "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor does it exclude equivalent exemplary structures and techniques known to those skilled in the art.

[0262] The disclosure herein describes non-limiting examples. For ease of description or explanation, various parts of the disclosure herein use the terms "each," "every," or "all" when discussing various examples. Such use of the terms "each," "every," or "all" is non-limiting. In other words, when the disclosure herein provides a description applicable to "each," "every," or "all" of certain objects or components in some particular object or component, it should be understood that this is a non-limiting example, and it should also be understood that in various examples, such a description may apply to fewer than "each," "every," or "all" of the particular objects or components.

[0263] The foregoing description includes only examples of systems and computer-implemented methods. Of course, it is impossible to describe every conceivable combination of components or computer-implemented methods for the purposes of this disclosure, but many other combinations and arrangements are possible. Furthermore, when the terms “comprising,” “having,” or “possessing” are used in the detailed description, claims, appendices, and drawings, such terms are intended to have a similar inclusiveness to “comprising” as a transitional term in the claims.

[0264] Various embodiments have been described for illustrative purposes, but these descriptions are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent without departing from the scope and substance of the described embodiments. The terminology used herein is chosen to best illustrate the principles of the embodiments, the practical application of or improvement of technology available on the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A system comprising: Memory (206), the memory storing computer-executable components; and Processor (204), the processor executing the computer-executable component stored in the memory (206), wherein the computer-executable component includes: Data access component (232), the data access component: Access first data (212), the first data including first patient data associated with the patient, second patient data associated with one or more additional patients, a set of clinical rules, and treatment information related to the patient's medical condition, and Access second data (214), the second data including one or more results generated by clinical decisions associated with the medical condition; Data generation component (234), the data generation component: One or more cohorts (216) of the patient's medical history are identified based on the analysis of the first data (212) and the second data (214), and Third data (218) is generated based at least on the first data (212), the second data (214), and the one or more cohorts (216) of the patient's medical history, the third data including at least two alternative treatment plans that can be used for subsequent treatment of the medical condition; and Display component (236), the display component: The device displays a patient timeline on its user interface (UI), which includes a time view of the patient's medical history specific to the medical condition. The clinical decision and one or more outcomes are highlighted via bounding boxes on the user interface. The user interface displays a visual connection between the clinical decision and one or more outcomes to highlight the patient's medical course progression based on the clinical decision. A visualization (222) of one or more cohorts (216) of the patient's medical history is displayed on the user interface, wherein the visualization (222) is influential in evaluating the at least two alternative treatment plans in reference cohort results, and wherein the visualization (222) is capable of being adopted by a medical device to automatically perform actions related to the subsequent treatment of the medical condition based on at least one cohort of the one or more cohorts (216) of the patient's medical history, provided that the at least one cohort meets a defined set of criteria.

2. The system of claim 1, wherein the computer-executable component further comprises: A first artificial intelligence (AI) component (238) detects multiple decision points within the time view based on the first data (212), wherein each decision point represents a corresponding clinical decision for the patient, and wherein the clinical decision corresponds to a decision point within the time view.

3. The system of claim 2, wherein detecting the plurality of decision points comprises: The first set of decision points is identified by the planning search component (242) based on modifications within the treatment plan associated with the medical condition; The detection component (244) identifies the second set of decision points based on inputs associated with treatment decisions included in the treatment plan; The evaluation component (246) identifies the third set of decision points based on the set of clinical rules, wherein the set of clinical rules includes rules configured to detect and define clinical patterns; and The merging component (248) generates a list including the multiple decision points by merging the first set of decision points, the second set of decision points, and the third set of decision points.

4. The system of claim 3, wherein the computer-executable component further comprises: A second artificial intelligence (AI) component (240) detects the one or more results, wherein detecting the one or more results includes: The decision point associated with the clinical decision is selected by the selection component (250); A summary set of prompts is generated by the prompt generation component (252) to identify a set of events representing the consequences of the clinical decision; The summary set of prompts is input into a large language model (LLM) by the prompt generation component (252); and The merging component (248) analyzes the results generated by the large language model when processing the aggregated hint set.

5. The system of claim 2, wherein the one or more queues (216) identifying the patient's medical history comprise: The data generation component (234) summarizes the patient's medical history prior to the decision point; The data generation component (234) compares the patient's medical history with the corresponding medical history of the corresponding patient among the one or more additional patients; and The data generation component (234) selects a set of medical processes from the corresponding medical processes as one or more queues of the patient's medical processes based on relevant clinical criteria (216).

6. The system of claim 5, wherein the data generation component (234) further generates cost information describing the corresponding costs associated with the patient's medical course and the corresponding costs associated with the corresponding patient's medical course.

7. The system of claim 5, wherein the display component (236) further displays the corresponding medical history of the corresponding patient on the user interface via a branch path branching from the decision point, such that the branch path highlights alternative progress of the patient's medical history resulting from alternative clinical decisions.

8. The system of claim 1, wherein displaying the visualization (222) on the user interface comprises: The display component (236) outputs on the user interface the first results and outcome indicators of different choices of the first treatment plan associated with the corresponding queues in the one or more queues (216) of the patient's medical history.

9. The system of claim 1, wherein the data generation component (234) further generates a ranking list (220) of medical practitioners based on the first patient data and the treatment information, wherein the ranking list (220) of medical practitioners can be adopted by a terminal entity to explore a second treatment plan used by the medical practitioner to treat the medical condition, explore a second outcome associated with the second treatment plan, and contact the medical practitioner.

10. The system of claim 2, wherein the first artificial intelligence component (238) further detects one or more of the plurality of decision points as corresponding key moments indicating non-standard insights identified by the first artificial intelligence component (238) based on the corresponding clinical decision.

11. The system of claim 2, wherein the computer-executable component further comprises: A reporting component (254) generates an AI-based report (224) based on results associated with the corresponding clinical decision and recommendations for subsequent treatment. The AI-based report includes an interpretation of the information learned by the data generation component (234).

12. The system of claim 11, wherein the display component (236) highlights the results via visual indicators and scores displayed on the patient timeline on the user interface.

13. The system of claim 1, wherein the computer-executable component further comprises: A training component (256) trains the data generation component (234) to iteratively analyze the first data (212) and the second data (214) to obtain new information, and identifies a new cohort most relevant to the patient’s medical history at a given point in time based on the new information.

14. A computer-implemented method, comprising: The system accesses first data (212) operably coupled to the processor (204), the first data including first patient data associated with a patient, second patient data associated with one or more additional patients, a set of clinical rules, and treatment information related to the patient's medical condition; The system accesses second data (214), which includes one or more results generated by clinical decisions associated with the medical condition; The system analyzes the first data (212) and the second data (214) via generative artificial intelligence. The system identifies one or more cohorts (216) of the patient’s medical history based on the analysis of the first data (212) and the second data (214) by the generative artificial intelligence. The system generates third data (218) via the generative artificial intelligence based at least on the first data (212), the second data (214), and the one or more cohorts (216) of the patient's medical history. The third data includes at least two alternative treatment plans that can be used for subsequent treatment of the medical condition. The system displays a patient timeline on the device's user interface, the patient timeline including a time view of the patient's medical history specific to the medical condition; as well as The system displays visualizations (222) of one or more cohorts (216) of the patient’s medical history on the user interface, wherein the visualizations (222) are influential in evaluating the at least two alternative treatment plans in reference cohort results.

15. The computer-implemented method according to claim 14, further comprising: The system detects multiple decision points within the time view based on the first data (212) via the generative artificial intelligence, wherein each decision point represents a corresponding clinical decision for the patient, and wherein the clinical decision corresponds to a decision point within the time view.

Images