JP5215011B2 - Medical service message processing apparatus, method and program - Google Patents

Description

  The present invention relates to a technique for processing a message related to a medical service.

  Patent Document 1 discloses a technique for distributing work to a plurality of specialist terminals in order to efficiently process the work.

JP-A-8-102981

  By the way, in the medical field, when communication is made between business personnel involved in medical work, for example, verbal or PHS (Personal Handyphone System) is used as a communication means. The same transmission means as described above is also used when a request for work performed in a medical service is made.

  However, when a work request is made using the above-described transmission means, for example, (A) a partner who has been requested may not be found, and (B) only one partner can be requested at the same time. (C) The other party may not be able to perform the requested work.

  Accordingly, an object of the present invention is to efficiently perform a request for work performed in a medical service.

  The medical service message processing device according to the present invention includes a reception unit that receives a request including patient identification information, a transmission unit that transmits a request message based on the received request to a plurality of request destination terminals and one or more doctor terminals, When receiving a response message to the request message from one or more request destination terminals of the doctor terminal and the plurality of request destination terminals, the request destination that issued the response message in response to the response message from the doctor terminal Selecting means for selecting any one of the terminal and the doctor terminal and transmitting a request confirmation message to the selected terminal.

  In a preferred embodiment according to the present invention, when the response message to the request message is returned from a plurality of request destination terminals, the selection means displays the identification information of the user of the request destination terminal that issued the response message. The doctor terminal may be notified, and the one terminal may be selected based on user identification information included in the response message from the doctor terminal.

  In the medical service message processing device according to the present invention, the selecting means is such that if the response message from the doctor terminal is an acceptance message for accepting the request accepted by the acceptance means, the response message from the plurality of request destination terminals. Regardless of whether the message is an acceptance message, the doctor terminal may be selected.

  The medical service message processing device according to the present invention further includes a patient database that stores patient identification information and doctor identification information in association with each other, and the transmission unit includes patient identification information included in the request received by the reception unit, The request message may be transmitted to one doctor terminal corresponding to the doctor identification information associated in the patient database.

  The medical service message processing device according to the present invention further comprises a request destination database that stores the request destination and one or more request destination terminals in the request destination in association with each other, and the request receiving means receives the designation of the request destination, The transmission unit may select and transmit one or more request destination terminals associated with the specified request destination in the request destination database.

  The medical service message processing device according to the present invention further includes a flow database that stores a plurality of request destinations in order, and the transmission unit completes the work related to the first request destination among the plurality of request destinations. According to the order of the request destinations stored in the flow database, one or more request destination terminals associated with the second request destination next to the first request destination may be selected and transmitted.

  In the medical service message processing device according to the present invention, the selection means receives the acceptance message for the request message from one or more request destination terminals of the doctor terminal and the plurality of request destination terminals, and then receives the acceptance message. When receiving a withdrawal instruction for an acceptance message from any one of the request destination terminal and the doctor terminal that has returned, the request destination terminal that has returned the acceptance message and the doctor terminal other than the terminal that has issued the withdrawal instruction Any one terminal may be selected and a request confirmation message may be transmitted to the selected terminal.

  Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

  FIG. 1 is a diagram illustrating a configuration example of a computer system according to the present embodiment.

  A plurality of terminals 1 and a server 2 are connected via a communication network 3.

  The terminal 1 is a computer used by a person who is engaged in medical work (for example, a doctor, a nurse, an engineer who handles medical equipment, etc., and hereinafter referred to as “business-related person”). The terminal 1 is provided with an input / output unit for the user (working person) to input to the terminal 1 and display various screens. For example, a display, a keyboard, a mouse, or the like is employed as the input / output unit.

  The server 2 is a computer that supports a business person concerned with the business. For example, the server 2 is a request (hereinafter referred to as “work request”) for work performed in medical work (for example, X-ray imaging or examination using CT (Computed Tomography), hereinafter simply referred to as “work”). Is received from the business personnel, and the business personnel (hereinafter referred to as “workers”) who perform the requested work are supported. For example, the server 2 supports the determination of the operator by performing the process shown in FIG.

  FIG. 2 is a diagram for explaining an overview of processing performed by the server 2.

  The server 2 accepts a work request 51 from any one of the terminals 1 (business personnel using the terminal 1) (FIG. 2 (1)). The work request 51 includes, for example, information indicating the contents of the requested work, information indicating a place where the work is performed (hereinafter referred to as “request destination”), and a patient (hereinafter referred to as a patient who will receive treatment by the work). Information for identifying “target patient”) is included. As information for identifying a patient (hereinafter referred to as “patient identification information”), for example, an ID given to the patient, the name of the patient, and the like are employed.

  The server 2 that has received the work request 51 sends a message (hereinafter referred to as “request message”) 52 for notifying the accepted work request 51 to the terminal 1 used by a business person who may be a work performer. Transmit (FIG. 2 (1)). For example, as a business person who may be a worker, a doctor (primary physician) who is in charge of the target patient and the terminal 1 installed at the request destination are used (login to the terminal 1). Yes, it can be a business person. In the request message 52, for example, the request message 52 is identified in addition to the same information as the information included in the work request 51 (information indicating the content of the work, information indicating the request destination, and patient identification information of the target patient). Information for is included. As information for identifying the request message 52 (hereinafter, “message identification information”), for example, an ID or a branch number assigned to the request message 52 is employed. Hereinafter, the terminal 1 that has made a request to the server 2 is referred to as a “request source terminal 11”, and the terminal 1 that receives a work request 51 notification by receiving a request message 52 from the server 2 is referred to as a “request notification terminal 12”. . The terminal 1 installed at the request destination is referred to as “request destination terminal 13”.

  Thereafter, the server 2 receives a response indicating that the user of the terminal 1 accepts the work request 51 (can perform the work) from any one or more of the request notification terminals 12 (hereinafter, “accept response”). 53 is received (FIG. 2 (2)). The acceptance response 53 includes, for example, message identification information of a request message 52 related to the acceptance response 53 (a request message 52 notifying the work request 51 to be accepted in the acceptance response 53).

  The server 2 that has received the acceptance response 53 sends a message (hereinafter, “acceptance response message”) 54 for notifying the acceptance response 53 to the request source terminal 11 and the request notification terminal 12 for each accepted acceptance response 53. Transmit (FIG. 2 (2)). The acceptance response message 54 includes, for example, message identification information included in the acceptance response 53 and information for identifying the user of the terminal 1 that has issued the acceptance response 53 (the business person who accepted the work request 51). included. As information for identifying a business person (hereinafter, “business person identification information”), for example, an ID given to the business person, the name of the business person, and a terminal used by the business person The name 1 is adopted. The terminal 1 that has received the acceptance response message 54 displays a screen based on the acceptance response message 54 and notifies the user of the terminal 1 of the content of the acceptance response message 54. As a result, the users of the request source terminal 11 and the request notification terminals 12 can know the business related person who has accepted the work request 51 (hereinafter, “work execution candidate”).

  In addition, the user of the terminal 1 that has issued the acceptance response 53 can withdraw the acceptance response 53. When the acceptance response 53 is withdrawn, the terminal 1 of the user performing the withdrawal issues an instruction (hereinafter referred to as “withdrawal instruction”) 55 to withdraw the acceptance response 53 issued by itself to the server 2 (FIG. 2 ( 2)). The withdrawal instruction 55 includes, for example, message identification information of a request message 52 associated with the withdrawal instruction 55 (a request message 52 associated with the acceptance response 53 withdrawn by the withdrawal instruction 55).

  The server 2 that has received the withdrawal instruction 55 transmits a message (hereinafter referred to as “cancellation message”) 56 for notifying the accepted withdrawal instruction 55 to the request source terminal 11 and the request notification terminal 12 (FIG. 2 (2)). ). The withdrawal message 56 includes, for example, message identification information included in the withdrawal instruction 55, and business party identification information of the user of the terminal 1 that issued the withdrawal instruction 55 (the business party who performed the withdrawal of the acceptance response 53). Is included. The terminal 1 that has received the withdrawal message 56 displays a screen based on the withdrawal message 56 and notifies the user of the terminal 1 of the content of the withdrawal message 56. Thereby, the users of the request source terminal 11 and each request notification terminal 12 can know the person who withdraws the acceptance response 53 among the business persons who accepted the work request 51. When the acceptance response 53 is withdrawn, the acceptance response 53 (acceptance that has not been withdrawn) that is valid at the time when the worker is determined (for example, after a predetermined period of time has elapsed since the acceptance of the work request 51). The user of the terminal 1 that has issued the response 53) becomes a work execution candidate.

  The work performer is determined from among the work execution candidates. When the worker is determined, the server 2 transmits a message (hereinafter referred to as “confirmation message”) 57 notifying that the worker has been confirmed to the request source terminal 11 and the request notification terminal 12 (FIG. 2). (3)). The confirmation message 57 includes, for example, message identification information of a request message 52 related to the confirmation message (a request message 52 that is notified of the work request 51 that the work performer will confirm by the confirmation message 57), and the work execution. Business person identification information.

  As a method for determining one work performer from among the work execution candidates, for example, any of the following methods can be employed.

