Epidemic situation management device and epidemic situation management method

Abstract

The invention relates to an epidemic situation management device and an epidemic situation management method. In an example embodiment, an epidemic management system includes a memory device that stores instructions defining a graphical database for disease epidemic tracking. The instructions specify the creation of a host node for a given host and the connection of a seizure node to the host node through a "case" link. The seizure nodes are associated with seizure parameters, the seizure parameters relating to a disease classification of the host. In addition, the instruction specifies that the epidemic node is connected to the attack node via a'partial 'link to indicate that the host has become part of the disease epidemic, the epidemic node is connected to the definition node via a'defined as' link, and the definition node specifies a disease parameter of a disease related to the epidemic node.

Description

[0001] This application is a divisional application, and the parent application it is targeting is a Chinese invention patent application with an application date of July 2, 2019, the applicants being "Baxter International Corporation" and "Baxter Healthcare Co., Ltd.", the invention name being "Graphical Database for Epidemic Tracking and Management", and the application number being 201980044469.6. Technical Field

[0002] The present invention relates to a graphical database for epidemic tracking and management. Background Art

[0003] While the world has advanced, the tracking and management of outbreaks has lagged behind. It often takes months for disease researchers to identify an outbreak and even longer to determine its distribution, spread, and origin. Typically, infection tracking is a manual process that involves studying 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, a lot of effort is required to enter the correct data. In addition, a lot of computing power is required to analyze the collected data. Because of the effort and power required, only relatively severe or harmful outbreaks can be tracked, and many outbreaks cannot be tracked.

[0004] In addition to the above, medical data related to an outbreak is only entered after it is identified. The time lag between outbreak occurrence, identification, data collection, and analysis can cause an outbreak to spread rapidly without people being aware of it. As many healthcare professionals believe, the next pandemic (or wave of pandemics) will begin as small outbreaks in isolated areas (such as urban centers or the fringes of developed regions) and go under the health radar until a large portion of the world's population is affected. Summary of the invention

[0005] The present disclosure describes a graph database for epidemic tracking and management. In particular, the present disclosure describes a method, system and device for creating and updating a graph database to track one or more epidemics. The methods, systems and devices disclosed herein can also be configured to analyze the graph database to provide epidemic management and epidemic prediction. The graph database merges the medical, location, time and / or demographic relationships between nodes according to a predetermined structure. The definitions and relationships provided among different types of nodes enable information to be automatically merged into the graph database. In addition, the definitions and relationships enable the origin of the epidemic to be located to identify the cause and potential solutions of the epidemic.

[0006] Various aspects of the subject matter described herein may be used alone or in combination with one or more other aspects described herein. Without limiting the foregoing description, in a first aspect of the present disclosure, an epidemic 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 epidemic tracking graph database. The node processor creates an epidemic tracking graph database by comparing the patient data with disease parameters of different diseases, the disease parameters specifying a "possible" classification for various diseases, a "probable" classification for various diseases, and a "confirmed" classification for various diseases. For each patient for whom at least one of the "possible", "probable" and "confirmed" classifications is determined for one of the diseases, the node processor adds the patient to a graph database associated with an outbreak of the determined disease by 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 associated with the disease classification of the host, and creating an outbreak node, the outbreak node being connected to the episode node via a "part of" link to indicate that the host has become part of an outbreak of the determined disease, the outbreak node being connected to a definition node via a "defined as" link, the definition node specifying disease parameters of the disease associated with the outbreak node. The outbreak management server apparatus may also include a database analyzer configured to analyze the graph database associated with the outbreak of the determined disease to display at least one of an indexed patient or a relationship among patients for identification.

[0007] According to a second aspect of the present disclosure, which may be used in combination with any other aspect listed 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 host nodes linked to the same epidemic node.

[0008] According to the third aspect of the present disclosure, unless otherwise specified, it can be used in combination with any other aspect listed herein, and the database analyzer is configured to: receive a request from a user device to view the relationship of a designated host associated with a specific disease specified by a relevant epidemic node; determine the epidemiological link between the designated host and (i) other hosts connected to the same relevant epidemic node or (ii) at least one of the persons who are at the same place as the host at the same time; and display a user interface on the user device, wherein the user interface graphically displays the designated host connected to other hosts to display potential contacts with a risk of contact with the specific disease associated with the host.

[0009] According to a fourth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspect listed herein, the node processor is configured to determine a "possible", "probable" or "confirmed" classification for at least some other hosts; and the database analyzer is configured to provide a graphical indication of the "possible", "probable" or "confirmed" classification in a user interface for at least some other hosts.

[0010] According to the fifth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspects listed herein, and the epidemiological link includes at least one of the following: "through the air" link, "animal reservoir" link, "environmental host" link, "food and drinking water" link, "insect bite" link, "animal-to-human contact" link, "contaminated object" link, "droplet transmission" link, or "human-to-human contact" link, and each other host is at least one of a patient, a clinician, a human, an animal, a vector, or an object.

[0011] According to the sixth aspect of the present disclosure, unless otherwise specified, it can be used in combination with any other aspect listed herein, the node processor is configured to: for each host node where sample data is available within the patient data for each patient: create a sample node linked to each host node via a sample link, the sample node being associated with a sample parameter indicating the time or status of the sample obtained from the patient; create an isolation node linked to the sample node via an isolation link, the isolation node being associated with an isolation parameter, the isolation parameter specifying an isolate in the sample result related to the obtained sample; and create a biological node linked to the isolation node via a biological link, the biological node being associated with a biological parameter specifying at least one organism found in an isolation routine.

[0012] According to the seventh aspect of the present disclosure, unless otherwise specified, it can be used in combination with any other aspects listed herein, and the node processor is configured to: determine hosts having the same organism specified in each biological parameter of the biological node as a first host set; determine hosts linked to the same epidemic node as a second host set from the first host set; and display a graphical representation, which displays the connection between the biological node and the epidemic node for the second host set to display the spread of the disease and the biological logic of the epidemic causing the disease.

[0013] According to the eighth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspects listed herein, the node processor is configured to: for each host node for which location data is available within the patient data for the respective patient: create a dwell node linked to the respective host node via a dwell link, the dwell node being associated with a dwell parameter specifying the date / time when the host node is at a specific location; and create a location node linked to the dwell node via an "in" link, the location node being associated with a location parameter specifying the specific location.

[0014] According to the ninth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspects listed herein, and the specific location includes at least one of the following: a hospital bed identifier or node, a room identifier or node, a corridor identifier or node, a ward identifier or node, a level identifier or node, a wing 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, a region 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, unless otherwise stated, it can be used in combination with any other aspects listed herein, the interface is configured to receive patient data from at least one of an electronic medical record ("EMR") server or a third-party server, and wherein the patient data includes at least one of the following: patient medical data, social media data, location data, or demographic data.

[0016] According to the eleventh aspect of the present disclosure, unless otherwise specified, it can be used in combination with any other aspect listed herein, an epidemic management system includes a memory device storing instructions therein, the instructions defining a graph database for disease epidemic tracking. The instructions specify the creation of a host node for a given host, the host node is associated with host parameters, an episode node is connected to the host node via a "case" link, the episode node is associated with an episode parameter related to the disease classification of the host, and an epidemic node is connected to the episode node via a "part of" link to indicate that the host has become part of the epidemic of the disease, the epidemic node is connected to a definition node via a "defined as" link, and the definition node specifies the disease parameters of the disease related to the epidemic node. The system also includes an epidemic management server, the epidemic management server is configured to: receive patient data related to the host, and based on the content of at least some of the received patient data that matches the parameter definition of each node, store at least some of the received patient data in the graph database with one or more parameters of at least one of the host node, the episode node or the epidemic node.

[0017] According to the twelfth aspect of the present disclosure, unless otherwise specified, it can be used in combination with any other aspect listed herein, and the server is configured to connect the host node to the epidemic node via the outbreak 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 the thirteenth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspects listed herein, and the host parameters include at least one of the name of the host, a patient classification mark, a clinician classification mark, a personnel classification mark, an animal classification mark, a vector classification mark, an object classification mark, patient demographic data, or patient medical data.

[0019] According to the fourteenth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspect listed herein, and the onset parameters include at least one of the following: the case number of the host, the "possible" classification of the host's disease, the "probable" classification of the host's disease, the "confirmed" classification of the host's disease, the immune status of the host, the immune type of the host, a sign indicating that the host is infected with the disease in a medical institution, or death information related to the host.

[0020] According to the fifteenth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspects listed herein, and the disease parameters include at least one of the following: the name of the disease, the background of the disease, the time / place related to the disease, the clinical criteria of the disease, the laboratory criteria of the disease, the mode of transmission of 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 the sixteenth aspect of the present disclosure, unless otherwise specified, it can be used in combination with any other aspect listed herein, and the server is configured to: determine the case classification of the attack node for the host node by comparing at least some patient parameters with the criteria for determining the "suspected", "probable" and "confirmed" classifications in the disease parameters; and based on the comparison, store at least one of the "suspected", "probable" or "confirmed" classifications for the disease at each attack parameter of the attack node.

[0022] According to the seventeenth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspects listed herein, and the server is configured to generate a case number for each attack parameter of the attack node after determining a "confirmed" or "probable" classification for the host.

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

