Graph database for outbreak tracking and management

Abstract

To provide a favorable graph database for outbreak tracking and management.SOLUTION: A graph database for outbreak tracking and management is disclosed. In an example embodiment, an outbreak management system includes a memory device storing instructions that define a graph database for disease outbreak tracking. The instructions specify, for a given host, that a host node is created and an episode node is connected to the host node via a 'case' link. The episode node is associated with episode parameters that are related to a disease classification of the host. In addition, the instructions specify that an outbreak node is connected to the episode node via a 'part of' link to specify that the host is becoming a part of an outbreak of the disease. The outbreak node is connected to a definition node via a 'defined as' link. The definition node specifies disease parameters of the disease that is related to the outbreak node.SELECTED DRAWING: Figure 1

Description

[Background technology]

[0001] As of spring 2018, the world's population was approximately 7.6 billion. The United Nations estimates that the population will reach 8 billion by 2024 and 9 billion by 2042. As the world's population grows, people are moving into higher-density suburban and urban areas in addition to encroaching into undeveloped areas such as forests and grasslands. For example, the city of Manila in the Philippines has a density of 107,000 people per square mile, while more populous Indian cities such as Mumbai have nearly 12 million people at an average density of 73,000 people per square mile.

[0002] In addition to population growth and further densification, travel, such as air travel, has become more communalized, allowing more people to travel greater distances. Rising wages among the global middle class allow more of the world's population to travel regionally, nationally, or internationally. The globalization of business and trade further increases the number of external contacts per day. Overall, an increasing number of people living within densely populated areas, combined with an increasing mobile population, creates optimal conditions for the rapid spread of infectious diseases and other outbreaks. In fact, the world has suffered several threats in the past few years, including severe acute respiratory syndrome ("SARS"), swine flu, and Ebola hemorrhagic fever, in addition to human immunodeficiency virus ("HIV"). The U.S. Centers for Disease Control and Prevention ("CDC") also maintains a website of currently recognized outbreaks in the United States and around the world.

[0003] While the world is progressing, outbreak tracking and management is lagging. It often takes disease researchers months to identify an outbreak and even longer to determine its distribution, spread, and origin. Infection tracking is generally a manual process that involves reviewing medical records, government records, and field notes. Some government organizations and large medical centers build and analyze relational databases of outbreak information to determine distribution, spread, and origin. However, extensive effort is required to input the correct data. In addition, significant computing power is required to analyze the collected data. As a result of the effort and capacity required, only relatively severe or malignant outbreaks are tracked, leaving many outbreaks untracked.

[0004] In addition to the above, medical data related to an outbreak is entered only after the outbreak is identified. The delay between outbreak occurrence, identification, data collection, and analysis can result in an outbreak spreading rapidly before much is known. Many medical professionals believe that the next pandemic (or pandemic wave) will begin small in isolated areas, such as urban centers or the outskirts of developed areas, and progress below health radar until a significant portion of the world's population is affected. Summary of the Invention [Means for solving the problem]

[0005] The present disclosure describes a graph database for outbreak tracking and management. In particular, the present disclosure describes methods, systems, and devices for creating and updating a graph database for tracking one or more outbreaks. The methods, systems, and devices disclosed herein can also be configured to analyze the graph database and provide outbreak management and outbreak forecasting. The graph database incorporates medical, location, temporal, and / or demographic relationships between nodes according to a predetermined structure. The definitions and relationships provided between different types of nodes allow information to be automatically incorporated into the graph database. Furthermore, the definitions and relationships allow the origin of an outbreak to be located to identify causes and potential solutions for the outbreak.

[0006] Aspects of the subject matter described herein may be useful alone or in combination with one or more other aspects described herein. Without limiting the foregoing, in a first aspect of the present disclosure, an outbreak management server device includes an interface for receiving patient data related to a patient, and a node processor communicatively coupled to the interface and configured to create an outbreak tracking graph database. The node processor creates the outbreak tracking graph database by comparing the patient data with disease parameters of different diseases, the disease parameters defining conditions for a "probable" classification for each disease, a "probable" classification for each disease, and a "confirmed" classification for each disease. For each patient for which at least one of a "probable," "probable," and "confirmed" classification is determined for one of the diseases, the node processor creates a host node for the patient and connects it to the host node via a "case" link; an episode node associated with episode parameters related to the host's disease classification; an occurrence node connected to the episode node via a "part of" link indicating the host is becoming part of an outbreak for the determined disease; and an occurrence node connected to the definition node via a "defined as" link, the definition node defining disease parameters for the disease associated with the occurrence node. The outbreak management server device also includes a database analyzer configured to analyze and display the graph database associated with the determined disease outbreak for identification of at least one of an index patient or a relationship between patients.

[0007] According to a second aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the node processor is configured to use at least a portion of the patient data to create epidemiological links between at least some of the host nodes that are linked to the same origin node.

[0008] According to a third aspect of the present disclosure, which may be used in combination with any other aspects recited herein unless otherwise stated, a database analyzer is configured to receive from a user device a request to view relationships of a designated host associated with a particular disease defined by an associated outbreak node, determine epidemiological links between the designated host and at least one of (i) other hosts connected to the same associated outbreak node, or (ii) humans co-located with the host at the same time, and cause a user interface to be displayed on the user device graphically showing the designated host connected to other hosts and indicating potential contacts at risk of contacting the particular disease associated with the host.

[0009] According to a fourth aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the node processor is configured to determine a “probable,” “likely,” or “confirmed” classification for at least some of the other hosts, and the database analyzer is configured to provide a graphical indication of the “probable,” “likely,” or “confirmed” classification for at least some of the other hosts within a user interface.

[0010] According to a fifth aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the epidemiological link includes at least one of an "airborne transmission" link, an "animal reservoir host" link, an "environmental reservoir host" link, a "food and drinking water" link, an "insect bite" link, an "animal / human contact" link, a "contaminated object" link, a "droplet spread" link, or a "human / human contact" link, and each of the other hosts is at least one of a patient, a clinician, a human, an animal, a fomite, or an object.

[0011] According to a sixth aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the node processor is configured to: for each host node for which sample data is available within the patient data for an individual patient, create a sample node linked to the individual host node via a sample link, the sample node associated with a sample parameter indicating a time or status of the sample obtained from the patient; create an isolate node linked to the sample node via an isolate link, the isolate node associated with an isolate parameter defining the isolate within the sample result associated with the obtained sample; and create a microorganism node linked to the isolate node via a microorganism link, the microorganism node associated with a microorganism parameter defining at least one microorganism found within the isolation routine.

[0012] According to a seventh aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the node processor is configured to determine hosts having the same microorganisms defined within the individual microorganism parameters of the microorganism node as a first set of hosts, determine hosts linked to the same occurrence node from the first set of hosts as a second set of hosts, display a graphical representation showing connections between the microorganism nodes and the occurrence nodes for the second set of hosts, and show biological materials involved in the spread of disease and the occurrence of disease.

[0013] According to an eighth aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the node processor is configured to: for each host node for which location data is available in the patient data for an individual patient, create a stay node linked to the individual host node via a stay link, the stay node being associated with a stay parameter specifying a date / time the host node was at the particular location; and create a location node linked to the stay node via a “stay at” link, the location node being associated with a location parameter specifying the particular location.

[0014] According to a ninth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the specific location includes at least one of a hospital bed identifier or node, a hospital room identifier or node, a corridor identifier or node, a ward identifier or node, a floor identifier or node, a building identifier or node, a hospital identifier or node, a structure identifier or node, a building identifier or node, a street identifier or node, a site identifier or node, an area identifier or node, a state identifier or node, a country identifier or node, or a GPS coordinate.

[0015] According to a tenth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the interface is configured to receive patient data from at least one of an electronic medical record (“EMR”) server or a third-party server, the patient data including at least one of patient medical data, social media data, location data, or demographic data.

[0016] According to an eleventh aspect of the present disclosure, which may be used in combination with any other aspects recited herein unless otherwise stated, an outbreak management system includes a memory device having instructions stored therein defining a graph database for disease outbreak tracking. The instructions specify that, for a given host, a host node associated with host parameters is created; an episode node associated with episode parameters related to the host's disease classification is connected to the host node via a "case" link; an outbreak node connected to a definition node via a "defined by" link, the definition node defining disease parameters for a disease associated with the outbreak node; and the outbreak node connected to the episode node via an "contained by" link, indicating that the host is becoming part of an outbreak of the disease. The system also includes an outbreak management server configured to receive patient data related to the host and to store at least some of the received patient data in the graph database in one or more parameters of at least one of the host node, the episode node, or the outbreak node based on content of at least some of the received patient data matching parameter definitions of the individual nodes.

[0017] According to a twelfth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the server is configured to connect the host node to the occurrence node via the episode node after determining that at least some of the patient data matches at least some of the disease parameters of the definition node.

[0018] According to a thirteenth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the host parameters include at least one of a host name, a patient classification flag, a clinician classification flag, a human classification flag, an animal classification flag, a vector classification flag, an object classification flag, patient demographic data, or patient medical data.

[0019] According to a fourteenth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the episode parameters include at least one of a case number for the host, a "probable" classification for the disease for the host, a "likely" classification for the disease for the host, a "confirmed" classification for the disease for the host, an immunization status for the host, an immunization type for the host, a flag indicating that the host contracted the disease in a medical facility, or mortality information related to the host.

[0020] According to a fifteenth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the disease parameters include at least one of the name of the disease, the background of the disease, the time / geographic location associated with the disease, the clinical criteria for the disease, the laboratory criteria for the disease, the mode of transmission for the disease, the criteria for determining a "suspected" classification, the criteria for determining a "probable" classification, and the criteria for determining a "confirmed" classification.

[0021] According to a sixteenth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the server is configured to determine a case classification for an episode node related to the host node by comparing at least some of the patient parameters with criteria for determining “suspected,” “probable,” and “confirmed” classifications for disease parameters, and store at least one of “suspected,” “probable,” or “confirmed” classifications for the disease in individual episode parameters of the episode node based on the comparison.

