Patient pathway restructuring and aggregation

Abstract

A technique for patient data management includes obtaining patient history data from a database, the history data including a history of one or more diagnostic events, one or more treatment events, and clinical outcome events for each patient. For each patient, based on the history data, a computing system generates a patient pathway including a graph including nodes for the one or more diagnostic events, the one or more treatment events, and the clinical outcome events. The computing system receives, via an interface, one or more criteria for selecting a subset of the patient pathways for the patient. The computing system selects a graph representing the subset of the patient pathways based on the one or more criteria. The computing system aggregates the subset of the patient pathways into a merged graph. The computing system displays the merged graph in the interface.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 187,211, filed May 11, 2021, the entire contents of which are incorporated herein by reference. [Background technology]

[0002] background A medical data management system stores information associated with patient events and records. These records may reflect a patient's sequence of diagnoses, treatments, and / or medical outcomes. Such records can provide information about why, when, where, and how a patient accesses health care.

[0003] Clinical guidelines generally refer to documents intended to guide decisions and standards regarding diagnosis, management, and treatment in specific areas of healthcare. Clinical guidelines may provide the latest data on prevention, diagnosis, prognosis, treatment including dosage, risks / benefits for specific diseases, and cost-effectiveness of treatments. Guidelines may identify all available (or known) decision / treatment options and their possible outcomes at a particular stage of disease. Based on a patient's current condition, clinicians can refer to the guidelines to obtain different treatment options and possible outcomes and decide on a treatment option for the patient.

[0004] While clinical guidelines can provide a rationale for prescribing a particular treatment to a patient, they typically do not provide insight into how to improve patient care. For example, clinical guidelines can provide different treatment options and possible outcomes, but do not provide insight into real-world patient outcomes. Summary of the Invention

[0005] Quick Overview Disclosed herein is a technique for reconstructing and aggregating patient pathways for multiple patients based on the patient's medical history data. For each patient, the medical history data may include a diagnostic event in which the patient was initially diagnosed with a disease, one or more treatment events following the diagnostic event, and a historical sequence of clinical outcome events over time. The diagnostic events may include, for example, biomarker testing events, laboratory testing events, etc. Additionally, the historical sequence may also include one or more post-treatment follow-up testing events. The patient pathway reconstruction and aggregation system may retrieve patient medical history data from a database and generate a graph representing the patient pathway for each patient. The graph may include multiple nodes, including a start node, an end node, and nodes representing the diagnostic event, one or more treatment events, and clinical outcome events between the start node and the end node, with the nodes connected by edges.

[0006] The patient pathway reconstruction and aggregation system may also receive input via the interface to select a subset of the patient pathway for display on the interface. The input may also include one or more criteria for selecting the subset of the patient pathway. Based on the input, the patient pathway reconstruction and aggregation system may select a subset of graphs representing the subset of the patient pathway and merge the subset of graphs into a merged graph. The input may be received via a graphical user interface connection.

[0007] The system can select a subset of graphs to create a merged graph based on various criteria received as part of the instructions. For example, the criteria could specify the number of most common patient pathways shared by patients (e.g., 4, 8, 10, etc.). The system can then merge the number of most common patient pathways into the merged graph. As another example, the input may include criteria for selecting one or more common treatment events, such as treatment events shared by a threshold number / percentage of patients. The system can then select a subset of patient pathways with common treatment events that meet the criteria. As another example, the system can select a subset of graphs based on clusters of patients with similar characteristics. As another example, the system can merge events into higher-level categories.

[0008] In some examples, the system may generate additional analytical data for subsets of patient pathways to provide clinical and operational insights into the clinical care received by the patient. For example, the system may generate various metrics for each subset of patient pathways and display the metrics in the interface. As another example, the system may retrieve medical history data for subsets of patients that share a particular treatment event. Based on the medical history data for the subsets of patients, additional analyses such as cumulative survival probability, clinical outcome prediction, and next treatment event prediction may be performed, and the results of the analysis may also be displayed in the interface. In some examples, discriminative treatment event nodes associated with the mutually exclusive subsets of patients may be identified and selected. Based on the node selection, medical history data for the mutually exclusive subsets of patients may also be accessed and compared.

[0009] These and other exemplary embodiments are described in detail below. For example, other embodiments are directed to systems, devices, and computer-readable media associated with the methods described herein.

[0010] A better understanding of the nature and advantages of embodiments of the present disclosure may be obtained with reference to the following detailed description and accompanying drawings.

[0011] The detailed description is made with reference to the accompanying drawings. [Brief explanation of the drawings]

[0012] [Figure 1A] 1 is an example of a patient pathway. [Figure 1B-1] This is an example of a clinical guideline. [Figure 1B-2] This is an example of a clinical guideline. [Figure 1B-3] This is an example of a clinical guideline. [Figure 1B-4] This is an example of a clinical guideline. [Figure 2] 1 is an example of a route reconstruction and aggregation system in accordance with certain aspects of the present disclosure. [Figure 3A] 3 illustrates an example of the operation of the internal components of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 3B] 3 illustrates an example of the operation of the internal components of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 3C] 3 illustrates an example of the operation of the internal components of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 3D] 3 illustrates an example of the operation of the internal components of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 3E] 3 illustrates an example of the operation of the internal components of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 3F] 3 illustrates an example of the operation of the internal components of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 4A] 3 illustrates an example of the operation of the internal components of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 4B]3 illustrates an example of the operation of the internal components of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 5A] 3 illustrates an example of the operation of the internal components of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 5B] 3 illustrates an example of the operation of the internal components of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 6A] 3 illustrates an example of the operation of a graphical user interface of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 6B-1] 3 illustrates an example of the operation of a graphical user interface of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 6B-2] 3 illustrates an example of the operation of a graphical user interface of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 6C] 3 illustrates an example of the operation of a graphical user interface of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 6D] 3 illustrates an example of the operation of a graphical user interface of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 6E] 3 illustrates an example of the operation of a graphical user interface of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 6F] 3 illustrates an example of the operation of a graphical user interface of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 6G] 3 illustrates an example of the operation of a graphical user interface of the route reconstruction and aggregation system of FIG. 2 in accordance with certain aspects of the present disclosure. [Figure 7] 10A-10C illustrate examples of methods for generating and displaying patient pathways according to certain aspects of the present disclosure. [Figure 8]FIG. 1 illustrates an exemplary computer system that can be utilized to implement the techniques disclosed herein. DETAILED DESCRIPTION OF THE INVENTION

[0013] Detailed Description A patient pathway can refer to the sequence of a patient's diagnoses, treatments, and medical outcomes. A patient pathway can provide information about why, when, where, and how a patient accesses healthcare. A patient's patient pathway can be developed based on one or more treatments selected for the patient, which can determine the patient's clinical outcome (e.g., survival or death). The selection of a treatment for a patient is typically based on the patient's medical condition and clinical guidelines for treating the patient's medical condition.

[0014] Clinical guidelines typically provide the latest data regarding prevention, diagnosis, prognosis, treatment including dosage, risks / benefits, and cost-effectiveness of treatments for a particular disease. Guidelines may also identify all available (or known) decision / treatment options and their outcomes at a particular stage of disease or treatment, and may identify different options / outcomes at different stages of disease / treatment. Based on a patient's current condition, clinicians can refer to the guidelines to obtain different treatment options and possible outcomes and determine treatment options for the patient. Examples of clinical guidelines may include the National Comprehensive Cancer Network® (NCCN) Clinical Practical Guidelines in Oncology.

[0015] Although clinical guidelines can provide a basis for prescribing a specific treatment for a patient, their usefulness in improving the clinical care provided to patients can be limited for several reasons. Specifically, although clinical guidelines can list a number of treatment options and their outcomes, the guidelines typically do not provide insight into which treatment option is best for a particular patient. For example, guidelines typically do not provide comparisons of various metrics, such as survival rates, costs, and durations, between different treatment and / or surgical options to enable clinicians to select the best treatment / surgical regimen for a patient. Furthermore, guidelines do not provide information for gaining clinical and operational insights. For example, clinicians cannot gain clinical insights, such as identifying unmet needs in clinical care or potential deviations from clinical guidelines. Furthermore, clinicians cannot gain operational insights, such as identifying inefficiencies in clinical workflow or opportunities for optimizing resource management.

[0016] Disclosed herein is a technique for reconstructing and aggregating patient pathways for multiple patients based on their historical medical data. For each patient, the historical medical data can include a historical sequence of (1) a diagnostic event (also referred to as a diagnosis event) corresponding to diagnosing the patient with a disease, (2) one or more treatment events following the diagnosis event, and (3) clinical outcome events. These events can be stored in terms of time (e.g., time-stamped). Treatment events can include, for example, therapeutic regimens, surgical regimens, etc., each of which can include the administration of one or more medications and / or surgical procedures over a period of time. Clinical outcome events can include, for example, survival or death at a given time point from diagnosis, which can be adjusted for the year of diagnosis based on a particular study period.

