JP2020149646A - Medical institution selection server and medical institution selection method - Google Patents

Abstract

To more accurately predict time up to starting treatment for a patient.SOLUTION: A medical institution selection server is configured to: hold a flow prediction model that predicts a flow which includes one or more processes to be executed on a patient from state information of the patient, and medical institution information that indicates a state of a resource for executing each process included in an executable flow for each medical institution; acquire the state information of the patient; predict flow to be executed on the patient from the acquired state information of the patient and the flow prediction model; acquire a state of a resource for executing each process included in the predicted flow in each medical institution with reference to the medical institution information; and select medical institution candidates to which the patient is transported based on the acquired states of the resources.SELECTED DRAWING: Figure 1

Description

The present invention relates to a medical institution selection server and a medical institution selection method.

As a background technique in this technical field, there is Japanese Patent Application Laid-Open No. 2011-48775 (Patent Document 1). In this publication, "In the emergency hospital selection system 1, the vehicle terminal 2 is mounted on the emergency vehicle, and the management server 3 acquires and displays the identification information of the hospital to be headed from the emergency site. The management server 3 is predetermined. It is installed in the general center that has jurisdiction over the area of the hospital, and when there is an inquiry about the hospital from the vehicle terminal 2, it inquires the hospital server 4 about the response time of each hospital (the time until it becomes possible to respond to emergency patients). , Select the most suitable hospital and notify the vehicle terminal 2 while considering the travel time obtained from the distance between the emergency site and each hospital. The hospital server 4 is installed for each hospital in the jurisdiction area. Then, when the management server 3 inquires about the response time by communicating with the management server 3, the current response time is calculated from the situation of the doctor, the operating room, etc. and notified. The management server 3 and each of them. The hospital server 4 is configured to be communicable via, for example, a network 5 such as WAN. ”(See summary).

Japanese Unexamined Patent Publication No. 2011-48775

The treatment required for the patient depends on the patient's condition before emergency transportation, and whether these treatments are possible depends on the medical institution. Further, even in a medical institution capable of these treatments, the time during which the treatment can be started for the patient varies depending on the situation of resources for performing the treatment. Therefore, one aspect of the present invention is to provide a medical institution that can more accurately predict the time until the start of treatment for a patient and, by extension, treat the patient earlier by considering the above-mentioned circumstances. The purpose is to be able to select.

In order to solve the above problems, one aspect of the present invention adopts the following configuration. A medical institution selection server that selects a medical institution that transports a patient, including a processor and a memory, and the memory provides a flow consisting of one or more processes executed for the patient, and the state information of the patient. Holds a flow prediction model predicted from the medical institution and medical institution information indicating the status of resources for executing each process included in the feasible flow for each medical institution, and the processor holds the state information of the patient. Is acquired, the flow executed for the patient is predicted based on the acquired state information of the patient and the flow prediction model, and the prediction at each medical institution is made with reference to the medical institution information. Acquire the status of resources for executing each process included in the flow, select the medical institution candidate to transport the patient based on the acquired resource status, and obtain the information of the selected medical institution candidate. A medical institution selection server that outputs.

According to one aspect of the present invention, it is possible to more accurately predict the time until the start of treatment for a patient, and thus it is possible to select a medical institution that can perform treatment for a patient earlier.

Issues, configurations and effects other than those described above will be clarified by the description of the following embodiments.

It is a block diagram which shows the configuration example of the hospital selection system in Example 1. FIG. This is an example of a correspondence table in the first embodiment. It is an example of the medical treatment flow table in Example 1. This is an example of the resource status table in the first embodiment. It is an example of the patient classification history table in Example 1. This is an example of the emergency transport history table in the first embodiment. This is an example of the acceptance inquiry required time history table in the first embodiment. It is a flowchart which shows an example of the hospital selection process in Example 1. FIG. This is an example of patient classification based on the patient classification prediction model in Example 1. It is an example of the treatment start time of each patient classification of each hospital in Example 1. This is an example of the probability that each hospital cannot handle the patient and the expected value of the treatment start time at each hospital in Example 1. It is a flowchart which shows an example of the prediction processing of the treatment start possible time of each patient classification in Example 1. FIG. It is a flowchart which shows an example of the calculation process of the treatment start possible time in Example 1. FIG. It is explanatory drawing which shows an example of the execution time of the process in Example 1. FIG. It is a flowchart which shows an example of the estimation process of the transport end time of a patient in Example 1. FIG. In the first embodiment, it is an example of an input screen displayed on the terminal. In the first embodiment, it is an example of an output screen displayed on the terminal. In the first embodiment, it is an example of an output screen displayed on the terminal.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In the present embodiment, in principle, the same components are designated by the same reference numerals, and the repeated description will be omitted. It should be noted that the present embodiment is merely an example for realizing the present invention and does not limit the technical scope of the present invention.

This embodiment describes a hospital selection system that selects a hospital to transport a patient in an emergency. The hospital is an example of a medical institution, and the patient may be transported to a medical institution other than the hospital. Further, in the present embodiment, an example of transporting a stroke patient will be described, but a patient with an injury or illness other than stroke is transported by appropriately changing the process of the medical care flow described later and the model for determining the patient classification. It is clear that it can also be applied to cases where Further, although the present embodiment describes an example of transporting a patient using an emergency vehicle, it is clear that the present embodiment can be applied not only to a vehicle but also to a case of transporting a patient using other transportation equipment such as a ship or an aircraft. Is.

FIG. 1 is a block diagram showing a configuration example of a hospital selection system. The hospital selection system includes, for example, a hospital selection server 100 and a terminal 200 connected by a network 300 such as the Internet. The hospital selection server 100 is composed of, for example, a computer having a CPU (Central Processing Unit) 101, a memory 102, an auxiliary storage device 103, and a communication device 104.