[0024] According to the nineteenth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspects listed herein, the instruction specifies a symptom node for a given host connected to the host node via a "having symptoms" link, the symptom node being associated with one or more symptom parameters, the symptom parameters specifying a start date of the symptom, an end date of the symptom, and at least one of a symptom identifier corresponding to the symptom experienced by the host.

[0025] According to the twentieth aspect of the present disclosure, unless otherwise specified, it can be used in combination with any other aspects listed herein, the instruction specifies for a given host that the host node is connected to another host node via an epidemiological link, and wherein the epidemiological link includes at least one of an "through the air" link, an "animal host" link, an "environmental host" link, a "food and drinking water" link, an "insect bite" link, an "animal-to-human contact" link, a "contaminated object" link, a "droplet transmission" link, or a "human-to-human contact" link.

[0026] According to the twenty-first aspect of the present disclosure, referring to Figures 1 to 20 Any structure and function shown and described may be combined with reference to Figures 1 to 20 Any structure and functionality illustrated and described in any of the other figures and any one or more of the foregoing aspects may be used.

[0027] In view of the above aspects and the disclosure of this document, an advantage of the present disclosure is to provide a graph database that provides tracking and management of epidemics.

[0028] Another advantage of the present disclosure is to provide a system that creates a graph database based on a predefined data structure to enable the source of an epidemic to be determined.

[0029] Another advantage of the present disclosure is to provide a system that creates a graph database based on a predefined data structure to identify individuals who are likely or susceptible to an epidemic.

[0030] The advantages discussed herein may be found in one or some, but not all, of the embodiments disclosed herein. Additional features and advantages are described herein and will be apparent from the following detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figures 1 to 3 An example embodiment of an example outbreak tracking and management system including an outbreak management server according to an example embodiment of the present disclosure is shown.

[0032] Figure 4 An example embodiment according to the present disclosure is shown. Figures 1 to 3 Diagram of the epidemic management server.

[0033] Figure 5 A diagram showing an example patient electronic medical record according to an example embodiment of the present disclosure is shown.

[0034] Figure 6 and 7 A diagram showing a graphical representation of an epidemic situation according to an example embodiment of the present disclosure is shown.

[0035] Figure 8A diagram showing an epidemic graph database structure according to an example embodiment of the present disclosure.

[0036] Fig. 9 A diagram showing an interface screen of an epidemic graph database for specifying a host node according to an example embodiment of the present disclosure.

[0037] Fig. 10A A diagram showing a hierarchical location graph for use with a graph database according to an example embodiment of the present disclosure.

[0038] Fig. 10B A diagram of a graph database including sample nodes, quarantine nodes, and biological nodes is shown according to an example embodiment of the present disclosure.

[0039] Fig.11 A diagram showing an example graph database for ward location nodes according to an example embodiment of the present disclosure is shown.

[0040] Fig.12 A diagram showing an example graph database for flu epidemic nodes according to an example embodiment of the present disclosure is shown.

[0041] Figures 13 to 18 A diagram illustrating an example interface screen of epidemic analysis data determined from an epidemic graph database according to an example embodiment of the present disclosure.

[0042] Fig.19 and 20 A flow chart illustrating an example process of configuring and creating a graph database according to an example embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0043] The present disclosure generally relates to a method, system, and apparatus for creating and analyzing an epidemic graph database for epidemic management. The graph database disclosed herein is specifically configured to provide medical, location, and / or temporal relationships between elements of an epidemic. The unique definitions between the elements of the graph database enable associations to be automatically determined among multiple individuals with minimal input from clinicians. The example methods, systems, and apparatus disclosed herein are configured to immediately perform certain defined analyses on the graph database upon receipt of a first suspected, probable, or confirmed case to determine the distribution, spread, and origin of the epidemic in near real time.

[0044] In contrast to graph databases, traditional relational databases consist of tables of data. Certain data from different tables are linked together using unique keys. Relational databases are generally suitable for flat data layouts, where the relationships between data are only one to three levels deep. As additional levels of data are added or data becomes increasingly interrelated, relational databases require a lot of computing power to perform analysis. Some of the computation can be avoided using indexes and relational databases. However, as new data is added, indexes can become outdated, which may require recompiling the database and subsequent analysis.

[0045] As disclosed herein, methods, devices, and systems are configured to operate with a graph database for epidemic management. The graph database includes a data structure of nodes linked via data relationships (e.g., edges). The relationships between nodes can be semantic, which enables semantic analysis and queries. Each node can have one or more parameters or attributes that define or store underlying data. The example graph database disclosed herein enables computationally efficient modeling of complex hierarchies and continuous updating of them when new data is provided. In some cases, the disclosed graph database can have seven to twenty different data levels. Graph databases are particularly suitable for epidemic management because the hierarchical, multi-level nature of the graph database approximates the actual spread of conditions during an epidemic.

[0046] The graph database disclosed herein includes nodes and edges / relationships. The graph database is configured to associate data items in a storage or memory with a collection of nodes and edges. In some embodiments, nodes and edges can be stored in a table or list, wherein the edges are used to link the nodes together. The edges of the graph database enable the stored data to be linked together and retrieved by one or more operations. In the example shown, the nodes represent an epidemic, a definition of an epidemic, an outbreak of an epidemic, a host (e.g., a person, an object, an animal, equipment, a vector, etc.), symptoms of the host, the location of the host, the date / time of the host at the location, and a location hierarchy (e.g., an organizational structure of a hospital facility). Each node has one or more parameters or attributes that define the stored data associated with the node. Nodes also include edges or relationships. Edges or relationships connect nodes together and define the relationship between them.

[0047] The example graph database created and processed by the example methods, apparatus, and systems may be stored in a data structure 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 example graph database disclosed herein enables epidemic information to be automatically created from patient medical records, demographic databases, and / or clinician input information. In this way, the graph database enables the tracking of epidemics for each person identified as having a defined condition. When additional information is received, the example system, method, and apparatus are configured to update the graph database in near real time to provide an up-to-date representation of potential and actual epidemics. Additional information can be easily added through the example system, method, and apparatus, just as by creating nodes, parameters or attributes, and / or relationships. Since new nodes, parameters or attributes, and relationships are built on top of what is already in the graph database, there is no need to recompile the database.

[0049] The example systems, methods, and apparatus disclosed herein are configured to analyze a graphical database to determine the distribution, spread, and origin of an outbreak in addition to providing information that helps stop the spread. For example, the systems, methods, and apparatus disclosed herein can be configured to identify "high risk" populations for quarantine or vaccination, provide graphical representations to illustrate the progress of an outbreak, identify intervention points, provide reports to government agencies, perform statistical analysis of an outbreak to determine, for example, incidence rates, outbreak onset curves, etc., and / or combine outbreak data to determine an overall picture of the burden of an outbreak on a health system region or country.

[0050] The example systems, methods, and devices disclosed herein are configured to create and manage different types of outbreaks. As disclosed herein, an outbreak can include a small public health event (e.g., food poisoning) and / or a large public health event (e.g., an epidemic or pandemic). An outbreak can also include a traumatic neurological event, a contamination event, and / or a nosocomial infectious disease infection. Thus, an outbreak is not limited to viral or bacterial infections, but can also include chemical, radiation, or biological exposures.

[0051] I. Epidemic Tracking and Management System Implementation

[0052] Figures 1 to 3 An example embodiment of an example outbreak tracking and management system 100 is shown according to an example embodiment of the present disclosure. The example system 100 includes an outbreak management server 102 and a hospital information system ("HIS") 104. The server 102 is configured to create, analyze, and manage a graph database. The example HIS 104 is configured to provide connectivity within a hospital or medical 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 to the HIS 104.

[0053] The example HIS 104 is communicatively coupled via a network 106 to one or more devices or computers configured to transmit or otherwise provide patient medical data 107. The HIS 104 stores the patient medical data 107 as an electronic medical record ("EMR") within a memory device 108. In the example shown, 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 administrative server 116 configured to transmit administrative patient medical data 107d, and a patient tracking server 118 configured to transmit patient tracking medical data 107e.

[0054] The laboratory server 110 may be communicatively coupled to one or more laboratory instruments that generate laboratory data by analyzing one or more biological samples from a patient. The laboratory server 110 stores the laboratory data as laboratory patient medical data 107a, which is periodically transmitted to the patient's EMR via the HIS 104 and stored at a memory device 108.

[0055] Medical devices 112 include any type of clinical medical device, including infusion pumps, renal failure treatment machines, physiological sensors, patient bedside monitors, pulse oximeters, CT scanners, MRI scanners, etc. Medical devices 112 generate operational data and / or alarms / alarms regarding treatments performed on a patient or measurements performed on a patient. This data is stored as device patient medical data 107b and transferred to the patient EMR located at memory device 108. Although Figure 1 The example environment 100 shows one medical device, but it should be understood that the environment 100 may include tens of thousands of medical devices.

[0056] Example clinician devices 114 include any smart phone, tablet computer, laptop computer, desktop computer, workstation, etc. configured to receive clinician-entered data 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 at the memory device 108. Although Figure 1 The example environment 100 shows one clinician device 114, but it should be understood that the environment 100 may include tens of thousands of devices.

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