[0022] According to a seventeenth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the server is configured to generate a case number for individual episode parameters of the episode node after determining a "confirmed" or "probable" classification for the host.

[0023] According to an eighteenth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the instructions specify that, for a given host, a role node is connected to an episode node via a role link, and the role node is associated with a role parameter that specifies whether the host is a patient, a clinician, a family member, or an individual.

[0024] According to a nineteenth aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the instructions specify that, for a given host, a symptom node is connected to a host node via a “symptomatic” link, and the symptom node is associated with one or more symptom parameters specifying at least one of a symptom start date, a symptom end date, and a symptom identifier corresponding to a symptom suffered by the host.

[0025] According to a twentieth aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the instructions specify that, for a given host, the host node is connected to another host node via an epidemiological link, the epidemiological link including at least one of an "airborne" link, an "animal reservoir host" link, an "environmental reservoir host" link, a "food and drinking water" link, an "insect bite" link, an "animal / human contact" link, a "contaminated object" link, a "droplet spread" link, or a "human / human contact" link.

[0026] According to a twenty-first aspect of the present disclosure, any of the structures and functionality shown and described in connection with Figures 1-20 may be used in combination with any of the structures and functionality shown and described in connection with any of the other Figures 1-20 and any one or more of the aforementioned aspects.

[0027] Therefore, in light of the above aspects and disclosures herein, it is an advantage of the present disclosure to provide a graph database that provides for occurrence tracking and management.

[0028] It is another advantage of the present disclosure to provide a system that creates a graph database according to a predetermined data structure, allowing provenance to be determined.

[0029] It is another advantage of the present disclosure to provide a system that creates a graph database according to a predetermined data structure and identifies individuals who are potential or suspect for an outbreak.

[0030] The advantages discussed herein may be found in one or some, but perhaps not all, of the embodiments disclosed herein. Additional features and advantages will be described herein and will be apparent from the following detailed description and figures. (Item 1) An occurrence management server device, an interface for receiving patient data associated with the patient; a node processor communicatively coupled to the interface, the node processor comprising: comparing said patient data with disease parameters of different diseases, said disease parameters defining the conditions for a "probable" classification for said individual disease, a "probable" classification for said individual disease, and a "confirmed" classification for said individual disease; For each patient in whom at least one of the above "possible," "probable," and "confirmed" classifications is determined for one of the above diseases: creating a host node for the patient; creating an episode node connected to the host node via a "case" link, the episode node being associated with episode parameters related to a disease classification of the host; creating an occurrence node, said occurrence node being connected to said episode node via an "inherited by" link, indicating that said host is becoming part of said occurrence for a disease to be determined, said occurrence node being connected to a definition node via a "defined by" link, said definition node defining disease parameters for said disease associated with said occurrence node; adding said patient to a graph database associated with said determined occurrence of the disease by a node processor configured to create an occurrence tracking graph database by: a database analyzer configured to analyze and display the graph database associated with the determined disease occurrences for identification of at least one of an index patient or a relationship between the patients; and An occurrence management server device comprising: (Item 2) 2. The apparatus of claim 1, wherein the node processor is configured to use at least a portion of the patient data to create epidemiological links between at least some of the host nodes that are linked to the same origin node. (Item 3) The database analyzer receiving a request from a user device to view a relationship of a specified host associated with a particular disease defined by an associated developmental node; Determining an epidemiological link between the designated host and at least one of (i) other hosts connected to the same relevant outbreak node, or (ii) humans co-located with the host at the same time; displaying a user interface on the user device graphically illustrating the designated host connected to the other hosts and indicating potential contacts at risk of contracting the particular disease associated with the host; Item 3. The apparatus according to item 2, configured to perform the following: (Item 4) the node processor is configured to determine the "probable," "likely," or "confirmed" classification for at least some of the other hosts; the database analyzer is configured to provide within the user interface a graphical indication of the "probable," "likely," or "confirmed" classification for at least some of the other hosts; Item 3. The device according to item 3. (Item 5) the epidemiological links include at least one of an "airborne transmission" link, an "animal reservoir" link, an "environmental reservoir" link, a "food and drinking water" link, an "insect bite" link, an "animal-human contact" link, a "contaminated object" link, a "droplet spread" link, or a "human-human contact" link; Each of the other hosts is at least one of a patient, a clinician, a human, an animal, a fomite, or an object; Item 3. The device according to item 3. (Item 6) The node processor, for each host node for which sample data is available in the patient data for the individual patient, creating a sample node linked to a respective host node via a sample link, said sample node being associated with a sample parameter indicating a time or status of the sample obtained from said patient; creating an isolate node linked to the sample node via an isolate link, the isolate node associated with isolate parameters defining an isolate within a sample result associated with the obtained sample; creating a microorganism node linked to the isolate node via a microorganism link, the microorganism node being associated with a microorganism parameter defining at least one microorganism found in the isolation routine; 4. The apparatus according to item 1 or 3, configured to perform (Item 7) The node processor includes: determining hosts having the same microorganisms defined within the individual microorganism parameters of the microorganism node as a first set of hosts; determining hosts linked to the same developmental node as a second set of hosts from the first set of hosts; displaying a graphical representation showing connections between the microbial nodes and the outbreak nodes for the second set of hosts, showing the spread of the disease and biological material involved in the outbreak of the disease; 7. The apparatus according to item 6, configured to perform the following. (Item 8) The node processor, for each host node for which location data is available in the patient data for the individual patient, creating a visitor node linked to said individual host node via a visit link, said visitor node being associated with a visit parameter specifying the date / time said host node was at a particular location; creating a place node linked to said stay node via a "stay" link, said place node being associated with location parameters defining said particular location; 7. The apparatus of item 1, 3, or 6, configured to perform (Item 9) Item 9. The apparatus of item 8, wherein the specific location includes at least one of a hospital bed identifier or node, a hospital room identifier or node, a corridor identifier or node, a ward identifier or node, a floor identifier or node, a building identifier or node, a hospital identifier or node, a structure identifier or node, a building identifier or node, a street identifier or node, a site identifier or node, an area identifier or node, a state identifier or node, a country identifier or node, or a GPS coordinate. (Item 10) Item 10. The device of item 1, wherein the interface is configured to receive the patient data from at least one of an electronic medical record ("EMR") server or a third-party server, and the patient data includes at least one of patient medical data, social media data, location data, or demographic data. (Item 11) 1. An occurrence management system, comprising: a memory device having instructions stored therein, the instructions defining a graph database for disease outbreak tracking, the instructions for, with respect to a given host: A host node is created, said host node being associated with host parameters; An episode node is connected to the host node via a "case" link, and the episode node is associated with episode parameters related to the disease classification of the host; an occurrence node is connected to the episode node via an "inherited by" link to indicate that the host is becoming part of an occurrence of the disease, and the occurrence node is connected to a definition node via a "defined by" link, the definition node defining disease parameters for the disease associated with the occurrence node; a memory device defining an outbreak management server, receiving patient data associated with the host; storing at least some of the received patient data in the graph database in one or more parameters of at least one of the host node, the episode node, or the origin node based on content of at least some of the received patient data matching parameter definitions of the individual nodes; an outbreak management server configured to An occurrence management system comprising: (Item 12) Item 12. The system of item 11, wherein the server is configured to connect the host node to the occurrence node via the episode node after determining that at least some of the patient data matches at least some of the disease parameters of the definition node. (Item 13) 13. The system of claim 11 or 12, wherein the host parameters include at least one of the host's name, a patient classification flag, a clinician classification flag, a human classification flag, an animal classification flag, a vector classification flag, an object classification flag, patient demographic data, or patient medical data. (Item 14) 14. The system of claim 11 or 13, wherein the episode parameters include at least one of a case number for the host, a "probable" classification for the disease for the host, a "likely" classification for the disease for the host, a "confirmed" classification for the disease for the host, an immunization status for the host, an immunization type for the host, a flag indicating that the host contracted the disease in a medical facility, or mortality information associated with the host. (Item 15) Item 15. The system of item 14, wherein the disease parameters include at least one of a name of the disease, a background of the disease, a time / location associated with the disease, clinical criteria for the disease, laboratory criteria for the disease, a mode of transmission for the disease, criteria for determining a "suspected" classification, criteria for determining the "probable" classification, and criteria for determining the "confirmed" classification. (Item 16) The above server is determining a case classification for the episode node associated with the host node by comparing at least some of the patient parameters with the criteria for determining the "suspected," "probable," and "confirmed" classifications of the disease parameters; storing at least one of the "suspected," "probable," or "confirmed" classifications of the disease based on the comparison in the individual episode parameters of the episode node; Item 16. The system of item 15, configured to perform the following: (Item 17) Item 17. The system of item 16, wherein the server is configured to generate the case number for individual episode parameters of the episode node after determining the "confirmed" or "probable" classification for the host. (Item 18) 18. The system of claim 11, 12, or 17, wherein the instructions specify that, for the given host, a role node is connected to the episode node via a role link, and the role node is associated with a role parameter that specifies whether the host is a patient, a clinician, a family member, or an individual. (Item 19) 19. The system of claim 11 or 18, wherein the instructions specify that, for the given host, a symptom node is connected to the host node via a "symptomatic" link, and the symptom node is associated with one or more symptom parameters specifying at least one of a symptom start date, a symptom end date, and a symptom identifier corresponding to a symptom suffered by the host. (Item 20) the instructions specify, for the given host, that the host node is connected to another host node via an epidemiological link; the epidemiological links include at least one of an "airborne transmission" link, an "animal reservoir" link, an "environmental reservoir" link, a "food and drinking water" link, an "insect bite" link, an "animal-human contact" link, a "contaminated object" link, a "droplet spread" link, or a "human-human contact" link; 21. The system according to item 11 or 20. [Brief explanation of the drawings]