[0017] Specifically, the patient pathway reconstruction and aggregation system can retrieve patient history data from a database and generate a graph representing each patient's patient pathway. The graph can include multiple nodes, including a start node, an end node, and nodes representing a diagnosis event, one or more treatment events, and a clinical outcome event between the start node and the end node, with the nodes connected by edges. The graph can also represent temporal relationships between different events, with the node locations and edge directions based on the timing of the events reflected in the medical history data. In some examples, the patient pathway reconstruction and aggregation system can traverse the patient's medical history record, arranging the events in chronological order, creating a node for each event, and adding the nodes to the graph in chronological order.

[0018] The patient pathway reconstruction and aggregation system can also receive input via the interface to select a subset of a patient's patient pathway. The input can include one or more criteria for selecting the subset of the patient pathway. Based on the input, the patient pathway reconstruction and aggregation system can select a subset of graphs representing the subset of the patient pathway and merge the subset of graphs into a merged graph. The merging can include merging nodes from different graphs that represent the same type of diagnostic event, the same type of treatment event, or the same type of clinical outcome event into a merged node, and merging edges between two merged nodes into a single edge. There is useful information to be gained from viewing patient pathways at a population level (e.g., trends in patient outcomes, costs, and treatment times for different pathways). However, such visualizations are typically not useful due to the large amount of different patient data involved, resulting in a cluttered appearance from which it is difficult to discern meaning. By merging nodes that represent the same type of event, the graph is simplified, allowing clinicians to discern information useful for improving patient treatment.

[0019] Specifically, the system can determine that two nodes representing two diagnosis events for two patients represent the same type of diagnosis event, even if the two patients have the same diagnosis (e.g., the same type of cancer and the same stage), and merge the two nodes into a merged node representing the same type of diagnosis event. Furthermore, the system can determine that two nodes representing two treatment events for two patients represent the same type of treatment event, even if the two events have the same treatment / surgical regimen, and merge the two nodes into a merged node representing the same treatment event. Furthermore, the system can merge two nodes of the same type of clinical outcome event (e.g., survival or death) and merge the two nodes into a merged node representing the same clinical outcome event. In all of these cases, the two nodes can be merged regardless of whether the events represented by the nodes occur within the same or different time periods. In some examples, merging can also include clustering pairs of nodes representing different diagnosis / treatment events that are close in time and / or connected by a large number of edges, or nodes selected as part of input via a graphical user interface, into a single node.

[0020] The system can select a subset of graphs to create the merged graph based on various criteria received as part of the instructions. For example, the criteria may specify that all graphs or all patients are to be included in the merged graph. The criteria may specify that only a certain percentage of patients (e.g., 100%, 70%, 50%, 10%, etc.) are to be represented in the merged graph, and the system can select a subset of graphs representing the specified percentage of patients and include them in the merged graph. As another example, the criteria could specify the number of most common patient pathways shared by patients (e.g., 4, 8, 10, etc.). The system can merge the number of most common patient pathways into the merged graph.

[0021] In some examples, the input may include criteria for selecting one or more common treatment events, and the system may select a subset of patient pathways having one or more common treatment events. For example, the criteria may specify a specific treatment regimen or a specific surgical regimen, and the system may select patient pathways that have treatment event nodes of the specific treatment regimen or the specific surgical regimen as part of the subset of patient pathways. As another example, the criteria may specify a common treatment event shared by a threshold percentage of patients, or a threshold percentage of patients transitioning from a first common treatment event to a second common treatment event, and the system may select a subset of patient pathways having common treatment events that meet the criteria.

[0022] In some examples, the system can generate additional analytical data for a subset of patient pathways, which can provide clinical and operational insights into the clinical care a patient received. For example, the system can generate various metrics (e.g., total time, total cost, total number of patients, patient survival rate, deviations from clinical guidelines (if any), etc.) for each patient pathway and / or each event node represented in the merged graph and display the metrics in the interface. The metrics can be overlaid on the merged graph and / or displayed in separate graphs. Displaying the metrics enables comparisons between patient pathways and provides clinical and operational insights. For example, comparing survival rates across patient pathways can identify specific treatment / surgical regimens to improve survival rates. Furthermore, if patient pathways indicate that different treatments are prescribed for patients with the same medical condition, it can also identify potential deviations in clinical care from clinical guidelines. Furthermore, comparing the total cost and / or total time of patient pathways can also identify potential inefficiencies in clinical workflow and resource management.

[0023] In addition, the system can support the identification and analysis of different patient cohorts. For example, each common event node in the merged graph can be associated with a patient cohort, and historical data for a subset of patients can be accessed from a database through node selection in the interface. Various analyses, such as cumulative survival probability over time to generate Kaplan-Meier (KM) plots, can then be performed on the patient cohort's historical data. In some examples, discriminant treatment event nodes associated with mutually exclusive patient cohorts can be identified and selected. Based on the node selection, historical data for the mutually exclusive patient cohorts can also be accessed and compared. The system can further perform predictions based on the analysis results of the patient cohorts. For example, the system can predict the clinical outcome or next treatment step for a patient who has a treatment event in the merged graph but has not yet reached the end of their journey, based on the similarity between the patient and the patient cohort associated with the treatment event.

[0024] Using the disclosed technology, the system can reconstruct a patient pathway from a patient's medical history data and display the patient pathway in a merged graph along with various metrics within the interface. The system can also selectively display a subset of the patient pathway to the user based on user input, providing the user with a visualization of the patient pathway of interest. The system can also support exploratory analysis and hypothesis generation by displaying pathway metrics data (e.g., time, cost, outcomes, etc.), which can provide clinical and operational insights into the clinical treatment the patient received, all of which can improve the clinical care provided to future patients.

[0025] I. Patient Pathway Development Examples 1A and 1B show examples of a patient pathway 100 and a clinical guideline 120. A patient pathway can refer to the sequence of a patient's diagnosis, treatment, and medical outcomes. A patient pathway can provide information about why, when, where, and how a patient accesses healthcare. A clinical guideline generally refers to a document intended to guide decisions and standards regarding diagnosis, management, and treatment in a specific area of ​​healthcare. A clinical guideline may provide the latest data regarding prevention, diagnosis, prognosis, treatment including dosage, risk / benefit for specific diseases, and cost-effectiveness of treatment. Both patient pathways and clinical guidelines can be used by clinicians to evaluate a patient's treatment history, different treatment options, and possible outcomes, which can be used to determine treatment options for the patient.

[0026] A. Patient Pathway Examples FIG. 1A illustrates an example of a patient pathway 100. A patient pathway can refer to a patient's sequence of diagnoses, treatments, and clinical outcomes over time. As shown in FIG. 1A, the patient pathway 100 can begin with a clinician's disease diagnosis 102 at time T0. Based on the results of the disease diagnosis 102, the clinician can make a treatment regimen decision from one of treatment options 104a, 104b, or 104c, and the patient can begin the treatment regimen between times T1 and T2. Each treatment option can include therapy (e.g., prescription of a specific medication), surgery, or both. Optionally, the patient's condition after treatment can be analyzed, and in step 106 between times T3 and T4, the patient can continue the treatment regimen or receive a different treatment regimen. After the treatment regimen is completed, a patient medical outcome 108 can occur at time T5. The medical outcome can include, for example, the patient's survival or death within a specific period (e.g., one year) after the treatment is completed.

[0027] The selection of a treatment regimen for a patient may determine the patient's subsequent journey and is typically based on preconceived notions of what the patient's journey should be, often based on the patient's medical condition and clinical guidelines. Clinical guidelines may provide the latest data on prevention, diagnosis, prognosis, treatment including dosage, risks / benefits for specific diseases, and cost-effectiveness of treatments. Guidelines may identify all available (or known) decision / treatment options at a particular stage of disease and their potential outcomes. Based on the patient's current medical condition, clinicians can refer to the guidelines to obtain different treatment options and potential outcomes and decide on a treatment option for the patient.

[0028] B. Clinical Guidelines Examples 1B shows an example of a clinical guideline 120 for prostate cancer treatment, which may be drawn from the National Comprehensive Cancer Network® (NCCN) Oncology Clinical Practice Guidelines and Acute Coronary Syndrome (ACS) Guidelines. As shown in FIG. 1B, the clinical guideline 120 for prostate cancer treatment may include a diagnosis section 122 and a treatment section 124. The diagnosis section 122 may include various tests and biopsy procedures performed by general practitioners and urologists, and the treatment section 124 includes multiple alternative treatment options, such as radiation therapy, prostatectomy, and androgen deprivation therapy. The treatment options in the treatment section 124 may be selected based on the risk assessment from the diagnosis section 122.

