Computer-implemented method, computer system, computer-readable medium, and program

Abstract

To provide a computer-implemented method, a system, a computer-readable storage medium and a program for evaluating reduction of a disease risk.SOLUTION: In a method, patient data of a patient is received, selection of a disease outcome is received, and a risk score of the disease outcome selected by the patient is determined. The determination uses the patient data. Therapy options may be generated on the basis of the patient data according to a medical record data structure. Further in the method, a therapy effect for each of the therapy options is determined, the risk score is changed, the therapy effects are compared, recommendation of at least one of the therapy options is provided by comparison with the therapy effects.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to assessing disease risk, and more particularly to a method, system, computer readable medium and program for assessing disease risk reduction in a patient. [Background technology]

[0002] In recent years, chronic diseases have become the leading cause of death and disability. By 2020, chronic diseases are expected to account for 73% of all deaths and 60% of the global burden of disease. Examples of major chronic diseases include diabetes, hypertension, hyperlipidemia, chronic obstructive pulmonary disease (COPD), and cardiovascular and cerebrovascular diseases. Therefore, the prevention and treatment of chronic diseases are important. Summary of the Invention [Problem to be solved by the invention]

[0003] The present disclosure aims to provide a computer-implemented method, system, computer-readable medium, and program for assessing a patient's disease risk reduction. [Means for solving the problem]

[0004] According to exemplary embodiments of the present invention, a computer-implemented method, computer system, computer-readable medium, and program can assess a reduction in disease risk. Patient data can be received for a patient. A selection of disease outcomes can be received. A risk score for the selected disease outcome that the patient will experience can be determined. Treatment options can be generated based on the patient data and by accessing a medical record data structure. A treatment effect for each of the treatment options can be determined. The treatment effect can modify the risk score. The treatment effects can be compared. At least one of the treatment options can be recommended based on the comparison of the treatment effects.

[0005] In another exemplary embodiment of the present invention, the computer-implemented method, computer system, computer-readable medium, and program can also assess disease risk reduction. Patient data can be received for a patient. A risk score of a selected disease outcome that the patient will experience can be determined. The determination can use the patient data. Treatment options can be generated based on the patient data and by accessing a medical record data structure. The treatment options can include individual treatment options and at least one combination of treatment options. A risk score achieved by each treatment option can be determined. The reduced risk scores can be compared. At least one of the treatment options can be recommended in response to the comparison of the reduced risk scores.

[0006] The above and other objects, features, and advantages of the present disclosure will become more apparent through a more detailed description of several embodiments of the present disclosure in the accompanying drawings. In various embodiments of the present disclosure, generally the same reference numerals refer to the same components. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 illustrates a cloud computing node according to one embodiment of the present invention. [Figure 2] FIG. 2 illustrates a cloud computing environment in accordance with one embodiment of the present invention. [Figure 3] FIG. 3 illustrates an abstract model layer according to one embodiment of the present invention. [Figure 4] FIG. 4 is a flow chart illustrating an exemplary method for assessing disease risk reduction according to one embodiment of the present disclosure. [Figure 5] FIG. 5 illustrates an example of a patient node graph according to one embodiment of the present disclosure. [Figure 6] FIG. 6 shows an example of a disease outcome association graph according to an embodiment of the present disclosure. [Figure 7] FIG. 7 shows an embodiment of a therapy tree illustrating the relationships between therapy modalities according to an embodiment of the present disclosure. [Figure 8] FIG. 8 shows a modified treatment tree compared to the treatment tree shown in FIG. [Figure 9A] FIG. 9A illustrates an example of a medical record data structure according to an embodiment of the present disclosure. [Figure 9B] FIG. 9B shows a modified medical record data structure compared to the medical record data structure shown in FIG. 9A. DETAILED DESCRIPTION OF THE INVENTION

[0008] Detailed embodiments of the claimed structures and methods are disclosed below; however, it should be understood that the disclosed embodiments are merely exemplary of the claimed structures and methods, which may be implemented in various forms. However, the present invention may be implemented in many different forms and should not be construed as limited to the exemplary embodiments set forth in this disclosure. Rather, these exemplary embodiments are provided so that this disclosure will be consistent and complete, and will convey the full scope of the present invention to those skilled in the art. In this disclosure, details of well-known features and techniques are omitted so as not to unnecessarily obscure the presented embodiments.

[0009] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementations of the teachings recited in this disclosure are not limited to cloud computing. Rather, embodiments of the present invention may be implemented in combination with any other type of computing environment now known or later developed.

[0010] Cloud computing is a service delivery model for on-demand network access that provides convenient access to a shared pool of rapidly provisioned and openly configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) with minimal administrative effort or interaction with the service provider. This cloud model includes at least five characteristics, at least three service models, and at least four deployment models.

[0011] Its features are as follows:

[0012] On-demand self-service: Cloud consumers are automatically provisioned with computing capacity, such as server time and network storage, as they need it, without any human interaction with the service provider.

[0013] Widespread network access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by different thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0014] Resource Sharing: Using a multi-tenant model, a provider's computing resources are shared to serve multiple consumers, with different physical and virtualized resources dynamically allocated and reallocated as needed. A sense of location independence exists, such that consumers generally have no control or knowledge of the exact location (e.g., country, state, or data center) of the resources provided, but can specify location at a higher level of abstraction.

[0015] Rapid Elasticity: Capabilities can be provisioned quickly and elastically, sometimes automatically, to quickly scale out and quickly release and quickly scale in. To the consumer, the capabilities available for provisioning often appear unlimited and can be purchased at any time and in any quantity.

[0016] Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at several levels of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of the services being used.

[0017] The service model is as follows:

[0018] Software as a Service (SaaS): The functionality offered to the consumer is the use of the provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through a thin-client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or individual application functionality, except for limited user-specific application configuration settings.

[0019] Platform as a Service (PaaS): The capability offered to consumers is to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does control the deployed applications and, possibly, the configuration of the application hosting environment.

[0020] Infrastructure as a Service (IaaS): The functionality provided to the consumer is the provision of processing, storage, network, and other basic computing resources on which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, deployed applications, and possibly limited control over select networking components (e.g., host firewalls).

[0021] The deployment model is as follows:

[0022] Private Cloud: Cloud infrastructure operates solely for one organization. It can be managed by that organization or a third party and can exist on or off-premises.

[0023] Community Cloud: Cloud infrastructure is shared by several organizations to support a specific community with common interests (e.g., mission, security requirements, policy, and compliance considerations). It can be managed by those organizations or a third party and can reside on or off premises.

[0024] Public Cloud: Cloud infrastructure is made available to the public or large industry groups and is owned by organizations that sell cloud services.

[0025] Hybrid Cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that allow for data and application portability (e.g., cloud bursting for load balancing between clouds).

[0026] Cloud software is service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure, which comprises multiple interconnected nodes.

[0027] Referring to Figure 1, a schematic of one embodiment of a cloud computing node is shown. Cloud computing node 10 is intended only as one example of a preferred cloud computing node and is not intended to suggest any limitation on the scope of use or functionality of the embodiments of the present invention described in this disclosure. In any event, cloud computing node 10 may implement and / or perform any of the functions described above.

[0028] Cloud computing node 10 may include a portable electronic device, such as a communication device, operating in conjunction with computer system / server 12, or numerous other general-purpose or special-purpose computing systems or configurations. Examples of well-known computing systems, environments, and configurations, or combinations thereof, suitable for use with computer system / server 12 may include, but are not limited to, personal computer systems, server computer systems, thin clients, handheld or laptop devices, multiprocessor systems, microprocessor systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0029] The computer system / server 12 may be described in the general context of system-executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system / server 12 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0030] 1, computer system / server 12 within cloud computing node 10 is shown in the form of a general-purpose computing device. Components of computer system / server 12 may include, but are not limited to, one or more processors or processing units 16, system memory 28, and a bus 18 coupling various system components from system memory 28 to processor unit 16.

[0031] Bus 18 may represent any one or more of several bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, or a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures may include an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0032] Computer system / server 12 includes a variety of computer system-readable media, which can be any media that can be accessed and used by computer system / server 12, and can include both volatile and nonvolatile media, removable and non-removable media.

[0033] System memory 28 includes readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Computer system / server 12 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example, storage system 34 may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk drive (e.g., a floppy disk), and an optical disk drive may be provided for reading from and writing to a CD-ROM, DVD-ROM, or other optical media, removable, non-volatile optical disk. As further shown and described below, system memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of embodiments of the present invention.

[0034] The programs / utilities 40 include a set (at least one) of program modules 42, which may be stored, illustratively but not limited to, in the system memory 28. An operating system, one or more application programs, other program modules, and program data may also be stored in the system memory 28. The operating system, one or more application programs, other program modules, and program data, or some combination thereof, may each include an implementation of a networking environment. The program modules 42 generally perform the functions and / or methodologies of embodiments of the present invention described in this disclosure.

[0035] The computer system / server 12 may also communicate with one or more external devices 14, such as a keyboard, pointing device, display 24; one or more devices that allow a user to interact with the computer system / server 12; or any device (e.g., network card, modem, etc.) that allows communication between the computer system / server 12 and one or more computing devices. Such communication occurs through input / output (I / O) interface 22. Furthermore, computer system / server 12 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), and combinations thereof, via network adapter 20. As shown, network adapter 20 communicates with other components of computer system / server 12 via bus 18. It should be understood that other hardware and / or software components, not shown, may be used in combination with computer system / server 12. Examples include, but are not limited to, microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0036] FIG. 2 illustrates an exemplary cloud computing environment 50. As illustrated, the cloud computing environment 50 includes one or more cloud computing nodes 10, with which communicate local computing devices used by cloud consumers, such as a personal digital assistant (PDA) or cellular phone 54a, a desktop computer 54b, a laptop computer 54c, or an automobile computer system 54n, or any combination thereof. The cloud computing nodes 10 can communicate with each other. They can be physically or virtually grouped in one or more networks (not shown), such as the private, community, public, or hybrid clouds described above, or any combination thereof. The types of computing devices 54a-n illustrated in FIG. 2 are for illustrative purposes only; it is understood that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of computerized device through any type of network or addressable network connection (e.g., a web browser), or both.

[0037] Referring now to Figure 3, a set of functional abstraction layers is shown provided by the cloud computing environment 50 of Figure 2. It should be understood that the components, layers, and functions shown in Figure 3 are intended to be illustrative only, and that embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0038] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include a mainframe 61, multiple servers based on a RISC (reduced instruction set computer) architecture 62, multiple servers 63, multiple blade servers 64, multiple storage devices 65, and network and networking components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0039] The visualization layer 70 provides an abstraction layer from which embodiments of virtual entities, described below, are provided: virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75.