[0031] [Figure 1] 1-3 illustrate an exemplary embodiment of an exemplary occurrence tracking and management system, including an occurrence management server, according to an exemplary embodiment of the present disclosure. [Figure 2] 1-3 illustrate an exemplary embodiment of an exemplary occurrence tracking and management system, including an occurrence management server, according to an exemplary embodiment of the present disclosure. [Figure 3] 1-3 illustrate an exemplary embodiment of an exemplary occurrence tracking and management system, including an occurrence management server, according to an exemplary embodiment of the present disclosure.

[0032] [Figure 4] FIG. 4 illustrates a schematic diagram of the occurrence management server of FIGS. 1-3, according to an exemplary embodiment of the present disclosure.

[0033] [Figure 5] FIG. 5 shows a diagram of an exemplary patient electronic medical record, according to an exemplary embodiment of the present disclosure.

[0034] [Figure 6] 6 and 7 show diagrams of graphical representations of occurrence conditions according to exemplary embodiments of the present disclosure. [Figure 7] 6 and 7 show diagrams of graphical representations of occurrence conditions according to exemplary embodiments of the present disclosure.

[0035] [Figure 8] FIG. 8 shows a schematic diagram of an occurrence graph database structure according to an exemplary embodiment of the present disclosure.

[0036] [Figure 9] FIG. 9 shows a schematic diagram of an interface screen of a developmental graph database for a defined host node, according to an exemplary embodiment of the present disclosure.

[0037] [Figure 10A] FIG. 10A shows a schematic diagram of a hierarchical location map for use with a graph database, according to an exemplary embodiment of the present disclosure.

[0038] [Figure 10B] FIG. 10B shows a schematic diagram of a graph database including a sample node, an isolate node, and a microorganism node, according to an exemplary embodiment of the present disclosure.

[0039] [Figure 11] FIG. 11 illustrates a schematic diagram of an exemplary graph database for ward location nodes, according to an exemplary embodiment of the present disclosure.

[0040] [Figure 12] FIG. 12 illustrates a schematic diagram of an exemplary graph database for influenza outbreak nodes, according to an exemplary embodiment of the present disclosure.

[0041] [Figure 13] 13-18 show diagrams of exemplary interface screens of developmental analysis data determined from a developmental graph database, according to exemplary embodiments of the present disclosure. [Figure 14] 13-18 show diagrams of exemplary interface screens of developmental analysis data determined from a developmental graph database, according to exemplary embodiments of the present disclosure. [Figure 15] 13-18 show diagrams of exemplary interface screens of developmental analysis data determined from a developmental graph database, according to exemplary embodiments of the present disclosure. [Figure 16]13-18 show diagrams of exemplary interface screens of developmental analysis data determined from a developmental graph database, according to exemplary embodiments of the present disclosure. [Figure 17] 13-18 show diagrams of exemplary interface screens of developmental analysis data determined from a developmental graph database, according to exemplary embodiments of the present disclosure. [Figure 18] 13-18 show diagrams of exemplary interface screens of developmental analysis data determined from a developmental graph database, according to exemplary embodiments of the present disclosure.

[0042] [Figure 19] 19 and 20 illustrate flow diagrams showing example procedures for configuring and creating a graph database according to an example embodiment of the present disclosure. [Figure 20] 19 and 20 illustrate flow diagrams showing example procedures for configuring and creating a graph database according to an example embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0043] The present disclosure generally relates to methods, systems, and devices for creating and analyzing outbreak graph databases for outbreak management. The graph databases disclosed herein are specifically configured to provide medical, location, and / or temporal relationships between components of an outbreak. Unique definitions between components of the graph database allow links to be determined automatically between multiple individuals with minimal input from clinicians. Exemplary methods, systems, and devices disclosed herein are configured to perform defined analytics on the graph database to determine the distribution, spread, and origin of an outbreak in near real time, as soon as the first suspected, probable, or confirmed case is received.

[0044] Compared to graph databases, traditional relational databases contain tables of data. Unique keys are used to link data from different tables together. Relational databases are generally suited for flat data layouts where relationships between data are only one to three levels deep. As additional levels of data are added, or as data becomes increasingly interconnected, relational databases require significant computing power for analysis. Some computation can be avoided using indexes with relational databases. However, indexes can become stale as new data is added, which can require recompilation of the database and subsequent analysis.

[0045] As disclosed herein, the methods, devices, and systems are configured to operate with graph databases related to outbreak management. Graph databases include data structures that link nodes via data relationships (e.g., edges). The relationships between nodes can be semantic, allowing for semantic analysis and querying. Each node can have one or more parameters or attributes that define and store underlying data. The exemplary graph databases disclosed herein allow complex hierarchical structures to be computationally efficiently modeled and continually updated as new data is provided. In some cases, the disclosed graph databases can have between 7 and 20 distinct data levels. Graph databases are particularly well-suited for outbreak management because the hierarchical, multilevel nature of graph databases approximates the actual spread of conditions during an outbreak.

[0046] Graph databases disclosed herein include nodes and edges / relationships. Graph databases are configured to associate data items in a memory or store with a collection of nodes and edges. In some embodiments, nodes and edges may be stored in a table or list, with edges used to link nodes together. The edges of a graph database allow stored data to be linked together and retrieved using one or several operations. In the illustrated example, nodes represent outbreaks, outbreak definitions, outbreak episodes, hosts (e.g., humans, objects, animals, equipment, vectors, etc.), host symptoms, host locations, dates / times the host was at a location, and location hierarchy (e.g., the organizational structure of a hospital facility). Each node has one or more parameters or attributes that define the stored data relevant to the node. Nodes also include edges or relationships. Edges or relationships connect nodes together and define the relationships between them.

[0047] Exemplary graph databases created and processed by exemplary methods, apparatus, and systems may be stored in data structures configured to store nodes, parameters or attributes, and relationships. In some embodiments, the graph database may be configured for query languages ​​such as Gremlin, SPARQL, Cypher, etc. In other embodiments, the graph database may be accessed via one or more application programming interfaces ("APIs").

[0048] The exemplary graph database disclosed herein allows occurrence information to be automatically created from patient medical records, demographic databases, and / or clinician input information. Thus, the graph database allows occurrences to be tracked for each person identified as having a defined condition. As additional information is received, the exemplary systems, methods, and apparatus are configured to update the graph database in near real time to provide an up-to-date representation of potential and actual occurrences. Additional information is easily added by the exemplary systems, methods, and apparatus, such as through the creation of nodes, parameters or attributes, and / or relationships. Because new nodes, parameters or attributes, and relationships are built according to those already in the graph database, no recompilation of the database is required.

[0049] In addition to providing information to help stop the spread, the example systems, methods, and devices disclosed herein are configured to analyze graph databases to determine the distribution, spread, and origin of an outbreak. For example, the systems, methods, and devices disclosed herein can be configured to identify people "at risk" for quarantine or vaccination, provide graphical representations to illustrate the progression of an outbreak, identify intervention points, provide reports to government agencies, perform statistical analysis of the outbreak, e.g., determine incidence rates, epidemic curves, etc., and / or combine outbreak data to determine a picture of the outbreak's burden on a health system region or country.

[0050] The exemplary systems, methods, and devices disclosed herein are configured to create and manage different types of outbreaks. As disclosed herein, outbreaks can include small-scale public health outbreaks (e.g., food poisoning) and / or large-scale public health outbreaks (e.g., epidemics or pandemics). Outbreaks can also include traumatic neurological events, contamination events, and / or hospital-based contagious infections. Thus, outbreaks are not limited to viral or bacterial infections, but can also include chemical, radiation, or biological exposures.

[0051] I. Embodiments of an Incidence Tracking and Management System 1-3 illustrate an exemplary embodiment of an exemplary incidence tracking and management system 100 according to an exemplary embodiment of the present disclosure. The exemplary system 100 includes an incidence management server 102 and a hospital information system (“HIS”) 104. The server 102 is configured to create, analyze, and manage a graph database. The exemplary HIS 104 is configured to provide connectivity within a hospital or healthcare environment. In some examples, the server 102 may be included within the HIS 104. In other examples, the server 102 may be external to the HIS 104 and communicatively coupled thereto.

[0052] The exemplary HIS 104 is communicatively coupled to one or more devices or computers configured to transmit or otherwise provide patient medical data 107 via a network 106. The HIS 104 stores the patient medical data 107 as an electronic medical record ("EMR") in a memory device 108. In the illustrated example, the HIS 104 is communicatively coupled to a laboratory server 110 configured to transmit laboratory patient medical data 107a, a medical device 112 configured to transmit device patient medical data 107b, a clinician device 114 configured to transmit clinician patient medical data 107c, an administration server 116 configured to transmit administrative patient medical data 107d, and a patient tracking server 118 configured to transmit patient tracking medical data 107e.

[0053] The lab server 110 may be communicatively coupled to one or more lab instruments that generate lab data from the analysis of one or more biological samples from patients. The lab server 110 stores the lab data as lab patient medical data 107a, which is periodically transmitted via the HIS 104 to the patient's EMR, which is stored in the memory device 108.

[0054] The medical device 112 includes any type of clinical medical device, including an infusion pump, a renal failure therapy machine, a physiological sensor, a patient bedside monitor, a pulse oximetry monitor, a CT scanner, an MRI scanner, etc. The medical device 112 generates operational data and / or alerts / alerts related to treatments performed on the patient or measurements performed on the patient. The data is stored as device patient medical data 107b and transmitted to the patient's EMR located on the memory device 108. While the example environment 100 of FIG. 1 shows one medical device, it should be understood that the environment 100 may include tens of thousands of medical devices.

[0055] Exemplary clinician devices 114 include any smartphone, tablet computer, laptop computer, desktop computer, workstation, etc. configured to receive data entered by a clinician regarding a patient's condition. The data may include observation notes, prescriptions, treatments, diagnoses, observed / identified symptoms, etc. The received data is stored as clinician-patient medical data 107c and transmitted to the patient's EMR, which is stored in memory device 108. While the exemplary environment 100 of FIG. 1 shows one clinician device 114, it should be understood that environment 100 may include tens of thousands of devices.