[0029] As described above, while clinical guidelines 120 can provide a basis for prescribing a particular treatment for a prostate cancer patient, their usefulness in improving the clinical care provided to patients may be limited. Specifically, clinical guidelines 120 list a number of treatment options but do not provide insight into which treatment option is best for a particular patient. For example, clinical guidelines 120 do not provide comparisons of various metrics, such as survival rates, costs, and durations, between different treatment and / or surgical options to enable clinicians to select the best treatment / surgical regimen for a patient. Furthermore, clinical guidelines 120 do not provide information for gaining clinical and operational insights. For example, clinicians cannot gain clinical insights, such as identifying unmet needs in the clinical care of prostate cancer patients and identifying potential deviations from clinical guidelines 120. Furthermore, clinicians cannot gain operational insights, such as identifying inefficiencies in clinical workflow, opportunities for resource management optimization, and the like, from clinical guidelines 120. Such insights may be obtained from analyzing the patient pathways followed by a large population of patients, as described herein.

[0030] II. Patient Pathway Restructuring and Consolidation The patient pathway reconstruction and aggregation system can generate aggregated patient journeys that show the progression of multiple patients in a user-friendly manner. As described above, individual patient pathways and clinical guidelines are useful in evaluating treatment options for patients. However, individual pathways and clinical guidelines do not show how patients will respond at a population level. The patient pathway reconstruction and aggregation system solves these and other problems by generating streamlined, aggregated patient pathways that clinicians can interact with to drill down to various levels for useful data and analytics, which helps clinicians provide a better patient experience and better outcomes.

[0031] A. Patient Pathway Reconstruction and Aggregation System FIG. 2 illustrates an example of a patient pathway reconstruction and aggregation system 200 that can address at least some of the problems described above. The patient pathway reconstruction and aggregation system 200 can receive patient history data from a patient database 202 and reconstruct a patient pathway for each patient. Reconstructing individual pathways can show a patient's care journey over time, which can help provide better care to patients. These pathways can be aggregated at a population level, thereby providing useful information about trends among multiple patients. Various techniques are described for making these aggregated pathways useful and transparent to help provide useful information to clinicians. In some examples, the history data can also include an event log. The patient pathway reconstruction and aggregation system 200 can also receive input to selectively display a subset of the patient pathways.

[0032] The patient pathway reconstruction and aggregation system 200 may also calculate various metrics for each patient pathway, such as the total time and total cost incurred by the patient pathway, the total number of patients taking the patient pathway, the patient survival rate, the degree of deviation of the patient pathway from clinical guidelines, etc. The patient pathway reconstruction and aggregation system 200 may display metrics using a selected subset of patient pathways. The patient pathway reconstruction and aggregation system 200 may support additional analytics, such as identifying different patient cohorts and analyzing patient cohort characteristics, to provide more clinical and operational insights, support clinical predictions for patients who have not yet completed their clinical journey, etc.

[0033] 2 , the patient pathway reconstruction and aggregation system 200 may include a preprocessing module 203, a pathway reconstruction module 204, a clustering module 205, a common pathway module 206, a common event module 208, a pathway selection module 210, a merging module 212, an analysis module 220, and a graphical user interface 230. The pathway reconstruction module 204 may aggregate various data in the patient database 202, such as patient identifiers (IDs) 240 that uniquely identify different patients, patient medical history data 242, and patient financial records 244, and generate a graph representing the patient pathway for each patient. The graphical user interface 230 may display some or all of the graphs in a merged graph format along with various metrics associated with the displayed graphs.

[0034] B. Exemplary Medical History Data 3A and 3B show example medical history data 242 and financial records 244, as well as example graphs generated by pathway reconstruction module 204. As shown in FIG. 3A, medical history data 242 may be associated with a patient's patient identifier 240 (having a value X) and may include a data structure (e.g., a mapping table) that stores various events in the patient's medical history, as well as medical outcome events (e.g., survival / death), and the time of each event. For example, medical history data 242 may include an entry 302 that maps a disease A diagnosis event to time T0, an entry 304 that maps a treatment event labeled event 0 to time T1, an entry 306 that maps a treatment event labeled event 1 to time T2, and an entry 308 that maps a medical outcome event (which may be survival or death) to time T3. Each treatment event may include a treatment regimen, a surgical regimen, etc., each of which may include the administration of one or more medications and / or surgical procedures over a period of time represented by a mapped time (e.g., time T1, T2, etc.). Additionally, financial record 244 may include an entry 312 that maps treatment event event0 to a monetary cost represented by cost0, and an entry 314 that maps treatment event event1 to a cost represented by cost1.

[0035] The preprocessing module 203 can retrieve data from the patient database 202 and prepare the data for further processing. For example, the preprocessing module 203 can convert medical history data 242 and / or financial records 244 into a tabular format. The preprocessing module 203 can select variables of interest. The preprocessing module 203 can merge events into categories 395. For example, events associated with blood glucose levels, cancer staging, and biopsy results are all grouped into a higher-level category of biomarkers 395. Events associated with administering specific drugs and chemotherapy treatments are classified into a higher-level category of treatments 395. Within these higher-level categories 395, the preprocessing module can also identify lower-level categories 395. For example, within biomarkers, there are different types of biomarkers, such as radiological, molecular, histological, and physiological. The preprocessing module 203 can identify biomarker events within each category and group events together for both lower level categories 395 (e.g., molecular biomarkers) and / or higher level categories 395 (e.g., biomarkers).

[0036] The path reconstruction module 204 can traverse the medical history data 242 and the financial records 244 and generate a graph representing the patient path taken by the patient. The graph can include nodes representing events and directional edges connecting the nodes. The path reconstruction module 204 can traverse the medical history data 242 according to the chronological order of the events, create a node for each event, and add the nodes and edges to the graph according to the chronological order. The path reconstruction module 204 can also calculate various metrics, such as time and cost, by traversing the medical history data 242 and the financial records 244 and associate the metrics with the edges. The path reconstruction module 204 can also store the graph back in the path database 209.

[0037] C. Exemplary Patient Pathway Graph 3B illustrates an example of a graph 320 generated by the pathway reconstruction module 204 based on medical history data 242 and financial records 244. As shown in FIG. 3B, the graph 320 may be associated with a patient identifier (ID) 240 (having a value X) and may include a start node 322, event nodes including an event node 324 representing a disease A diagnosis event, an event node 326 representing a treatment event 0, an event node 328 representing a treatment event 1, an event node 330 representing a medical outcome event (survival or death), and an end node 332. The nodes are also connected by directional edges representing the temporal relationship between the nodes and the events. For example, the start node 322 is connected to the disease A diagnosis event node 324 by edge 342a. Treatment Event 0 node 326 is connected to Disease A Diagnosis event node 326 by edge 342b, Treatment Event 1 node 328 is connected to Treatment Event 0 node 326 by edge 342c, Medical Outcome event node 330 is connected to Treatment Event 1 node 328 by edge 342d, while End node 332 is connected to Medical Outcome event node 330 by edge 342e.

[0038] Each edge can be an exit edge of the previous node and an entrance edge of the subsequent node, and the direction of the edge indicates that the Disease A Diagnosis Event node 324 precedes the Treatment Event 0 node 326, the Treatment Event 1 node 328, and the Medical Outcome Event node 330. Some of the edges can also be associated with metrics such as time and cost. For example, edge 342b is associated with the transition time 345 elapsed between the Disease A Diagnosis Event and the Treatment Event 0, which can be represented by ΔTa (e.g., the difference between times T1 and T0 in FIG. 3A ). Edge 342c is associated with the transition time 347 elapsed between the Treatment Event 0 and the Treatment Event 1, which can be represented by ΔTb (e.g., the difference between times T2 and T1 in FIG. 3A ), and cost 349, which can be equal to Cost 0, the monetary cost associated with Treatment Event 0. Additionally, edge 342d is associated with a transition time 351 elapsed between treatment event 1 and the medical outcome event, which may be represented by ΔTc (e.g., the difference between times T3 and T2 in FIG. 3A ), and a cost 353, which may be equal to cost 1, the monetary cost associated with treatment event 1. The pathway reconstruction module 204 can then store the graph as pathway 355 in the pathway database 209.

[0039] D. Patient Pathway Clustering Referring back to FIG. 2 , the clustering module 205 can cluster patients based on the individual patient pathways generated by the pathway reconstruction module 204. In some implementations, the clustering module 205 clusters patients to build cohorts of patients with similar trajectories. Clusters are built based on similar sequences of events. For example, the clustering module clusters patients based on the order of events in the patient pathway graph, the time between one or more events in the patient pathway graph, or other factors that describe the patient's trajectory. As another example, individual patient pathways can be compared using natural language processing (NLP) techniques to provide a similarity score that is used to identify patients to cluster. For example, similar patient pathways can be identified by combining a baseline model, Word Mover's Distance (WMD), with dimensionality reduction techniques such as Hierarchical Density-Based Spatial Clustering of Applications with Noise (HDBSCAN) or Spectral clustering and Uniform Manifold Approximation and Projection (UMAP).