[0058] The example patient tracking server 118 is configured to track the location of a patient in a medical facility. The example server 118 is configured to receive information indicating a ward to which a patient is assigned or has been moved. The server 118 is also configured to receive information indicating a room or bed to which a patient is assigned. The server 118 transmits the patient tracking medical data 107e to the patient's EMR at the memory device 108 via the HIS 104. The server 118 may transmit the data 107e each time the patient's location changes, and may include discharge instructions.

[0059] Example network 106 may include any wired or wireless local area network ("LAN") and / or wide area network ("WAN"). In some examples, network 106 may include one or more firewalls, gateways, and / or switches that control access, formatting, and routing of data. Network 106 may be configured to be self-contained within a medical facility, and / or may include external networks and corresponding interfaces / virtual tunnels.

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

[0061] Figure 5 An example patient EMR 500 is shown according to an example embodiment of the present disclosure. The EMR 500 includes Figure 1The EMR 500 includes patient medical data 107 received by one or more devices 110 to 118. This includes a patient identifier and / or name, patient physiological and / or demographic information, patient location, symptoms, diagnosis, medical history, medical device data, laboratory results, prescriptions, and notes. The patient medical data 107 is stored in a relational or table data structure and provides substantial medical characteristics of the patient. In some examples, different categories of information include data fields, tags, or metadata that identify the stored data. For example, the EMR 500 may include a label "Room Number" next to an alphanumeric value corresponding to a patient's room and bed. In other embodiments, each of the different types of patient medical data is stored in a different field or portion of the EMR 500 in a predefined or preconstructed arrangement.

[0062] Back to Figure 1 , the example HIS 104 is configured to provide access to the patient EMR 500 (more generally, the patient medical data 107) located in the memory device 108. For example, the clinician device 114 can access the memory device 108 via the HIS 104 to view, edit, add, or remove patient medical data from the patient's EMR. In addition, the example outbreak 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 can transmit a copy of the patient medical data 107 to the outbreak management server 102 at a periodic time or upon receipt of the data.

[0063] The example outbreak management server 102 is configured to enable a clinician to specify a framework for creating an outbreak graph database. The example outbreak management server 102 operates according to the framework to automatically (or with minimal clinician input) create a graph database for a specified outbreak type. The outbreak management server 102 is also configured to analyze the graph database to determine the distribution, spread, and origin of the outbreak. The management server 102 is configured to render the graph database as a graphical representation to provide different views of the outbreak or to provide results of an analysis or semantic query. The outbreak management server 102 can be configured to provide an interactive graphical representation that enables a clinician to filter or hide data at a specific level or to view parameter or attribute values ​​of the underlying data of one or more specified nodes.

[0064] The outbreak management server 102 is communicatively coupled to a memory device 120 configured to store a graph database. Figure 1As shown, 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, including nodes, relationships, and parameters of the graph database. The outbreak management server 102 analyzes the graph database 122 to create analysis data 124, which is also stored in the memory device 120.

[0065] Figure 1 The epidemic management server 102 is communicatively coupled to one or more user devices 126 via a wired or wireless network. The server 102 is configured to transmit a graph database 122 and / or analysis data from a memory device 120 to view, navigate and / or edit at a user device 126. In some embodiments, the user device 126 accesses the epidemic management server 102, which provides and / or transmits an interface for interacting with a graph database 122 located in the memory device 120. The interface is configured to include features that enable a user to submit a semantic query and / or select an option for analysis. In response to a request from the user device 126, the example epidemic management server 102 performs the requested analysis on the graph database to generate analysis data 124, which is sent to the user device 126 for display. The interface can also be configured to enable the user device 126 to modify or add nodes, relationships and / or parameters to the graph database (or confirm nodes, relationships and / or parameters).

[0066] Example user devices 126 include smart phones, tablet computers, laptop computers, desktop computers, workstations, servers, etc. In some examples, the user device 126 may include a clinician device 114. In other examples, the user device 126 may be a device external to or separate from a hospital system, which may be connected to the server 102 via a secure gateway, access port, and / or firewall.

[0067] In some embodiments, the epidemic management server 102 operates according to instructions 128 stored in a memory (e.g., a memory device 120), which, when executed, causes the epidemic management server 102 to perform operations, steps, methods, processes, routines, algorithms, etc. described herein. For example, the instructions enable the server 102 to create, manage, and analyze an epidemic graph database 122 according to user-specified criteria. The example instructions 128 may also be configured to enable the epidemic management server 102 to improve how epidemic medical information is structured in a database by creating a storage structure or framework based on nodes and relationships that approximate the actual epidemic. The instructions 128 specify the creation of an epidemic graph database with well-defined relationships between different types of nodes at different data levels, which enables computationally efficient processing and analysis of real-time analysis results and almost instant query results based on semantic language input. In addition, the example instructions 128 are configured to render and process the graph database 122 in a graphical representation that approximates the actual underlying data structure, which is relatively easy for users to understand compared to excessive raw patient medical data or data stored in a relational database.

[0068] Figure 2 An example embodiment according to the present disclosure is shown. Figure 1FIG. 1 is another embodiment of an outbreak tracking and management system 100 of the present invention. In the illustrated embodiment, the example outbreak management server 102 is communicatively coupled to the user device 126 via a network 202 (e.g., the Internet). The outbreak management server 102 may also be communicatively coupled to a data server 204, which is configured to transmit patient data 206 for creating a graph database. The example data server 204 is configured to generate certain data describing the location of a patient at a specific date / time. The data server 204 may also include data indicating the patient's symptoms, physiological information, or any other information related to determining the nodes, parameters, and / or relationships of 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 mappings, keyword identifiers, and other structured natural language search routines to identify data for one or more nodes, relationships, and / or parameters. For example, a social media post may include information indicating that a patient checked in at a location at a specified time / date. The example outbreak management server 102 is configured to parse the post to obtain location information for creating a location node. In addition, the outbreak management server 102 parses the time / date data 206a of the time / date node. The outbreak management server 102 can then create relationships between the patient's node and the location and time / date nodes, which will be stored in the graph database, for example: "Person (node)-STAYED (relationship)-Stay (node ​​of start and end date / time)-IN-Location (node)" ("Person (node)-Stayed (relationship)-Stay (node ​​of start and end date / time)-In-Location (node)"). In other examples, the server 102 is configured to identify tags within the data 206 to identify the patient's contact with other individuals at a specific location at a specific date / time.

[0069] The example outbreak management server 102 may also be communicatively coupled to a demographic server 204b, which is configured to manage demographic information and family relationships of patients. For example, some government organizations maintain one or more databases of individuals that may include the person's name, address, age, gender, race, ethnicity, etc. The database may also include a list of other individuals who live at the same address or are related to the person. The server 102 is configured to receive demographic data 206b from the server 204b. The server 102 analyzes the demographic data to create relationships among individuals and demographic parameter information of the patient.

[0070] The example outbreak management server 102 is further communicatively coupled to a geolocation server 204c, which is configured to transmit geolocation tracking data. For example, a cellular operator provides a location tracking service for smartphones. The operator maintains a database that associates the user's location (e.g., GPS location) with the date / time at which the user was at that location. The server 102 receives the location data 206c from the geolocation server 204c, which is used to create location and / or date / time nodes about the patient's travel.

[0071] Figure 3 An example embodiment according to the present disclosure is shown. Figure 1 FIG. 1 is a diagram of another embodiment of an outbreak tracking and management system 100 of FIG. In the illustrated embodiment, the outbreak management server 102 optionally receives patient data 206 from a server 204. In addition, the outbreak management server 102 is communicatively coupled to the HIS 104 via a network 202. In the illustrated embodiment, the server 102 may include a cloud-based service host configured to provide distributed computing across one or more locations.

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

[0073] II. Epidemic Management Server Implementation

[0074] Figure 4 An example embodiment according to the present disclosure is shown. Figures 1 to 3 FIG. 1 is a diagram of an outbreak management server 102 . As described 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 . Figure 4The graphical representation of instructions 128 is shown as an operational block. In some embodiments, blocks may be combined, added, removed, or further subdivided. It should be appreciated that the graphical representation of instructions 128 is provided to describe the operation of server 102. Furthermore, in some embodiments, instructions 128 may be embodied as hardware or a combination of hardware and software, such as an application specific integrated circuit ("ASIC"), a microcontroller, and / or a processor. Additionally or alternatively, instructions 128 may be executed by a single processor or a group of processors, such as in a distributed computing environment.

[0075] Figure 4 The example outbreak management server 102 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 at 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 send a request message for the patient medical data 107. In some cases, the request message may subscribe to the patient medical data 107 so that changes to the data 107 may be automatically sent from the HIS 104 to the EMR interface 402. In some embodiments, the interface 402 may periodically or continuously receive the patient medical data 107 from the HIS 104 without having to send a request message.

[0076] The example interface 402 is configured to send the received data 107 to the node processor 404. In some embodiments, the interface 402 can queue the data 107 until the node processor 404 is available. In addition, in some embodiments, the interface 402 can be configured to convert the patient medical data from a first format to a second format compatible with being processed by the node processor 404 or stored in a graph database. For example, the interface 402 can be configured to convert the patient medical data 107 from an HL7 format to an ASCII format to store the data in an EMR or a graph database. In some embodiments, the interface 402 converts the data 107 into a JSON, HTML, text, or nonSQL format.