The CPU 101 includes a processor and executes a program stored in the memory 102. The memory 102 includes a ROM (Read Only Memory) which is a non-volatile storage element and a RAM (Random Access Memory) which is a volatile storage element. The ROM stores an invariant program (for example, a BIOS (Basic Input / Output System)) and the like. The RAM is a high-speed and volatile storage element such as a DRAM (Dynamic Random Access Memory), and temporarily stores a program executed by the CPU 101 and data used when the program is executed.

The auxiliary storage device 103 is, for example, a large-capacity and non-volatile storage device such as a magnetic storage device (HDD (Hard Disk Drive)) or a flash memory (SSD (Solid State Drive)), and is a program and a program executed by the CPU 101. Stores the data used when executing. That is, the program is read from the auxiliary storage device 103, loaded into the memory 102, and executed by the CPU 101.

The hospital selection server 100 may have an input interface 105 and an output interface 108. The input interface 105 is an interface to which an input device such as a keyboard 106 or a mouse 107 is connected and receives input from an operator. The output interface 108 is an interface to which a display device 109, a printer, or other display device is connected, and outputs a program execution result in a format that can be visually recognized by an operator.

The communication device 104 is a network interface device that controls communication with other devices according to a predetermined protocol. Further, the communication device 104 includes a serial interface such as USB.

The program executed by the CPU 101 is provided to the hospital selection server 100 via removable media (CD-ROM, flash memory, etc.) or network 300, and is stored in the non-volatile auxiliary storage device 103, which is a non-temporary storage medium. .. Therefore, the hospital selection server 100 may have an interface for reading data from removable media.

The hospital selection server 100 is a computer system composed of physically one computer or a plurality of computers logically or physically configured, and operates in separate threads on the same computer. It may operate on a virtual computer built on a plurality of physical computer resources. The same applies to the terminal 200.

The CPU 101 includes, for example, a patient classification prediction unit 111, a treatment startable time prediction unit 112, a prediction result integrated processing unit 113, a hospital candidate selection unit 114, and a transportation time estimation unit 115. The patient classification prediction unit 111 predicts the patient classification to which the patient corresponds by using, for example, the input patient information and the patient classification prediction model 121 described later. The treatment startable time prediction unit 112 predicts the time when the patient's treatment can be started.

The prediction result integration processing unit 113 integrates prediction results for a plurality of patient classifications when there is a possibility that the patient falls under a plurality of applicable patient classifications. The hospital candidate selection unit 114 selects hospital candidates based on, for example, the time when treatment can be started, the probability of being able to handle patient classification, and the like. The transport time estimation unit 115 estimates the time until the patient is transported to the hospital by the emergency vehicle.

For example, the CPU 101 functions as a patient classification prediction unit 111 by operating according to the patient classification prediction program loaded in the memory 102, and starts treatment by operating according to the treatment startable time prediction program loaded in the memory 102. It functions as a possible time prediction unit 112. The relationship between the program and the functional unit is the same for the other functional units included in the CPU 101. Further, the relationship between the program and the functional unit is the same for the functional unit described later included in the CPU 201 of the terminal 200.

In addition, a part or all of the functions by the functional part included in the CPU 101 and the CPU 201 may be realized by hardware such as ASIC (Application Specific Integrated Circuit) and FPGA (Field-Programmable Gate Array).

The auxiliary storage device 103 includes, for example, a patient classification prediction model 121, a response availability table 122, a medical care flow table 123, a resource status table 124, an emergency vehicle movement time prediction model 125, a patient classification history table 126, an emergency transportation history table 127, and The acceptance inquiry required time history table 128 is retained. A part or all of the information stored in the auxiliary storage device 103 may be stored in the memory 102, or may be stored in the database connected to the hospital selection server 100.