[0040] E. Common Pathway The common pathway module 206 can identify common patient pathways shared by multiple patients and generate metrics for the common patient pathways. In some embodiments, the common pathway module 206 identifies common patient pathways based on the clusters identified by the clustering module 205. Each cluster may be evaluated separately, simplifying the process because clusters contain patients with similar pathways. As described below, a subset of common pathways may be provided for display by the graphical user interface 230. The common pathway module 206 can determine that two patient pathways are identical if they have the same sequence of diagnosis events, treatment events, and medical outcome events, where the sequence is defined by the order of events in the graph representing the patient pathway. Each individual patient pathway may include events associated with a specific patient, such as the type of treatment administered to a patient with a specific patient identifier at a specific date, time, and location. These events are categorized into various event types that are not specific to a specific patient or event. For example, the type of diagnosis event is based on the disease for which the patient is diagnosed at an event. As another example, the type of treatment event may be based on a treatment administered to a patient or a surgical procedure administered to a patient. As another example, the type of clinical outcome event may be based on the survival of a patient at a predetermined time after one or more treatment events, or the death of a patient at a predetermined time after one or more treatment events.

[0041] 1. Examples of common pathways 3C illustrates an example operation of the common pathway module 206. As shown in FIG. 3C, a patient pathway for a patient having patient ID 240 (of X0) may be represented by a graph 320 including a start node 322, a disease A diagnosis event node 324, a treatment event 0 node 326, a medical outcome (death) node 328, and an end node 330, each connected by edges 333, 334, 336, and 338. Edge 333 may be associated with transition time ΔTa1, edge 334 may be associated with transition time ΔTb1, and edge 336 may be associated with transition time ΔTc1. Additionally, a patient pathway for a patient with patient ID 240 (of X1) may be represented by a graph 340 including a start node 342, a disease A diagnosis event node 344, a treatment event node 346, a medical outcome (death) node 343, and an end node 350, each connected by edges 352, 354, 356, and 358. Edge 352 may be associated with transition time ΔTa2, edge 354 may be associated with transition time ΔTb2, and edge 356 may be associated with transition time ΔTc2.

[0042] 3C , the common pathway module 206 may determine that graphs 320 and 340 represent a common patient pathway based on both graphs having the same sequence of events, including the same Disease A diagnosis event (represented by nodes 324 and 344), the same treatment event (represented by nodes 326 and 346), and the same medical outcome event (death, represented by nodes 328 and 343). Based on this determination, the common pathway module 206 may create graph 360 representing the common patient pathway based on aggregating information in graphs 320 and 340. For example, graph 360 includes a common start node 362, a common Disease A diagnosis event node 364, a common treatment event 0 node 366, a common medical outcome (death) node 368, and a common end node 370, each connected by edges 372, 374, 376, and 378. Each node is associated with the patient ID 240 (e.g., X0, X1) of the patients who share the common patient pathway. Additionally, each of edges 372, 374, 376, and 378 is formed by merging edges and associated information from graphs 320 and 340. For example, edge 372 is associated with a transition time ΔTa_y, which may be the average of ΔTa1 and ΔTa2. Additionally, edge 374 is associated with a transition time ΔTb_y, which may be the average of ΔTb1 and ΔTb2. Additionally, edge 376 is associated with a transition time ΔTc_y, which may be the average of ΔTc1 and ΔTc2. Other information associated with edges, such as cost (not shown in FIG. 3C), may also be averaged and become associated with the merged edge in graph 360. Graph 360 is also associated with a common path ID 380 (labeled Y in FIG. 3C).

[0043] 2. Example of common route recording After identifying the common pathways, the common pathway module 206 can generate records (e.g., in the form of a table) that associate various metrics and events with each common pathway and store the records in the pathway database 209. FIG. 3D shows an example of a common pathway record 382. As shown in FIG. 3D, the common pathway record 382 may associate each common pathway ID (e.g., Y0, Y1, etc.) with a diagnosis event, a treatment event, a medical outcome event, a total number of patients sharing the common patient pathway associated with the ID (e.g., N0, N1, etc.), and a total cost of the common patient pathway (e.g., total cost 0, total cost 1, etc.). The total number of patients in each common patient pathway can be obtained by counting the number of unique patient identifiers associated with the common event node in a graph (e.g., graph 360) representing the common patient pathway, and the total cost of each common patient pathway can be obtained by summing the average costs associated with each merged edge of the graph. The common pathway record 382 can also be stored in the pathway database 209. In some examples, common pathway records 382 may also be created by counting edges passing between nodes representing common diagnostic, treatment, and medical outcome events.

[0044] F. Common Events Referring back to FIG. 2 , the common event module 208 can identify common event nodes (diagnoses, procedures, medical outcomes) shared by patients who do not share a common patient pathway and create records that associate the common event nodes with the patient IDs of patients that have the common event node as part of their patient pathway, as well as other event nodes connected to the common event node.

[0045] 3E and 3F illustrate example operation of the common event module 208. The common event module 208 can traverse the graphs of patient pathways stored in the pathways 355 and / or common pathway records 382. Figure 3E illustrates graph 384 associated with patient IDs X0 and X1 and including a node 385 associated with treatment event 0a, a node 386 associated with treatment event 1, and a node 387 associated with a medical outcome event (survival), and graph 388 associated with patient IDs X2 and X3 and including a node 389 associated with treatment event 0b, a node 390 associated with treatment event 1, and a node 391 associated with a medical outcome event (death).

[0046] The common event module 208 determines that both graphs have nodes representing treatment event 1 (nodes 386 and 390) and can create a common event node 392 representing treatment event 1, with entrance edges from treatment event nodes 385 and 389 and exit edges to medical outcome event nodes 387 and 391. The common event module 208 can also associate the common event node 392 with patient IDs X0, X1, X2, and X3. Additionally, referring to FIG. 3F , the common event module 208 can also create a common event node record 394 (e.g., a table) that associates each common event node with the common event node ID, the entrance node (to which the entrance edge is connected), and the exit node (to which the exit edge is connected), as well as the patient ID associated with the common event node. If the common event node is associated with a treatment, the common event node record 394 can further store information about the specific treatment regimen and / or the specific surgical regimen associated with the common event node. 3F , in common event node record 394, common event node 392 is assigned a common event node ID “Z0” and is associated with patient IDs X0, X1, X2, and X3. Common event node 392 is further associated with procedure event nodes 385 and 389 (represented by event node IDs “Z1” and “Z2”) as entry nodes and medical outcome event nodes 387 and 391 (represented by event node IDs “Z3” and “Z4”) as exit nodes. Common event node record 394 may also be stored in pathway database 209.

[0047] G. Route Selection 2, the pathway selection module 210 can receive input specifying one or more selection criteria, select a subset of patient pathways based on the selection criteria, retrieve a graph representing the selected patient pathways from the pathway database 309, and then provide the graph for display on the graphical user interface 230. In some examples, the input can also be received via the graphical user interface 230.

[0048] The pathway selection module 210 may include a common pathway filtering module 250 and a common event filtering module 252 to perform selection based on different types of criteria. Specifically, the common pathway filtering module 250 may receive an input specifying the number of most common patient pathways shared by patients (e.g., 4, 8, 10, etc.). The common pathway filtering module 250 may then reference the common pathway records 382, ​​identify the number of common patient pathways associated with the most common patients, rank the common patient pathways based on the number of patients, and retrieve a graph representing the number of top-ranked common patient pathways. As another example, the input may specify that only a certain percentage of patients (e.g., 100%, 70%, 50%, 10%, etc.) are represented in the common patient pathways. The common pathway filtering module 250 may also instruct the common pathway module 206 to generate a sample of common patient pathways based on the sample of patient pathways for the specified percentage of patients and provide a graph of the sample of common patient pathways for display on the graphical user interface 230. In some examples, the routing module 210 may also obtain common patient pathway metric data from the common pathway record 382 and provide the data for display on the graphical user interface 230 .

