JP6349155B2 - Cooperation destination search support method and system for medical / nursing care related facilities - Google Patents

Description

  The present invention relates to a cooperation destination search support method and system for medical / nursing related facilities, and more specifically, any medical related facility or nursing related facility cooperates with the facility using a cooperation request timeline. The present invention relates to a cooperation / search support method and system for medical / care-related facilities, which supports other medical-related facilities, care-related facilities, and other facilities (for example, pharmaceutical companies and research institutions) so that they can be easily searched.

  For example, (a) Clinic (clinic office) searches for a hospital that accepts hospitalization of patients diagnosed or treated at its own facility. When searching for clinics, home-visit nursing stations, group homes, nursing homes, etc. that are in charge of post-discharge care for patients discharged from their own facilities, (c) the clinic is in charge of home-visit nursing When searching for other clinics or hospitals that will take care of the patient's visit on behalf of the doctor at the clinic, (d) When searching for a nursing facility that accepts the patient's short stay at their facility, (e) Your facility Search for pharmaceutical companies and research institutes that have detailed information about new drugs that are useful in treating patients. However, the present invention is not limited to these. Needless to say, the present invention can be applied to any external facility to which medical-related facilities and care-related facilities can cooperate in some form.

  Medical facilities include clinics, clinics (small-scale medical facilities), hospitals (medium- and large-scale medical facilities), home-visit nursing stations, etc. All of these medical-related facilities have specialized fields. Many different professions belong and work together on patient treatment, testing, nursing, etc. In recent years, there are more and more cases where these medical facilities have to cooperate with each other to treat patients due to the progress of medical specialization. Specifically, depending on the type of illness found by diagnosis, the severity of the medical condition, the degree of recovery, etc., other medical facilities may be in charge of treatment of patients at your facility, or you will receive home-visit nursing There are frequent cases in which doctors of other medical facilities are visited for patients who are present, and the need for cooperation between such medical facilities is increasing.

  In recent years, with the progress of an aging society, many nursing care-related facilities have been established, and the number of medical workers who reside in the facility or who diagnose and treat patients in the facility is increasing. For this reason, not only cooperation between medical related facilities but cooperation between medical related facilities and care related facilities is also increasing. Furthermore, in order to obtain new drug information for patients at their own facilities, cooperation with facilities other than medical facilities and nursing care facilities (for example, pharmaceutical companies and research institutes) has begun.

  Under such circumstances, there is a strong demand for the early solution of the following problems that occur in cooperation with these medical / care-related facilities.

  For example, if a clinic wishes to have its patients admitted to such a well-equipped hospital in order to receive more advanced testing and treatment, It is necessary to find out immediately. In this case, in the past, we looked for hospitals that could possibly be accepted by the clinic individually, and by telephone or fax, each patient's medical information, disease information, etc. were accepted and accepted. It is common to use the method of percussion. However, with this method, it is necessary to keep in touch several times before getting a “accepted (accepted)” response from the hospital at the consultation destination. The problem is that it takes time and effort.

  In addition, if the “acceptance (acceptance)” response is not obtained from the hospital at the consultation destination, the same operation is repeated for another hospital until an “acceptance (acceptance)” response is obtained. As a result, there is a problem that the burden is further increased for the clinic where the consultation is made.

  Even if a hospital wants to discharge a patient at its own facility, it is necessary to find a clinic or group home or other medical-related facility or care-related facility that will take care of the patient after discharge. There is a problem similar to the above case of searching for a hospital with an empty bed.

  Therefore, a system for solving such a problem caused by cooperation between medical and nursing care related facilities has been developed. One example is the “bed management system” described in Japanese Patent Application Laid-Open No. 2002-032489.