(A) Method based on the order in which the server 2 receives the acceptance response 53 When this method is adopted, the server 2 receives the acceptance response 53 every time it accepts the acceptance response 53 from the request notification terminal 12 ( Hereinafter, “reception order”) is stored. The server 2 can determine, for example, the user of the terminal 1 that has issued the acceptance response 53 with the earliest acceptance order among the work execution candidates, as the work performer.

(B) Method Based on Priority Set for Each Business Person When this method is adopted, a priority for determining a worker is preset for each business person. For example, the server 2 can determine a person who has the highest priority among work execution candidates as a work performer.

(C) Method based on the response message received from the terminal 1 used by the attending physician (C-1) Method prioritizing the attending physician In this method, the terminal 1 used by the attending physician (hereinafter referred to as “the attending physician terminal 14”) When the response message received from the server is the acceptance response 53, the server 2 transmits the response message (acceptance response 53) regardless of whether or not there is the terminal 1 that issued the acceptance response 53 other than the doctor terminal 14. The attending physician who uses the attending physician terminal 14 is determined as the operator. Therefore, when this method is adopted, the server 2 preferentially determines the attending physician as the performing operator when the attending physician is included in the candidate operations.

(C-2) Method Based on Instruction of Physician In this method, the response message received from the attending doctor terminal 14 is an instruction (hereinafter referred to as “designation instruction”) 58 for specifying a worker (FIG. 2 (3) )), The server 2 determines the business related person designated by the designation instruction as the work implementer. The designation instruction 58 includes, for example, message identification information of a request message 52 related to the designation instruction 58 (a request message 52 that has notified the work request 51 that a work performer is determined by the designation instruction 58), and This includes the business party identification information of the business party designated as the work implementer.