[0056] The example management server 116 is configured to receive patient management information. The information includes patient demographic and / or physiological information such as gender, weight, age, date of birth, height, medical history, etc. The information may also include the ward (or treatment area) and / or room assigned to the patient. The information may be received at the time of patient admission or may be entered / obtained after the patient is admitted or transferred to a new location within the medical facility. The management server 116 transmits the management information to the patient's EMR in the memory device 108 as managed patient medical data 107d.

[0057] The exemplary patient tracking server 118 is configured to track the location of patients within a medical facility. The exemplary server 118 is configured to receive information indicating the ward to which the patient is assigned or being transferred. The server 118 is also configured to receive information indicating the room or bed to which the patient is assigned. The server 118 transmits patient tracking medical data 107e via the HIS 104 to the patient's EMR in the memory device 108. The server 118 may transmit data 107e for each patient location change, which may include an indication of discharge.

[0058] The exemplary network 106 may include any wired or wireless local area network ("LAN") and / or wide area network ("WAN"). In some embodiments, the network 106 may include one or more firewalls, gateways, and / or switches that control access, formatting, and data routing. The network 106 may be configured independently within the medical facility and / or may include external networks and corresponding interfaces / virtual tunnels.

[0059] The example HIS 104 is configured to store the received data 107 in an appropriate patient EMR stored in memory device 108. In some embodiments, the patient medical data 107 includes a patient name or other identifier that corresponds to an identifier in or linked to the EMR. The HIS 104 compares the identifiers and determines a match. After a match is identified, the HIS 104 stores the patient medical data in the matching EMR.

[0060] FIG. 5 illustrates an exemplary patient EMR 500 according to an exemplary embodiment of the present disclosure. The EMR 500 includes patient medical data 107 received from one or more of the devices 110-118 of FIG. 1 . This includes the patient's identifier and / or name, physiological and / or demographic information, patient location, symptoms, diagnoses, medical history, medical device data, lab results, prescriptions, and notes. The patient medical data 107 is stored in a relational or tabular data structure to provide a substantial medical characterization of the patient. In some examples, different categories of information include data fields, indicators, or metadata that identify the stored data. For example, the EMR 500 may include an indicator "Room Number" next to an alphanumeric value corresponding to the patient's room and bed. In other embodiments, different types of patient medical data are each stored in different fields or sections of the EMR 500 in a predetermined or pre-structured arrangement.

[0061] Returning to FIG. 1 , the example HIS 104 is configured to provide access to the patient EMR 500 (and more generally, the patient medical data 107) located in the memory device 108. For example, the clinician device 114 may access the memory device 108 via the HIS 104 to view, edit, add, or remove patient medical data from the patient's EMR. Additionally, the example occurrence management server 102 is configured to periodically (e.g., every 60 seconds, every 5 minutes, every hour, etc.) or continuously access the memory device 108 to obtain the patient medical data 107. Additionally or alternatively, the HIS 104 may transmit a copy of the patient medical data 107 to the occurrence management server 102 at periodic times or as the data is received.

[0062] The exemplary Outbreak Management Server 102 is configured to allow a clinician to define a framework for the creation of an outbreak graph database. The exemplary Outbreak Management Server 102 operates according to the framework, as appropriate, to automatically (or with minimal clinician input) create a graph database for the defined types of outbreaks. The Outbreak Management Server 102 is also configured to analyze the graph database to determine the distribution, spread, and origin of the outbreaks. The management server 102 is configured to render the graph database into a graphical representation to provide different views of the outbreaks or to provide the results of analytical or semantic queries. The Outbreak Management Server 102 may also be configured to provide an interactive graphical representation that allows a clinician to filter or hide data or visibility parameters or attribute values ​​for certain levels of underlying data for one or more defined nodes.

[0063] The Outbreak Management Server 102 is communicatively coupled to a memory device 120 configured to store a graph database. As illustrated in FIG. 1 , the Outbreak Management Server 102 receives or otherwise accesses a copy of the patient medical data 107. The Outbreak Management Server 102 is configured to create a graph database 122 from the copy of the patient medical data 107, the graph database 122 including the nodes, relationships, and parameters of the graph database. The Outbreak Management Server 102 analyzes the graph database 122 and creates analyzed data 124, which is also stored in the memory device 120.

[0064] The outbreak management server 102 of FIG. 1 is communicatively coupled to one or more user devices 126 via a wired or wireless network. The server 102 is configured to transmit the graph database 122 and / or analytical data from the memory device 120 for viewing, navigating, and / or editing at the user device 126. In some embodiments, the user device 126 accesses the outbreak management server 102, which provides and / or transmits an interface for interacting with the graph database 122 located in the memory device 120. The interface is configured to include features that allow a user to submit semantic queries and / or select options for analysis. In response to a request from the user device 126, the example outbreak management server 102 performs the requested analysis on the graph database and generates analytical data 124, which is transmitted to the user device 126 for display. The interface may also be configured to allow the user device 126 to modify or add nodes, relationships, and / or parameters to the graph database (or verify nodes, relationships, and / or parameters).

[0065] Exemplary user devices 126 include smartphones, tablet computers, laptop computers, desktop computers, workstations, servers, etc. In some examples, user device 126 may comprise clinician device 114. In other examples, user device 126 may be a device external to or separate from the hospital system that may connect to server 102 through a secure gateway, access port, and / or firewall.

[0066] In some embodiments, the outbreak management server 102 operates according to instructions 128 stored in memory (e.g., memory device 120) that, when executed, cause the outbreak management server 102 to perform the operations, steps, methods, procedures, routines, algorithms, etc. described herein. For example, the instructions enable the server 102 to create, manage, and analyze the outbreak graph database 122 according to user-defined criteria. The example instructions 128 may also be configured to cause the outbreak management server 102 to refine the way in which outbreak medical information is structured within the database by creating a storage structure or framework based on nodes and relationships that approximate actual occurrences. The instructions 128 provide for the creation of an outbreak graph database with clearly defined relationships between different types of nodes at different data levels, which enables computationally efficient processing and analysis for real-time analysis results and near-instant query results based on semantic linguistic input. Additionally, the example instructions 128 are configured to render and manipulate the graph database 122 into a graphical representation that approximates the actual underlying data structure, which is relatively easy for a user to understand compared to the excessive amounts of raw patient medical data or data stored in a relational database.

[0067] FIG. 2 illustrates a schematic diagram of another embodiment of the outbreak tracking and management system 100 of FIG. 1 , in accordance with an exemplary embodiment of the present disclosure. In the illustrated embodiment, an exemplary outbreak management server 102 is communicatively coupled to a user device 126 via a network 202 (e.g., the Internet). The outbreak management server 102 is also communicatively coupled to a data server 204 configured to transmit patient data 206 to create a graph database. The exemplary data server 204 is configured to generate data describing a patient's location at a particular date / time. The data server 204 may also include data indicating a patient's symptoms, physiological information, or anything else that may be relevant to determine nodes, parameters, and / or relationships for the graph database. For example, a social media server 204a is configured to transmit social media data 206a related to the patient. The social media data may include posts, tweets, images, check-in information, etc. The social media data 206a is processed by the Outbreak Management Server 102 using, for example, word maps, keyword identifiers, and other text natural language search routines to identify data related to one or more nodes, relationships, and / or parameters. For example, a social media post may include information indicating that a patient checked into a location at a specified time / date. The exemplary Outbreak Management Server 102 is configured to parse the post for location information to create location nodes. Further, the Outbreak Management Server 102 parses the time / date data 206a for time / date nodes. The Outbreak Management Server 102 may then create relationships between the patient node and the location and time / date nodes, which would be stored in the graph database as "Person (node) - Stayed (relationship) - Stay (node ​​with start and end date / time) - Stayed at - Location (node)." In other examples, the server 102 is configured to identify tags in the data 206 to identify contacts between the patient and other individuals at a location at a date / time.

[0068] The example outbreak management server 102 is also communicatively coupled to a demographics server 204b, which is configured to manage patient demographic information and familial relationships. For example, some government organizations maintain one or more databases of individuals, which may include a person's name, address, age, gender, race, ethnicity, etc. The database may also include a list of other individuals residing at the same address or related to the person. The server 102 is configured to receive demographic data 206b from server 204b. The server 102 analyzes the demographic data and generates population parameter information about interpersonal relationships and patients.

[0069] The example outbreak management server 102 is further communicatively coupled to a geo-location server 204c configured to transmit geo-location tracking data. For example, a mobile phone operator provides a location tracking service for smartphones. The operator maintains a database that correlates a user's location (e.g., GPS location) with the date / time the user was at that location. The server 102 receives this location data 206c from the geo-location server 204c, which it uses to create location and / or date / time nodes for the patient's journey.

[0070] 3 illustrates a schematic diagram of a further embodiment of the incidence tracking and management system 100 of FIG. 1 , in accordance with an exemplary embodiment of the present disclosure. In the illustrated embodiment, the incidence management server 102 optionally receives patient data 206 from a server 204. In addition, the incidence management server 102 is communicatively coupled to the HIS 104 via a network 202. In the illustrated embodiment, the server 102 may comprise a cloud-based service host configured to provide distributed computing across one or more locations.

[0071] 3 also shows that the user device 126 includes an application 302 (e.g., App) configured to display the graph database 122. The application 302 is also configured to allow a user of the device 126 to interact with and / or modify the graph database 122 and / or the analytical data 124. The application 302 may include instructions that cause the device 126 to communicate with one or more APIs at the server 102 to access the graph database 122 and / or the analytical data 124. The application 302 may also include instructions that specify how the graph database 122 and / or the analytical data 124 should be rendered and displayed on the device 126. The application 302 may further include instructions that define interface tools that a user may use to modify or manipulate the graph database 122 and / or the analytical data 124. In some embodiments, the application 302 may be configured to access the patient medical data 107 in the memory device 108 via the HIS 104.