[0040] In one embodiment, the management layer 80 may provide the following functions: A resource provisioning unit 81 provides dynamic acquisition of computing resources and other resources used to perform tasks within the cloud computing environment. A metering and pricing unit 82 provides cost tracking as resources are used within the cloud computing environment and provides accounting or billing for the consumption of these resources. In one embodiment, these resources may include application software licenses. A security unit provides identification and authentication of cloud consumers and tasks, as well as protection of data and other resources. A user portal unit 83 provides accessibility to the cloud computing environment and system administrators for consumers. A service level management unit 84 provides allocation and management of cloud computing resources to meet required service levels. A service level agreement (SLA) planning and fulfillment unit 85 pre-provisions and acquires cloud computing resources required for future requests according to SLAs.

[0041] The workload layer 90 provides examples of functionality for utilizing a cloud computing environment. Examples of workloads and functionality provided by this layer include mapping and navigation 91, software development and lifetime management 92, virtual classroom education delivery 93, data analytics processing 94, transaction processing 95, and disease risk reduction assessment 96.

[0042] When performing a typical chronic disease risk assessment, demographic patient data, vital signs, laboratory tests, etc. are received as input data. A risk assessment algorithm or model is used for a given disease outcome to derive a risk score and corresponding medical prescription. Here, a possible disease outcome is having a specific disease or having consequences caused by the disease. Death, hearing loss, etc. are possible outcomes. One example of a risk assessment algorithm and model is the Framingham Risk Model, which is used for cardiovascular disease. In a risk assessment report for a patient, a risk score for a given disease outcome can be shown and several prescriptions can be provided. For example, for a patient at high risk for chronic obstructive pulmonary disease (COPD), a possible prescription for the patient is to "quit smoking." This prescription, which results in a positive treatment for the patient's future health course, can be referred to as a treatment prescription.

[0043] Some treatment instructions are based on clinical guidelines. In such cases, treatment instructions are provided to patients based on established clinical guidelines. This type of guideline usually provides a general guide to treatment but does not provide a quantitative evaluation of how effective the treatment will be. In addition, the guideline does not provide information on risk factors.

[0044] Another method for providing treatment recommendations involves assessing risk by varying the value of a risk factor. In other words, this approach involves comparing changes in risk score to changes in the value of a risk factor. Here, a risk factor is a piece of patient data used as input for a risk assessment algorithm or model. For a patient with hypertension, for example, blood pressure is considered a risk factor. If the patient does not lower their blood pressure, i.e., if they do not lower their risk factors, the patient's risk score for experiencing a CVA may be 0.8. If the patient lowers their blood pressure, the patient's risk score for CVA may decrease to 0.4. Lowering blood pressure constitutes a treatment for the patient's health. This method uses two assessments with different inputs to the same model, but it cannot demonstrate the actual effectiveness of the treatment. In addition, this comparison method does not allow for some risk factors, such as the patient's age and gender, to be controlled for or varied.

[0045] Quantitative evaluation of treatment options for disease has been difficult because most researchers do not have the resources or time necessary to select and utilize a battery of risk assessments in medically controlled experiments to evaluate the pros and cons of different treatments for different diseases.

[0046] The methods, computer systems, computer-readable media, and programs described in this disclosure assist physicians, healthcare professionals, and patients by helping healthcare professionals utilize values ​​determined in medical studies to quantitatively evaluate potential health treatment options and reduce the risk of negative health or disease outcomes. Using publicly available data to calculate risk scores, along with the solutions provided in this disclosure, automatically and accurately evaluates different treatment options and combinations of different treatment options to provide quantitative and effective recommendations without requiring researchers to conduct lengthy medically controlled experiments.

[0047] FIG. 4 is a flow chart illustrating a process 400 for assessing disease risk reduction according to the present disclosure.

[0048] The disease risk reduction process according to embodiments of the present disclosure can be implemented in at least one embodiment by computer system / server 12 shown in FIG.

[0049] After start 401 of process 400 of Figure 4, step 402 generates a medical record data structure. The medical record data structure includes knowledge tables or medical record tables that provide information from medical research linking patient data based on performed tests to risk and disease outcomes.

[0050] Generating a medical record data structure in step 402 involves collecting information and recording the collected information in a data structure, such as a knowledge table. The data structure includes knowledge records derived from medical literature or medical studies. The knowledge records of the data structure may also or alternatively include summaries of information from portions of medical literature or from medical studies. Each knowledge record records information that fits a particular group of distributions for patient data, given disease outcomes, potential treatment modalities, and corresponding relative risk reductions. Table 1, provided below, shows an example of such a knowledge table. In at least some embodiments, the knowledge table records the names or codes of referenced literature or referenced studies.

[0051] Patient data may include, for example, demographic data, vital signs, health measurements, and laboratory test results, or combinations thereof. Demographic data may include, for example, the height, weight, age, and gender of each study patient. Vital signs may include, for example, the temperature, blood pressure, heart rate, and respiratory rate of each study patient. Laboratory test results may include, for example, low-density lipoprotein cholesterol (LDL-C), e.g., LDL-C 2 mmol / L; high-density lipoprotein cholesterol (HDL-C), e.g., HDL-C 3 mmol / L; blood glucose level, e.g., blood glucose level 7 mmol / L; and serum uric acid level, e.g., serum uric acid level 450 μmol / L. Medical records may also include links between patient diagnoses and their patient data. For example, patient data may include links or trends to patients or patient groups with atherosclerotic cardiovascular disease (ASCVD), hyperlipidemia, or diabetes. These specific data discussed above are exemplary. Data other than the examples provided above can be included in the patient data that is part of the medical record included in the generated medical record data structure. The medical record can include information about risk factors for a patient or group of patients. For example, certain patient vital signs, health measurements, or laboratory test results, or a combination thereof, can be recorded along with corresponding risk factors.

[0052] Table 1, presented below, is an example of a medical record data structure that may be generated in step 402 of process 400. In Table 1, the multiple references or studies are generally referred to as R1, R2, and R3. Table 1 contains three rows, each of which is an entry for information from three medical references R1, R2, and R3.

[0053] [Table 1]

[0054] In Table 1, information from document R1 includes information about a patient with patient data P1, and if treatment measure I1 is used, disease outcome O1 decreases to 0.31. Table 1 is an example of a medical record data structure that can be generated in step 402.

[0055] In another embodiment of the present disclosure, the knowledge table can lack a "Patient Data" column, and the recorded RRR for a treatment modality applies to all possible patients or everyone. In a further embodiment of the present disclosure, the collected information can be organized into multiple tables. These tables can, for example, lack an "Outcome" column, and each of the tables can be used for a specific outcome.

[0056] The ways in which the collected information is organized as shown in the examples are not the only ways that may be done in accordance with this disclosure. Other ways of organizing information are also possible in accordance with this disclosure.

[0057] 9A illustrates a medical record table 902, which is an example of a medical record data structure according to some embodiments. Medical record table 902 is part of Example A, an implementation of process 400, which is further disclosed in the ensuing disclosure. Medical record table 902 includes six columns and five rows. Each column represents a different category of information. Each row corresponds to information from a different medical study or medical literature. Thus, medical record table 902 includes a first medical record table row 904 and four other rows of data from four other medical studies or four other medical literatures that correspond to and contain information. First medical record table row 904 provides information based on a medical study approved by Estess and published in 2002.

[0058] The first and second columns, "P" and "P:Extended," provide patient data information. References in the first and second columns refer to entries or nodes in the patient data node graph 500, described subsequently and shown in FIG. 5. The third column, "T," refers to entries or nodes in the therapy tree 700, described subsequently and shown in FIG. 7. The fourth column, "O," refers to entries or nodes in the disease-outcome relationship graph 600, described subsequently and shown in FIG. 6. The fifth column, "RRR," refers to relative risk reduction values, described in more detail below. The relative risk reductions in the fifth column are values ​​that indicate the reduction or relative risk reduction in the chance that a patient who fits the patient data categories in the first two columns and is provided with the therapy option listed in the third column will experience the disease outcome listed in the fourth column. The amount of this relative risk reduction in the fifth column can be that presented in a medical study or medical publication related to the row, for example, an RRR of 0.31 reduced risk of experiencing disease outcome 602a presented in the Estess 2002 medical study for patients with patient data 502a and 502d who were administered the treatment option of 602a.

[0059] Thus, medical record table 902, when used in conjunction with additional graphs or trees, can provide more information than that provided in Table 1, and more specifically, in the columns for patient data, treatment modalities, and outcomes.

[0060] The medical record data structure can be generated manually by a medical professional who collects and reviews various medical studies and / or medical literature. Alternatively, the medical record data structure can be generated by a computer program that implements natural language processing (NLP) techniques and scans medical studies and / or medical literature that is uploaded to a computer, such as computer system / server 12. Additionally or alternatively, the computer program can scan the Internet for published medical studies and / or published medical literature, collect such published works or fragments, and apply natural language processing (NLP) to search for new, relevant studies or medical literature to enter into the medical record data structure. The medical record data structure can be generated in spreadsheet software or some other suitable information storage software that allows the stored information to be quickly and efficiently searched and analyzed by a processor, such as processing unit 16. The medical record data structure can be stored in a memory, such as memory 28, and displayed on a screen, such as display 24.

[0061] Step 404 of process 400 involves creating a patient data node graph. Figure 5 is an example of a patient data node graph 500 according to one embodiment of the present disclosure. Patient data node graph 500 is part of Example A mentioned in step 402 above. Patient data node graph 500 illustrates the relationship between two different types of patient data—one from a diagnosis, namely, a diagnosis of acute myocardial infarction (AMI), and the other from a patient's age.

[0062] When a patient receives a diagnosis of acute myocardial infarction (AMI), the AMI diagnosis can be classified into two subtypes: ST-elevation acute myocardial infarction (STEMI) and non-ST-elevation acute myocardial infarction (NON-STEMI). Considering that some literature includes treatment for only one of the AMI subtypes, e.g., treatment for STEMI but not NON-STEMI, classification into two subtypes can help provide more accurate predictions. Patient data node graph 500 in FIG. 5 illustrates the relationship between AMI, STEMI, and NON-STEMI diagnoses. Medical record table 902, shown in FIG. 9A, has entries in the first and second columns that reference nodes from patient data node graph 500.