[0077] The external data interface 406 of the server 102 is configured to process the patient data 206 from the 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 at the server 204 to read the patient data 206. The interface 406 may be additionally or alternatively 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.) of the patient whose information is being requested. For example, the external data interface 406 may request information only after a host node in the epidemic graph database has been created for the patient based on the patient medical data 107. In some cases, 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.

[0078] Again, similar to the EMR interface 402, the example interface 406 is configured to send the received data 206 to the node processor 404. In some embodiments, the interface 406 can queue the data 206 until the node processor 404 is available. In addition, in some embodiments, the interface 406 can be configured to convert the patient data from a first format to a second format compatible with processing by the node processor 404 or storage in a graph database. For example, the interface 402 can be configured to convert the patient data 206 from a text format to an ASCII format to store the data in the EMR or graph database. In some embodiments, the interface 406 converts the data 107 into a JSON, HTML, text, or nonSQL format.

[0079] Before the epidemic management server 102 can create a graph database, the foundation or framework of the graph database must be defined. The example server 102 includes a graph configuration interface 408 and a graph configurator 410, which are configured to enable a user to configure conditions 412 for epidemic detection and conditions for determining possible / suspected, possible and confirmed cases. The interface 408 and the configurator 410 are also configured to enable a user to specify a hierarchy of node types in a location such as a hospital. User-provided information or system-generated information 412 is stored in a database 414 as an epidemic graph template or definition file.

[0080] It should be considered that the condition 412 does not specify or define the structure of the epidemic graphical database itself, but specifies the conditions for creating different node types, determining the relationship between nodes, or determining the value for writing one or more node parameters. For example, the database 414 can store different types of graphical database templates for each type of disease, infection, or epidemic. The EU Official Gazette-Commission Executive Decision, released on August 8, 2012, stipulates the case definition of reported infection on September 27, 2012, which is incorporated herein by introduction, wherein the prerequisite conditions (if applicable), clinical standards and diagnostic criteria for various diseases and infections are defined. In addition, the document also stipulates epidemiological standards and case classification standards (i.e., the definition of possible / suspected cases of infection, the definition of probable cases of infection, and / or the definition of confirmed cases of infection) for various infections or epidemic conditions. The case classification standard is based on clinical standards and diagnostic standards. These information are used together to specify parameters and determine the case classification of the case definition of the disease or infection of the host node in the graphical database. In addition, the epidemiological standard also specifies the contraction standard, which is used to evaluate the relationship between hosts to determine the possibility or susceptibility of other individuals contracting the host or infection.

[0081] In the example of Q Fever (Coxiella burnetii), clinical criteria are defined as anyone with at least one of the following three symptoms: fever, pneumonia, or hepatitis. Laboratory criteria are defined as at least one of the following: isolation of Coxiella burnetii from a clinical specimen, detection of Coxiella burnetii in nucleic acid in a clinical specimen, or Coxiella burnetii-specific antibody response (IgG or IgM phase II). Epidemiological criteria include at least one of the following: exposure to a common source or animal-to-human transmission. Although there is no "possible" classification case definition, the "probable" classification case definition includes anyone who meets the clinical criteria and has an epidemiological link, while the "confirmed" case classification includes anyone who meets both clinical and laboratory criteria.

[0082] In some embodiments, the graphical configuration interface 408 is configured to be displayed to a clinician or other user (from Figure 1Device 114 or 126) receives condition 412. Graphic configuration interface 408 can, for example, provide an input user interface or field to prompt a user for a case condition. Graphic configurator 410 processes the received condition to define a condition for a specified outbreak. After the condition is defined, example node processor 404 is configured to determine whether the patient's symptoms or other medical data 107 match the specified condition to determine whether the patient has a "possible", "probable" or "confirmed" classified case for the outbreak. If so, node processor 404 creates an episode in the patient's outbreak graph database 122, which can include adding the patient's graph or node to an existing graph database of other patients / nodes with the same disease or outbreak.

[0083] In other embodiments, the graphic configuration interface 408 is configured to receive status 412 as source information from, for example, an electronic version of the "Official Journal of the European Union". In these embodiments, the graphic configurator 410 is configured to read and parse text to identify infection names, prerequisite conditions, clinical criteria, diagnostic or laboratory criteria, epidemiological criteria, and case classifications. The graphic configurator 410 automatically creates an epidemic template or definition for each infection by filling the identified information into appropriate parameters, nodes, relationships, etc. This configuration enables the interface 408 to be communicatively coupled to a health system or government database of infections. The interface 408 uses the connection to obtain new infection information when it is published, thereby increasing the speed at which the epidemic can be detected / tracked. It should be recognized that epidemic conditions can also be determined for other types of epidemics (such as food contamination or spoilage, chemicals, radiation, etc.).

[0084] Figure 6 and 7 Showing an example embodiment according to the present disclosure, Figure 4 A graphical representation 600 of condition 412 . Figure 6 The example graphical representation 600 includes clinical criteria for influenza. Figure 7The example graphical representation 600 includes laboratory standards, epidemiological standards, and case classifications for "probable", "possible", and "confirmed" for influenza. Conditions 412 can be provided by a user or automatically extracted from a document or database. Example node configurator 410 is configured to create a definition file or template for an influenza epidemic graphical database based on the information in the graphical representation 600. For example, clinical standards can be marked as symptoms, and AND and OR logic are used to provide a computational relationship between symptoms in a definition file or template. In addition, laboratory standards can be marked as laboratory data types. In addition, node configurator 410 can use epidemiological standards to determine epidemiological links for graphical databases, which can correspond to higher weights for identifying potentially infected individuals. In addition, case classification includes Boolean logic of laboratory and clinical standards, which is used by node configurator 410 to program the conditions of "suspected", "probable", and "confirmed" classifications for triggering graphical databases.

[0085] Figure 4 The example node processor 404 is configured to create an epidemic graph database for defined infection and other epidemic types. According to an example embodiment of the present disclosure, the node processor 404 is based on Figure 8 The graphical database structure or framework 800 shown is used to create a graphical database. The example graphical database structure 800 is specifically configured to record different data levels related to the epidemic. In other words, the graphical database structure 800 defines the relationship between different types of nodes (shown as circular elements) and the structural or semantic relationship (e.g., edge) between nodes. The node processor 404 uses the graphical database structure 800 to link nodes together based on the specified format so as to create only meaningful links for downstream analysis. For example, the graphical database structure 800 specifies that the outbreak node (Outbreak Node) is defined by the definition node (DefinitionNode) using the "DEFINED AS" edge or relationship. In addition, each occurrence of the epidemic is designated as an Episode Node (Episode Node), which has a "part of (PART OF)" edge or relationship with the outbreak node. It should be recognized that an unlimited number of Episode Nodes (Episode Nodes) can be linked to an outbreak node representing a host with a classified case "confirmed", "probable" or "possible" about a disease associated with the epidemic. Structure 800 prevents nodes other than outbreak nodes from being directly associated with outbreak nodes, or even prevents outbreak nodes from being linked to other outbreak nodes.

[0086] like Figure 8As shown in structure 800, each outbreak node is connected to a host node (Host Node) via a "case" relationship or link. Host nodes can be connected to other host nodes via epidemiological links, and at least some of the other host nodes have their own outbreak nodes that link back to epidemic nodes (not shown). Host nodes are also connected to symptom nodes (Symptom Nodes) via "HASSYMPTOM" edges, relationships or links. Host nodes can be further connected to one or more stay nodes (STAY Nodes) via a "STAYED" relationship or link. Stay nodes are connected to "location nodes" via a "located at" relationship or link. In some embodiments, as shown in Figure 10, location nodes can be part of a larger hierarchy of location nodes representing a hierarchy of physical spaces in a location.

[0087] In the example shown, the Role Node is linked to the Outbreak Node via a "ROLE" edge, relationship, or link. This enables the graph database to reflect whether the same person or host acted as a carrier during an outbreak based on a specific role (such as a clinician or patient). In some embodiments, the Outbreak Node can be linked to the Note Node via a "HAS NOTE" relationship or link. The Note Node can specify information related to the outbreak.

[0088] The example node processor 404 is configured to generate an epidemic graph database when a patient has at least a suspected case of an infection or condition related to the epidemic. The node processor 404 can create a separate epidemic graph database for a specific location until there is enough data to indicate that the epidemic has spread to a larger area. For example, the node processor 404 can create different epidemic graphs for patients in different locations of a town. However, because the data provides new cases and relationships between patients, the node processor 404 may have enough information to combine graphs together via epidemiological links with other host nodes.

[0089] The following table is Figure 8 Each of the different types of nodes shown provides parameters (e.g., attributes). Each outbreak node is connected to a definition node, which contains the case definition for the outbreak. As shown, each outbreak node has only a single definition node. Table 1 below shows the parameters of the definition node. Figure 4 The condition 412 shown in identifies or receives the value of the parameter. It should be appreciated 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 outbreaks may not have a "suspected" classification criterion.

