JP2015022362A - Emergency request system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an emergency request system to be used when making an emergency request directed to staff members etc. being objects to be requested.SOLUTION: An emergency request system includes: an object person information storage section for storing information on object persons being emergency request objects; a request reception processing section for receiving request information containing conditions for specifying a request object person, from a request side terminal executing a request; a request notification processing section for specifying an object person being a sending destination for a request notification, from the object person information storage section, on the basis of the conditions contained in the received request information, and sending the request notification to an object person terminal used by the specified object person; and a response reception processing section for receiving response information corresponding to the request notification, from the object person terminal. When a request kind in the request information is of a prescribed kind, the request notification processing section generates a unique identifier containing a prescribed answer number, and then generates a request notification containing information being a response destination which is obtained by adding the identifier to a predetermined access destination.

Description

  The present invention relates to an emergency request system for making an emergency request to a subject staff member.

  In the emergency department of the hospital, doctors in charge of duty are on standby to handle the treatment of emergency patients. However, in recent years, there is a shortage of doctors in the emergency department, and there are not many doctors on duty. Under such circumstances, for example, when a large-scale accident or disaster occurs, the doctors in charge of the duty alone are insufficient, so it is necessary to call other doctors.

  In this case, conventionally, each doctor is called individually by referring to a staff list or a dedicated list, or by telephone using a broadcast system as described in Non-Patent Document 1, for example. An emergency call is taking place.

  In some cases, patients who require specialized knowledge in the treatment content may be able to respond even to a large-scale accident or disaster. In such cases, emergency department doctors may need to call for doctors with more specialized knowledge, even though they have a broad range of medical knowledge.

  In that case, as in the case described above, the doctor is individually called by referring to the name list and the like.

  In addition, not only in the medical field, but also in government agencies, companies, etc., if an emergency occurs, the staff in charge may be called. In this case as well, the method of making an individual call is adopted as described above.

Kanda Tsushinki Co., Ltd., “Simultaneous Request System | Solution | Kanda Tsushinki Co., Ltd.”, Internet <URL: http://www.kandt.co.jp/network/yobidashi_issei.html>

  As described above, in the conventional case, a nurse in the emergency department or the like sometimes calls a call, but there are not many staff such as nurses in the time zone on duty. Also, even if an incoming call is received, the requirements cannot be communicated unless the other party answers, and even if a message is put in an answering machine, it takes some time. In particular, when many telephones are called, it can take a lot of time, and it may interfere with the original work.

  By using the simultaneous call system of Non-Patent Document 1, it is possible to reduce the burden on the staff when making a call. However, although it is possible to notify the receiving doctor that there has been an emergency call, it cannot be denied that the situation is inferior in terms of providing information such as what the situation is. Therefore, if you want to know the information, it is necessary to start again from the doctor side, and in that case, staff such as nurses will have to answer the telephone again. Also, after making a general call, information such as whether the doctor confirmed the call and how long it can arrive cannot be grasped by the hospital.

  In addition, when a specific doctor is called by a conventional method, the doctor in charge responds to a staff member such as a nurse who considers who is likely to be applicable according to the symptoms. It will be. In that case, the doctor's thoughts of dealing with it are dispersed, so the possibility of distracting attention to treatment cannot be denied. Also, it is not easy to give such instructions unless you are proficient in various information such as specialized fields of doctors in the hospital.

  In such a case, a system for performing a general call as in Non-Patent Document 1 cannot be used.

  Even in government offices and companies other than medical care, just as with the hospitals mentioned above, using the general call system of Non-Patent Document 1 is inferior in terms of providing information. It is not possible for government agencies or companies to grasp information such as whether they have confirmed or how long they can arrive. Also, traditional methods must be used to call specific personnel appropriate to deal with the incident that has occurred.

  In view of the above problems, the present inventor has performed the present invention.

  1st invention is an emergency request system used when making an urgent request to a target person, and the emergency request system stores a target person information storage unit for storing information of a target person who is a target of an emergency request. And a request reception processing unit that receives request information including a condition for specifying a request target person from a requesting terminal that makes a request, and a target to which a request notification is sent based on the condition in the received request information A request notification processing unit that sends a request notification to a target person terminal used by the specified target person and a response information for the request notification is received from the target person terminal. A response reception processing unit, and when the request type in the request information is a predetermined type, the request notification processing unit generates a unique identifier including a predetermined response number, It generates a request report including information as a response destination to the identifier added to the predetermined access destination information, which is urgent demand system.

  By comprising like this invention, the target person who satisfy | fills a predetermined condition can be specified automatically, and a request notification can be performed with respect to the target person. Therefore, anyone can easily make a request to the target person, and the work load is reduced. Also, unlike the case of telephone calls, time is not required and the amount of information transmitted to the target person increases.

  In the above-described invention, the response reception processing unit can be configured as an emergency request system that performs a process of calculating an estimated arrival time based on the answer number.

  By configuring as in the present invention, the requesting side can know when the target person will arrive.

  In the above-described invention, the emergency request system further sends a notification confirming a response status to the target terminal of the specified target person every predetermined time after receiving the request information, The system can be configured as an emergency request system having a post-status processing unit that automatically cancels the request after a predetermined time has elapsed since the request information was received.

  By configuring as in the present invention, it is possible to periodically confirm the situation with respect to the subject, and to cancel the request itself automatically after a certain period of time has passed. This can reduce the work load on the requesting side.

  In the above-mentioned invention, the emergency request system further transmits a control instruction to the target person terminal so as to acquire the position information of the target person, and receives the position information from the target person terminal. A position information acquisition processing unit that calculates a distance and / or travel time, and the request notification processing unit is configured to specify the target person to which the request notification is to be sent, It can be configured like an emergency request system that specifies the distance and / or travel time specified in (1).

  By comprising like this invention, the target person who is easy to move to the side which performed the request | requirement can be specified. Therefore, even if a request is made, a notification is given to a person who can respond quickly, so that the response time is improved.

  In the above-described invention, the emergency request system further includes a case information storage unit that stores information on past cases processed by the target person, and refers to the case information storage unit based on the request information. A case information reference processing unit for specifying the presence and / or the number of processing cases of the same type of case as the case in the request, and the request notification processing unit is a target for sending the request notification When the target person to be specified is specified, it can be configured as an emergency request system that specifies the experience and / or the number of processing cases specified by the case information reference processing unit.

  By configuring as in the present invention, it is possible to notify the request in consideration of the presence / absence of experience in the past and the degree of experience. Therefore, we can expect a high quality response.

  The emergency request system described above is highly effective when used in the medical field as in the present invention. That is, an emergency request system used when an emergency request is made to a medical worker, the emergency request system including a target person information storage unit that stores information on a medical worker who is a target of an emergency request, A request reception processing unit that receives request information including a condition for specifying a medical worker to be requested from a requesting terminal used by the hospital, and a request notification destination based on the condition in the received request information A request notification processing unit that sends a request notification to a target person terminal used by the specified medical worker, and response information for the request notification. A response reception processing unit that receives from the user terminal, and the request notification processing unit receives a predetermined response number when the type of request in the request information is a predetermined type. Including generating a unique identifier, and generates a request notification including the response destination becomes information added to the predetermined access destination information the identifier can be configured as an emergency request system.

  By configuring as in the present invention, anyone can easily make a request to a health care worker, for example, in an emergency medical field. In medical practice, time is extremely important. By using the system of the present invention, the workload of the requesting staff can be reduced, so that time can be used effectively. In addition, unlike the case of telephone calls, a large amount of information can be transmitted, so that the medical staff who receives the request can respond after obtaining a large amount of knowledge in advance.

  In the above-described invention, the response reception processing unit can be configured as an emergency request system that performs a process of calculating an estimated arrival time based on the answer number.

  When calling a health care professional, the important information is when it arrives. Therefore, by configuring as in these inventions, the hospital can grasp when the medical worker who has called (requested) arrives.

  In the above-described invention, the request notification processing unit generates a unique identifier including a predetermined response number corresponding to the estimated arrival time to the hospital, and adds the identifier to predetermined access destination information. The response reception processing unit can be configured as an emergency request system that calculates a scheduled arrival time based on a response number in the identifier.

  The calculation of the estimated arrival time of the medical staff can be performed by executing the processing as in the present invention. By such processing, the medical staff who receives the request notification can easily inform the hospital of the time required for arrival, thereby reducing the burden.

  In the above-mentioned invention, the request notification processing unit generates a unique identifier including a predetermined answer number corresponding to the type of the current location of the medical worker, and adds the identifier to information on a predetermined access destination When a request notification including information as a response destination is sent, the response reception processing unit determines whether the medical worker is in the hospital or outside the hospital based on the answer number in the identifier. If it is determined, it prompts the target terminal of the medical worker to input information on the estimated arrival time to the hospital, and based on the estimated arrival time information received from the target terminal, It can be configured like an emergency request system.

  In addition, processing such as that of the present invention may be used to calculate the estimated arrival time of a medical worker. That is, an answer indicating whether the medical worker is inside or outside the hospital is accepted, and only when the person is outside the hospital, the time required for arrival is accepted. As a result, the hospital can grasp the general information of the current location of the medical staff, and if it is outside the hospital, it can know the estimated arrival time by accepting the time until it arrives at the hospital. .

  In the above-mentioned invention, the emergency request system further sends a notification confirming a response status to the target terminal of the specified medical worker at a predetermined time after receiving the request information, The system can be configured as an emergency request system having a post-status processing unit that automatically cancels the request after a lapse of a predetermined time after receiving the request information.

  By configuring as in the present invention, it is possible to periodically check the situation with respect to the medical staff who has sent the request notification, and to cancel the request itself automatically after a certain period of time. This can reduce the work burden on the hospital side.

  In the above-described invention, the emergency request system further transmits a control instruction to the target person terminal so as to acquire the position information of the medical staff and receives the position information from the target person terminal, whereby the hospital and its medical care are received. A position information acquisition processing unit that calculates a distance and / or travel time with respect to the worker, and the request notification processing unit determines the medical worker to which the request notification is to be sent. Like an emergency request system that uses the distance and / or travel time specified by the location information acquisition processing unit to identify the medical staff with a short distance and / or short travel time, and send the request notification. Can be configured.

  By configuring as in the present invention, it is possible to preferentially send a request notification from a medical worker who can easily move to a hospital. Therefore, the request can be dealt with promptly and the response time is improved.

  In the above-described invention, the emergency request system further refers to a case information storage unit that stores information on the electronic medical record, and information on the electronic medical record stored in the case information storage unit based on the request information. And a case information reference processing unit for identifying a medical worker who has previously treated the same kind of symptoms as the request and the number of treatments, and the request notification processing unit sends the request notification. An emergency request system that, when identifying a target medical worker, specifies from a medical worker with a large number of treatments among the medical workers identified by the case information reference processing unit, and sends the request notification. It can be configured as follows.

  Medical care is a highly specialized industry. But there are many different patients. Therefore, when making a request, it may not be necessary to call a medical worker who is free. Therefore, the medical staff who has previously treated the same type of symptoms as the patient's symptoms is identified, and the priority for request notification is changed according to the number of cases. As a result, high-quality treatment can be desired.

  The above emergency request system can be realized by executing the following program on a computer. That is, a request reception processing unit that receives request information including a condition for identifying a medical worker who is a request target from a requesting terminal used by a hospital, an emergency based on the condition in the received request information From the target person information storage unit that stores the information of the medical staff subject to the request, the medical staff who is the destination of the request notification is specified, and a request is made to the target terminal used by the specified medical staff. An emergency request program that functions as a request notification processing unit that sends a notification, and a response reception processing unit that receives response information for the request notification from the target person terminal, wherein the request notification processing unit is a type of request in the request information However, in the case of a predetermined type, a unique identifier including a predetermined response number is generated, and the identifier is information on a predetermined access destination. Generating a request notification including the added response destination information serving an urgent demand program.

  By configuring like the program of the present invention, the above emergency request system can be realized.

  By using the emergency request system of the present invention, it is possible to carry out the work easily without any excessive burden being placed on a staff member such as a nurse who makes an emergency request, such as an urgent gathering request. In addition, since various kinds of information can be added at the time of request, information can be obtained even by the staff in charge such as a doctor who receives the information. In addition, information such as whether the emergency request has been confirmed and how long it can arrive can be grasped by the requesting hospital, government office, company, or the like.

  In addition, when calling a staff member such as a specific doctor, based on conventional processing records such as medical records and report documents, a staff member such as a doctor who has experience with the symptom or incident is automatically identified. Requests can also be made, reducing the burden on those who are dealing with treatment.