(D) Method Based on Instruction of User of Requester Terminal 11 In this method, when the server 2 receives the designation instruction 58 from the requestor terminal 11, the server 2 is designated by the accepted designation instruction 58. The person concerned with the business is determined to be the operator.

  FIG. 3 is a diagram illustrating a configuration example of the server 2.

  For example, the server 2 includes a control unit 21 and a storage unit 24. The control unit 21 is a device that controls processing performed by the server 2. The control unit 21 includes, for example, a request reception unit 22, a request notification unit 23, and an implementer determination unit 2D.

  In the storage unit 24, for example, a database 25 and message destination information 2C are stored. In the database 25, for example, request destination information 26, login information 27, patient person information 28, work flow information 29, transmission history information 2A, and message recording information 2B are accumulated. Details of each information 26-2C stored in the storage unit 24 will be described with reference to FIGS.

  FIG. 4 is a diagram illustrating an example of the request destination information 26.

  The request destination information 26 is information for managing the request destination terminal 13 (the terminal 1 installed in the place (request destination) where the requested work is performed). In the request destination information 26, for example, for each request destination indicated by the request destination name 261, each terminal name 262 of the terminal 1 installed at the request destination and the terminal 1 installed at the request destination. Each IP263 is included.

  The request destination name 261 is the name of the request destination. The terminal name 262 is the name of the terminal 1 installed at the request destination. IP263 is the IP address of the terminal 1 installed at the request destination. For example, the IP 263 is referred to when the request message 52 is transmitted to the terminal 1.

  As described above, the server 2 that has received the work request 51 uses the request message 52 for notifying the received work request 51 as a terminal 1 (request notification) used by a business person who may be a work performer. To the terminal 12). In this embodiment, the request notification terminal 12 is the attending doctor terminal 14 and the request destination terminal 13. The server 2 can determine the request destination terminal 13 that is the transmission destination of the request message 52 by referring to the request destination information 26. In the example of FIG. 4, when the request destination of the accepted work request 51 is “general radiographing room”, the server 2 includes the terminal 1 installed in the “general radiographing room” in addition to the attending physician terminal 14. (That is, “shooting room 1”, “shooting room 2”, “shooting room 3”,...) Is determined as the transmission destination of the request message 52.

  FIG. 5 is a diagram illustrating an example of the login person information 27.

  The logged-in person information 27 is information for managing business persons who are using the terminal 1 (logged in to the terminal 1). In the logged-in person information 27, for example, for each business-related person indicated by the login person ID 271, each terminal name 272 of the terminal 1 where the business-related person is logged in, and the terminal where the business-related person is logged in 1 each IP273.

  The login person ID 271 is an ID given to a business person who has logged into the terminal 1. The terminal name 272 is the name of the terminal 1 where the business related person is logged in. IP 273 is the IP address of the terminal 1 to which the business related person is logged in.

  The logged-in user information 27 is used to identify the user of the terminal 1. For example, when the server 2 receives the acceptance response 53 from the request notification terminal 12, the server 2 identifies the name of the terminal 1 that issued the acceptance response 53 and the user of the terminal 1 by referring to the logged-in user information 27. can do. In the example of FIG. 5, when the IP address of the terminal 1 that issued the acceptance response 53 is “10.51.XXX.ZZZ”, the server 2 sets the name of the terminal 1 that has issued the acceptance response 53 to “CT”. The user of the terminal 1 that issued the room 1 ”and the acceptance response 53 can be identified as the business related person to whom the ID“ 912ZZZZ ”is assigned. Further, the server 2 can also specify the names of business persons using the terminal 1 that issued the acceptance response 53 by referring to the patient person-in-charge information 28. The server 2 accepts the name of the terminal 1 that issued the acceptance response 53, the ID given to the business person, and the name of the business person specified by referring to the login person information 27 and the patient person information 28. It may be business person identification information included in the response message 54 (message for notifying the accepted acceptance response 53).

  FIG. 6 is a diagram illustrating an example of the patient staff information 28.

  The patient person in charge information 28 is information for managing a business person in charge of the patient (hereinafter, “person in charge”). The patient person in charge information 28 includes, for example, each person in charge ID 283 of the person in charge of the patient, each person in charge name 284 of the person in charge of the patient, for each patient indicated by the patient ID 281 and the patient name 282. Relevant information 285 for each person in charge of the patient and a priority value 286 for each person in charge of the patient are included.

  The patient ID 281 is an ID assigned to the patient. The patient name 282 is the name of the patient. The person in charge ID 283 is an ID given to the person in charge of the patient. The person-in-charge name 284 is the name of the person in charge of the patient. The relationship information 285 is information indicating the relationship between the patient and the person in charge. For example, if the person in charge is a doctor (primary physician) in charge of the patient, the relationship information 285 is “primary physician”. The priority value 286 is a priority value set for the person in charge of the patient. The priority is used when the above-described method (B) for determining the worker is employed.

  The patient contact information 28 is mainly used for identifying the patient's attending physician. As described above, the server 2 that has received the work request 51 transmits a request message 52 for notifying the accepted work request 51 to the request notification terminal 12 (the primary doctor terminal 14 and the request destination terminal 13). The server 2 can identify the attending doctor of the target patient in the received work request 51 by referring to the patient person in charge information 28, and the terminal 1 used by the identified attending doctor as the transmission destination of the request message 52. It can be determined as the attending physician terminal 14. In the example of FIG. 6, when the patient identification information (ID given to the patient) of the target patient included in the received work request 51 is “012XXXX”, the server 2 indicates that the patient ID 281 is “012XXXX”. The person in charge who is present and the relation information 185 is “the attending doctor” (that is, the business person assigned the ID “901YYYY”) can be identified as the attending doctor of the target patient in the accepted work request 51. Further, the server 2 refers to the logged-in person information 27 using the ID (“901YYYY”) assigned to the identified primary doctor as a key, so that the primary doctor terminal 14 that is the transmission destination of the request message 52 (used by the identified primary doctor) Terminal 1) can be determined. In the case of the example in FIG. 4, the identified attending physician (a business person to whom the ID “901YYYY” is assigned) logs in to two terminals (“exam room 1” and “east 1NS”). Therefore, in this case, the request message 52 is transmitted to these two doctor terminals 14.

  FIG. 7 is a diagram illustrating an example of the message destination information 2C.

  The message destination information 2C includes, for each request message 52, the request source terminal 11 related to the request message 52 (the terminal 1 that issued the work request 51 that is the basis of the request message 52) and the request notification terminal related to the request message 52. 12 (information on the terminal 1 that received the request message 52). In the message destination information 2C, for each request message 52 indicated by the message ID 2C1 and the branch number 2C2, for example, information on the request source terminal 11 and the request notification terminal 12 regarding the request message 52 (transmission / reception classification 2C4 and terminal name) 2C5, IP2C6, login user ID 2C7, login user name 2C8, relationship information 2C9, priority value 2CA, response 2CB, and confirmation 2CC).

  The message ID 2C1 is an ID given to the request message 52. The branch number 2C2 is a branch number given to the request message 52. In the present embodiment, the request message 52 is identified by a combination of message ID 2C1 and branch number 2C2. That is, the combination of the message ID 2C1 and the branch number 2C2 becomes the message identification information described above. The patient ID 2C3 is an ID given to the target patient in the request message 52.

  The transmission / reception category 2C4 is information indicating whether the terminal 1 is the request source terminal 11 or the request notification terminal 12. If the transmission / reception classification 2C4 is “transmission”, the terminal 1 is the terminal 1 that has issued the work request 51 (that is, the request source terminal 11). On the other hand, if the transmission / reception classification 2C4 is “reception”, the terminal 1 is the terminal 1 that has received the request message 52 (that is, the request notification terminal 12). The terminal name 2C5 is the name of the terminal 1. IP2C6 is the IP address of the terminal 1. The login person ID 2C7 is an ID given to a business person who uses the terminal 1. The login person name 2C8 is the name of a business person using the terminal 1. The relationship information 2C9 is information indicating the relationship between the target patient in the request message 52 and the business related person using the terminal 1. The priority value 2CA is a priority value set for a business person using the terminal 1. The response 2CB is an acceptance order of the acceptance response 53 when the acceptance response 53 is accepted from the terminal 1. In the example of FIG. 7, the response 2CB is that the server 2 has received the acceptance response 53 from the “photographing room 1” and “photographing room 3”, and the acceptance response 53 received from the “photographing room 1” is first. Is shown. The confirmed 2CC is information indicating the terminal 1 (hereinafter referred to as “executor terminal 15”) used by the finally determined operator. A terminal 1 (the “photographing room 3” in the example of FIG. 7) for which the confirmation 2CC is “1” indicates the terminal 1 used by the determined operator.

  For example, the server 2 uses the message transmission destination information 2C to determine the transmission destinations of the acceptance response message 54, the withdrawal message 56, and the confirmation message 57. For example, in the example of FIG. 7, when the acceptance response 53 is received from the “photographing room 1”, the server 2 sends the request message 52 (message ID 2C1 of “1234XXXXXX” and “012XXXX” related to the acceptance response 53). To the request source terminal 11 (“reception 1”) and the request notification terminal 12 (“imaging room 1”, “imaging room 2”, “imaging room 3”, and “examination room 1”) regarding the branch number 2C2) An acceptance response message 54 is transmitted. Note that the server 2 may not transmit the acceptance response message 54 to the terminal 1 that has issued the acceptance response (“shooting room 1”).

  In addition, the server 2 can use the message transmission destination information 2C to determine the worker. For example, when the above-described method (A) for determining the worker is adopted, the server 2 refers to the response 2CB (acceptance order) in the message destination information 2C, and the acceptance order is the earliest (the value is the highest). The user of the small terminal 1 can be determined as the operator. Further, for example, when the method (B) for determining the worker who has been described above is adopted, the server 2 refers to the priority value 2CA in the message destination information 2C, and has the highest priority (priority level). The user of the terminal 1 having the smallest value can be determined as the operator.

  FIG. 8 is a diagram illustrating an example of the work flow information 29.

  The workflow information 29 is information that defines a workflow that is a combination of a plurality of tasks. The work flow information 29 includes, for example, information (branch number 292 and request destination name 293) regarding each work constituting the work flow for each work flow indicated by the work flow name 291.

  The branch number 292 is a branch number assigned to each work constituting the work flow. The branch number indicates the order in which work is performed. In the present embodiment, when the workflow defined in the workflow information 29 is executed, among the individual tasks constituting the workflow, the tasks are performed in order from the smallest branch number value. Done. The request destination name 293 is the name of the request destination.

  FIG. 9 is a diagram illustrating an example of the message recording information 2B.

  The message record information 2B contains, for each request message 52, the actions performed in connection with the request message 52 (accepting the work request 51, accepting the permission response 53, accepting the withdrawal instruction 55, and confirming the operator). This is information for managing information related to each. The message recording information 2B is used as a log for referring to the processing result after the processing is performed, for example. In the message record information 2B, for each request message 52 indicated by the message ID 2B1 and branch number 2B4, for example, information (action name 2B5, date and time 2B7, terminal name 2B8, IP2B9 Login user ID 2BA, login user name 2BB, and comment 2BC).

  The message ID 2C1 is an ID given to the request message 52. The branch number 2C2 is a branch number given to the request message 52. The patient ID 2B2 is an ID given to the target patient in the request message 52.

  The action name 2B5 is information indicating the action. “Request” indicates that the server 2 has accepted the work request 51. “Accept” indicates that the server 2 has accepted the acceptance response 53. “Withdrawal” indicates that the server 2 has accepted the withdrawal instruction 55. “Confirmed” indicates that the worker has been confirmed. The date 2B7 is the date when the action was performed. The terminal name 2B8 is the name of the terminal 1 related to the action. When the action is acceptance of the work request 51, the permission response 53, or the withdrawal instruction 55, the terminal name 2B8 is the name of the terminal 1 that issued the work request 51, the permission response 53, or the withdrawal instruction 55. When the action is confirmation of the worker, the terminal name 2B8 is the name of the terminal 1 used by the confirmed worker. IP2B9 is the IP address of the terminal 1 indicated by the terminal name 2B8. The login user ID 2BA is an ID given to the user of the terminal 1 indicated by the terminal name 2B8. The login user name 2BB is the name of the user of the terminal 1 indicated by the terminal name 2B8. The comment 2BC is text (for example, text that can be input in an area 717 of the screen 7 to be described later) notified to the server 2 when the business person who performed the action performs the action.

  FIG. 10 is a diagram illustrating an example of the transmission history information 2A.

  The transmission history information 2A is information generated by extracting a part of information of the message record information 2B (that is, information regarding both actions of accepting the work request 51 and confirming the work performer). Since each information element of the transmission history information 2A is substantially the same as that of the message recording information 2B, description thereof is omitted.

  The above is the description of the configuration of the computer system according to the present embodiment.

  Hereinafter, with reference to FIG. 11 to FIG. 25, the medical service message processing performed in the computer system according to the present embodiment will be described. 11 to 16 are diagrams showing the flow of processing, and FIGS. 17 to 25 are diagrams showing an example of the screen 7 displayed on the terminal 1.

  FIG. 11 is a diagram illustrating a processing flow when the server 2 that has received the work request 51 transmits the request message 52.

  First, a business-related person logs in to the terminal 1 (request source terminal 11) (FIG. 11-1). From then on, the certain business-related person (the business-related person who has logged in to the request source terminal 11) becomes a user of the request destination terminal 11.

  The request source terminal 11 notifies the control unit 21 of the server 2 that login has been performed (FIG. 11-1.1). This notification includes the ID assigned to the business person who has logged into the request source terminal 11.

  The control unit 21 assigns the login name ID 271 corresponding to the terminal name 272 of the request source terminal 11 and the IP 273 in the login user information 17 to the business related person who logged in to the request destination terminal 11 notified from the request source terminal 11. The login is registered by using the obtained ID (FIG. 11-1.1.1).

  After that, the request source terminal 11 displays a screen 71 displayed when requesting the work as shown in FIG. The screen 71 includes, for example, an area 711 for displaying a title, an area 712 for displaying progress information for the work request 51 (for example, information indicating which terminal 1 has received an acceptance response), and a target patient An area 713 for designating the name of the patient, an area 714 for designating the ID given to the target patient, an area 715 for designating the requested work content, an area 716 for designating the request destination, and an area 712 An area 717 for inputting an arbitrary text to be displayed, a “Send” button 718 for executing a work request, and a “Close” button 719 for canceling the work request are provided. Note that, in the screen 7 after FIG. 18, the same reference numerals as those in FIG. 17 are assigned to substantially the same regions and buttons as those in FIG. Descriptions of substantially the same regions and buttons as in FIG. 17 will be omitted unless necessary.

  The user of the request source terminal 11 sets the name of the target patient and the ID assigned to the target patient in the area 713 and the area 714 on the screen 71 (FIG. 11-2).

  Further, the user of the request source terminal 11 sets the requested work content and the request destination in the area 715 and the area 716 on the screen 71 (FIG. 11-3).

  Next, the user of the request source terminal 11 presses the “Send” button 718 on the screen 71 to execute a work request (FIG. 11-4).

  The request source terminal 11 that has received the execution of the work request issues a work request 51 to the control unit 21 of the server 2 (FIG. 11-4.1). The work request 51 includes information set on the screen 71 (the name of the target patient, the ID given to the target patient, the details of the requested work, the request destination, etc.).

  The control unit 21 (request reception unit 22) of the server 2 that has received the work request 51 refers to the request destination included in the work request 51 and the request destination information 26 stored in the storage unit 24, and requests message 52. The request destination terminal 13 to be the transmission destination is determined. The method of determining the request destination terminal 13 is as described in FIG. The control unit 21 acquires the IP address of the request destination terminal 13 from the request destination information 26 (FIG. 11-4.1.1).

  Next, the control unit 21 (request receiving unit 22) includes the name of the target patient included in the work request 51 or the ID assigned to the target patient, the patient person in charge information 28 stored in the storage unit 24, and the login person. With reference to the information 27, the attending doctor terminal 14 as the transmission destination of the request message 52 is determined. The method of determining the attending doctor terminal 14 is as described in FIG. The control unit 21 acquires the IP address of the attending doctor terminal 14 from the logged-in person information 27 (FIG. 11-4.1.2).

  Thereafter, the control unit 21 (request notification unit 23) transmits a request message 52 to each of the request notification terminals 12 (request destination terminal 13 and attending physician terminal 14) (FIG. 11-4.1.3). In the request message 52, in addition to the same information as the information included in the work request 51 (name of the target patient, ID given to the target patient, requested work content, request destination, etc.), the message identification of the request message 52 Information (ID and branch number assigned to the request message 52) is included.

  The request notification terminal 12 that has received the request message 52 displays a screen 72 as shown in FIG. 18 (FIG. 11.4.1.3.1). In the area 711, the area 713, the area 714, the area 715, and the area 716 on the screen 72, the same information as that displayed on the screen 71 of FIG. Further, in the area 712 on the screen 72, the text input in the area 717 on the screen 71 in FIG. 17 is displayed. The screen 72 is provided with an “Accept” button 721 for accepting the requested work.

  Thereafter, the control unit 21 of the server 2 updates the message destination information 2C stored in the storage unit 24 (FIG. 11-4.1.4). Information related to each of the request source terminal 11 and the request notification terminal 12 related to the request message 52 transmitted in FIG. 11-4.1.3 is added to the message destination information 2C.

  FIG. 12 is a diagram showing a processing flow when the server 2 has not received the acceptance response 53 for the request message 52 at all.

  When the acceptance response 53 is not received within a certain time (FIG. 12-1), the control unit 21 of the server 2 uses the request source terminal 11 and the request notification terminal from the message destination information 2C stored in the storage unit 24. 12 IP addresses are acquired (FIG. 12-2).

  Thereafter, the control unit 21 notifies each of the request notification terminals 12 to cancel the request message 52 (FIG. 12-3).

  Upon receiving the notification to cancel the request message 52, the request notification terminal 12 deletes the screen (that is, the screen 72 in FIG. 18) displayed when the request message 52 is received (FIG. 12-3.1).

  Further, the control unit 21 of the server 2 notifies the request source terminal 11 that the acceptance response has not been received (FIG. 12-4).

  Upon receiving the notification that the acceptance response has not been received, the request source terminal 11 accepts the requested work in, for example, the area 712 on the screen displayed when the work is requested (that is, the screen 71 in FIG. 17). A text indicating that there has not been displayed is displayed (FIGS. 12-4.1).

  FIG. 13 is a diagram showing a processing flow when the server 2 receives the acceptance response 53 from the request destination terminal 13.

  First, the user of one of the request destination terminals 13 presses the “Accept” button 721 on the screen 72 of FIG. 18 displayed by the request destination terminal 13 to accept the requested work (FIG. 13). -1).

  Upon receiving acceptance of the requested work, the request destination terminal 13 issues an acceptance response 53 to the control unit 21 of the server 2 (FIG. 13-1.1). The acceptance response 53 includes message identification information of the request message 52 related to the acceptance response 53.

  Upon receiving the acceptance response 53, the control unit 21 of the server 2 adds information indicating that the acceptance response 53 has been accepted to the message destination information 2C and the message recording information 2B stored in the storage unit 24 (FIG. 13). -1.1.1). That is, the acceptance order of the acceptance response 53 is added to the response 2CB of the request destination terminal 13 that issued the acceptance response 53 in the message destination information 2C. In addition, information indicating that the acceptance response 53 has been received from the request destination terminal 13 is added to the location corresponding to the related request message 51 in the message record information 2B.

  Thereafter, the control unit 21 acquires the IP addresses of the request source terminal 11 and the request notification terminal 12 from the message destination information 2C stored in the storage unit 24 (FIG. 13-1.1.2).

  Thereafter, the control unit 21 transmits an acceptance response message 54 for notifying the accepted acceptance response 53 to each of the request source terminal 11 and the request notification terminal 12 (request destination terminal 13 and the attending physician terminal 14) ( Figure 13-1.1.3, 1.1.4, 1.1.5). The acceptance response message 54 includes message identification information included in the acceptance response 53 and business person identification information of the user of the requested terminal 13 that issued the acceptance response 53 (assigned ID and name, and the terminal 1 to be used). Name).

  In the request source terminal 11 that has received the acceptance response message 54, for example, in the area 712 on the screen displayed when the work is requested (that is, the screen 71 in FIG. 17), the ID or name included in the acceptance response message 54 is displayed. A text indicating that the requested business person has accepted the requested work is displayed (FIG. 13-1-1.4.1).

  In the request notification terminal 13 that has received the acceptance response message 54, for example, the acceptance response message 54 includes an area 712 in the screen displayed when the request message 52 is received (that is, the screen 72 in FIG. 18). A text indicating that the business person indicated by the ID or name has accepted the requested work is displayed (FIGS. 13.1.1.3.1 and 1.1.5.1).

  As described above, the user of the terminal 1 that has issued the acceptance response 53 can withdraw the acceptance response 53. When the acceptance response 53 is withdrawn, a screen 73 as shown in FIG. 19 is used. The screen 73 is provided with a “Cancel” button 731 for withdrawing the acceptance response 53. The user of the terminal 1 that has issued the acceptance response 53 inputs, for example, text indicating that the acceptance response 53 is to be withdrawn into an area 717 on the screen 73 and presses the “Cancel” button 731 to instruct the server 2 to withdraw. 55 is transmitted. Thereby, the acceptance response 53 is withdrawn.

  When the acceptance response 53 is withdrawn, the control unit 21 of the server 2 adds information indicating that the acceptance response 53 has been withdrawn to the message destination information 2C and the message recording information 2B stored in the storage unit 24. to add. That is, the value of the response 2CB of the terminal 1 that issued the withdrawal instruction 55 in the message destination information 2C is deleted. Further, information indicating that the terminal 1 that has issued the withdrawal instruction 53 has withdrawn the acceptance response 53 is added to the location corresponding to the related request message 51 in the message record information 2B. Thereafter, the withdrawal message 56 is transmitted to the request source terminal 11 and the request notification terminal 12.

  FIG. 14 is a diagram showing a processing flow when the server 2 receives the acceptance response 53 from the attending doctor terminal 14.

  First, the attending physician presses the “Accept” button 721 on the screen 72 of FIG. 18 displayed on the attending physician terminal 14 to accept the requested work (FIG. 14-1).

  The attending physician terminal 14 that has accepted acceptance of the requested work issues an acceptance response 53 to the control unit 21 of the server 2 (FIG. 14-1.1). The acceptance response 53 includes message identification information of the request message 52 related to the acceptance response 53.

  Upon receiving the acceptance response 53, the control unit 21 of the server 2 adds information indicating that the acceptance response 53 has been accepted to the message destination information 2C and the message recording information 2B stored in the storage unit 24 (FIG. 14). -1.1.1). That is, the acceptance order of the acceptance response 53 is added to the response 2CB of the attending doctor terminal 14 that has issued the acceptance response 53 in the message destination information 2C. In addition, information indicating that the acceptance response 53 has been received from the attending physician terminal 14 is added to the location corresponding to the related request message 51 in the message record information 2B.

  When the attending physician accepts the work request as in the case of FIG. 14, the control unit 21 (executor determination unit 2D) of the server 2 is based on the above-described method (C-1) of determining the operation operator. Then, the attending physician is determined as the operator.

  Then, the control unit 21 (practitioner determination unit 2D) determines the user (primary physician) of the primary doctor terminal 14 to be the operator of the operation in the message destination information 2C and the message record information 2B stored in the storage unit 24. Information indicating this is added (FIGS. 14-1.1.2). That is, the confirmed 2CC of the attending doctor terminal 14 in the message destination information 2C is set to “1”. In addition, information indicating that the user (primary physician) of the attending physician terminal 14 has been determined as the operator is added to the location corresponding to the related request message 51 in the message record information 2B.

  Thereafter, the control unit 21 acquires the IP addresses of the request source terminal 11 and the request notification terminal 12 from the message destination information 2C stored in the storage unit 24 (FIG. 14-1.1.3).

  Thereafter, the control unit 21 transmits a confirmation message 57 notifying that the worker has been confirmed to the request source terminal 11 and the request notification terminal 12 (FIGS. 14-1.1.4, 1.1.5, 1.1.6). The confirmation message 57 includes message identification information of the request message 52 related to the confirmation message 57 and business person identification information (assigned ID, name, etc.) of the operator (primary physician).

  In the request source terminal 11 and the request destination terminal 13 that have received the confirmation message 57, a screen 75 as shown in FIG. 21 is displayed (FIGS. 14.1.1.4.1 and 1.1.5.1). In an area 712 on the screen 75, text indicating that the worker has been confirmed is displayed.

  In addition, on the attending doctor terminal 14 (that is, the practitioner terminal 15) that has received the confirmation message 57, a screen 76 as shown in FIG. Similarly to the screen 75 in FIG. 21, text indicating that the worker has been confirmed is displayed in an area 712 on the screen 76. The screen 76 is provided with a “Next” button 761 for requesting the next operation.

  FIG. 15 is a diagram showing the flow of processing when the attending physician designates a worker.

  When the attending physician (or the request source terminal 11) designates a worker, a screen 74 as shown in FIG. 20 is used. In the area 716 on the screen 74, the name of the user (practicable candidate) of the request destination terminal 13 that issued the acceptance response 53 is displayed, and one of the practicable candidates can be selected. A radio button 742 is provided. The screen 74 is provided with a “Choice” button 741 for designating a worker.

  When the attending physician selects one of the feasible candidates (the business related person to be determined as the work performer) using the radio button 741, and presses the “Choice” button 741 (FIG. 15-1). The designation instruction 58 is issued from the attending physician terminal 14 to the control unit 21 of the server 2 (FIG. 15-1.1). The designation instruction 58 includes message identification information of the request message 52 related to the designation instruction 58, and business person identification information (assigned ID, name, etc.) of the business person designated as the operator. .

  The control unit 21 of the server 2 that has received the designation instruction adds information indicating that the designation instruction 58 has been accepted to the message recording information 2B stored in the storage unit 24 (FIG. 15-1.1.1). . That is, information indicating that the designation instruction 58 has been received from the attending physician terminal 14 is added to the location corresponding to the related request message 51 in the message record information 2B.

  As in the case of FIG. 15, when the designation instruction 58 is received from the attending physician terminal 14 (or the request source terminal 11), the control unit 21 (executor determination unit 2D) of the server 2 determines the above-described operator. On the basis of the method (C-2), the business related person designated by the designation instruction 58 is determined as the work implementer.

  Then, the control unit 21 (practitioner determination unit 2D) determines the business related person designated by the designation instruction 58 in the message transmission destination information 2C and the message recording information 2B stored in the storage unit 24 as the work practitioner. Information indicating that this has been done is added (FIG. 15-1.1.2). That is, the confirmed 2CC of the terminal 1 used by the business related person designated by the designation instruction 58 in the message destination information 2C is set to “1”. In addition, information indicating that the business-related person designated by the designation instruction 58 is determined as the work performer is added to the location corresponding to the related request message 51 in the message record information 2B.

  Thereafter, the control unit 21 acquires the IP addresses of the request source terminal 11 and the request notification terminal 12 from the message destination information 2C stored in the storage unit 24 (FIG. 15-1.1.3).

  Thereafter, the control unit 21 transmits a confirmation message 57 notifying that the worker has been confirmed to the request source terminal 11 and the request notification terminal 12 (FIGS. 15-1.1.4, 1.1.5, 1.1.6). The confirmation message 57 includes message identification information of the request message 52 related to the confirmation message 57 and business person identification information (assigned ID, name, etc.) of the worker.

  On the request notification terminal 12 other than the request source terminal 11 and the implementer terminal 15 that have received the confirmation message 57, a screen 75 as shown in FIG. 21 is displayed (FIGS. 15-1.1.5.1, 1.1). .6.1). In an area 712 on the screen 75, text indicating that the worker has been confirmed is displayed.

  In addition, the practitioner terminal 15 that has received the confirmation message 57 displays a screen 76 as shown in FIG. 22 (FIG. 14.1.1.4.1). Similarly to the screen 75 in FIG. 21, text indicating that the worker has been confirmed is displayed in an area 712 on the screen 76. The screen 76 is provided with a “Next” button 761 for requesting the next operation.

  FIG. 16 is a diagram showing the flow of processing when the work flow defined in the work flow information 29 is executed.

  First, the request source terminal 11 acquires the work flow information 29 from the storage unit 24 of the server 2 (FIG. 16-1).

  Next, the user of the request source terminal 11 selects one of the workflows defined in the workflow information 29 (the one to be executed) (FIG. 16-2). Hereinafter, the workflow selected in FIG. 16B is referred to as a “target workflow”.

  Then, the user of the request source terminal 11 issues a work request for the work having the branch number “1” among the work constituting the target work flow (FIG. 16C).

  The request source terminal 11 that has received the execution of the work request issues a work request 51 to the control unit 21 of the server 2 (FIG. 16-3.1).

  The control unit 21 of the server 2 that has received the work request 51 transmits a request message 52 to each of the request notification terminals 12 (request destination terminal A and request destination terminal B in the example of FIG. 16) (FIG. 16-). 3.1.1, 3.1.2).

  Thereafter, the control unit 21 of the server 2 receives the acceptance response 53 from the request destination terminal A (FIG. 16-4).

  Upon receiving the acceptance response 53, the control unit 21 of the server 2 transmits an acceptance response message 54 to each of the request source terminal 11 and the request destination terminal B (FIGS. 16-4.1, 4.2).

  Thereafter, the user of the request destination terminal A is determined to be the operator.

  The control unit 21 of the server 2 transmits a confirmation message 57 to the request source terminal 11 and the request notification terminal 12 (request destination terminal A and request destination terminal B) (FIGS. 16-5, 6 and 7).

  The request destination terminal A that has received the confirmation message 57 displays a screen 77 as shown in FIG. 23 (FIG. 16-7.1). In an area 712 on the screen 77, text indicating that the user of the requested terminal A has been determined to be the work implementer is displayed. The screen 77 sets the name of the target patient, the ID given to the target patient, the requested work content, and the request destination in each of the area 713, the area 714, the area 715, and the area 716, as in the screen 71 of FIG. A work request can be executed by pressing a “Send” button 718.

  The request destination terminal A that has received the confirmation message 57 obtains the work flow information 29 from the storage unit 24 of the server 2 (FIG. 16-7.2).

  Then, the user of the request source terminal A requests the work for the work having the branch number “2” among the work constituting the target work flow (FIG. 16-8).

  The request destination terminal A that has received the execution of the work request (the request source terminal 11 after issuing the work request 51) issues the work request 51 to the control unit 21 of the server 2 (FIG. 16-8.1). ). Processing similar to that shown in FIGS. 16-3.1.1 to 16-7.1 is performed on the work request 51.

  The processing as described above is repeatedly performed in accordance with the order indicated by the branch numbers for all the tasks constituting the target workflow.

  Note that the requester terminal 11 displays a screen 78 as shown in FIG. 24 in order to grasp the progress of the work flow. In an area 712 on the screen 78, text indicating the progress of the work flow (for example, which terminal 1 has issued the work request 51 for the work that has been performed and which user of the terminal 1 has become the work performer, etc. Is displayed).

  In addition, by displaying a screen 79 as shown in FIG. 25 on the attending doctor terminal 14, the attending doctor can view information related to work performed when he / she has not logged in to the attending doctor terminal 14. In an area 712 on the screen 79, text indicating information related to work performed when the attending doctor has not logged in to the attending doctor terminal 14 (for example, from which terminal 1 the work request 51 is issued for the work that has been performed. , A text indicating which terminal 1 user has become a worker, etc.).

  The above-described embodiments of the present invention are examples for explaining the present invention, and are not intended to limit the scope of the present invention only to those embodiments. The present invention can be implemented in various other modes without departing from the gist thereof.