[0072] II. Outbreak Management Server Embodiments FIG. 4 illustrates a schematic diagram of the outbreak management server 102 of FIGS. 1-3 in accordance with an exemplary embodiment of the present disclosure. As disclosed above, the operation of the outbreak management server 102 may be defined by instructions 128 stored in a memory device communicatively coupled to the server 102. FIG. 4 shows a graphical representation of the instructions 128 as operational blocks. In some embodiments, blocks may be combined, added, removed, or further subdivided. It should be understood that the graphical representation of the instructions 128 is provided to illustrate the operation of the server 102. Furthermore, in some embodiments, the instructions 128 may be embodied as hardware, such as an application-specific integrated circuit ("ASIC"), a microcontroller, and / or a processor, or a combination of hardware and software. Additionally or alternatively, the instructions 128 may be executed by a single processor or a group of processors, such as in a distributed computing environment.

[0073] The example outbreak management server 102 of FIG. 4 includes an EMR interface 402 configured to receive or otherwise obtain a copy of the patient medical data 107 from the HIS 104. The example EMR interface 402 may include one or more instructions for accessing one or more APIs in the HIS 104 to read the patient medical data 107 from the memory device 108. The interface 402 may additionally or alternatively be configured to transmit a request message for the patient medical data 107. In some instances, the request message may subscribe to the patient medical data 107 such that changes to the data 107 are automatically sent from the HIS 104 to the EMR interface 402. In some embodiments, the interface 402 may receive the patient medical data 107 from the HIS 104 periodically or continuously without having to send a request message.

[0074] The example interface 402 is configured to transmit received data 107 to the node processor 404. In some embodiments, the interface 402 may queue the data 107 until the node processor 404 is available. Additionally, in some embodiments, the interface 402 may be configured to convert the patient medical data from a first format to a second format that is compatible for processing by the node processor 404 or storage in a graph database. For example, the interface 402 may be configured to convert the patient medical data 107 from HL7 format to ASCII format for storing the data in an EMR or graph database. In some embodiments, the interface 402 converts the data 107 to JSON, HTML, text, or non-SQL format.

[0075] The external data interface 406 of the server 102 is configured to process patient data 206 from an external third-party server 204. Similar to the EMR interface 402, the external data interface 406 may include one or more instructions for accessing one or more APIs in the server 204 to read the patient data 206. The interface 406 may additionally or alternatively be configured to transmit a request message for the patient data 206. The request message may include authentication information for accessing the patient data 206. The request message may also include an identifier (e.g., name, address, alphanumeric code, etc.) for the patient for whom information is requested. For example, the external data interface 406 may request information only after a host node in the developmental graph database has been created for the patient based on the patient medical data 107. In some instances, the request message may subscribe to the patient data 206 so that changes to the data are automatically sent from the server 204 to the external data interface 406. In some embodiments, the interface 406 may receive the patient data 206 from the server 204 periodically or continuously without having to send a request message.

[0076] Again, similar to the EMR interface 402, the example interface 406 is configured to transmit the received data 206 to the node processor 404. In some embodiments, the interface 406 may queue the data 206 until the node processor 404 is available. Additionally, in some embodiments, the interface 406 may be configured to convert the patient data 206 from a first format to a compatible second format for processing by the node processor 404 or storage in a graph database. For example, the interface 402 may be configured to convert the patient data 206 from a text format to an ASCII format for storing the data in the EMR or graph database. In some embodiments, the interface 406 converts the data 206 to JSON, HTML, text, or a non-SQL format.

[0077] Before the outbreak management server 102 can create a graph database, a foundation or framework for the graph database needs to be defined. The example server 102 includes a graph configuration interface 408 and a graph configurer 410 configured to allow a user to configure conditions 412 for outbreak detection and conditions for determining probable / suspect, probable, and confirmed cases. The interface 408 and the configurer 410 are also configured to allow a user to define a hierarchy of node types at a location, such as a hospital. The information 412 provided by the user or generated by the system is stored in a database 414 as an outbreak graph template or definition file.

[0078] It should be understood that conditions 412 do not prescribe or define the structure of the outbreak graph database itself, but rather prescribe or define conditions for creating different node types, determining relationships between nodes, or determining values ​​for describing one or more node parameters. For example, database 414 may store different types of graph database templates for each type of disease, infection, or outbreak. The Commission Implementing Decision of August 8, 2012, Official Journal of the European Union, dated September 27, 2012, establishing case definitions for reporting epidemics (incorporated herein by reference), defines prerequisites (where appropriate), clinical criteria, and diagnostic criteria for many diseases or infectious diseases. In addition, this document prescribes epidemiological and case classification criteria (i.e., definitions of possible / suspect cases of infectious disease, definitions of probable cases of infectious disease, and / or definitions of confirmed cases of infectious disease) for each infectious disease or outbreak condition. The case classification criteria are based on clinical and diagnostic criteria. Together, this information is used in the graph database to prescribe parameters and determine case classifications for the disease or infectious disease case definitions of host nodes. In addition, epidemiological criteria define the susceptibility criteria used to assess the relationship between hosts and to determine the likelihood or susceptibility of hosts or other individuals to infectious disease.

[0079] In one example involving Q fever (Coxiella burnetii), clinical criteria are defined as any human with at least one of the following three symptoms: fever, pneumonia, or hepatitis. Laboratory criteria are defined as at least one of isolation of Coxiella burnetii from a clinical specimen, detection of Coxiella burnetii in nucleic acid in a clinical specimen, or a Coxiella burnetii-specific antibody response (IgG or IgM phase II). Epidemiological criteria include at least one of exposure to a common source or animal-to-human transmission. There is no "probable" categorical case definition, but a "probable" categorical case definition includes any human meeting clinical criteria with an epidemiological link, and a "confirmed" case classification includes any human meeting clinical and laboratory criteria.

[0080] In some embodiments, the graph configuration interface 408 is configured to receive conditions 412 from a clinician or other user (device 114 or 126 in FIG. 1 ). The graph configuration interface 408 may, for example, provide an input user interface or field that prompts the user for case conditions. The received conditions are processed by the graph configurer 410 to define conditions for the specified occurrence. After the conditions are defined, the example node processor 404 is configured to determine whether the patient's symptoms or other medical data 107 match the specified conditions and determine whether the patient has a "probable," "probable," or "confirmed" classified case for the occurrence. If applicable, the node processor 404 creates an episode in the occurrence graph database 122 for the patient, which may include adding a graph or node for the patient to existing graph databases for other patients / nodes with the same disease or occurrence.

[0081] In other embodiments, graph configuration interface 408 is configured to receive conditions 412 as source information, for example, from an electronic version of the Official Journal of the European Union. In these embodiments, graph configurer 410 is configured to read the text, parse it, and identify infectious disease names, prerequisites, clinical criteria, diagnostic or laboratory criteria, epidemiological criteria, and case classifications. Graph configurer 410 automatically creates outbreak templates or definitions for each infectious disease by populating the identified information with appropriate parameters, nodes, relationships, etc. This configuration allows interface 408 to be communicatively coupled to a health system or government database of infectious diseases. Interface 408 uses the connection to obtain new infectious disease information as it becomes publicly available, thereby increasing the speed at which outbreaks can be detected / tracked. It should be understood that outbreak conditions may also be determined for other types of outbreaks, such as food contamination or spoilage, chemical, radiation, etc.

[0082] 6 and 7 illustrate a graphical representation 600 of the conditions 412 of FIG. 4 according to an exemplary embodiment of the present disclosure. The exemplary graphical representation 600 of FIG. 6 includes clinical criteria for influenza. The exemplary graphical representation 600 of FIG. 7 includes laboratory criteria for influenza, epidemiological criteria, and case classifications for “probable,” “probable,” and “confirmed.” The conditions 412 may be provided by a user or automatically extracted from a document or database. The exemplary node configurator 410 is configured to create a definition file or template for an influenza outbreak graph database based on the information in the graphical representation 600. For example, clinical criteria may be labeled as symptoms, with AND or OR logic used to provide a computational relationship between the symptoms in the definition file or template. Additionally, laboratory criteria may be labeled as a laboratory data type. Furthermore, the node configurator 410 may use the epidemiological criteria to determine epidemiological links for the graph database, which may correspond to a higher weighting for identifying potentially infected individuals. Additionally, the case classification includes a Boolean logic of laboratory and clinical criteria that is used by the node configurator 410 to program the conditions for triggering "suspected," "probable," and "confirmed" classifications within the graph database.

[0083] The example node processor 404 of FIG. 4 is configured to create an outbreak graph database for defined infectious disease and other outbreak types. The node processor 404 creates the graph database based on the graph database structure or framework 800 shown in FIG. 8 according to an example embodiment of the present disclosure. The example graph database structure 800 is specifically configured to record different layers of data related to an outbreak. In other words, the graph database structure 800 defines the relationships between different types of nodes (shown as circular elements) and the textual or semantic relationships (e.g., edges) between the nodes. The node processor 404 uses the graph database structure 800 to link nodes together based on a defined format to create only meaningful links for downstream analysis. For example, the graph database structure 800 specifies that an outbreak node is defined by a defining node using a "defining" edge or relationship. Additionally, each occurrence of an outbreak is defined as an episode node with a "container" edge or relationship to the outbreak node. It should be understood that an infinite number of episode nodes may be linked to an occurrence node, representing hosts with cases classified as "confirmed," "probable," or "possible" for the disease associated with the outbreak. Structure 800 prevents nodes other than episode nodes from being directly linked to occurrence nodes, or even prevents occurrence nodes from being linked to other occurrence nodes.

[0084] As illustrated in structure 800 of FIG. 8 , each episode node is connected to a host node via a “case” relationship or link. Host nodes may be connected to other host nodes via epidemiological links, with at least some of the other host nodes having their own episode nodes linking back to an occurrence node (not shown). Host nodes are also connected to symptom nodes via “symptom” edges, relationships, or links. Host nodes may further be connected to one or more stay nodes via “stay” relationships or links. Stay nodes are connected to “place nodes” via “stay-at” relationships or links. In some embodiments, place nodes may be part of a larger hierarchy of place nodes, representing a hierarchy of physical spaces within a place, as shown in FIG. 10 .