The “bed management system” described in Patent Document 1 is
A server that is installed in an information service organization and stores a hospital database based on patient information such as hospital information about hospitals and doctors, etc.
It consists of a terminal that is installed in each hospital etc. and can be connected to the server via the Internet.
Vacant floor information calculated based on the hospital database stored in the server is provided to each hospital via the terminal.

  The hospital database includes the hospital identification code, hospital name, type, number of beds, facilities, number of doctors and nurses, hospital departments, etc., hospital entry / exit status of each ward, hospital entry / exit for each patient And patient information related to the history of hospital transfers and the like. The hospital database is managed by an information service organization having a server. At each hospital, when data is added or changed, or when a patient enters or exits or is transferred, new data is sent to the server using the terminal, and the information stored in the hospital database is updated accordingly. .

  Of the information stored in the hospital database, publicly available information excluding privacy information and the like is stored in the public database. Information stored in the public database can be viewed from the outside. Therefore, when a hospital wants to transfer a patient who has been admitted to another hospital, it has facilities that can perform examinations, operations, etc. of the patient by searching the public database and has an empty bed ( It is possible to find a hospital having an empty bed. That is, if necessary, it is possible to quickly know the acceptance posture of other hospitals.

  As another related technique, there is a “patient management support system” described in Patent Document 2 (Japanese Patent Laid-Open No. 2012-146249).

The “bed management support system” of Patent Document 2 is
A bed management support system for supporting the management of a plurality of beds in a hospital,
Evaluation results for a plurality of attributes or a plurality of needs regarding a patient who is admitted to the hospital and receives medical services in any of the plurality of beds, and bed conditions that should be possessed by a bed suitable for the patient's medical services, Bed condition determination information storage means for storing bed condition determination information configured in association with each other;
When an evaluation result for a plurality of attributes or a plurality of needs of the patient is specified by a predetermined method, a bed condition corresponding to the specified evaluation result is stored in the bed condition determination information storage unit. It is characterized by comprising a bed condition specifying means for specifying with reference to the bed condition determination information.

  `` Bed management '' means the bed provision method of what kind of bed to provide for inpatients, specifically securing and providing bed for new inpatients, For that purpose, discharge of hospital patients or adjustment of hospital transfer, and movement of beds within and between wards.

  In the “bed management support system” described in Patent Literature 2, since bed conditions corresponding to evaluation results for a plurality of attributes or a plurality of needs of a patient are specified, a bed that meets a plurality of attributes or a plurality of needs of a patient. It becomes possible to grasp conditions accurately and promptly, and it is possible to maintain and improve the safety and quality of medical services for patients.

JP 2002-032489 A JP 2012-146249 A

  However, in the “patient management system” of Patent Document 1 described above, the work of storing patient information such as hospital information and hospital entry / exit history regarding equipment and doctors in the hospital database used in the system is heavy, The task of reflecting the frequently-changed information in the hospital database one by one has a disadvantage that it is more burdensome. In other words, the hospital database is convenient and effective, but its maintenance work is difficult.

  In the "bed management support system" described in Patent Document 2 described above, the bed condition determination information storage means (storage unit) is suitable for evaluation results for a plurality of attributes or a plurality of needs related to a patient and the patient's medical service. Since the “bed condition determination information” configured to correlate with the bed conditions to be held by the bed is stored, the bed condition determination information storage unit (memory) is stored in the same manner as the “bed management system” of Patent Document 1 described above. Part) maintenance work is required.

  In the first place, the “bed management support system” of Patent Document 2 is intended to provide hospitalized patients more effectively and efficiently than ever before with the resources that the hospital has. It is suitable for selecting the optimal bed for the patient's necessary medical services, but not for the purpose of consulting other hospitals about whether or not patients can be accepted.

  The present invention has been made in consideration of such circumstances, and the purpose of the present invention is to provide details on new medicines, etc., when it is desired to request external patient hospitalization, discharge, home visit, short stay, etc. When you want to obtain information from the outside, other medical-related facilities, nursing-related facilities, or other external facilities that medical-related facilities or nursing-related facilities cooperate with your facility for the examination or treatment of patients at your facility It is an object of the present invention to provide a cooperation destination search support method and system for medical / nursing care related facilities that supports a facility (hereinafter also referred to as a cooperation destination) so that it can be searched quickly and easily.

  Another object of the present invention is a medical / care-related facility that can eliminate the troublesome work of searching for a recipient of a patient by telephone or fax (cooperation of searching for a cooperation destination) without troublesome work such as database maintenance. It is to provide a cooperation destination search support method and system.

  Other objects of the present invention which are not specified here will be apparent from the following description and the accompanying drawings.

(1) A cooperation destination search support method for a medical / nursing care facility according to the first aspect of the present invention includes:
A collaborative destination search support method for medical / nursing related facilities that supports medical related facilities or nursing care related facilities to search for a desired collaborative destination,
On the user terminal, let the originator of the cooperation request specify one or more cooperation request destinations to which the cooperation request is sent,
Generating one or a plurality of cooperation request destinations specified on the user terminal and a cooperation request timeline that can be accessed by the transmission source;
Let the sender input the content of the cooperation request on the user terminal,
The content of the cooperation request input on the user terminal is displayed on the cooperation request timeline as cooperation request information,
On the cooperation request timeline, one or more of the cooperation requests is transmitted from the one or more cooperation request destinations and the transmission source by exchanging messages between the one or more cooperation request destinations and the transmission source. It is characterized in that a desired cooperation destination can be found from among the destinations.

  In the cooperation destination search support method for a medical / care-related facility according to the first aspect of the present invention, one or a plurality of cooperation request destinations that are desired to transmit the cooperation request on the user terminal are designated as the transmission source. And generating the cooperation request timeline that can be accessed by the source and one or more designated cooperation request destinations. And the content of the said cooperation request which the said transmission origin input on the said user terminal is displayed on the said cooperation request timeline as the said cooperation request information, and is notified to the one or some said cooperation request destination. As a result, one or a plurality of cooperation request destinations and the transmission source can freely exchange messages such as questions based on the cooperation request information on the cooperation request timeline. For this reason, the transmission source can find a desired cooperation destination from one or a plurality of cooperation request destinations through its message exchange on its own user terminal.

  Therefore, the medical facility or nursing care facility, which is the sender or the organization to which it belongs, obtains detailed information on new drugs, etc. from the outside, when requesting hospitalization, discharge, home visit, short stay, etc. When it is desired to do so, it is possible to quickly and easily search for other medical-related facilities, care-related facilities, and other facilities (that is, cooperation destinations) that cooperate with the own facility.

  In addition, since the database for managing the cooperation request destination is not necessary, the troublesome work of searching for a patient receiving place (cooperation destination search work) by telephone or fax can be made unnecessary without troublesome work such as database maintenance. .

  (2) In a preferred example of the cooperation destination search support method for medical / care-related facilities according to the first aspect of the present invention, the input of the content of the cooperation request is performed by specifying a patient or a theme. In this example, it is easy to display the cooperation request information on the patient timeline related to the patient or the theme timeline related to the theme by using information indicating the identified patient or the theme. There is an advantage.

  (3) In another preferred example of the cooperation destination search support method for medical / care-related facilities according to the first aspect of the present invention, a patient timeline or a theme timeline related to the cooperation request is provided, and the cooperation request Information is also displayed on the patient timeline or the theme timeline in addition to the collaboration request timeline. In this example, the fact that the cooperation request has been made and the details thereof can be quickly notified not only to the cooperation request destination but also to all the members of the patient timeline or the theme timeline related to the cooperation request. There is an advantage that you can.

  (4) In still another preferable example of the cooperation destination search support method of the medical / nursing care related facility according to the first aspect of the present invention, the source is added to the patient timeline or the theme timeline related to the cooperation request. The cooperation request destination determined as a desired cooperation destination is automatically invited. In this example, there is an advantage that the cooperation request destination determined as a desired cooperation destination by the transmission source can quickly and easily communicate with all the members of the patient timeline or the theme timeline. is there.

  (5) In still another preferable example of the cooperation destination search support method for medical / care-related facilities according to the first aspect of the present invention, one or a plurality of cooperation request destinations specified on the user terminal are requested to be a cooperation request. Whether or not to save as a destination group can be selected. In this example, there is an advantage that one or a plurality of cooperation request destinations can be specified easily and quickly simply by selecting the saved cooperation request destination group.

  (6) In still another preferable example of the cooperation destination search support method for the medical / care-related facility according to the first aspect of the present invention, one or a plurality of the cooperation request information displayed on the cooperation request timeline Messages exchanged between the cooperation request destination and the source are displayed in the form of a thread. In this example, even if a plurality of the cooperation request information is displayed on the cooperation request timeline and a large number of messages are posted for each cooperation request information, one or a plurality of the cooperation request destinations and the transmission source Has the advantage that there is no fear of confusing those messages.

(7) A cooperation destination search support system for a medical / nursing care facility according to the second aspect of the present invention,
A collaborative search support system for medical / nursing related facilities that supports medical related facilities or nursing related facilities searching for a desired collaborative destination,
A linkage request destination designation screen display means for displaying a linkage request destination designation screen for designating one or a plurality of linkage request destinations to which the linkage request is transmitted, on the user terminal;
A cooperation request / timeline generating means for generating a cooperation request / timeline that can be accessed by one or a plurality of the cooperation request destinations specified on the cooperation request destination designation screen and a source of the cooperation request;
Cooperation request content input screen display means for displaying a cooperation request content input screen for inputting the content of the cooperation request on the user terminal;
The content of the cooperation request input on the cooperation request content input screen is provided with cooperation request content display means for displaying on the cooperation request timeline as cooperation request information,
On the cooperation request timeline, one or more of the cooperation requests is transmitted from the one or more cooperation request destinations and the transmission source by exchanging messages between the one or more cooperation request destinations and the transmission source. It is characterized in that a desired cooperation destination can be found from among the destinations.

  In the cooperation destination search support system of the medical / nursing care related facility according to the second aspect of the present invention, one or a plurality of cooperation request destinations that desire to transmit the cooperation request on the cooperation request destination designation screen, The cooperation request timeline that can be accessed by the source and one or more designated cooperation request destinations is generated. Then, the content of the cooperation request input by the sender on the cooperation request content input screen is displayed on the cooperation request timeline as the cooperation request information to notify one or a plurality of cooperation request destinations. . As a result, one or a plurality of cooperation request destinations and the transmission source can freely exchange messages such as questions based on the cooperation request information on the cooperation request timeline. For this reason, the transmission source can find a desired cooperation destination from one or a plurality of cooperation request destinations through its message exchange on its own user terminal.

  Therefore, the medical facility or nursing care facility, which is the sender or the organization to which it belongs, obtains detailed information on new drugs, etc. from the outside, when requesting hospitalization, discharge, home visit, short stay, etc. When it is desired to do so, it is possible to quickly and easily search for other medical-related facilities, care-related facilities, and other facilities (that is, cooperation destinations) that cooperate with the own facility.

  In addition, since the database for managing the cooperation request destination is not necessary, the troublesome work of searching for a patient receiving place (cooperation destination search work) by telephone or fax can be made unnecessary without troublesome work such as database maintenance. .

  (8) In a preferable example of a cooperation destination search support system for medical / care-related facilities according to the second aspect of the present invention, input of the content of the cooperation request on the cooperation request content input screen specifies a patient or a theme. Done. In this example, it is easy to display the cooperation request information on the patient timeline related to the patient or the theme timeline related to the theme by using information indicating the identified patient or the theme. There is an advantage.

  (9) In another preferable example of the cooperation destination search support system for medical / care-related facilities according to the second aspect of the present invention, a patient / theme time for generating a patient timeline or a theme timeline related to the cooperation request Line generation means, and the cooperation request information is displayed on the patient timeline or the theme timeline generated by the patient / theme timeline generation means in addition to the cooperation request timeline. Is done. In this example, the fact that the cooperation request has been made and the details thereof can be quickly notified not only to the cooperation request destination but also to all the members of the patient timeline or the theme timeline related to the cooperation request. There is an advantage that you can.

  (10) In still another preferred example of the cooperation destination search support system for medical / nursing care related facilities according to the second aspect of the present invention, it is desired by the sender in the patient timeline or theme timeline related to the cooperation request. The cooperation request destination determined as the cooperation destination is automatically invited. In this example, there is an advantage that the cooperation request destination determined as a desired cooperation destination by the transmission source can quickly and easily communicate with all the members of the patient timeline or the theme timeline. is there.

  (11) In still another preferred example of the cooperation / destination-related facility cooperation destination search support system according to the second aspect of the present invention, the one or more cooperation request destinations specified on the cooperation request destination designation screen are Whether or not to save as a cooperation request destination group can be selected. In this example, there is an advantage that one or a plurality of cooperation request destinations can be specified easily and quickly simply by selecting the saved cooperation request destination group.

  (12) In yet another preferred example of the cooperation destination search support system for medical / care-related facilities according to the second aspect of the present invention, one or a plurality of cooperation request information displayed on the cooperation request timeline Messages exchanged between the cooperation request destination and the source are displayed in the form of a thread. In this example, even if a plurality of the cooperation request information is displayed on the cooperation request timeline and a large number of messages are posted for each cooperation request information, one or a plurality of the cooperation request destinations and the transmission source Has the advantage that there is no fear of confusing those messages.

  The medical / care-related facility cooperation destination search support method according to the first aspect of the present invention and the medical / nursing-related facility cooperation destination search support system according to the second aspect of the present invention include the hospitalization, discharge, home visit, and short stay of the patient at the own facility. When you want to request external information, etc., or when you want to obtain detailed information about new drugs from outside, medical-related facilities and care-related facilities cooperate with your facility for the examination and treatment of patients in your facility It is possible to support other medical facilities, nursing care facilities and other external facilities (that is, cooperation destinations) so that they can be searched quickly and easily, and without troublesome work such as database maintenance. There is an effect that it is possible to dispense with troublesome patient receiving destination searching work (cooperation destination searching work) by fax.

It is a conceptual diagram which shows the utilization state of the cooperation destination search assistance system of the medical care / care-related facility which concerns on one Embodiment of this invention, and has shown about the case where a patient is admitted from a clinic to a hospital. It is a conceptual diagram which shows the utilization state of the cooperation destination search assistance system of the medical and care related facility which concerns on one Embodiment of this invention, and has shown about the case where a patient is discharged from a hospital. It is explanatory drawing which shows the whole structure of the cooperation destination search assistance system of the medical / nursing care related facility which concerns on one Embodiment of this invention. It is a flowchart which shows the operation | movement flow of the cooperation destination search assistance system shown to FIGS. FIG. 5 is a flowchart illustrating an operation flow of the cooperation destination search support system illustrated in FIGS. FIG. 6 is a flowchart illustrating an operation flow of the cooperation destination search support system illustrated in FIGS. It is explanatory drawing which shows the example of a patient timeline list used with the cooperation destination search assistance system shown to FIGS. It is explanatory drawing which shows the example of a patient timeline used with the cooperation destination search assistance system shown to FIGS. It is explanatory drawing which shows the example of the cooperation request type selection screen used with the cooperation destination search assistance system shown to FIGS. It is explanatory drawing which shows the example of the cooperation request content input screen used with the cooperation destination search assistance system shown to FIGS. 1-3, and shows the case of the cooperation which concerns on a patient discharge. It is explanatory drawing which shows the example of the cooperation request content input screen used with the cooperation destination search assistance system shown to FIGS. 1-3, and shows the case of cooperation which concerns on provision of chemical | medical agent information. It is explanatory drawing which shows the example of the cooperation request content input screen used with the cooperation destination search assistance system shown to FIGS. 1-3, and shows the case of cooperation which concerns on nutritional guidance. It is explanatory drawing which shows the example of the registered request destination group selection screen used with the cooperation destination search assistance system shown to FIGS. It is explanatory drawing which shows the example of the request destination member selection screen used with the cooperation destination search assistance system shown to FIGS. It is explanatory drawing which shows the example of the request destination member selection screen (at the time of group name registration) used with the cooperation destination search assistance system shown to FIGS. It is explanatory drawing which shows the example of the display mode (before determination) of the request information to a patient timeline used with the cooperation destination search assistance system shown to FIGS. It is explanatory drawing which shows the example of the display mode (before determination) of the request information to a request destination group timeline used with the cooperation destination search assistance system shown to FIGS. It is explanatory drawing which shows the example of the display mode (after determination) of the request information to a request destination group timeline used with the cooperation destination search assistance system shown in FIGS. It is explanatory drawing which shows the example of the display mode (after confirmation) of the request information to a patient timeline used with the cooperation destination search assistance system shown in FIGS. It is a conceptual diagram which shows the utilization state of the medical assistance system containing the cooperation destination search assistance system shown in FIGS. FIG. 19 is an explanatory diagram showing the interrelationship among patients, patient personnel, medical workers, and medical facilities participating in the medical support system of FIG. It is a functional block diagram which shows the internal structure of the medical assistance system shown in FIG. It is a figure which shows the structural example of the table used for the medical assistance system shown in FIG. 18, (a) is a user table, (b) is a patient table, (c) is a medical worker table, (d) is medical care. It is a related facility table. It is a figure which shows the structural example of the table used for the medical assistance system shown in FIG. 18, (a) is a medical related facility patient table, (b) is a disease table, (c) is a group table, (d) is It is a group participation table. FIG. 19 is a diagram illustrating a configuration example of a table used in the medical support system illustrated in FIG. 18, where (a) is an invitation request table, (b) is a timeline table, (c) is a medical information sharing rule table, (d ) Is an NFC terminal management rule table. It is a figure which shows the structural example of the table used for the medical assistance system shown in FIG. 18, (a) is a message transmission reservation table, (b) is a patient attribute table. It is explanatory drawing which shows the relationship between all the tables used for the medical assistance system shown in FIG. It is explanatory drawing which shows the relationship of the person who can access the display area produced | generated for every disease for every patient of the patient timeline formed by the medical assistance system shown in FIG. 18, and the display area. FIG. 19 is a flowchart showing a series of operations when a user who wants to use a medical support service newly registers a user in the medical support system shown in FIG. 18. FIG. 19 is a flowchart showing a series of operations when a user of a medical support service newly registers a patient in the medical support system shown in FIG. 18. 19 is a flowchart showing a series of operations when a user of a medical support service newly registers a medical worker in the medical support system shown in FIG. FIG. 19 is a flowchart showing a series of operations when a medical worker performs family registration in the medical support system shown in FIG. 18. In the medical support system shown in FIG. 18, it is a flowchart which shows a series of operation | movement when a medical worker performs family registration, and is a continuation of FIG. 28A. 19 is a flowchart showing a series of operations when a patient performs family registration in the medical support system shown in FIG. In the medical support system shown in FIG. 18, it is a flowchart which shows a series of operation | movement at the time of a patient performing family registration, and is a continuation of FIG. 30A. FIG. 19 is a flowchart showing a series of operations when a medical worker or patient invites a supporter who is a user in the medical support system shown in FIG. 18. The medical support system shown in FIG. 18 is a flowchart showing a series of operations when a medical worker or patient invites a supporter who is a user, and is a continuation of FIG. 31A. FIG. 19 is a flowchart showing a series of operations when a medical worker or patient invites a supporter who is a non-user in the medical support system shown in FIG. 18. The medical support system shown in FIG. 18 is a flowchart showing a series of operations when a medical worker or patient invites a supporter who is a non-user, and is a continuation of FIG. 32A. It is explanatory drawing which shows the example of the "new user registration screen" used in the medical assistance system shown in FIG. It is explanatory drawing which shows the example of the "login screen" used in the medical assistance system shown in FIG. It is explanatory drawing which shows the example of the "new patient registration screen" used in the medical assistance system shown in FIG. It is explanatory drawing which shows the example of the "new medical worker registration screen" used in the medical assistance system shown in FIG. It is explanatory drawing which shows the example of the "family registration request screen" used in the medical assistance system shown in FIG. 18, when a medical worker requests. It is explanatory drawing which shows the example of the "family registration approval screen" used in the medical assistance system shown in FIG. 18, when a medical worker requests. It is explanatory drawing which shows the example of the "family registration request screen" used in the medical assistance system shown in FIG. 18, when a patient requests. It is explanatory drawing which shows the example of the search result screen of a medical relevant facility used in the medical assistance system shown in FIG. 18, when a patient requests. It is explanatory drawing which shows the example of the "family registration confirmation screen" used in the medical assistance system shown in FIG. 18, when a patient requests. It is explanatory drawing which shows the example of the "supporter invitation screen" in the case of inviting the existing user used in the medical assistance system shown in FIG. It is explanatory drawing which shows the example of the "supporter invitation permission / refusal screen" in the case of inviting the existing user used in the medical assistance system shown in FIG. It is explanatory drawing which shows the example of the "supporter invitation approval screen" in the case of inviting the existing user used in the medical assistance system shown in FIG. It is explanatory drawing which shows the example of the "supporter invitation screen" in the case of inviting a non-user used in the medical assistance system shown in FIG. It is explanatory drawing which shows the example of the "supporter invitation approval screen" in the case of inviting a non-user used in the medical assistance system shown in FIG. It is explanatory drawing which shows the example of the "supporter invitation permission / refusal screen" in the case of inviting a non-user used in the medical assistance system shown in FIG. FIG. 19 is a flowchart showing a series of operations for patient group registration by a medical staff in the medical support system shown in FIG. 18. FIG. It is explanatory drawing which shows an example of the medical staff menu used in the medical assistance system shown in FIG. It is explanatory drawing which shows an example of a patient menu used in the medical assistance system shown in FIG. It is explanatory drawing which shows an example of the timeline regarding the patient A used in the medical assistance system shown in FIG. It is explanatory drawing which shows the medical information with which patient A was integrated used in the medical assistance system shown in FIG. It is explanatory drawing which shows an example of a patient group registration screen used in the medical assistance system shown in FIG.

  Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings.

(Overall configuration when using medical facility / nursing care facility search support service)
FIG. 1 and FIG. 2 show an overall configuration when using a cooperation support service provided by a cooperation destination search support system (hereinafter referred to as a cooperation support system) 100 of a medical / care-related facility according to an embodiment of the present invention. . As shown in both figures, the cooperation support system 100 is configured to operate in combination with the medical support system 30, so to use the cooperation support system 100, it becomes a “user” of the medical support system 30. There is a need. Therefore, a patient, a medical worker (for example, a doctor, a nurse, etc.), a patient-related person (for example, a patient's family or relative, friend, acquaintance, etc.) and / or a care worker (for example, a care manager, Home helpers etc.) are all “users” of the medical support system 30.

  The medical support system 30 used in the present embodiment is an embodiment of a medical / care support system (see Japanese Patent Application No. 2013-149980) previously filed by the applicant of the present application. Therefore, it can be said that the cooperation support system 100 according to the present embodiment is a subsystem for adding a cooperation destination search support function for medical / care-related facilities to the medical support system 30. However, the cooperation support system 100 generates a timeline (here, a patient timeline and / or a theme timeline) as a communication tool for patients, healthcare workers, patient personnel, and / or caregivers. It is possible to cooperate with any system other than the medical / nursing care support system (see Japanese Patent Application No. 2013-149980) of the earlier application as long as it is a system that can be used, and the time provided as such a communication tool It goes without saying that a function for generating a line (patient timeline and / or theme timeline) may be installed in the cooperation support system 100.

  In the following description relating to the medical support system 30, “patient P1” and “patient P2” are used to distinguish individual patients, and “patient P” is used when individual patients are not distinguished. Similarly, when distinguishing individual medical workers (doctors, nurses, care managers, helpers, etc.), they are described as “medical worker M1”, “medical worker M2”, etc. M ”. When distinguishing individual patient-related persons (patient family, acquaintances, friends, etc.), “patient-related person R1”, “patient-related person R2”, etc., otherwise, “patient-related person R” To do. When not distinguishing each medical related facility, it describes with "medical related facility F", and when distinguishing, it describes with "medical related facility F1," "medical related facility F2," etc. When not distinguishing each patient group, it describes with "(patient) group G", and when distinguishing, it describes with "(patient) group G11", "(patient) group G12", etc.

  In the medical support system 30, “medical workers” include care workers such as care managers (care managers) and home helpers (helpers) who are engaged in nursing care at medical facilities.

  Further, in the following description relating to the cooperation support system 100, individual medical related facilities, nursing care related facilities, and other facilities (for example, pharmaceutical companies and research institutions) (hereinafter also referred to as cooperation candidate facilities) as cooperation request destinations. When not distinguished, it is written as “cooperation candidate facility LF”, and when distinguished, it is written as “cooperation candidate facility LF1”, “cooperation candidate facility LF2”, or the like. Similarly, when not distinguishing each cooperation request destination group, it describes as “(cooperation) request destination group RG”, and when distinguishing, “(cooperation) request destination group RG1”, “(cooperation) request destination group”. “RG2” or the like.

  FIG. 1 shows that when a patient P of a clinic C wants to be admitted to an appropriate hospital, the clinic C uses the cooperation support system 100 and the medical support system 30 to cooperate with the clinic C. It is a conceptual diagram which shows the process of searching for (hospital which accepts a patient).

  Clinic C often orders the patient P or his family (patient official R) to be admitted to another well-equipped hospital at the discretion of the doctor or receives consultation from the patient P or his family May decide to be hospitalized. In such a case, it is necessary to find an appropriate hospital in a short period of time and have the patient P accepted (hospitalized). When Clinic C introduces a medical support system 30 that generates a timeline provided for each patient P as a communication tool with a medical worker M or a patient-related person R (in other words, Clinic C When the medical support service provided by the medical support system 30 is used), as will be described later, it is extremely easy to search for the medical-related facility F and the care-related facility of the cooperation destination by the cooperation support system 100 according to the present embodiment. Will be able to do.

  In FIG. 1, although the details of the medical support system 30 will be described later, a timeline (hereinafter referred to as a patient) provided for each patient P as a communication tool for a medical worker M, a patient person R, or a care worker. A timeline). By posting medical-related information and messages on the patient timeline, it is possible to share medical-related information among predetermined members, and at the same time, smooth communication between members can be achieved through messages posted by members. . In addition to the patient timeline, the medical support system 30 provides themes provided in the same format as the patient timeline for each specific theme such as drug information provision or nutritional guidance in addition to the patient timeline. -A timeline is also generated. In the following description, both the patient timeline and the theme timeline are collectively referred to as “patient / theme timeline”.

  The cooperation support system 100 responds to an instruction from the clinic C, and requests a cooperation request destination group including doctors and nurses (medical workers M) of the cooperation candidate facilities LF1 to LFn (n is a natural number of 2 or more) as members ( Hereinafter, an RG (also referred to as a request destination group) is generated, and a timeline (hereinafter referred to as a cooperation request timeline) is generated as a communication tool for members of the cooperation request destination group RG. At this time, it is also possible to generate only the cooperation request timeline without generating the cooperation request destination group RG. In response to the cooperation destination search request from the clinic C, the cooperation support system 100 posts a cooperation request to the cooperation request timeline of the request destination group RG including the cooperation candidate facilities LF1 to LFn. Thereby, all members such as doctors and nurses of the cooperation candidate facilities LF1 to LFn can know that the cooperation request has arrived. These members read the cooperation request and compare the contents of the cooperation request with the situation of their own facility to determine whether or not a new patient P can be accepted. The member of the cooperation candidate facility LF that is determined to be acceptable may send a message on the cooperation request timeline and reply “acceptable”. If clinic C (the person in charge) who issued the cooperation request agrees with this answer, the candidate cooperation facility LF of the member who answered “acceptable” is determined as the accepting destination (cooperation destination). In this way, the clinic C can very easily search for a cooperation destination.

  When the cooperation destination (acceptance destination) of the clinic C is confirmed, the cooperation support system 100 automatically invites members of the cooperation candidate facility LF that answered “acceptable” to the patient timeline of the patient P related to the cooperation request. . As a result, invited members can freely access medical-related information and messages posted (shared) on the patient timeline. The explanation given to the doctors and nurses of F can be simplified, and the efficiency of the inter-facility cooperation work is dramatically increased.

  FIG. 2 shows that when a patient at hospital H wants to be discharged, the hospital H uses the cooperation support system 100 and the medical support system 30 to cooperate with the hospital H and the care related facility ( It is a conceptual diagram which shows the process of searching for a clinic, a group home, etc. who take charge of the care of the patient after discharge.

  The hospital H often instructs the patient P or his family (patient-related person R) to be discharged at the discretion of the doctor, or decides on discharge from the patient P or his / her family. In such a case, it is necessary to search for an appropriate clinic or group home in a short period of time and have the patient P take care of the patient P after discharge. When the hospital H introduces a medical support system 30 that generates a timeline provided for each patient P as a communication tool for the medical staff M and patient personnel R, the same as in FIG. In addition, the cooperation support system 100 according to the present embodiment makes it very easy to search for a medical-related facility F or a care-related facility as a cooperation destination.

  In the case of FIG. 2, as in the case of FIG. 1, the cooperation support system 100 responds to an instruction from the hospital H, and includes doctors, nurses, care managers, helpers, etc. (medical workers) of the cooperation candidate facilities LF1 to LFn. A cooperation request destination group RG including M) as a member is generated, and a cooperation request timeline is generated. At this time, it is also possible to generate only the cooperation request timeline without generating the cooperation request destination group. In response to the cooperation destination search request from the hospital H, the cooperation support system 100 posts a cooperation request to the cooperation request timeline of the request destination group RG including the cooperation candidate facilities LF1 to LFn. Thereby, all members such as doctors, nurses, care managers, helpers and the like of the cooperation candidate facilities LF1 to LFn can know that the cooperation request has arrived. These members read the cooperation request and compare the contents of the cooperation request with the situation of their own facility to determine whether or not a new patient P can be accepted. The member of the cooperation candidate facility LF that is determined to be acceptable may send a message on the cooperation request timeline and reply “acceptable”. If the hospital H (the person in charge) who issued the cooperation request agrees with this answer, the cooperation candidate facility LF of the member who answered “acceptable” is determined as the receiving destination (cooperation destination). In this way, the hospital H can very easily search for the cooperation destination.

  When the cooperation destination (acceptance destination) of the hospital H is determined, the cooperation support system 100 automatically invites members of the cooperation candidate facility LF that has replied “acceptable” to the patient timeline of the patient P related to the cooperation request. As a result, invited members can freely access medical information and messages posted on the patient timeline. The explanations given to doctors, nurses, care managers, helpers, etc. of related facilities can be simplified, and the efficiency of the inter-facility cooperation work is dramatically increased.

(Configuration of cooperation support system)
Next, the configuration of the cooperation support system 100 according to the present embodiment will be described with reference to FIG.

  As illustrated in FIG. 3, the cooperation support system 100 includes a cooperation request destination designation screen display unit 101, a cooperation request / timeline control unit 102, a cooperation request content input screen display unit 103, a cooperation request content transmission unit 104, and a cooperation request. A destination information management unit 105 and a cooperation destination information management unit 106 are provided.

  The cooperation request destination designation screen display unit 101 is formed from software that controls the operation thereof, and, if necessary, a predetermined registered cooperation request destination group selection screen via a medical support system 30 to a designated user terminal. (Refer to FIG. 11) is displayed, and it is determined whether to select a cooperation request destination group or to newly register a request destination group for a user who wants to use the cooperation support service (use applicant). Encourage In addition, a predetermined cooperation request destination member selection screen (see FIGS. 12 and 13) is displayed to prompt the user to designate the cooperation request destination member. At this time, the cooperation request destination designation screen display unit 101 stores the user information stored in the user information storage unit 312 of the user management unit 310 of the medical support system 30 or the patient information storage unit 313 as necessary. The patient information and the medical worker information stored in the medical worker information storage unit 314 are read and used. Note that the operation of the cooperation request destination designation screen display unit 101 may be executed in a separate process from the system 30 without cooperating with the medical support system 30.

  The cooperation request / timeline control unit 102 is formed of software for controlling the operation, an information storage medium such as a hard disk, and software for controlling operations such as recording, reproduction, and erasing of information on the information storage medium. The Various information such as the contents of the cooperation request transmitted from the user terminal and the message group posted on the cooperation request / timeline is recorded on the information storage medium, and is reproduced / erased as necessary.

  The cooperation request / timeline control unit 102 generates and operates the cooperation request / timeline in cooperation with the medical support system 30 (specifically, the timeline control unit 326 of the group management unit 320 of the system 30). And the communication operation between the cooperation request timeline and the patient / theme timeline. Specifically, for example, a new cooperation request timeline is generated in response to the cooperation request, and then the cooperation request content that matches the cooperation request contents in both the cooperation request timeline and the patient timeline or the theme timeline. "Request notification panel" 162 is displayed (that is, the content of the cooperation request is displayed as "cooperation request information"), and messages posted on the cooperation request timeline are displayed in a time series as a thread format in association with the cooperation request. To do. In addition, the content of the status display button 163 of the “Cooperation Request Notification Panel” 162 of the cooperation request / timeline is changed to “adjusting” or “confirmed” according to the progress of the cooperation operation, and the patient timeline Alternatively, the contents of the status display button 163 of the “cooperation request notification panel” 162 in the theme / timeline are changed to “standby” and “confirmed” in accordance with the progress of the cooperation operation. Further, a cooperation request button 154 (see FIG. 8) is displayed on the patient timeline or the theme timeline of the patient P related to the cooperation request, and a confirmation button 166 (see FIGS. 15 and 16) is displayed on the cooperation request timeline. ) And the display mode is changed according to the confirmed / unconfirmed status.

  As described above, the cooperation request / timeline control unit 102 displays not only the means for controlling the cooperation request / timeline but also the contents of the cooperation request in both the cooperation request / timeline and the patient timeline / theme / timeline. It also operates as a means for communicating the cooperation request timeline with the patient timeline or the theme timeline.

  The cooperation request / timeline control unit 102 further cooperates with the medical support system 30 (specifically, the invitation request control unit 324 and the invitation request information storage unit 325 of the group management unit 320 of the system 30). In response to the cooperation request, the member of the cooperation destination who answered “acceptable” is automatically invited to the patient timeline or the theme timeline of the patient P related to the cooperation request. That is, the cooperation request / timeline control unit 102 also operates as a cooperation destination member invitation unit.

  In the medical support system 30, as described later, when inviting a certain user to a specific patient group, whether or not an invitation request may be transmitted to the user (invited user), the medical provider side and / or It is necessary to obtain the permission of the administrator on the patient side and to obtain the user's approval as to whether or not to accept the invitation request. However, when inviting a collaborator member who answered “acceptable” in response to the collaboration request to the patient timeline or theme timeline of the patient P related to the collaboration request, the invitation is automatically performed, It does not require permission from the health care provider and patient managers or approval of their members.

  The above-described operation of the cooperation request / timeline control unit 102 may be executed in a separate process from the system 30 without cooperating with the medical support system 30.

  The cooperation request content input screen display unit 103 is formed from software that controls the operation thereof. The cooperation request content input screen display unit 103 displays a predetermined cooperation request type selection screen (see FIG. 9) on a designated user terminal as necessary, and a user who wishes to use the cooperation support service. Encourage (users who want to use it) to select a cooperation request type. In addition, a predetermined cooperation request content input screen (see FIGS. 10A, 10B, and 10C) is displayed according to the selected cooperation request type, and prompts to input / transmit the cooperation request content. The operation of the cooperation request content input screen display unit 103 may be executed in a separate process from the system 30 without cooperating with the medical support system 30.

  The cooperation request content transmission unit 104 is formed from software for controlling the operation, and cooperates with the medical support system 30 to input the cooperation request content input screen (see FIGS. 10A, 10B, and 10C). The request content is transmitted in the form of an e-mail to all members of the selected cooperation request destination group (if the cooperation request destination group is not generated, a member specified individually by the source of the cooperation request). The operation of the cooperation request content transmission unit 104 may be executed in a process separate from the system 30 without cooperating with the medical support system 30.

  The cooperation request destination information management unit 105 is formed from an information storage medium such as a hard disk and software for controlling operations such as recording, reproduction, and deletion of information on the information storage medium. The link request destination information management unit 105 specifies various information related to the link request destination (information related to the link request destination group, information related to members belonging to the group, and group non-creation information if the link request destination group is not created. Managed member information). For example, the name of the cooperation request destination group, the name of the member, the affiliation, the job type, etc., the name, location, work content, characteristics, etc. Manage information related to The cooperation request destination information management unit 105 may store user information stored in the user information storage unit 312 of the user management unit 310 of the medical support system 30, patient information stored in the patient information storage unit 313, The medical worker information stored in the worker information storage unit 314 is read and used.

  The cooperation destination information management unit 106 is formed of an information storage medium such as a hard disk and software that controls operations such as recording, reproduction, and deletion of information on the information storage medium. The cooperation destination information management unit 106 associates the cooperation destination information, that is, the cooperation destination finally determined by the transmission source of the cooperation request (a medical facility, a care facility, or other facilities that cooperates with the transmission source) and the link destination information. Manage information related to members. Specifically, it is information such as the name and location of the facility to be linked, the name / job type / contact information of the member in charge, the contents of the linkage, and the start time of the linkage. The cooperation destination information management unit 106, as necessary, stores the user information stored in the user information storage unit 312 of the user management unit 310 of the medical support system 30, the patient information stored in the patient information storage unit 313, and the medical engagement. The medical worker information stored in the person information storage unit 314 is read and used.

(Operation of cooperation support system)
Next, the operation of the cooperation support system 100 having the above configuration will be described with reference to FIGS.

  Here, Dr. Taro Nozaki (pseudonym) at Nozaki Clinic is taken up as a medical worker M seeking cooperation support. As shown in FIG. 4, Dr. Nozaki first logs in to the medical support system 30 from his / her terminal (user terminal) (step S201). From the viewpoint of the medical support system 30, the user is waiting for login. In response to the login, the medical support system 30 performs authentication, and if it is determined that the user is a regular user, the use of the medical support system 30 is permitted. (Step S202). As shown in FIG. 18, the user terminal includes a patient terminal 10, a medical worker terminal 11, and a patient-related terminal 12. The user terminal used here is a medical worker, Dr. Nozaki, who is a medical worker. Since it is a terminal to be used, it becomes the medical worker terminal 11.

  When it is determined that the user is an authorized user in the login authentication in step S202, the medical support system 30 displays a list of timelines to which the user has access authority on the user terminal. Specifically, a timeline list 151 of Nozaki Clinic (Doctor Nozaki) as shown in FIG. 7 is displayed on the user terminal (Doctor Nozaki's terminal 11) (step S203). The user, Dr. Nozaki, sees the timeline list 151 and selects the timeline of the patient P who wishes to be admitted to a well-equipped hospital (step S204). Here, it is assumed that Dr. Nozaki, the user, selects the timeline of Hisae Sumida (a pseudonym) from the displayed timeline list 151. Then, the medical support system 30 displays the timeline (patient timeline) 152 (see FIG. 8) of the selected Hisae Sumida on the user terminal (Doctor Nozaki's terminal 11) (step S205).

  In the selected patient timeline 152, as shown in FIG. 8, a thread 153 composed of a series of posts (messages) is displayed. In the thread 153, a large number of posts (messages) are arranged vertically in time series so that the latest post (message) is positioned at the top. In the patient timeline 152, a cooperation request button 154 that is not present in the case of the medical support system 30 alone is additionally displayed. The additional display of the cooperation request button 154 is performed by the cooperation request / timeline control unit 102 of the cooperation support system 100.

  When the user (Doctor Nozaki) clicks the cooperation request button 154 displayed on the patient timeline 152 (step S206), the cooperation support system 100 (specifically, the cooperation request content input screen display unit) 103) displays a cooperation request type selection screen 155 (see FIG. 9) on the user terminal (Doctor Nozaki's terminal 11) (step S207). As shown in FIG. 9, on the cooperation request type selection screen 155, four selection buttons 156 of “hospitalization”, “discharge”, “drug information”, and “nutrition guidance” are displayed. However, it goes without saying that other types of selection buttons may be displayed.

  The user (Doctor Nozaki) may select the desired type by clicking the selection button 156 of the desired type on the cooperation request / type selection screen 155 (step S208). Here, it is assumed that the user clicks (selects) the “discharge” selection button 156. In response to this, the cooperation support system 100 (cooperation request content input screen display unit 103) displays the cooperation request content input screen 157 (see FIG. 10A) on the user terminal (step S209). As shown in FIG. 10A, the cooperation request content input screen 157 includes a plurality of display fields and input fields such as patient age, patient sex, disease name, severity, visit frequency, patient address, and free text. When the cooperation request content input screen 157 is displayed, patient information of the patient (here, Mr. Hisae Sumida) related to the cooperation request is read from the medical support system 30, and patient age, patient sex, disease name, patient address The four items are automatically displayed. For this reason, it is easy to input the contents of the cooperation request. The other items, that is, the three items of severity, visit frequency, and free text are input by the user himself (here, Dr. Nozaki, the source of the cooperation request) as necessary (step S210).

  After the necessary information has been entered at the user terminal (Doctor Nozaki's terminal 11), when the user (Doctor Nozaki) clicks the “Send” button on the collaboration request content input screen 157, the input / The displayed information (cooperation request content) is transmitted to the cooperation support system 100 and registered. Specifically, the transmitted cooperation request content is recorded in the information storage medium of the cooperation request / timeline control unit 102 of the cooperation support system 100 (step S211).

  Subsequently, the cooperation support system 100 (specifically, the cooperation request destination information management unit 105) displays a registered cooperation request destination group selection screen 158 (see FIG. 11) on the user terminal as shown in FIG. (Step S212). The registered cooperation request destination group selection screen 158 shown in FIG. 11 includes “My group” (a group owned by the Nozaki clinic itself that is the source of the cooperation request) and “Cancer receiving hospital dedicated group” (a cancer linked to the Nozaki clinic) (Groups that include only the patient receiving hospital) are displayed.

  The user (Doctor Nozaki) looks at the registered cooperation request destination group selection screen 158 and determines whether or not to select a registered cooperation request destination group (step S213). When selecting a registered cooperation request destination group, select (determine) a desired registered cooperation request destination group (a group dedicated to a cancer patient receiving hospital in FIG. 11) from the registered cooperation request destination group selection screen 158. What is necessary is just to click a "send" button (step S214). Then, the cooperation support system 100 (cooperation request destination information management part 105) displays the cooperation request destination member selection screen 159 (refer FIG. 12) on a user terminal (step S215). On the cooperation request destination member selection screen 159, all members belonging to the selected registered cooperation request destination group (group dedicated to cancer patient receiving hospital) are listed as cooperation destination candidates. If you do not want to select a registered cooperation request destination group, you can click the “Cancel” button. Then, the cooperation support system 100 (cooperation request destination information management part 105) displays the cooperation request destination member selection screen 159 (refer FIG. 12) on a user terminal (step S215). In this case, the cooperation request destination member selection screen 159 displays a list of all members that can be selected as cooperation destination candidates.

  While viewing the cooperation request destination member selection screen 159, the user (Doctor Nozaki) selects a member (cooperation destination candidate) who wants to send a cooperation request (step S216). Then, it is determined whether or not a new cooperation request destination group is created with the selected member (step S217). This determination is transmitted to the cooperation support system 100 depending on whether or not a check box 160 of “Register this group in my group” is checked on the cooperation request destination member selection screen 159 of FIG. FIG. 12 shows a case where a new cooperation request destination group is not created with the selected member. In this case, it is only necessary to click the “Send” button without checking the “Register this group in my group” checkbox 160. Then, the cooperation support system 100 registers the selected cooperation request destination member (step S220). The information registered here is stored in the cooperation request destination information management unit 105.

  When a new cooperation request destination group is created with the selected member, as shown in FIG. 13, a check box 160 of “Register this group in my group” is checked and a new field is entered in the input field 161. It is only necessary to input a group name (step S218). Here, “dementia group” is entered. When the “Send” button is clicked after the input is completed, the cooperation support system 100 registers a new cooperation request destination group name (step S219), and further registers the selected cooperation request destination member (step S220). The information registered here is stored in the cooperation request destination information management unit 105.

  The case where a new cooperation request destination group is not created in step S217 is a case where the cooperation destination search with the selected member is limited to a temporary one (one time only). In this case, since it is considered that the cooperation destination search is not performed for the selected member in the future, it is meaningless to create a cooperation request destination group. Conversely, a new cooperation request destination group is created when it is expected that the cooperation destination search with the selected member will be repeated in the future. Here, if a cooperation request destination group is created and registered, simply selecting a cooperation request destination group on the registered cooperation request destination group selection screen 158 will immediately display a list of all members of the group. This is because cooperation candidates can be selected and transmitted easily and quickly from the list, which is very convenient.

  Even when it is determined in step S217 that a new cooperation request destination group is not created, a cooperation request destination group may be created in the cooperation support system 100. This is because the system configuration can be simplified a little. However, in that case, it is necessary to prevent the user from knowing the existence of the newly created cooperation request destination group so that the user does not get lost.

  Subsequently, the cooperation support system 100 determines whether or not an existing cooperation request timeline exists as shown in FIG. 6 (step S221). If it is determined that an existing cooperation request / timeline exists, that is, if any of the registered cooperation request destination groups is selected on the registered cooperation request destination group selection screen 158, the existing cooperation request / timeline is newly added. A thread area is generated (step S222). If it is determined that there is no existing request timeline, that is, no registered cooperation request destination group is selected on the registered cooperation request destination group selection screen 158, and a new cooperation request destination group is created. If so, both a cooperation request timeline and a thread area are newly generated (step S223). Then, the content of the cooperation request is displayed as “cooperation request information” in the existing or new cooperation request timeline, the message of the cooperation request sender (Doctor Nozaki) is displayed in the thread area (step S224), and further The content of the cooperation request is also displayed as “cooperation request information” on the patient timeline of patient P related to the cooperation request (here, Hisae Sumida's patient timeline) (step S225). In parallel with this, the contents of the cooperation request are transmitted in the form of an e-mail to all the selected cooperation request destination members. Accordingly, there is an advantage that the fact that there is a cooperation request and the details thereof can be quickly notified not only to all members of the cooperation request destination but also to all the members of the patient timeline related to the cooperation request.

  The series of operations in steps S221 to S225 is executed by the cooperation request / timeline control unit 102 of the cooperation support system 100. The operation of step S226 is executed by the cooperation request content transmission unit 104 of the cooperation support system 100.

  The display mode of the cooperation request content (cooperation request information) on the patient timeline (here, Hisae Sumida's patient timeline) 152 related to the cooperation request is as shown in FIG. 14, for example. As shown in the figure, the content of the cooperation request is displayed in the form of a cooperation request notification panel 162 in which items related to Mr. Hisae Sumida's discharge acceptance request are displayed as a list. Only the cooperation request contents are displayed on the cooperation request notification panel 162, and the thread 153 related to the cooperation request contents is not displayed. In the cooperation request notification panel 162, a status display button 163 is displayed in a conspicuous color at a conspicuous position. In FIG. 14, since it is before confirmation of a cooperation request destination member (acceptance destination), “standby” is displayed. Reference numeral 164 is a list of members participating in the patient timeline (member list). Here, face photos of all members are displayed side by side so that participating members can be listed.

  Moreover, the display mode of the cooperation request content on the cooperation request / timeline 165 at this time is, for example, as shown in FIG. As shown in the figure, the cooperation request content is displayed in the form of a cooperation request notification panel 162 in which discharge request information is displayed as a list. This is the same as for the corresponding patient timeline 152 (FIG. 14). However, the cooperation request timeline 165 is different from the case of the patient timeline 152 in that the thread 153 related to the cooperation request content is also displayed. In the cooperation request notification panel 162, a status display button 163 is displayed in a conspicuous color at a conspicuous position. In FIG. 15, since “coordination request destination member (acceptance destination) has not yet been determined,“ adjusting ”is displayed.

  The confirmation button 166 is displayed in the message from the cooperation request destination member in the thread 153, and the cooperation request source user (Doctor Nozaki) clicks the confirmation button 166 of the cooperation request destination member to be selected. In this way, it is possible to determine the cooperation request destination member.

  Individual cooperation request destination members compare the contents of the cooperation request with the current state of their facilities while exchanging messages with the user (Dr. Nozaki) of the cooperation request originator in the existing or new cooperation request timeline 165. Thus, it is examined whether or not the content of the cooperation request can be accepted at the own facility (step S226). One or a plurality of cooperation request destination members determined to be acceptable express a message “acceptable” by posting a message in the cooperation request timeline 165. The user who is the source of the collaboration request (here, Dr. Nozaki) reads one or more collaboration request destination members who have expressed "acceptable" by reading a post in the collaboration request timeline 165, and he or they What is necessary is just to compare and examine the medical-related facility F to which it belongs, and to select and determine the optimal member and facility F.

  As a result of the comparison, when one member and the facility F are determined, the cooperation request transmission source user (Doctor Nozaki) clicks the confirmation button 166 of the cooperation request destination member to be selected (step S227). Then, the cooperation support system 100 (specifically, the cooperation request destination information management unit 105) registers the confirmed cooperation destination (selected / decided cooperation request destination member) (step S228), and the corresponding patient timeline 152. Automatically invites the cooperation destination member (step S229). The invited partner member is displayed with the face photograph added to the patient timeline 152 (step S230). This state is shown in FIG. 16 and FIG. The automatic invitation at this time is executed by the cooperation support system 100 using the invitation request control unit 324 of the medical support system 30. This automatic invitation has an advantage that the cooperation request destination selected / decided can quickly and easily communicate with all the members of the patient timeline 152, that is, the patient related to the cooperation request and its supporters.

  The display mode of the cooperation request content on the cooperation request / timeline 165 after the confirmation is, for example, as shown in FIG. As shown in the figure, the status display button 163 in the request notification panel 162 is displayed as “Confirmed”. In addition, the confirmation button 166 in the thread 153 is changed to a pressed state.

  The display mode of the content of the cooperation request on the corresponding patient timeline (here, Hisae Sumida's patient timeline) 152 after confirmation is, for example, as shown in FIG. As shown in the figure, the status display button 163 in the cooperation request notification panel 162 is displayed as “Confirmed”. In the member list 164 of the patient timeline, face photographs of all the members are displayed side by side. As indicated by reference numeral 167, the confirmed cooperation destination member (selected / decided cooperation request destination member) Is added and displayed. As a result, not only the cooperation request destination but also all the members of the patient group (patient timeline 152) of the patient related to the cooperation request can know the response status to the cooperation request in real time.

  As described above, the cooperation request timeline 165 is generated only when a new cooperation request destination group RG is created. For example, when the cooperation request destination group RG is created as an A group in which request destination members (members of cooperation destination candidates) related to dementia are collected, a cooperation request timeline for the A group is newly generated. Similarly, when a group B is created as a collection of request-destination members (members of cooperation destination candidates) related to diabetes, a cooperation request timeline for group B is newly generated. When a request group member related to cancer (cooperation destination candidate member) is created as a C group, a cooperation request timeline for the C group is newly generated. When a request group member (cooperation destination candidate member) capable of emergency response is created as a D group, a cooperation request timeline for the D group is newly generated. When the E group is created as a collection of request destination members (cooperation destination candidate members) whose cost is low, a cooperation request timeline for the E group is newly generated.

  In this way, if you create a cooperation request destination group for each cooperation need, then select the group, select a member that is a candidate for cooperation from the member list, and enter the cooperation request details Since a separate (new) thread area is generated for each cooperation request in the cooperation request timeline of the cooperation request destination group, it is very easy to perform cooperation consultation for members included in the same group There is. In addition, since a new thread area is generated for each cooperation request, even if cooperation requests are repeatedly sent to the same cooperation request destination group, many messages posted for each cooperation request are confused in the cooperation request timeline. There is also an advantage that there is no fear of it.

  When temporary cooperation request destination members (cooperation destination candidate members) are collected, it is not necessary to generate a cooperation request destination group. This is because the search for these members is one-time and is known not to be reused. Therefore, in this case, both the cooperation request timeline and the thread area are newly generated, and using the cooperation request timeline, the search for the cooperation destination is performed in the same manner as when the cooperation request destination group exists. Done.

  The above description is a case where the user (to Dr. Nozaki) selects “discharge” for a specific patient from the cooperation request type selection screen 155 (see FIG. 9). When “hospitalization” of a specific patient is selected from the cooperation request type selection screen 155, the input items on the cooperation request content input screen 157 (FIG. 10A) are changed to those consistent with “hospitalization”. The operation is the same as in the case of “discharge” described above, except that the cooperation request information displayed on the cooperation request / timeline 165 is changed to one that matches “hospitalization”. However, the cooperation support system 100 can also support other cooperation request types. Then, the case where the selection buttons 156 “medicine information” and “nutrition guidance” displayed on the cooperation request type selection screen 155 are selected will be described. Here, the difference from the case where “discharge” is selected will be mainly described.

(When linking drug information)
When the user (Doctor Nozaki) selects the type “drug information” in step S208 of FIG. 4, the subsequent operation of the cooperation support system 100 is as follows.

  When the user (Doctor Nozaki) clicks (selects) a selection button 156 called “drug information” from the cooperation request / type selection screen 155, the cooperation support system 100 (cooperation request content input screen display unit 103) responds to it. The cooperation request content input screen 157 (see FIG. 10B) is displayed on the user terminal (step S209). In this case, on the cooperation request content input screen 157, as shown in FIG. 10B, three input fields of a disease name, a drug name, and a request content are provided. In these input fields, the user himself (Doctor Nozaki, the source of the cooperation request) needs to input as necessary (step S210). After inputting the information as shown in FIG. 10B, when the user (Doctor Nozaki) clicks the “Send” button on the cooperation request content input screen 157, the information entered and displayed on the cooperation request content input screen 157 (cooperation request content) Is transmitted to the cooperation support system 100 (cooperation request / timeline control unit 102) and registered (step S211).

  After that, the cooperation support system 100 (cooperation request destination information management unit 105) displays the registered cooperation request destination group selection screen 158 (see FIG. 11) on the user terminal (step S212), so that the user (Doctor Nozaki) Referring to the registered cooperation request destination group selection screen 158, it is determined whether or not to select a registered cooperation request destination group (step S213). Here, we want information about the drug ABC for type I diabetes, but there seems to be no member who is likely to provide it in the registered cooperation request destination group. Then, a “cancel” button is clicked to display a cooperation request destination member selection screen 159 (see FIG. 12) on the user terminal (step S215). In this case, since all members that can be selected as cooperation destination candidates are displayed in a list on the cooperation request destination member selection screen 159, a hospital that seems to have information on the administration method of the drug ABC from among them. A member (cooperation candidate) such as a pharmaceutical company or a research institute is selected (step S216). Then, a new cooperation request destination group is created with the selected member (step S217). Specifically, as shown in FIG. 13, in the cooperation request destination member selection screen 159, the check box 160 of “Register this group in my group” is checked, and a new group name is displayed in the input field 161. For example, “drug ABC information group” is input (step S218). After completing the input, click the “Send” button to register a new cooperation request destination group name (step S219), and further register the selected cooperation request destination member (step S220).

  In this case, since there is no existing cooperation request timeline (step S221), both the cooperation request timeline and the thread area are newly generated (step S223). Then, in the new cooperation request timeline, the content of the cooperation request “information request about type I diabetes medicine ABC” shown in FIG. 10B is displayed as “cooperation request information”, and in the thread area, A message of the cooperation request sender (Doctor Nozaki) is displayed (for example, “If you know you are in a hurry, please urgently teach me.”) (Step S224). Further, the content of the cooperation request is displayed as “cooperation request information” on the theme timeline related to the cooperation request, for example, “diabetes medicine timeline” (step S225). At the same time, the content of the cooperation request is sent to all the selected cooperation request destination members in the form of e-mail. All members of the requested theme timeline (here, the diabetes drug timeline) will be informed promptly.

  At this time, the display mode of the cooperation request content (cooperation request information) on the theme timeline (here, the diabetes drug timeline) related to the cooperation request is as shown in FIG. 14, for example. That is, the cooperation request content “request for providing information on type I diabetes medicine ABC” is displayed in the form of a cooperation request notification panel 162 in which the three items shown in FIG. 10B are displayed in a list as in FIG. Appears on the diabetes drug timeline. In the diabetes drug timeline, only the cooperation request information is displayed on the cooperation request notification panel 162, and the thread 153 related to the contents of the cooperation request is not displayed. In the cooperation request notification panel 162, a status display button 163 similar to that in FIG. 14 is displayed.

  Moreover, the display mode of the cooperation request content on the cooperation request / timeline 165 at this time is, for example, as shown in FIG. That is, the cooperation request content “request for providing information about type I diabetes medicine ABC” is in the form of a cooperation request notification panel 162 in which the three items shown in FIG. Are displayed in the cooperation request timeline 165. This is the same as in the corresponding diabetes drug timeline. However, the cooperation request timeline 165 is different from the diabetes drug timeline in that the thread 153 related to the cooperation request content is also displayed. In the cooperation request notification panel 162, a status display button 163 similar to that shown in FIG. 15 is displayed.

  In the cooperation request timeline 165, as in FIG. 15, a confirmation button 166 is displayed in the message from the cooperation request destination member in the thread 153, and the user (Doctor Nozaki) who wants to select the cooperation request originates. By clicking the link request destination member confirmation button 166, the link request destination member (a person who can provide information on the type I diabetes medicine ABC) can be determined.

  In the cooperation request timeline 165, each cooperation request destination member exchanges a message with the user (Doctor Nozaki) of the cooperation request originator in the existing or new cooperation request timeline 165, and relates to the cooperation request. It is examined whether or not “information about type I diabetes drug ABC” can be provided (step S226). One or a plurality of cooperation request destination members determined to be able to provide can be expressed by posting a message in the cooperation request timeline 165 to indicate “can be provided”. The user (Dr. Nozaki) who is the origin of the collaboration request is a member of one or more collaboration request destinations who have expressed “available” by reading a post in the collaboration request timeline 165 and he or they belong What is necessary is just to compare and examine the medical related facility F, and to select and determine the optimal member and the facility F.

  The message posted in the cooperation request timeline 165 is, for example, as follows.

  As a result of the comparison, when one member and the facility F are determined, the cooperation request transmission source user (Doctor Nozaki) clicks the confirmation button 166 of the cooperation request destination member to be selected (step S227). Then, the confirmed cooperation destination (selected / decided cooperation request destination member) is registered (step S228), and the cooperation destination member is automatically invited to the diabetes drug timeline (step S229). The invited partner member is displayed with the face photograph added to the diabetes drug timeline (step S230). This state is the same as in FIGS.

  The display mode of the cooperation request content on the cooperation request / timeline 165 after confirmation is performed as shown in FIG. 16, for example. As shown in the figure, the status display button 163 in the request notification panel 162 is displayed as “Confirmed”. In addition, the confirmation button 166 in the thread 153 changes to a pressed state.

  The display mode of the cooperation request content to the diabetes drug timeline after confirmation is performed as shown in FIG. 17, for example. As shown in the figure, the status display button 163 in the cooperation request notification panel 162 is displayed as “confirmed”. In the member list of the Diabetes Medicine timeline, face photos of all members are displayed side by side, but a face photo of the confirmed partner member (selected / decided partner request member) is added. Is displayed.

(When collaborating on nutritional guidance)
Next, a case where the user (Doctor Nozaki) selects the type “nutrition guidance” in step S208 of FIG. 4 will be described.

  When the user (Doctor Nozaki) clicks (selects) the selection button 156 “Nutrition Guidance” from the cooperation request type selection screen 155, the cooperation support system 100 (cooperation request content input screen display unit 103) responds accordingly. The cooperation request content input screen 157 (see FIG. 10C) is displayed on the user terminal (step S209). In this case, on the cooperation request content input screen 157, as shown in FIG. 10C, three input fields of a disease name, nutrients, and request content are provided. In these input fields, the user himself (Doctor Nozaki, the source of the cooperation request) needs to input as necessary (step S210). After inputting the information as shown in FIG. 10C, when the user (Doctor Nozaki) clicks the “Send” button on the cooperation request content input screen 157, the information entered and displayed on the cooperation request content input screen 157 (cooperation request content) Is transmitted to the cooperation support system 100 (cooperation request / timeline control unit 102) and registered (step S211).

  After that, the cooperation support system 100 (cooperation request destination information management unit 105) displays the registered cooperation request destination group selection screen 158 (see FIG. 11) on the user terminal (step S212), so that the user (Doctor Nozaki) Referring to the registered cooperation request destination group selection screen 158, it is determined whether or not to select a registered cooperation request destination group (step S213). Here, he wants nutritional guidance for hypertensive patients, but there seems to be no member in the registered cooperation request group that is likely to provide it. Then, a “cancel” button is clicked to display a cooperation request destination member selection screen 159 (see FIG. 12) on the user terminal (step S215). In this case, the cooperation request destination member selection screen 159 displays a list of all members that can be selected as cooperation destination candidates, and from this list, hospitals, laboratories, etc. that are supposed to be able to provide nutritional guidance for hypertensive patients. Members (cooperation destination candidates) are selected (step S216). Then, a new cooperation request destination group is created with the selected member (step S217). As a new group name, for example, “hypertension nutrition instruction group” is input (step S218). After completing the input, click the “Send” button to register a new cooperation request destination group name (step S219), and further register the selected cooperation request destination member (step S220).

  In this case, since there is no existing cooperation request timeline (step S221), both the cooperation request timeline and the thread area are newly generated (step S223). Then, in the new cooperation request timeline, the content of the cooperation request “nutrition instruction request for hypertension patient” shown in FIG. 10C is displayed as “cooperation request information”, and in the thread area, the cooperation request sender ( Dr. Nozaki) 's message (for example, “I am in a hurry, if you know, please give me urgent guidance.”) (Step S224). Further, the content of the cooperation request is displayed as “cooperation request information” on the theme timeline related to the cooperation request, for example, the “hypertension nutrition guidance timeline” (step S225). At the same time, the content of the cooperation request is sent to all the selected cooperation request destination members in the form of e-mail. All members of the requested theme timeline (here, hypertension nutrition guidance timeline) will be informed promptly.

  The display mode of the content of the cooperation request (cooperation request information) on the theme timeline (here, the hypertension nutrition guidance timeline) related to the cooperation request at this time is, for example, as shown in FIG. That is, the cooperation request content of “nutrition instruction request for hypertensive patient” is in the form of a cooperation request notification panel 162 in which the three items shown in FIG. Displayed on the line. In the hypertension nutrition instruction timeline, only the cooperation request information is displayed on the cooperation request notification panel 162, and the thread 153 related to the cooperation request content is not displayed. In the cooperation request notification panel 162, a status display button 163 similar to that in FIG. 14 is displayed.

  Moreover, the display mode of the cooperation request content on the cooperation request / timeline 165 at this time is, for example, as shown in FIG. That is, the content of the cooperation request “nutrition instruction request for hypertension patient” is the cooperation request time in the form of the cooperation request notification panel 162 in which the three items shown in FIG. Displayed on line 165. This is the same as in the corresponding hypertension nutrition guidance timeline. However, the linkage request timeline 165 is different from the hypertension nutrition guidance timeline in that the thread 153 related to the linkage request content is also displayed. In the cooperation request notification panel 162, a status display button 163 similar to that shown in FIG. 15 is displayed.

  In the cooperation request timeline 165, as in FIG. 15, a confirmation button 166 is displayed in the message from the cooperation request destination member in the thread 153, and the user (Doctor Nozaki) who wants to select the cooperation request originates. By clicking the link request destination member confirmation button 166, the link request destination member (a person who can perform nutritional guidance for a hypertensive patient) can be determined.

  In the cooperation request timeline 165, each cooperation request destination member exchanges a message with the user (Doctor Nozaki) of the cooperation request originator in the existing or new cooperation request timeline 165, and relates to the cooperation request. It is examined whether or not “nutrition guidance for hypertensive patients” can be performed (step S226). One or a plurality of cooperation request destination members determined to be instructed express a message “instructible” by posting a message in the cooperation request timeline 165. The user (Dr. Nozaki) who is the origin of the collaboration request is a member of the collaboration request timeline 165, and one or more collaboration request destination members who have expressed "can be instructed" and he or they belong. Compare and review facilities, and select and determine the best members and facilities.

  As a result of the comparison, when one member and the facility F are determined, the cooperation request transmission source user (Doctor Nozaki) clicks the confirmation button 166 of the cooperation request destination member to be selected (step S227). Then, the confirmed cooperation destination (selected / decided cooperation request destination member) is registered (step S228), and the cooperation destination member is automatically invited to the hypertension nutrition guidance timeline (step S229). The invited partner member is displayed with the face photograph added to the hypertension nutrition guidance timeline (step S230). This state is the same as in FIGS.

  The display mode of the cooperation request content on the cooperation request / timeline 165 after confirmation is performed as shown in FIG. 16, for example. As shown in the figure, the status display button 163 in the request notification panel 162 is displayed as “Confirmed”. In addition, the confirmation button 166 in the thread 153 changes to a pressed state.

  The display mode of the cooperation request content to the hypertension nutrition guidance timeline after confirmation is performed as shown in FIG. 17, for example. As shown in the figure, the status display button 163 in the cooperation request notification panel 162 is displayed as “confirmed”. In the member list of the Hypertension Nutrition Guidance Timeline, the face photos of all members are displayed side by side, but the face photo of the confirmed partner member (selected / decided partner request destination member) is added Displayed.

(Contents of medical support system and medical support service)
The configuration and operation of the cooperation support system 100 are as described above. Since the cooperation support system 100 operates on the medical support system 30, the medical support system 30 and the medical support service provided by the medical support system 30 are subsequently provided. Will be described.

(Overall configuration when using medical support service)
FIG. 18 shows an overall configuration (conceptual diagram) when using a medical support service provided by the medical support system 30.

  As shown in FIG. 18, the patient terminal 10 owned by the patient P after the patient P, the patient-related person R, or the medical worker M who wishes to use the medical support service registers the user by a predetermined method. Or a medical worker terminal 11 operated by a medical worker M or a patient-related terminal 12 owned by a patient-related person R (these terminals are collectively referred to as a “user terminal”), which is a communication network. 20 is used.

  The patient P, patient-related person R, or medical worker M who has registered as a user becomes a “user” of this medical support service. Since this medical support service is realized by the medical support system 30, the “user” of this medical support service can also be referred to as the “user” of the medical support system 30. A patient P, patient-related person R, or medical worker M who is not registered as a user cannot use this medical support service.

  When an instruction is sent from any one of the user terminals 10, 11, or 12 to the medical support system 30 via the Internet 20, the “user registration” described later is performed by the operation of hardware and software installed in the medical support system 30. Various operations and functions such as “group generation”, “invitation to group”, “message transmission / reception (communication)”, “family registration”, and “browsing medical information” are executed. In addition, by doing so, while maintaining the privacy of the patient P, the medical information of each patient and the exchanged message can be exchanged between a plurality of medical workers M, between the patient P and the medical worker M, or It becomes possible to share between the patient P, the medical worker M, and the patient person R, and it becomes possible to provide better medical services to the individual patients P based on the shared medical information and messages. .

  The patient terminal 10 and the patient-related terminal 12 are usually mobile terminals such as mobile phones and smartphones, and individual patients P and patient-related persons R own their own terminals. A personal computer (personal computer) or a touch panel type terminal can also be used. Since the medical worker terminal 11 is often installed in a medical facility, it is usually a desktop or notebook personal computer, but it goes without saying that a touch panel terminal or a portable terminal can also be used. In short, these terminals 10, 11, and 12 may be any terminal devices that can transmit, receive, and display information with the medical support system 30 via the Internet 20, and their forms and configurations are not limited.

  Each patient P suffers from one or more diseases and receives medical services such as diagnosis and treatment from a medical worker M belonging to the specific medical facility F. In order to simplify the explanation, in the present embodiment, it is assumed that only two patients P1 and P2 are using this medical support service, but it goes without saying that more patients P actually use it. Yes.

  The patient-related person R refers to a person who is related to the patient P in some form, such as the family, relatives, friends, and acquaintances of the individual patient P. Even if the medical worker M is a family member, relative, friend, or acquaintance of a patient P, it can be a patient related person R of the patient P. Here, it is assumed that eight patient personnel R1, R2, R3, R4, R5, R6, R7 and R8 are participating, but depending on the circumstances of patient P, more or Needless to say, fewer patients R may use it.

  The medical worker M refers to a person engaged in medical care in a medical facility F such as a doctor or a nurse. The medical worker M belongs to various medical-related facilities F such as clinics (small-scale clinics), hospitals (medium-scale / large-scale medical facilities), and home-visit nursing stations with specialized fields. F provides medical services such as diagnosis and treatment to the patient P. Here, it is assumed that only eight medical workers M1, M2, M3, M4, M5, M6, M7 and M8 are participating, but in reality, more or fewer medical workers M It goes without saying that will participate.

  The medical-related facility F refers to a facility where a medical service is provided to the patient P by the medical worker M, for example, a small clinic (clinic), a larger hospital, a visiting nursing station, or the like. Any facility that provides medical services such as diagnosis, treatment, nursing, care, examination, surgery, consultation, etc. is sufficient.

  Further, in FIG. 18, the patient P, the medical worker M, and the patient person R are depicted as possessing the terminals 10, 11, and 12, respectively, but the present invention is not limited to this. Each of the patient P, the patient-related person R, and the medical worker M has identification information (user ID) that can be uniquely identified, and is distinguished even if logged in to the medical support system 30 from the same terminal. There is no problem even if multiple people share it.

  FIG. 19 shows the interrelationship between the patients P1 and P2, who are users of the medical support system 30, the patient personnel R1 to R8, and the medical workers M1 to M8 who are using the medical support system 30. It is explanatory drawing.

  In the medical support system 30, a patient group G is registered for each disease of each patient P. That is, a separate patient group G is formed for each disease that each patient P has. The person (participant) (that is, group member) who participates in each patient group G is usually a medical person in charge belonging to the medical facility F in which the patient P is receiving treatment in addition to the patient P himself / herself. It includes at least one worker M, and further includes a patient-related person R added as necessary. Therefore, the group member of each patient group G is generally composed of the patient P himself, the medical staff M in charge, and the patient personnel R.

  In general, any one of the medical facilities F to which the medical staff M who participates in each patient group G belongs is “family registered” with respect to the patient group G (and thus the patient P). . The medical-related facility F that is “family registered” is mainly responsible for the overall treatment policy for the disease of the patient P related to the patient group G.

  However, the configuration of group members is not limited to such a case. For example, there may be a case where only the patient P and one or more medical workers M are group members (not including patient personnel R), or only a plurality of medical workers M are group members (patient P). Or patient-related person R). The former occurs, for example, when the patient P does not want to inform the patient person R of his / her medical information. The latter occurs when it is desired to share the medical information of the patient P among a plurality of medical workers M who are involved in the treatment of the patient P but do not want the patient P to be informed. If the patient P is not included as a group member, approval for sharing of medical information cannot be obtained from the patient P on the medical support system 30, so that it is obtained outside the medical support system 30 separately. For example, approval may be obtained in writing. Of course, only the process in which the patient P approves the digitized document or the like may be added to the medical support system 30 for convenience. It goes without saying that a subsystem for obtaining approval for sharing medical information from the patient P may be separately incorporated in the medical support system 30.

  A participant (group member) excluding the patient P himself / herself in each patient group G is called a “supporter” regardless of the patient-related person R as a medical worker M. This is because they support the patient P in some way. Therefore, if the group member of each patient group G includes the patient P, it can be said that the patient is composed of the patient P himself and at least one supporter. When the patient P is not included, it can be said that the patient P is composed of only a plurality of supporters.

  In this embodiment, as is clear from FIG. 19, the patient P1 suffers from three diseases (here, diabetes, hyperlipidemia, and gout), and the patient group G11 for each of the three diseases of the patient P1. , G12 and G13 are generated, and a medical facility F is associated with each patient group G. Specifically, the clinic F1 is registered for the patient group G11 for treating diabetes, the clinic F2 is registered for the patient group G12 for treating hyperlipidemia, and patients for gout treatment are registered. The hospital F3 is registered for the group G13. Thus, here, patient P1 belongs to three patient groups G11, G12, and G13. As will be described later, in the patient groups G11, G12, and G13, the medical workers M who belong to the clinic F1, the clinic F2, and the hospital F3 that are registered as family members also belong.

  The patient P2 suffers from two diseases (here, Alzheimer and hypertension), and patient groups G21 and G22 are generated for each of the two diseases of the patient P2. Are associated. Specifically, the hospital group F21 is registered for the Alzheimer treatment patient group G21, and the home care station F4 is registered for the patient group G22 for hypertension treatment. Thus, patient P2 belongs to two patient groups G21 and G22 here. As will be described later, in the patient groups G21 and G22, medical workers M who belong to the hospital F3 and home-visit nursing station F4, which are registered as family members, belong respectively.

  As described above, patient group G11 is a group for treating diabetes of patient P1, patient group G12 is a group for treating hyperlipidemia of patient P1, and patient group G13 is a group for treating gout of patient P1. The patient group G21 is a group for treating Alzheimer's of the patient P2, and the patient group G22 is a group for treating hypertension of the patient P2. Thus, since the patient group G is created for each disease that the individual patient P has, medical information regarding the specific disease of the specific patient P is shared within each patient group G. As a result, a higher quality medical service can be provided.

  The medical worker M1 is a doctor and belongs to the clinic F1, and belongs to the diabetes treatment group G11 and the gout treatment group G13 of the patient P1 as a supporter. The medical worker M2 is a nurse, belongs to the same clinic F1 as the medical worker M1, and belongs to the diabetes treatment group G11 of the patient P1 as a supporter.

  The medical worker M3 is a doctor who belongs to the clinic F2 and belongs to the hyperlipidemia treatment group G12 of the patient P1 as a supporter. The medical worker M4 is a nurse, belongs to the same clinic F2 as the medical worker M3, and belongs to the hyperlipidemia treatment group G12 of the patient P1 as a supporter.

  The medical worker M5 is a doctor who belongs to the hospital F3 and belongs to the diabetes treatment group G13 of the patient P1 as a supporter. The medical worker M6 is a doctor, belongs to the same hospital F3 as the medical worker M5, and belongs to the group G11 for treating diabetes of the patient P1, the group G21 for treating Alzheimer and the group G22 for treating hypertension of the patient P2, as supporters doing.

  The medical worker M7 is a nurse, belongs to the home-visit nursing station F4, and belongs to the Alzheimer treatment group G21 of the patient P2 as a supporter. The medical worker M8 is a nurse, belongs to the same visiting nursing station F4 as the medical worker M7, and belongs to the hypertension treatment group G22 of the patient P2 as a supporter.

  The patient-related person R1 is a family of the patient P1, and belongs as a supporter to the diabetes treatment group G11 and the gout treatment group G13 of the patient P1. The patient-related person R2 is a relative of the patient P1, and belongs to the diabetes treatment group G11 of the patient P1 as a supporter. Patient-related person R3 is the family of patient P1, and belongs to the group G12 for treating hyperlipidemia of patient P1 as a supporter. The patient-related person R4 is a friend of the patient P1, and belongs to the diabetes treatment group G11 of the patient P1 as a supporter. The patient-related person R5 is a friend of the patient P1, and belongs to the group G13 for treating gout of the patient P1 as a supporter.

  The patient-related person R6 is a family of the patient P2, and belongs to the Alzheimer treatment group G21 of the patient P2 as a supporter. Patient-related person R7 is a relative of patient P2, and belongs to Alzheimer's treatment group G21 of patient P2 as a supporter. Patient-related person R8 is the family of patient P2, and belongs to group P22 for treating hypertension of patient P2 as a supporter.

  As described above, in the medical support system 30, patient groups G11, G12, and G13 are formed for each of the three diseases (here, diabetes, hyperlipidemia, and gout) that the patient P1 has. A clinic F1, a clinic F2, and a hospital F3 are registered as family members in G11, G12, and G13, respectively. Therefore, the medical workers M1 and M2 who belong to the clinic F1 are in charge of treating the disease (here, diabetes) of the patient group G11 of the patient P1 as the attending physician. The medical workers M3 and M4 who belong to the clinic F2 are in charge of treating the disease (here hyperlipidemia) of the patient group G12 of the patient P1 as the attending physician. Medical workers M5 and M6 belonging to the hospital F3 are in charge of treating a disease (here, gout) of the patient group G13 of the patient P1 as the attending physician.

  The patient personnel R1, R2, and R4 who belong to the patient group G11 of the patient P1 consult with the patient P1 and the medical workers M1 and M2 on the treatment policy for diabetes of the patient P1, and so on. To help. According to the sharing rules approved by the patient P, sharing and communication of medical information on diabetes among the patient P1, the medical workers M1 and M2, and the patient personnel R1, R2 and R4 belonging to the patient group G11 ( Message exchange).

  The patient-related person R3 who belongs to the patient group G12 of the patient P1 takes the patient P1 by consulting with the patient P1 and the medical workers M3 and M4 on the treatment policy for the hyperlipidemia of the patient P1. Support. According to the sharing rules approved by the patient P, the sharing of medical information and communication (message) between the patient P1, the medical workers M3 and M4, and the patient-related person R3 who belong to the patient group G12 Exchange) is possible.

  The patient personnel R1 and R5 who belong to the patient group G13 of the patient P1 support the patient P1 by consulting with the patient P1 and medical workers M5 and M6 on the treatment policy for the gout of the patient P1. To do. According to the sharing rules approved by the patient P, the medical information regarding gout is shared and communicated (message exchange) between the patient P1, the medical workers M1 and M5, and the patient personnel R1 and R5 who belong to the patient group G13. Is possible.

  Similarly, patient groups G21 and G22 are formed for each of two diseases (here, Alzheimer's and hypertension) that the patient P2 has, and each of these patient groups G21 and G22 includes a hospital F3 and a visiting nursing station F4, It is registered family. Therefore, the medical workers M5 and M6 belonging to the hospital F3 are in charge of treating the disease (here, Alzheimer) of the patient group G21 of the patient P2 as the attending physician. The medical workers M7 and M8 belonging to the home-visit nursing station F4 are in charge of treating the disease (here, hypertension) of the patient group G22 of the patient P2 as the attending physician.

  The patient personnel R6 and R7 who belong to the patient group G21 of the patient P2 support the patient P2 by consulting with the patient P2 and the medical workers M6 and M7 on the treatment policy for the Alzheimer of the patient P2. To do. According to the sharing rules approved by the patient P, sharing and communication of medical information about Alzheimer (message exchange) between the patient P2, the medical workers M6 and M7, and the patient personnel R6 and R7 who belong to the patient group G21 Is possible.

  The patient person R8 who belongs to the patient group G22 of the patient P2 supports the patient P2 by consulting with the patient P2 and the medical workers M6 and M8 on the treatment policy for the hypertension of the patient P2. Among the patients P2, medical workers M6 and M8, and patient-related personnel R7 who belong to the patient group G22, medical information sharing and communication (message exchange) regarding hypertension is performed according to the sharing rules approved by the patient P. Is possible.

  Various functions necessary for realizing the above-described sharing of medical information and communication (message exchange) within each patient group G are described below from the patient terminal 10, the medical staff terminal 11, or the patient-related terminal 12 as will be described later. Provided by the medical support system 30 in response to the request or instruction.

(Configuration and function of medical support system)
Next, the configuration and function of the medical support system 30 will be described with reference to FIG. FIG. 20 is a functional block diagram showing the internal configuration of the medical support system 30.

  As illustrated in FIG. 20, the medical support system 30 includes a user management unit 310, a group management unit 320, an authentication unit 340, and a communication control unit 350.

  The communication control unit 350 is connected to the medical support system 30 and a plurality of user terminals (that is, the patient terminal 10, the medical worker terminal 11, and the patient related person) via the Internet 20 as a communication network provided outside the medical support system 30. This is a section that enables transmission / reception of information to / from the terminal 12). Since the communication control process of the communication control unit 350 is executed by a known method, the description thereof is omitted.

  The authentication unit 340 authenticates whether a person who has accessed the medical support system 30 from the user terminal 10, 11, or 12 via the Internet 20 is an authorized user who has received user registration in the medical support system 30. The section to do.

  The authentication unit 340 is connected to the Internet 20 provided outside the medical support system 30 via the communication control unit 350. The user management unit 310 and the group management unit 320 are connected to the patient terminal 10, the medical worker terminal 11, and the patient-related person terminal 12 outside the medical support system 30 on condition that the authentication unit 340 obtains predetermined authentication. Send and receive information between them. Only when the authentication unit 340 authenticates as a regular user, the person is permitted to access the user management unit 310 and the group management unit 320. Only then will the user be able to use the medical support service provided by the medical support system 30.

  The user authentication process in the authentication unit 340 is performed by a known method. For example, in response to a user request, a predetermined login screen (see FIG. 33B) is displayed on the user terminal 10, 11 or 12, and the user identification information (ID) and password (PW) input on the screen are displayed. Then, it is determined whether or not it matches what is registered in the user management unit 310. If they match, it is determined that the user is a regular user, and access to the user management unit 310 and the group management unit 320 is permitted. If they do not match, it is determined that the user is not a regular user, and access to the user management unit 310 and the group management unit 320 is denied.

  Next, the user management unit 310 will be described.

  The user management unit 310 registers individual users who use medical services provided by the medical facility F or users who support the users, that is, patients P, medical workers M, and patient personnel R (user registration). ) And a section for managing registered users. The user management unit 310 includes a registration unit 311, a user information storage unit 312, a patient information storage unit 313, a medical worker information storage unit 314, a medical related facility information storage unit 315, and a disease information storage unit 316.

  The registration unit 311 is formed from software that controls the operation thereof, and controls operations related to general user registration in the user management unit 310. For example, a predetermined user registration screen (see FIG. 33A) is displayed on the user terminal 10, 11, or 12 that has accessed the medical support system 30, and a person who wants to use the medical support service (a user who wants to use the medical support service). The user is prompted to input and transmit predetermined personal information. Accordingly, when predetermined personal information is transmitted from the user terminal 10, 11 or 12 to the medical support system 30, the personal information is stored in the user information storage unit 312 as “user information” of the user who wants to use it. . Further, the registration unit 311 reads out and uses the user information stored in the user information storage unit 312 as necessary, and corrects / deletes the user information.

  The user information storage unit 312 is formed from an information storage medium such as a hard disk and software that controls operations such as recording, reproduction, and erasing information on the information storage medium, and in accordance with instructions from the registration unit 311, user information That is, necessary information of the patient P, the medical worker M, and the patient person R as a user is stored. At this time, “user identification information” (user ID) that can be uniquely identified is assigned to each user.

  The user information is stored, for example, in the form of a user table as shown in FIG. The items of this user table include “user ID” (user identification information) assigned to each user, “login ID” and “password” necessary for each user to log in to the medical support system 30, and each user. “Registration date”, which is the date of registration in the medical support system 30, and “status” indicating the validity / invalidity of each user's registration. As the “login ID” assigned to each user and stored, the “mail address” applied by the user at the time of user registration is used. This is the same as the assigned “user ID” (user identification information). This is to make a one-to-one correspondence with a person who applied for user registration (a person who wants to use it). However, it is also possible to assign a unique character string or the like to the login ID with the mail address as a separate item. The “password” is assigned for user authentication. The “registration date” is an item provided to record the date when each user can use the medical service. “Status” is provided to record whether each user's registration is valid and the medical service is available, or whether the registration is invalid and the medical service cannot be used. Item.

  The patient information storage unit 313 is formed of an information storage medium such as a hard disk and software for controlling operations such as recording, reproduction, and deletion of information on the information storage medium, and in response to an instruction from the registration unit 311, the patient P Remember your personal information. At this time, a “patient ID” that can be uniquely identified is assigned to each patient P. The “patient ID” is “patient identification information” and “service recipient identification information”.

  The personal information of the patient P is stored, for example, in the form of a patient table as shown in FIG. The items of this patient table include “patient ID” (service recipient identification information) assigned to each patient P, “user ID” (user identification information) possessed by each patient P, and “patient name” of each patient P. "," Sex "," birth date "," mail address "," address "and" phone number ". As the “mail address”, the mail address applied by the user at the time of user registration is usually used, but a different mail address may be used.

  The medical worker information storage unit 314 is formed from an information storage medium such as a hard disk and software for controlling operations such as recording, reproduction, and erasing of information on the information storage medium, and according to instructions from the registration unit 311, The personal information of the medical worker M is stored. At this time, a “medicine ID” that can be uniquely identified is assigned to each medical worker M. This “medical worker ID” is “medical worker identification information” and is also “business worker identification information”.

  The personal information of the medical worker M is stored, for example, in the form of a medical worker table as shown in FIG. The items of this medical worker table include “medical worker ID” (business worker identification information) assigned to each medical worker M, “user ID” (user identification information) possessed by each medical worker M, each “Medical-related facility ID” assigned to the medical-related facility F to which the medical worker M belongs, and “medical name”, “sex”, “birth date”, and “job type” of each medical worker M It has become. The “job type” column stores job types such as doctors and nurses.

  The medical-related facility information storage unit 315 is formed from an information storage medium such as a hard disk and software that controls operations such as recording, reproduction, and erasing information on the information storage medium, and according to instructions from the registration unit 311, Necessary information of the medical related facility F is stored. At this time, a “medical-related facility ID” that can be uniquely identified is assigned to each medical-related facility F. The “medical related facility ID” is “medical related facility identification information”.

  The necessary information on the medical facility F is stored in the form of a medical facility table as shown in FIG. The items of this medical related facility table include “medical related facility ID” (medical related facility identification information) assigned to each medical related facility F, “facility name”, “facility type”, “ “Medical subjects”, “Address”, “Telephone number”, “HP (Homepage)”, “Medical hours” and “Nearest station”. The “facility type” column stores the type of each medical-related facility F such as a medical clinic, a hospital, or a home-visit nursing station.

  The disease information storage unit 316 is formed from an information storage medium such as a hard disk and software for controlling operations such as recording, reproduction, and erasing information on the information storage medium, and in accordance with instructions from the registration unit 311 Remember. At this time, a “disease ID” that can be uniquely identified for each disease is assigned. This “disease ID” is “disease identification information”.

  The disease information is stored, for example, in the form of a disease table as shown in FIG. The items of this disease table include “disease ID” (disease identification information) assigned to each disease, “medical related facility patient ID” defined in the medical related facility patient table shown in FIG. "Disease name". “Medical-related facility patient ID” is identification information indicating the relationship (link) between the patient P and the medical-related facility F registered by the patient P. In the disease table, the “disease ID” is associated with the “medical-related facility patient ID”. The use of the “medical-related facility patient ID” facilitates the association between the patient P and the disease and the medical-related facility. This is because it can be done.

  Next, the group management unit 320 will be described.

  The group management unit 320 is a section that manages the patient group G registered and formed for each disease of the individual patient P in the medical support system 30. For example, in addition to registering a new patient group, it performs many functions such as storing group / member information, controlling invitation requests, timelines and messages, and family registration. The group management unit 320 includes a registration unit 321, a group information storage unit 322, a group / member information storage unit 323, an invitation request control unit 324, an invitation request information storage unit 325, a timeline control unit 326, a message control unit 327, a family facility. An information storage unit 328, a shared consent information storage unit 329, a patient reality verification unit 330, and an authentication unit 331 are included.

  The registration unit 321 is formed from software for controlling the operation, and generates and registers a patient group G for each disease of each patient P in response to a request from the medical worker M or the patient P. Further, in response to a request from the medical worker M or the patient P, a process related to “family registration” (specifically, associating the patient P with the disease and the medical facility F) described later is also executed.

  The patient group G is generated at the request of the medical worker M when the medical worker M performs “patient group registration”. “Patient group registration” refers to registering, in the medical support system 30, a patient P who is treated by a medical facility F to which a medical worker M belongs and the disease. At this time, the medical worker M designates the patient P who is treated by the medical facility F to which he / she belongs and the disease, and registers it in the medical support system 30. This is because the medical information of the patient P can be shared in the medical related facility F to which M belongs. The registration unit 321 automatically generates a patient group G in synchronization with “patient group registration”, and stores the information related to the generated patient group G in the group information storage unit 322.

  The initial group member of patient group G thus generated is zero unless a predetermined member (default member) is automatically invited. Neither the medical worker M who has performed “patient group registration” nor the patient P who has been subject to “patient group registration” is a group member. In order for a medical worker M who has performed “patient group registration” to become a group member, it is necessary to send an invitation request to himself and approve it. Similarly, in order for the patient P, who is the subject of “patient group registration”, to become a group member, it is necessary to send an invitation request to the patient P for approval.

  The patient group G is generated at the request of the patient P when the patient P requests “family registration”. At this time, the patient P selects one of the medical facilities F he / she is receiving treatment for, etc., requests “family registration”, and approves it to the medical facility F. So that This is because the patient P mainly designates a medical facility F that desires to receive treatment and is mainly responsible for the overall treatment policy. The registration unit 321 automatically generates a patient group G in synchronization with “family registration”, and stores the information related to the generated patient group G (patient group information) in the group information storage unit 322. In the “family registration”, the patient P, the disease, and the medical facility F are specifically associated.

  In the patient group G generated in this way, the initial group member is zero unless the default member is automatically invited. Neither the patient P who requested “family registration” nor the health care worker M of the medical facility F subject to “family registration” is a group member. In order for the patient P who requested "family registration" to become a group member, it is necessary to send an invitation request to himself and approve it himself. Similarly, in order for the medical worker M related to “family registration” to become a group member, the patient P who requested “family registration” needs to send an invitation request to the medical worker M for approval. .

  The group information storage unit 322 is formed from an information storage medium such as a hard disk and software for controlling operations such as recording, reproduction, and deletion of information on the information storage medium. Information indicating which disease of which patient P is related and which medical related facility F is registered as “family facility” is stored.

  “Patient group information” is stored, for example, in the form of a group table as shown in FIG. This group table includes “group ID” which is group identification information, “group name” indicating what kind of disease the patient group relates to, and “patient ID” defined in the disease table of FIG. "As an item.

  The group / member information storage unit 323 is formed of an information storage medium such as a hard disk and software for controlling operations such as recording, reproducing, and erasing information on the information storage medium. The group member information storage unit 323 includes patient group member information, that is, a patient P who can be said to be the owner of each patient group G, and a medical worker M who participates in each patient group G as a supporter of the patient P. Information related to the patient-related person R is stored.

  “Patient group / member information” is stored, for example, in the form of a group participation table as shown in FIG. This group participation table includes “group participation ID” which is identification information attached to the action “group participation” for a certain patient group G, “user ID” of users participating in the patient group G, It includes items of “group ID” of the participating patient group G and “accessible timeline” for designating a timeline accessible to each member. Using such a group participation table, it is possible to record the group members belonging to each patient group G, and which group members can access which timeline in each patient group G (ie, What access authority each group member has) can also be recorded.

  The invitation request control unit 324 is formed from software that controls the operation, and identifies a non-group member (that is, a patient P, a medical worker M, or a patient person R) who wants to participate in an individual patient group G. To control the “invite request” sent to those non-group members. The invitation request control unit 324 transmits an invitation request in the form of an e-mail to the specified non-group member in response to an instruction from the user, that is, the medical worker M or the patient P or the patient person R. Also, a reply (indicating whether or not the invitation request has been accepted) from the user who received the invitation request is received.

  The invitation request is an invitation in the form of an email sent to a user who wants to join the desired patient group G and become a group member. The invitation request can be sent by any of the patient P, the medical staff M, and the patient person R. However, before sending an invitation request to a user who wishes to participate in the patient group G, a predetermined administrator's It is necessary to get "permission". This is determined by the administrator in consideration of whether or not the user to be invited is suitable as a group member and whether or not any trouble is caused by the participation of the user. The manager includes a “medical worker manager” and a “patient manager”. The “medical worker administrator” is a medical worker M (also a user) who has the authority to “permit” or “reject” the transmission of the invitation request, for each medical facility F or for each patient group. Set to As the “medical worker manager”, for example, a clinic director or an office manager is designated. The “patient-side administrator” is a user who is given the authority to “permit” or “deny” the transmission of an invitation request from the patient P by the patient P himself (also a user) or a family member or friend of the patient P. It is set for each patient P or for each patient group. As the “patient side manager”, for example, the parent, spouse, child, close friend, etc. of the patient P is designated.

  Normally, both the “medical worker manager” and the “patient manager” both when the medical worker M sends an invitation request and when the patient P or the patient person R sends an invitation request. It is specified that an invitation request cannot be sent without permission. That is, setting is made so as to determine whether or not to send the invitation request in consideration of both the situation on the medical worker M side and the situation on the patient P side. This is because when a patient becomes a group member, the medical information and messages of the patient P can be browsed, and who becomes a group member has a large influence on both the patient P and the medical worker M. . However, it is not limited to this. If the permission of either “medical worker manager” or “patient manager” is obtained, an invitation request may be sent, or only the “medical worker manager” is allowed. If obtained, an invitation request may be transmitted. This point can be determined as needed or desired.

  Thus, in the medical support system 30, in order to “complete” the transmission of the invitation request (“invitation completion”), at least one of the “medical worker manager” and the “patient manager” "Permission" is required and adding group members does not cause problems.

  Users who receive an invitation request sent with the “permission” of both “healthcare manager” and “patient manager” or at least one of them will receive the patient group specified in the invitation request. In order to participate in G, the invitation may be “approved”. Then you are automatically added as a group member. When not participating in the patient group G, the invitation may be “rejected”. As described above, the user who has received the invitation request can select whether or not to participate in the patient group G by deciding whether or not to “approve” the invitation.

  The user who accepted the invitation becomes a member of the patient group G, but all the group members other than the patient P (specifically, the medical worker M and the patient-related person R) become supporters of the patient P. Among the group members, the medical information and messages of the patient P are shared according to the sharing rule selected by the patient P. Thus, for example, if you want to get a second opinion on your illness from a health care professional M at another medical-related facility F, or a family or relative who wants the patient P to know about the course of treatment for their illness, When there is a patient related person R such as a friend, an invitation request is transmitted to such a person. By carrying out like this, the medical information about the specific disease of the patient P of the medical related facility F, while ensuring the uniqueness, a plurality of medical workers M including medical personnel of other medical related facilities, and patient related personnel R, can be shared with P patient.

  The settings of “medical worker manager” and “patient manager” are stored in the invitation request information storage unit 325. The “permission” process by the “medical worker manager” and the “patient manager” is executed by the invitation request controller 324. The invitation request control unit 324 executes generation and transmission of an invitation request and reception of a reply from an invitation request recipient.

  The invitation request information storage unit 325 is formed of an information storage medium such as a hard disk and software that controls operations such as recording, reproduction, and deletion of information on the information storage medium. The invitation request information storage unit 325 generates “invitation request information” generated by the invitation request control unit 331 in response to the request, that is, various information indicating who sends the invitation request to whom, and an invitation request by the administrator. Stores information about permission or rejection. The contents of the reply from the recipient of the invitation request (approval of invitation request or permission / inhibition) and the settings of “medical worker manager” and “patient manager” are also stored.

  “Invitation request information” is stored, for example, in the format of the invitation request table shown in FIG. As items of this invitation request table, “invitation request ID” assigned to each invitation request, “invitation source user ID” which is identification information of a user who sends the invitation request, and whether or not the invitation request may be transmitted. "Invitation request permission" that is identification information, "Invitation request approval" that is whether the invitation request is approved by the invitee, "Invitation destination user ID" that is identification information of the other party to whom the invitation request is sent , “Invitation email address” and “Invitation passphrase” of the recipient (sending destination) to which the invitation request is sent, “Group ID” which is the identification information of the patient group to be invited, Timeline accessible to group members An "accessible timeline" that shows the code of is included. Thus, in this invitation request table, if there is an email address of the other party to whom the invitation request is sent and the negotiated invitation destination passphrase, the invitation request can be sent to anyone at any time.

  Note that the invitation request passphrase is included in the invitation request table of FIG. 23A because the person who received the invitation request is a legitimate invitation destination, in other words, the person himself / herself. This is for confirming whether or not there is a passphrase. In order for the person who received the invitation request to participate in the patient group of the invitation source related to the invitation request, the URL described in the email of the invitation request is accessed, and the invitation request approval screen displayed there It is necessary to enter a passphrase. If the entered passphrase does not match the “invite destination passphrase” stored in the invitation request table, it will be impossible to join that patient group. It can be done.

  The timeline control unit 326 is formed from software for controlling the operation, and controls a “patient timeline” (that is, an information display area) assigned to each patient group G. Specifically, an information display area called “patient timeline” is assigned to the newly generated patient group G, and the shared medical information is posted on the patient timeline in a predetermined order (for example, posted). Display in time order). Since the information to be displayed and the parameters such as the display time are sent from the medical staff terminal 11 to the group management unit 330 via the Internet 20, the timeline control unit 335 displays the sent information according to the parameters. Display on patient timeline.

  An example of a patient timeline is shown in FIG. The patient timeline 51 is generated for the patient group G11 for treating diabetes of the patient P1, and includes an all-person sharing area 51a and a healthcare worker sharing area 51b. In the all-member sharing area 51a, information shared by all members of the patient group G11 is displayed. In the medical worker sharing area 51b, information shared only by the medical worker M of the patient group G11 is displayed. Therefore, all the members of the patient group G11 can share the medical information displayed in the all-member sharing area 51a. In addition to the patient P1, the medical workers M1 and M2 belonging to the clinic F1, and the medical information belonging to the hospital F3. The worker M6 and patient personnel R1, R2, and R4 can freely post and view. In contrast to this, the medical information displayed in the medical worker shared area 51b can be shared only by the medical staff of the patient group G11, and belongs to the medical workers M1 and M2 belonging to the clinic F1 and the hospital F3. Medical worker M6 can freely post and view.

  In addition to the patient timeline assigned to each patient group G for the cooperation support system 100 that cooperates with the medical support system 30, the timeline control unit 326 corresponds to specific themes such as drug information provision and nutritional guidance. It is also modified to control the theme timeline that is assigned. Therefore, the timeline control unit 326 generates the theme timeline in the same format as the patient timeline for each specific theme such as information provision or nutritional guidance, and the member of the cooperation request destination group generated for each theme. And messages posted to the same theme / timeline from the source of the cooperation request are displayed in time series, for example. All members of the request group that correspond to the source of the request related to a specific theme can post messages to the theme timeline related to the theme, and can also view posted messages and various information. is there.

  The message control unit 327 is formed of software for controlling the operation, and controls transmission / reception of messages addressed from one group member to another group member. For this control, for example, the message transmission reservation table shown in FIG. The items of the message transmission reservation table include “transmission reservation ID” that is identification information assigned to each transmission reservation, “destination user ID” that is identification information of the user to whom the message is sent, and identification of the user who sends the message. The information is “sender user-ID” as information, “message” as the content to be transmitted, and “scheduled transmission date and time” in which the scheduled date and time when the message is transmitted is stored.

  The patient attribute table shown in FIG. 24B stores attributes of individual patients P, and is used when the message control unit 336 selectively transmits a predetermined message to some patients P. Is done. This patient attribute table includes “patient attribute ID” which is identification information given to the attributes of each patient P, “patient ID” of each patient P, “attribute name” of each patient P, and each patient P It has an item “attribute value”. The value “2013 health checkup guidance” stored in “attribute name” needs to be sent to this patient P as “2013 health checkup guidance” and is stored in “attribute value”. The value “not yet” indicates that the “2013 health check guide” has not been transmitted yet. Therefore, if a value of “2013 medical examination guidance” is stored in the “attribute name” and a patient ID whose “attribute value” is “not yet” is selected, a plurality of patients P having the same attribute are selected. Collectively, a “2013 health check-up guide” can be transmitted. Since the transmission can be reserved using the message transmission reservation table, it is very convenient.

  The family facility information storage unit 328 is formed of an information storage medium such as a hard disk and software for controlling operations such as recording, reproducing, and erasing information on the information storage medium. The family facility information storage unit 328 stores “family facility information” used and generated in the “family registration” (association between the patient P, the disease, and the medical related facility F) executed by the registration unit 321.

  The family registration process is as follows. As described above, “family registration” may be performed at the request of the medical worker M or at the request of the patient P. In the former case, the medical worker M asks the patient P, who is in charge of treatment, “Would you like to do family registration?” And if the patient P approves it, the registration unit 321 performs family registration. To do. In the latter case, “I want to register family members for the medical facility F that the patient P is receiving or is trying to receive (medical worker M belongs to). When the medical-related facility F (medical worker M) approves it, the registration unit 321 executes family registration.

  For the inquiry (inquiry) for family registration, the invitation request transmission function of the invitation request control unit 324 and the reception function of a reply to the invitation request are used. In other words, in a normal invitation request that asks the user to participate in the patient group G, a comment saying “I received an invitation to the patient group but would you like to participate?” In the invitation request for requesting registration, the comments as described above are attached, and both are different in this respect, and are otherwise the same. Therefore, an email for family registration request (family registration request) can be said to be a special case of an email for invitation request (group participation request).

  For example, a medical worker M who belongs to a certain medical related facility F registers the medical related facility F with respect to the disease for the patient P who is treating the disease that is his medical related facility F. When requesting, the registration unit 321 displays a predetermined family registration request screen on the medical worker terminal 11 in accordance with an instruction from the medical worker M. On that screen, after inputting the mail address of the patient P related to family registration, the user is prompted to send a family registration request. When the e-mail address is input and the “Send” button is clicked, the registration unit 321 transmits an e-mail of the family registration request to the e-mail address in the same format as the invitation request. When the patient P who has received the email for requesting family registration clicks the “approval” button included therein, the registration unit 321 includes information on the patient P related to family registration, information on the disease, and the medical facility F. Are associated with each other to generate “family facility information”, which is stored in the family facility information storage unit 328.

  Before sending a family registration request e-mail to the patient P, the registration unit 321 checks whether family facility information has already been generated in the same medical facility F for the same disease of the same patient P. If the same family facility information already exists, new family facility information is not generated, that effect is displayed on the medical staff terminal 11, and the family registration process is terminated. This is to prevent the situation where duplicate medical information about the same disease of the same patient P exists in the same medical related facility F by surely preventing duplication of family registration. Newly generating family facility information and storing it in the family facility information storage unit 322 is limited to the case where the same family facility information does not exist.

  The medical worker M and the patient P who belong to the medical-related facility F that has registered family members need to be members of the same patient group G. In order to share the medical information and message of the patient P between the group members and to improve the medical service provided to the patient P by the medical worker M, both of them must be members of the same patient group G. Because is a condition. However, the time to become a member of the patient group G may be before or after family registration. The patient group G is generated when the medical worker M performs “patient group registration” and when the patient P performs “family registration”. Unless the designated member (default member) is automatically invited, it is zero, so for the medical worker M and patient P related to family registration, send an invitation request as soon as possible It is preferable to have patient group G participate.

  The above-mentioned “family registration” is performed when the patient P approves a family registration request by the medical worker M, but the patient P himself / herself receives medical treatment for some disease. F can be voluntarily registered. In this case, the registration unit 321 displays a predetermined family registration screen on the patient terminal 10 in response to an instruction from the patient P, and prompts the patient P to designate a medical facility F for which family registration is desired. For example, the patient terminal 10 guides the user to select and designate a medical facility F desired to be registered for family care from the medical facilities F registered in the medical support system 30. What is necessary is just to urge to search and specify the medical facility F. When the patient P designates a specific medical related facility F and clicks the “family registration” button, the registration unit 321 associates the patient P related to the family registration, the disease, and the information of the medical related facility F with each other, The “facility information” is generated and stored in the family facility information storage unit 328. In this case, the patient P who has registered family members may be set as a default member. Then, since the patient P himself / herself becomes a group member from the beginning of the generation of the group G, it is not necessary to send an invitation request.

  For example, when the patient P1 voluntarily registers the medical facilities F1 and F2, the medical facilities F1 and F2 do not know whether the patient P1 is the same person before using the medical support system 30. It becomes possible to confirm that the medical information regarding different diseases of the patient P1 that has been handled separately belongs to the same person in the medical support system 30. For this reason, in the medical support system 30, medical information stored independently in different medical facilities can be integrated, managed, stored, and viewed as medical information of the same patient. Similarly, when the patient P1 is registered in the medical-related facilities F1, F2, F3... And three or more medical-related facilities, medical information regarding diseases in the three or more medical-related facilities is stored in the medical support system. At 30, they are integrated as those of the same patient P1 and can be managed centrally.

  The “family facility information” is stored, for example, in the form of a medical related facility patient table as shown in FIG. The items of this medical related facility patient table include the “medical related facility patient ID” assigned to each patient P who receives treatment at each medical related facility F, and the medical related facility shown in FIG. “Medical related facility ID” defined in the table, “Patient number” of the patient P in the medical related facility F, “Patient name”, “Gender”, “Birth date”, “Insurance” of the patient P "," Last visit date "," address "," phone number "," mail address ", and" passcode ". The “medical related facility patient ID” is identification information indicating the relationship between the patient P and the medical related facility F registered by the patient P. The “family related facility identification information” or “medical related facility / patient relationship identification” You can say "information". The “patient number” is identification information of the patient P who is receiving treatment or the like at the medical facility F. The “passcode” is information assigned to each patient P for identity verification, and is used when the patient P approves a family registration request.

  As described above, “family facility information” is stored in the family facility information storage unit 328. During the process, the registration unit 321 displays a predetermined sharing consent screen on the patient terminal 10, and the patient Ask whether P agrees to share medical information related to his specific disease within the medical facility F related to family registration. If this answer is “I do not agree to sharing”, the family registration is performed on the condition that medical information is not shared. An answer to the effect of “not agreeing to sharing” is also stored in the sharing agreement information storage unit 323. In this case, the merit of performing the family registration is only transmission / reception and sharing of messages between group members.

  If the patient P does not agree to share medical information, it may be set so that family registration itself is not performed.

  The medical support system 30 cannot share medical information among the medical workers M who belong to the patient group G because consent to the sharing of medical information cannot be obtained from the patient P until family registration is performed. However, this is inconvenient and there is a desire to share medical information among medical workers M in order to improve medical services. Therefore, if consent to the sharing of medical information is obtained from the patient P using a document or the like outside the medical support system 30, the medical support system 30 can share the medical information by setting that fact. However, the shared range in that case is limited to the medical workers M belonging to the patient group G.

  The registration unit 321 displays a predetermined sharing rule selection screen on the above-described medical information sharing inquiry screen, and prompts the user to select a sharing rule, that is, a medical information sharing range. For example, there are two sharing rule options, one is “shared only within the medical facility F related to family registration”, and the other is “the inside of the medical facility F related to family registration and the family registration” Shared by all group members, including the patient P who is involved. When any one of the sharing rules is selected, the registration unit 321 stores the reply “agree to share” and the selected sharing rule in the sharing agreement information storage unit 329.

  Needless to say, three or more sharing rules may be set. In this case, for example, in addition to the two rules described above, a rule that “the medical information of the patient P is shared but the message is not shared” can be added.

  The process for selecting the sharing rule of the medical information of the patient P described above is the same for both the family registration by the medical worker M and the family registration by the patient P.

  The shared consent information storage unit 329 is formed of an information storage medium such as a hard disk and software for controlling operations such as recording, reproduction, and erasing of information on the information storage medium. Willing to share medical information ”(shared consent information) and the selected sharing rule.

  The sharing agreement information and the selected sharing rule are stored, for example, in the form of a medical information sharing table shown in FIG. The items of the medical information sharing table are the “user ID” of the patient P, the “medical related facility ID” of the medical related facility F registered for family registration, and the “sharing rule” agreed by the patient P. In the medical information sharing table shown in FIG. 23C, the patient P whose user ID is “100” gives “in-hospital sharing permission” at the medical related facility F whose medical related facility ID is “1000”. The medical-related facility F with the facility ID “1001” gives “general sharing permission”.

  Here, “in-hospital sharing permission” means, for example, sharing limited to the clinic F1 in which the patient P1 is registered, that is, sharing limited to the medical workers M1 and M2 who belong to the clinic F1 Indicates that This means that medical information related to diabetes of the patient P1 is shared only between the medical workers M1 and M2 of the clinic F1 belonging to the patient group G11.

  “Comprehensive sharing permission” means, for example, not only the medical workers M1 and M2 who belong to the clinic F2 in which the patient P1 is registered, but also the patient P1 and the patient related persons of the patient P1 who participate as a supporter Indicates that you agree to share with R3. This is because medical information related to hyperlipidemia of the patient P1 is, in other words, between the medical personnel M3 and M4 of the clinic F2 belonging to the patient group G12, the patient P1 himself, and the patient concerned R3. Means shared by all group members.

  In the medical information sharing table shown in FIG. 23 (c), if the intention to disagree is shared, the family registration is executed, but the shared disagreement information is not stored in the medical information sharing table. It has become. However, it goes without saying that it may be memorized.

  The patient existence verification unit 330 is formed from software for controlling the operation, and “whether or not the patient P who requested the family registration actually exists”, in other words, “the patient P is the person himself / herself”. It is verified whether it is impersonation of others. This patient reality verification process is preferably performed prior to starting the family registration process described above.

  For example, when a new patient P visits a medical facility F where a medical patient M is present, the medical worker M (or staff) uses his / her own receipt computer with his / her patient number (different from the patient ID of the medical support system 30). Is input to the medical support system 30 and a temporary passcode is issued. As a result, a new patient user having the temporary passcode is provisionally registered in the medical support system 30 linked with the receipt computer. Therefore, the registered temporary passcode and the “registration form” printed with the user support URL (and QR code (registered trademark)) of the medical support system 30 are handed to the new patient P at the time of examination or reception, Access the URL on the patient terminal 10 and enter your patient number, your name, your date of birth, and the temporary passcode printed on the registration form on the displayed user registration screen. , Ask to register.

  Then, the patient existence verification unit 330 matches all of the patient number, name, date of birth, and temporary passcode entered and transmitted on the user registration screen with those temporarily registered in the medical support system 30. If they match, the regular user registration is performed. If they do not match, the regular user registration is rejected. In this way, whether the person who applied for user registration is the above-mentioned new patient P himself / herself can be verified based on whether or not the temporarily registered user can be registered as a regular user.

  This patient reality verification process can also be implemented using an NFC (Near Field Communication) terminal capable of near field communication. For example, when an NFC terminal is installed at the window of the medical facility F and the patient P contacts his / her patient terminal 10 with the NFC terminal, the terminal number of the NFC terminal is automatically set to the patient terminal 10 by infrared communication or the like. To be read. Then, a medical worker M or a staff member (for example, a clerk) of the medical facility F tells the patient P that “the patient terminal 10 is brought into contact with the NFC terminal installed at the window and then displayed on the patient terminal 10. "Please access the user registration URL of the medical support system 30 to be registered and register as a user." This eliminates the need for printing and distributing the temporary passcode on the “registration form”. The user registration process in this case is the same as that in the case of using the “registration sheet” described above.

  FIG. 23D shows an example of an NFC terminal table created for managing NFC terminals. The NFC terminal table includes a “medical related facility ID” assigned to each medical related facility F, an “NFC terminal number” assigned to each NFC terminal, and the medical related facility patient table of FIG. The “medical care facility patient ID” assigned to each patient in each medical care facility F and the “pass code” assigned to each patient P are defined. The passcode entered in the “passcode” column of the NFC terminal table is the same as the passcode entered in the “passcode” column of the medical-related facility patient table of FIG.

  The authentication unit 331 is formed from software that controls the operation thereof, and the patient P, the medical worker M, or the patient related person who has accessed the specific patient group G of the medical support system 30 via the user terminal. Check whether R is a legitimate member of the patient group G, in other words, is authorized to access the timeline of the patient group G. And if it is confirmed that it is a regular member, access to the timeline of the patient group G is permitted. If it is confirmed that the patient is not a regular member, access to the timeline of the patient group G is refused.

  The various tables used in the medical support system 30 have a relationship as shown in FIG. That is, the user table includes a patient table, a medical worker table, a medical information sharing table, and an invitation request table according to “user ID” (or “invitation source user ID”, “invitation destination user ID”, “sender user ID”). The patient table is further associated with the medical related facility table and the medical related facility patient table by “patient ID”. The medical worker table is further related to the medical facility table by “medical facility ID”. The medical related facility table is associated with the disease table, the medical information sharing table, and the NFC terminal management table by “medical related facility patient ID”. The group table is associated with a group participation table, an invitation request table, a timeline table, and a disease table. The NFC terminal management table is associated with the medical related facility table and the medical related facility patient table. The patient attribute table is associated with the patient table.

(Operation of medical support system)
Next, various operations of the medical support system 30 of the present embodiment having the above configuration will be described with reference to FIGS.

(user registration)
FIG. 27 is a flowchart showing a series of operations when a user who wishes to use the medical support service newly registers a user in the medical support system 30 of the present embodiment.

  As shown in FIG. 27, the registration unit 311 of the user management unit 310 of the medical support system 30 always waits for an access from a user who wants to use (step S11). When there is an access from a terminal of a user who wants to use (specifically, a medical worker M or a patient P or a patient-related person R), a predetermined “new user registration screen” is displayed on the terminal, The personal information is input and transmitted (step S12). The “new user registration screen” is, for example, as shown in FIG. 33A, and prompts the user who wishes to use the user to input his / her name and e-mail address for transmission. At that time, the user registration is prompted to select whether to register as “patient” or “healthcare professional”. This is because the services provided and the services that can be implemented differ greatly depending on which category is used for registration. Then, the registration unit 311 determines whether the personal information (name and email address) transmitted from the terminal is predetermined (step S13).

  If the received personal information is not the specified one, for example, if the e-mail address is not in the correct notation, an error / re-entry display will be displayed on the terminal of the user who wishes to use it, and the personal information will be entered again (step) S14). If the received personal information is predetermined, a user ID and a password (PW) are assigned to the received personal information and stored in the user information storage unit 312 (step S15). Then, an e-mail for notifying that the user registration is completed is transmitted to the received e-mail address and an assigned user ID and PW are notified. Thus, new user registration is completed.