[0049] Additionally, the common event filtering module 252 can receive input specifying criteria for selecting one or more common treatment events, and the system can select a subset of patient pathways having one or more common treatment events. For example, the criteria may specify a specific treatment regimen or a specific surgical regimen. The common event filtering module 252 can reference the common event node records 394 to identify common treatment event nodes having the specified treatment / surgical regimen and identify entry and exit nodes for the identified common treatment event nodes. The common event filtering module 252 can also track the entry and exit nodes of the identified nodes in the common event node records 394 until it reaches nodes representing diagnostic and medical outcome events. As another example, the criteria may specify common treatment events shared by a threshold percentage of patients, or a threshold percentage of patients transitioning from a first common treatment event to a second common treatment event, and the common event filtering module 252 can filter out transitions / edges that do not meet the threshold percentage as part of the tracking. The common event filtering module 252 can then provide a graph representing the identified nodes from the common event node record 394, including treatment event nodes, consultation event nodes, and medical outcome event nodes, to the graphical user interface 230 for display.

[0050] In some examples, the merge module 212 can receive the graphs provided by the routing module 210 and merge them into a merged graph for display on the graphical user interface 230. The merge operation can include merging nodes of different graphs that represent the same type of diagnostic event, the same type of treatment event, or the same type of clinical outcome event into a merged node and based on merging edges between two merged nodes into a single edge. By merging graphs, the merged graph can be more compact and easier to visualize.

[0051] H. Marge In some examples, the merge module 212 merges graphs based on categories determined by the preprocessing module 203. The merge module 212 can create pathways based on higher level categories (e.g., biomarkers). The merge module 212 can nest lower level categories (e.g., molecular biomarkers) within pathways and place individual biomarkers there.

[0052] 4A illustrates an exemplary merging operation by the merge module 212. As shown in FIG. 4A, the pathway selection module 210 can provide graph 402, graph 422, graph 442, and graph 462. Each graph can represent a patient pathway for a single patient or a common patient pathway generated by the common pathway module 206. Graph 402 includes a start node 404, a disease A diagnosis event node 406, a treatment event 0 node 408, a medical outcome event (death) node 410, and an end node 412, connected by edges 414, 416, 418, and 420. Graph 422 includes a start node 424, a disease A diagnosis event node 426, a treatment event 1 node 428, a medical outcome (survival) node 430, and an end node 432, connected by edges 434, 436, 438, and 440. Further, graph 442 includes a start node 444, a disease A diagnosis event node 446, a treatment event 0 node 448, a medical outcome event (survival) node 450, and an end node 452, connected by edges 454, 456, 458, and 460. Additionally, graph 462 includes a start node 464, a disease A diagnosis event node 466, a treatment event 1 node 468, a medical outcome event (survival) node 470, and an end node 472, connected by edges 474, 476, 478, and 480.

[0053] The merge module 212 can traverse graphs 402, 422, 442, and 462 and merge them into a merged graph 482. Merging operations can include merging nodes representing the same diagnosis event, the same treatment event, or the same clinical outcome event into a merge node, and merging edges between two merge nodes into a single edge. As shown in FIG. 4A , the merge module 212 can merge nodes 406, 426, 446, and 466, each representing the same disease A diagnosis event, into merge node 483, which represents a disease A diagnosis event. In addition, the merge module 212 can merge nodes 408 and 448, representing treatment event 0, into merge node 484, and merge nodes 428 and 468, representing treatment event 1, into merge node 485. Furthermore, the merge module 212 can merge nodes 410 and 470, representing death events, into merge node 486, and merge nodes 430 and 450, representing survival events, into merge node 487. The merge module 212 can also merge start and end nodes into a single start node 488 and a single end node 489, respectively. In some implementations, additional information is stored in the nodes, such as the number of patients associated with the node.

[0054] In addition, merge module 212 also merges edges. As part of the merging, metrics associated with the edges, such as time, cost, total number of patients, etc., can be combined (e.g., averaged, added, etc.) into the merged edge. For example, edges 414, 434, 454, and 474 are merged into edge 490, edges 416 and 456 are merged into edge 491, edges 436 and 476 are merged into edge 492, edges 420 and 480 are merged into edge 493, and edges 440 and 460 are merged into edge 494. Meanwhile, edges 418, 438, 458, and 478 between treatment event nodes and medical outcome event nodes are retained in merged graph 482.

[0055] In some examples, the merge module 212 can also associate each event node with the patient ID of the patient that shares that event node. As described below, associating patients with shared event nodes can support additional analysis and visualization effects. For example, with reference to FIG. 4B , assuming a cohort of patients C0, C1, C2, and C3 share patient pathways represented by graphs 402, 422, 442, and 462, respectively, the merge module 212 can associate a disease A diagnosis event node 483 in the merged graph 482 with cohorts C0, C1, C2, and C3. Additionally, the merge module 212 can associate a treatment event 0 node 484 with cohorts C0 and C2 and a treatment event 1 node 485 with cohorts C1 and C3. The merge module 212 can also associate a survival event node 487 with cohorts C0 and C3 and a mortality event node 486 with cohorts C1 and C2.

[0056] I.Analysis The analysis module 220 can perform additional analysis on the merged graph generated by the merge module 212. For example, referring to FIG. 5A , the analysis module 220 can track the progress of each patient (or each patient cohort) represented in the merged graph 482 over time. The tracking can be based on the association of the patient with each node in the merged graph as well as the time information included in the edges. In some examples, the graphical user interface 230 can be configured to display the progress of patients over time in the merged graph 482. For example, the graphical user interface 230 can display that patients X and Y are in the treatment event 0 node 484 and the treatment event 1 node 485, respectively, at time T2. Furthermore, the graphical user interface 230 can also display that patients X and Y are in the survival event node 487 and the death event node 486, respectively, at time T3. The output of the analysis module 220 of FIG. 5A can support animated display of the merged graph 482 to show the progression of patients in the graph against time to improve visualization of various metrics (e.g., time, survival rate, etc.) of different patient pathways.

[0057] In some examples, the analysis module 220 generates nested pathway visualizations using the categories 395 generated by the preprocessing module 203. Using the higher- and / or lower-level categories generated by the preprocessing module 203, the analysis module 220 can organize the pathways to be displayed based on category. This can be used to generate a more user-friendly visualization that clearly shows different types of events within the pathway (e.g., as shown in FIG. 6G). In some implementations, a user (e.g., a physician) can scroll or zoom to higher-level categories, such as biomarker tests, to view different types of biomarkers within the pathway.

[0058] In some examples, the analysis module 220 can access historical patient data associated with particular event nodes to support additional analyses, such as survival analysis. For example, referring to FIG. 5B , the treatment event 0 node 484 and the treatment event 1 node 485 can be discriminant nodes associated with mutually exclusive patient cohorts. The analysis module 220 can retrieve historical patient data for cohorts C0 and C2 associated with the treatment event 0 node 484 and historical patient data for cohorts C1 and C3 associated with the treatment event 1 node 485 and generate a Kaplan-Meier (KM) plot 502. In some examples, an adjusted Cox regression model curve can also be generated. The KM plot for the cohorts involved in the treatment can then be analyzed to determine, for example, the effectiveness of the treatment / surgical regimen represented by nodes 484 and 485. Furthermore, the analysis module 220 can perform predictions based on the KM plot 502. For example, for a patient deciding between treatment options represented by nodes 484 and 485, the patient's characteristics can be compared with those of cohorts C0, C1, C2, and C3, and a KM plot of the cohorts with characteristics most similar to the patient can be used to generate hypotheses that allow, for example, prediction of the patient's survival rate after receiving the same treatment taken by the cohorts. These interactive features can be used to help clinicians make informed decisions to explore relevant attributes and determine courses of action (e.g., treatment) to improve the patient's chances of survival and / or improve the patient's ability to plan for the future and improve the patient's quality of life. By interacting with the interface to view additional analytics, clinicians can identify potential deviations from clinical guidelines and potential inefficiencies in clinical workflow and resource management by navigating the interface to view additional metrics.

[0059] III. Graphical User Interface 6A-6F illustrate an example of the operation of the graphical user interface 230. As shown in FIG. 6A, the graphical user interface 230 may include a display interface 602 for displaying a merged graph of patient pathways, as well as input interfaces 604, 606, and 608. The input interface 604 may provide input for a certain number of the most common patient pathways to be displayed in the display interface 602, and the input interface 606 may provide input for a certain percentage of patients represented in the common patient pathways. Additionally, the input interface 608 may provide input for selecting metrics (e.g., number of patients (cases), time, and cost) to be displayed in the merged graph. In FIG. 6A, the graphical user interface 230 is configured to display a fully merged graph of all patient pathways for all patients in the patient database 202.

[0060] 6B illustrates another exemplary operation of the graphical user interface 230. As shown in FIG. 6B, the graphical user interface 230 can receive input from an input interface 604 to display the top five most common patient pathways as a merged graph 610 based on the output of the common pathway module 206, the pathway selection module 210, and the merge module 212, and input from an interface 608 to display the number of patients associated with each node and edge. The graphical user interface 230 also displays a graph 612 of various metrics for each common patient pathway, including the total number of patients, the total cost, and the total time.