It is a figure which shows the structural example of the computer system which concerns on this embodiment. It is a figure explaining the outline | summary of the process which a server performs. It is a figure which shows the structural example of a server. It is a figure which shows an example of request destination information. It is a figure which shows an example of login person information. It is a figure which shows an example of patient person in charge information. It is a figure which shows an example of message delivery destination information. It is a figure which shows an example of work flow information. It is a figure which shows an example of message recording information. It is a figure which shows an example of transmission / reception log information. It is a figure which shows the flow of a process when the server which received the work request transmits a request message. It is a figure which shows the flow of a process when a server does not receive the acceptance response with respect to a request message at all. It is a figure which shows the flow of a process when a server receives an acceptance response from a request destination terminal. It is a figure which shows the flow of a process when a server receives an acceptance response from an attending doctor terminal. It is a figure which shows the flow of a process when the attending physician designates the operator. It is a figure which shows the flow of a process when the work flow defined in work flow information is performed. It is a figure which shows an example of the screen displayed when requesting work. It is a figure which shows an example of the screen displayed when a request message is received. It is a figure which shows an example of the screen displayed when withdrawing an acceptance response. It is a figure which shows an example of the screen displayed when specifying a worker. It is a figure which shows an example of the screen displayed when a confirmation message is received in terminals other than a implementer terminal. It is a figure which shows an example of the screen displayed when a confirmation message is received in a implementer terminal. It is a figure which shows an example of the screen displayed when the work after the 2nd is started in a work flow. It is a figure which shows an example of the screen displayed in order to grasp | ascertain progress of a work flow in a requestor terminal. It is a figure which shows an example of the screen displayed in order to browse the information regarding the work implemented when the attending physician was not logged in to the attending physician terminal.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Terminal, 2 ... Server, 3 ... Communication network, 21 ... Control part, 22 ... Request reception part, 23 ... Request notification part 23, 24 ... Memory | storage part, 25 ... Database, 26 ... Request destination information, 27 ... Login person Information, 28 ... Patient person information, 29 ... Workflow information, 2A ... Transmission history information, 2B ... Message record information, 2C ... Message destination information, 2D ... Executor determination unit