(New patient registration)
The registration unit 311 requests the use applicant (new user) registered as a user as described above to register more detailed personal information. Since the items to be registered differ between the case of registration as a patient (patient registration) and the case of registration as a health care worker (health care worker registration), they will be described separately.

  FIG. 28A is a flowchart showing a series of operations when a user of the medical support service newly registers a patient in the medical support system 30 of the present embodiment.

  As shown in FIG. 28A, the authentication unit 340 of the medical support system 30 first displays a predetermined “login screen” on the patient terminal 10 of the patient P who has accessed, and prompts login (step S21). As the “login screen”, for example, the one shown in FIG. 33B is used. In response to this, the patient P inputs his / her user ID and PW on the “login screen” and clicks the send button displayed on the screen. The authentication unit 340 determines whether the received user ID and PW match the user ID and PW registered in the user information storage unit 312 of the user management unit 310 (step S22). If either or both of the user ID and PW do not match, an error is displayed and a re-input is prompted (step S23). When both the user ID and the PW match, the registration unit 311 of the user management unit 310 displays a predetermined new patient registration screen on the patient terminal 10 and prompts input of more detailed personal information (step S24).

  As the new patient registration screen, for example, the screen shown in FIG. 34A is used. In this case, since the name is automatically entered in the name field of the patient P by the registration unit 311, the patient P inputs his / her address, date of birth, telephone number, and e-mail address. ”And then click the send button.

  Then, the registration unit 311 determines whether the patient information transmitted from the patient terminal 10 is predetermined (step S25). If the received patient information is not predetermined, for example, if a telephone number has not been entered, or if the e-mail address is not correctly written, an error / re-input indication is displayed on the patient terminal 10, and the patient information The user is prompted to input again (step S26). If the received patient information is predetermined, a patient ID is assigned to the user ID related to the received patient information and stored in the patient information storage unit 313 (step S27). Then, an e-mail notifying that the patient registration has been completed and notifying the assigned patient ID is transmitted to the received e-mail address (step S28). Thus, new patient registration is completed. It should be noted that the notification of completion of patient registration and the communication of the patient ID may be performed by other methods such as displaying on the patient terminal 10 or handing a sheet on which the patient ID is printed to the patient without using e-mail. Needless to say.