[0085] In the illustrated example, role nodes are linked to episode nodes via "role" edges, relationships, or links. This allows the graph database to reflect whether the same person or host acted as a carrier during an occurrence based on a certain role, such as clinician or patient. In some embodiments, occurrence nodes may be linked to note nodes via "has notes" relationships or links. Nodes may specify information related to an occurrence.

[0086] The exemplary node processor 404 is configured to generate an outbreak graph database when a patient has at least a suspected case of an infection or condition associated with an outbreak. The node processor 404 may create separate outbreak graph databases for specific locations until there is enough data to indicate the spread of the outbreak to a larger area. For example, the node processor 404 may create different outbreak graphs for patients in different parts of a city. However, as data provides new cases and interrelationships between patients, the node processor 404 may have enough information to combine the graphs together with other host nodes via epidemiological links.

[0087] The following table provides parameters (e.g., attributes) for each of the different types of nodes shown in FIG. 8. Each occurrence node is connected to a definition node, which contains a case definition for the occurrence. As shown, there is a single definition node per occurrence node. Table 1 below shows the parameters of the definition node. Values ​​for the parameters are identified or received from the condition 412, shown in FIG. 4. It should be understood that the parameters or attributes shown in Table 1 are merely illustrative and that the table may contain additional or fewer parameters or attributes. For example, some occurrences may not have a "suspicious" classification criterion. [Table 1-1]

[0088] For any given outbreak, there are hosts (e.g., sources of infection) that have cases in the outbreak. Cases are labeled as episode nodes. The following cryptographic query on a graph database illustrates an example host connection to an outbreak: [Table 1-2]

[0089] Cryptographic queries may be filtered for non-null case classifications to focus on individuals "affected" by the outbreak. When people (e.g., hosts) are added to an outbreak, the server 102 is configured to create the same relationships (i.e., with connecting episode nodes), but the case classification may not be set initially. This ensures that there is a short list of people or hosts for review before finally assigning a case status. This process is followed each time a host is added to an outbreak or when an individual host is synchronized with the connected server 204. Table 2 below shows the parameters of an episode node. The node processor 404 determines the parameter values ​​for the episode node, for example, from the patient's medical data 107. The start_date / start_ts of the episode node are used to determine the "onset" (e.g., the epidemic line of the outbreak) and indicate when the host or individual became part of the outbreak. The classification may change over time as hosts may transition between "probable," "likely," and "confirmed" case classifications. The node processor 404 uses the definition node to determine a case classification for the episode node. For example, the patient's symptoms and laboratory data 107 are matched by the node processor 404 to the case classification criteria in the definition node to determine whether the patient is suspected, probable, or confirmed for the disease associated with the outbreak. In other examples, a clinician may provide or type in the classification. In these other examples, the node processor 404 may review the patient's information related to the classification criteria and then determine a recommended classification that is displayed for review by the clinician. [Table 2]

[0090] In any single occurrence, a single episode node can be identified as the index instance, which is identified by a one-to-one relationship between the occurrence node and the episode node called the index.

[0091] An exemplary host node includes parameters that provide information related to the host, including parameters that provide an indication or flag as to whether the host is a human, animal, vector, object, etc. The host node may also include parameters related to the name, demographic information, physical characteristics, medical data 107, or other information related to the human. The node processor 404 may analyze or parse the data 107 and 206 for information and populate the parameters. In some embodiments, the node processor 404 may use word maps, natural language matches, tag / field identifiers, and / or metadata to determine characteristics about the population.

[0092] The role nodes shown in Figure 8 may provide roles for at least some occurrence nodes that are linked to episode nodes and linked to people. Table 3 below shows examples of roles, including patients, staff, and the general public. It should be understood that an episode node may have more than one role node, for example, a staff member at a hospital who may ultimately also be a patient. [Table 3-1]

[0093] The example symptom node is linked to the host by the node generator 404 of the server 102 using, for example, the following cryptographic query: [Table 3-2]

[0094] The node generator 404 may determine symptoms from the patient's medical data 107, for example, by searching for symptom keywords. Table 4 below shows exemplary parameters or attributes of a symptom node that may be determined by the node generator 404. The exemplary node generator 404 uses the symptom parameters to determine a host case classification for the episode node using defined criteria. As new symptoms are received, the host generator 404 adds the new symptoms as new symptom nodes connected to the host node and updates the case classification accordingly. Additionally, if a symptom has terminated, the host generator 404 marks the symptom as terminated. In some embodiments, the node generator 404 receives an input message 422 from the device 114 or 126 via the user interface 420. The input message 422 includes symptom information provided by the clinician. The message 422 may also include a case classification. In some embodiments, the user interface 420 may display an input window for the selected patient that allows the user to select a symptom from a drop-down list and / or select an icon representing a case classification. [Table 4]

[0095] The example graph database structure 800 of FIG. 8 illustrates host nodes linked together via epidemiological links. Table 5 below shows examples of types of epidemiological links. In some examples, Table 5 may include risk scores or weights based on links that correspond to how a disease is typically transmitted. Links that are not associated with transmission may be assigned lower risk scores when the database analyzer 430 of the server 102 searches for potential infected hosts. In other cases, Table 5 may contain only epidemiological links related to transmission. [Table 5]

[0096] In some embodiments, node generator 404 is configured to use data 107 and / or 206 to determine epidemiological links (or potential links for confirmation) between hosts. For example, social media or demographic relationship data may be used to determine epidemiological links. In other examples, geographic location may be used to determine when two hosts were in the same location at the same time. In other examples, clinician notes may include a list of individuals who came into contact with a patient. In yet other examples, a patient's treatment schedule, included within data 107, may identify which clinicians came into contact with the patient. Node generator 404 is configured to use word maps, fields, labels, or metadata to identify names from data 107 and / or 206 to identify hosts and potential epidemiological links between hosts.

[0097] In some embodiments, the user interface 420 of FIG. 4 may display an interface screen 900 that provides, for a given selected host 902, a graphical representation of links or potential links between hosts. Upon request, the database analyzer 430 analyzes the links (or links labeled as "potential links") between the selected host and other hosts, determines, and renders a graphical representation. A clinician interacts with the interface screen 900 by selecting potential links and assigning corresponding epidemiological links. The clinician's selection of an epidemiological link causes the node generator 404 to update the links between the selected hosts in the graph database with the received epidemiological link. For example, a potential link is changed by the node generator 404 to an epidemiological link.

[0098] Returning to FIG. 8 , host nodes are linked to location nodes via stay nodes. The stay node specifies the start and end dates and / or times that the host was at a particular location. Table 6 below shows example parameters or attributes of a stay node. The example node generator 404 determines the date / time from patient medical data 107, for example, corresponding to the admission and tracking of a patient within a medical facility. For example, a patient record may indicate that the patient was located in bed A, room 1774 in an acute treatment ward or treatment area, for one week in April 2018. The node generator 404 uses metadata, data indicators, fields, etc. to locate the date, which it uses to populate the appropriate parameter or attribute of the stay node. In other examples, a user may provide the date / time via the user interface 420. Additionally, the node generator 402 may use geographic location data 206 to determine the date / time information. The exemplary date / time information may be used by the data analyzer 430 to determine which hosts were in the same location at the same time. [Table 6]

[0099] A place node includes parameters that identify a place. Table 7 below shows some example parameters for a place node. In addition, a place node may include parameters for GPS coordinates, street address, building name, and / or geographic location of interest. The node generator 404 uses data 107 and / or 206 to determine values ​​for parameters or attributes, as well as to determine a date / time for the place node. [Table 7]

[0100] In many embodiments, locations are part of a larger hierarchical location. In these embodiments, a link to a stay node corresponds to the lowest location node in the hierarchy. A hierarchy may correspond to an organization within a geographic location or physical space, such as a hospital. The example graph builder 410 of FIG. 4 is configured to automatically create a hierarchical location map 1000 from imported data, as shown in FIG. 10A, which may define a hierarchical structure of locations. In other examples, the graph builder 410 allows a user to create the hierarchical location map 1000. As shown in FIG. 10A, each lower-level location is linked to a higher-level location via a "containment" relationship or link. In the illustrated example, a hospital ward location node contains ward location nodes A and B, each of which contains several room location nodes. In addition, some room location nodes are directly connected to the ward location node without a connection to a ward node. Furthermore, some room location nodes connect to separate bed location nodes. 10A corresponds to a hospital, in other embodiments, the graph constructor 410 may create relationship maps for businesses, neighborhoods, cities, commercial / residential buildings, public spaces, transportation systems, etc. The location nodes are used by the database analyzer 430 to determine relationships and / or physical distances between hosts during specified times / dates.

[0101] In some embodiments, location nodes may include a risk score that provides a numerical indication of a host's risk of infection corresponding to the distance between locations. The exemplary database analyzer 430 may use the risk scores for locations to identify potential hosts with epidemiological links to other hosts. For example, patients in adjacent beds may be assigned a relatively high risk score for their respective bed nodes. Table 8 below shows examples of risk scores for different location nodes. [Table 8]

[0102] In some embodiments, a ward location (or other centralized location node) includes parameters or attributes that provide relevant, general (e.g., survey) information about the location. The parameters may be related to an outbreak and / or related to the activity level of the location. In some embodiments, the survey information may be its own node (e.g., a survey node) linked to the location. Table 9 shows an example of survey or location node parameters or attributes related to activity level. The user interface 420 allows a user to provide the information in Table 9. Additionally or alternatively, the node generator 404 is configured to read hospital patient tracking information and determine overall activity for a particular location. For example, the node generator 404 may determine the number of patients in beds for a treatment area compared to the total number of beds. The database analyzer 430 may display the information in Table 9 to show how the activity level of a location changes or corresponds to an outbreak. [Table 9]