The patient classification prediction model 121 is a model for predicting patient classification from patient condition information (for example, patient's symptom, medical history, hearing information by paramedics, etc.). The response availability table 122 shows the response availability of patients of each patient classification in each hospital, and if it is possible, the medical treatment flow to be executed for the patients. The medical care flow consists of one or more processes. Hereinafter, the medical treatment flow is also simply referred to as a flow.

The medical care flow table 123 holds information on the processes included in the flow. The resource status table 124 shows the status of the resources required to execute the process of each flow. The emergency vehicle movement time prediction model 125 is a model for predicting the movement time of an emergency vehicle from, for example, a time zone, a day of the week, and a movement time based on route information and / or congestion information. The patient classification history table 126 shows, for example, patient status information and patient classification history, and is used to generate a patient classification prediction model 121.

The emergency transport history table 127 shows, for example, the history of the travel time based on the time zone, the day of the week, the route information and / or the traffic jam information, and the travel time of the emergency vehicle, and is used to generate the emergency vehicle travel time prediction model 125. Used. The acceptance inquiry required time history table 128 shows the history of the time required for the acceptance inquiry to each hospital.

In this embodiment, the information used by the hospital selection system may be represented by any data structure without depending on the data structure. In this embodiment, the information is expressed in a table format, but for example, a data structure appropriately selected from a list, a database, or a queue can store the information.

The terminal 200 is composed of, for example, a computer having a CPU 201, a memory 202, an auxiliary storage device 203, a communication device 204, an input device 205, a display device 206, and a GPS (Global Positioning System) receiving device 207. The terminal 200 is, for example, a tablet terminal carried by an ambulance crew, a PC (Personal Computer) installed in an ambulance, or the like.

The description of the CPU 201, the memory 202, the auxiliary storage device 203, and the communication device 204 as hardware is the same as the description of the CPU 101, the memory 102, the auxiliary storage device 103, and the communication device 104, and is therefore omitted.

The CPU 201 includes, for example, a patient status information input transmission unit 211 and a hospital candidate display unit 212. The patient status information input transmission unit 211 receives the input of the patient status information and transmits it to the hospital selection server 100. The hospital candidate display unit 212 displays the hospital candidate information received from the hospital selection server 100 on the display device 206.

The input device 205 is, for example, a keyboard, a mouse, or the like. The display device 206 is, for example, a display or the like. For example, the input device 205 and the display device 206 may be integrated like a touch panel. The terminal 200 may also have an input interface and an output interface, and may be connected to an external input device and a display device, as in the hospital selection server 100. The GPS receiving device 207 receives a signal from a GPS satellite and acquires the position information of the terminal 200 based on the received signal.

FIG. 2 is an example of the availability table 122. The response availability table 122 includes, for example, an ID column 1221, a hospital column 1222, a patient classification column 1223, a response availability column 1224, a medical care flow ID column 1225, and a position column 1226. The ID field 1221 holds an ID that identifies a record in the availability table 122. The hospital column 1222 retains the name of the hospital.

The patient classification column 1223 stores the patient classification. The response availability column 1224 holds a value indicating whether or not the hospital can respond to the treatment of patients in the patient classification. The medical care flow ID column 1225 holds the medical care flow ID when the value of the correspondence column 1224 is "possible", and holds, for example, the null value when the value of the correspondence availability column 1224 is "impossible". ..

Even if the patient classification is the same, different medical care flow IDs may be stored for the same patient classification because resources and the like may differ depending on the hospital. Also, there may be multiple records for the same patient classification in the same hospital, as multiple types of flows may be feasible for the same patient classification in the same hospital. When the availability and the medical care flow ID are unknown, a value of "unknown" or a null value or the like is stored in the correspondence availability column 1224 and the medical care flow ID column 1225. The location column 1226 holds the location information of the hospital. The position information is represented by, for example, the coordinate values of latitude and longitude.

FIG. 3 is an example of the medical care flow table 123. The example of FIG. 3 shows a flow in which the medical treatment flow ID is “3”. The medical care flow table 123 includes, for example, a process ID column 1231, a process name column 1232, a start condition column 1233, and an execution time column 1234. The process ID column 1231 holds an ID that identifies the process.

The process name column 1232 holds the name of the process. In the example of FIG. 3, "t-PA treatment" and "catheter treatment" are therapeutic acts, and the other flow is not the therapeutic act itself but a preparatory act such as an examination for performing the therapeutic act. For example, the medical treatment flow table 123 may have a flag for distinguishing between a treatment action and a preparation action, or another data indicating a flow corresponding to the treatment action may be stored in the auxiliary storage device 103. Good.

The start condition column 1233 stores a condition for starting the corresponding process. For example, in FIG. 3, the "blood test" can be started at any time after the patient has been transported, whereas the "CT" is a process with process IDs 1-4 (ie, "blood test", " It cannot be started until all of "medical history confirmation", "ECG testing", and "echo") are completed.

It should be noted that the start conditions of the two processes need to be defined so as not to include the termination of each other's processes. Specifically, for example, when the start condition of the process having the process ID "1" is "2 ends" and the start condition of the process having the process ID "2" is "1 ends", any of the above. This is because the process cannot be started either. Further, as an example of the start condition of another process, there is an inability to execute at the same time as a predetermined process.

The execution time column 1234 holds the time taken from the start to the end of execution of the process. In the example of FIG. 3, since the medical care flow table 123 is prepared for each medical care flow ID, for example, an index for searching each medical care flow table 123 may be stored in the auxiliary storage device 103. Further, the flow information of all the medical care flow IDs may be stored in one medical care flow table 123. In this case, for example, the medical care flow table 123 may further include a medical care flow ID column.

FIG. 4 is an example of the resource status table 124. The example of FIG. 4 shows the resource status in "B private hospital". The resource status table 124 includes, for example, a process ID column 1241 and a available start time column 1242. The process ID column 1241 holds the process ID of the process included in the flow that can be executed by "B private hospital".

The available start time column 1242 stores information indicating a time when the use of the resource used for the process can be started. Note that "0 minutes later" stored in the available start time column 1242 indicates that the resource for executing the flow is currently available. The resource may include not only physical resources such as examination equipment, treatment equipment, and surgical equipment, but also human resources such as doctors, examination technicians, and nurses.

For example, the hospital selection server 100 is connected to the server of each hospital, the server of each hospital periodically or in real time transmits the resource status to the hospital selection server 100, and the hospital selection server 100 follows the received resource status. Update the resource status table 124.

FIG. 5 is an example of the patient classification history table 126. The patient classification history table 126 is used to generate a patient classification prediction model 121 that predicts patient classification from the patient state. The patient classification history table 126 includes, for example, a patient ID column 1261, an explanatory variable column 1262, and an objective variable column 1263.

The patient ID column 1261 stores, for example, an ID that identifies the patient. The explanatory variable column 1262 holds the value of the explanatory variable of the patient. In the example of FIG. 5, variables indicating the patient's condition such as dizziness, hemiplegia, normal conversation, anticoagulant taking, and history of diabetes are explanatory variables. Has been adopted as.

The objective variable column 1263 holds the value of the objective variable of the patient. In the example of FIG. 5, patient classification is adopted as the objective variable. That is, for example, when the values of the explanatory variable and the objective variable are unknown, for example, the value "unknown", the null value, or the like may be stored in the explanatory variable column 1262. This also applies to the emergency transport history table 127, which will be described later.

The patient classification prediction model 121 may be a model given in advance. For example, the patient classification prediction unit 111 machine-learns (for example, deep) the values of the explanatory variables and the objective variables of the patient classification history table 126. It may be a model generated by learning (learning, logistic regression, etc.).

FIG. 6 is an example of the emergency transport history table 127. The emergency transport history table 127 is used to generate an emergency vehicle movement time prediction model 125 that predicts the movement time of an emergency vehicle from time information and the like during emergency transport. The emergency transport history table 127 includes, for example, an ID column 1271, an explanatory variable column 1272, and an objective variable column 1273. The ID column 1271 holds a record in the emergency transport history table 127, that is, an ID that identifies the history of emergency transport.

The explanatory variable column 1272 holds the value of the explanatory variable in the history corresponding to the ID. In the example of FIG. 6, the day of the week and the time zone in which the emergency transportation was performed and the travel time based on the route calculation and / or the traffic jam are adopted as explanatory variables. The travel time based on route calculation and / or traffic congestion is, for example, the travel time for a general vehicle predicted by a car navigation system or the like, and is a characteristic of an emergency vehicle (for example, it can pass through a red light intersection). Is an unconsidered value.

The objective variable column 1273 holds the value of the objective variable in the history corresponding to the ID. In the example of FIG. 6, the moving time of the emergency vehicle is adopted as the objective variable. The emergency vehicle travel time is the actual travel time of the emergency vehicle in the history.

The emergency vehicle movement time prediction model 125 may be a model given in advance. For example, the transport time estimation unit 115 machine-learns the values of the explanatory variables and the objective variables of the emergency transport history table 127 ( For example, it may be a model generated by deep learning, logistic regression, etc.).

FIG. 7 is an example of the acceptance inquiry required time history table 128. The acceptance inquiry required time history table 128 includes, for example, a date and time column 1281, a hospital column 1282, and an inquiry required time column 1283. The date and time field 1281 holds the date and time when the acceptance inquiry was made in the past. The hospital column 1282 stores the name of the hospital to which the acceptance inquiry was made in the past. The inquiry required time column 1283 holds the required time required for the acceptance inquiry.

For hospitals whose resource usage status is recorded in the resource status table 124, it is not necessary to make an acceptance inquiry because the resource usage status is known. Therefore, since it is not necessary to calculate the acceptance inquiry required time described later for such a hospital, the acceptance inquiry required time history table 128 does not have to hold the acceptance inquiry required time history of such a hospital.

FIG. 8 is a flowchart showing an example of the hospital selection process. First, the patient status information input transmission unit 211 of the terminal 200 receives the input of the patient status information input by the user of the terminal 200, and the input status information and the current state of the terminal 200 acquired by the GPS receiving device 207. The location information and the location information are transmitted to the hospital selection server 100 (S801). The input state information includes the value of the explanatory variable of the patient classification prediction model 121. Further, the current position information of the terminal 200 is information indicating the position of the patient.

The patient classification prediction unit 111 of the hospital selection server 100 inputs the value of the explanatory variable included in the received state information into the patient classification prediction model 121, thereby performing the patient classification which is the value of the objective variable of the patient classification prediction model 121. Acquire (S802).

The treatment startable time prediction unit 112 predicts the treatment startable time of each patient classification acquired in step S802 for each hospital by using the response availability table 122, the medical treatment flow table 123, and the resource status table 124 (S803). ). Details of step S803 will be described later.

The prediction result integrated processing unit 113 cannot handle the patient at each hospital because of the probability of patient classification acquired in step S802 and the value in the correspondence column 1224 of each patient classification in the correspondence table 122. The probability is calculated (step S804). Specifically, the probability that a hospital cannot handle the patient is calculated by, for example, the sum of the probabilities of patient classification for which there is no record for the hospital in the availability table 122.

Further, in step S804, the prediction result integrated processing unit 113 determines the treatment startable time at each hospital from the probability of patient classification obtained in step S802 and the treatment startable time of each patient classification predicted in step S803. Calculate the expected value of. It should be noted that the prediction result integrated processing unit 113 does not need to calculate the expected value for the hospital where the probability that the patient cannot be dealt with is 100%.

Subsequently, the hospital candidate selection unit 114 selects, for example, a hospital whose unresponsive probability calculated in step S804 is equal to or less than a predetermined value, and selects a hospital in order of earliest expected value of the treatment startable time calculated in step S804. Information including the probability of unresponsiveness and the expected value of the treatment startable time is sorted, and the sorted information is displayed on the display device 109 (S805).

In step S805, the hospital candidate selection unit 114 may select a predetermined number of hospitals in ascending order of the probability of non-correspondence calculated in step S804, or hospitals having a lower probability of non-correspondence than the average value. You may choose.

FIG. 9 is an example of the result of patient classification by the patient classification prediction model 121 obtained in step S802. From the patient classification prediction model 121, the probabilities corresponding to each patient classification can be obtained. The patient classification prediction model 121 may be a model in which the value of the objective variable is determined and returned as one. In addition, the patient classification prediction unit 111 may determine one patient classification based on the obtained probability. Specifically, for example, the patient classification prediction unit 111 may select the patient classification with the highest probability (when there are a plurality of patient classifications with the highest probability, the patient classification is randomly selected from these patient classifications). ..

FIG. 10 is an example of the treatment start time of each patient classification obtained in step S803 at each hospital. Since "A Municipal Hospital" cannot handle the patient classifications "(A)" and "(B)", the value "Impossible" is stored instead of the treatment start time.

FIG. 11 is an example of the probability that each hospital cannot handle the patient and the expected value of the treatment start time at each hospital, which are obtained in step S804. In addition, hospitals that cannot handle the patient may be excluded from the output at the time of step S804.

FIG. 12 is a flowchart showing an example of the prediction processing of the treatment startable time of each patient classification in step S803. The treatment startable time prediction unit 112 sets N = 1 in the counter (S1201). The treatment startable time prediction unit 112 reads the record in the Nth row of the response availability table 122 (S1202).

The treatment startable time prediction unit 112 determines whether or not the value in the correspondence column 1224 of the record is “correspondence” (S1203). When the treatment startable time prediction unit 112 determines that the value in the correspondence column 1224 of the record is "correspondence" (S1203: Yes), the treatment start possible time is calculated for the hospital and patient classification of the record. (S1204), the transition to step S1206. Details of step S1204 will be described later.

When the treatment startable time prediction unit 112 determines that the value in the correspondence column 1224 of the record is "not available" (S1203: No), the hospital indicated by the record does not support the patient classification indicated by the record. Information indicating that it is “impossible” is output (S1205), and the process proceeds to step S1206.

For example, a record whose availability is unknown, or a record whose treatment start time cannot be calculated because the flow ID is unknown or the resource status corresponding to the flow ID is unknown even if it is available. On the other hand, only the transport time estimation process in step S1302, which will be described later, is performed.

Subsequently, the treatment startable time prediction unit 112 determines whether or not all the records in the correspondence availability table 122 have been read (S1206). When it is determined that all the records in the response availability table 122 have been read (S1206: Yes), the treatment startable time prediction unit 112 ends the process in step S803.

When the treatment startable time prediction unit 112 determines that there is an unread record in the response availability table 122 (S1206: No), the value of the counter N is incremented (S1207), and the process returns to the process of step S1202.

In the above-mentioned example, the patient classification is predicted from the patient's condition using the patient classification prediction model 121, the flow ID corresponding to the predicted patient classification is acquired from the correspondence availability table 122, and the flow corresponding to the flow ID is obtained. A series of algorithms that acquire each process from the clinical flow table 123 may be defined as one flow prediction model. Further, the auxiliary storage device 103 may have a model for directly estimating the flow from the patient's state, and in this case, the flow may be acquired by the model.

FIG. 13 is a flowchart showing an example of the treatment startable time calculation process in step S1204. The treatment startable time prediction unit 112 reads the medical care flow table 123 and the resource status table 124 corresponding to the medical care flow ID indicated by the record read in step S1202 (that is, corresponding to the hospital and patient classification indicated by the record). S1301). The transport time estimation unit 115 estimates the end time of transport of the patient to the hospital (S1302). Details of step S1302 will be described later.