(New medical worker registration)
Next, the case of registering as a medical worker (medical worker registration) will be described. FIG. 28B is a flowchart showing a series of operations when the user newly registers a medical worker.

  The process for registering a new healthcare worker is the same as the process for registering a new patient described above, except for the information to be registered. That is, as shown in FIG. 28B, the authentication unit 340 of the medical support system 30 first displays a predetermined “login screen” (see FIG. 33B) on the medical worker terminal 11 of the medical worker M who has accessed. The user is prompted to log in (step S31). In response to this, the medical worker M inputs his / her user ID and PW on the “login screen” and clicks the send button displayed on the screen. The authentication unit 340 determines whether or not the received user ID and PW match the user ID and PW registered in the user information storage unit 312 of the user management unit 310 (step S32). If either or both of the user ID and PW do not match, an error message is displayed to prompt re-input (step S33). When both the user ID and the PW match, the registration unit 311 of the user management unit 310 displays a predetermined new medical worker registration screen on the medical worker terminal 11 and prompts the user to input more detailed personal information (step) S34).

  As a new medical worker registration screen, for example, the screen shown in FIG. 34B is used. In this case, since the name is automatically input into the name column of the medical worker M by the registration unit 311, the medical worker M is in charge of the medical worker M's date of birth and the medical care to which he belongs. Enter the name of the related facility, the type of medical facility, the medical subject, the address of the medical facility, the telephone number, the homepage, the consultation time, the nearest station, and select “male” as the gender and “doctor” as the job type, for example. Then click the send button.

  And the registration part 311 judges whether the medical worker information transmitted from the medical worker terminal 11 is a predetermined thing (step S35). If the received medical worker information is not predetermined, for example, if a telephone number has not been entered or if the medical facility address is not in the correct notation, an error / re-input indication is displayed on the medical worker terminal 11 And prompting the user to input medical staff information again (step S36). If the received medical worker information is predetermined, the medical worker ID is assigned to the user ID related to the received medical worker information and stored in the medical worker information storage unit 314 (step S37). The received medical worker information and medical related facility information are stored in the medical worker information storage unit 314 and the medical related facility information storage unit 315, respectively. Then, to the e-mail address registered as the login ID, an e-mail notifying that the medical worker registration has been completed and notifying the assigned medical worker ID is transmitted (step S38). In this way, new medical worker registration is completed. The notification of the completion of the registration of the medical worker and the communication of the medical worker ID are displayed on the medical worker terminal 11 without using an e-mail, and a sheet on which the medical worker ID is printed is given to the medical worker M. Needless to say, other methods may be used.

  When new patient registration or new medical worker registration is completed as described above, the user can use various services as the patient P or the medical worker M. The main menu displayed at that time is shown in FIGS.

  FIG. 47 is an example of the main menu for the medical worker M, and displays four buttons of “patient group registration”, “family registration”, “invitation to group”, and “various approval / permission lists”. . FIG. 48 is an example of the main menu for the patient P, and displays three buttons of “family registration”, “invitation to group”, and “various approval / permission lists”. The “various approval / permission list” is, for example, a button for selecting a function such as permission to send an invitation request or approval of an invitation request.