[0063] The patient data node graph 500 in FIG. 5 can also be thought of as a data structure and illustrates how hierarchical information among patient data is represented and recorded. In FIG. 5, the diagnoses of AMI, STEMI, and NON-STEMI are represented as first, second, and third patient data nodes 502a, 502b, and 502c in the graph. Here, a solid arrow 506 in FIG. 5 indicates a relationship between entities represented by multiple nodes. Because of this relationship, the entity or information represented by the starting node of the solid arrow 506 is a subtype of the entity or information of the end node of the arrow. For example, in FIG. 5, the STEMI diagnosis (represented by the second patient data node 502b) is a subtype of the AMI diagnosis (represented by the first patient data node). The NON-STEMI diagnosis (represented by the third patient data node 502c) is also an AMI diagnosis (represented by the first patient data node 502a).

[0064] In some embodiments, the patient data can also include extended data such as age. Thus, for this embodiment, a combination of age and diagnosis can be used for matching in the medical record data structure. In FIG. 5, the fourth patient data node 502d shows patient data that takes into account the patient's age. A dashed arrow 504 from the fourth patient data node 502d terminates at the first patient data node 502a. The dashed arrow 504 accompanies the "AMI" diagnosis with "Age" for evaluation and prediction purposes.

[0065] 5, the patient data node graph 500 categorizes patient ages into four groups: ≦55 years (represented by the fifth patient data node 502e), 56-64 years (represented by the sixth patient data node 502f), 65-74 years (represented by the seventh patient data node), and ≧75 years (represented by the eighth patient data node 502h). Solid arrows 506 extend from the fifth, sixth, seventh, and eighth patient data nodes 502e, 502f, 502g, and 502h to the fourth patient data node 502d, indicating that the fifth, sixth, seventh, and eighth patient data nodes 502e, 502f, 502g, and 502h are of the subtype represented by the fourth patient data node 502d.

[0066] The patient data node graph 500 may be manually generated by a medical professional who collects and evaluates various medical studies or medical literature, or the medical record data structure generated in step 402, or a combination thereof. Alternatively, the patient data node graph 500 may be generated by a computer program that performs natural language processing (NLP) techniques and scans medical studies and / or medical literature that is uploaded to a computer, such as computer system / server 12. Additionally or alternatively, the computer program may scan the Internet for published medical studies and / or published medical literature and collect such published works or fragments and apply natural language processing (NLP) to search for new relevant studies or medical literature to enter into the patient data node graph 500. The patient data node graph 500 may be generated using graphing software or some suitable software that allows information to be recorded in a graph format that can then be quickly and efficiently searched and analyzed by a processor. This patient data node graph 500 can be stored in a memory, such as memory 28, and displayed on a screen, such as display 24.

[0067] The patient data node graph 500 can be used in combination with medical record data structures to help guide medical practitioners and patients in making better decisions about what medical and patient benefits may be produced or achieved with certain medical treatments, and therefore what possible treatments may be best to recommend.

[0068] Step 406 of process 400 generates a disease-outcome relationship graph. FIG. 6 illustrates an example of a disease-outcome relationship graph 600 according to an embodiment of the present disclosure. The disease-outcome relationship graph 600 of FIG. 6 is part of Example A, mentioned above in the discussion of steps 402 and 404. The disease-outcome relationship graph 600 illustrates the relationship between possible disease outcomes resulting from a given disease. The disease-outcome relationship graph 600 of FIG. 6 also illustrates one way in which hierarchical information regarding disease outcomes can be viewed as a data structure and can be recorded and represented.

[0069] In Figure 6, the solid arrows 506 have the same meaning as the solid arrows 506 used in Figure 5. For example, one of the solid arrows 506 indicates that the second disease outcome node 602b represents an outcome that is a subtype of the outcome represented by the first disease outcome node 602a. According to Figure 6, myocardial infarction (MI) (represented by the second disease outcome node 602b) is a subtype of major adverse cardiovascular event (MACE) (represented by the first disease outcome node 602a). Cardiovascular death (represented by the fourth disease outcome node 602d) is a subtype of MACE (supported by the first disease outcome node 602a) and is also a subtype of mortality (represented by the third disease outcome node 602c).

[0070] Disease-outcome relationship graph 600 can be manually generated by a medical professional who collects and evaluates various medical studies or medical literature, or the medical record data structure generated in step 402, or a combination thereof. Alternatively, disease-outcome relationship graph 600 can be generated by a computer program that performs natural language processing (NLP) techniques and is uploaded to a computer, such as computer system / server 12, to scan medical studies and / or medical literature. Additionally or alternatively, the computer program can scan the Internet for published medical studies and / or published medical literature and collect such published works or snippets and apply natural language processing (NLP) to search for new, relevant studies or medical literature to input into disease-outcome relationship graph 600. Disease-outcome relationship graph 600 can be generated using graphing software or some suitable software that allows information to be recorded in a graph format that can then be quickly and efficiently searched and analyzed by a processor. These disease-outcome relationship graphs 600 can be stored in a memory, such as memory 28, and can be displayed on a screen, such as display 24.

[0071] The disease outcome relationship graph 600, in combination with medical record data structures, and optionally in combination with the patient data node graph 500, can be used to help guide medical practitioners and patients in making better decisions about what medical and patient effects certain medical treatments will produce, and therefore what treatments are best recommended to reduce the risk of encountering potential negative disease outcomes.

[0072] Step 408 of process 400 involves generating a therapy tree. FIG. 7 illustrates an example of a therapy tree 700 according to one embodiment of the present disclosure. The therapy tree 700 of FIG. 7 is part of Example A, mentioned above, in consideration of steps 402, 404, and 406. The therapy tree 700 illustrates the relationship between certain possible disease treatment options that can be performed to treat a patient and reduce the chance that the patient will experience a negative outcome. The therapy tree 700 of FIG. 7 can also be thought of as a data structure, illustrating how hierarchical information regarding treatment options can be displayed and recorded. Some treatments, when applied to a patient, are not performed or applied in combination with other treatments. Such treatments can be referred to as exclusive treatments. Alternatively, some treatments can be performed in combination with one or more other therapeutic modalities and can be referred to as inclusive modalities. A treatment can include one or more pharmaceutical modalities, one or more non-pharmaceutical modalities, or a combination of both. For example, treatments may include the treatment "quit smoking," which may be considered a non-pharmaceutical measure, and the pharmaceutical measure "take aspirin."

[0073] FIG. 7 illustrates a therapy tree 700, in which branch nodes represent therapeutic approaches. The first and second generic nodes 702a and 702b in FIG. 7 indicate that at least some of their child nodes are recommended or potential therapeutic approaches to be administered to the patient in combination. For example, a patient may preferentially receive thrombolysis (represented by the first therapy node 708a) in combination with regular aspirin intake (represented by the second therapy node 708b). Thrombolysis, also known as thrombolytic therapy, involves the use of drugs to dissolve dangerous clots in blood vessels, improving blood flow and preventing damage to tissues and organs. Thrombolysis (represented by the first therapy node 708a) may also be administered in combination with beta-blocker therapy (represented by the third therapy node 708c), angiotensin-converting enzyme inhibitors (ACEIs) (supported by therapy node 708d), or both. Beta-blockers, also known as beta-adrenergic blockers, are medications or drugs that lower blood pressure. In some examples, the first, second, third and fourth therapy nodes 708a, 708b, 708c, 708d may be considered as comprehensive therapies and may be applied to a patient in combination with the following exclusive therapies corresponding to the fifth, sixth, seventh and eighth therapy nodes 708e, 708f, 708g, 708h:

[0074] 7 indicates that its child nodes are typically used exclusively when used as a therapy for a patient. For example, primary angioplasty (shown as fifth therapy node 708e), primary coronary artery bypass grafting (“CABG”) (shown as sixth therapy node 708f), primary percutaneous transluminal coronary angioplasty (“PTCA”) (shown as seventh therapy node 708g), and primary coronary intervention (“primary PCT”) (shown as eighth therapy node 708h) cannot be applied in a combined manner with one another, but instead should be performed independently of other exclusive therapy nodes shared with some patient nodes, which in this case share the first exclusive node 704a as a parent or descendant node. In the case of exclusive node 704a and its four child nodes, the therapies represented by the fifth, sixth, seventh, and eighth therapy nodes 708e, 708f, 708g, and 708h should be applied to a patient independently and should not be applied in combination with one another. In some embodiments, the therapies branching out from the exclusive node cannot be used in combination with any other therapies, including any of the therapies that are child or branch nodes of a generic node such as the second generic node 702b, e.g., in some embodiments, the first, second, third, and fourth therapy nodes 708a, 708b, 708c, and 708d.

[0075] The first generic node 702a is shown to have several great-grandchild nodes representing generic therapies. These nodes representing generic therapies are first, second, third, and fourth therapy nodes 708a, 708b, 708c, and 708d. The first generic node 702a is also shown to have several great-grandchild nodes representing exclusive therapies. These nodes representing exclusive therapies are fifth, sixth, seventh, and eighth therapy nodes 708e, 708f, 708g, and 708h. The second generic node 702b shown in FIG. 7 is shown to have all or some descendant nodes representing generic therapies. Exclusive nodes typically have descendant nodes representing therapies that are not required to be administered to a patient in combination with each other (and should not be combined with any of these other descendant nodes).

[0076] While graph or tree representations of patient data, disease-outcome relationships, and treatments are not required in some embodiments, this type of data structuring allows for a more accurate organization of information collected from literature or research, and thus helps achieve more accurate matching and predictions.

[0077] Step 410 of process 400 shown in FIG. 4 is receiving patient data from a patient. A patient is a person or animal whose disease risk reduction can be assessed. In one embodiment, the patient data can include one or more patient data items or elements. These data items or elements can include the patient's demographic data, vital signs, health measurements, or laboratory test results. Demographic data can include the patient's name, height, weight, age, gender, etc. Vital signs can include the patient's temperature, blood pressure, heart rate, respiratory rate, etc. Laboratory test results can include, for example, low-density lipoprotein cholesterol (LDL-C), e.g., LDL-C, 2 mmol / L; high-density lipoprotein cholesterol (HDL-C), e.g., HDL-C, 3 mmol / L; blood glucose level, e.g., blood glucose level, 7 mmol / L; and serum uric acid level, e.g., serum uric acid level, 450 μmol / L. Medical records can also include links between the patient's diagnostic results and their patient data. For example, the patient data may have a link or propensity for a patient or patient group with arteriosclerotic cardiovascular disease (ASCVD), hyperlipidemia, or diabetes. These particular data listed above are exemplary. Data other than the exemplary data listed above may be included in the patient data that is part of the medical record included in the generated medical record data structure. The medical record may include information regarding risk factors for a patient or patient group. For example, certain vital signs, health measurements, or laboratory test results of a patient, or a combination thereof, may be recorded along with corresponding risk factors. In other words, in at least some embodiments, the risk factors used by the model are a subset of the patient data.