[0061] 6C and 6D illustrate an example operation of the graphical user interface 230 based on the output of the analysis module 220. As shown in FIGS. 6C and 6D, the graphical user interface 230 can operate in an animation mode based on the output of the analysis module 220. The graphical user interface 230 further includes an input interface 614, which can be in the form of a time slider, for selecting a time of a patient's progression in the common patient pathway represented by the merged graph 610. In FIGS. 6C and 6D, each dot on the edge (e.g., X0 and X1) can represent a case / patient, with the patient moving from one event node to another in the merged graph 610 during different times selected by the input interface 614. For example, as shown in Figure 6C, patients X0 and X1 have not yet started FOLFOX treatment (a chemotherapy regimen consisting of the drugs folinic acid (leucovorin), fluorouracil (5-FU), and oxaliplatin (eloxatin)), represented by treatment event node 616, at 6 months from disease diagnosis, whereas in Figure 6D, patients X0 and X1 have completed FOLFOX treatment at 1 year from disease diagnosis.

[0062] 6E and 6F illustrate another exemplary operation of the graphical user interface 230 based on the output of the analysis module 220. As shown in FIG. 6E, the graphical user interface 230 includes an input interface 620 that receives input for selecting two discriminant nodes to identify two patient cohorts. The two discriminant nodes may be two treatment event nodes, two diagnosis nodes, etc. Referring back to FIG. 6D, the treatment event node 616 is associated with FOLFOX treatment, while the treatment event node 622 is associated with FOLFOX and bevacizumab treatments, each including a mutually exclusive set of patients. Based on the selection of the treatment event nodes 616 and 622, two cohorts (Cohort 1 and Cohort 2) are identified, and their medical data may be accessed by the analysis module 220. In FIG. 6E, demographic information 624 of the two cohorts is displayed, and in FIG. 6F, a KM plot 626 of the two cohorts is displayed.

[0063] 6G shows another example of a view of the graphical user interface 230 showing nested pathways. To improve the visual presentation of a pathway map (e.g., as shown in FIG. 6B), the patient pathway reconstruction and aggregation system 200 groups nodes belonging to different categories. For example, as depicted in FIG. 6G, the nodes are grouped into three high-level categories: Treatment Strategy A 632, Biomarkers 634, and Treatment Strategy 2 636. Within each of these high-level categories 632, 634, 636 are respective events. Events A and E are specific first-line treatments (e.g., different drugs or therapies administered); events B, C, H, I, and F are specific biomarkers (e.g., blood glucose, prostate-specific antigen, etc.); and events D and G are specific second-line treatments.

[0064] In the example shown in FIG. 6G, node connections may be generated as described above based on an ordered series of events in multiple patient pathways. Additionally, nodes are grouped to reflect different levels of categories. By showing events grouped into different categories, a more user-friendly visualization is provided that clearly shows different types of events within the pathway. A user (e.g., a physician) can scroll or zoom to higher-level categories, such as biomarker tests, to view different types of biomarkers within the pathway. This helps users drill down to various levels and easily navigate the graph to obtain information of interest.

[0065] IV. Method 7 illustrates an example method 700 for reconstructing and aggregating patient pathways for multiple patients based on historical patient data. Method 700 may be performed, for example, by the patient pathway reconstruction and aggregation system 200 of FIG. 2.

[0066] In step 702, the system retrieves patient historical data from a database (e.g., patient database 202), where the historical data includes a history of one or more diagnosis events, one or more treatment events, and clinical outcome events for each patient. A diagnosis event can include, for example, an event in which a patient is diagnosed with a disease. A treatment event can include, for example, a therapeutic regimen, a surgical regimen, etc., each of which can include administering one or more medications and / or surgical procedures over a period of time. A clinical outcome event can include, for example, survival or death at a predetermined time point from diagnosis, which can be adjusted for the year of diagnosis based on a particular study period. The historical data can include large amounts of complex data. For example, the historical data can include data for more than 100 patients, more than 500 patients, more than 1,000 patients, or more than 5,000 patients. For each patient, the historical data can include dozens or hundreds of different events.

[0067] In some embodiments, the system preprocesses the medical history data, which may include formatting the data (e.g., in a tabular format, standardizing certain values ​​or terms, etc.). In some examples, preprocessing includes grouping events into categories. This may include higher level categories such as treatments, biomarkers, etc. Alternatively, or in addition, this may include lower level categories such as molecular biomarkers, drug treatments, etc.

[0068] In step 704, for each patient and based on the medical history data, the system generates a patient pathway including a graph including nodes and edges connecting the nodes, where the nodes represent one or more diagnosis events, one or more treatment events, and clinical outcome events, and the edges represent the temporal relationships between the events represented by the nodes. Figure 3B shows an example of a patient pathway generated by the system. In some examples, the patient pathway reconstruction and aggregation system can traverse the patient's medical history record arranging the events according to chronological order, create a node for each event, and add the nodes to the graph according to chronological order. As mentioned above, there may be thousands of events, resulting in thousands of nodes connected by thousands of edges.

[0069] In some embodiments, the system clusters patients based on the sequence of events in the patient pathway for each patient to generate patient clusters. For example, trace clustering is applied to the sequence of events in the patient pathway to create clusters of patients who follow similar sequences. Part of the reason traditional multi-patient pathways appear spaghetti-like (e.g., as shown in FIG. 6A) is the variability of patient data, which arises from both the size of the dataset and patients with different treatment pathways. By clustering "similar" patients together before applying the pathway-building algorithm, the system creates smaller groups of treatment pathways for similar patients.

[0070] In step 706, the system receives, via an interface, one or more criteria for selecting a subset of patient pathways for patients. The user interacts with the interface to configure the criteria. FIG. 6B shows an example of an interface. For example, the criteria may specify that all graphs or all patients are included in the merged graph. The criteria may specify that only a certain percentage of patients (e.g., 100%, 70%, 50%, 10%, etc.) are represented in the merged graph. As another example, the criteria may specify the number of most common patient pathways shared by patients (e.g., 4, 8, 10, etc.). In some examples, the input may include criteria for selecting one or more common treatment events. For example, the criteria may specify a specific treatment regimen or a specific surgical regimen. As another example, the criteria may specify that a common treatment event is shared by a threshold percentage of patients, or that a threshold percentage of patients transition from a first common treatment event to a second common treatment event.

[0071] In step 708, the system selects graphs representing a subset of patient pathways based on one or more criteria. Based on the specified criteria, the system identifies and selects corresponding graphs. For example, the criteria may specify a certain percentage of patients represented in the merged graph, and the system selects a subset of graphs representing the specified percentage of patients. As another example, the criteria may specify one or more common treatment events. The system may select graphs representing a subset of patient pathways that have one or more common treatment events. As another example, the criteria may specify a specific treatment regimen or a specific surgical regimen, and the system may select graphs that have treatment event nodes for the specific treatment regimen or the specific surgical regimen.

[0072] In some examples, the one or more criteria specify a number of patients. The system identifies one or more common patient pathways shared by that number of patients. The system associates each common patient pathway with a count of several patients who share the common patient pathway. The system ranks each patient pathway based on the associated count. The system selects a number of the top-ranked patient pathways as a subset of the patient pathways.

[0073] In some examples, the one or more criteria specify a threshold percentage of patients. The system identifies one or more common types of treatment events shared by several patients. The system associates each common type of treatment event with a percentage of patients who share the common type of treatment event. The system selects a subset of patient pathways that include the one or more common types of treatment events associated with the threshold percentage of patients.

[0074] In some examples, the system selects events to include in the subset of the patient pathway based on identifying common types of events. For example, the system identifies one or more common types of treatment events shared by several patients. The system associates each common type of treatment event with a subset of patients that share the common type of treatment event. The system selects a first common type of treatment event and a second common type of treatment event to be included in the subset of the patient pathway. The first common type of treatment event is shared by a first subset of patients, and the second common type of treatment event is shared by a second subset of patients that also have the first common type of treatment event before having the second common type of treatment event. The first common type of treatment event and the second common type of treatment event are selected to be included in the subset of the patient pathway based on a percentage between the second subset and the first subset that exceeds a threshold percentage.

[0075] In some embodiments, graphs representing subsets of patient pathways are further selected based on patient clusters. For example, one patient cluster is selected and step 710 is performed for that patient cluster, then another patient cluster is selected and step 710 is performed for that patient cluster, etc. This can simplify and improve the merging process since clusters of patients have similar patient pathways.

[0076] In step 710, the system aggregates a subset of patient pathways into a merged graph by merging nodes of the graph that represent the same type of diagnostic event, the same type of treatment event, or the same type of clinical outcome event into a merge node, and by merging edges between two merge nodes into a single edge. An example of aggregation is shown in Figure 3C.