(Registration / generation of patient groups)
In the medical support system 30 of the present embodiment, a patient group is registered and generated for each disease of each patient P in order to share medical information and messages. Registration / generation of the patient group is performed by patient group registration by the medical worker M or family registration by the patient P. Therefore, patient group registration will be described first, followed by family registration by medical staff. Then, family registration by the patient will be described. In the following description, the disease is registered together with the name of the patient P when registering the patient group, but the registration of the disease may be omitted. In this case, since the medical support system 30 is set so that “a patient group generated for each patient P in one medical related facility F is limited to one”, the operation is simplified. .

(Patient group registration by healthcare professionals)
FIG. 46 is a flowchart showing a series of operations when the medical worker M registers a patient group in the medical support system 30 of the present embodiment. “Patient group registration” is to register the patient P and the disease being treated by the medical facility F to which the medical worker M belongs to the medical support system 30 to generate a patient group G. .

  As shown in FIG. 46, the authentication unit 340 of the medical support system 30 first displays a predetermined “login screen” (see FIG. 33B) on the medical worker terminal 11 of the medical worker M who has accessed. A login is prompted (step S101). In response to this, the medical worker M inputs his / her user ID and PW on the “login screen” and clicks the send button displayed on the screen. The authentication unit 340 determines whether or not the received user ID and PW match the user ID and PW registered in the user information storage unit 312 of the user management unit 310 (step S102). If either or both of the user ID and PW do not match, an error is displayed and prompting for re-input (step S103).

  When both the user ID and the PW match, the registration unit 321 of the group management unit 320 displays a predetermined “medical worker menu screen” (see, for example, FIG. 47) on the medical worker terminal 11. Since “patient group registration” in the “medical worker menu screen” is selected, a predetermined “patient group registration screen” is displayed on the medical worker terminal 11 and prompted to input predetermined patient information and disease information. (Step S105).

  As the “patient group registration screen”, for example, the one shown in FIG. 51 is used. In this case, after inputting the patient's name as the predetermined patient information and the disease name as the predetermined disease information, the transmission button is clicked. When the medical support system 30 is set so that “the number of patient groups generated for each patient P in one medical related facility F is limited to one”, the registration of the disease is unnecessary.

  Next, the registration unit 321 determines whether the information transmitted from the medical worker terminal 11 is predetermined (step S105). If the received information is not predetermined patient information and disease information, for example, if the disease name is not entered or the patient's name is incorrect, an error / re-input display is performed on the medical staff terminal 11, The user is prompted to input information again (step S106). If the received information is predetermined, it is determined whether or not “patient group registration” related to the received information has already been performed, that is, whether or not the patient group registration is duplicated (step S107). If it is determined that there is duplication, the input of non-overlapping information is instructed (step S108), and steps S105 to S107 are repeated.

  If it is determined in step S107 that patient group registrations do not overlap, the registration unit 321 generates and registers patient groups (step S109). Thereby, the patient group G for the designated disease of the designated patient P is generated in the medical support system 30. At this time, information on the medical related facility F (medical related facility information) to which the logged-in medical worker M belongs is also registered. Further, since step S107 is present, there is no possibility that the same patient group is generated and registered in duplicate. The patient group G at the time of generation / registration has no participants, that is, the group members are zero unless a default member is registered. However, the designated patient P himself / herself, another medical worker M belonging to the same medical related facility F as the medical worker M who has registered the patient group, and other medical workers belonging to other medical related facilities F If there is a person who wants to participate in the patient group G, such as the person M, send an invitation request to the person for approval after receiving permission from both the health care manager and the patient manager. You can add group members freely. All group members other than the patient P are supporters of the patient P.

  Medical personnel M who have become group members can share medical information related to a specified disease of the patient P related to the patient group G on the condition that consent from the patient P in writing or the like is obtained. Therefore, it is possible to improve the medical service provided to the patient P.