[0078] For Example A, referred to above for steps 402, 404, 406, and 408, the received patient data includes data indicating that the patient is 60 years old and has been diagnosed as suffering from a STEMI.

[0079] The patient data can be received by a computer, such as computer system / server 12, after an individual, physician, or other healthcare professional accesses the computer on which the medical record data structure and, optionally, the patient data node graph 500, disease-outcome relationship graph 600, and treatment tree 700 are stored. The medical record data structure, patient data node graph 500, disease-outcome relationship graph 600, and treatment tree 700 can be stored in a computer memory, such as memory 28. The computer can be located at a healthcare facility or can be remotely stored in a computer accessible via the cloud and therefore accessible by the patient, or a healthcare professional or physician. The patient accesses a website or app that uses a graphical user interface and queries the patient for personal physical information. The website or app then passes the personal physical information to the computer as patient data.

[0080] Alternatively, a healthcare professional or doctor can access the website or app and provide the patient's physical information as patient data via a graphical user interface. The healthcare professional or doctor can obtain that physical information manually from the patient. The healthcare professional or doctor can provide a physical questionnaire that the patient completes and returns. The healthcare professional or doctor has a separate computer in a rest room or office that the patient can access and that provides patient data that is received by another computer hosting the disease risk reduction assessment program. The healthcare professional or doctor can alternatively visually view the patient information and then type the information into the website, app, or computer program. The healthcare professional or doctor can then enter the individual's physical information into a computer or computing node using the website or app's graphical user interface. In instances where the medical record data structure is stored on another computer, the website or app then passes the individual's physical information as patient data to the computer hosting the medical record data structure. In instances where the medical record data structure is stored on a medical professional's or doctor's local computer, for example in their medical office, the medical professional or doctor enters the individual's physical information using a keyboard or touch screen, such as an external device 14, or speaks into a microphone, allowing the local computer to process and use the information and possibly graphs and trees related to the medical record data structure.

[0081] In step 412 of FIG. 4, possible disease outcomes whose likelihood is to be tested are entered into or received by the computer system. A healthcare professional or patient may be concerned about the likelihood of certain disease outcomes being experienced or lurking in the patient, and the entire method is based on an assessment of at least how the patient's risk of experiencing the disease outcome can be reduced and most effectively mitigated. Therefore, the system needs to know which disease outcomes are being analyzed and whether their risk is desired to be reduced. The patient or healthcare professional can enter the possible disease outcomes into a graphical user interface generated by the computer program and displayed on the screen of the display 24. The computer program can alternatively generate a list of various disease outcomes to be displayed on the display 24 and provide the patient or healthcare professional with the option of scrolling through the generated list to select one of the disease outcomes using the external device 14.

[0082] For example, a healthcare professional or patient may input in step 412 that they are interested in determining whether they should explore the risk of a potential disease outcome of a major adverse cardiovascular event (MACE) based on their patient data. The disease outcome of MACE is input in this embodiment of process 400 according to Example A, as described above for the steps above. Thus, the evaluation of disease risk reduction performed in Example A would be evaluating what treatment would best help a patient who experienced a STEMI at age 60 reduce the risk of experiencing another MACE within, for example, a specific time frame.

[0083] In step 414 of FIG. 4, a risk score for the selected disease outcome that the patient will experience is determined. The determination uses the patient data received in step 410. Determining the risk score may include calculating the risk score using a risk assessment algorithm or model. The risk score is directed toward a particular disease outcome. One example of a risk assessment algorithm or model that may be used is the Framingham Risk Model, which is used for cardiovascular disease. In one embodiment of the present disclosure, the risk score may be described by the following equation (1):

[0084]

number

[0085] In the above formula (1), X is a vector whose elements are composed of patient data including the patient's risk factors required by the risk assessment algorithm or model. r is the risk score that the patient has, will experience, or will encounter a given disease outcome. Here, f() represents the functional relationship between r and X. f(X) is a risk model for calculating the risk score for individual patient data. The risk model can be obtained by applying data analysis through machine learning, deep learning, or other techniques based on the patient's historical data according to medical discovery methods.

[0086] For Example A above, for step 411, several entries in a medical record data structure corresponding to medical literature or derived from medical research indicate that the other MACE risk score is 0.43 for patients between the ages of 57 and 63 who have been diagnosed with STEMI.

[0087] Example B is presented below, which illustrates the determination of a risk score by performing a calculation according to some embodiments. In Example B, a risk model for calculating the MACE (major adverse cardiovascular event) risk of a patient who has suffered an AMI (acute myocardial infarction) includes three risk factors: age, white blood cell count (WBC), and Killip level (killip_score). This risk model calculates the risk of whether the patient will experience a MACE event within 30 days of the AMI. The WBC count is the result of a laboratory test. The Killip level is a doctor's diagnosis of the patient after examining the patient after an AMI. AMI (acute myocardial infarction) is one type of MACE (major adverse cardiovascular event), and the risk score indicates the likelihood that the patient will experience a second MACE, e.g., a second myocardial infarction, within a short period of time, e.g., 30 days. The risk model in this Example B for generating a mortality risk score f(X) is a logistic regression (LR) model, as shown in Equation (2) below.

[0088]

number

[0089] The Killip classification is a system used for individuals who experience an AMI, accounting for physical examination and progression of cardiac disease, to predict and stratify their mortality. Individuals with a low Killip class are less likely to die within the first 30 days after their myocardial infarction than those with a high Killip class. The four Killip classes are: Killip Class I are individuals with no clinical signs of heart disease. Killip Class II describes individuals with pulmonary rasping or constriction sounds, S3, and elevated carotid pressure. Killip Class III are individuals with definite acute pulmonary edema. Killip Class IV describes individuals who are in cardiac shock or hypotension (measured as systolic blood pressure less than 90 mmHg) and have evidence of peripheral vasoconstriction (oliguria, cyanosis, or diaphoresis).

[0090] Calculations were performed using the risk model described above as part of Example B for five different patients diagnosed with AMI to determine their experienced or potential mortality, i.e., risk of death. Patient data from the five patients are given as three variables in the first three columns of Table 2 below, and the calculated risk score for each patient based on the formula is given in the fourth column.

[0091] [Table 2]

[0092] The calculations show that the second patient (aged 56 years) has the highest risk of another MACE within 30 days, while the fifth patient (aged 34 years) has the lowest risk of another MACE within 30 days.

[0093] A patient data item or element from the received patient data may be a risk factor for a first assessment model, but may not be a risk factor for a second risk assessment model. For example, a patient data item such as whether the patient smokes may be a risk factor. For a model for assessing the risk of arthritis, a patient data item such as whether the patient smokes may not be a risk factor.

[0094] Net risk (AR) is defined as the ratio of the number of people experiencing an event to the number of people in the population. When two groups of people or patients include one group receiving a therapeutic treatment and a second group not receiving the therapeutic treatment, the first group is called the treatment group and the second group is called the control or reference group. In the control group, the AR of a specific event, such as experiencing a specific disease outcome, is described as the control group net risk (ARC). In the treatment group, the AR of a specific event, such as experiencing a specific disease outcome, is described as the control group net risk (ART).

[0095] In some alternative embodiments, the risk score determined in step 414 can be determined by looking up data from the medical record data structure generated in step 402. In these embodiments, medical studies or literature, whose information is already recorded in the medical record data structure, may have already determined risk scores for different groups of patients with respect to certain possible disease outcomes. The risk score or risk scores can be entered into the medical record data structure in step 402, such that determining the risk score in step 414 can include accessing the medical record data structure and retrieving the risk score from the medical record data structure based on the patient data. The computer program uses the patient data as input to search through entries stored in the medical record data structure and find a match with an entry that also has the same patient data. The risk score associated with that entry can then be returned to a processor or medical professional or can be temporarily stored for calculations to be performed by the computer program.

[0096] For example, a medical record data structure similar to the medical record table 902 shown in Figure 9A can exist entitled "r" for risk score. This alternative medical record data structure can indicate that for patients between the ages of 50 and 59 who have laboratory test results indicating their total cholesterol level is 290 mg / dL, the r for MACE (represented by the first disease outcome node 602a in Figure 6) is 0.6, the r for MI (represented by the second disease outcome node 602c in Figure 6) is 0.35, the r for mortality (represented by the third disease outcome node 602c in Figure 6) is 0.5, and the r for cardiovascular death (represented by the fourth disease outcome node 602a in Figure 6) is 0.2.

[0097] In step 416 of process 400 shown in Figure 4, the patient data received in step 410 is matched with one or more nodes in the patient data node graph 500 shown in Figure 5. This step may be performed by text search software that scans or reads through the information and text recorded in the patient data node graph 500 and compares that text and information to the text and information in the patient data. For example, if the patient data is of a particular age but the nodes represent a range of possible ages for the patient, software with logical comparison features may also be used. This software may be used and programmed to perform the required matching.

[0098] For example, in Example A, described below, where the patient data received in step 410 includes the patient's age information of 60 years old and the patient has a diagnosis of STEMI, the processor can obtain this patient data and scan the patient data nodes to match the age data with the STEMI diagnosis for the sixth patient data node 502f and the second patient data node 502b, respectively, as part of step 416. This matching node information will be useful to the computer system in subsequent steps when the computer system searches through the medical record data structures coded with the given node numbers within the patient data node graph 500. This matching node information may be stored in a memory, such as memory 28, coupled to a processor, such as processing unit 16, and available for access for subsequent matching and mapping.

[0099] In step 418 of process 400 shown in Figure 4, the disease outcomes entered in step 412 are matched with nodes from disease-outcome relationship graph 600 shown in Figure 6. The same or similar software used to perform the matching of step 416 can also be used to perform the matching of step 418.

[0100] For example, in embodiment A, where a major adverse cardiovascular event (MACE) is selected and entered as described in step 412 above, the matching in step 418 scans the disease-outcome relationship graph 600 to match the entered disease with a first disease-outcome node 602a representing the disease outcome of the MACE. This matching node information will be useful to the computer system in subsequent steps when the computer system searches through the medical record data structures coded with the given node numbers in the disease-outcome relationship graph 600. This matching node information may be stored in a memory, such as memory 28, connected to a processor, such as processing unit 16, and available for access for subsequent matching and mapping.