Claims (7)

A patient database for associating and storing patient identification information and doctor identification information;
Request accepting means for accepting a request including patient identification information;
Physicians corresponding a request message based on the request accepted the request receiving means, the physician identification information associated with the patient identification information included in the request is accepted the request receiving means in a plurality of request destination terminal and the patient database A request transmitting means for transmitting to the terminal;
Response accepting means for accepting a response message to the request message from the doctor terminal and one or more request destination terminals of the plurality of request destination terminals ;
Notification means for notifying the doctor terminal of the identification information of the user related to the request destination terminal that has returned an acceptance message indicating acceptance of the request as the response message;
When the response message received from the doctor terminal by the response accepting unit is an acceptance message, the doctor terminal is selected, and the response receiving unit notifies the doctor terminal of the response message received from the doctor terminal. Selection means for selecting one request destination terminal based on the identification information of the user related to the request destination terminal when the identification information of the user is included;
Confirmation sending means for sending a request confirmation message to the doctor terminal or the one request destination terminal selected by the selection means;
A medical service message processing apparatus comprising:   The request transmission unit transmits the request message received by the request reception unit only to a request destination terminal that is logged in to the medical service message processing device among the plurality of request destination terminals.
  The medical service message processing apparatus according to claim 1. A request destination database for storing the request destination in association with one or more request destination terminals at the request destination;