The treatment startable time prediction unit 112 selects one of the unselected processes in the read medical care flow table 123 that can calculate the time satisfying the start condition (the selected process is also referred to as process X) (S1303). ).

For example, in the example of FIG. 3, the process having the process ID "5" cannot be executed until the process having the process IDs "1" to "4" is completed, so that the process IDs are "1" to "4". The process cannot be selected in step S1303 until the end time of the process is calculated. In the example of FIG. 3, in the first step S1303, the selectable process is a process having a process ID of "1" to "4" whose start condition does not include the termination of another process. In this example, in the first step S1303, the treatment startable time prediction unit 112 randomly selects one process from, for example, the processes having the process IDs “1” to “4”.

The treatment startable time prediction unit 112 (1) a time satisfying the start condition of the process X in the medical care flow table 123 (for example, when the end of one or more predetermined processes is the start condition, the one or more predetermined time is specified. The latest time among the process end times) or (2) the process X resource availability start time in the resource status table 124 is determined as the process X start time (S1304).

The treatment startable time prediction unit 112 calculates the time obtained by adding the execution time of the process X in the medical care flow table 123 read in step S1301 to the start time calculated in step S1304 as the end time of the process X (S1305). .. The treatment startable time prediction unit 112 determines whether or not all the flows of the medical treatment flow table 123 read in step S1301 have been selected (S1306).