[0101] In step 420 of process 400 shown in FIG. 4, the nodes matched in steps 416 and 418 are matched with records in the medical record data structure generated in step 402. The matching in step 420 is used to find treatment options related to the received patient data and the disease outcomes one wishes to analyze and the risk of which one wishes to reduce. The same or similar software used to perform the matching in steps 416 and 418 can also be used to perform the matching in step 420. The treatment options found can be stored in a memory, such as memory 28, connected to a processor, such as processing unit 16, and available for access for subsequent matching and mapping.

[0102] In embodiment A, when the sixth patient data node 502f matched in step 416, the second patient data node 502b, and the first disease outcome node 602a matched in step 428 are used in step 420, they can be matched to records in a medical record table 902 shown in Figure 9A. The medical record table 902 is one example of a medical record data structure.

[0103] The matching in step 420 for embodiment A recognizes that the second, third, fourth, and fifth data columns, plus row 904 of the first medical record table, match the first disease outcome node 602a, but not the fourth data row, whose entry "602b" in its disease outcome column O corresponds to the second disease outcome node 602b, but not the first disease outcome node 602a.

[0104] The matching in step 420 also recognizes that the third data row alone initially matches the second patient data node 502b and the sixth patient data node 502f. The third data row is the data row with the entry "502b" corresponding to the first patient data node 502b. The third data row does not contain any expression that matches the sixth patient data node 502f, but the third data row does not contain any node information that contradicts the sixth patient data node 502f. The third data row has a blank entry for the "P: Extension" column and therefore does not contain patient data that contradicts the sixth patient data node 502f.

[0105] A comparison of the matching between the medical record table 902 and the patient data node (the first, second, third, and fifth data rows are patient matches) and the matching between the disease outcome node of the medical record table 902 (the third data row is the outcome match) performed in step 420 of Example A indicates that the initial match of the third data row alone is the matching row that should be used to find a treatment option. Therefore, the treatment information "708e" indicated in the third column "I" in the third data row is considered to have been found by the initial match.

[0106] Thus, when multiple nodes, such as multiple patient nodes, are used for matching, a row or data segment in the medical record data structure is determined if at least one patient data node matches the row or data segment, or if there are no entries in the row or data segment that conflict with entries in other patient data nodes. Of course, if multiple patient data nodes match entries or segments in the data structure, then the group of multiple patient data nodes is determined to match the row or data segment.

[0107] In step 422 of process 400 shown in FIG. 4, the treatment options found in step 420 are mapped to the treatment tree generated in step 408. The same or similar software used to perform the matching of steps 416, 418, and 420 can also be used and programmed to perform the mapping of step 422. The mapping indicates or displays a particular treatment option based on the treatment option information found in step 420. This particular treatment option is then stored in a memory, such as memory 28, coupled to a processor, such as processing unit 16, and made accessible for subsequent presentation to a healthcare professional or patient when providing a recommendation.

[0108] Building on example A provided above, in which nodes were matched to medical record table 902, resulting in the finding of treatment entry "708e," mapping this treatment entry "708e" to treatment tree 700 in example A indicates that this entry corresponds to fifth treatment node 708e, which represents the treatment option of primary angioplasty. The mapping of step 422 for example A also indicates that fifth treatment node 708e is a child node of first exclusive node 704a, which indicates that primary angioplasty, represented by fifth treatment node 708e, cannot be performed in combination with some other possible treatments represented by other child nodes of first exclusive node 704a, i.e., cannot be performed in combination with procedures or treatment options corresponding to sixth, seventh, and eighth treatment nodes 708f, 708g, and 708h. The possible treatment that the patient may undergo primary angioplasty is recorded in a memory, such as memory 28, for embodiment A, ready to be later presented to the patient as part of a recommendation.

[0109] In step 424 of process 400 shown in FIG. 4, ancestor nodes of the graph, medical record data structure, or treatment tree, or a combination thereof, are checked to find additional relevant treatment options. The ancestor nodes are ancestors of the nodes matched in steps 416, 418, and 422. An ancestor node of a first node can be a node connected to the first node higher in the hierarchy defined by the node graph. The same or similar software used to perform the matching of steps 416, 418, and 420 can also be used and programmed to perform the check of step 424. The additional relevant treatment options found can be recorded in a memory, such as memory 28 connected to processing unit 16, and made available for subsequent steps to determine a reduced risk score and, in some instances, accessible for later presentation to a healthcare professional or patient when providing a recommendation. The check to find ancestor nodes assists in finding additional records recorded in the medical regulation data structure that contain relevant information about possible treatment options associated with the selected possible disease outcome.

[0110] For example, in step 424, the patient data node graph 500 checks whether the second patient data node 502b has any ancestor nodes and whether the sixth patient data node 502f has any ancestor nodes. This check determines (1) whether the second patient data node 502b, which indicates a patient diagnosis of AMI, of which STEMI is a subtype, is an ancestor node of the second patient data node 502b, and (2) whether the fourth patient data node 502d, which represents all ages, is an ancestor node of the sixth patient data node, which represents the age range of 56 to 64 years. The check in step 424 for example A in the disease-outcome relationship graph 600 indicates that the first disease-outcome node 602a does not have any ancestor nodes.

[0111] As part of step 424, information regarding the identified ancestor node is returned to the medical record data structure to find any additional entries, columns, or data segments that match the identified ancestor node.

[0112] For example, using the first patient data node 502a and the fourth patient data node 502d identified as relevant ancestor nodes for the received patient data, the medical record data table 902 for the patient for whom the patient data was obtained is searched using the first patient data node 502a and the fourth patient data node 502d as inputs for the search.

[0113] In Example A, this search results in row 904 of the first medical record table being identified as a match because row 904 of the first medical record table associated with the patient data includes "502a" and "502d" as entries in its second column. Row 902 of the first medical record table also matches because the result entry for that result column is result column "602a" which matches the selected or entered disease outcome, MACE. The entered disease outcome may typically be selected with the intent of finding the best treatment to eliminate the disease outcome.

[0114] Even though the first column entry "502a" for this second data row matches information in one of the associated ancestor nodes, the second data row in medical records table 902 still does not match in embodiment A because the second column entry "502e" for this second data row conflicts with the sixth patient data node 502f. The second column entry "502e" corresponds to the fifth patient data node 502e, which corresponds to an age range of 55 years or younger. This age range conflicts with the patient data in embodiment A, where the patient is 60 years old.

[0115] A third row of data in medical record table 902 was previously identified in the initial matching (step 420) of Example A as matching the patient data and selected possible patient outcome.

[0116] The fourth data row in medical record table 902 is not yet identified as a match in Example A because the patient data entry for "502c" corresponding to a non-STEMI diagnosis still conflicts with the initial patient data for a STEMI diagnosis. This non-match is also trivial because neither the first nor second column of the fourth data row directly matches the newly found associated ancestor node. In other words, none of these entries ("502c", blank) directly matches the first patient data node 502a, which is the ancestor node of the second patient data node 502b.

[0117] Considering the patient data, a fifth data row in medical record table 902 is also newly identified as a match for Example A because the fifth data row contains "502" as an entry in its first column. This entry "502a" directly matches a first patient data node 502a, which is identified as an ancestor node to a second patient data node 502b, which corresponds to patient data with a STEMI diagnosis. This new match also occurs because the second column is blank and therefore has no entries that conflict with the second patient data node 502b. This new match also occurs because entry "602a" in the result column directly matches a first disease outcome node 602a, which corresponds to a possible disease outcome of MACE for which effective treatments are sought.

[0118] Thus, checking the ancestor nodes in step 424 in Example A revealed that row 904 and row 5 of the first medical record table, in addition to row 3 of the data, match for the patient data and selected disease outcome.

[0119] Thus, as part of step 424 of embodiment A, therapy "708a" from row 904 of the first medical record table and therapy option "708f" from the fifth data row are also saved as references to the associated therapy options, since their treatment effect information is included within the medical record data structure. The mapping in therapy tree 700 returns a pointer to first therapy node 708a corresponding to thrombolytic therapy corresponding to the information in "708a" and first therapy node 708f corresponding to primary CABG corresponding to the information in "708f." This information is also stored, for example, in memory 28, for reference when providing one or more recommendations to the patient.

[0120] In step 426 of process 400 shown in FIG. 4, a treatment tree, e.g., treatment tree 700, is checked to determine a preferred combination of the found treatment options. The same or similar software used to perform the matching, mapping, and checking described above can also be used and programmed to perform the check of step 426. The determined treatment options are then recorded in a memory, e.g., memory 28, connected to processing unit 16, and made available for the subsequent step of determining a reduced risk score and, in some instances, accessible for subsequent presentation to a healthcare professional or patient when providing a recommendation. The check to determine a preferred combination can, in some instances, help demonstrate that the best treatment includes a specific treatment, specific therapeutic approach, or combination of options.

[0121] For Example A, the therapy tree 700 is checked in step 426 with respect to the identified therapy information "708e," "708a," and "708f" to determine which of the therapy procedures corresponding to this information could be a preferred combination in a treatment plan for the patient to provide the best treatment to reduce the risk of negative disease outcomes. Checking the therapy tree 700 indicates that the fifth and sixth therapy nodes 708e and 708f are both child nodes of the exclusive node 704a and therefore are not preferred for providing to the patient as a combined treatment. Instead, the patient could be offered either a primary angioplasty or a primary CABG, but not both. However, the check also indicates that the angioplasty treatment corresponding to the first therapy node 708a is a child node of the second inclusive node 708b and is not a child node of the exclusive node 704a. Thus, thrombolytic therapy can be preferably combined with either primary angioplasty or primary CABG as two separate treatment possibilities resulting from the combination of individual therapeutic modalities or individual treatment options. Briefly, the two preferred combinations are designated (“708a”, “708e”) and (“708a”, “708f”). These two newly identified combinations are stored in a memory, such as memory 28, for use in subsequent reduced risk score calculations performed by a processor, such as processing unit 16.

[0122] In at least some embodiments, steps 416 and 426 can be combined with one another to configure one or more treatment options based on the patient data.

[0123] 4, step 427 of process 400 may provide a notification to provide more patient data from the patient to enable checking for more matches of treatment options. Step 427 is described in more detail below with respect to Example D.

[0124] In step 428 of process 400 shown in FIG. 4, a reduced risk score is determined for each of the treatment options identified from steps 420, 424, and 427 and for each of the preferred combinations identified in step 426. This determination is performed by a processor, such as processing unit 16, programmed to include certain mathematical formulas that allow the calculation of the reduced risk score to be calculated. This determination also includes checking the medical record data structure to obtain any risk scores, such as relative risk reductions, for the particular treatments recorded in the medical record data structure. The risk score reduction can constitute the treatment effect of each treatment option, and such reduced risk scores also aid in analyzing the treatment effect of the treatment option.