(Invite existing user supporters)
Next, the medical worker M who has registered the patient group as described above invites the patient P, the medical worker M, and the patient-related person R who are already registered as users of the medical support service as supporters. The operation in this case will be described with reference to FIGS. 31A and 31B. In addition, this operation | movement is the same also when not the medical worker M but the patient P or the patient related person R invites a supporter.

  31A and 31B are flowcharts showing a series of operations when inviting an existing user to a supporter in the medical support system 30 of the present embodiment.

  First, as shown in FIG. 31A, the authentication unit 340 of the medical support system 30 first has a predetermined “login screen” (see FIG. 33B) on the medical worker terminal 11 of the inviting person who has accessed (that is, the medical worker M). Are displayed) to prompt login (step S81). In response to this, the invitee inputs his / her user ID and PW on the “login screen” and clicks the send button displayed on the screen. The authentication unit 340 determines whether or not the received user ID and PW match the user ID and PW registered in the user information storage unit 312 of the user management unit 310 (step S82). If either or both of the user ID and PW do not match, an error is displayed and prompting for re-input (step S83).

  When both the user ID and the PW match, the registration unit 311 of the user management unit 310 displays a “medical worker menu screen” and prompts the user to select a desired function. 47 is used as the “medical worker menu screen”. Here, since a new supporter is invited, the inviter selects “Invite to group”. Accordingly, in response to this, the invitation request control unit 331 of the group management unit 330 displays a predetermined “supporter invitation screen” on the inviter's terminal 11 and prompts the user to specify the destination of the invitation request (step S84). . Since the person (invitee) invited as a supporter has already been registered as a user, the names of users who can be selected as the invitee are displayed in a list on the "supporter invitation screen", and the invitee wishes Select a person from the list.

  For example, the “supporter invitation screen” in step 84 can be in the form shown in FIG. In this example, the names of users who can be selected as invitees are displayed in a list on the “supporter invitation screen”. The inviter can select and designate the invitee simply by clicking the “Invite” button attached to the name in the list.

  The invitation request control unit 331 determines whether or not the designation of the invitee has been completed (step S85). When the invitation request control unit 331 determines that the invitation has been completed, the “supporter” is displayed on the terminal of the medical provider manager and the terminal of the patient manager. An “invitation permission / refusal screen” is displayed, and permission for invitation request transmission is requested (step S86). Then, the invitation request control unit 331 determines whether a reply “permitted” has been received from both the terminal of the medical provider manager and the terminal of the patient manager (step S87). If you do not receive a “permitted” reply from both the health care provider's administrator's terminal and the patient's administrator's terminal, the invitation request email will not be sent and the supporter invitation process will end .

  For example, the “supporter invitation approval / disapproval screen” in step 86 can be in the form shown in FIG. In this example, to allow the supporter invitation, click the “Allow” button. If you do not want to allow supporter invitations, click the “Do not allow” button.

  When receiving a reply of “permitted” from both the terminal of the medical provider manager and the terminal of the patient manager, the invitation request control unit 331 sends an invitation request e-mail to the designated invitee. (Step S88), and waits for access (return arrival) from the invitee (step S89).

  When there is an access from the invitee, a predetermined “supporter invitation approval screen” is displayed on the invitee's terminal according to the access (step S90), and whether or not the invitee has approved the invitation request. Judgment is made (step S91).

  If the invitee rejects the invitation request, a screen notifying that the participation in the patient group G has been refused is displayed on the invitee's invitee's terminal (step S92), and then the supporter invitation process is performed. finish. If the invitee approves the invitation request, it is added to the patient group G as a supporter (step S93), and a screen notifying that it has been added as a supporter is displayed on the invitee's terminal (step S94). End the supporter invitation process.

  The “invitation request approval screen” in step 90 can be in the form shown in FIG. 42, for example. In this example, the invitee can approve the invitation request simply by clicking the “Approve” button in this screen. To reject the invitation request, simply click the “Reject” button.