[0077] The system identifies multiple sets of graph nodes among subsets of patient pathways, each set representing the same type of diagnosis event, the same type of treatment event, or the same type of clinical outcome event, and merges each of the multiple sets of graph nodes. Specifically, if two patients have the same diagnosis (e.g., the same type of cancer and the same stage), the system determines that two nodes of two diagnosis events for the two patients represent the same type of diagnosis event and can merge the two nodes into a merged node representing the same diagnosis event. Furthermore, the system determines that two nodes of two treatment events for the two patients can be determined to represent the same type of treatment event if the two events have the same treatment / surgical regimen and can merge the two nodes into a merged node representing the same treatment event. Furthermore, the system can merge two nodes of the same type of clinical outcome event (e.g., survival or death) and merge the two nodes into a merged node representing the same clinical outcome event. In all of these cases, the two nodes can be merged regardless of whether the events represented by the nodes occur within the same or different time periods. For example, nodes representing the same type of diagnostic event, the same type of treatment event, or the same type of clinical outcome event represent events occurring at different times. In some examples, merging can also include clustering pairs of nodes representing different diagnostic / treatment events that are close in time and / or connected by a large number of edges, or nodes selected as part of input via a graphical user interface, into a single node.

[0078] In some embodiments, the system generates merged graphs based on event categories, for example, the system generates pathways for higher level categories, and within these higher level categories, biomarker events are grouped together, treatment events are grouped together, etc., as shown in FIG.

[0079] In step 712, the system displays the merged graph in the interface. Examples of merged graphs are shown in Figures 6A-6D. In addition to the merged graph, the system can also generate and display additional analytical data for subsets of the patient pathways, which can provide clinical and operational insights into the clinical care the patient received. For example, the system can generate various metrics for each patient pathway and / or each event node represented in the merged graph and display the metrics in the interface. The metrics can include, for example, the number of patients sharing the patient pathway, the total cost of one or more diagnostic events and one or more treatment events in the patient pathway, the total time between the first diagnostic event and the clinical outcome event in the patient pathway, the patient's survival rate, and deviations from clinical guidelines (if any). The metrics can be overlaid on the merged graph and / or displayed in separate graphs.

[0080] In some examples, the system displays a merged graph with nested pathways (e.g., as shown in FIG. 6G). The merged graph includes higher-level categories, event-level nodes, and possibly lower-level categories. The system can receive user input to zoom out to higher-level categories or zoom in to event-level nodes. This improves the visual presentation and interpretability of the pathway map.

[0081] In some examples, the system may also support the identification and analysis of different patient cohorts. For example, each common event node in the merged graph can be associated with a patient cohort (e.g., a group of similar patients identified from the merged graph). Medical history data for a subset of patients can be accessed from a database via selection of a node in the interface. Various analyses can be performed on the data for the patient cohort.

[0082] In some examples, the system can make a clinical prediction based on the processing results. For example, the system receives the patient's medical data, compares the patient's medical data with the medical data of a first subset of patients, and makes a clinical prediction for the patient based on the first processing results and the comparison results. For example, the identified cohort of patients is used to predict the probability of survival. As a specific example, a predictive machine learning model can be trained to make clinical predictions to predict the medical outcome of a particular patient. For example, a random survival forest (RSF) model can be trained based on data from previous patients and their survival statistics to predict the survival probability of a new patient as a function of time since diagnosis (e.g., of advanced cancer). The prediction can be provided to the new patient, for example, to improve their ability to plan for the future. This has the potential to improve the patient's quality of life. Alternatively or additionally, the system can determine the cumulative survival probability over time and generate a Kaplan-Meier (KM) plot. The KM plot can also be displayed. Additionally or alternatively, the system can output the attributes and medical outcomes of the patient cohort. This may help facilitate clinical decisions for a particular patient. For example, the system may output a summary of the attributes of a cohort of patients, along with a comparison of the attributes of patients within the cohort, allowing a clinician to examine relevant attributes and determine a course of action (e.g., treatment) to improve a patient's chances of survival.

[0083] In some examples, the system generates and displays multiple merged graphs. For example, the merged graph generated in step 710 is a first merged graph, where the graph is the first graph. A patient pathway for a patient is represented by a second graph (e.g., for a different group of patients). The system generates the second merged graph representing the patient pathway for a patient based on merging nodes of the second graph representing the same type of diagnostic event, the same type of treatment event, or the same type of clinical outcome event into a merge node and merging edges between the two merge nodes into a single edge. The system displays the second merged graph in the interface. For example, the second merged graph is displayed in the interface before displaying the first merged graph.

[0084] In some examples, the system can receive user input to retrieve and display additional information by interacting with the merged graph. For example, each patient is associated with a patient identifier in the database. Each merge node representing the same type of treatment event in the merged graph is associated with the patient identifier of each patient who has the event represented by the merge node in the patient's medical history data. The system receives, via the interface, a selection of a merge node representing a type of treatment event. The system determines the patient identifier associated with the merge node. The system uses the patient identifier to retrieve medical history data for a subset of patients from the database. The system processes the medical history data for the subset of patients to generate processed results and displays the processed results in the interface. The processed results may include, for example, survival curves for the subset of patients. This can be repeated in response to receiving a selection of an additional merge node (e.g., upon detecting the selection of a second merge node representing a second type of treatment event, the system repeats the process using the second patient identifier to generate a second processed result).

[0085] In some examples, each merge node representing the same type of treatment event or the same type of clinical outcome event in the merged graph is associated with a patient identifier for each patient who has the event represented by the merge node in their medical history data and the time of the event since the patient was first diagnosed with the disease. The system displays the course of events over time for each patient represented in the merged graph based on the patient identifier and the time of the event associated with each merge node representing the same type of treatment event or the same type of clinical outcome event in the merged graph.

[0086] The techniques described herein provide improved visualizations that can help clinicians efficiently understand large amounts of data. For example, using the spaghetti-like patient pathways shown in FIG. 6A , clinicians would need to expend significant time and energy to make sense of all the data shown and discern useful information, if at all. In contrast, using the merged graph shown in FIG. 6G , clinicians can clearly see the various pathways a patient is taking in an organized manner. Furthermore, the user interface allows clinicians to drill down into different categories of events (e.g., treatment events, biomarkers, etc.), further aiding the interpretability of the merged graph.

[0087] In some embodiments, the user interface also provides the advantage of allowing the user to interact with the merged graph and drill down into the data for different patients or cohorts of patients. The system can also calculate and display additional metrics, such as survival probability, time, and cost. This can be used to explore relevant attributes and make informed decisions to determine courses of action (e.g., treatment) to improve the patient's survival probability and / or improve the patient's ability to plan for the future and improve the patient's quality of life. Additional advantages include the ability to identify potential deviations in clinical care from clinical guidelines, as well as potential inefficiencies in clinical workflow and resource management, by navigating the interface and viewing additional metrics.

[0088] V. Computer Systems Any of the computer systems referred to herein may utilize any suitable number of subsystems. An example of such a subsystem is shown in computer system 800 of FIG. 8. In some embodiments, a computer system includes a single computer device, and the subsystems can be components of the computer device. In other embodiments, a computer system can include multiple computer devices, each of which is a subsystem with its internal components. Computer systems can include desktop and laptop computers, tablets, mobile phones, and other mobile devices. In some embodiments, cloud infrastructure (e.g., Amazon Web Services), graphical processing units (GPUs), and the like can be used to implement the disclosed techniques.

[0089] The subsystems shown in FIG. 8 are interconnected via a system bus 75. Additional subsystems are shown, such as a printer 74, a keyboard 78, a storage device 79, and a monitor 76 coupled to a display adapter 82. Peripherals and input / output (I / O) devices coupled to the I / O controller 71 may be connected to the computer system by any number of means known in the art, such as an input / output (I / O) port 77 (e.g., USB, FireWire®). For example, the I / O port 77 or an external interface 81 (e.g., Ethernet, Wi-Fi, etc.) may be used to connect the computer system 10 to a wide area network such as the Internet, a mouse input device, or a scanner. Through the interconnection via the system bus 75, the central processing unit 73 can communicate with each subsystem and control the execution of instructions from the system memory 72 or storage device 79 (e.g., a fixed disk such as a hard drive or an optical disk) as well as the exchange of information between the subsystems. The system memory 72 and / or storage device 79 may embody computer-readable media. Another subsystem is a data collection device 85, such as a camera, microphone, or accelerometer. Any of the data referred to herein may be output from one component to another and may be output to a user.

[0090] A computer system may include multiple identical components or subsystems connected to each other, for example, by external interfaces 81 or by internal interfaces. In some embodiments, computer systems, subsystems, or devices may communicate over a network. In such cases, one computer may be considered a client and another computer may be considered a server, each of which may be part of the same computer system. Each client and server may include multiple systems, subsystems, or components.