[0125] The net risk reduction (ARR) of a treatment or mitigation measure that reduces the likelihood of an event occurring in a group of people can be calculated by subtracting the net risk in the control group (ARC) from the net risk in the treatment group (ART). In other words, the ARR can be calculated as the calculated difference between the ARs occurring in the treatment and control groups (e.g., ART from ARC). In other words, ARR = ARC - ART. In one example, if the risk of an event occurring in the control group is 40% (ARC = 40%) and the risk of the event occurring in the treatment group is 30% (ART = 30%), the ARR for the treatment with respect to a particular event can be calculated as 40% - 30% = 10% (or 0.1).

[0126] According to some embodiments of the present disclosure, this value is termed the "relative risk reduction" (RRR) and is used to evaluate the effectiveness of hierarchical options and reduced risk scores. Relative risk reduction helps characterize the effectiveness of a treatment in a treatment group. Relative risk reduction (RRR) is determined as follows: RRR = (ARC - ART) / ARC = 1 - ART / ARC. In the example above, if ARC = 40% and ART = 30%, the RRR of a treatment for a particular event is calculated as 1 - 0.75 = 0.25.

[0127] For a particular therapeutic approach, the RRR of the therapeutic approach for a given disease outcome can be collected from existing medical literature or research. For example, if a certain patient takes aspirin regularly, the RRR for cardiovascular death is 0.25. Therefore, aspirin reduces the probability or chance that a patient will experience cardiovascular death.

[0128] For each of one or more treatment options, the treatment effect can be evaluated by considering the impact of each of the one or more treatment options of the corresponding treatment option on the risk score. According to one embodiment of the present disclosure, considering the impact of each of the one or more treatment options on the risk score includes calculating the treatment effect by using a relative risk reduction of the corresponding treatment, where the relative risk reduction is identified or determined from medical knowledge regarding the relevant treatment. According to one embodiment of the present disclosure, the medical knowledge can be obtained from at least one medical publication or study whose information is recorded in a medical record data structure. The determined treatment effect is represented by a reduced risk score, with the lowest reduced risk score corresponding to the treatment with the greatest effect.

[0129] According to one embodiment of the present disclosure, the reduced risk score q is written as Equation (3):

[0130]

number

[0131] In the above equation, T is a vector of treatment options, and f(x) represents the risk score r mentioned above. Here, equation (3) is expanded as equation (4).

[0132]

number

[0133] where n is the number of treatment options in the treatment regimen, and RRR(t) is the risk reduction for treatment option t.

[0134] As described above, in Example A, a total of five treatment options, namely, treatment information “708e,” “708a,” “708f,” (“708a,” “708e”), and (“708a,” “708f”), are generated, which include three treatment options as well as two preferred combinations. Medical record data table 902 shown in FIG. 9A indicates that medical study Estess (2002) concluded that the RRR for treatment “708a” (thrombolysis) was 0.31 (shown in the first medical record table row 904), medical study Chucherat (2003) concluded that the RRR for treatment “708e” (primary angioplasty) was 0.15 (shown in the third data row), and medical study Yusuf (1994) concluded that the RRR for treatment “708f” (primary CABG) was 0.39.

[0135] Equation (3) given above and applicable to Example A can be used to calculate the reduced risk score for each of the three individual treatments described above, as well as the combination of the two preferred treatment options. The calculation starts with the risk score of 0.43 obtained in step 414 of Example A.

[0136] [Table 3]

[0137] These calculations show that the data show that using thrombolysis ("708a") and CABG ("708f") together as a treatment for the patient in Example A resulted in a significant reduction in the risk score. Therefore, the use of thrombolysis ("708a") and primary CABG ("708f") together has the greatest therapeutic effect of the five treatment options listed above.

[0138] In another example, Example D, the medical record table 902 shown in FIG. 9A was also generated in step 402, with MACE also being the disease outcome in step 412, and patient data received including a diagnosis of STEMI, as in Example A. However, unlike Example A, in Example D, the patient data received in step 410 did not include any information regarding the patient's age. During execution of step 416 in Example E, the computer program recognized that a second data row in the medical record table 902 contained a possible match for the patient if the patient had an age of 55 years or less. In particular, the second data row in the medical record table 902 included an entry for "502e" in the "P: Extension" column, and the entry for "502e" was the fifth patient data node 502e shown in the patient data node graph 500 of FIG. 5. The fifth patient data node 502e corresponds to an age of 55 years or less.

[0139] In this situation of Example D, a possible but unconfirmed row match is identified, and a notification can be generated to the physician, healthcare professional, or patient, prompting them to enter the patient's age, allowing the computer program to determine whether a second row of data matches the patient, and if so, includes useful, quantitative data to assist in improving the patient's health plan. This notification is an example of step 427 of process 400. This notification can occur, for example, by generating a graphical user interface notification displayed on display 24. For example, if the computer program executes the notification, the patient or healthcare professional can then enter the patient's age of 48, and the computer program can then determine that the second row of data matches the patient. Thus, unlike Example A, four individual treatment options were found for the patient in Example D. A preferred combination of treatment options was then determined in Example D using the preferred combination check of step 426 in the treatment tree 700. This step 426 for Example D generated seven possible combinations in addition to the four individual treatment options. The preferred set of seven combinations in Example C presented below is the same combination in terms of the number of treatments as the seven preferred combinations for Example D.

[0140] For Example B presented previously, in step 414, an 89-year-old patient with a white blood cell count of 12*10^9 L and Killip level 3 had a MACE risk score of 0.249. Further in Example B, a medical record data structure containing entries representing the following eight treatments had relative risk reduction values ​​as shown in Table 4, provided below. These relative risk reduction values ​​were derived from information from medical literature that was entered into the medical record data structure in other steps of process 400, such as process step 402.

[0141] [Table 4]

[0142] Steps 416-424 of process 400 performed in Example B resulted in generating treatment options for the 89-year-old patient as Treatments 1, 5, and 6. Step 426 determined that Treatments (1,5) and (1,6) were also preferred for the 89-year-old patient. Using these five treatment options (three individual treatments and two combinations) and calling for a risk score of 0.249, step 428 in Example B determined the following reduced risk scores for the treatments and preferred combinations of treatments shown in Table 5, presented below:

[0143] [Table 5]

[0144] These calculations show that the data indicate that using a combination of primary PCI and ticagrelor as treatments together in the 89-year-old patient in Example B achieved a significant reduction in risk score and the greatest therapeutic effect, with the reduced risk score of 0.149 being smaller than each of the four calculated reduced risk scores in Example B.

[0145] Example C, presented below, further illustrates step 428 of determining risk scores for treatment options. In Example C, four treatment options I1, I2, I5, and I6 were generated in step 415 of process 400. The medical record data structure for this Example C includes the following RRR information obtained from multiple medical documents L1, L2, L3, and L4, respectively. This RRR information is presented for each of the four individual treatment approaches or options in Table 6 below.

[0146] [Table 6]

[0147] Step 426 in Example C indicated that treatment options I5 and I6 are not suitable for combination with each other, but all other combinations of the four treatment options are preferred. For Example C, the risk score in step 414 was obtained as 0.5 for the patient's disease outcome H. Using the treatment options and starting with a risk score of 0.5, step 428 in Example C determined the following individual treatment options and preferred combinations of treatments with reduced risk scores, as shown in Table 7:

[0148] [Table 7]

[0149] These calculations show that the data show that the combination of using treatment options I1, I2, and I6 together as treatment for the patient in Example C achieves the greatest reduction in risk score and the greatest treatment effect, with a reduced risk score of 0.25 being less than each of the other calculated reduced risk scores of 10 for Example C.

[0150] In some embodiments of the present disclosure, the medical record data structure can have entries from one or more literature or studies providing information or data regarding the effectiveness of a particular treatment option, e.g., one or more studies can provide a specific RRR for a treatment option. According to this embodiment, medical knowledge can be derived from multiple collections of literature or from multiple studies. Each of the multiple collections of literature or studies can be assigned a respective weight or deviation value when calculating the reduction risk score. A greater weight is assigned to literature that indicates a treatment option that achieves a more accurate effect.

[0151] According to some embodiments of the present disclosure, the weight of each document or study can be preset by considering its accuracy, document importance factor, peer review, or number of citations or the number of times it has been cited by other documents / studies. According to other embodiments of the present disclosure, the weight of each document or study can be determined using the DerSimonian-Laird method (DL method), which considers the inter-study variance of observed effects. In further embodiments, methods known to those skilled in the art other than the DL method can also be used to determine the weight of a document or study.

[0152] Thus, in these embodiments, step 428 can also assign a weight or deviation value to each of multiple references or studies when calculating a reduction risk score or determining treatment effectiveness. For example, for a treatment to stop smoking, three different medical references, L1, L2, and L3, can provide unique RRR values ​​for reducing the risk of outcome "O" that a patient or patient group will experience. Table 8, presented below, illustrates the weights and unique RRR values ​​for L1, L2, and L3.

[0153] [Table 8]

[0154] For those embodiments involving different document weightings, RRR(t) in equation (4) can be expressed as equation (5) below:

[0155]

number

[0156] In the above formula, m is the number of documents or studies available for one treatment, and w is the importance weight of the corresponding document or study.

[0157] In Example E, then, according to equation (5), using the information from Table 8 above, the combined effect RRR = {(0.8 * 0.35) + (0.5 * 0.42) + (0.6 * 0.40)} / (0.8 + 0.5 + 0.6) ≒ 0.38. According to the three references L1 to L3, the corresponding value "0.38" is recorded as the final RRR for the therapeutic measure "quit smoking." The weights in Table 8 presented above can be obtained using the DL method.

[0158] For example, an example of calculating weights using the DL method is described herein as Example F. In this example, both Study 1 and Study 2 in a medical record data structure provide relative risk reductions for using high doses of statins to reduce the risk of MACE. Although both studies are given the same weight, the studies assign different deviation values ​​to the magnitude of the observed effect from its true effect. Study 1 has rrr = 0.42, but a deviation value v1 = 0.39. Study 2 has rrr = 0.35, but a deviation value v1 = 0.1. Because the relative risk reduction values ​​between the two studies are combined, the relative risk reduction value of one study is referred to as "rrr" and the combined relative risk reduction value is referred to as "RRR."