It is a conceptual diagram which shows typically an example of the system configuration | structure of the emergency request system of this invention. It is a conceptual diagram which shows typically an example of the hardware constitutions of the computer for implement | achieving the emergency request system of this invention. It is a flowchart which shows typically an example of the process of a request process. It is a flowchart which shows typically an example of the process of a request process. It is a flowchart which shows typically an example of the process of the production | generation process of the response URL contained in the request information in a request process. It is a flowchart which shows typically an example of the process of a response process. It is a flowchart which shows typically an example of the process of a request cancellation | release process. It is a flowchart which shows typically an example of the process of a response condition confirmation process. It is a figure which shows an example of the screen of a user registration typically. It is a conceptual diagram which shows an example of a user information storage part typically. It is a figure which shows typically an example of the screen of a subject's registration. It is a conceptual diagram which shows an example of a subject information storage part typically. It is a figure which shows an example of a request | requirement page typically. It is a conceptual diagram which shows an example of a request information storage part typically. It is a figure which shows typically an example of the request notification in the case of a collection request. It is a figure which shows typically an example of the request notification in the case of a disaster request. It is a figure which shows typically an example of the request notification in the case of an advice and image interpretation request. It is a figure which shows typically an example of the request notification in the case of a standby request. It is a figure which shows typically an example of the response page with respect to an advice and image interpretation request. It is a figure which shows typically an example of the response page for receiving the input of arrival time. It is a figure which shows typically an example of the screen which shows a group response and a disaster response. It is a figure which shows an example of a response information storage part typically. It is a figure which shows an example of a login page typically. It is a figure which shows an example of a request content confirmation page typically. It is a figure which shows an example of a request completion page typically. It is a figure which shows an example of an answer content confirmation page typically. It is a figure which shows an example of an answer completion page typically. It is a figure which shows typically an example of the request | requirement page containing the information under request | requirement. It is a figure which shows an example of a request cancellation | release confirmation page typically. It is a figure which shows an example of a request cancellation completion page typically. It is a figure which shows an example of a request cancellation | release notification typically. It is a figure which shows an example of a response status confirmation notification typically. It is a conceptual diagram which shows typically the system configuration | structure of another example of an emergency request system. It is a figure which shows typically another example of the registration screen of a subject. It is a conceptual diagram which shows typically the system configuration | structure of another example of an emergency request system.

  The conceptual diagram of an example of the system configuration | structure of the emergency request system 1 of this invention is shown in FIG. The emergency request system 1 includes a management server 2 used by a company or the like that manages the system, a system administrator terminal 3 that is a computer used by a system administrator who performs system management on the request side of a hospital or company, It has a requesting terminal 4 that is used by a requester such as a hospital or a company that requests a call, and a target terminal 5 that is used by the target person to be requested. The system administrator terminal 3, the requesting terminal 4, and the target user terminal 5 may be desktop computers, portable computers such as tablet computers, communication terminals such as mobile phones, PHS and PDAs, and laptop computers. It may be a computer. These are collectively referred to simply as “computers”.

  The management server 2, the system administrator terminal 3, the requesting terminal 4, and the target person terminal 5 of the emergency request system 1 are realized by various computers. FIG. 2 shows an example of the hardware configuration of the computer. The computer includes an arithmetic device 70 such as a CPU for executing program arithmetic processing, a storage device 71 such as a RAM and a hard disk for storing information, a display device 72 such as a display, a keyboard and a pointing device (such as a mouse and a numeric keypad). ), And a communication device 74 that transmits and receives the processing result of the arithmetic device 70 and information stored in the storage device 71 via a network such as the Internet or a LAN.

  Each drawing shows a case where the management server 2 is realized by a single computer, but the functions may be distributed and realized in a plurality of computers. In addition, each means in the present invention is only logically distinguished in function, and may be physically or virtually the same area.

  In the following description of the present specification, a case where a request such as a call is made to a doctor by the emergency request system 1 of the present invention will be described as an example. Therefore, the system administrator is a hospital system administrator, the requesting side is a hospital emergency medical department, and the target is a doctor.

  Note that the emergency request system 1 of the present invention can be applied to requests other than requests from doctors. For example, in the medical field, it can also be applied to requests from nurses, technical staff, office workers, etc. in addition to doctors. It can also be applied outside the medical field, and can be applied when an emergency call is made to a predetermined person in a company or public office.

  The management server 2 includes a user information registration processing unit 20, a user information storage unit 21, a target person information registration processing unit 22, a target person information storage unit 23, a login processing unit 24, a request reception processing unit 25, a request information storage unit 26, The request notification processing unit 27, the response reception processing unit 28, and the response information storage unit 29 are included.

  The user information registration processing unit 20 receives the user information input from the system administrator terminal 3 by the system administrator of the hospital using the emergency request system 1 and stores it in the user information storage unit 21 to be described later. Register user information. In this specification, the user includes a doctor who is a request target, and a system administrator, a nurse, and a clerk who may operate as a requester. User information includes user identification information, authentication information such as a password, hospital name, name, authority (title, etc.) to which the user belongs. FIG. 9 schematically shows an example of a user registration screen.

  The user information storage unit 21 stores the user information received by the user information registration processing unit 20. FIG. 10 schematically shows an example of the user information storage unit 21.

  The target person information registration processing unit 22 receives information on the target person to be requested, which is input from the system administrator terminal 3 by the system administrator, in the case of this specification, information on the doctor, and will be described later. Stored in the person information storage unit 23. Target information includes organization (for example, hospital name), name, e-mail address, telephone number, conditions (for example, job title and specialty), and information indicating whether the request is valid or invalid. . FIG. 11 schematically shows an example of a subject registration screen.

  The target person information storage unit 23 stores the target person information received by the target person information registration processing unit 22. FIG. 12 schematically shows an example of the subject information storage unit 23.

  The login processing unit 24 executes a login process when using the emergency request system 1. That is, by receiving authentication information such as user identification information (ID) and a password from the system administrator terminal 3 or the requesting terminal 4, it is determined whether or not it matches the authentication information stored in the user information storage unit 21. Execute the login process.

  The request reception processing unit 25 receives information on a request to a target person, for example, a doctor, by performing a predetermined operation at the requesting terminal 4. In this case, the request page shown in FIG. 13 is inputted with the conditions of the target person who is the target of the request, and by receiving it, the process in the request notification processing unit 27 described later is performed.

  The request information storage unit 26 stores the information of the request received by the request reception processing unit 25 in association with identification information for identifying it. FIG. 14 schematically shows an example of the request information storage unit 26.

  The request notification processing unit 27 refers to the target person information storage unit 23 based on the request information received by the request reception processing unit 25 and identifies a corresponding target person, for example, a doctor. Then, a request notification is generated and notified to the identified target person. The request notification is preferably an e-mail, but is not limited thereto, and may be an SNS message function or the like.

  As in the example of the present specification, in the case of request notification to a doctor and the type of request is a collection request, advice / image interpretation request, disaster request, etc., a response URL is generated. In the response URL generation process, first, a hash value is calculated based on the target person identification information, the request date and time, and a predetermined hash function, and an arbitrary URL for each target person with the hash value added as a parameter is generated. If the request type is a set request or a disaster request, a URL is generated by adding a response number corresponding to the type to the hash value.

  For example, when the request type is a set request, a settable time type indicating “how long can be set up” is set as the type, “1” is set within “10 minutes”, and “2” is set within “30 minutes” "Set to", "3" is set to "set within 1 hour", and "4" is set to "unsettable". Then, a URL is generated by adding response numbers “1” to “4” corresponding to these types to the hash value.

  When the type of request is a disaster request, a current location type indicating “location of current location” is provided as a type, “1” is “home”, “2” is “in-hospital disaster response headquarters”, and “3” is “ “First hospital room”, “4” is set as “hospital ward”, “5” is set as “disaster site”, and “6” is set as “moving”. Then, a URL is generated by adding reply numbers “1” to “6” corresponding to these types to the hash value.

  An example of the request notification generated as described above is shown in FIGS. 15 is a request notification when the request type is a collective request, FIG. 16 is a request notification when the request type is a disaster request, and FIG. 17 is a request when the request type is an advice / image interpretation request. FIG. 18 shows a request notification in the case of a standby request.

  The response reception processing unit 28 receives a response to the request notification sent to the target person, and stores it as response information in a response information storage unit 29 described later. Also, processing corresponding to the received response information is executed.

  For example, in the case of a response to an advice / image interpretation request, for example, a response page shown in FIG. 19 is displayed on the target person terminal 5 to receive an advice corresponding to the image. Further, in the case of a response to a disaster request, a response page for accepting an input of the time required for arrival shown in FIG. 20 is displayed on the target person terminal 5 and an input of the time that can be gathered is accepted. Then, as shown in FIGS. 21A to 23, a response page indicating that the response has been made is displayed on the target person terminal 5.

  As response information, for example, in the case of a response to a set request, the response content for the type that can be set becomes response information. In the case of a response to a disaster request, the response content for the current location type becomes response information, and in the case of a response to an advice / image interpretation request. , The content of the advice becomes the response information.

  The response information storage unit 29 stores the response information received by the response reception processing unit 28. In this case, in order to identify the response information, the response information is stored in association with the uniquely identifiable response identification information. FIG. 22 schematically shows an example of the response information storage unit 29.

  The posterior situation processing unit 30 performs automatic cancellation processing on request information stored in the request information storage unit 26 for which request has not been canceled, for request information that has passed a predetermined time, For request information for which the time has not passed, a response status confirmation notification for periodically confirming the response status is sent to each target person.

  Next, a processing process using the emergency request system 1 of the present invention will be described with reference to FIGS.

  First, as a prior process of the process of FIG. 3, when the hospital uses the emergency request system 1, it is necessary to perform user registration from the system administrator terminal 3. In this case, the system administrator accesses the management server 2 by performing a predetermined operation on the system administrator terminal 3. When this access is accepted, the user information registration processing unit 20 causes the system administrator terminal 3 to display the user registration screen shown in FIG.

  Based on the user registration screen displayed on the system administrator terminal 3, authentication information such as user identification information (ID) and password, and input of a name and the like are accepted. Also accepts selection of hospital name and authority. Examples of authorities include system administrators, doctors, nurses, technical staff, and clerks. When the “new user registration” button on the screen of FIG. 9 is pressed, various information received as input is sent from the system administrator terminal 3 to the management server 2 as user information, and user information registration processing of the management server 2 The unit 20 stores the received user information in the user information storage unit 21. By executing such processing, users who use the emergency request system 1 can be registered sequentially.

  Next, registration of the subject who requests is performed from the system administrator terminal 3. In this case, the system administrator accesses the management server 2 by performing a predetermined operation on the system administrator terminal 3. When this access is accepted, the target person information registration processing unit 22 causes the system administrator terminal 3 to display the target person registration screen shown in FIG.

  The doctor information to be requested is stored in the subject registration screen displayed on the system administrator terminal 3. For example, input such as a hospital name, a doctor's name, a doctor's e-mail address, a doctor's telephone number, and a doctor's title is accepted. The job title indicates the conditions of whether or not the person is a candidate, for example, “young” (a person who is shallow as a doctor), “suburbs” (residing near a hospital), “ACS” (acute coronary) Doctors who can cope with the syndrome (generic name for unstable angina pectoris, acute myocardial infarction, sudden ischemic cardiac death), "brain surgery" (brain surgery department doctor), "orthopedics" (orthopedic surgery department doctor), etc. There is an example. The title can be arbitrarily set such as “Obstetrics”, “Pediatrics”, “Veteran” (experienced doctor), “Department” or “Department” (responsible person).

  When the “doctor registration” button on the screen of FIG. 11 is pressed, various types of information received as input are sent from the system administrator terminal 3 to the management server 2 as subject information, and subject information registration in the management server 2 is performed. The processing unit 22 stores the received subject information in the subject information storage unit 23. By executing such processing, it is possible to sequentially register the doctors that are the targets of the emergency request.

  After performing such pre-processing, a request by the emergency request system 1 is actually made to the doctor.

  First, the person in charge of the requesting hospital, for example, a nurse or a clerk, requests access to the login page of the management server 2 by performing a predetermined operation on the requesting terminal 4 (S100). Upon receiving this request, the login processing unit 24 of the management server 2 (S110) transmits the login page shown in FIG. 23 to the requesting terminal 4 (S120) and displays it (S130). In FIG. 23, it is assumed that the nurse “Hanako Suzuki” logs in.

  When the login page is displayed on the requesting terminal 4, the nurse “Hanako Suzuki” who performs the login operation inputs authentication information such as an ID and a password given to the nurse (S140), and clicks the “Login” button. By pressing the key, the input authentication information is sent from the requesting terminal 4 to the management server 2. When the authentication information is received by the login processing unit 24 of the management server 2 (S150), it is determined whether the received authentication information is stored in the user information storage unit 21 (S160, S170). If they do not match, the login processing unit 24 transmits the login page to the requesting terminal 4 again. On the other hand, if they match, the login process has been successfully completed, and the request reception processing unit 25 transmits a request page as shown in FIG. 13 to the requesting terminal 4 (S180).

  When the request page is displayed on the requesting terminal 4 (S190), the nurse “Hanako Suzuki” who makes the request inputs the request information (S200). That is, according to the request page, information such as conditions and conditions for identifying the doctor to be requested is input as request information in accordance with an instruction from the doctor who is handling or a predetermined rule.

  For example, if multiple illnesses visit a hospital and the support is limited, if one wants the support of a young doctor, “collection” as “request”, “multiple illness” as “reason”, “request target” Enter “young” and “1” as the required number.

  In addition, if you want advice for interpretation of images such as CT images and MRI images of the brain, “request” is “advice / image interpretation”, “request target” is “brain surgery”, “confirmation content” is “brain MRI” Please give me advice on image interpretation "," Image "as the storage location (folder name, etc.) of the MRI image, the background of taking the MRI image in" Remarks ", for example," trauma caused by traffic accident ", etc. Enter additional information.

  In addition, when a large-scale disaster occurs, if you want a doctor to support you, information such as “disaster” as “request”, “young, suburbs” as “request target”, “no designation” as “necessary number” input.

  If a doctor who wants to be on standby is desired, information such as “standby” as “request”, “young” as “request target”, and “one person” as “necessary number” is input.

  The request information input on the request page in this way is sent from the requesting terminal 4 to the management server 2 by pressing “Confirm”, and is received by the request reception processing unit 25 of the management server 2 (S210). In the request information, it is determined whether there is a doctor who satisfies the condition to be requested (S220) or the necessary number of persons is sufficient (S230). If the condition is not satisfied, error information is displayed on the request page. Therefore, the request reception processing unit 25 sends the information to the requesting terminal 4 (S240).

  On the other hand, if the condition can be satisfied, the request reception processing unit 25 transmits the request content confirmation page shown in FIG. 24 to the requesting terminal 4 (S250) and displays it on the requesting terminal 4 (S260). The nurse “Hanako Suzuki” confirms the input content displayed on the request content confirmation page on the requesting terminal 4 and if there is a problem (S270), the request page is displayed by pressing the “correct” button. Then, request information is input again. On the other hand, if there is no problem with the input contents (S270), the "Send" button is pressed. As a result, information indicating that the contents are confirmed is sent from the requesting terminal 4 to the management server 2 (S280). When this information is received by the request reception processing unit 25 of the management server 2 (S290), the request reception processing unit 25 transmits a request completion page shown in FIG. 25 to the requesting terminal 4 (S300). It is displayed (S310).

  Further, when the request reception processing unit 25 receives information indicating that the content has been confirmed from the requesting terminal 4, the request reception processing unit 25 stores the information in the request information storage unit 26 as request information (S320). At this time, request identification information for identifying the request information and request date / time information (date / time information storing the request information) are stored in association with each other.

  When the request information is stored in the request information storage unit 26, the request notification processing unit 27 determines the type of request in the request information (S330), and if it is a “standby request”, it meets the condition in the request information. The doctor to perform is specified from the subject information storage unit 23. Then, information on the e-mail address of each specified doctor is extracted, and a request notification as shown in FIG. 18 is generated and transmitted to the e-mail address (S340).

  In addition, the request notification processing unit 27 identifies a doctor corresponding to the condition in the request information from the subject information storage unit 23 when the type of request is “collection request”, “advice / image interpretation request”, or “disaster request”. To do. Then, response URL generation processing corresponding to these doctors is executed (S350).

  That is, the request notification processing unit 27 extracts the identified doctor IDs from the target person information storage unit 23 (S400), and extracts request date and time information from the request information storage unit 26 (S410). Then, a hash value is generated by using the request date and ID as arguments of a predetermined hash function (S420).

  In the case of “collection request” for the generated hash value, a response URL is generated by adding it to a predetermined URL for each answer number of the groupable time type (S430). As the possible time types, “1” is “set within 10 minutes”, “2” is “set within 30 minutes”, “3” is “set within 1 hour”, and “4” is “unsettable” As an example. Also, assume that the generated hash value is “dae1ff52385d585d555a3c24fa552de0” and the predetermined URL is “http://example.jp/emc/receive/”. Then, “http://example.jp/emc/receive/dae1ff52385d585d555a3c24fa552de0/1” as the response URL corresponding to the response number 1, and “http://example.jp/emc/receive” as the response URL corresponding to the response number 2. / dae1ff52385d585d555a3c24fa552de0 / 2 ”,“ http://example.jp/emc/receive/dae1ff52385d585d555a3c24fa552de0/3 ”as the response URL corresponding to the answer number 3, and“ http://example.jp ”as the response URL corresponding to the answer number 4 / emc / receive / dae1ff52385d585d555a3c24fa552de0 / 4 ”is generated. In this way, a request notification for a collection request including a response URL as shown in FIG. 15 is generated.

  If the request type is “disaster request”, a response URL is generated by adding the response number of the current location type to a predetermined URL (S430). As the current location type, the answer number “1” is “home”, “2” is “in-hospital disaster response headquarters”, “3” is “hospital first care room”, “4” is “hospital ward”, “5” Is “disaster site” and “6” is “moving”, the response URL corresponding to the response number 1 is “http://example.jp/emc/receive/dae1ff52385d585d555a3c24fa552de0/1” “Http://example.jp/emc/receive/dae1ff52385d585d555a3c24fa552de0/2” as the response URL corresponding to the number 2 and “http://example.jp/emc/receive/dae1ff52385d585d555a3c24fa552de0/” as the response URL corresponding to the response number 3 3 ”,“ http://example.jp/emc/receive/dae1ff52385d585d555a3c24fa552de0/4 ”as the response URL corresponding to the response number 4, and“ http://example.jp/emc/ ”as the response URL corresponding to the response number 5. receive / dae1ff52385d585d555a3c24fa552de0 / 5 ”,“ http: // exam ”as the response URL corresponding to the answer number 6 ple.jp/emc/receive/dae1ff52385d585d555a3c24fa552de0/6 ”. In this manner, a disaster request request notification including a response URL as shown in FIG. 16 is generated.

  When the request type is “advice / image interpretation request”, only the hash value is added to a predetermined URL. That is, “http://example.jp/emc/receive/dae1ff52385d585d555a3c24fa552de0/” is generated as a response URL. In this way, a request notification of an advice / image interpretation request including a response URL as shown in FIG. 17 is generated.

  Then, the request notification processing unit 27 extracts the email address information of each doctor specified above and transmits a request notification as shown in FIGS. 15 to 17 to the email address (S360).

  The request notification sent in this way is received by the identified subject terminal 5 of each doctor (S370, S380).

  Through the processing described above, the nurse “Hanako Suzuki” can easily send a request notification to each doctor corresponding to the request information. In addition, if various information is included in the remarks column as the request information, for example, more information can be notified than before, so that the doctor can grasp more information.

  The doctor who has received the request notification waits at a predetermined location if the request is a waiting request shown in FIG.

  If the request notification is a collection request, an advice / image interpretation request, or a disaster request, a response URL in the request notification is selected (clicked) (S500). Here, the response reception processing unit 28 determines the selected response URL (S510, S520).

  When the request notification is an advice / image interpretation request, since the response URL only includes a hash value, the request information in the request information storage unit 26 is specified based on the hash value. Then, based on the specified request information, an advice / image interpretation request response page including an image to be interpreted shown in FIG. 19 is transmitted to the target person terminal 5 (S530), and is displayed on the target person terminal 5 (S540). .

  The target person who viewed this screen inputs the result of the interpretation in a predetermined location, for example, in the “Advisory” field on the advice / image interpretation request response page, and presses the “Confirm” button to enter the content of the answer. Is sent from the subject terminal 5 to the management server 2 (S550). The sent response content is received by the response reception processing unit 28 of the management server 2 (S560), and as shown in FIG. 26, a response content confirmation page is transmitted to the target person terminal 5 (S570).

  When the response content confirmation page is displayed on the target person terminal 5 (S580), and when the content is to be corrected (S590), by pressing the “correct” button, the advice / image interpretation request response page in S540 is again displayed. Is displayed. On the other hand, if there is no correction (S590), pressing the “Send” button sends information indicating that the content has been confirmed from the target terminal 5 to the management server 2 (S600). When this information is received by the response reception processing unit 28 of the management server 2 (S610), the response reception processing unit 28 transmits the response completion page shown in FIG. 27 to the target person terminal 5 (S620). It is displayed (S630).

  In addition, when receiving information indicating that the content has been confirmed from the target person terminal 5, the response reception processing unit 28 stores the response content in the response information storage unit 29 (S720). At this time, the response information is stored in association with the response identification information for identifying the response information. Also, the response date information is stored in association with each other. The doctor who has requested the image interpretation can know the advice as the response content by browsing the response information by a predetermined method such as the requesting terminal 4.

  In S510 and S520, when the request notification is a disaster request, the response URL includes the current location type in addition to the hash value. Therefore, the response reception processing unit 28 determines whether the hospital is inside or outside the hospital based on the current location type (S640). If the current location type is “2” (hospital response headquarters), “3” (hospital primary care room), or “4” (hospital ward), it is determined to be in the hospital, and the current location type is “1” (home ), “5” (disaster site), and “6” (moving), it is determined to be outside the hospital.

  When it is determined that the patient is out of the hospital, the response reception processing unit 28 transmits an arrival time response page shown in FIG. 20 to the target person terminal 5 (S650), and displays it on the target person terminal 5 (S660). . The doctor who browsed the arrival time response page considers how long it will be possible to arrive at the hospital, and presses a button corresponding to that, for example, a button “within 30 minutes”. The target user terminal 5 transmits time information corresponding to the pressed button to the management server 2 as the response content (S670). The sent response content is received by the response reception processing unit 28 of the management server 2 (S680), and the response reception processing unit 28 calculates the estimated arrival time based on the response content (S690).

  For example, if the received response content is “within 30 minutes” as described above, and the date and time when the response is received is “May 29, 2013 23:12:45”, the response content at the received time The estimated arrival time is calculated as “May 29, 2013 23:42:45”.

  Then, the response acceptance processing unit 28 transmits the disaster response page shown in FIG. 21A to the target person terminal 5 (S700), and displays it on the target person terminal 5 (S710). Further, the response reception processing unit 28 stores, as response information, information indicating the current location type, the response content on the arrival time response page, and the estimated arrival time received in the response information storage unit 29 as response content. (S720). At this time, the response information is stored in association with the response identification information for identifying the response information. Also, the response date information is stored in association with each other. Then, the hospital side can perform a predetermined operation to view this response information on the requesting terminal 4 or the like and know the estimated arrival time of the doctor who made the response.

  If it is determined in S640 that the current location type is in the hospital, the disaster response page shown in FIG. 21 (b) is transmitted to the target person terminal 5 because it is already in the hospital (S700). It is displayed (S710). In addition, the response reception processing unit 28 stores the information indicating the current location type received from the target person terminal 5 as the response information in the response information storage unit 29 as the response content (S720). At this time, the response information is stored in association with the response identification information for identifying the response information. Also, the response date information is stored in association with each other.

  In S510 and S520, when the request notification is a set request, the response URL includes a settable time type in addition to the hash value. Therefore, the response reception processing unit 28 calculates the estimated arrival time based on the settable time type (S690). For example, when the collectable type included in the response URL is “2” and the date and time when the response is received is “2013 May 29 23:12:45”, the time of the response content is set at the received time. The estimated arrival time is calculated as “May 29, 2013 23:42:45”.

  Then, the response acceptance processing unit 28 transmits the collective response page shown in FIG. 21C to the target person terminal 5 (S700), and displays it on the target person terminal 5 (S710). Further, the response reception processing unit 28 stores, as response information, information indicating the settable time type and estimated arrival time received from the subject terminal 5 in the response information storage unit 29 as response contents (S720). At this time, the response information is stored in association with the response identification information for identifying the response information. Also, the response date information is stored in association with each other.

  By executing the processing as described above, a response to the request notification transmitted from the management server 2 to the target person terminal 5 can be acquired. At that time, if necessary, information on how long it can be reached can be acquired, so that the hospital can recognize when and how many doctors can arrive.

  Next, processing when canceling a request will be described. First, when the person in charge of the requesting hospital, for example, the nurse “Hanako Suzuki”, cancels the request that has already been made, the requesting terminal 4 performs login processing to the management server 2 (S800).

  That is, a request is made to access the login page of the management server 2 by performing a predetermined operation on the requesting terminal 4. Upon receiving this request, the login processing unit 24 of the management server 2 transmits the login page shown in FIG. 23 to the requesting terminal 4 for display.

  When the login page is displayed on the requesting terminal 4, the nurse or the clerk inputs the authentication information such as the ID and password assigned to him and presses the “Login” button. Authentication information is sent from the requesting terminal 4 to the management server 2. When the authentication information is received by the login processing unit 24 of the management server 2, it is determined whether the received authentication information is stored in the user information storage unit 21. If they do not match, the login processing unit 24 transmits the login page to the requesting terminal 4 again.

  If they match, the log-in process has been successfully performed, and the request reception processing unit 25 refers to the request information storage unit 26 to determine whether there is information being requested (S810). If there is no information, the request reception processing unit 25 transmits a request page as shown in FIG. 13 to the requesting terminal 4 (S820).

  On the other hand, if there is information being requested, the information is extracted from the request information storage unit 26, and a request page including the requested information is transmitted to the requesting terminal 4 as shown in FIG. 28 (S830). ). This request page is displayed on the requesting terminal 4 (S840).

  When canceling the request for the requested information, select the request to be canceled from the requested information shown in FIG. 28, and press the “Request Cancel” button to cancel the request cancellation information. Is transmitted from the requesting terminal 4 to the management server 2 (S850). The request cancellation information is received by the request reception processing unit 25 of the management server 2 (S860).

  The request reception processing unit 25 that has received the request cancellation information transmits a request cancellation confirmation page shown in FIG. 29 to the requesting terminal 4 (S870), and the requesting terminal 4 displays it (S880). If the request is not canceled (S890), the request page shown in FIG. 28 is displayed again by pressing the “Cancel” button.

  When request cancellation is performed (S890), information on execution of request cancellation is transmitted to the management server 2 by pressing an "OK" button on the request cancellation confirmation page (S900). When the request reception processing unit 25 of the management server 2 receives the request cancellation execution information (S910), the request information to be canceled is deleted from the request information storage unit 26 (S920). Here, the deletion means that the request information may actually be deleted from the request information storage unit 26, or information indicating that the request has been canceled is stored so that the request information is not displayed. May be executed.

  When the request information is updated in this way, the request reception processing unit 25 transmits a request release completion page shown in FIG. 30 to the requesting terminal 4 (S930), and the requesting terminal 4 displays it (S940). ). On the other hand, when deleting the request information in S920, the request notification processing unit 27 transmits a request cancellation notification shown in FIG. 31 to each doctor who transmitted the request notification (S950). The request cancellation sent is received by the subject terminal 5 (S960), and the doctor recognizes that the request has been canceled by browsing it.

  Next, a case will be described in which a response is received from a doctor who has been requested, and the subsequent response status is notified.

  First, the posterior situation processing unit 30 refers to the request information storage unit 26 and determines the type of request and its status (whether requested or released) for each request information (S1000). Then, the request information whose request has already been released is excluded from the processing target (S1010).

  Among the requested information, the request information of “Gathering request”, “Advisory / image interpretation request”, and “Disaster request” is requested time from the date when the request information was received (request date information). If it has passed, for example, 5 minutes, 10 minutes, 20 minutes, 30 minutes, 45 minutes, 60 minutes, 75 minutes after the request date and time, the doctor identified as the destination of the request information In response to this, a response status confirmation notification as shown in FIG. 32 is transmitted (S1040). Then, the doctor who has received the response status confirmation notification at the subject terminal 5 (S1050) can recognize the current status.

  On the other hand, when a predetermined time (for example, 90 minutes) elapses from the request date and time when the request information is received, the posterior situation processing unit 30 executes processing for automatically canceling the request. That is, the request information determined in S1000 is deleted from the request information storage unit 26 in order to cancel the request information (in addition to deleting the request information, information indicating that the request information has been canceled is stored). Then, a request cancellation notification shown in FIG. 31 is transmitted to the doctor specified as the transmission destination of the request information (S1070). The doctor receives the request cancellation notice at the target person terminal 5 (S1080), and recognizes that the request has been canceled by browsing it.

  In addition, in the request information determined as being requested in S1000 to S1020, if the type of request is “standby request”, if a predetermined time (for example, 90 minutes) has elapsed from the request date and time, the subsequent situation The processing unit 30 executes processing for automatically canceling the request. That is, the request information determined in S1000 is deleted from the request information storage unit 26 in order to cancel the request information (in addition to deleting the request information, information indicating that the request information has been canceled is stored). Then, a request cancellation notification shown in FIG. 31 is transmitted to the doctor specified as the transmission destination of the request information (S1070). The doctor receives the request cancellation notice at the target person terminal 5 (S1080), and recognizes that the request has been canceled by browsing it.

  By executing the processing as described above, it is possible to manage the subsequent response status after receiving a response from the requested doctor.

  In the above-described embodiment, when specifying a target doctor, the current location information of the doctor may be acquired by GPS, and this may be used as a condition for specifying the target doctor. FIG. 33 schematically shows an example of a conceptual diagram of the system configuration of the emergency request system 1 in the present embodiment. In the case of the present embodiment, as shown in FIG. 33, the management server 2 includes a position information acquisition processing unit 31.

  When the position information acquisition processing unit 31 receives a request for acquiring position information from the requesting terminal 4, the position information acquisition processing unit 31 has a GPS function provided in the target person terminal 5 possessed by a target person (such as a doctor) that satisfies the conditions of the request information. A control instruction is sent so that the position information (latitude and longitude information) is acquired and sent to the management server 2. When the position information acquisition processing unit 31 acquires position information from each target person terminal 5, the position information acquisition processing unit 31 calculates the distance to the hospital using the position information and the position information of the hospital. In this case, the linear distance to the hospital may be calculated, or the actual distance may be calculated by referring to the map information. In addition to the distance, the time required for movement may be calculated.

  Then, the request notification processing unit 27 identifies a doctor who is a target person based on the request information received from the target person terminal 5 and the position information, distance, and travel time information acquired from the position information acquisition processing unit 31.

  In addition, after specifying the doctor who becomes an object person, the process by the positional information acquisition process part 31 may be performed, and you may make it send a request | requirement notification preferentially with respect to a doctor with short distance, and a doctor with a short movement time.

  In order to execute the above functions, for example, the following processing may be executed.

  First, in order to acquire the position information in the position information acquisition processing unit 31, the requesting terminal 4 presses the “acquire position information” button from the registration screen of the target person shown in FIG. An information acquisition request is sent from the requesting terminal 4 to the management server 2.

  The position information acquisition processing unit 31 that has received the position information acquisition request activates the GPS function for the doctor's target terminal 5 that satisfies the conditions of the request information, acquires the position information, and sends it to the management server 2. Send a control instruction to send. Each subject terminal 5 that has received this control instruction activates the GPS function, acquires its position information, and sends it to the management server 2.

  The position information acquisition processing unit 31 that has received the position information from each target person terminal 5 calculates the distance to the hospital and the travel time based on the position information. By passing the distance and travel time calculated here to the request notification processing unit 27, the request notification processing unit 27 further narrows down and identifies the doctors of the target person to whom the request notification is sent. In some cases, a request notification is sent in order from a doctor who is close to the doctor and a doctor who has a short travel time. That is, the requested doctors are rearranged according to the distance and travel time, and a request notification is first sent to doctors corresponding to the required number of people in the request information. For example, if three people are required, three doctors with short distances and travel times are identified in order, and a request notification is sent only to the three doctors.

  If there are doctors who do not respond after a certain period of time, or doctors who cannot be collected, requests are made according to the number of doctors who do not respond or cannot be collected according to the order of the rearranged doctors. Send notifications. For example, if one of the three people sent above did not respond and one was a non-aggregate response, a request notification has already been sent to the third of the doctors sorted above. Therefore, a request notification is sent to the fourth and fifth doctors.

  In this way, a request notification can be sent in accordance with the current state of the doctor.

  In this embodiment, further, a case will be described in which the target person to be requested is specified by referring to information obtained by processing past cases and specifying the optimum target person. An example of the system configuration of the emergency request system 1 in this case is shown in FIG.

  The emergency request system 1 according to the present embodiment further includes a case information reference processing unit 32 and a case information storage unit 33. FIG. 35 shows a case where the above configuration is added to the emergency request system 1 of the second embodiment, but the above configuration may be added to FIG.

  Based on the request information received by the request reception processing unit 25, the case information reference processing unit 32 determines whether the same type of cases have been processed in the past among the case information stored in the case information storage unit 33. Specify the number of cases. Then, a target person who has processed the same type of case is passed to the request notification processing unit 27. Alternatively, for the target person specified by the request notification processing unit 27 based on the request information, the number of processes of the same type of past cases among the case information stored in the case information storage unit 33 is specified, and the ranking is based on the specified number. Do. Then, the priority order is passed to the request notification processing unit 27.

  The item information storage unit 33 stores past item information. The project information includes electronic medical record information, for example.

  For example, there are the following methods for executing the processing in this embodiment.

  When the request page is displayed on the requesting terminal 4 (S190), the nurse or the clerk who makes the request inputs the request information (S200). As request information to be input at this time, for example, in the remarks column of the request page, what kind of symptom is present, what kind of symptom is suspected, and which doctor in a specialized field is specified.

  For example, when a certain sick person is transported as an emergency patient, if a certain special disease is suspected as a result of the examination, the name of the disease is entered.

  The request information input on the request page in this way is sent from the requesting terminal 4 to the management server 2 by pressing “Confirm”, and is received by the request reception processing unit 25 of the management server 2 (S210). In the request information, it is determined whether there is a doctor who satisfies the condition to be requested (S220) or the necessary number of persons is sufficient (S230). If the condition is not satisfied, error information is displayed on the request page. Therefore, the request reception processing unit 25 sends the information to the requesting terminal 4 (S240).

  On the other hand, if the condition can be satisfied, the request reception processing unit 25 transmits the request content confirmation page shown in FIG. 24 to the requesting terminal 4 (S250) and displays it on the requesting terminal 4 (S260). The nurse or the clerk checks the input content displayed on the request content confirmation page on the requesting terminal 4 and if there is a problem (S270), the request page is displayed by pressing the “correct” button. Then, request information is input again. On the other hand, if there is no problem with the input content (S270), information indicating that the content has been confirmed is sent from the requesting terminal 4 to the management server 2 by pressing the “Send” button (S280). When this information is received by the request reception processing unit 25 of the management server 2 (S290), the request reception processing unit 25 transmits a request completion page shown in FIG. 25 to the requesting terminal 4 (S300). It is displayed (S310).

  Further, when the request reception processing unit 25 receives information indicating that the content has been confirmed from the requesting terminal 4, the request reception processing unit 25 stores the information in the request information storage unit 26 as request information (S320). At this time, the request information is stored in association with the request identification information for identifying the request information. Further, the request date information is stored in association with each other.

  When the request information is stored in the request information storage unit 26, the request notification processing unit 27 determines the type of request in the request information (S330). If it is a “waiting request”, the doctor corresponding to the condition in the request information is specified from the subject information storage unit 23. Then, information on the e-mail address of each specified doctor is extracted, and a request notification as shown in FIG. 18 is generated and transmitted to the e-mail address (S340).

  In addition, the request notification processing unit 27 identifies a doctor corresponding to the condition in the request information from the subject information storage unit 23 when the type of request is “collection request”, “advice / image interpretation request”, or “disaster request”. To do. Then, response URL generation processing corresponding to these doctors is executed (S350).

  In this embodiment, when the corresponding doctor is specified, the request notification processing unit 27 merely specifies the corresponding doctor from the target person information storage unit 23 based on the request information as in the first embodiment. Instead, the case information reference processing unit 32 extracts information such as a disease name entered in the remarks column in the request information, and based on the extracted information such as the disease name, the item information that is an electronic medical record is extracted as the item information. Search from the storage unit 33. In this case, a cross-sectional search is performed for each patient's electronic medical record to determine whether the disease name is included and who is the doctor who performed the treatment. Then, the number of treatments for each disease name is calculated for each doctor.

  In this way, the information on the number of treatments for each doctor is passed to the request notification processing unit 27, and the request notification processing unit 27 determines whether or not the conditions in the request information are met in order from the doctor with the largest number of treatments. When the doctors are reached, they are identified as subjects.

  As another method, the doctor information corresponding to the condition is passed to the case information reference processing unit 32. Then, the case information processing unit extracts information such as a disease name entered in the remarks column in the request information. Then, the corresponding doctor determines the number of treatments for the disease with the extracted disease name by searching the electronic medical record from the case information storage unit 33. Then, for each doctor who meets the condition, the number of treatments for that disease name is calculated.

  In this way, the number of treatments of the disease name for each doctor who meets the conditions is passed to the request notification processing unit 27, and the request notification processing unit 27 determines whether the conditions in the request information are met in order from the doctor with the largest number of treatments. When the required number of doctors is reached, identify them as subjects.

  By executing the processing as described above, a doctor who has experience with the disease name can be identified as the target person. For this identification, deep knowledge is not necessary, and only registration as request information is sufficient.

  The subsequent processing is executed in the same manner as in the first and second embodiments.

  By using the emergency request system 1 according to the present invention, it is possible to carry out the work easily without any excessive burden on the staff such as a nurse who makes an emergency request, such as an urgent gathering request. . In addition, since a variety of information can be added at the time of a simultaneous request, information can also be obtained on the part of a staff member such as a doctor who receives the request. In addition, information such as whether the emergency request has been confirmed and how long it can arrive can be grasped by the requesting hospital, public office, company, or the like.

  In addition, when calling a staff member such as a specific doctor, a staff member such as a doctor who has experience with the relevant symptom or incident is automatically identified and requested based on the conventional records of medical records and reports. Can also reduce the burden on the person undergoing treatment.