When the treatment startable time prediction unit 112 determines that there is an unselected flow (S1306: No), the process returns to step S1303. When the treatment startable time prediction unit 112 determines that all the flows have been selected (S1306: Yes), the record patient classification of the flow indicated by the record read in step S1202 (that is, the record patient classification in the hospital indicated by the record). ) The treatment start time is calculated (S1307).

In step S1307, the treatment startable time prediction unit 112 specifically indicates the earliest time among the start times of a specific treatment action that is not a preparatory action for treatment such as an examination (the example of FIG. 3 (that is, a stroke patient). In (Example), the start time of t-PA treatment or the earlier time of the start time of catheter treatment) is calculated as the treatment startable time.

By the above-mentioned processing, the hospital selection server 100 of this embodiment can select a hospital that can correspond to the predicted patient classification, and can more accurately calculate the treatment startable time in consideration of the resource status of the flow. As a result, it is possible to more accurately select a hospital that can start treatment earlier.

For example, if the emergency vehicle is a doctor car or the like, there may be a case where a part or all of the flow process can be executed in the emergency vehicle while the patient is being transported. For example, it is assumed that the auxiliary storage device 103 holds the process information of the emergency vehicle, which indicates the process that can be executed in the emergency vehicle, the start condition of the process, and the execution time of the process. For example, in steps S1303 to S1305, when the treatment startable time prediction unit 112 refers to the process information of the emergency vehicle and determines that there is a process that can be completed in the emergency vehicle by the transportation end time, the process is concerned. The process may be preferentially executed in the emergency vehicle, and the start time and end time of the process may be calculated.

FIG. 14 is an explanatory diagram showing an example of the process execution time calculated in steps S1304 and S1305. In all cases (1) to (3), the end time of transportation to the hospital is 10 minutes later.

First, the case (1) will be described. In case (1), the value of the progress from the onset, which is the explanatory variable, is "less than 4.5 hours", and the value of the presence or absence of the medical history, which is the explanatory variable, is "none", from the patient classification prediction model 121. This is an example in which the patient classification is determined in (a).

First, the flow of patient classification (a) in the hospital in case (1) and the resource status of the flow will be described. In the flow of patient classification (a) of the hospital, "blood test", "medical history confirmation", "electrocardiogram", "echo", "CT", "contrast CT", "t-PA treatment", and "catheter treatment" Is executed.