(Inviting non-user supporters by health care workers or patients)
Next, the medical worker M who has registered the patient group as described above invites the patient P, the medical worker M, and the patient-related person R who are not yet registered as users of the medical support service as supporters. The operation in this case will be described with reference to FIGS. 32A and 32B. In addition, this operation | movement is the same also when not the medical worker M but the patient P or the patient related person R invites a supporter.

  32A and 32B are flowcharts showing a series of operations when inviting a non-user to a supporter in the medical support system 30 of the present embodiment.

  In the case of inviting a non-user, the name of the invitee to whom the invitation request is sent and the destination (email address) are individually specified, and the invitee (healthcare professional M) terminal 11 “invite request” This is different from the above-described case of inviting an existing user in that a new user registration process is executed before the “approval screen” is displayed.

  That is, as shown in FIG. 32A, the authentication unit 340 of the medical support system 30 performs a predetermined “login screen” on the terminal 11 of the accessing inviter (that is, the medical worker M) as in the case of inviting an existing user. ”To step S83 in which it is determined that both the user ID and the PW match. When both the user ID and the PW match, the registration unit 311 of the user management unit 310 displays a “medical worker menu screen” and prompts the user to select a desired function.

  47 is used as the “medical worker menu screen”. Here, since a new supporter is invited, the inviter selects “Invite to group”. Accordingly, in response to this, the invitation request control unit 331 of the group management unit 330 displays a predetermined “supporter invitation screen” on the inviter's terminal 11 and prompts the user to specify the destination of the invitation request (step S84). . Since the person invited as a supporter (invitee) has not been registered as a user yet, it is necessary to individually specify the destination of the invitation request.

  For example, the “supporter invitation screen” in step 84 can be in the form shown in FIG. In this example, it is necessary to individually input the mail address and telephone number (passphrase) of the person designated as the invitee. In FIG. 43, only one set of e-mail address and telephone number (passphrase) fields is provided, but it goes without saying that a plurality of sets may be provided. If it does so, it will become possible to input a mail address and a telephone number (passphrase) of several persons collectively in the same screen. When the input is completed, the invitation request can be transmitted to the invitee simply by clicking the “Invite” button.

  The invitation request control unit 331 determines whether or not the designation of the destination of the invitation request has been completed (step S85). If the invitation request control unit 331 determines that the invitation request has been completed, the invitation request control unit 331 The “supporter invitation approval / disapproval screen” is displayed, and permission to send an invitation request is requested (step S86). Then, the invitation request control unit 331 determines whether a reply “permitted” has been received from both the terminal of the medical provider manager and the terminal of the patient manager (step S87). If you do not receive a “permitted” reply from both the health care provider's administrator's terminal and the patient's administrator's terminal, the invitation request email will not be sent and the supporter invitation process will end . When a reply of “permitted” is received from both the terminal of the medical provider manager and the terminal of the patient manager, an invitation request e-mail is transmitted to the e-mail address of the designated invitee (step S88). ). Then, it waits for access from the invitee (step S89). If there is access, before displaying the “invitation request approval screen”, a predetermined “new user registration screen” is displayed on the terminal of the invitee and the user of the medical support system 30 is registered to the invitee. Then, the user is prompted to approve the invitation request (step S95).

  When the new user registration process is executed by the invitee and the invitee is registered as a user of the medical support system 30, the invitation request control unit 331 displays a predetermined “invite request approval screen” on the invitee's terminal. (Step S90), it is determined whether the invitee has approved the invitation request (step S91).

  If the invitee rejects the invitation request, a screen notifying that the participation in the patient group G is rejected is displayed on the inviter's terminal (step S92), and the supporter invitation process is terminated.

  If the invitee approves the invitation request, the supporter invitation is allowed, so the invitee who accepted the invitation is added as a supporter to the patient group G and becomes a group member (step S93). And after displaying the screen which notifies that a supporter was added on a terminal of an invitee (step S94), a supporter invitation process is complete | finished.

  The “invitation request approval screen” in step 90 can be in a format as shown in FIG. 44, for example. In this example, in order to approve the invitation request, the invitee only has to input his / her name and email address and then click the send button. When refusing an invitation request, it does not respond to this invitation request (e-mail), but can be ignored.

  The “supporter invitation permission / refusal screen” in step 86 can be in the form shown in FIG. 45, for example. In this example, click the "Allow" button if the healthcare provider administrator or patient administrator allows the supporter invitation, or click the "Do not allow" button if the supporter invitation is not allowed Just do it.