[0103] In some embodiments, the exemplary node processor 404 receives batch information about patients in a hospital during a time period associated with an outbreak. In these embodiments, the node processor 404 may create clusters of nodes linked together by hospital location nodes. As more property values ​​are identified from the received patient medical data 107, the node processor 404 determines relationships (e.g., epidemiological links) between patients. Table 10 below illustrates graph database nodes and relationships that the node processor 404 may use to synchronize different clusters of one or more patients across the same location. The database analyzer 430 may determine, for example, from the data in Table 10 that the outbreak is localized to a particular hospital ward or treatment area or room floor. [Table 10]

[0104] In some instances, the node processor 404 is configured to create a single graph database of outbreak types per location. As new patients are hospitalized or develop symptoms, the exemplary node processor 404 is configured to add the patients as host nodes to the graph database. Tracking patients who are not showing symptoms but are in the same location as an outbreak allows the database analyzer 430 to identify patients who are vulnerable to an outbreak.

[0105] In some embodiments, the node processor 404 is configured to include microbiology information in a graph database. As illustrated in FIG. 8, each host node may be connected to a sample node via a "sample" edge, relationship, or link. In addition, a host node's corresponding episode node may also have a "sample" edge or relationship to the sample node. This linking takes into account hosts potentially having many different microbiology samples that may or may not be associated with an outbreak. Table 11 shows example parameters or attributes of a sample node. [Table 11]

[0106] Each sample node can be linked to an isolate node via an "isolate" edge or relationship. The isolate node defines the isolate within the sample result. Table 12 below shows exemplary parameters for an isolate node. [Table 12]

[0107] Isolate nodes can be connected to Microorganism nodes via "Microbe" edges or relationships. Microorganism nodes identify a single microorganism found in the isolation routine. Table 13 below shows exemplary parameters for a Microorganism node. [Table 13]

[0108] In some examples, the node generator 404 can be configured to use a preliminary, final, revision, and deletion ("PFA(D)") system for sample results and isolate levels. FIG. 10B illustrates a graph database 1050 including sample nodes, isolate nodes, and microorganism nodes, according to an exemplary embodiment of the present disclosure. The graph database 1050 shows that samples and isolates from different hosts are traced back to the same microorganism. Such information is useful by indicating not only the spread of an outbreak, but also the biological material involved (or suspected) in the outbreak.

[0109] In some embodiments, the graph database may replace samples, isolates, and microorganisms with similar nodes to identify exposure to chemicals, radiation types, etc.

[0110] 11 illustrates an example graph database 1100 for ward place nodes, according to an exemplary embodiment of the present disclosure. The graph database 1100 may be rendered by the database analyzer 430 in response to viewing relationships to the ward place node. In this example, the database analyzer 430 may collapse or hide the location hierarchy to view stay and host nodes that have relationships to the ward place node. In some instances, the database analyzer 430 is configured to color-code host nodes based on their case classification relative to the outbreak to visually show the spread of the outbreak relative to the ward place node.

[0111] FIG. 12 illustrates an exemplary graph database 1200 for influenza outbreak nodes, according to an exemplary embodiment of the present disclosure. In this example, different types of host nodes are shown, with host node 1202 corresponding to a human and host nodes 1204, 1206, and 1207 corresponding to vectors or objects. The exemplary node generator 404 is configured to generate a separate episode node 1208 for each of the host nodes. However, only episode nodes 1208c and 1208e, which are linked to confirmed or probable cases of influenza in humans, are provided with case numbers. In contrast, the other episode nodes 1208a, 1208b, 1208d, and 1208f are not linked to confirmed or probable cases of influenza and therefore are not assigned case numbers. In addition, the exemplary node generator 404 provides epidemiological links between host nodes 1202, 1204, 1206, and 1208. In some cases, the node generator 404 determines the links from the data 107 and 206. In other cases, the links are defined by the clinician via the user interface 420.

[0112] In some embodiments, different types of outbreaks may be part of the same graph database. In other words, each outbreak may be a separate cluster, where the clusters are linked together based on location and / or host. For example, for a particular location, some hosts may be linked to a first outbreak, while other hosts are linked to a second outbreak. The interrelationships between outbreaks allow the database analyzer 430 to determine and display information about patient vulnerability to certain overlapping outbreaks or to determine correlations between different outbreaks. The database analyzer 430 is configured to filter the graph database for a single outbreak type by removing or hiding nodes related to other outbreaks.

[0113] 13 illustrates a dashboard interface 1300 configured to be rendered by the database analyzer 430, according to an exemplary embodiment of the present disclosure. The dashboard interface 1300 includes a separate section that provides an overview regarding a selected outbreak. The database analyzer 430 analyzes nodes associated with a defined outbreak (e.g., influenza) to determine, for example, the length of the outbreak, the total number of people affected, the total number of deaths attributed to the outbreak, a timeline of onset, and graphs of case classification.

[0114] FIG. 14 illustrates a symptom tracker interface 1400 configured to be rendered by the database analyzer 430, according to an exemplary embodiment of the present disclosure. The database analyzer 430 is configured to use host and symptom nodes to determine which patients had a particular symptom and the corresponding time period for the symptom. The interface 1400 also includes the patient's location or identifier and demographic information under the patient's name. Such information provides an indication of all patients exhibiting at least one symptom that may be associated with the outbreak. In some embodiments, the interface 1400 is interactive. For example, the interface 1400 may include a filter feature for filtering by location, case classification, etc. In response to a request for filtering, the database analyzer 430 determines appropriate information to display from the outbreak graph database. In other embodiments, the interface 1400 is configured to allow a clinician to move, expand, or shorten a time period for a symptom, such as the symptom 1402 for "vomiting." The interface 1400 transmits recommendations provided by the clinician to the node processor 404, which adjusts parameters within the symptom node accordingly (eg, altering the duration of the symptom).

[0115] FIG. 15 illustrates a schematic diagram of a patient interface screen 1500 for a patient (i.e., patient 3) associated with a host node of an outbreak, according to an exemplary embodiment of the present disclosure. The database analyzer 430 determines the information to display in the interface screen 1500 based on patient information, relationships to other hosts, and time / date / location information. A clinician may view the screen 1500 by selecting the patient in the screens / interfaces 1200 and 1400 or by providing a query of the patient's name or identifier. The interface 1500 may provide an overview of the patient's locations over time, including a map of those locations. The interface screen 1500 may also display graphical relationships between the patient and other hosts the patient has come into contact with at an identified location. The interface screen 1500 further indicates, for example, which of those other host nodes have confirmed or probable cases of influenza.

[0116] 16 illustrates a schematic diagram of an outbreak interface screen 1600 for a norovirus outbreak determined by the database analyzer 430, according to an exemplary embodiment of the present disclosure. In the illustrated example, the database analyzer 430 receives a request to view dates of norovirus occurrence in a specified location. In response, the database analyzer 430 analyzes the graph database for nodes related to norovirus and compiles information from case classifications of the corresponding host of patients / humans. In some examples, the interface screen 1600 may include an option for selection that causes the database analyzer 430 to display confirmed cases compared to suspected and probable cases.

[0117] FIG. 17 illustrates a schematic diagram of a map screen 1700 showing a norovirus outbreak in the county of Wales, according to an exemplary embodiment of the present disclosure. In the illustrated example, the database analyzer 430 receives a request to view a map of norovirus outbreaks for a specified location. In response, the database analyzer 430 analyzes a graph database for nodes related to norovirus and the specified location. If the number of confirmed and / or probable cases exceeds a threshold for a particular location, the database analyzer 430 determines that an icon should be placed on the map to indicate the presence of an outbreak at that location. In some embodiments, the threshold may be as low as one case. In some instances, the database analyzer 430 may select the color and / or size of the icon based on the confirmed and / or probable cases for a particular area. A clinician may use tools accompanying the map screen 1700 to zoom in on a particular location and view individual cases, for example, by address and / or area within the healthcare facility. As the clinician changes the resolution of the map screen 1700, the database analyzer 430 may provide higher resolution icons by neighborhood, street, or residence, etc., rather than by city. To do this, the database analyzer 430 determines the confirmed and / or probable cases that correspond to the map displayed, the scale of the area (e.g., neighborhood, street, address, etc.), and the area identified within the displayed map. The database analyzer 430 may also analyze the incidence information over time to provide an indication as to whether incidence is increasing or decreasing with respect to location, compare dates of incidence, and determine locations of spread.

[0118] 18 illustrates a schematic diagram of an outbreak contact screen 1800, according to an exemplary embodiment of the present disclosure. In the illustrated example, the database analyzer 430 receives a request to view links between human hosts or nodes. For a given host, the database analyzer 430 may identify confirmed, probable, or possible cases compared to all contacts. Such information may be used to quarantine or take precautions regarding certain individuals connected to the infected host. The screen 1800 may also show the interrelationships between different hosts and how the outbreak is spreading.

[0119] Exemplary Procedures for Outbreak Tracking and Management 19 and 20 illustrate flow diagrams showing example procedures 1900 and 2000 for configuring and creating a graph database according to an exemplary embodiment of the present disclosure. While procedures 1900 and 2000 are described with reference to the flow diagrams illustrated in FIGS. 19 and 20, it should be understood that many other ways of implementing the steps associated with procedures 1900 and 2000 may be used. For example, the order of many of the blocks may be changed, certain blocks may be combined with other blocks, and many of the described blocks are optional. Furthermore, the actions described in procedures 1900 and 2000 may be performed across multiple devices, including, for example, the outbreak management server 102, the user device 126, the clinician device 114, the HIS 104, and / or the server 204 of FIGS. 1-3. Furthermore, the procedures may illustrate instructions 128 of FIG. 4.

[0120] The example procedure 1900 of FIG. 19 begins when the outbreak management server 102 receives one or more conditions 412 related to an infection or event (block 1902). The conditions 412 may be received in writing from a website and / or typed in by a clinician. The server 102 identifies clinical information within the outbreak conditions and creates definition nodes, templates, and / or files for the defined outbreak (blocks 1904 and 1906). As described above with respect to FIG. 4, this includes identifying case criteria and incorporating the criteria into parameters or attributes of the definition node for the outbreak. The server 102 may also create an outbreak node linked to the definition node (block 1908). The server 102 stores the definition node and the outbreak node in memory (block 1910). The case criteria for the outbreak can then be used to determine whether a host has an episode within the new outbreak. If so, the outbreak can be created in a new graph database or added to the current graph database for the corresponding location.