The only start condition for "blood test", "medical history confirmation", "electrocardiogram", and "echo" is "end of transport". In addition, the start condition of "CT" is that "blood test", "medical history confirmation", "electrocardiogram", and "echo" have been completed. The start condition of "catheter treatment" is that "contrast-enhanced CT" has been completed.

The condition for starting "t-PA treatment" is that "CT" has been completed. The start condition of "catheter treatment" is that "contrast-enhanced CT" has been completed. Further, the available start time of the resources of "ECG" and "Echo" is 15 minutes later, and the available start time of the resource status of other flows is earlier than the time when the use start condition is satisfied.

As described with reference to FIG. 13, the treatment startable time prediction unit 112 executes the process for starting the treatment action earlier by determining the execution time of each process from the above-mentioned flow start condition and resource status. The order can be determined.

Case (2) is different from case (1) in that the patient classification is (a) as in case (1), but the available start time of the resource of "CT" is 30 minutes later. Twenty minutes later, although it is satisfied that the "blood test", "medical history confirmation", "electrocardiogram", and "echo", which are the start conditions of "CT", have been completed, at the time of 20 minutes, " "CT" resources are not yet available. In addition, since the start conditions of "t-PA treatment", "contrast-enhanced CT", and "catheter treatment" cannot be satisfied at the stage where "CT" is not completed, from 20 minutes to 30 minutes later. During that time, there is a time when no process is executed.

In case (3), the value of the course from the onset, which is the explanatory variable, is "4.5 hours or more", and the value of the presence or absence of kidney disease, which is the explanatory variable, is "presence", from the patient classification prediction model 121. This is an example in which the patient classification is determined in (a). Since "CT" cannot be performed on patients suffering from kidney disease, the flow of case (3) is to perform "t-PA treatment" and "contrast-enhanced CT" starting from "CT". However, it differs from the flow of case (1) in that "MRI" is performed and then "catheter" treatment is performed.

The start condition of "MRI" is that "blood test", "medical history confirmation", "electrocardiogram", and "echo" have been completed in the same manner as the start condition of "CT". The condition for starting "catheter treatment" is that "MRI" has been completed.

FIG. 15 is a flowchart showing an example of the estimation process of the patient transport end time in step S1302 (S1302). The transport time estimation unit 115 acquires the position information of the hospital and the current position information of the terminal 200 acquired in step S801 from the correspondence availability table 122 (S1501).

The transport time estimation unit 115 acquires the travel time by a general vehicle (not an emergency vehicle) from the current position to the hospital based on route calculation and / or congestion information using the hospital position information and the current position information. (S1502).

In the process of step S1501, for example, the transport time estimation unit 115 transmits the hospital position information and the current position information to the car navigation server outside the hospital selection server 100, and the car navigation server considers the congestion prediction. It is executed by calculating the travel time by a general vehicle based on the route information and transmitting it to the hospital selection server 100. When transportation equipment such as ships and airplanes is used instead of emergency vehicles, congestion prediction does not have to be taken into consideration.

When the hospital selection server 100 has a model for car navigation for general vehicles, for example, the transportation time estimation unit 115 acquires congestion prediction information from the outside, and the hospital position information and the current position information. And the congestion prediction information may be applied to the model to execute the process of step S1501.

Subsequently, the transport time estimation unit 115 inputs the current day of the week, the time zone, and the travel time calculated in step S1502, which are explanatory variables, into the emergency vehicle travel time prediction model 125, and is an objective variable. The transportation end time is calculated by calculating the moving time of the vehicle and adding the moving time of the emergency vehicle to the current time (S1503).

By the processing of FIG. 15, it is possible to more accurately calculate the travel time of an emergency vehicle having different characteristics and constraint conditions from that of a general vehicle. This makes it possible to more accurately select hospitals with short transportation times.

In addition, it is not possible to calculate the treatment start time due to reasons such as the hospital where the availability is unknown in the response availability table 122, or the flow ID is unknown or the resource status corresponding to the flow ID is unknown even if the response is possible. It is conceivable that emergency personnel will make an acceptance inquiry to inquire about the acceptance of patients and the time when treatment can be started.

Therefore, in step S1503, the transportation time estimation unit 115 may consider the time required for acceptance inquiry when calculating the transportation end time to such a hospital. Specifically, for example, the transport time estimation unit 115 uses other statistics such as the average value (maximum value, minimum value, or median value) of the time required for acceptance inquiry to the hospital in the acceptance inquiry time history table 128. The transport end time may be calculated by adding the travel time obtained from the emergency vehicle travel time prediction model 125 to the current time.

If the hospital selection server 100 and the terminal 200 do not perform the hospital resource reservation processing described later, the hospital makes a reservation (acceptance inquiry) to the hospital by telephone or the like, so that the transportation end time for all hospitals is calculated. In, the time required for acceptance inquiry may be taken into consideration.

FIG. 16 is an example of an input screen displayed on the terminal 200. The input screen 1600 is a screen for inputting the patient state information (value of the explanatory variable input to the patient classification prediction model 121) in step S801. The input screen 1600 includes, for example, an explanatory variable input area 1601, a determination execution button 1602, and an objective variable display area 1603.

The explanatory variable input area 1601 is an area for inputting the value of the explanatory variable for inputting to the patient classification prediction model 121. In the example of FIG. 16, the user of the terminal 200 can input the explanatory variable by selecting the value of the explanatory variable displayed in the explanatory variable input area 1601. In the example of FIG. 16, the selected value of the explanatory variable is displayed in white characters.

When the determination execution button 1602 is selected while the explanatory variable is input in the explanatory variable input area 1601, for example, the patient classification predicted by the hospital selection server 100 using the patient classification prediction model 121 (for example, the most applicable probability). Information on the patient classification) and the flow to be executed for the patient is displayed in the objective variable display area 1603. In the objective variable display area 1603, for example, as in the information shown in FIG. 9, a plurality of patient classifications and probabilities corresponding to each of the plurality of patient classifications may be displayed.