The request accepting means accepts designation of a request destination,
The request transmitting means selects and transmits one or more request destination terminals associated with the specified request destination in the request destination database;
The medical work message processing apparatus according to claim 1 or 2. A flow database for storing a plurality of request destinations in order;
The request transmission means, after the work related to the first request destination among the plurality of request destinations is completed, in accordance with the order of the request destinations stored in the flow database, Select and send one or more requesting terminals associated with the second requesting party,
The medical operation message processing apparatus according to claim 3 . The selection means includes
One of the request destination terminal and the doctor terminal that returned the acceptance message after accepting an acceptance message for the request message from one or more request destination terminals of the doctor terminal and the plurality of request destination terminals. When accepting the withdrawal instruction of the acceptance message from the request destination terminal that returned the acceptance message and the doctor terminal, any one terminal other than the terminal that issued the withdrawal instruction is selected.
The medical work message processing apparatus according to claim 1 or 2 . A medical work message processing method by a computer, wherein the computer includes a patient database that stores patient identification information and doctor identification information in association with each other.
Accept requests that include patient identification information,
A request message based on the received request is transmitted to a plurality of request destination terminals and a doctor terminal corresponding to doctor identification information associated with patient identification information included in the received request in the patient database ,
Receiving a response message to the request message from one or more request destination terminals of the doctor terminal and the plurality of request destination terminals;
Notifying the doctor terminal of the identification information of the user related to the request destination terminal that has returned the acceptance message indicating acceptance of the request as the response message,
When the response message received from the doctor terminal is an acceptance message, the doctor terminal is selected, and the response message received from the doctor terminal includes the identification information of the user related to the requested terminal notified to the doctor terminal If there is, select one request destination terminal based on the identification information of the user related to the request destination terminal,
A medical work message processing method for transmitting a request confirmation message to the selected doctor terminal or the one request destination terminal . A computer program for performing medical service message processing, when executed on a computer including a patient database that stores patient identification information and doctor identification information in association with each other, the computer program
Accept requests that include patient identification information,
Sends a request message based on the request of the accepted plurality of request destination terminal and the doctor terminal corresponding physician identification information associated with the patient identification information included the in the request accepted in the patient database, to,
Receiving a response message to the request message from one or more request destination terminals of the doctor terminal and the plurality of request destination terminals;
Notifying the doctor terminal of the identification information of the user related to the request destination terminal that has returned the acceptance message indicating acceptance of the request as the response message,
When the response message received from the doctor terminal is an acceptance message, the doctor terminal is selected, and the response message received from the doctor terminal includes the identification information of the user related to the requested terminal notified to the doctor terminal If there is, select one request destination terminal based on the identification information of the user related to the request destination terminal,
A computer program for performing medical service message processing for transmitting a request confirmation message to the selected doctor terminal or the one request destination terminal .

Images