1: Emergency request system 2: Management server 3: System administrator terminal 4: Request side terminal 5: Target person terminal 20: User information registration processing unit 21: User information storage unit 22: Target person information registration processing unit 23: Target person Information storage unit 24: Login processing unit 25: Request reception processing unit 26: Request information storage unit 27: Request notification processing unit 28: Response reception processing unit 29: Response information storage unit 30: Subsequent situation processing unit 31: Position information acquisition processing Unit 32: Matter information reference processing unit 33: Matter information storage unit 70: Computing device 71: Storage device 72: Display device 73: Input device 74: Communication device

Claims (13)

An emergency request system used when making an urgent request to a target person,
The emergency request system
A subject information storage unit for storing information of a subject subject to an emergency request;
A request reception processing unit that receives request information including a condition for identifying a request target person from a requesting terminal that makes a request;
Based on the conditions in the received request information, a target person to which a request notification is sent is specified from the target person information storage unit, and a request notification is sent to the target terminal used by the specified target person A notification processing unit;
A response reception processing unit that receives response information for the request notification from the target person terminal,
The request notification processing unit
When the request type in the request information is a predetermined type, a unique identifier including a predetermined response number is generated, and information serving as a response destination is added to the predetermined access destination information. Generate a request notification containing
Emergency request system characterized by that. The response reception processing unit
Based on the answer number, the estimated arrival time is calculated.
The emergency request system according to claim 1. The emergency request system further includes:
After receiving the request information, a notification confirming the response status is sent to the target terminal of the specified target person at a predetermined time, and after a predetermined time has passed since the request information was received, Post-situation processing unit that automatically cancels the request,
The emergency request system according to claim 1 or 2, characterized by comprising: The emergency request system further includes:
A position information acquisition process for transmitting a control instruction to the target person terminal to acquire the position information of the target person and receiving the position information from the target terminal, thereby calculating a distance and / or travel time with the requesting side. Part,
The request notification processing unit
When specifying the target person to whom the request notification is sent, specify the distance and / or travel time specified by the position information acquisition processing unit,
The emergency request system according to any one of claims 1 to 3, wherein the system is an emergency request system. The emergency request system further includes:
An item information storage unit for storing information on past items processed by the target person,
By referring to the case information storage unit based on the request information, there is a case information reference processing unit for specifying the presence and / or the number of processing cases of the same type of cases as the case in the request in the past. And
The request notification processing unit
When specifying the target person to whom the request notification is sent, specify the experience and / or the number of processing cases specified by the case information reference processing unit,
The emergency request system according to any one of claims 1 to 4, wherein the system is an emergency request system. An emergency request system used when making an emergency request to a healthcare worker,
The emergency request system
A subject information storage unit for storing information on medical personnel who are the subject of an emergency request;
A request reception processing unit that receives request information including a condition for identifying a medical worker to be requested from a requesting terminal used by a hospital;
Based on the conditions in the received request information, a medical worker who is the destination of the request notification is specified from the target person information storage unit, and a request notification is sent to the target terminal used by the specified medical worker. A request notification processing section to be sent;
A response reception processing unit that receives response information for the request notification from the target person terminal,
The request notification processing unit
When the request type in the request information is a predetermined type, a unique identifier including a predetermined response number is generated, and information serving as a response destination is added to the predetermined access destination information. Generate a request notification containing
Emergency request system characterized by that. The response reception processing unit
Based on the answer number, the estimated arrival time is calculated.
The emergency request system according to claim 6. The request notification processing unit
A unique identifier including a predetermined response number corresponding to the expected arrival time to the hospital is generated, and a request notification including information serving as a response destination is added to the predetermined access destination information.
The response reception processing unit
Calculate the estimated arrival time based on the answer number in the identifier.
The emergency request system according to claim 6 or 7, characterized in that. The request notification processing unit
Generating a unique identifier including a predetermined response number corresponding to the type of the current location of the medical worker, sending a request notification including information serving as a response destination with the identifier added to information of a predetermined access destination,
The response reception processing unit
Based on the answer number in the identifier, determine whether the medical worker is in the hospital or outside the hospital,
If it is determined that the patient is outside the hospital, the target terminal of the medical worker is prompted to input information on the estimated arrival time to the hospital,
Calculate the estimated arrival time based on the estimated arrival time information received from the target terminal.
The emergency request system according to any one of claims 6 to 8, wherein the system is an emergency request system. The emergency request system further includes:
After receiving the request information, a notification confirming the response status is sent to the target terminal of the specified medical worker at a predetermined time, and after a predetermined time has passed since the request information was received, A post-situation processing unit that automatically cancels the request;
The emergency request system according to any one of claims 6 to 9, characterized by comprising: The emergency request system further includes:
The control instruction is transmitted to the target person terminal so as to acquire the position information of the medical staff, and the distance information and / or travel time between the hospital and the medical staff is calculated by receiving the position information from the target terminal. A position information acquisition processing unit,
The request notification processing unit
When identifying a medical worker who is a target for sending the request notification, using the distance and / or travel time specified by the position information acquisition processing unit, the medical worker who is near and / or short in travel time. And prioritize and send the request notification,
The emergency request system according to any one of claims 6 to 10, wherein the system is an emergency request system. The emergency request system further includes:
A case information storage unit for storing electronic medical record information;
A project that identifies a medical worker who has previously treated a symptom of the same type as the symptom in the request and the number of treatments by referring to the electronic medical record information stored in the case information storage unit based on the request information An information reference processing unit,
The request notification processing unit
When identifying a medical worker to whom the request notification is to be sent, among the medical workers identified by the case information reference processing unit, the medical worker with the highest number of treatments is identified preferentially, and the request notification is sent. send,
The emergency request system according to any one of claims 6 to 11, wherein the system is an emergency request system. Computer
A request acceptance processing unit that accepts request information including conditions for identifying a medical worker to be requested from a requesting terminal used by a hospital;
Based on the conditions in the received request information, the medical worker to which the request notification is sent is specified from the target person information storage unit that stores the information of the medical worker who is the target of the emergency request, and the specified medical staff A request notification processing unit for sending a request notification to the target user terminal used by the user,
A response reception processing unit for receiving response information for the request notification from the target person terminal 5;
An emergency request program to function as
The request notification processing unit
When the request type in the request information is a predetermined type, a unique identifier including a predetermined response number is generated, and information serving as a response destination is added to the predetermined access destination information. Generate a request notification containing
An emergency request program characterized by this.

Images