[0091] Aspects of the embodiments may be implemented in the form of control logic, in a modular or integrated manner, using hardware (e.g., application-specific integrated circuits or field-programmable gate arrays) and / or using computer software in conjunction with a generally programmable processor. As used herein, a processor includes a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units on a single circuit board or networked. Based on the disclosure and teachings provided herein, those skilled in the art will know and understand other ways and / or methods for implementing embodiments of the present invention using hardware and combinations of hardware and software.

[0092] Any software components or functions described in this application may be implemented as software code executed by a processor, e.g., using conventional or object-oriented techniques, using any suitable computer language, such as, for example, Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable non-transitory computer-readable media may include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a compact disc (CD) or digital versatile disc (DVD), flash memory, etc. The computer-readable medium may also be any combination of such storage or transmission devices.

[0093] Such programs may also be encoded and transmitted using carrier signals adapted for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Thus, data signals encoded with such programs may be used to create computer-readable media. Computer-readable media encoded with program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer-readable media may reside on or within a single computer product (e.g., a hard drive, CD, or an entire computer system) or may reside on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing a user with any of the results referred to herein.

[0094] Any of the methods described herein may be performed in whole or in part using a computer system including one or more processors that may be configured to perform the steps. Accordingly, embodiments may be directed to a computer system configured to perform the steps of any of the methods described herein, with potentially different components performing each step or each group of steps. While presented as numbered steps, steps of the methods herein may be performed simultaneously or in a different order. In addition, some of these steps may be used with some of other steps from other methods. Also, all or some of the steps may be optional. Furthermore, any steps of any method may be performed using a module, unit, circuit, or other means for performing those steps.

[0095] The specific details of particular embodiments may be combined in any suitable manner without departing from the spirit and scope of the embodiments of the invention, however, other embodiments of the invention may be directed to particular embodiments relating to each individual aspect or particular combinations of these individual aspects.

[0096] The foregoing description of exemplary embodiments of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form described, and many modifications and variations are possible in light of the above teaching.

[0097] The terms "a," "an," or "the" are intended to mean "one or more" unless specifically indicated otherwise. The use of "or" means "inclusive or" and, unless specifically indicated otherwise, is intended to mean "exclusive or." A reference to a "first" element does not necessarily require that a second element be provided. Furthermore, a reference to a "first" or "second" element does not limit the referenced element to a particular location unless expressly specified.

[0098] All patents, patent applications, publications, and descriptions mentioned herein are incorporated by reference in their entirety for all purposes. None are admitted to be prior art.

Claims

1. 1. A computer-implemented method comprising: obtaining historical medical data for a plurality of patients from a database, the historical medical data including a history of one or more diagnostic events, one or more treatment events, and clinical outcome events for each of the plurality of patients; generating, for each patient based on the medical history data, a patient path comprising a graph including nodes and edges connecting the nodes, wherein the nodes represent the one or more diagnostic events, the one or more treatment events, and the clinical outcome events, and the edges represent temporal relationships between the one or more diagnostic events, the one or more treatment events, and the clinical outcome events represented by the nodes; receiving, via an interface, one or more criteria for selecting a subset of the patient pathways for the plurality of patients; selecting a graph representing a subset of the patient pathways based on the one or more criteria; a subset of said patient pathways; identifying, among the subset of patient pathways, a plurality of sets of nodes of the graph, each set of nodes representing the same type of diagnostic event, the same type of treatment event, or the same type of clinical outcome event; merging each set of the plurality of sets of nodes of the graph; merging the edges between two merged nodes into a single edge; aggregating into a merged graph by displaying the merged graph in the interface; A method comprising:

2. The method of claim 1 , wherein the type of diagnostic event is based on the disease for which the patient is diagnosed at the event.

3. The method of claim 1 , wherein the type of treatment event is based on at least one of a treatment administered to the patient or a surgical procedure administered to the patient.

4. 10. The method of claim 1, wherein the type of clinical outcome event is based on one of: survival of a patient at a predetermined time after the one or more treatment events; or death of the patient at the predetermined time after the one or more treatment events.

5. The method of claim 1 , wherein nodes representing the same type of diagnostic events, the same type of treatment events, or the same type of clinical outcome events represent events occurring at different times.

6. identifying one or more common patient pathways shared by several patients of the plurality of patients; associating each common patient pathway with a count of the number of patients who share the common patient pathway; ranking each patient pathway based on the associated count; selecting a number of the top ranked patient pathways as a subset of said patient pathways; further comprising The method of claim 1 , wherein the one or more criteria specify the number.

7. identifying one or more common types of treatment events shared by several patients of the plurality of patients; Associating each common type of treatment event with a percentage of the patients who share the common type of treatment event; selecting a subset of the patient pathways that includes one or more common types of treatment events associated with a threshold percentage of the patients; further comprising The method of claim 1 , wherein the one or more criteria specify the threshold percentage.

8. identifying one or more common types of treatment events shared by several of said patients; associating each common type of treatment event with a subset of the patients who share the common type of treatment event; selecting a first common type of treatment event and a second common type of treatment event for inclusion in the subset of patient pathways; further comprising the first common type of treatment event is shared by a first subset of the patients; the second common type of treatment event is shared by a second subset of the patients who also received the first common type of treatment event prior to receiving the second common type of treatment event; 2. The method of claim 1, wherein the first common type of treatment event and the second common type of treatment event are selected for inclusion in the subset of the patient pathway based on a percentage between the second subset and the first subset exceeding a threshold percentage.

9. further comprising clustering the patients based on a sequence of events in the patient pathway for each patient to generate a plurality of patient clusters; The method of claim 1 , wherein the step of selecting the graph representing a subset of the patient pathways is further based on the patient clusters.

10. The method of claim 1, further comprising grouping the one or more diagnostic events, the one or more treatment events, and the clinical outcome event into categories; The method of claim 1 , wherein the merged graph is further based on the categories.

11. determining one or more metrics for each patient pathway in the subset of patient pathways; displaying the one or more metrics simultaneously with the merged graph in the interface; The method of claim 1 further comprising:

12. 12. The method of claim 11 , wherein the one or more metrics of a patient pathway include at least one of a number of patients sharing the patient pathway, a total cost of one or more diagnostic events and one or more treatment events of the patient pathway, or a total time between a first diagnostic event and a clinical outcome event in the patient pathway.

13. the merged graph is a first merged graph, the graph is a first graph, a patient pathway for the patient represented by a second graph; The method further comprises: generating a second merged graph representing a patient pathway for the patient based on merging nodes of the second graph representing the same type of diagnostic event, the same type of treatment event, or the same type of clinical outcome event into a merged node and merging the edges between two merged nodes into a single edge; displaying the second merged graph on the interface; The method of claim 1 , comprising:

14. The method of claim 13 , wherein the second merged graph is displayed in the interface prior to displaying the first merged graph.

15. each of said patients being associated with a patient identifier in said database; each merged node in the merged graph representing a treatment event of the same type is associated with the patient identifier of each patient having the one or more diagnostic events, the one or more treatment events, or the clinical outcome event represented by the merged node in the patient's medical history data; The method comprises: receiving, via the interface, a selection of a first merged node representing a first type of treatment event; determining a first patient identifier associated with the first merged node; retrieving medical history data for a first subset of patients from the database using the first patient identifier; processing the historical medical data for a first subset of the patients to generate a first processed result; displaying the first processing result on the interface; The method of claim 1 further comprising:

16. 16. The method of claim 15, wherein the first processing result comprises a survival curve for the first subset of patients.

17. receiving, via the interface, a selection of a second merged node representing a second type of treatment event; determining a second patient identifier associated with the second merged node; retrieving medical history data for a second subset of patients from the database using the second patient identifier; processing the historical medical data for the first subset of patients to generate a second processed result; displaying the first processing result and the second processing result on the interface; 16. The method of claim 15, further comprising:

18. each merged node in the merged graph representing the same type of treatment event or the same type of clinical outcome event is associated with the patient identifier of each patient having the one or more diagnosis events, the one or more treatment events, or the clinical outcome event represented by the merged node in the patient's medical history data, and with the time of the one or more diagnosis events, the one or more treatment events, or the clinical outcome event since the patient was first diagnosed with a disease; The method further comprises:

16. The method of claim 15, further comprising displaying a progression of events with respect to time for each patient represented in the merged graph based on the patient identifier and the time associated with each merged node representing the same type of treatment event or the same type of clinical outcome event in the merged graph.

19. receiving medical data of a patient; comparing the medical data of the patient with medical data of a first subset of the patients; performing a clinical prediction for the patient based on the first processing result and the comparison result; 16. The method of claim 15, further comprising:

20. 20. A computer readable medium storing a plurality of instructions for controlling a computer system to perform the operations of the method according to any one of claims 1 to 19.

Images