(Family registration by medical staff)
Next, family registration by medical staff will be described with reference to FIGS. 29A and 29B. FIGS. 29A and 29B are flowcharts showing a series of operations when a medical worker performs family registration in the medical support system 30 of the present embodiment.

  First, as shown in FIG. 29A, the authentication unit 340 of the medical support system 30 first displays a predetermined “login screen” on the medical worker terminal 11 of the medical worker M who has accessed, and prompts login ( Step S41). In response to this, the medical worker M inputs his / her user ID and PW on the login screen and clicks the send button displayed on the screen. The authentication unit 340 determines whether the received user ID and PW match the user ID and PW registered in the user information storage unit 312 of the user management unit 310 (step S42). If either or both of the user ID and PW do not match, an error is displayed and prompting for re-input is made (step S43).

  When both the user ID and the PW match, the registration unit 311 of the user management unit 310 prompts the user to select a desired function by displaying a predetermined menu screen (see FIG. 47). Here, since a new family registration is performed, the medical worker M selects “family registration request”. Accordingly, in response to this, the registration unit 321 of the group management unit 320 displays a predetermined “family registration request screen” on the medical staff terminal 11 and prompts input / transmission of predetermined patient information (step S44).

  The “family registration request screen” in step S44 can be in the form shown in FIG. 45, for example. In this example, the medical worker M inputs the email address of the patient P and then clicks the send button. In this case, the names of patients P that can be registered for family members may be displayed in a list on the medical staff terminal 11 and may be selected by clicking the name of the desired patient P.

  Next, the registration unit 321 of the group management unit 320 determines whether or not the information transmitted from the medical worker terminal 11 is predetermined (step S45). If the received information is not predetermined, for example, if the e-mail address is not in the correct notation, an error / re-input display is performed on the medical staff terminal 11 to prompt the user to input the information again (step S46). . If the received information is predetermined, it is determined whether or not “family registration” related to the received information has already been performed, that is, whether or not “family registration” overlaps (step S47). If it is determined that the information overlaps, the input of non-overlapping information is instructed (step S48), and then steps S45 to S47 are repeated.

  If it is determined in step S47 that the family registration does not overlap, the process proceeds to step S49, and the patient P related to the family registration, in other words, the patient P designated on the “family registration request screen” is displayed on the medical support system. Determine if you are an existing user. This is because the patient P related to family registration may not yet be a user of the medical support system. If it is determined in step S49 that the user is not an existing user, the above-described patient group registration process is executed (step S50). When the patient group registration process is completed in this way, the registration unit 321 transmits an e-mail notifying that “family registration request” has been made to the e-mail address of the patient P related to family registration (step S51). This email includes a URL linked to the “family registration approval screen”, and the patient P can click on this URL to open the “family registration approval screen” on the patient terminal 10.

  Next, the registration unit 321 waits for access from the patient P related to family registration (step S52), and when accessed from the patient terminal 10, displays a "family registration approval screen" (step S53). Then, it is determined whether or not family registration has been approved (step S54). When it is determined that the family registration is approved, the patient information related to the family registration, the disease information, and the medical related facility information are associated with each other and stored in the family facility information storage unit 328 (step S56), and the sharing rule selected by the patient P is shared. It memorize | stores in the consent information storage part 329 (step S57), and complete | finishes. If it is determined in step S54 that the family registration has not been approved, the medical staff terminal 11 is notified that the family registration has been rejected, and the family registration process is terminated.

The “family registration approval screen” in step 53 can be in the form shown in FIG. 36, for example. In this example, when the registration is approved, the patient P inputs his / her passcode, and “Rule 1 (in-hospital sharing)” and “Rule 2 (inclusive) are selected from the pull-down list in the information sharing rule column. After selecting “Share” ”or“ Rule 3 (Share Reject) ”, the registration approval button is clicked. In the case of refusing registration, the patient P may input his / her passcode and then click the registration refusal button. In case of registration refusal,
It is not necessary to select an information sharing rule.

(Family registration by patient)
Next, family registration by the patient P will be described with reference to FIGS. 30A and 30B. 30A and 30B are flowcharts showing a series of operations when a patient performs family registration in the medical support system 30 of the present embodiment.

  First, as shown in FIG. 30A, the authentication unit 340 of the medical support system 30 first displays a predetermined “login screen” on the patient terminal 10 of the patient P who has accessed, and prompts login (step S61). In response to this, the patient P inputs his / her user ID and PW on the “login screen” and clicks the send button displayed on the screen. The authentication unit 340 determines whether or not the received user ID and PW match the user ID and PW registered in the user information storage unit 312 of the user management unit 310 (step S62). If either or both of the user ID and PW do not match, it means that the patient P is not yet a user of the medical support system, so an error is displayed (step S63) and the new user registration process is executed. (Step S64). The patient P executes the new user registration process, returns to step S61, inputs his user ID and PW on the login screen, and clicks the send button displayed on the screen.

  When both the user ID and the PW match, the registration unit 311 of the user management unit 310 displays a “menu screen” (see FIG. 48) and prompts the user to select a desired function. Here, since a new family registration is performed, the patient P selects “family registration request”. Accordingly, in response to this, the registration unit 321 of the group management unit 320 displays a predetermined “family registration request screen” on the patient terminal 10 and prompts to search and specify a medical-related facility for which family registration is desired ( Step S65). Further, a predetermined “sharing rule selection screen” is displayed on the patient terminal 10 and prompted to select one (step S66).

  The “family registration request screen” in step 65 can be in the form shown in FIG. 37, for example. In this example, it is possible to search and specify a medical facility where the patient P desires family registration. A display example of the search result is shown in FIG. In the example of FIG. 38, it is possible to specify by simply clicking the “family registration” button displayed in the name of the desired medical-related facility from the medical-related facilities displayed as a list by searching.

  The “sharing rule selection screen” in step 66 can be in the form of a “family registration confirmation screen” as shown in FIG. 39, for example. In this example, when confirming the family registration, the patient P inputs his / her passcode, and “Rule 1 (in-hospital sharing)” and “Rule 2 (inclusive) are selected from the list that is pulled down in the information sharing rule column. After selecting "Share" "or" Rule 3 (Share Reject) ", the registration button is clicked. To cancel family registration, simply click the cancel button. In the case of cancellation, it is not necessary to enter a passcode and select an information sharing rule.

  And the registration part 321 judges whether all the information transmitted from the patient terminal 10 is gathered (step S67). If all the received information is not complete, for example, if the disease name has not arrived, an error / re-input display is performed on the patient terminal 10 to prompt the user to input the information again (step S68). If all the received information is available, it is determined whether “family registration” related to the received information has already been performed, that is, whether “family registration” is duplicated (step S69). If it is determined that the information overlaps, the input of non-overlapping information is instructed (step S70), and steps S65 to S69 are repeated.

  If it is determined in step S69 that the family registration does not overlap, the process proceeds to step S71, in other words, whether or not the patient P requesting family registration is registered as a patient in the medical facility F related to family registration. For example, it is determined whether or not the patient is a patient of the medical facility F designated on the “family registration request screen”. This is because the patient may not yet be a patient of the medical facility F related to family registration. If it is determined in step S71 that the patient is registered in the medical facility F, the patient information related to family registration, the disease information, and the medical facility information are associated with each other and stored in the family facility information storage unit 328 (step S73). After the sharing rule selected by the patient P is stored in the sharing agreement information storage unit 329 (step S74), the group G is registered and generated (step S75), and the family registration process is terminated.

  Thus, the patient group G for the designated disease of the designated patient P is also generated by the family registration by the patient P. This patient group G has zero group members at the time of generation, except for the case where a default member is registered, as is the case with the patient group G registered and generated by the patient group registration by the medical worker M. In addition, the patient P who has performed family registration, the medical worker M who belongs to the medical worker M related to family registration, the medical worker M who belongs to other medical facilities F, and the patient-related person R, the patient If there is a person who wants to participate in Group G, send an invitation request to the person with approval from both the health care manager and the patient manager, and receive approval. Can be added freely. All group members other than the patient P are supporters of the patient P.

  In the patient group G generated by the family registration by the patient P, the designated disease of the patient P related to the patient group G according to the sharing rule agreed by the patient P among the medical workers M who became group members Medical information about can be shared. Therefore, it is possible to improve the medical service provided to the patient P.

  An example of the timeline of the patient group G regarding the patient A is shown in FIG. In this example, the answer (message) of Mr. Koichi Sato, a health care worker (doctor), and the reply (message) of Hanako Yamada, a health care worker (nurse), to the question (message) issued by Mr. A Reply message of Michiko Nakamura, who is a health care worker (care manager)) is lined in chronological order, so it is easy to understand the flow of the talk and it is very easy to understand. Since any member belonging to this patient group can access this timeline, it is possible to easily read messages on the timeline, post messages on the timeline, and the like. Therefore, in this group of Mr. A, communication is performed smoothly and communication is easy.

  FIG. 50 shows an example of integrated medical information of patient A. As can be seen from this example, medical information related to diabetes stored and stored in the X clinic and medical information related to lung cancer stored and stored in the Y clinic can be browsed in an integrated state. For this reason, both the medical worker M belonging to the X clinic and the medical worker M belonging to the Y clinic can share medical information regarding different diseases of the patient A. Therefore, the medical worker belonging to the X clinic The worker M can perform treatment and the like in consideration of medical information at the Y clinic. A medical worker M who belongs to the Y clinic can also be treated in consideration of medical information at the X clinic. As a result, there is an advantage that treatment suitable for the patient's symptoms can be performed.

(Generate theme timeline)
In the medical support system 30 of the present embodiment, in addition to the patient timeline, for the cooperation support system 100 to cooperate, the theme timeline related to the cooperation request, for example, “diabetes medicine timeline” or “hypertension nutrition guidance time” Line "is generated. The theme timeline is generated independently of the patient timeline. The theme timeline displays cooperation request information (contents of the cooperation request) regarding the specific theme related to the cooperation request, messages posted from members of the cooperation request destination group related to the specific theme, and the like.

  As described above, in the cooperation support system 100 according to an embodiment of the present invention, one or more who wish to transmit a cooperation request on the cooperation request destination designation screen 159 displayed on the user terminal 11 of the present invention. The link request destination is designated by the link request source (Doctor Nozaki), and accordingly, a link request timeline 165 that can be accessed by the call source and one or more specified link request destinations is generated. . Then, the content of the cooperation request input by the sender on the cooperation request content input screen 157 is displayed on the cooperation request timeline 165 in the form of the cooperation request notification panel 162 as “cooperation request information”. Notify the link request destination. As a result, one or a plurality of cooperation request destinations and the transmission source can freely exchange messages such as questions on the cooperation request timeline 165 based on “cooperation request information”. For this reason, the transmission source can find a desired cooperation destination from one or a plurality of cooperation request destinations through its message exchange on its own user terminal 11.

  Therefore, the medical-related facility or the care-related facility, which is the sender, when requesting the patient's hospitalization, discharge, home visit, short stay, etc. from the outside, or when obtaining detailed information about a new drug from the outside, It is possible to quickly and easily search for other medical-related facilities, nursing-related facilities, and other external facilities (that is, cooperation destinations) that cooperate with the own facility.

  In addition, since a database for managing cooperation request destinations is not necessary, troublesome patient reception destination search work (cooperation destination search work) by telephone or fax can be eliminated without troublesome work such as database maintenance.

(Modification)
The embodiments described above show examples embodying the present invention. Therefore, the present invention is not limited to this embodiment, and it goes without saying that various modifications can be made without departing from the spirit of the present invention.

  For example, in the above-described embodiment, the cooperation support system 100 can be used for four types of cooperation requests such as hospitalization, discharge, drug information, and nutritional guidance for medical-related facilities and care-related facilities. It is not limited to. It is applicable to various types of cooperation requests other than these. For example, the present invention can also be applied to a cooperation request in the case of consulting with a care-related facility about whether or not a short stay is possible.

DESCRIPTION OF SYMBOLS 10 Patient terminal 11 Medical staff terminal 12 Patient related terminal 20 Internet 30 Medical support system 51 Patient timeline 51a Medical staff common area 51b Medical worker shared area 100 Cooperation support system 101 Cooperation request destination designation screen display part 102 Cooperation request timeline Control unit 103 Linkage request content display unit 104 Linkage request content transmission unit 105 Linkage request destination information management unit 106 Linkage destination information management unit 151 Timeline list 152 Patient timeline 153 Thread 154 Linkage request button 155 Linkage request type selection screen 156 Selection button 157 Cooperation request content input screen 158 Registered cooperation request destination group selection screen 159 Cooperation request destination member selection screen 160 Check box 161 Input field 62 Cooperation Request Notification Panel 163 Status Display Button 164 Group Member List 165 Cooperation Request Timeline 166 Confirm Button 167 Confirmed Cooperation Destination Medical Worker 310 User Management Unit 311 Registration Unit 312 User Information Storage Unit 313 Patient Information Storage Unit 314 Medical Care Worker information storage unit 315 Medical related facility information storage unit 316 Disease information storage unit 320 Family registration management unit 321 Registration unit 322 Family facility information storage unit 323 Shared consent information storage unit 324 Patient reality verification unit 330 Group management unit 331 Invite request Control unit 332 Invite request information storage unit 333 Group information storage unit 334 Group / member information storage unit 335 Timeline control unit 336 Message control unit 337 Authentication unit 340 Authentication unit 350 Communication control unit F Medical Related Facilities F1 Clinic F2 Clinic F3 Hospital F4 Visiting Nursing Stations LF1-LFn Candidate Facility G Patient Group G11 Patient P1 Diabetes Treatment Group G12 Patient P1 Hyperlipidemia Treatment Group G13 Patient P1 Gout Treatment Group G21 Patient P2 Alzheimer treatment group G22 Patient P2 hypertension treatment group RG Cooperation request destination group M Medical worker M1, M2, M3, M4, M5, M6, M7, M8 Medical worker P Patient P1, P2 Patient R Patient relationship Patients R1, R2, R3, R4, R5, R6, R7, R8 Patients involved

Claims (12)

A collaborative destination search support method for medical / nursing related facilities that supports medical related facilities or nursing care related facilities to search for a desired collaborative destination,
The cooperation request destination specifying screen display means in cooperation request destination designation screen displayed on the user terminal, to specify one or more coordination request destination cooperation requests originating Niso cooperation request is sent,
A cooperation request / timeline generating means generates a cooperation request / timeline that can be accessed by one or a plurality of the cooperation request destinations specified on the cooperation request destination designation screen on the user terminal and the source . Generate
In cooperation request content input screen displayed on the user terminal by cooperation request content input screen displaying means, to enter the contents of the collaboration request to the source,
Wherein the content of the cooperation request the collaboration request input in the contents input screen on the user terminal, is displayed in the collaboration request timeline as cooperation request information by cooperation request content display means,
On the cooperation request timeline, one or more of the cooperation requests is transmitted from the one or more cooperation request destinations and the transmission source by exchanging messages between the one or more cooperation request destinations and the transmission source. A collaborative destination search support method for a medical / care-related facility characterized in that a desired collaborative partner can be found from among the destinations. 2. The cooperation destination search support method for medical / care related facilities according to claim 1, wherein the input of the content of the cooperation request on the cooperation request content input screen on the user terminal is performed by specifying a patient or a theme. The patient / theme timeline generation means provides a patient timeline or theme timeline related to the cooperation request,
The cooperation request search method of the medical / care related facility according to claim 1 or 2, wherein the cooperation request information is displayed on the patient timeline or the theme timeline in addition to the cooperation request timeline. . To said patient timeline or the theme timeline according to the cooperation request, medical and nursing care according to claim 3, wherein the linkage request destination determined as the desired cooperation destination by the caller is automatically invited Support method for searching facilities for cooperation. 5. The user can select whether or not to save one or a plurality of the cooperation request destinations specified on the cooperation request destination designation screen on the user terminal as a cooperation request destination group. The search method for cooperation destinations of medical and nursing care facilities described in 1.   The message exchanged between one or a plurality of cooperation request destinations and the transmission source is displayed in a thread format for each of the cooperation request information displayed on the cooperation request timeline. 5. A cooperation destination search support method for a medical / care-related facility according to any one of 5 above. A collaborative search support system for medical / nursing related facilities that supports medical related facilities or nursing related facilities searching for a desired collaborative destination,
A linkage request destination designation screen display means for displaying a linkage request destination designation screen for designating one or a plurality of linkage request destinations to which the linkage request is transmitted, on the user terminal;
A cooperation request / timeline generating means for generating a cooperation request / timeline that can be accessed by one or a plurality of the cooperation request destinations specified on the cooperation request destination designation screen and a source of the cooperation request;
Cooperation request content input screen display means for displaying a cooperation request content input screen for inputting the content of the cooperation request on the user terminal;
The content of the cooperation request input on the cooperation request content input screen is provided with cooperation request content display means for displaying on the cooperation request timeline as cooperation request information,
On the cooperation request timeline, one or more of the cooperation requests is transmitted from the one or more cooperation request destinations and the transmission source by exchanging messages between the one or more cooperation request destinations and the transmission source. A collaborative partner search support system for medical / care related facilities, characterized in that a desired collaborator can be found from among the partners.   The cooperation destination search support system for medical / care-related facilities according to claim 7, wherein the input of the content of the cooperation request on the cooperation request content input screen is performed by specifying a patient or a theme. A patient / theme timeline generating means for generating a patient timeline or a theme timeline related to the cooperation request;
9. The cooperation request information is also displayed on the patient timeline or the theme timeline generated by the patient / theme timeline generation means in addition to the cooperation request timeline. Cooperation destination search support system for the listed medical / nursing care facilities. To said patient timeline or the theme timeline according to the cooperation request, medical and nursing care according to claim 9, wherein the cooperation request destination determined as the desired cooperation destination by the caller is automatically invited Facility search support system for facilities.   The medical device according to any one of claims 7 to 10, wherein it is possible to select whether or not to save one or more of the cooperation request destinations specified on the cooperation request destination designation screen as a cooperation request destination group. Cooperation destination search support system for care-related facilities.   The message exchanged between one or a plurality of the cooperation request destinations and the transmission source is displayed in the form of a thread for each of the cooperation request information displayed on the cooperation request timeline. 11. A cooperation destination search support system for medical / care-related facilities according to any one of 11 above.

Images