[0090] Attribute Description name Name(currently"Definition") background Background to the case (HTML) time_place lnformation on the time and place of the outbreak / incident(HTML) clinical_criteria Clinical criteria(HTML) lab_criteria Laboratory criteria(HTML) primary_mode_of_transmission Primary mode of transmission(relationship name) other_modes_of_transmission Other modes of transmission(JSON object of multiple relationships) suspected_enabled Possible / suspected case classification applicable to this outbreak(boolean) probable_enabled Probable case classification applicable to this outbieak(boolean) suspected Criteria for determining a possible / suspected case(HTML) probable Criteria for determining a probable case(HTML) confirmed Criteria for determining a confirmed case(HTML) notes Additional notes (HTML) created_at When the node was created(populated by NeoEloquent) updated_at When the node was last_updated(populated by NeoEloquent)

[0091] Table 1

[0092] For any given outbreak, there are hosts (e.g., infection sources) that have outbreak cases. These cases are labeled as outbreak nodes. The following cryptographic query against the graph database shows an example host association with an outbreak:

[0093]

[0094] Password queries can be filtered for non-empty case classifications in order 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 relationship (i.e., with the connected outbreak node), but the case classification may not be initially set. This way, the list of people or hosts to be investigated is short before the case status is finally assigned. This process is followed whenever a host is added to an outbreak or each host is synchronized from a connected server 204. Table 2 below shows the parameters of the outbreak node. The node processor 404 determines the parameter values ​​for the outbreak node from, for example, the patient's medical data 107. The start_date / start_ts of the outbreak node are used to determine the "incidence" (e.g., the outbreak curve) to indicate when the host or individual became part of the outbreak. Since the host may transition between the "possible", "probable" and "confirmed" case classifications, the classification may change at any time. The node processor 404 uses the definition node to determine the case classification of the outbreak node. For example, the node processor 404 matches the patient's symptoms and laboratory data 107 with the case classification status in the defined node to determine whether the patient is suspected, possible, or confirmed for a disease associated with the outbreak. In other examples, the clinician may provide or input the classification. In these other examples, the node processor 404 may determine a recommended classification, which is displayed to the clinician for confirmation after reviewing the patient information related to the classification status.

[0095] Attribute Descripton start_date Human readable Y-m-d H:i:s date of the start of the case start_ts Timestamp version of the above(better for querying) classification NULL or ′?′(possible), ′P′(probable), ′C′(confirmed) immunisation_status Immunisation status at case onset(json terminology source) immunisation_type Type of immunisation(json terminology source) acquisition_of_infection e.g. hospital-acquired(json terminology source) death_certificate lf person died was the outbreak / incident organism / related condition recorded on the death certificate? created_at Automatically set by NeoEloquent updated_at Automatically set by NeoEloquent

[0096] Table 2

[0097] In any single outbreak, a single outbreak node can be identified as the index case. This can be identified by a one-to-one relationship between the outbreak node and the outbreak node called INDEX.

[0098] The example host node includes parameters that provide information about the host. This includes parameters that provide an indication or sign of whether the host is a person, animal, vector, object, etc. The host node may also include parameters about name, demographics, physical attributes, medical data 107, or other information about the person. The node processor 404 may analyze or parse data 107 and 206 for information to populate the parameters. In some examples, the node processor 404 may use word graphs, natural language matching, tags / field identifiers, and / or metadata to determine the attributes of the population.

[0099] Figure 8 The role nodes shown can be linked to the outbreak node, and at least some of the outbreak nodes linked to people are provided with roles respectively. Table 3 below shows role examples, including patients, staff and the public. It should be appreciated that an outbreak node can have more than one role node, for example, a hospital staff member may also end up being a patient.

[0100]

[0101]

[0102] Table 3

[0103] 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:

[0104]

[0105] The node generator 404 can determine symptoms from the patient's medical data 107 by, for example, searching for symptom keywords. Table 4 below shows example parameters or attributes of symptom nodes that can be determined by the node generator 404. The example node generator 404 uses symptom parameters to determine the case classification of the host for the onset node using defined criteria. When a new symptom is received, the host generator 404 adds the new symptom as a new symptom node connected to the host node, and updates the case classification accordingly. In addition, if the symptom ends, the host generator 404 records the end of the symptom. 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 can also include a case classification. In some embodiments, the user interface 420 can display an input window for a selected patient so that the user can select a symptom and / or select an icon representing a case classification from a drop-down list.

[0106] Attribute Details uuid Unique identifier symptom Symptom-see constants in App\Symptom start_date Start date of symptom(ATOM format) end_date End date of symptom(ATOM format) created_at Automatically populated by NeoEloquent updated_at Automatically populated by NeoEloquent

[0107] Table 4

[0108] Figure 8The example graph database structure 800 shows 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 associations corresponding to how the disease is typically spread. When the database analyzer 430 of the server 102 searches for potentially infected hosts, associations that are not related to transmission may be assigned lower risk scores. In other cases, Table 5 may only contain epidemiological links related to transmission.

[0109] Relationship Description AIRBORNE Airborne ANIMAL_RESERVOIRS 动物宿主 动物到人的接触 动物到人的接触 受污染物体 受污染物体 飞沫传播 飞沫传播 环境宿主 环境宿主 食物和饮用水 食物和饮用水 昆虫叮咬 昆虫叮咬 人到人接触 人到人接触

[0110] Table 5

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

[0112] In some embodiments, Figure 4 The user interface 420 of the embodiment can display an interface screen 900, which provides a graphical representation of associations or potential associations between hosts for a given selected host 902. Upon request, the database analyzer 430 analyzes the associations between the selected host and other hosts (or associations marked as "potential associations") to determine and render a graphical representation. The clinician interacts with the interface screen 900 by selecting a potential association and assigning a corresponding epidemiological link. The clinician's selection of an epidemiological link causes the node generator 404 to update the associations between the selected hosts in the graphical database through the received epidemiological link. For example, the node generator 404 changes the potential association to an epidemiological link.

[0113] return Figure 8, the host node is linked to the location node via the stay node. The stay node specifies the start and end date and / or time of the host at a specific location. Table 6 below shows example parameters or attributes of the stay node. The example node generator 404 determines the date / time, for example, by the patient medical data 107 corresponding to the patient access and tracking in the medical facility. For example, the patient record may indicate that the patient was in the Acute Care Ward or the nursing area 1774 room A bed (Bed A) for one week in April 2018. The node generator 404 uses metadata, data tags, fields, etc. to locate the date, which is used to fill in the appropriate parameters or attributes of the stay node as a value. In other examples, the user can provide the date / time via the user interface 420. In addition, the node generator 402 can use the geographic location data 206 to determine the date / time information. The data analyzer 430 can use the example date / time information to determine which hosts are located in the same place at the same time.

[0114] 属性 描述 开始日期 停留的人类可读开始日期 开始时间戳 停留的时间戳开始日期 结束日期 (可选)停留的人类可读结束日期 结束时间戳 (可选)停留的时间戳结束日期 只读 在用户界面中不可编辑该节点(对于从第三方系统导入的停留记录) 创建时间 节点创建的时间 - 由NeoEloquent自动记录 更新时间 节点最后更新的时间 - 由NeoEloquent自动记录

[0115] Table 6

[0116] The location node includes parameters that identify the location. Table 7 below shows examples of parameters for a location node. In addition, the location node may include parameters for GPS coordinates, street addresses, building names, and / or attractions. Node generator 404 uses data 107 and / or 206 to determine the value of a parameter or attribute, similar to determining the date / time of a location node.

[0117] 属性 描述 通用唯一识别码 位置的唯一标识符 名称 位置的名称 类型 位置的类型:例如房间、隔间、医院群组等 风险 位置接近风险评分(见上文) 只读 Set to true if the locations data is imported from a third party system(see below) created_at When the node was created - recorded automatically by NeoEloquent updated_at When the node was last updated - recorded automatically by NeoEloquent

[0118] Table 7

[0119] In many embodiments, the location is part of a larger hierarchical location. In these embodiments, the link to the stay node corresponds to the lowest location node in the hierarchy. The hierarchy can correspond to a geographic location or an organization in a physical space, such as a hospital. Figure 4 The example graphic configurator 410 is configured to automatically create a hierarchical location map 1000 from imported data, such as Figure 10A As shown, the imported data may specify a hierarchical structure of locations. In other examples, the graphic configurator 410 enables a user to create a hierarchical location map 1000. Figure 10AAs shown, each sub-location is linked to a higher-order location via a "CONTAINS" relationship or link. In the example shown, the hospital ward location node (Ward LocationNode) contains the wing location nodes (Wing Location Nodes) A ​​and B, each of which contains multiple room location nodes. In addition, some room location nodes (Room Location Nodes) are directly connected to the ward location node, without being connected to the wing node (Wing Node). In addition, some room location nodes are connected to individual bed location nodes. Although Figure 10A The diagram 1000 in FIG. 4 corresponds to a hospital, but in other examples, the graph configurator 410 can create a relationship graph for a business, a community, a city, a commercial / residential building, a public place, a transportation system, etc. The database analyzer 430 uses the location nodes to determine the relationship and / or physical distance between hosts during a specified time / date.

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

[0121]

[0122] Table 8