[0159] For calculation purposes, let RRR(t) be the combined relative risk reduction with high statin use determined for both studies, and "k" is the number of studies in the analysis. i is the weight assigned to each study. Y i is the observed effect in study i. V i Y regarding its true effect i The standard deviation is T 2 is the between-study deviation.

[0160] [Table 9]

[0161] This calculation therefore shows that in Example F, in Studies 1 and 2, the relative risk reduction preserved for high statin doses is preserved as 0.364.

[0162] At 430 of process 400 shown in FIG. 4, the reduced risk scores determined in step 428 are compared to each other. The same or similar software used to perform the matching and mapping described above can also be used to perform the comparison of step 430. The comparison will reveal which treatment or combination of treatments had the greatest therapeutic effect and achieved the smallest reduced risk score. The comparison can include ranking the treatments and combinations of treatments in ascending or descending order of reduced risk score.

[0163] Step 432 of process 400 shown in FIG. 4 provides a recommendation of one or more of the identified treatment options or combinations of treatment options. This provision is performed via a computer program that displays a message on a display screen, such as on display 24, or that communicates an audio message with the recommendation via a speaker connected to the computer. In some embodiments, the computer program recommends the treatment or combination of treatments that has the greatest therapeutic effect and achieves the smallest reduced risk score. The provision of the recommendation can constitute a treatment decision to be made.

[0164] This recommendation in step 432 can be implemented via a computer program that lists, displays, or announces the treatments or combinations in ascending or descending order according to the reduction risk score, and highlights the lowest- or highest-ranked entry. The highlighted entry constitutes the recommended treatment. In some embodiments, if there are multiple treatment options with similar therapeutic effects, e.g., producing similar reduction risk scores, then the computer program can recommend multiple treatment options while providing information about their different effects. For example, multiple entries that are similarly superior to other treatments in terms of their therapeutic effects or reduction risk scores can be highlighted or announced, and each of the multiple entries can be highlighted on the display screen in a different color or with a different background sound or music played through a speaker. As part of step 430, the treatment or combination with the smallest q required by equation (3) can be recommended.

[0165] In example A, as part of step 432, the computer program may recommend that the patient accept a combination of thrombolysis (“708a”) and primary CABG (“708f”) because this combination has the greatest therapeutic effect and the smallest reduction risk score of 0.181. In example B, as part of step 432, the computer program may recommend that the patient accept a combination of primary PCI and ticagrelor because this combination has the greatest therapeutic effect and the smallest reduction risk score of 0.149. In example C, as part of step 432, the computer program may provide a recommendation that the patient accept a combination of treatment options I1, I2, and I6 because this combination has the greatest therapeutic effect and the smallest reduction risk score of 0.25.

[0166] In step 434 of process 400 shown in Figure 4, the computer program checks whether new medical records, studies, or literature have become available or published that provide new quantitative disease risk information or that provide quantitative treatment effect information. This check can be performed in the same manner as step 402, using NLP techniques to identify medical literature with quantitative information, either by a practitioner manually checking newly published medical literature or scanning the Internet, or by a program scanning uploaded medical studies or medical literature, or both.

[0167] 4, in step 436 of process 400, if the check in step 434 indicates that new medical studies or literature containing one or more quantitative pieces of information is available, the computer program adds the information from the new medical studies or literature to the medical record data structure, the patient data node graph 500, the disease-outcome relationship graph 600, and the treatment tree 700, or any combination thereof. This addition can be performed either by a practitioner manually typing or entering the information from the newly published and identified medical studies or literature, or by a computer program that collects information from multiple medical publications or studies and generates new entries in the medical record data structure, the patient data node graph 500, the disease-outcome relationship graph 600, and the treatment tree 700, or any combination thereof.

[0168] An example of step 436 for Example A is described below using Figures 8 and 9B. For example, suppose in step 434, a new publication, Hjalmarson 1981, is discovered that shows that metoprolol, when used as a treatment, reduces the risk of mortality to 0.36. Figure 9B shows that a new record entry row 908 is added to medical record table 902 to produce an updated medical record table 906 with the new record entry row 908 containing information from the Hjalmarson 1981 publication and with the entry "712" in the "0" traveled result column.

[0169] 8 shows an updated therapy tree 800 created by modifying therapy tree 700 by adding a new therapy node 712 connected to the third therapy node 708c and the second exclusive node 704b. The Hjalmarson 1981 paper includes data showing that metoprolol therapy can be used in patients who experience an AMI (corresponding to the first patient data node 502a) and reduces the risk of mortality (corresponding to the third disease outcome node 602c) by 0.36. Thus, in the updated medical record table 906, "entry 602" is entered in the result column "O" of the newly recorded entry row 908, and entry "502a" is entered in the patient data column "P." Hjalmarsson's paper indicates that metoprolol is a beta blocker (corresponding to the third therapy node 702c) and cannot be used in therapy in combination with other beta blockers. Figure 8 therefore shows that the new therapy node 712 is connected to the third therapy node 702c via the second exclusive node 704b.

[0170] In step 438 of process 400 shown in FIG. 4, the computer program can check whether a disease risk reduction evaluation should be performed on another patient. If step 438 is positive, then the process returns to step 410 and repeats step 410 for the new patient. Steps 402-408 do not need to be repeated because the medical record data structure generated in step 402, the patient data node graph 500 generated in step 404, the disease-finding relationship graph 600 generated in step 406, and the therapy tree 700 generated in step 408 (or the updated therapy tree 800 generated in step 436) can be used to evaluate disease risk reduction for the new patient. With the check for a new patient in step 438, process 400 can postpone until a new patient is brought forward requesting an evaluation, or until the same patient is brought forward requesting another evaluation. Process 400 then begins at step 410, as the medical record data structure, patient data node graph 500, disease-outcome relationship graph 600, and treatment tree 700 or updated treatment tree 800 can be used to assess disease risk reduction for the new patient.

[0171] The methods, computer systems, computer-readable recording media, and computer programs disclosed herein improve the selection of medical treatments, improve the automation of the evaluation of medical treatments, and assist researchers and healthcare professionals in utilizing the value of the determinations in medical research by eliminating the need for redundant performance of medically controlled experiments.

[0172] The present invention may be embodied in any possible level of technical detail integration as a system, a method, a computer-readable recording medium, a computer program, or a combination thereof, wherein the computer-readable recording medium and the computer program have computer-readable program instructions for causing a processor to perform the features of the present invention.

[0173] A computer-readable storage medium may be any tangible device capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media may be, for example, but not limited to, electrical, magnetic, optical, electro-magnetic, or semiconductor storage devices, or any suitable combination thereof. More specific examples of computer-readable storage media include the following: portable computer disks, hard disks, random access memories (RAMs), read-only memories (ROMs), erasable programmable read-only memories (EPROMs or flash memories), static random access memories (SRAMs), portable compact disk read-only memories (CD-ROMs), digital versatile disks (DVDs), memory sticks, floppy disks, punch cards, or mechanically encoded devices having protruding structures within grooves that record instructions, and any suitable combination thereof. As used herein, a computer-readable recording medium is not to be construed as a transitory signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave such as a wave guide or other communication medium (e.g., light pulses passing through a fiber optic cable), or an electrical signal communicated through a wire.

[0174] The computer programs described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or can be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network can include copper cables, fiber optics, wireless routers, firewalls, switches, gateway computers, and edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium within the computing / processing device for storage.

[0175] Computer-readable program instructions for carrying out the operations of the present invention can be either source code or object code written in any combination of programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine language instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or one or more procedural programming languages, such as object-oriented programming languages ​​like Smalltalk®, C++, the "C" programming language, or similar programming languages. The computer-readable program instructions can execute entirely on the user computer, partially on the user computer as a stand-alone software package, partially on the user computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user computer through any type of network, including a local area network (LAN), a wide area network (WAN), or the connection can be to an external computer (e.g., through an Internet service provider). In some embodiments, computer-readable program instructions can be executed by electrical circuitry, including, for example, programmable logic circuitry, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), using state information from the computer-readable program instructions to personalize the electrical circuitry to perform features of the present invention.

[0176] Aspects of the invention described herein have been described with reference to flowchart instructions and / or block diagrams of methods, apparatus (systems), and computer-readable storage media and computer program products according to embodiments of the invention. It will be understood that any combination of flowchart illustrations and / or block diagrams and / or blocks in flowchart illustrations and / or block diagrams can be implemented by computer-readable program instructions.

[0177] The computer-readable program instructions can be provided to a computer processor or other programmable data processing device to create a machine, and execution by the computer processor or other programmable data processing device generates means for implementing the functions / operations specified in the block or blocks of the flowcharts and block diagrams, or a combination thereof. These computer-readable program instructions that direct a computer, programmable data processing device, or other device, or a combination thereof, to function in a particular manner can also be stored on a computer-readable recording medium, and the computer-readable recording medium having the instructions stored thereon constitutes an article of manufacture containing instructions that implement the functional / operational features specified in the block or blocks of the flowcharts and block diagrams, or a combination thereof.

[0178] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device and cause a computer-implemented process to perform a series of operational steps on the computer, other programmable apparatus, or other device to implement the functions / acts identified in a block or blocks of the flowcharts and block diagrams, or a combination thereof, on the computer, other programmable apparatus, or other device.

[0179] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and possible implementations of systems, methods, and computer programs according to various embodiments of the present invention. In this regard, the flowcharts or block diagrams may represent modules, segments, or portions of instructions, which contain one or more executable instructions for implementing a specific logical function(s). In some alternative implementations, the functions described in the blocks may be performed other than as illustrated. For example, two blocks shown in succession may actually be performed as a single step, or may be performed simultaneously, substantially simultaneously, or partially or completely overlapping in time, depending on the functionality involved, or the blocks may sometimes be performed in reverse order. It should also be noted that block diagrams and / or flowchart illustrations, and / or combinations thereof, may be implemented by special-purpose hardware-based systems that perform specific functions or operations or execute specific-purpose hardware and computer instructions.

[0180] The description of various embodiments of the present invention is presented for illustrative purposes and is not intended to be exclusive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used in this specification have been selected to best explain the principles, practical applications, or technical improvements beyond those found in the marketplace of the present embodiments, or to enable those skilled in the art to understand the embodiments disclosed herein. [Explanation of symbols]

[0181] 10 cloud computing nodes 12...Computer Systems / Servers 14...External Device 16...Processing unit 18...Bus 20...Network adapter 22...Input / Output (I / O) Interface 28…System memory

Claims