[0121] The example procedure 2000 of FIG. 20 begins when the Outbreak Management Server 102 receives patient medical data 107 from the HIS 104 (block 2002). The Outbreak Management Server 102 may also receive patient data 206 from the server 204 (block 2004). The Outbreak Management Server 102 then determines the patient's (or human's) previous and current locations based on the data 107 and / or 206 (block 2006). The Outbreak Management Server 102 creates a host node and a location node (and a stay node) for the patient / human (block 2008). The Outbreak Management Server 102 also determines relationships between the patient and other hosts (block 2010). The determined relationships are added to a graph database between the appropriate nodes. In some examples, the Outbreak Management Server 102 may prompt the clinician to provide relationships to other hosts or to provide confirmation of potential determined relationships.

[0122] The example Outbreak Management Server 102 also identifies the patient's symptoms from the data 107 and / or 206 (block 2012). From the identified symptoms, the Outbreak Management Server 102 determines whether the patient's symptoms match a case classification for one or more outbreaks (block 2014). If a match with an outbreak exists, the Outbreak Management Server 102 creates an episode node and creates a link between the patient and the outbreak (block 2016). If a match with a case classification does not exist, the Outbreak Management Server 102 returns to block 2002 to receive data for the same patient or additional patients.

[0123] If the outbreak management server 102 creates an episode node, the server 102 may then compare the number of patient episodes (with the same or similar epidote) to a threshold to determine whether an alert should be generated or whether the outbreak should otherwise be promoted for further attention (block 2018). If the threshold is exceeded, the management server 102 is configured to generate an alert or otherwise transmit a message or provide an indication that the outbreak should receive attention (block 2020). This may include, for example, the server 102 transmitting one or more text messages or pushing a notification to the clinician device 114. If the threshold is not exceeded and / or after an alert is generated, the outbreak management server 102 returns to block 2002 to process newly received data regarding the same patient or other patients.

[0124] conclusion It should be understood that all of the disclosed methods and procedures described herein can be implemented using one or more computer programs or components. These components can be provided as a series of computer instructions on any conventional computer-readable medium, including RAM, ROM, flash memory, magnetic or optical disks, optical memory, or other storage media. The instructions can be configured to be executed by a processor, which, when executing the series of computer instructions, performs or facilitates the performance of all or a portion of the disclosed methods and procedures.

[0125] It should be understood that various changes and modifications to the exemplary embodiments described herein will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the present subject matter and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.

[0126] It is understood that 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, paragraph 6 is not intended to be invoked unless the terms "means" or "steps" are expressly recited in a claim. Thus, the claims are not intended to be limited to the corresponding structure, materials, or actions described in the specification or equivalents.

Claims

1. An occurrence management device, a node processor; an occurrence tracking graph database for a particular disease including an occurrence node connected to a definition node via a "defined by" link, the definition node defining disease parameters for the disease including conditions for disease classification including a "probable" classification for the disease, a "likely" classification for the disease, and a "confirmed" classification for the disease; a memory device storing machine-readable instructions; Equipped with The machine-readable instructions, when executed by the node processor, cause the node processor to: receiving, via the interface, patient data associated with the patient; determining whether the patient should be associated with the occurrence node corresponding to the disease by comparing the patient data with the disease parameters of the definition node; the "probable" classification is selected if at least some of the patient data meets at least some clinical criteria defining at least one condition; The "likely" classification may be based on whether at least some of the patient data: meets at least some of the clinical criteria defining at least one symptom; The patient is selected if he / she has an epidemiological link to a known host in the outbreak tracking graph database for the disease; The "confirmed" classification indicates that at least some of the patient data: at least some of the clinical criteria defining at least one symptom; and At least some laboratory criteria for diagnosis that define at least one of the isolation, detection, identification, or antibody response associated with said disease. is selected if it matches adding the patient to the developmental tracking graph database for the disease if at least one of the "probable", "likely", or "confirmed" classifications is determined for the patient; and A device that performs the following.

2. The node processor: creating a host node for the patient; creating an episode node connected to the host node via a "case" link, the episode node being associated with episode parameters related to the disease classification of the patient; connecting the episode node to the occurrence node via an "inclusion from" link to indicate that the patient is becoming part of the disease occurrence; The apparatus of claim 1 , configured to add the patient to the developmental tracking graph database by:

3. The device of claim 2, wherein the interface is configured to receive the patient data from at least one of an electronic medical record ("EMR") server or a third-party server, and the patient data includes at least one of patient medical data, social media data, location data, or demographic data.

4. The instructions further include causing the node processor to, if sample data is available within the patient data: creating a sample node linked to the host node via a sample link, the sample node being associated with a sample parameter indicating a time or status of a sample obtained from the patient; creating an isolate node linked to the sample node via an isolate link, the isolate node associated with isolate parameters defining an isolate within a sample result associated with the obtained sample; creating a microorganism node linked to the isolate node via a microorganism link, the microorganism node being associated with a microorganism parameter defining at least one microorganism found in the isolation routine; The apparatus of claim 2 .

5. The epidemiological links include at least one of an "airborne transmission" link, an "animal reservoir" link, an "environmental reservoir" link, a "food and drinking water" link, an "insect bite" link, an "animal-human contact" link, a "contaminated object" link, a "droplet spread" link, or a "human-human contact" link; The device of claim 1 , wherein the known host is at least one of a patient, a clinician, a human, an animal, a fomite, or an object.

6. The device described in claim 1, wherein the known host has at least one of a "possible" classification for the disease, a "likely" classification for the disease, or a "confirmed" classification for the disease to enable the epidemiological link to be made to the patient.

7. The known host is associated with a second host node that is connected to a second episode node via a "case" link; The apparatus of claim 6 , wherein the second episode node is connected to the occurrence node of the occurrence tracking graph database via a “container-from” link.

8. The device of claim 1, wherein the node processor is configured to use at least one of social media data, demographic relationship data, geographic location data, clinician notes, or treatment schedules of the patient or the known host to determine the epidemiological link between the patient and the known host.

9. The device of claim 1, wherein the "possible" classification is further selected if at least some of the patient data includes a clinician's judgment regarding the disease.

10. The instructions further cause the node processor to: comparing the number of host nodes or episode nodes added to the outbreak tracking graph database for the disease within a defined time period with a threshold; generating an alert indicating an occurrence of the disease if the number of host nodes or episode nodes exceeds the threshold; The apparatus of claim 1 .

11. The device of claim 10, wherein the alert includes at least one text message or push notification transmitted to at least one clinician device.

12. The device described in claim 10, wherein the comparison is performed only on episode nodes or host nodes associated with a "likely" or "confirmed" classification.

13. A method for operating an occurrence management device, the occurrence management device comprising a server and a memory device, the method comprising: the memory device storing an occurrence tracking graph database for a particular disease including an occurrence node connected to a definition node via a "defined by" link, the definition node defining disease parameters for the disease including conditions for disease classification including a "probable" classification for the disease and a "confirmed" classification for the disease; receiving, by the server, patient data associated with a patient; the server determining whether the patient should be associated with the occurrence node associated with the disease by comparing the patient data with the disease parameters of the definition node; the "probable" classification is selected if at least some of the patient data meets at least some clinical criteria defining at least one condition; The "confirmed" classification indicates that at least some of the patient data: at least some of the clinical criteria defining at least one symptom; and At least some laboratory criteria for diagnosis that define at least one of the isolation, detection, identification, or antibody response associated with said disease. is selected if it matches if at least one of the "probable" or "confirmed" classifications is determined for the patient, the server adds the patient to the incidence tracking graph database for the disease; A method of operation comprising:

14. The patient is the server creating a host node for the patient; the server creating an episode node connected to the host node via a "case" link, the episode node being associated with episode parameters related to the disease classification of the patient; the server connecting the episode node to the occurrence node via an "inclusion from" link to indicate that the patient is becoming part of the disease occurrence; 14. The method of claim 13, wherein the occurrence tracking graph database is added by

15. The method of claim 13, wherein the patient data is received from at least one of an electronic medical record ("EMR") server or a third-party server, and the patient data includes at least one of patient medical data, social media data, location data, or demographic data.

16. The disease classification further comprises a "likely" classification for the disease, The "likely" classification may be based on whether at least some of the patient data: meets at least some of the clinical criteria defining at least one symptom; The patient is selected if he / she has an epidemiological link to a known host in the outbreak tracking graph database for the disease; 14. The method of claim 13, wherein the patient is further added to the developmental tracking graph database for the disease if the "likely" classification is determined for the patient.

17. The epidemiological links include at least one of an "airborne transmission" link, an "animal reservoir" link, an "environmental reservoir" link, a "food and drinking water" link, an "insect bite" link, an "animal-human contact" link, a "contaminated object" link, a "droplet spread" link, or a "human-human contact" link; 17. The method of claim 16, wherein the known host is at least one of a patient, a clinician, a human, an animal, a fomite, or an object.

18. The method of claim 17, wherein the known host has at least one of a "possible" classification for the disease, a "likely" classification for the disease, or a "confirmed" classification for the disease to enable the epidemiological link to be made to the patient.

19. The method of claim 13, wherein the "possibly considered" classification is further selected if at least some of the patient data includes a clinician's judgment regarding the disease.

20. The method of claim 20, wherein the server determines that sample data is available within the patient data; the server creating a sample node linked to the host node via a sample link, the sample node being associated with a sample parameter indicating a time or status of the sample obtained from the patient; the server creating an isolate node linked to the sample node via an isolate link, the isolate node associated with isolate parameters defining an isolate within a sample result associated with the obtained sample; the server creating a microorganism node linked to the isolate node via a microorganism link, the microorganism node being associated with a microorganism parameter defining at least one microorganism found in the isolation routine; The method of claim 14 further comprising:

Images