[0123] In some embodiments, the ward location (or other centralized location node) includes parameters or attributes that provide general (e.g., survey) information related to the location. Parameters can be related to the epidemic and / or to the activity level of the location. In some embodiments, the survey information can be its own node (e.g., Survey Node), which is linked to the location. Table 9 shows examples of parameters or attributes of survey or location nodes related to activity levels. User interface 420 enables a user to provide the information in Table 9. Additionally or alternatively, node generator 404 is configured to read hospital patient tracking information to determine the overall activity of a particular location. For example, node generator 404 can determine the number of patients in a bed in a nursing area compared to the total number of beds. Database analyzer 430 can display the information in Table 9 to show how the activity level of a location changes or corresponds to an epidemic.

[0124] Attribute Description date Human readable date(Y - m - d) date_ts Timestamp of the date of the survey(at 00:00 hours) specialty Specialty of the ward(text) closed Boolean: whether or not the ward is closed rooms Number of bays / rooms rooms_closed Number of bays / rooms closed cohorted Number of cohorted patients empty_beds Number of empty beds(at 10am) isolation_rooms Number of isolation rooms staffed_beds Number of staffed beds created_at When the node was created - recorded automatically by NeoEloquent updated_at When the node was last_updated - recorded automatically by NeoEloquent

[0125] Table 9

[0126] In some embodiments, the example node processor 404 receives batch information about patients in the hospital during a time period related to the epidemic. In these embodiments, the node processor 404 can create a cluster of nodes linked together by the hospital location node. When more attribute values ​​are identified from the received patient medical data 107, the node processor 404 determines the relationship between the patients (e.g., epidemiological links). Table 10 below shows the nodes and relationships of the graphical database of different clusters of one or more patients in the same place that the node processor 404 can use to synchronize. The database analyzer 430 determines, for example, from the data in Table 10 that the epidemic occurred at a specific hospital ward or nursing area or room level.

[0127] Node Details Host:Person Each patient will have a unique Host:Person node stay Each period of ward / room / bed occupancy will be represented by a Stay node Location:HospitalGroup A hospital group location Location: Hospital A hospital location Location: Ward A ward location Location: Room A room level location Location: Bed A bed level location

[0128] Table 10

[0129] In some cases, the node processor 404 is configured to create a single graph database for each type of outbreak at each location. When a new patient is admitted or includes symptoms, the example node processor 404 is configured to add the patient as a host node to the graph database. Tracking patients who do not exhibit symptoms but are in the same location as the outbreak enables the database analyzer 430 to identify patients who are susceptible to the outbreak.

[0130] In some embodiments, the node processor 404 is configured to include microbiology information in the graph database. Figure 8 As shown, each host node can be connected to a sample node (Specimen Node) via a "Specimen" edge, relationship or link. In addition, the corresponding outbreak node of the host node can also have a "sample" edge or relationship with the sample node. This linking indicates that the host may have many different microbial samples, which may or may not be related to the epidemic. Table 11 shows example parameters or attributes of the sample node.

[0131]

[0132] Table 11

[0133] Each sample node may be linked to an IsolateNode via an "ISOLATE" edge or relationship. An IsolateNode specifies an isolate within a sample result. Table 12 below shows example parameters for an IsolateNode.

[0134] Attribute Description uuid String″{lab_request_id}#{specimen_number}#{organism_code}″ readonly (boolean) indication that this is imported data so is read only in the UI result_status PFA result status of the isolate (Preliminary, Final or Amended) created_at When the node was created updated_at When the node was last updated

[0135] Table 12

[0136] The Isolation Node may be connected to an OrganismNode via an "Organism" edge or relationship. The OrganismNode identifies a single organism found in the Isolation Routine. Table 13 below shows example parameters for the OrganismNode.

[0137] Attribute Description uuid Code for the organism (the organism code from ICNet) readonly (boolean) indication that this is imported data so is read only in the UI name Name of the organism created_at When the node was created updated_at When the node was last updated

[0138] Table 13

[0139] In some examples, node generator 404 can be configured to use a Preliminary, Final, Amended, and Deleted (“PFA(D)”) system for sample results and separation levels. Figure 10B A graph database 1050 including sample nodes, quarantine nodes, and biological nodes is shown according to an example embodiment of the present disclosure. The graph database 1050 shows that samples and isolates from different hosts can be traced back to the same organism. Such information can not only show the spread of the epidemic, but also show the biological logic that caused the epidemic (or suspected).

[0140] In some examples, graph databases can replace samples, isolates, and organisms with similar nodes to identify exposure to chemicals, types of radiation, and more.

[0141] Figure 11 An example graphical database 1100 of ward location nodes is shown according to an example embodiment of the present disclosure. The graphical database 1100 may be rendered by the database analyzer 430 in response to viewing a relationship relative to the ward location node. In this example, the database analyzer 430 may compress or hide the location hierarchy to view the stay nodes and host nodes that have a relationship with the ward location node. In some cases, the database analyzer 430 is configured to color-code the host nodes based on the case classification of the epidemic to visually indicate the spread of the epidemic relative to the ward location node.

[0142] Figure 12An example graph database 1200 for influenza epidemic nodes according to an example embodiment of the present disclosure is shown. In this example, different types of host nodes are shown, wherein host node 1202 corresponds to a person, and host nodes 1204, 1206, and 1207 correspond to a vector or object. The example node generator 404 is configured to generate a separate attack node 1208 for each host node. However, only the attack nodes 1208c and 1208e that are linked to confirmed or clinical cases of influenza in a person are provided with case numbers. In contrast, other attack nodes 1208a, 1208b, 1208d, and 1208f are not linked to confirmed or clinical cases of influenza, and therefore are not assigned case numbers. In addition, the example node generator 404 provides epidemiological links between host nodes 1202, 1204, 1206, and 1208. In some cases, the node generator 404 determines the link from data 107 and 206. In other cases, the link is specified by a clinician via a user interface 420.

[0143] 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 that is linked together based on location and / or hosts. For example, for a particular location, some hosts may be linked to a first outbreak, while other hosts may be linked to a second outbreak. The interrelationships between outbreaks enable the database analyzer 430 to determine and display information about a patient's susceptibility 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.

[0144] Figure 13 A dashboard interface 1300 configured to be rendered by a database analyzer 430 is shown according to an example embodiment of the present disclosure. The dashboard interface 1300 includes separate sections that provide an overview of a selected outbreak. The database analyzer 430 analyzes, for example, nodes related to a specified outbreak (e.g., influenza) to determine, for example, the duration of the outbreak, the total number of people infected, the total number of deaths attributable to the outbreak, a timeline of incidence, and a case classification graph.

[0145] Figure 14A symptom tracker interface 1400 configured to be rendered by a database analyzer 430 is shown according to an example embodiment of the present disclosure. The database analyzer 430 is configured to use the host and symptom nodes to determine which patients have specific symptoms and the corresponding time period of the symptoms. The interface 1400 also includes the patient's location or identifier and demographic information under the patient's name. Such information indicates that all patients show an indication of at least one symptom that may be related to the epidemic. In some embodiments, the interface 1400 is interactive. For example, the interface 1400 may include a filter feature to filter by location, case classification, etc. In response to a request for filtering, the database analyzer 430 determines the appropriate information to be displayed from the epidemic graphical database. In other embodiments, the interface 1400 is configured to enable a clinician to move, expand, or shorten the time period of a symptom (such as the symptom 1402 of "vomiting"). The interface 1400 transmits the recommendation provided by the clinician to the node processor 404, and the node processor 404 adjusts the parameters in the symptom node accordingly (e.g., changing the duration of the symptom).

[0146] Figure 15 A diagram of a patient interface screen 1500 of a patient (i.e., patient 3) associated with a host node of an epidemic is shown according to an example embodiment of the present disclosure. The database analyzer 430 determines the information to be displayed in the interface screen 1500 based on the patient information, the relationship with other hosts, and the time / date-location information. The clinician can view the screen 1500 by selecting a patient in the screens / interfaces 1200 and 1400 or by providing a query entry of the patient's name or identifier. The interface 1500 can provide an overview of the patient's location over time, including a map of these locations. The interface screen 1500 can also display a graphical relationship between the patient and other hosts that the patient has contacted at certain identified locations. The interface screen 1500 further shows, for example, which of those other host nodes have confirmed or probable cases of influenza.

[0147] Figure 16 A diagram of an outbreak interface screen 1600 for a Norovirus outbreak determined by a database analyzer 430 is shown according to an example embodiment of the present disclosure. In the example shown, the database analyzer 430 receives a request to view the date on which the Norovirus occurred at a specified location. In response, the database analyzer 430 analyzes the nodes in the graph database related to the Norovirus and compiles information from case classifications of hosts corresponding to the patient / person. In some examples, the interface screen 1600 may include options for selection that cause the database analyzer 430 to display confirmed cases compared to suspected and probable cases.