The input screen 1600 may include a button for displaying the output screen of FIG. 17, which will be described later, after the determination execution button 1602 is selected and the determination is executed. Further, the input screen 1600 may not include the objective variable display area 1603, and the output screen of FIG. 17 may be automatically displayed after the determination execution button 1602 is selected and the determination is executed.

FIG. 17 is an example of an output screen displayed on the terminal 200. The output screen 1700 is displayed on the display device 206 by, for example, the hospital candidate display unit 212. The output screen 1700 includes, for example, an objective variable display area 1701 and a map information display area 1702. The objective variable display area 1701 displays information on the patient classification predicted using the patient classification prediction model 121 and the flow scheduled to be executed for the patient, as in the objective variable display area 1603, for example.

The map information display area 1702 displays, for example, the location information of the hospital selected as a candidate in step S805 and the current location information of the terminal 200. The map information display area 1702 includes the hospital information display area 1703. In the hospital information display area 1703, for example, the treatment start time when the patient is transported to the candidate hospital, which is calculated in step S803, is displayed.

For hospitals such as Hospital D where the treatment start time could not be calculated, for example, the time obtained by adding the time predetermined for each patient classification to the transport end time is displayed as the treatment start time. Alternatively, the transport end time may be displayed instead of the treatment start time, or the predicted reception inquiry time may be displayed.

Further, the hospital information display area 1703 includes, for example, a status display button 1704 and a transport reservation button 1705. When the status display button 1704 is selected, for example, the screen transitions to an output screen for displaying the resource status of FIG. 18 described later. The status display button 1704 is not displayed for hospitals such as Hospital D whose resource status is unknown.

When the transport reservation button 1705 is selected, for example, the available start time of the resource status table 124 of the hospital is updated based on the start time and the end time of the resource corresponding to the flow process of the hospital. Specifically, for example, the end time is updated as the available start time. Further, the hospital selection server 100 may transmit the start time and the end time of the resource corresponding to the flow process of the hospital to the server of the hospital. In this case, the server of the hospital transmits the resource at the hospital. Make a reservation until the end time.

In addition, for example, the estimated time of arrival may change due to an accident or the like while the hospital is determined and the patient is being transported. In such a case, the hospital selection server 100 receives, for example, the input of the changed arrival time or receives it from the terminal 200. The hospital selection server 100 may update the resource reservation time by recalculating the start time and end time of each flow based on the changed arrival time. Further, when the difference between the actual arrival time and the estimated arrival time is equal to or greater than a predetermined value, the resource reservation time may be updated in the same manner.

By executing these reservation processes, the resource status table 124 can be updated in real time, and by extension, the estimation of the treatment start time that is executed after that can be performed more accurately.

For hospitals such as Hospital D, where availability is unknown or resource status is unknown, the reception inquiry button 1706 may be displayed instead of the transport reservation button 1705. When the reception inquiry button 1706 is selected, for example, a call to the hospital is started, or patient status information or patient classification is transmitted to the hospital. In addition, when the reception to the hospital is completed by the reception inquiry even though the correspondence is unknown, for example, the value of the correspondence of the patient classification of the hospital in the correspondence table 122 is changed to "Yes". May be good.

FIG. 18 is an example of an output screen displayed on the terminal 200. The output screen 1800 is displayed on the display device 206 by, for example, the hospital candidate display unit 212. For example, when the above-mentioned status display button 1704 is selected, the output screen 1700 transitions to the output screen 1800, or the output screen 1800 pops up.

The output screen 1800 displays the resource status of each process of the selected flow of the hospital corresponding to the status display button 1704. FIG. 18 is an example when the status display button 1704 corresponding to Hospital A is selected. In the example of FIG. 18, hospital A has three sets of resources (patient slots 1-3) to execute the selected flow.

For example, "finished" indicates that the resource has been used, but there is a reserved resource in the set to which the resource belongs. "Empty" indicates that the resource is free, that is, it can be reserved immediately. "Not" indicates that the resource is unavailable due to a failure or the like, or that the resource is not subject to use in the flow. In addition, the blank indicates that the resource is reserved. Further, for example, "elapsed time" indicates the elapsed time from the start of use of the resource of the set.

The present invention is not limited to the above-described examples, and includes various modifications. For example, the above-described embodiment has been described in detail in order to explain the present invention in an easy-to-understand manner, and is not necessarily limited to those having all the described configurations. It is also possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Further, it is possible to add / delete / replace a part of the configuration of each embodiment with another configuration.

Further, each of the above configurations, functions, processing units, processing means and the like may be realized by hardware by designing a part or all of them by, for example, an integrated circuit. Further, each of the above configurations, functions, and the like may be realized by software by the processor interpreting and executing a program that realizes each function. Information such as programs, tables, and files that realize each function can be stored in a memory, a hard disk, a recording device such as an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD.

In addition, the control lines and information lines indicate those that are considered necessary for explanation, and do not necessarily indicate all the control lines and information lines in the product. In practice, it can be considered that almost all configurations are interconnected.

100 hospital selection server, 101 CPU, 102 memory, 104 communication device, 103 auxiliary storage device, 112 treatment startable time prediction unit, 114 hospital candidate selection unit, 115 transportation time estimation unit, 121 patient classification prediction model, 122 compatibility table , 123 Medical flow table, 124 Resource status table, 125 Emergency vehicle movement prediction model, 128 Acceptance inquiry time history table, 200 terminals, 201 CPU, 202 memory, 203 auxiliary storage device, 206 display device, 211 Patient status information input unit , 212 Hospital candidate display

Claims (12)