1. 1. A computer-implemented method executed by a computer, the method comprising: generating, by one or more processors, a medical record data structure, the medical record data structure including a plurality of record groups, each record group including a set of linked medical record data including medical patient data and at least one treatment option; receiving, by the one or more processors, patient data for a patient; receiving by the one or more processors a selection of a disease outcome; determining, by the one or more processors, a risk score that the patient will experience the selected disease outcome using the patient data; accessing, by the one or more processors, the generated medical record data structure to generate treatment options based on the patient data; matching the patient data and the selected disease outcomes with the plurality of record groups in the medical record data structure; identifying at least one additional treatment option of the treatment options using at least one medical record data graph including interconnected medical record data nodes based on a result of the matching; generating said treatment options, including: determining, by the one or more processors, an effect of the treatment for each of the treatment options, including the at least one additional treatment option, where the effect of the treatment changes the risk score; comparing, by the one or more processors, the effectiveness of the treatments; providing, by the one or more processors, a recommendation of at least one of the treatment options based on the comparison of the effectiveness of the treatments; Execute Computer-implemented methods.

2. the efficacy of said treatments is determined by determining a relative risk reduction for a corresponding one of said treatment options based on medical knowledge related to said corresponding treatment option; The computer-implemented method of claim 1 .

3. said medical knowledge is derived from multiple sources or multiple studies; a weight or deviation value is assigned to each of the plurality of documents or each of the studies when determining the effectiveness of the treatment; 3. The computer-implemented method of claim 1 or 2.

4. A computer-implemented method as described in any one of claims 1 to 3, wherein the multiple record groups in the medical record data structure include linked entries that record specific distribution information associated with at least one element selected from the group consisting of patient data, a given disease outcome, a treatment option, and a corresponding relative risk reduction.

5. Identifying the additional treatment options based on the results of the matching comprises: matching the matched record groups with respective nodes of the at least one medical record data graph; identifying at least one ancestor node of the matched node in a match with said node; identifying at least one additional treatment option of the treatment option using the identified at least one ancestor node; and The computer-implemented method of any one of claims 1 to 4, comprising:

6. A computer-implemented method described in any one of claims 1 to 5, wherein the at least one medical record data graph represents relationships between medical record data and is selected from the group consisting of a patient data node graph and a disease-outcome relationship graph.

7. 1. A system for assessing disease risk reduction, the system comprising: one or more processors; a memory coupled to at least one of the one or more processors; a set of computer program instructions, executed by at least one of the one or more processors and stored in the memory; The set of computer program instructions causes the processor to: generating a medical record data structure, the medical record data structure including a plurality of record groups, each record group including a set of linked medical record data including medical patient data and at least one treatment option; receiving the patient's patient data; receiving a selection of disease outcomes; determining a risk score for the patient that the patient will experience the selected disease outcome using the patient data; accessing the generated medical record data structure to generate treatment options based on the patient data; matching the patient data and the selected disease outcomes with the plurality of record groups in the medical record data structure; identifying at least one additional treatment option of the treatment options using at least one medical record data graph including interconnected medical record data nodes based on a result of the matching; generating, including; determining the effect of the treatment for each of the treatment options, including the at least one additional treatment option, where the effect of the treatment changes the risk score; comparing the effectiveness of said treatments; providing a recommendation for at least one of said treatment options based on the comparison of effectiveness of said treatments; and To run the system.

8. the efficacy of said treatments is determined by determining a relative risk reduction for a corresponding one of said treatment options based on medical knowledge related to said corresponding treatment option; The system of claim 7.

9. said medical knowledge is derived from multiple sources or multiple studies; a weight or deviation value is assigned to each of the plurality of documents or each of the studies when determining the effectiveness of the treatment; 9. A system according to claim 7 or 8.

10. Identifying the additional treatment options based on the results of the matching comprises: matching the matched record groups with respective nodes of the at least one medical record data graph; identifying at least one ancestor node of the matched node in a match with said node; identifying at least one additional treatment option of the treatment option using the identified at least one ancestor node; and The system according to any one of claims 7 to 9, comprising:

11. 1. A computer-readable medium containing program instructions for assessing disease risk reduction, the program instructions directing a processor to: generating, by one or more processors, a medical record data structure, the medical record data structure including a plurality of record groups, each record group including a set of linked medical record data including medical patient data and at least one treatment option; receiving, by the one or more processors, patient data for a patient; receiving by the one or more processors a selection of a disease outcome; determining, by the one or more processors, a risk score that the patient will experience the selected disease outcome using the patient data; accessing, by the one or more processors, the generated medical record data structure to generate treatment options based on the patient data; matching the patient data and the selected disease outcomes with the plurality of record groups in the medical record data structure; identifying at least one additional treatment option of the treatment options using at least one medical record data graph including interconnected medical record data nodes based on a result of the matching; generating said treatment options, including: determining, by the one or more processors, an effect of the treatment for each of the treatment options, including the at least one additional treatment option, where the effect of the treatment changes the risk score; comparing, by the one or more processors, the effectiveness of the treatments; providing, by the one or more processors, a recommendation of at least one of the treatment options based on the comparison of effectiveness of the treatments; A computer-readable recording medium that causes the computer to execute the above.

12. the efficacy of said treatments is determined by determining a relative risk reduction for a corresponding one of said treatment options based on medical knowledge related to said corresponding treatment option; The computer-readable storage medium of claim 11.

13. said medical knowledge is derived from multiple sources or multiple studies; a weight or deviation value is assigned to each of the plurality of documents or each of the studies when determining the effectiveness of the treatment; 13. The computer-readable recording medium according to claim 11 or 12.

14. A computer-readable recording medium as described in any one of claims 11 to 13, wherein the multiple record groups in the medical record data structure include linked entries that record specific distribution information related to at least one element selected from the group consisting of patient data, a given disease outcome, a treatment option, and a corresponding relative risk reduction.

15. Identifying the additional treatment options based on the results of the matching comprises: matching the matched record groups with respective nodes of the at least one medical record data graph; identifying at least one ancestor node of the matched node in a match with said node; identifying at least one additional treatment option of the treatment option using the identified at least one ancestor node; and The computer-readable recording medium according to any one of claims 11 to 14, comprising:

16. 1. A computer-implemented method executed by a computer, the method comprising: generating, by one or more processors, a medical record data structure, the medical record data structure including a plurality of record groups, each record group including a set of linked medical record data including medical patient data and at least one treatment option; receiving, by the one or more processors, patient data for a patient; receiving by the one or more processors a selection of a disease outcome; determining, by the one or more processors, a risk score that the patient will experience the selected disease outcome using the patient data; accessing, by the one or more processors, the generated medical record data structure to generate, based on the patient data, treatment options including individualized treatment options and at least one combination of treatment options; matching the patient data and the selected disease outcomes with the plurality of record groups in the medical record data structure; identifying at least one additional treatment option of the treatment options using at least one medical record data graph including interconnected medical record data nodes based on a result of the matching; generating said treatment options, including: determining, by the one or more processors, a reduction risk score achieved by each of the treatment options for the selected disease outcome; comparing, by the one or more processors, the reduced risk scores; providing, by the one or more processors, a recommendation of at least one of the treatment options based on the comparison of the reduced risk scores; A computer-implemented method for causing

17. Obtaining literature or research containing quantitative information on medical knowledge; updating the medical record data structure by adding entries corresponding to the obtained literature or studies; 17. The computer-implemented method of claim 16, comprising:

18. the patient data includes at least one element selected from the group consisting of demographic data, vital signs, laboratory test results, and disease outcomes; 18. A computer-implemented method according to claim 16 or 17.

19. Identifying the additional treatment options based on the results of the matching comprises: matching the matched record groups with respective nodes of the at least one medical record data graph; identifying at least one ancestor node of the matched node in a match with said node; identifying at least one additional treatment option of the treatment option using the identified at least one ancestor node; checking a treatment tree to determine a combination of the at least one treatment option, the treatment tree including treatment option nodes defining relationships between a plurality of treatment options, and determining the combination of the at least one treatment option includes identifying at least one ancestor node of a node representing a determined individual treatment option; The computer-implemented method of any one of claims 16 to 18, comprising:

20. A computer-implemented method described in any one of claims 16 to 19, wherein the at least one medical record data graph represents relationships between medical record data and is selected from the group consisting of a patient data node graph and a disease-outcome relationship graph.

21. 1. A system for assessing disease risk, the system comprising: one or more processors; a memory coupled to at least one of the one or more processors; a set of computer program instructions executed by at least one of the one or more processors and stored in the memory; The set of computer program instructions causes the processor to: generating a medical record data structure, the medical record data structure including a plurality of record groups, each record group including a set of linked medical record data including medical patient data and at least one treatment option; receiving, by the one or more processors, patient data for a patient; receiving by the one or more processors a selection of a disease outcome; determining, by the one or more processors, a risk score that the patient will experience the selected disease outcome using the patient data; accessing, by the one or more processors, the generated medical record data structure to generate, based on the patient data, treatment options including individualized treatment options and at least one combination of treatment options; matching the patient data and the selected disease outcomes with the plurality of record groups in the medical record data structure; identifying at least one additional treatment option of the treatment options using at least one medical record data graph including interconnected medical record data nodes based on a result of the matching; generating said treatment options, including: determining, by the one or more processors, a reduction risk score achieved by each of the treatment options for the selected disease outcome; comparing, by the one or more processors, the reduced risk scores; providing, by the one or more processors, a recommendation of at least one of the treatment options based on the comparison of the reduced risk scores; To run the system.

22. Obtaining literature or research containing quantitative information on medical knowledge; updating the medical record data structure by adding entries corresponding to the obtained literature or studies; 22. The system of claim 21, comprising:

23. the patient data includes at least one element selected from the group consisting of demographic data, vital signs, laboratory test results, and disease outcomes; 23. A system according to claim 21 or 22.

24. Identifying the additional treatment options based on the results of the matching comprises: matching the matched record groups with respective nodes of the at least one medical record data graph; identifying at least one ancestor node of the matched node in a match with said node; identifying at least one additional treatment option of the treatment option using the identified at least one ancestor node; checking a treatment tree to determine a combination of the at least one treatment option, the treatment tree including treatment option nodes defining relationships between a plurality of treatment options, and determining the combination of the at least one treatment option includes identifying at least one ancestor node of a node representing a determined individual treatment option; The system according to any one of claims 21 to 23, comprising:

25. A system described in any one of claims 21 to 24, wherein the at least one medical record data graph represents relationships between medical record data and is selected from the group consisting of a patient data node graph and a disease-outcome relationship graph.

26. A computer-executable program for causing a computer to execute the computer-implemented method according to any one of claims 1 to 6 and 16 to 20.

Images