[0148] Figure 17Shown is a diagram of a map screen 1700 of an outbreak of norovirus for Welsh County according to an example embodiment of the present disclosure. In the example shown, the database analyzer 430 receives a request for viewing a diagram of an outbreak of norovirus at a specified location. In response, the database analyzer 430 analyzes nodes related to norovirus and a specified location in a graph database. If the number of confirmed and / or probable cases for a specific location exceeds a threshold, the database analyzer 430 determines to place an icon on the map to indicate that there is an outbreak at the location. In some embodiments, the threshold may be as low as one case. In some cases, the database analyzer 430 may select the color and / or size of an icon based on confirmed and / or probable cases for a specific area. A clinician may use a tool with a map screen 1700 to zoom in to a specific location to view, for example, individual cases by address and / or area in a medical facility. When the clinician changes the resolution of the map screen 1700, the database analyzer 430 may provide icons at a higher resolution (such as by community, street, or residence rather than by town). To this end, the database analyzer 430 determines the scale of the displayed map, the region (e.g., community, street, address, etc.) within the displayed map, and the confirmed and / or probable cases corresponding to the identified region. The database analyzer 430 can also analyze the epidemic information over time to provide an indication of whether the incidence rate at a certain location is increasing or decreasing, and compare the dates of the incidence rate to determine the location of the spread.

[0149] Figure 18 A diagram of a contact screen 1800 for an epidemic according to an example embodiment of the present disclosure is shown. In the example shown, the database analyzer 430 receives a request to view links between human hosts or nodes. The database analyzer 430 can identify confirmed, probable or possible cases compared to all contacts of a given host. This information can be used to isolate or take precautions against certain individuals who are in contact with an infected host. The screen 1800 can also display the relationships among different hosts and how the epidemic spreads.

[0150] Example process for epidemic tracking and management

[0151] Figure 19 and 20 Flowcharts 1900 and 2000 are shown showing example processes 1900 and 2000 for configuring and creating a graph database according to an example embodiment of the present disclosure. Figures 19 to 20The flowcharts shown describe processes 1900 and 2000, but it should be appreciated that many other methods of performing the steps associated with processes 1900 and 2000 may be used. For example, the order of many of the blocks may be changed, some blocks may be combined with other blocks, and many of the blocks described are optional. In addition, the actions described in processes 1900 and 2000 may be performed in multiple devices, including, for example, Figures 1 to 3 The outbreak management server 102, the user device 126, the clinician device 114, the HIS 104 and / or the server 204. In addition, the process may illustrate Figure 4 Instruction 128.

[0152] When the outbreak management server 102 receives one or more conditions 412 of an epidemic or event (block 1902), Figure 19 The example process 1900 begins. The condition 412 may be received from a website as a document and / or entered by a clinician. The server 102 identifies clinical information within the outbreak condition and creates a definition node, template, and / or file for the specified outbreak (blocks 1904 and 1906). Figure 4 As described, it includes identifying case criteria and filling the criteria into the parameters or attributes of the definition node for the epidemic. The server 102 can also create an epidemic node linked to the definition node (box 1908). The server 102 stores the definition node and the epidemic node in a memory (box 1910). The case criteria for the epidemic can then be used to determine whether the host has an outbreak in the new epidemic. If so, the epidemic can be created in a new graphical database, or the epidemic can be added to the current graphical database for the corresponding location.

[0153] When the epidemic management server 102 receives the patient medical data 107 from the HIS 104 (block 2002), Figure 20 The example process 2000 of begins. The outbreak management server 102 may also receive patient data 206 from server 204 (box 2004). The outbreak management server 102 then determines the past and current locations of the patient (or person) based on data 107 and / or 206 (box 2006). The outbreak management server 102 creates a host node and a location node (as well as a stay node) for the patient / person (box 2008). The outbreak management server 102 also determines the relationship between the patient and other hosts (box 2010). The determined relationship is added to the graph database between the appropriate nodes. In some examples, the outbreak management server 102 may prompt the clinician to provide the relationship with other hosts or provide confirmation of the potential determined relationship.

[0154] The example outbreak management server 102 also identifies the patient's symptoms from the data 107 and / or 206 (block 2012). The outbreak management server 102 determines from the identified symptoms whether the patient's symptoms match a case classification for one or more outbreaks (block 2014). If there is a match to an outbreak, the outbreak management server 102 creates an episode node and creates an association between the patient and the outbreak (block 2016). If there is no match to a case classification, the outbreak management server 102 returns to block 2002 and receives data for the same patient or an additional patient.