It is a medical institution selection server that selects the medical institution that transports patients.
Equipped with a processor and memory
The memory is
A flow prediction model that predicts a flow consisting of one or more processes executed for the patient from the patient's state information,
Holds medical institution information, which shows the status of resources for executing each process included in the viable flow, for each medical institution,
The processor
Obtain the patient's condition information and
Based on the acquired patient condition information and the flow prediction model, the flow executed for the patient is predicted, and the flow is predicted.
With reference to the medical institution information, the status of resources for executing each process included in the predicted flow at each medical institution is acquired.
Based on the status of the acquired resources, a medical institution candidate to transport the patient is selected.
A medical institution selection server that outputs information on the selected medical institution candidates. The medical institution selection server according to claim 1.
The memory holds flow information indicating the start condition and execution time of each process included in the flow indicated by the flow prediction model.
The status of the resource indicated by the medical institution information indicates a time when the resource can be used.
The processor
With reference to the flow information, the start condition and execution time of each process included in the predicted flow are acquired.
With reference to the medical institution information, the available time of resource availability for executing each process included in the predicted flow is acquired.
Based on the acquired start condition, the acquired execution time, and the acquired available start time, the start time of each process included in the predicted flow is calculated.
A medical institution selection server that selects the medical institution candidate based on the calculated start time. The medical institution selection server according to claim 2.
The processor
For each process included in the predicted flow, the later time of the time when the process satisfies the start condition or the available time of resource use for executing the process is calculated as the start time of the process. Medical institution selection server. The medical institution selection server according to claim 2.
The one or more processes include therapeutic actions.
A medical institution selection server that selects the medical institution candidate based on the treatment startable time, which is the earliest of the calculated start times of the process that is the treatment action in each of the predicted flows. The medical institution selection server according to claim 4.
The processor is a medical institution selection server that includes the treatment start time of each of the medical institution candidates in the information of the selected medical institution candidates and outputs the information. The medical institution selection server according to claim 2.
The memory is
A travel time prediction model that predicts the travel time by emergency transportation equipment from the estimated travel time based on the route,
The location information of the emergency transportation equipment and
Holds the location information of the medical institution and
The processor
The estimated travel time based on the position information of the emergency transportation device, the position information of the medical institution, and the route from the emergency transportation device to the medical institution indicated by the above is acquired.
Based on the acquired estimated travel time and the travel time prediction model, the transportation end time at which the emergency transportation device arrives at the medical institution is calculated.
A medical institution selection server that calculates the start time of each process included in the predicted flow based on the transport end time. The medical institution selection server according to claim 6.
The memory is
Holds acceptance inquiry required time history information showing the history of acceptance inquiry required time for each medical institution,
The processor
A medical institution selection server that calculates the transportation end time based on a predetermined statistic of the time required for acceptance inquiry to each medical institution. The medical institution selection server according to claim 2.
The processor
Obtain information indicating the destination medical institution that transports the patient determined from the medical institution candidates,
A medical institution selection server that updates the status of resources of the destination medical institution in the medical institution information based on the start time of each process included in the flow scheduled to be executed in the destination medical institution. The medical institution selection server according to claim 1.
The flow prediction model is
A patient classification prediction model that predicts the patient classification of the patient from the patient status information,
Includes correspondence availability information indicating for each medical institution the availability of the patient classification and the flow executed for the patients in the patient classification that can be handled.
The processor
Based on the acquired patient condition information and the patient classification prediction model, the patient classification of the patient is predicted.
A medical institution selection server that identifies a medical institution that can respond to the predicted patient classification with reference to the response availability information, and predicts the flow executed for the patient at the medical institution. The medical institution selection server according to claim 9.
The memory holds flow information indicating the start condition and execution time of each process included in the flow indicated by the flow prediction model.
The status of the resource indicated by the medical institution information indicates a time when the resource can be used.
The one or more processes include therapeutic actions.
The patient classification prediction model is a model that predicts the probability that the patient falls under each patient classification from the state information of the patient.
The processor
Based on the acquired patient condition information and the patient classification prediction model, the probability that the patient falls under each patient classification is predicted.
Based on the predicted probability and the availability information, the probability that each flow is executed for the patient at each medical institution is calculated.
With reference to the medical institution information, the available start time of the resource for executing each process included in each of the flows is acquired.
With reference to the flow information, the start condition and execution time of each process included in each flow are acquired.
With reference to the medical institution information, the available start time of the resource for executing each process included in each of the flows is acquired.
The start time of each process included in each of the flows is calculated based on the acquired start condition, the acquired execution time, and the acquired available start time.
For each of the flows, the treatment startable time, which is the earliest of the calculated start times of the process that is the treatment action, is calculated.
Based on the calculated treatment startable time and the probability that each flow is executed, the expected value of the treatment startable time at each medical institution is calculated.
A medical institution selection server that selects the medical institution candidate based on the calculated expected value. The medical institution selection server according to claim 1.
The processor is a medical institution selection server that includes the status of resources of the medical institution candidate in the information of the selected medical institution candidate and outputs the information. This is a method in which the medical institution selection server selects the medical institution that transports the patient.
The medical institution selection server is
A flow prediction model that predicts a flow consisting of one or more processes executed for the patient from the patient's state information,
Holds medical institution information, which shows the status of resources for executing each process included in the viable flow, for each medical institution.
The method is
The medical institution selection server acquires the patient's status information and
The medical institution selection server predicts the flow to be executed for the patient based on the acquired patient state information and the flow prediction model.
The medical institution selection server refers to the medical institution information to acquire the status of resources for executing each process included in the predicted flow at each medical institution.
The medical institution selection server selects a medical institution candidate to transport the patient based on the status of the acquired resources.
A method in which the medical institution selection server outputs information on the selected medical institution candidate.

Images