[0155] If the outbreak management server 102 creates an outbreak node, the server 102 may compare the number of patient outbreaks (having the same or similar outbreak nodes) to a threshold to determine whether an alert should be generated or more attention should be otherwise paid to the outbreak (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 be paid attention to (block 2020). This may include, for example, the server 102 transmitting one or more text messages or push notifications 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 for the same patient or other patients.

[0156] Conclusion

[0157] It will be appreciated that all disclosed methods and processes described herein may be implemented using one or more computer programs or components. These components may be provided as a series of computer instructions on any conventional computer-readable medium (including RAM, ROM, flash memory, magnetic or optical disks, optical storage or other storage media). The instructions may be configured to be executed by a processor that, when executing a series of computer instructions, performs or facilitates the execution of all or part of the disclosed methods and processes.

[0158] It should be understood that various changes and modifications to the example embodiments described herein will be apparent to those skilled in the art. Such changes and modifications may be made without departing from the spirit and scope of the present subject matter and without reducing its expected advantages. Therefore, it is intended that such changes and modifications be covered by the appended claims.

[0159] It should be recognized that no invocation of 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, paragraph 6, is intended unless the term "means" or "step" is explicitly recited in a claim. Thus, the claims are not intended to be limited to the corresponding structures, materials, or acts described in the specification or their equivalents.

Claims

1. An epidemic management device, comprising: Node processor; as well as a memory device storing machine-readable instructions that, when executed by the node processor, cause the node processor to: receiving, via the interface, patient data associated with the patient, Create an epidemic tracking graph database for a specific disease by doing the following: creating an outbreak node connected to a definition node via a "is defined as" link, the definition node specifying disease parameters of the disease associated with the outbreak node, comparing the patient data to disease parameters of the definition node connected to the outbreak node, the disease parameters specifying conditions for a "possible" classification for the disease, a "probable" classification for the disease, and a "confirmed" classification for the disease, and For each patient for whom at least one of the "possible", "probable" and "confirmed" classifications is determined for the disease, the patient is added to the outbreak tracking graphical database by: 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 host, and connecting the outbreak node to the outbreak node via a "part of" link to indicate that the host has become part of an outbreak for the disease, comparing a graphical database associated with outbreaks of the disease to a threshold value, and When the number of outbreak nodes or host nodes connected to the outbreak node exceeds the threshold, an alert indicating an outbreak of the disease is generated.

2. The device according to claim 1, wherein: The alert includes one or more text messages or push notifications transmitted to at least one clinician device.

3. The device according to claim 1, wherein: Only episode nodes or host nodes associated with the "probable" or "confirmed" classification were compared.

4. The device according to claim 1, wherein: Only onset nodes or host nodes associated with a specific location were compared.

5. The device according to claim 4, wherein: The alert includes an icon placed on a map to indicate the presence of an outbreak of the disease at the particular location.

6. The device according to claim 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 wherein, The patient data includes at least one of patient medical data, social media data, location data, or demographic data.

7. The device according to claim 1, wherein: The instructions further cause the node processor to, for each host node for which location data is available within the patient data for a corresponding patient: using the relevant patient data, determining a location associated with the host node; as well as For each determined location, (i) creating a dwell node linked to a corresponding host node via a dwell link, the dwell node being associated with a dwell parameter specifying a date / time at which the host node was at a particular location, and (ii) creating a location node linked to the stay node via an "in" link, the location node being associated with a location parameter specifying the specific location.

8. The device according to claim 7, wherein: The position parameters include at least one of the following: A hospital bed identifier or node, a room identifier or node, a corridor identifier or node, a ward identifier or node, a level identifier or node, a wing 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, a region identifier or node, a state identifier or node, a country identifier or node, or GPS coordinates.

9. The device according to claim 7, wherein: The instructions also cause the node processor to: determining individuals associated with each particular location that match the dwell parameters; and Do at least one of the following: Send instructions to the identified individual, or Send outbreak notifications to identified individuals.

10. The device according to claim 9, wherein: The instructions further cause the node processor to, for each determined individual: Create a host node; creating a dwell node linked to a corresponding host node via a dwell link, the dwell node being associated with a dwell parameter specifying a date / time when the host node was at the particular location; and The stay node is connected to the location node of the specific location via an "in" link, the location node being associated with a location parameter specifying the specific location.

11. The device according to claim 1, wherein: The instructions further cause the node processor to display at least one of an indexed patient or a relationship between patients for identification.

12. The device according to claim 1, wherein: The instructions also cause the node processor to: For each host node, an epidemiological link is created between the host and at least one of (i) or (ii) below, wherein: (i) other hosts connected to the same epidemic node, (ii) an individual who has been in the same location as the host at the same time.

13. The device according to claim 12, wherein: The epidemiology link includes at least one of the following: "through air" link, "animal reservoir" link, "environmental reservoir" link, "food and drinking water" link, "insect bite" link, "animal-to-human contact" link, "contaminated object" link, "droplet transmission" link, or "human-to-human contact" link, and Each of the other hosts is at least one of a patient, a clinician, a human, an animal, a vector or an object.

14. A method for epidemic management, comprising: In a server, receiving patient data associated with a patient; Through the server, a disease-specific epidemic tracking graph database is created by: creating an outbreak node connected to a definition node via a "is defined as" link, the definition node specifying disease parameters of the disease associated with the outbreak node, comparing the patient data to disease parameters of a definition node connected to the outbreak node, the disease parameters specifying conditions for a "possible" classification for the disease, a "probable" classification for the disease, and a "confirmed" classification for the disease, and For each patient for whom at least one of the "possible", "probable" and "confirmed" classifications is determined for the disease, the patient is added to the outbreak tracking graphical database by: 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 host, and connecting the outbreak node to the outbreak node via a "part of" link to indicate that the host has become part of an outbreak for the disease, comparing, via the server, a graphical database associated with the outbreak of the disease with a threshold value, and Via the server, when the number of outbreak nodes or host nodes connected to the outbreak node exceeds the threshold, an alert indicating an outbreak of the disease is generated.

15. The method according to claim 14, wherein: Comparisons are made only between onset nodes or host nodes associated with a particular location, and The alert includes an icon placed on a map to indicate that an outbreak of the disease exists at the particular location.

16. The method according to claim 14, wherein: The seizure parameters include at least one of the following: The case number of the host, the "possible" classification of the host's disease, the "probable" classification of the host's disease, the "confirmed" classification of the host's disease, the host's immune status, the host's immune type, signs indicating that the host was infected with the disease in a medical institution, or death information related to the host.

17. The method according to claim 14, wherein: The disease parameters include at least one of the following: The name of the disease, the background of the disease, the time / place associated with the disease, the clinical criteria for the disease, the laboratory criteria for the disease, the mode of transmission of the disease, the criteria used to determine the "possible" classification, the criteria used to determine the "probable" classification, and the criteria used to determine the "confirmed" classification.

18. The method according to claim 14, further comprising: For each host node for which location data is available in the patient data for the corresponding patient: determining, via the server, a location associated with the host node using the associated patient data; as well as For each determined location, (i) creating, via the server, a dwell node linked to a corresponding host node via a dwell link, the dwell node being associated with a dwell parameter specifying a date / time at which the host node was at a particular location, and (ii) creating, via the server, a location node linked to the stay node via an “in” link, the location node being associated with a location parameter specifying the specific location.

19. The method according to claim 18, further comprising: determining or recording, via the server, individuals associated with each specific location that match the stay parameters; as well as Do at least one of the following: sending, via the server, an indication of the determined individual, or, An epidemic notification is sent to the determined individuals via the server.

20. The method according to claim 19, further comprising: For each identified individual, Creating a host node via the server; creating, via the server, a dwell node linked to a corresponding host node via a dwell link, the dwell node being associated with a dwell parameter specifying a date / time at which the host node was at the particular location; as well as The stay node is connected, via the server, to the location node of the specific location via an "in" link, the location node being associated with a location parameter specifying the specific location.

21. An epidemic management device, comprising: Node processor; an outbreak tracking graph database for a specific disease, the outbreak tracking graph database comprising outbreak nodes connected to definition nodes via "defined as" links, the definition nodes specifying disease parameters for the disease, the disease parameters comprising conditions for disease classification, the disease classification comprising a "possible" classification for the disease, a "probable" classification for the disease, and a "confirmed" classification for the disease; and a memory device storing machine-readable instructions that, when executed by a 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 an epidemic node corresponding to the disease by comparing the patient data with the disease parameters of the defined node, wherein: selecting a "likely" classification when at least some of the patient data matches at least some of the clinical criteria specifying at least one symptom, selecting a "likely" classification when at least some of said patient data matches at least some of said clinical criteria specifying at least one symptom, and The patient has an epidemiological link to a known host of the outbreak tracking graph database for the disease, and selecting a "confirmed" classification when at least some of said patient data matches at least some of said clinical criteria specifying at least one symptom, and At least some of the laboratory standards used for diagnosis specify at least one of isolation, detection, recognition, or antibody response associated with the disease, and When at least one of a "possible," "probable," or "confirmed" classification is determined for the patient, the patient is added to the outbreak tracking graphical database for the disease.

22. The device according to claim 21, wherein The node processor is configured to add the patient to the epidemic tracking graph database by performing the following operations: 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; as well as The outbreak node is connected to the outbreak node via a "part of" link to indicate that the patient has become part of an outbreak for the disease.

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

24. The device according to claim 22, wherein: When sample data is available in the patient data, the instructions further cause the node processor to: 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 collected from the patient; creating a quarantine node linked to the sample node via a quarantine link, the quarantine node being associated with a quarantine parameter specifying a quarantine in a sample result associated with the collected sample; as well as A biological node is created that is linked to the quarantine node via the biological link, the biological node being associated with a biological parameter specifying at least one biological found in the quarantine routine.

25. The device according to claim 21, wherein The epidemiology link includes at least one of the following: "through air" link, "animal reservoir" link, "environmental reservoir" link, "food and drinking water" link, "insect bite" link, "animal-to-human contact" link, "contaminated object" link, "droplet transmission" link, or "human-to-human contact" link, and The known host is at least one of a patient, a clinician, a human, an animal, a vector or an object.

26. The device according to claim 21, wherein The known host has at least one of a "possible" classification for the disease, a "probable" classification for the disease, or a "confirmed" classification for the disease, so that the epidemiological link can be established with the patient.

27. The device according to claim 26, wherein: The known host is associated with a second host node, which is connected to a second episode node via a "case" link, and wherein, The second outbreak node is connected to the epidemic node of the epidemic tracking graph database via a "part" link.

28. The device according to claim 21, wherein The node processor is configured to determine an epidemiological link between the patient and the known host using at least one of social media data, demographic relationship data, geolocation data, clinician notes, or a treatment plan for the patient or the known host.

29. The device according to claim 21, wherein The "likely" classification is additionally selected when at least some of the patient data includes a clinician's judgment regarding the disease.

30. The device according to claim 21, wherein The instructions also cause the node processor to: comparing the number of host nodes or outbreak nodes added to the outbreak tracking graph database for the disease within a defined time period to a threshold, and When the number of the host nodes or the outbreak nodes exceeds the threshold, an alarm is generated indicating an outbreak of the disease.

31. The device according to claim 21, wherein The alert includes at least one text message or push notification transmitted to at least one clinician device.

32. The device according to claim 21, wherein Only episode nodes or host nodes associated with the "probable" or "confirmed" classification were compared.

33. A method for epidemic management, comprising: An epidemic tracking graph database for a specific disease is stored, which includes an epidemic node connected to a definition node via a "defined as" link, the definition node specifies disease parameters of the disease, the disease parameters include conditions for disease classification, the disease classification includes a "possible" classification for the disease and a "confirmed" classification for the disease; In a server, receiving patient data associated with a patient; By comparing the patient data with the disease parameters of the definition node, determining, via the server, whether the patient should be associated with the epidemic node associated with the disease, wherein selecting a "likely" classification when at least some of the patient data matches at least some of the clinical criteria specifying at least one symptom, and selecting a "confirmed" classification when at least some of the patient data matches at least some of the clinical criteria specifying at least one symptom, and at least some laboratory standards for diagnosis that specify at least one of isolation, detection, recognition, or antibody response associated with the disease; and When at least one of a "probable" or "confirmed" classification is determined for the patient, the patient is added to the epidemic tracking graphical database for the disease via the server.

34. The method of claim 33, wherein: The patient is added to the epidemic tracking graph database by the following operations: Creating a host node for the patient via the server; creating, via the server, 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; as well as Via the server, the outbreak node is connected to the outbreak node via a "part of" link to indicate that the patient has become part of the outbreak for the disease.

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

36. The method of claim 33, wherein: The disease classification further includes a "probable" classification for the disease, wherein the "probable" classification is selected when at least some of said patient data matches at least some of said clinical criteria specifying at least one symptom, and The patient has an epidemiological link to a known host of the outbreak tracking graph database for the disease, and Wherein, when the patient is determined to be classified as "probable", the patient is further added to the epidemic tracking graphic database for the disease.

37. The method of claim 36, wherein: The epidemiology link includes at least one of the following: "through air" link, "animal reservoir" link, "environmental reservoir" link, "food and drinking water" link, "insect bite" link, "animal-to-human contact" link, "contaminated object" link, "droplet transmission" link, or "human-to-human contact" link, and The known host is at least one of a patient, a clinician, a human, an animal, a vector or an object.

38. The method according to claim 37, wherein: The known host has at least one of a "possible" classification for the disease, a "probable" classification for the disease, or a "confirmed" classification for the disease, so that the epidemiological link can be established with the patient.

39. The method of claim 33, wherein: The "likely" classification is additionally selected when at least some of the patient data includes a clinician's judgment regarding the disease.

40. The method of claim 34, further comprising: Determining, via the server, that sample data in the patient data is available; creating, via the server, 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 collected from the patient; creating, via the server, a quarantine node linked to the sample node via a quarantine link, the quarantine node being associated with a quarantine parameter specifying a quarantine in a sample result associated with the collected sample; as well as Via the server, a biological node is created that is linked to the quarantine node via a biological link, the biological node being associated with a biological parameter specifying at least one biological found in a quarantine routine.

Images