WO2020021973A1 - 病院予約システム及びサーバ装置 - Google Patents

病院予約システム及びサーバ装置 Download PDF

Info

Publication number
WO2020021973A1
WO2020021973A1 PCT/JP2019/026079 JP2019026079W WO2020021973A1 WO 2020021973 A1 WO2020021973 A1 WO 2020021973A1 JP 2019026079 W JP2019026079 W JP 2019026079W WO 2020021973 A1 WO2020021973 A1 WO 2020021973A1
Authority
WO
WIPO (PCT)
Prior art keywords
hospital
evaluation
unit
user
reservation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2019/026079
Other languages
English (en)
French (fr)
Inventor
出野　徹
直樹 土屋
貴広 濱口
洋貴 和田
佐藤　博則
湯本　将彦
山内　隆伸
和 松岡
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Omron Healthcare Co Ltd
Original Assignee
Omron Healthcare Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Omron Healthcare Co Ltd filed Critical Omron Healthcare Co Ltd
Publication of WO2020021973A1 publication Critical patent/WO2020021973A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms

Definitions

  • the present invention relates to a hospital reservation system and a server device.
  • Patent Literature 1 proposes a technology that allows a patient to select an appropriate doctor based on evaluations of a plurality of doctors, for receiving treatment for his or her own disease.
  • the evaluation of a doctor is to present information about the doctor to a plurality of other doctors, and the other doctor evaluates the information based on the information, which is likely to be a subjective evaluation.
  • a doctor suitable for the user or a candidate for a hospital to which the doctor belongs is presented to the user based on the objective index, and the user cannot select and make a reservation from the candidates.
  • the present invention has been made in view of the above circumstances, and an object of the present invention is to present a candidate of a hospital or a doctor suitable for a user based on an objective index, and to reserve a hospital according to the selection of the user. It is to provide a hospital reservation system and a server device which can perform the above.
  • the present invention employs the following configuration in order to solve the above-described problems.
  • the hospital reservation system at each of the plurality of hospitals, at least patient information on the patient and, for each medical treatment, the reception date and time, medical treatment start date and time, medical treatment end date and time, medical doctor, and accounting end date and time.
  • An electronic medical record network for sharing an electronic medical record for each patient among the plurality of hospitals, the electronic medical record network describing the electronic medical record, and an electronic medical record collection unit that collects the contents of the electronic medical record from the electronic medical record network.
  • a biometric data collection unit for collecting biometric data of each of a plurality of users
  • a reception unit for receiving a request from a user terminal via the communication network, and an evaluation from the user terminal by the reception unit
  • the receiving unit receives the request.
  • An evaluation unit that evaluates the plurality of hospitals or doctors limited as the evaluation target, and based on an evaluation result by the evaluation unit, at least one of the evaluated plurality of hospitals or doctors is a reservation candidate.
  • a hospital is a small group of hospitals in one building, a large-scale hospital with multiple wards on one site, and a hospital group including affiliated hospitals distributed in multiple regions. May be.
  • the electronic medical records may be distributed for each hospital in the group. Further, the electronic medical record may be arranged in a data center provided in the electronic medical record network instead of in the hospital.
  • the arrangement includes being stored in a storage unit having a storage medium.
  • the data format of the electronic medical record may be different for each hospital, and the electronic medical record of each hospital can be converted into a unified format in the electronic medical record network and stored in the storage unit of the data center.
  • confidentiality is ensured by data encryption or the like.
  • access permissions are limited for each medical worker, and medical terminals operated by each medical worker can view and update information on electronic medical records located at the hospital or data center. It has become.
  • a limited access right is given to each user who is a patient, and the user terminal operated by each user can browse information of the electronic medical record arranged in the data center.
  • the hospital reservation system in response to an evaluation request from an arbitrary user terminal, a hospital or a doctor limited based on the biometric data of the user of the user terminal and the collected biometric data of a plurality of users.
  • the evaluation is made by an objective index of time, and a reservation candidate is presented to the user based on the evaluation result, and a hospital reservation is made according to the selection of the user of the user terminal of the evaluation request source.
  • presenting a hospital or doctor candidate suitable for the user the user can easily select a hospital, and can easily reserve a hospital according to the selection.
  • the evaluation unit calculates an evaluation value representing an evaluation result of the plurality of hospitals or doctors
  • the presentation unit calculates a plurality of hospitals or doctors in descending order of the evaluation value calculated by the evaluation unit.
  • a doctor can be extracted as the reservation candidate, and the extracted reservation candidate can be presented to the requesting user terminal together with the evaluation value. According to this configuration, it is possible to rearrange in the order of the evaluation values by using the numerical value called the evaluation value, and it is possible to easily present the reservation candidates suitable for the user.
  • the hospital reservation system further includes a correspondence database in which hospitals or doctors are databased according to attributes of the biometric data collected by the biometric data collection unit, and the limiting unit includes The plurality of hospitals or doctors to be evaluated may be limited by referring to the correspondence database based on attributes of the biometric data of the user of the original user terminal. According to this configuration, by using the database, it is possible to easily and quickly limit the hospitals or doctors to be evaluated.
  • the biometric data collection unit may receive, via the communication network, the biometric data of the user transmitted from each of the plurality of user terminals that collect the biometric data of the user. According to this configuration, the biometric data can be easily collected by collecting the biometric data from each user terminal of a user who subscribes to the hospital reservation service.
  • the biometric data collection unit may collect the history of the biometric data of each of the plurality of users, and the evaluation items evaluated by the evaluation unit may further include the biometric data collected by the biometric data collection unit.
  • the degree of symptom improvement based on a certain period of history of the data may be included. According to this configuration, it is possible to provide a candidate more suitable for the user by adding an evaluation based on the symptom improvement degree, ie, the symptom improvement degree.
  • the evaluation unit scores the evaluation result for each evaluation item, sets a total score for a doctor as an evaluation value, and sets a mean value of evaluation values of doctors belonging to the hospital as an evaluation value for a hospital.
  • the presentation unit extracts a plurality of hospitals or doctors from the higher evaluation value calculated by the evaluation unit as the reservation candidate, and extracts the extracted reservation candidate together with the evaluation value to the user terminal of the request source. Can be presented. According to this configuration, by using the scored evaluation value and presenting the reservation candidate together with the numerical value, it is possible to provide an index for selecting a hospital to be reserved by the user, thereby facilitating the selection of the user. It becomes possible.
  • the hospital reservation system further includes a doctor attribute acquisition unit that acquires doctor attribute information that can be disclosed including at least gender and age for each doctor belonging to each hospital
  • the reception unit includes: Further, the attribute information of the user of the user terminal of the request source that receives the attribute information and is evaluated by the evaluation unit further includes attribute information of the doctor acquired by the doctor attribute acquisition unit and the reception unit. And the attribute of the user terminal of the request source accepted by the user with the attribute information of the user.
  • the evaluation is performed based on the gender or age of the user to whom the evaluation value should be presented and the gender or age of the doctor, so that a doctor suitable for the user can be highly evaluated, and a doctor more suitable for the user. Becomes a candidate.
  • the receiving unit may further receive position information from the requesting user terminal, and the limiting unit may receive the position information from the requesting user terminal received by the receiving unit.
  • the plurality of hospitals or doctors to be evaluated is limited, and the evaluation items evaluated by the evaluation unit further include the position information from the user terminal of the request source received by the reception unit. , The relationship with the position of the hospital to be evaluated. According to this configuration, the possibility of presenting an inappropriate hospital to the user as a candidate is limited by limiting the hospitals that the user can visit according to the current position of the user requesting the evaluation and the designated position specified by the user. Can be smaller.
  • the hospital control unit further performs time management of a patient during stay at the current affairs of the hospital, and the evaluation unit accesses the hospital control unit, and at least a current time of each hospital.
  • the evaluation item obtained by acquiring the number of patients waiting for medical treatment and the number of patients reserved in the future and evaluating by the evaluation unit can further include the acquired number of patients waiting for medical treatment and the number of reserved patients. According to this configuration, it is possible to present hospital or doctor candidates in consideration of the current waiting time of each hospital.
  • the server device at each of the plurality of hospitals, at least the patient information on the patient and, for each medical treatment, reception date and time, medical treatment start date and time, medical treatment end date and time, medical doctor, and accounting end date and time.
  • An electronic medical record collection unit that collects the contents of the electronic medical record, from the electronic medical record network for sharing the electronic medical record for each patient, which includes the medical information,
  • a biometric data collection unit that collects biometric data of each of a plurality of users, a reception unit that receives a request from a user terminal via the communication network, an evaluation request from the user terminal by the reception unit, and the user terminal
  • the user of the request source of the evaluation request received by the reception unit is received.
  • the evaluation target is limited from among the plurality of doctors belonging to the plurality of hospitals or the plurality of hospitals.
  • the limiting unit based on the contents of the electronic medical record collected by the electronic medical record collecting unit, by an evaluation item including at least a medical treatment time and a waiting time per patient, the limited unit is limited by the limiting unit as the evaluation target
  • An evaluation unit that evaluates a plurality of hospitals or physicians, and, based on an evaluation result by the evaluation unit, at least one of the plurality of evaluated hospitals or physicians as a reservation candidate, the request via the communication network.
  • the server apparatus determines a time limit for a hospital or a doctor limited based on the biometric data of the user of the user terminal and the collected biometric data of the plurality of users.
  • a reservation candidate based on the evaluation result is transmitted to the user terminal requesting the evaluation and presented to the user, and a hospital reservation is performed according to the selection of the user of the user terminal.
  • the present invention it is possible to provide a technology capable of presenting a candidate for a hospital or a doctor suitable for a user based on an objective index, and making a reservation for a hospital according to the selection of the user.
  • FIG. 1 is a block diagram schematically illustrating an example of the configuration of the hospital reservation system according to the embodiment.
  • FIG. 2 is a block diagram illustrating an example of the overall configuration of the hospital reservation system according to the first embodiment.
  • FIG. 3 is a diagram illustrating an example of storage contents of a hospital database.
  • FIG. 4 is a diagram illustrating an example of the contents stored in the user database.
  • FIG. 5 is a diagram illustrating an example of the storage content of the correspondence database.
  • FIG. 6 is a diagram illustrating an example of the storage contents of the collection database.
  • FIG. 7 is a diagram illustrating an example of the storage contents of the evaluation database.
  • FIG. 8 is a flowchart illustrating an example of a processing procedure of the service server.
  • FIG. 1 is a block diagram schematically illustrating an example of the configuration of the hospital reservation system according to the embodiment.
  • FIG. 2 is a block diagram illustrating an example of the overall configuration of the hospital reservation system according to the first embodiment.
  • FIG. 3
  • FIG. 9 is a flowchart illustrating an example of a processing procedure of the user terminal.
  • FIG. 10 is a flowchart illustrating an example of the evaluation process in FIG.
  • FIG. 11 is a flowchart illustrating an example of the electronic medical record collection process in FIG.
  • FIG. 12 is a flowchart illustrating an example of the evaluation calculation process in FIG.
  • FIG. 13 is a diagram for describing an example of a history of biometric data.
  • FIG. 14 is a diagram for explaining another example of the history of the biometric data.
  • FIG. 15 is a flowchart illustrating an example of a processing procedure of the service server in the hospital reservation system according to the second embodiment.
  • FIG. 16 is a flowchart illustrating an example of the electronic medical record collection process in FIG. FIG.
  • FIG. 17 is a flowchart illustrating an example of the headcount collection process in FIG.
  • FIG. 18 is a flowchart illustrating an example of a processing procedure of the service server in the hospital reservation system according to the third embodiment.
  • FIG. 19 is a flowchart illustrating an example of the first evaluation calculation process in FIG.
  • FIG. 20 is a flowchart illustrating an example of the second evaluation calculation process in FIG.
  • FIG. 1 schematically illustrates an example of a configuration of a hospital reservation system according to the embodiment.
  • the hospital reservation system includes an electronic medical record network (EHR: Electronic Health Records) 1 and a service server 10 connected to a communication network NET such as the Internet.
  • the service server 10 can be connected to a plurality of user terminals 20 via the communication network NET.
  • the electronic medical record network 1 includes, at least in each of a plurality of hospitals, patient information relating to a patient and medical treatment information including a reception date / time, a medical treatment start date / time, a medical treatment end date / time, a medical doctor, and a transaction end date / time regarding each medical treatment.
  • This is a network for sharing the described electronic medical records (EMR: Electronic Medical Records) for each patient among a plurality of hospitals.
  • EMR Electronic Medical Records
  • the electronic medical record network 1 is configured, for example, by connecting a hospital server 30 provided in each of a plurality of hospitals and a data server 40 provided in a data center via a communication network NET. It should be noted that the electronic medical record network 1 may use a dedicated communication line instead of the Internet as the communication network NET.
  • the data server 40 needs to have a configuration that allows the service server 10 to access the data server 40 via the communication network NET.
  • the hospital server 30 of each hospital can have, for example, a control unit 31, a storage unit 32 connected to the control unit 31, and a communication interface (not shown).
  • the hospital server 30 includes, for example, a personal computer (PC) operated by a medical staff such as a doctor, a nurse, a laboratory technician, and a clerk in the hospital, an automatic reception machine and an automatic accounting machine operated by a visiting patient. , Etc., are connected via a hospital LAN (Local Area Network) or the like.
  • the hospital LAN may be a wired LAN, a wireless LAN, or a LAN in which wired and wireless are mixed.
  • the hospital server 30 includes an internal image capturing device such as a biological data measuring device that measures biological data such as a patient's blood pressure value and a CT (Computerized @ Tomography) device that captures an internal image of the patient.
  • an internal image capturing device such as a biological data measuring device that measures biological data such as a patient's blood pressure value and a CT (Computerized @ Tomography) device that captures an internal image of the patient.
  • Various types of inspection equipment including devices can be connected via a hospital LAN or the like.
  • Hospitals can be small hospitals, one room in a building, large hospitals with multiple wards located on one site, and hospital groups that include affiliated hospitals distributed in multiple regions. good.
  • the hospital server 30 may be provided for each hospital in the group, or one hospital server 30 may be arranged in one main hospital, and the medical terminals 33 of each affiliated hospital may be connected via a dedicated communication line or the like. May be connected to the hospital server 30.
  • the control unit 31 of the hospital server 30 may be provided for each hospital in the group, and the storage unit 32 may be arranged only in the hospital server 30 of one main hospital.
  • control unit 31 in the hospital server 30 includes, for example, a processor such as a CPU (Central Processing Unit) and an MPU (Micro Processing Unit) and a memory such as a RAM (Random Access Memory) and a ROM (Read Only Memory). And can be included.
  • the ROM stores, for example, a program executed by the processor.
  • the RAM is, for example, a memory used by the processor as a work memory.
  • the storage unit 32 can store, for example, a program executed by a processor of the control unit 31, setting data necessary for executing the program, and various databases.
  • Programs executed by the processor of the control unit 31 include, for example, an electronic medical record management program for browsing and updating the electronic medical record, a reservation management program for managing patient reservations, a reception time for each patient staying at the hospital, and the like. Management time management program, and the like.
  • the setting data required to execute the program can include, for example, an access address of the data server 40 of the data center.
  • the database includes, for example, a medical worker database that stores information on each medical worker including the authority and password of the medical worker operating the medical terminal 33, an electronic medical record database that stores an electronic medical record (EMR) of each patient, a reservation.
  • EMR electronic medical record
  • the storage unit 32 may include a reservation database that stores the status, and the like. It is not essential for the storage unit 32 of each hospital to store all of the programs, setting data, and databases as described above, and also stores programs, setting data, and databases other than those described above. Is also good.
  • the storage medium included in the storage unit 32 stores information such as a program stored in an electronic, magnetic, optical, mechanical, or chemical operation so that a computer or a machine can read information such as a recorded program. Any medium may be used as long as the medium accumulates the data.
  • an EEPROM registered trademark
  • the storage unit 32 may be used as a work memory by the processor of the control unit 31.
  • the processor of the control unit 31 executes, for example, an electronic medical record management program stored in the storage unit 32, and stores the contents of the electronic medical record stored in the storage unit 32 according to the operation of each medical terminal 33. The information can be displayed on the medical terminal 33 or the content of the electronic medical record can be updated.
  • the processor of the control unit 31 can also add, for example, inspection data from an inspection device (not shown) to the electronic medical record.
  • the processor of the control unit 31 can communicate with the data server 40 via a communication network NET or a dedicated communication line by a communication interface (not shown), for example. Communication by the communication interface is not limited to a specific communication method. However, in communication with the data server 40, it is necessary to secure confidentiality by data encryption or the like.
  • the processor of the control unit 31 can transmit, for example, the electronic medical records stored in the storage unit 32 to the data server 40 of the data center.
  • the processor of the control unit 31 can convert the electronic medical record into a common data format of the electronic medical record network 1 and transmit it after, for example, encrypting it.
  • the processor of the control unit 31 receives, from the data server 40, an electronic medical record created in another hospital and stored in the data server 40 in a common format, for example, decrypts the received electronic medical record, and After changing to the chart format, the chart can be registered in the electronic chart database of the storage unit 32.
  • the processor of the control unit 31 executes, for example, a reservation management program stored in the storage unit 32 to make a reservation from the medical terminal 33 or a request from the service server 10 or the user terminal 20 via the communication network NET.
  • the reservation database can be updated by receiving the reservation.
  • the processor of the control unit 31 acquires, for example, the reception date and time, the medical treatment start date and time, the medical treatment end date and time, the medical doctor, and the accounting end date and time by executing the time management program stored in the storage unit 32, for example. Then, it is also possible to manage the time of each patient during the current stay at the hospital.
  • the processor of the control unit 31 executes, for example, the electronic medical record management program, and obtains the medical information including the reception date and time, the medical treatment start date and time, the medical treatment end date and time, the medical doctor, and the accounting end date and time of each of the acquired patients. Can be described in each patient's electronic medical record.
  • the data server 40 of the data center can have, for example, a control unit 41, a storage unit 42 connected to the control unit 41, and a communication interface (not shown).
  • the control unit 41 can include, for example, a processor such as a CPU and an MPU, and a memory such as a RAM and a ROM.
  • the ROM stores, for example, a program executed by the processor.
  • the RAM is, for example, a memory used by the processor as a work memory. When the processor executes a necessary program, the control unit 41 can perform various operations.
  • the storage unit 42 can store, for example, a program executed by the processor of the control unit 41, setting data required for executing the program, and various databases.
  • the program executed by the processor of the control unit 41 includes, for example, an electronic medical record processing program for processing an electronic medical record transmitted from each hospital server 30 via the communication network NET or a dedicated communication line, the service server 10 and the user terminal. 20 and a communication program for transmission.
  • the database includes, for example, an access authority database storing the authority and password of a medical worker operating the medical terminal 33 and the user operating the user terminal 20, the authority of the service server 10, and the electronic information of each patient received from the hospital server 30.
  • An electronic medical record database that stores medical records (EMR) may be included.
  • the storage unit 42 may store programs and databases other than those described above.
  • the storage medium included in the storage unit 42 stores information such as a program stored in an electronic, magnetic, optical, mechanical, or chemical operation so that a computer or a machine can read information such as a recorded program. Any medium may be used as long as the medium accumulates the data.
  • a storage medium included in the storage unit 42 an EEPROM or the like can be used.
  • the storage unit 42 may be used as a work memory by the processor of the control unit 41.
  • the processor of the control unit 41 communicates with each hospital server 30 via the communication network NET or a dedicated communication line, for example, by executing an electronic medical record processing program stored in the storage unit 42.
  • the encrypted electronic medical record transmitted from the electronic medical record 30 can be decrypted and registered in the electronic medical record database of the storage unit 42, for example.
  • the processor of the control unit 41 encrypts the electronic medical record stored in the electronic medical record database of the storage unit 42 in a common format, for example, and encrypts the electronic medical record. It can be transmitted to the hospital server 30.
  • the storage unit 32 of the hospital server 30 does not have an electronic medical record database.
  • the electronic medical record stored in the storage unit 42 of the data server 40 can be virtually used as the electronic medical record included in the hospital server 30 of the hospital C. Therefore, the processor of the control unit 41 executes, for example, the electronic medical record processing program stored in the storage unit 42, and performs the medical treatment via the communication network NET or the dedicated communication line and the hospital server 30 of the hospital C. By acquiring operation information from the terminal 33, processing on the electronic medical record can be performed. Further, the processor of the control unit 41 can communicate with the service server 10 or the user terminal 20 via the communication network NET, for example, by executing a communication program stored in the storage unit 42.
  • control unit 31 of the hospital server 30 may convert the electronic medical record of the original data format stored in the storage unit 32 into the common data format of the electronic medical record network 1 and then transmit the converted data. Not required. From the hospital server 30 of each hospital, an electronic medical record in a unique data format may be transmitted to the data center after being encrypted, for example.
  • the control unit 41 of the data server 40 that has received the data, for example, decodes the received electronic medical record, converts the data format into a common data format of the electronic medical record network 1, and stores the electronic medical record in the storage unit 42. What is necessary is just to store it in a database.
  • control unit 41 of the data server 40 converts the electronic medical record of the common data format into a data format unique to each hospital, and then, for example, What is necessary is just to encrypt and transmit.
  • each medical worker can access from the medical terminal 33 the storage unit 32 or the data of the hospital server 30 of the own hospital to which access is permitted.
  • Information on the electronic medical record stored in the storage unit 42 of the data server 40 at the center can be viewed. If the authority is given, each medical worker can also update the electronic medical record from the medical terminal 33.
  • the user terminal 20 may be a general smart phone (smartphone) or a smart device such as a tablet terminal having a function of connecting to the communication network NET.
  • the user terminal 20 includes, for example, a control unit 21, a measurement unit 22 and a storage unit 23 connected to the control unit 21, a communication interface for connecting to a communication network NET (not shown), and a user interface. Can be. Further, the user terminal 20 can be connected to the biological data measurement device 24.
  • the communication interface can include, for example, a Wi-Fi® module.
  • the communication interface is connected to a communication network NET such as the Internet via a Wi-Fi base station (not shown), and communicates with the service server 10 and the data server 40 of the electronic medical record network 1 via the communication network NET. be able to.
  • the user interface includes a liquid crystal display, a touch panel arranged on a display screen thereof, and operation buttons provided on a housing of the smart device.
  • control unit 21 of the user terminal 20 can include, for example, a processor such as a CPU and an MPU and a memory such as a RAM and a ROM.
  • the ROM stores, for example, a program executed by the processor.
  • the RAM is, for example, a memory used by the processor as a work memory.
  • the measuring unit 22 measures various types of biological data of the user.
  • the measurement unit 22 can measure a pulse rate by using a camera and an LED flashlight generally provided in a smart device as a photoplethysmograph (PPG (Photo @ Plethysmography) sensor).
  • PPG Photo @ Plethysmography
  • a smart device capable of measuring a blood pressure by adding a pressure sensor.
  • the biometric data measurement device 24 is a device that can measure one or a plurality of various biometric data such as electrocardiogram, pulse, blood pressure, weight, body fat percentage, and the like.
  • the biometric data measurement device 24 performs short-range wireless communication with the control unit 21 of the user terminal 20, for example.
  • each of the user terminal 20 and the biometric data measurement device 24 can have a BLE communication module that employs a short-range wireless data communication standard such as Bluetooth (registered trademark), but is not limited thereto.
  • the biological data measurement device 24 and the control unit 21 of the user terminal 20 may be connected by wire.
  • the storage unit 23 stores a Web browser and various application programs (smartphone applications).
  • the control unit 21 can perform various operations.
  • the control unit 21 can access the service server 10 using a smartphone application, a Web browser, or the like.
  • a limited access right is given to each user who is a patient, and each user accesses the data server 40 from the user terminal 20 and accesses the data server 40 stored in the storage unit 42.
  • the user may be able to view the information on the electronic medical records for which the permission has been granted.
  • the user terminal 20 may have a GPS (Global Positioning System) receiver.
  • the user terminal 20 can use the location information of the user terminal acquired by the GPS receiver or the Wi-Fi module with the smartphone application, and can transmit the location information to the service server 10 or the like via the communication network NET as necessary. Has become.
  • the storage unit 23 can store the user's biological data acquired by the measurement unit 22 and the biological data measurement device 24 as PHR (Personal Health Records). That is, the user of the user terminal 20 can store the medical / health record managed by the user for a certain period or more in the storage unit 23.
  • PHR Personal Health Records
  • the service server 10 operating as a server device can include, for example, a control unit, a storage unit connected to the control unit, and a communication interface for connecting to the communication network NET. .
  • the communication interface can communicate with the user terminal 20 and the data server 40 or the hospital server 30 of the electronic medical record network 1 via the communication network NET. Communication by the communication interface is not limited to a specific communication method.
  • the control unit can include, for example, a processor such as a CPU and an MPU, and a memory such as a RAM and a ROM.
  • the ROM stores, for example, a program executed by the processor.
  • the RAM is, for example, a memory used by the processor as a work memory.
  • control unit When the processor executes the necessary programs, the control unit performs the following operations: the electronic medical record collection unit 11, the biological data collection unit 12, the reception unit 13, the limitation unit 14, the evaluation unit 15, the presentation unit 16, the reservation unit 17, the correspondence database. 18 and the operation of the doctor attribute acquisition unit 19 can be performed.
  • the electronic medical record collection unit 11 accesses, for example, the data server 40 of the data center in the electronic medical record network 1 via the communication network NET, and collects the contents of the electronic medical record of each hospital stored in the storage unit 42. Can be.
  • the electronic medical record collection unit 11 requests the control unit 41 of the data server 40 to transmit the description contents of the electronic medical record, and receives the electronic medical record transmitted from the data server 40, thereby transmitting the description contents of the electronic medical record. collect.
  • the biometric data collection unit 12 can, for example, collect biometric data stored in the storage unit 23 of each user terminal 20 via the communication network NET. For example, every time the biometric data is acquired by the measurement unit 22 or the biometric data measurement device 24 in the user terminal 20, the biometric data collection unit 12 transmits the acquired biometric data from the user terminal 20 to the service server 10, The biological data stored in the storage unit 23 of each user terminal 20 can be collected. Alternatively, the biometric data collection unit 12 requests the control unit 21 of each user terminal 20 to transmit the biometric data stored in the storage unit 23 for at least a certain period, and transmits the biometric data transmitted from each user terminal 20 for at least a certain period. It is also possible to collect biometric data by receiving the biometric data.
  • the receiving unit 13 receives a request from the user terminal 20 via the communication network NET, for example.
  • the request received by the reception unit 13 can include an evaluation request for requesting the presentation of a hospital candidate and a hospital reservation request for requesting a reservation to a hospital.
  • the control unit 21 of the user terminal 20 can also transmit information necessary for the evaluation operation in the service server 10, such as position information.
  • the latest biometric data stored as PHR in the storage unit 23 may be transmitted together.
  • the hospital reservation request includes information indicating the hospital or doctor requesting the reservation.
  • the limiting unit 14 limits the evaluation target to be evaluated when, for example, the receiving unit 13 receives the evaluation request and the biometric data of the user of the user terminal 20 from the user terminal 20 via the communication network NET.
  • the limiting unit 14 may be configured to store a plurality of hospitals or a plurality of hospitals based on the biometric data of the user of the user terminal 20 that has requested the evaluation
  • An evaluation target to be evaluated can be limited from among a plurality of doctors belonging to a hospital.
  • the evaluation unit 15 may, for example, identify a plurality of hospitals or doctors limited as evaluation targets by the limitation unit 14 based on the contents of the electronic medical record collected by the electronic medical record collection unit 11 and at least consultation time and waiting time per patient. Evaluate by evaluation items including time.
  • the medical treatment time is the time from the start of the medical treatment of the patient to the end of the medical treatment
  • the waiting time is the total of the time from the reception of the patient to the start of the medical treatment and the time from the end of the medical treatment to the end of the accounting.
  • the presentation unit 16 sets at least one of the plurality of evaluated hospitals or doctors as a reservation candidate to the user terminal 20 of the evaluation request source via the communication network NET. By transmitting, the reservation candidate can be presented to the user terminal 20.
  • the reservation unit 17 receives a hospital reservation request for the hospital or doctor selected by the user from the presented reservation candidates from the evaluation request source user terminal 20 via the communication network NET by the reception unit 13, for example.
  • the user requests the corresponding hospital to make a reservation.
  • the reservation unit 17 sends a request to the control unit 31 of the hospital server 30 corresponding to the hospital or the doctor indicated by the hospital reservation request, which operates as a hospital control unit that performs patient reservation management, via the communication network NET. It is possible to request the reservation of the user of the user terminal 20 of the reservation request source, that is, the evaluation request source.
  • the correspondence database 18 is, for example, a database of hospitals or doctors according to the attributes of the biometric data collected by the biometric data collection unit 12.
  • the limiting unit 14 can limit the plurality of hospitals or doctors to be evaluated with reference to the correspondence database 18 based on the attribute of the biometric data of the user of the user terminal 20 that has requested the evaluation.
  • the doctor attribute acquisition unit 19 can acquire doctor attribute information that can be disclosed, including at least gender and age, for each doctor belonging to each hospital.
  • the data server 40 has a database in which doctor attribute information of doctors belonging to each hospital is registered, and this database is, for example, controlled by the control unit 31 of the hospital server 30 in each hospital. It is updated every time there is a change in the doctor to which it belongs. Therefore, the doctor attribute acquisition unit 19 can acquire doctor attribute information from the control unit 41 of the data server 40 via, for example, the communication network NET.
  • many hospitals provide a web page or the like for hospital introduction by the hospital server 30 or another web server, and publish doctor attribute information which can be disclosed by a doctor belonging thereto. Therefore, the doctor attribute acquisition unit 19 can also acquire doctor attribute information from a Web page via the communication network NET, for example.
  • the receiving unit 13 can further receive the attribute information of the user of the user terminal 20 that is the requester of the evaluation via the communication network NET, and the evaluation items to be evaluated by the evaluating unit 15 further include the doctor attribute obtaining unit 19 And the attribute information of the user of the user terminal 20 of the evaluation request source received by the receiving unit 13 can be included.
  • the attribute information of the user may be transmitted together with the evaluation request from the user terminal 20, or may be received by the receiving unit 13 when the user subscribes to the service provided by the service server 10, and the information of the user who is the subscriber May be registered in a user database (not shown).
  • the patient first receives the patient at the automatic reception machine or reception counter. Then, for example, patient information including a patient ID for identifying a patient is input to the control unit 31 from a medical terminal 33 such as an automatic reception machine or a PC operated by a medical worker.
  • the control unit 31 describes or stores the reception date and time in the electronic medical record of the patient in the electronic medical record database stored in the storage unit 32 based on the patient information.
  • control unit 31 when a medical practice such as medical treatment, diagnosis, treatment, or the like of a patient by a doctor, or a medical examination operation of a patient by a nurse or a laboratory technician is performed, for example, the medical treatment start date and time, Information such as the end date and time, medical doctor, medical treatment content, prescription, test results, and the like are input to the control unit 31.
  • the control unit 31 writes, for example, the input information in the electronic medical record database of the patient in the electronic medical record database stored in the storage unit 32, that is, stores the input information.
  • the control unit 31 calculates the payment amount of each patient based on the contents of the electronic medical record stored in the storage unit 32, for example, using an accounting program stored in the storage unit 32.
  • the settlement information is input to the control unit 31 from a medical terminal 33 such as an automatic teller machine or a PC operated by a medical worker.
  • the control unit 31 stores, for example, the settlement information in the storage unit 32, and also describes or stores the accounting end date and time in the electronic medical record of the patient in the electronic medical record database stored in the storage unit 32.
  • the control unit 31 transmits, for example, information to be described in the electronic medical record.
  • the data is transmitted to the data server 40 via the network NET or the dedicated line.
  • the control unit 41 of the data server 40 updates, for example, the content of the electronic medical record of the corresponding patient in the electronic medical record database stored in the storage unit 42 based on the received information.
  • control unit 31 transmits the entire electronic medical record or the updated content to the communication network NET or The data is transmitted to the data server 40 via the dedicated line.
  • the control unit 41 of the data server 40 updates, for example, the content of the electronic medical record of the corresponding patient in the electronic medical record database stored in the storage unit 42 based on the received information.
  • the electronic medical record collection unit 11 of the service server 10 transmits the electronic medical record contents to the control unit 41 of the data server 40 of the data center in the electronic medical record network 1 via the communication network NET via a communication interface (not shown) at regular intervals.
  • a transmission request can be transmitted.
  • the contents of the electronic medical record transmitted from the data server 40 are received and stored in a storage unit (not shown).
  • patient information including personal information such as a name and an address identifying a patient and examination information on the patient is described. .
  • each electronic medical record medical treatment information, such as a reception date and time, a medical treatment start date and time, a medical treatment end date and time, a medical doctor, and a transaction end date and time, for each medical treatment of the patient is described.
  • the electronic chart description transmission request transmitted to the data server 40 includes collection target information that specifies information to be collected, and the electronic medical record collection unit 11 includes at least medical care information in the collection target information.
  • the request for transmitting the contents of the electronic medical record can include collection period information indicating a period during which information should be collected.
  • the electronic medical record collection unit 11 updates the storage contents of the storage unit (not shown) with the contents of the received electronic medical record.
  • the control unit 21 stores the acquired biometric data in the storage unit 23 as a PHR. Further, the control unit 21 can transmit the obtained biometric data to the service server 10 via a communication network NET via a communication interface (not shown).
  • the biometric data collection unit 12 of the service server 10 receives, for example, biometric data transmitted from each user terminal 20 via the communication network NET by a communication interface (not shown), and stores the biometric data stored in a storage unit (not shown). The received biometric data is additionally stored in the biometric data history of each user of the user terminal 20. Alternatively, the biometric data collection unit 12 requests the control unit 21 of each user terminal 20 to transmit the biometric data stored in the storage unit 23 for at least a certain period, and transmits the biometric data transmitted from each user terminal 20 for at least a certain period. By receiving the biometric data, the biometric data is collected.
  • the receiving unit 13 receives the evaluation request via a communication interface (not shown).
  • the limiting unit 14 stores the biometric data of the user of the user terminal 20 that has received the evaluation request together with the evaluation request in a storage unit (not shown). Based on biometric data collected from a plurality of users, an evaluation target to be evaluated is limited from among a plurality of hospitals or a plurality of doctors belonging to a plurality of hospitals. For example, the limiting unit 14 can limit the plurality of hospitals or doctors to be evaluated with reference to the correspondence database 18 based on the attributes of the biometric data of the user of the user terminal 20 that has made the evaluation request.
  • the evaluation request from the user terminal 20 includes a current position of the user terminal 20 acquired by the GPS receiver or the Wi-Fi module, and a position such as a designated position designated by a user input via a user interface (not shown). Information can be included.
  • the designated position can include, for example, address information such as the user's home and work location. Further, the designated position can be registered in advance for each user and stored in a storage unit (not shown) of the service server 10.
  • the limiting unit 14 can limit a plurality of hospitals or doctors to be evaluated based on the position information.
  • the evaluation unit 15 includes, among the contents of the electronic medical record collected by the electronic medical record collection unit 11 and stored in the storage unit (not shown), the electronic medical record corresponding to the hospital or the doctor limited as the evaluation target by the limiting unit 14 in this way. Is evaluated based on the evaluation items including at least the consultation time and the waiting time per patient based on the description contents, thereby evaluating the limited plurality of hospitals or doctors, and storing the evaluation results in a storage unit (not shown). I do.
  • the evaluation items evaluated by the evaluation unit 15 can include a degree of improvement of a symptom based on a history of biometric data collected by the biometric data collection unit 12 and stored in a storage unit (not shown) for a certain period. Further, the evaluation item evaluated by the evaluation unit 15 may include a relationship between the position information from the user terminal 20 that is the evaluation request source and the position of the hospital limited as the evaluation target.
  • the time spent in a hospital will be long, and it is not desirable to use the waiting time as it is when evaluating the hospital or doctor. Therefore, if there is a record of the examination performed in the contents of the electronic medical record collected by the electronic medical record collection unit 11 and stored in the storage unit (not shown), the time information of the medical treatment is not used for the evaluation of the hospital or the doctor. Alternatively, time is used by multiplying it by some coefficient. In addition, when collecting the contents of the electronic medical record in the electronic medical record collection unit 11, the information on the number of medical examinations in which the record of the examination is present may not be collected.
  • the evaluation request from the user terminal 20 can include user attribute information including at least gender and age for the user of the user terminal 20.
  • the user attribute information can be registered in advance for each user and stored in a storage unit (not shown) of the service server 10.
  • the doctor attribute acquisition unit 19 acquires openable doctor attribute information including at least gender and age for each doctor belonging to each hospital, and stores it in a storage unit (not shown).
  • the evaluation items evaluated by the evaluation unit 15 can include the relationship between the user attribute information and the doctor attribute information stored in the storage unit (not shown).
  • the control unit 31 of the hospital server 30 manages the time of the patient during the current affairs of the hospital.
  • the evaluation unit 15 transmits, via a communication interface (not shown), the control unit 31 of the hospital server 30 of the limited hospital or the hospital to which the limited physician belongs via the communication network NET, and at least the patient waiting for medical treatment at each hospital at the present time.
  • the number of patients and the number of reserved patients in the future can be obtained by inquiring.
  • the evaluation items evaluated by the evaluation unit 15 can include the acquired number of patients waiting for medical treatment and the number of reserved patients.
  • the presentation unit 16 sets at least one of the plurality of evaluated hospitals or doctors as a reservation candidate, and requests an evaluation request via a communication network NET by a communication interface (not shown).
  • the message is transmitted to the original user terminal 20.
  • the smartphone application or Web browser of the user terminal 20 that has received the reservation candidate presents it to the user.
  • the evaluation unit 15 calculates an evaluation value representing an evaluation result of a plurality of hospitals or doctors limited as evaluation targets, and the presentation unit 16 selects a plurality of hospitals or doctors as reservation candidates from the higher evaluation value.
  • the extracted reservation candidate may be transmitted to the user terminal 20 of the evaluation request source together with the evaluation value.
  • the evaluation unit 15 converts the evaluation result for each evaluation item into a score, sets a total score for a doctor as an evaluation value, and sets a mean value of evaluation values of doctors belonging to the hospital as a evaluation value for a hospital. good.
  • the presentation unit 16 extracts a plurality of hospitals or doctors from the one with the highest evaluation value calculated by the evaluation unit 15 as the reservation candidate, and sends the extracted reservation candidate together with the evaluation value to the user terminal 20 that is the evaluation request source. Can be sent.
  • the user terminal 20 When a patient who is the user of the user terminal 20 that has requested the evaluation and sees the reservation candidate presented on the user terminal 20 performs a reservation operation for a desired hospital using a user interface (not shown) on a smartphone application or a Web browser, the user terminal The control unit 21 of 20 transmits a hospital reservation request to the service server 10 through a communication interface (not shown) via the communication network NET.
  • the reservation unit 17 When the reception unit 13 of the service server 10 receives the hospital reservation request via a communication interface (not shown), the reservation unit 17 responds to the request by selecting the hospital selected by the user included in the hospital reservation request or the hospital to which the doctor belongs. Identify and request the hospital to make a reservation for the user. For example, the reservation unit 17 requests the control unit 31 of the hospital server 30 of the specified hospital to reserve the user of the user terminal 20 of the hospital reservation request source, that is, the evaluation request source via the communication network NET by a communication interface (not shown). Ask for.
  • the control unit 31 of the hospital server 30 that operates as a hospital control unit that manages a patient's reservation determines whether or not the reservation can be made, and if the reservation can be made, registers the patient's reservation.
  • the reservation result is returned to the service server 10 via the communication network NET.
  • the reservation unit 17 of the service server 10 receives the reservation result via a communication interface (not shown) and returns the result to the user terminal 20 that has issued the reservation request.
  • the reservation request transmitted from the reservation unit 17 to the hospital server 30 includes the e-mail address of the user of the reservation requesting user terminal 20 so that the reservation result can be notified directly from the hospital server 30 to the user. Is also good.
  • the evaluation unit 15 of the service server 10 collects the biometric data of the user of the user terminal 20.
  • the hospital or doctor limited based on the biometric data of a plurality of users is evaluated by an objective index of time, and the presentation unit 16 presents a reservation candidate to the user based on the evaluation result.
  • the reservation unit 17 makes a reservation for the hospital according to the selection of the hospital or the doctor of the user of the user terminal 20 that is the evaluation request source. Therefore, presenting a candidate of a hospital or a doctor suitable for the user based on the objective index, the user can easily select a hospital, and can easily reserve a hospital according to the selection. .
  • FIG. 2 is a block diagram illustrating an example of the overall configuration of the hospital reservation system according to the first embodiment.
  • the electronic medical record network 1 includes the hospital server 30 of each hospital and the data server 40 of the data center.
  • the hospital server 30 includes the control unit 31, the storage unit 32, and a communication interface (not shown), and is connected to the medical terminal 33.
  • the data server 40 includes the control unit 41, the storage unit 42, and a communication interface (not illustrated).
  • the user terminal 20 includes the control unit 21, the measurement unit 22, the storage unit 23, a communication interface (not shown), and a user interface (not shown). Connectable.
  • the service server 100 includes a control unit 110, a storage unit 120, and a communication interface 130.
  • the communication interface is described as “communication I / F”.
  • the control unit 110 includes, for example, a CPU 111, a RAM 112, a ROM 113, and the like, and controls each component of the service server 100 according to information processing.
  • a CPU 111 instead of the CPU 111, another processor such as an MPU may be used.
  • the ROM 113 stores, for example, an operating system executed by the CPU 111 and other programs (for example, a hospital reservation program).
  • the RAM 112 is, for example, a memory used by the CPU 111 as a work memory.
  • the CPU 111 executes a necessary program
  • the program may be stored in the storage unit 120 instead of the ROM 113, for example.
  • the CPU 111 executes a necessary program, for example, the target program stored in the ROM 113 and / or the storage unit 120 is expanded in the RAM 112. Then, the CPU 111 controls each component by interpreting and executing the program developed in the RAM 112, for example.
  • the storage unit 120 stores, for example, a program (for example, a hospital reservation program) executed by the control unit 110, setting data (for example, address information of the data server 40) necessary for executing the program, various databases, and the like. Can be memorized.
  • the storage medium included in the storage unit 120 stores information such as a program in a computer or a machine so that the information such as the program can be read by using an electrical, magnetic, optical, mechanical, or chemical action. Any medium may be used as long as the medium accumulates the data.
  • an EEPROM or the like can be used as the storage medium included in the storage unit 120.
  • the storage unit 120 may also be used by the CPU 111 as a work memory.
  • the databases stored in the storage unit 120 can include a hospital database 121, a user database 122, a correspondence database 123, a collection database 124, an evaluation database 125, and the like.
  • the hospital database, user database, correspondence database, collection database, and evaluation database are described as “hospital DB”, “user DB”, “medical DB”, “collection DB”, and “evaluation DB”. I have.
  • the communication interface 130 performs data communication with the user terminal 20, the hospital server 30, and the data server 40 via the communication network NET under the control of the control unit 110.
  • the communication protocol uses a protocol defined by the communication network NET. Specifically, TCP / IP (Transmission Control Protocol / Internet protocol), UDP / IP (User Datagram Protocol / Internet protocol), or the like can be used.
  • FIG. 3 is a diagram showing an example of the storage contents of the hospital database 121.
  • the hospital database 121 includes items such as hospital ID, access information, hospital information, hospital reputation, medical department, doctor ID, name, gender, age, number of guests, reservation status, and doctor reputation.
  • the information of the corresponding hospital is stored.
  • the reputation of the doctor is described as “reputation”, and the number of residents is described as “waiting”.
  • “Hospital ID” is a management number uniquely assigned to each hospital in the hospital reservation service provided by the service server 100.
  • the “access information” is address information for accessing the hospital server 30 or a hospital Web page.
  • “Hospital information” is general information on each hospital, such as the name, address, telephone number, business hours, holidays (business days), and parking lot information of the hospital.
  • “Hospital reputation” is subjective hospital evaluation information that has been arbitrarily input at each user terminal 20 and / or obtained from various hospital evaluation Web pages on the Internet.
  • “Clinical department” is information of a medical department that a hospital has, such as a medical department or a dermatology department.
  • doctor ID is a management number uniquely assigned to each doctor belonging to the hospital. This doctor ID can be distinguished from each other by associating it with the hospital ID, but since the doctor may move to another hospital, it is uniquely set in the hospital reservation service provided by the service server 100. If each hospital uses a unique doctor ID, a separate doctor database is prepared in the storage unit 120 so that the hospital unique doctor ID can be converted to a doctor ID for this hospital reservation service. good. “Name” is the name of each doctor. “Gender” is the gender of each doctor. “Age” is the age of each doctor. “Wait” is the current number of patients waiting for medical treatment for each doctor. “Reservation status” is the number of future reserved patients for each doctor.
  • the number of reserved patients is stored for an arbitrary period, such as dividing the day into morning and afternoon.
  • the “doctor reputation” is subjective doctor evaluation information that is arbitrarily input at each user terminal 20 and / or acquired from various hospital evaluation web pages on the Internet.
  • FIG. 4 is a diagram showing an example of the contents stored in the user database 122.
  • the user database 122 includes, as items, a user ID, a password, a name, user information, an ID for each hospital, a point, a priority condition, a date, a visit flag, and biometric data (for example, blood pressure, pulse, and the like). , Symptom patterns, etc.
  • the password is described as “PW”
  • the visit flag is described as “visit F”
  • the symptom pattern is described as “symptom P”.
  • the “user ID” is a user management number uniquely assigned when the user subscribes to the hospital reservation service provided by the service server 100.
  • “Password” is a value arbitrarily set by the user for authentication.
  • “Name” is the name of the user.
  • “User information” is information about the user, and includes a mail address, a telephone number, gender, and age.
  • the “hospital ID” is information indicating the management number of the user at each hospital, and is a combination of the hospital ID and the user management number at the hospital. With this hospital ID, it is possible to link each user with the electronic medical record of each hospital.
  • the “point” is position information of the user, and can include a current position, a home address, a work address, and a registered position.
  • the current position for example, the current position transmitted from the user terminal 20 is registered as necessary.
  • the home address, the work address, and the registered position are designated positions arbitrarily designated by the user.
  • the “priority condition” is information selected or arbitrarily specified by the user as a priority condition from predetermined options.
  • “Date” is the date when the biometric data was acquired at the user terminal 20.
  • the “visit flag” indicates whether or not the user has visited any hospital, and “1” is set when the user has visited the hospital.
  • the biological data (“blood pressure”, “pulse”, etc.) is the biological data acquired by the user terminal 20.
  • “Symptom pattern” indicates an attribute of biometric data including various measured values or a relationship between the measured values included in the biometric data, that is, a symptom set based on a pattern of the biometric data.
  • “Date”, “visit to hospital”, biometric data (“blood pressure”, “pulse”, etc.) and “symptom pattern” have a predetermined data capacity that can be assigned to each user. Is stored, and when more information is added, the oldest information is deleted.
  • a predetermined number may be used. In any case, the period or the number may be determined so as to store at least the biometric data for a certain period described later.
  • the user database 122 may store a record of a doctor ID with which the user has been treated in the past.
  • FIG. 5 is a diagram showing an example of the storage contents of the correspondence database 123.
  • the correspondence database 123 corresponds to the correspondence database 18 described in the application example.
  • the correspondence database 123 has, as items, a symptom pattern, a hospital ID, and a doctor ID.
  • the symptom pattern is described as “symptom P”.
  • the correspondence database 123 is a database of hospitals and doctors corresponding to symptom patterns.
  • Symptom pattern corresponds to the symptom pattern in the user database 122.
  • Hospital ID is a management number for specifying a hospital.
  • doctor ID is a management number for specifying a doctor. These hospital ID and doctor ID correspond to those in the hospital database 121.
  • FIG. 6 is a diagram showing an example of the storage contents of the collection database 124.
  • the collection database 124 has items such as a hospital ID, a patient ID, an appointment date and time, a reception, a medical treatment start, a doctor ID, a medical treatment end, a transaction end, a first medical examination flag, and a symptom.
  • the first consultation flag is described as “first consultation F”.
  • the “hospital ID” is a management number for specifying a hospital, and the hospital ID enables information of the hospital database 121 and the collection database 124 to be linked.
  • Patient ID is a patient management number uniquely assigned by each hospital.
  • “Reservation date and time” is the date and time when the patient made a reservation.
  • “Reception” is the time when the patient visited the hospital and performed reception. For example, in each hospital, reception is performed by a medical terminal 33, for example, a PC operated by a reception clerk or an automatic reception machine operated by a patient, and the reception time is described in an electronic medical record corresponding to the patient.
  • “Start of medical treatment” is the time when medical treatment of the doctor for the patient has started.
  • doctor ID is information for specifying a doctor who performs medical treatment.
  • the information of the hospital database 121 and the information of the collection database 124 can be linked by this doctor ID.
  • the “end of medical treatment” is the time at which the medical treatment of the doctor for the patient has ended.
  • a medical terminal 33 for example, a PC operated by a doctor or a nurse inputs a medical treatment start time, a doctor ID, and a medical treatment end time, and the information is described in an electronic medical record corresponding to the patient. Is done.
  • “Accounting end” is the time at which the patient has completed accounting.
  • the accounting end time is calculated for the patient. Is described in the electronic medical record corresponding to.
  • the “first consultation flag” indicates whether the medical treatment is the first consultation, and is set to “1” when the medical examination is the first consultation.
  • “Symptoms” is the name of the patient's disease.
  • FIG. 6 shows a case in which, when collecting the contents of the electronic medical record, the information on the number of medical examinations in which the record of the examination is present is not collected.
  • the collection database 124 further includes, for example, a flag indicating whether or not the examination has been performed as an item. In many cases, an examination is also performed at the time of the first consultation, so that a "first consultation flag" may be used as a flag indicating whether or not the examination is performed.
  • FIG. 7 is a diagram showing an example of the storage contents of the evaluation database 125.
  • the evaluation database 125 includes, as items, a user ID, a hospital ID, a hospital score, a medical department, a medical department score, a doctor ID, an overall score, a time score, and a symptom improvement degree score (for example, improvement of hypertension). Degree score, diabetes improvement degree score, urticaria improvement degree score, etc.).
  • FIG. 7 shows only the hypertension improvement degree score among the symptom-based improvement degree scores, and is described as “hypertension”.
  • the “User ID” is a management number for specifying a user, and the user ID enables information in the user database 122 and the evaluation database 125 to be linked.
  • the “hospital ID” is a management number for specifying a hospital, and the information of the hospital database 121, the collection database 124, and the evaluation database 125 can be linked by the hospital ID.
  • the “hospital score” is an evaluation value obtained by quantifying the evaluation result of the hospital. Here, the numerical value is shown with the highest point being 100 points, but this numerical expression is an example. For example, any value may be used, such as indicating the number of stars with five stars as the highest point, or expressing the number as a deviation value. This “hospital score” can be an average value of the evaluation values of all medical departments of the hospital.
  • “Clinical department” is information of a clinical department provided by the hospital, and the information of the hospital database 121 and the information of the evaluation database 125 can be linked by this medical department.
  • “Clinical department score” is an evaluation value for each medical department.
  • the “medical department score” can be an average value of evaluation values of all doctors belonging to the medical department, for example, a comprehensive score described later.
  • doctor ID is information for specifying a doctor who performs medical treatment. With this doctor ID, information of the hospital database 121, the collection database 124, and the evaluation database 125 can be linked.
  • the “overall score” is an evaluation value for each doctor. This “overall score” can be an added value of the time evaluation value of the doctor and the average value or weighted average value of all the improvement degree evaluation values.
  • Time score is a time evaluation value evaluated from the medical treatment time per patient and the waiting time for each doctor.
  • the time evaluation value is evaluated based on, for example, the average value of the medical treatment time per patient and the average value of the waiting time per patient.
  • the average value of the medical hours per patient is set to a higher evaluation value as the average value is longer according to a predetermined time range.
  • the average value of the medical treatment time per patient is 10 minutes or more, it is possible to set a perfect score of 10 points, and reduce the score by 1 point every 1 minute.
  • the average value of the waiting time per patient is set to a higher evaluation value as the average value is shorter, for example, according to a predetermined time range.
  • the “time score” may be a total score of the score obtained by the average value of the medical hours per patient and the score obtained by the average value of the waiting time per patient.
  • Symptom improvement score is an improvement evaluation value evaluated from the improvement of each symptom.
  • the improvement degree evaluation value is, for example, for a patient who has been registered in the user database 122 and is able to obtain a history of biometric data for a certain period of time among patients who received medical treatment by the doctor, Based on how much the symptom is improved based on the symptom, an evaluation value of the degree of improvement of the symptom can be obtained, and the average value of the evaluation values of all users can be obtained.
  • the score is set to 10 points, which is a perfect score, and one point is set every time the decrease is reduced by 1 mmHg. Can be reduced.
  • the “overall score” can be calculated from the “time score” and the total “improvement score by symptom”. In the present embodiment, as described later, a user who requests a hospital reservation is further specified.
  • the calculated “time score” can be corrected by adding a priority condition, user attribute information, and the like to the evaluation item.
  • FIG. 8 is a flowchart illustrating an example of a processing procedure of the service server
  • FIG. 9 is a flowchart illustrating an example of a processing procedure of the user terminal.
  • Step S101 the CPU 111 of the service server 100 determines whether it is time to collect biometric data.
  • biological data is collected at a predetermined timing, for example, once a day. If it is determined that it is time to collect biological data (step S101, YES), the CPU 111 proceeds with the process to step S102. If it is determined that it is not time to collect biometric data (step S101, NO), the CPU 111 proceeds with the process to step S103.
  • step S102 If it is determined in step S101 that it is time to collect biometric data (step S101, YES), the CPU 111 executes a biometric data collection process.
  • the CPU 111 requests the user terminal 20 of each user registered in the user database 122 to transmit the PHR stored in the storage unit 23 of the user terminal 20 via the communication interface 130.
  • the PHR request transmitted from the user terminal 20 is registered in the corresponding user's biometric data (“blood pressure”, “pulse”, etc.) in the user database 122 in response to the request.
  • the CPU 111 determines the attribute of the biometric data including the measured value or the relationship of the measured value of each item of the biometric data registered in the user database 122, that is, the symptom corresponding to the pattern of the biometric data. Register in the symptom pattern item. Note that any method may be used to determine this symptom. For example, a symptom is selected in advance for a large number of patterns of the biometric data, and the symptom is made into a database, and the pattern of the database and the pattern of the biometric data registered in the user database 122 are subjected to pattern matching, so that the most similar Symptoms can be adopted.
  • a symptom corresponding to the pattern of the biometric data registered in the user database 122 may be determined by machine learning a large amount of patterns of the biometric data.
  • Step S201 That is, the processor (not shown) of the control unit 21 of the user terminal 20 executes the hospital reservation program as one of the application programs to be executed in the background in the same manner as the e-mail program and the like. It is possible to determine whether or not a PHR request has been received. When determining that the PHR request has not been received (step S201, NO), the processor advances the process to step S202. When determining that the PHR request has been received (step S201, YES), the processor advances the process to step S203.
  • Step S202 When the processor (not shown) of the control unit 21 of the user terminal 20 determines in step S201 that the PHR request has not been received from the service server 100 (step S201, NO), there is a user operation through a user interface (not shown). It is determined whether or not. If it is determined that there is no operation (step S202, NO), the processor returns the process to step S201. If it is determined that an operation has been performed (step S202, YES), the processor advances the process to step S204.
  • Step S203 When determining in step S201 that the PHR request has been received from the service server 100 (step S201, YES), the processor (not shown) of the control unit 21 of the user terminal 20 executes a PHR transmission process.
  • the processor In the PHR transmission processing, the processor notifies the user of the user terminal 20 of the reception of the PHR request by a pop-up or the like. If the user confirming this performs an operation of permitting transmission, the processor transmits the PHR stored in the storage unit 23 to the service server 100 via a communication interface (not shown). In this case, the user authentication process need not be performed in order to respond to the request from the service server 100.
  • step S102 of the operation of the service server 100 there are user terminals that cannot collect biometric data.
  • the processor After the completion of the PHR transmission process, the processor returns the process to step S201.
  • the CPU 111 of the service server 100 updates the hospital database 121 when it is determined in step S101 that it is not time to collect biometric data (step S101, NO), or after the biometric data collection process in step S102 ends. Execute the process. For example, the CPU 111 needs to make an update by inquiring the hospital server 30 or the data server 40 of the update via the communication interface 130, or confirming a request for updating the hospital information from the hospital server 30 or the data server 40.
  • the hospital database 121 is updated for the hospital. Further, the CPU 111 can add a new hospital to the hospital database 121.
  • This new registration can be performed, for example, by the administrator of the service server 100 operating the administrator terminal (not shown) connected to the service server 100 directly or via the communication network NET.
  • the hospital ID, access information, hospital information, medical department, doctor ID, gender, and age are updated or newly registered among the items of the hospital database 121. I will not update on the situation.
  • the CPU 111 can search for subjective hospital evaluation information and doctor evaluation information from an arbitrary Web page or the like, and register the result in the hospital reputation and doctor reputation items of the hospital database 121.
  • there is no information to be changed and the contents of the hospital database 121 may not be updated at all.
  • Step S104 The CPU 111 of the service server 100 executes a process of updating the user database 122.
  • the CPU 111 updates the user database 122 for a user who needs updating by operating the user terminal 20 or an administrator terminal (not shown) via the communication interface 130. Updating according to an operation from the user terminal 20 requires user authentication, and the updating process in step S104 includes a user authentication process.
  • the CPU 111 can add a new user to the user database 122.
  • the user ID, password, name, user information, hospital-specific ID, point, and priority condition are updated or newly registered in the items of the user database 122. Some information may not be available.
  • an input by an operation from the user terminal 20 may be accepted, or the management number of the user may be inquired to each hospital server 30 by using user information, a point (home address), or the like as a key. May be collected at In the updating process in step S104, there is a case where there is no information to be changed and the content of the user database 122 is not updated at all.
  • Step S105 The CPU 111 of the service server 100 determines whether the PHR has been received from any of the user terminals 20 via the communication network NET by the communication interface 130. When determining that the PHR has not been received (step S105, NO), the CPU 111 proceeds with the process to step S106. If it is determined that a PHR has been received (step S105, YES), CPU 111 proceeds with the process to step S107.
  • Step S106 If the CPU 111 of the service server 100 determines in step S105 that the PHR has not been received from any of the user terminals 20 (step S105, NO), the communication interface 130 causes any one of the users via the communication network NET. It is determined whether an evaluation request has been received from the terminal 20. This determination includes a user authentication process. If it is determined that the evaluation request has not been received (step S106, NO), the CPU 111 returns the process to step S101. If it is determined that the user authentication has been performed and the evaluation request has been received (step S106, YES), CPU 111 proceeds to step S108.
  • Step S204 If the processor (not shown) of the control unit 21 of the user terminal 20 determines that any operation has been performed in step S202 (step S202, YES), whether the operation is an instruction to acquire biometric data by the measurement unit 22 or not Judge.
  • the instruction to acquire the biometric data can include an instruction to measure the biometric data by the measurement unit 22 provided in the user terminal 20. Further, the instruction to acquire biometric data may be an instruction to acquire biometric data measured by the biometric data measurement device 24 that can communicate with the user terminal 20. If it is determined that there is an instruction to acquire biometric data (step S204, YES), the processor advances the process to step S205. If it is determined that the performed operation is not a biometric data acquisition instruction (step S204, NO), the processor advances the processing to step S208.
  • Step S205 The processor (not shown) of the control unit 21 of the user terminal 20 executes the biometric data acquisition process when determining in step S204 that there is an instruction to acquire biometric data (step S204, YES).
  • the biometric data is acquired by measuring the biometric data by the measurement unit 22 provided in the user terminal 20.
  • biometric data is measured by the biometric data measurement device 24 that can communicate with the user terminal 20, and the measured biometric data is acquired by communication.
  • Step S206 The processor (not shown) of the control unit 21 of the user terminal 20 additionally records the acquired biometric data in the PHR stored in the storage unit 23.
  • a processor (not shown) of the control unit 21 of the user terminal 20 transmits the PHR stored in the storage unit 23 to the service server 100 via the communication network NET by a communication interface (not shown).
  • the PHR is transmitted with the user ID attached so that the biometric data of the PHR can be specified.
  • the processor returns the process to step S201.
  • Step S107 If the CPU 111 of the service server 100 determines in step S105 that a PHR has been received from any of the user terminals 20 (step S105, YES), the CPU 111 of the user database 122 in the user database 122 based on the received PHR. Update the date, biometric data ("blood pressure", "pulse”, etc.) and symptom pattern items. In this case, the received PHR is compared with the biometric data registered in the user database 122, and only the difference can be additionally updated. If the biometric data for a predetermined period or a predetermined number of biometric data has already been stored for the corresponding user in the user database 122, the oldest information is deleted and added.
  • the received PHR includes many times of biometric data per day, only the first biometric data may be added, or only the last biometric data may be added. You may do it. For example, for blood pressure, measurement data after waking up is particularly effective information, and therefore it is desirable to use the first one time of biological data. Therefore, which of a plurality of times is adopted may be determined according to the type of biometric data.
  • the CPU 111 advances the processing to step S106.
  • Step S208 If the processor (not shown) of the control unit 21 of the user terminal 20 determines that the operation performed in step S204 is not a biometric data acquisition instruction (step S204, NO), the performed operation is a medical evaluation acquisition instruction. Is determined. If it is determined that there is a medical evaluation acquisition instruction (step S208, YES), the processor advances the process to step S209. If it is determined that the performed operation is not a medical evaluation acquisition instruction (step S208, NO), the processor advances the process to step S210.
  • Step S209 The processor (not shown) of the control unit 21 of the user terminal 20 executes an evaluation process when determining in step S208 that a medical evaluation acquisition instruction has been issued (step S208, YES).
  • FIG. 10 is a flowchart illustrating an example of the evaluation process.
  • a processor (not shown) of the user terminal 20 receives an input of an evaluation condition by a user operation through a user interface (not shown).
  • the evaluation condition can include a priority condition.
  • the evaluation condition can include an evaluation target condition indicating whether the target for which the evaluation result is presented is a hospital or a doctor. Since a hospital may have a plurality of departments, the condition to be evaluated may be a department instead of a hospital.
  • the processor of the user terminal 20 sends the evaluation request to the service server 100 via the communication network NET with the input evaluation condition.
  • the evaluation request may include a user ID and a password for user authentication and position information indicating the current position of the user terminal 20.
  • the latest biometric data stored as PHR in the storage unit 23 may be transmitted together.
  • Step S2093 Thereafter, the processor of the user terminal 20 waits to receive a reservation candidate from the service server 100 via the communication network NET. That is, the processor determines whether or not a reservation candidate has been received, and if not, (step S2093, NO), repeats the processing of step S2093.
  • Step S108 If the CPU 111 of the service server 100 determines that the evaluation request has been received in step S106 (step S106, YES), the CPU 111 performs user authentication using the user ID and the password included in the received evaluation request, and then performs the same evaluation request.
  • the user database 122 is updated with the position information included in the evaluation condition and the priority condition included in the evaluation condition sent together with the evaluation request. That is, the CPU 111 updates the current position and the priority condition of the user database 122 at a point related to the user with the received information. Further, the CPU 111 stores the evaluation target condition included in the received evaluation condition in the RAM 112 or the storage unit 120. When the latest biometric data is also transmitted, the biometric data is compared with the biometric data registered in the user database 122, and additionally registered if necessary.
  • the CPU 111 limits the hospital or doctor to be evaluated. For example, the CPU 111 first reads a symptom from an item of a symptom pattern corresponding to the latest biometric data of the user in the user database 122, searches the correspondence database 123 using the read symptom as a search key, and searches for a hospital or doctor. Restrict. Further, the CPU 111 stores the attribute of the biometric data, that is, the hospital or physician to be evaluated from among the hospitals or physicians limited by the pattern of the biometric data in the priority condition item of the corresponding user in the user database 122. The information is limited by the information defining the position.
  • the CPU 111 calculates the distance from the address stored in the hospital information of the hospital database 121 by the current position stored in the point item of the corresponding user in the user database 122. Restricts hospitals or doctors within a predetermined range as evaluation targets. Similarly, the hospital or doctor to be evaluated can be limited by the home address if the priority condition is “home”, the work address if “workplace”, or the registered position if “registered position”. .
  • the method of narrowing down the hospitals or doctors to be evaluated may be limited by the position information first, and then limited by the biometric data pattern. Which of the hospital and the physician is to be evaluated depends on the evaluation target condition from the user terminal 20 that is the evaluation request source stored in the RAM 112 or the storage unit 120.
  • the CPU 111 stores the list of hospital IDs of the limited hospitals to be evaluated or the doctor IDs of the doctors to be evaluated and the hospital IDs of the hospitals to which the doctors belong in the RAM 112 or the storage unit 120. Even if the evaluation target is a physician, the hospital side may not be able to make a reservation specifying the physician, so the hospital to which the physician to be evaluated belongs is also evaluated.
  • Step S110 The CPU 111 executes an electronic medical record collection process of collecting the contents of the limited electronic medical record of the hospital.
  • FIG. 11 is a flowchart illustrating an example of the electronic medical record collection process.
  • Step S1101 In the electronic medical record collection process, the CPU 111 first determines one hospital ID by selecting one hospital ID from a list of hospital IDs stored in the RAM 112 or the storage unit 120.
  • the CPU 111 acquires the contents of the electronic medical record of the acquisition destination hospital from the data server 40 via the communication network NET by the communication interface 130.
  • the CPU 111 refers to the hospital database 121 based on the hospital ID and reads out specific information for specifying the hospital, for example, the hospital ID, access information, hospital name, address, or telephone number.
  • the CPU 111 requests the control unit 41 of the data server 40 via the communication network NET via the communication interface 130 to transmit the contents described in the electronic medical record together with the specific information.
  • the CPU 111 receives the contents of the electronic medical chart transmitted from the data server 40 in response to the request via the communication interface 130.
  • the CPU 111 registers information in the hospital database 121 and the collection database 124 based on the contents of the received electronic medical record. For example, the CPU 111 stores, in the collection database 124, information on each medical treatment described in the electronic medical record for each patient ID, that is, the appointment date and time, the reception, the medical treatment start, the doctor ID, the medical treatment end, the accounting end, the first medical examination flag, and the symptoms.
  • the CPU 111 when the examination is recorded in the received electronic medical record, the CPU 111 does not store the information on the medical care of the medical care in the collection database 124. Further, the CPU 111 totalizes the current number of patients waiting for medical treatment for each doctor ID based on the contents of the electronic medical record, and stores the total number in the “waiting” item corresponding to each doctor ID in the hospital database 121. I do.
  • the CPU 111 acquires the number of reserved patients from the acquisition destination hospital via the communication network NET by the communication interface 130.
  • the CPU 111 reads the access information of the hospital by referring to the hospital database 121 based on the hospital ID, and sends the current information about each doctor to the control unit 31 of the hospital server 30 of the hospital via the communication network NET by the communication interface 130.
  • the number of patients waiting for medical treatment at the present time can be determined by tabulating the contents of the electronic medical record.However, there is no electronic medical record for patients who have requested an appointment for the first consultation. I can't figure out. For this reason, it is necessary to inquire of the acquisition hospital about the number of reserved patients.
  • the CPU 111 receives, via the communication interface 130, information on the number of reserved patients transmitted from the hospital server 30 in response to the inquiry.
  • Step S1105 the CPU 111 stores the number of reserved patients in the item of “reservation status” in association with each doctor ID in the hospital database 121 in accordance with the received information on the number of reserved patients at the current time for each doctor.
  • Step S1106 the CPU 111 determines whether or not the collection of the contents of the electronic medical record has been completed for all the hospitals indicated by the hospital ID list stored in the RAM 112 or the storage unit 120. If it is determined that there is a hospital that has not been collected yet (step S1106, NO), the CPU 111 returns the process to step S1101, and performs the process for the next hospital. If it is determined that the collection of the contents of the electronic medical record has been completed from all listed hospitals (step S1106, YES), the CPU 111 advances the processing to step S111.
  • Step S111 The CPU 111 executes an evaluation calculation process of calculating an evaluation value based on the contents of the electronic medical records of each limited hospital stored in the collection database 124.
  • FIG. 12 is a flowchart illustrating an example of the evaluation calculation process.
  • Step S1111 In the evaluation calculation process, the CPU 111 first selects one hospital ID from the list of hospital IDs stored in the RAM 112 or the storage unit 120 to determine a hospital to be processed.
  • the CPU 111 evaluates the doctor based on the evaluation items including at least the medical treatment time and the waiting time per patient.
  • the CPU 111 refers to the collection database 124 based on the hospital ID and calculates a time score for each doctor at the hospital to be processed.
  • the time score can be calculated, for example, based on the sum of the score based on the average value of the medical hours per patient and the score based on the average value of the waiting time.
  • the medical treatment time is the time from the start of medical treatment to the end of medical treatment stored in the collection database 124
  • the waiting time is the time from the reception to the start of medical treatment stored in the collection database 124, and the time from the end of medical treatment to the end of accounting.
  • the CPU 111 stores the calculated time score for each doctor in the RAM 112 or the storage unit 120.
  • the consultation time is long at the first consultation. Therefore, it is determined whether or not the first consultation is performed based on the “first consultation flag” in the collection database 124, and the time used for calculating the time score is predetermined for the first consultation. It may be used after being multiplied by the given coefficient.
  • the CPU 111 evaluates the doctor by an evaluation item including a relationship between the attribute information of the doctor and the attribute information of the user. For example, the CPU 111 corrects the time score for each doctor stored in the RAM 112 or the storage unit 120 based on the attribute information.
  • the attribute information includes, for example, gender and age.
  • the CPU 111 compares the attribute information of each doctor stored in the hospital database 121 with the attribute information stored in the user database 122 and corresponding to the user ID of the evaluation requesting user. Then, the score value is corrected in accordance with a predetermined rule, such as increasing the score for the same sex or increasing the score as the age decreases.
  • the CPU 111 stores the corrected time score for each doctor in the RAM 112 or the storage unit 120.
  • the CPU 111 evaluates the doctor based on an evaluation item including a relationship between the position information designated as the priority condition from the user terminal 20 and the position of the hospital. For example, the CPU 111 corrects based on the attribute information and corrects the time score for each doctor stored in the RAM 112 or the storage unit 120 based on the priority condition.
  • the CPU 111 refers to the priority condition corresponding to the user ID of the user requesting the evaluation stored in the user database 122, and the position information designated as the priority condition is added to the address of the hospital stored in the hospital database 121. On the other hand, if the distance is within a certain distance, the score value is increased.
  • the CPU 111 stores the corrected time score for each doctor in the RAM 112 or the storage unit 120.
  • the CPU 111 evaluates the doctor based on the evaluation items including the current number of patients waiting for medical treatment and the number of reserved patients. For example, the CPU 111 corrects the time score for each doctor stored in the RAM 112 or the storage unit 120 based on the priority condition and corrects the time score based on the number of patients waiting for medical treatment and the number of reserved patients. The CPU 111 totalizes the number of patients waiting for medical treatment and the number of reserved patients for each doctor stored in the hospital database 121, and increases the score value as the total number is smaller. The CPU 111 stores the corrected time score for each doctor in the RAM 112 or the storage unit 120.
  • the CPU 111 refers to the user database 122 and the collection database 124 to calculate a symptom improvement degree score for each doctor. For example, based on each user's hospital ID in the user database 122, the user's symptom is acquired from the collection database 124, and a user having the same symptom as the symptom is specified. Further, biometric data to be referred to is determined according to the symptom. Then, if the specified user is registered in the user database 122, the CPU 111 reads out the history of the biometric data determined by the symptom of the user for a certain period from the user database 122 and evaluates it. For example, if the symptom is hypertension, the CPU 111 reads and evaluates the blood pressure value for a certain period.
  • FIG. 13 is a diagram showing an example of the history of the read biometric data.
  • the systolic blood pressure decreases by D.
  • the score is determined to be 10 points, which is a perfect score if the reduction amount D during a certain period P of the systolic blood pressure, for example, one month is 20 mmHg or more, and to be reduced by one point each time the reduction amount decreases by 1 mmHg.
  • FIG. 14 is a diagram showing another example of the history of the biometric data. Also in the example of this figure, it is assumed that the reduction amount D of the systolic blood pressure during the certain period P is in the range where the score is the same as that of the example of FIG. However, in this example, a temporarily deteriorated history is included. In such a case, the same score as in the example of FIG. 13 may be used as it is, or a lower score than in the example of FIG. 13 may be calculated. In particular, when the timing at which the temporarily deteriorated state turned to improvement was the timing at which there was a switch to another hospital or doctor, there is a high possibility that the temporarily deteriorated state is due to a misdiagnosis. .
  • the CPU 111 can perform this misdiagnosis based on, for example, the date recorded in the reservation date and time item of the collection database 124 and the date recorded in the date item of the user database 122 and the visit record recorded in the visit flag item. Sex can be determined and the score can be modified accordingly.
  • the CPU 111 stores the symptom improvement degree score for each physician thus calculated in the RAM 112 or the storage unit 120.
  • Step S1117 the CPU 111 calculates an overall score from the symptom-based improvement degree score and the corrected time score for each doctor stored in the RAM 112 or the storage unit 120. Further, the CPU 111 calculates a clinical department score and a hospital score from the total score for each doctor. The CPU 111 stores the total score, medical department score, and hospital score calculated for each doctor in the RAM 112 or the storage unit 120.
  • Step S1118 the CPU 111 registers the scores thus calculated and stored in the RAM 112 or the storage unit 120 in the evaluation database 125 in association with the user ID.
  • the CPU 111 registers the scores thus calculated and stored in the RAM 112 or the storage unit 120 in the evaluation database 125 in association with the user ID.
  • the time score based on the attribute information, the priority condition, and the like, as shown in FIG. 7, even in the same doctor, medical department, and hospital, different score values for each user are obtained in the evaluation database 125. Will be registered.
  • Step S1119 the CPU 111 determines whether the calculation of the evaluation value has been completed for all the hospitals indicated by the hospital ID list stored in the RAM 112 or the storage unit 120. If it is determined that there is a hospital for which the evaluation value has not been calculated yet (step S1119, NO), the CPU 111 returns the process to step S1111 and performs the process for the next hospital. If it is determined that the calculation of the evaluation values has been completed for all the listed hospitals (step S1119, YES), the CPU 111 advances the processing to step S112.
  • the CPU 111 reads out and sorts the evaluation results corresponding to the user ID of the user who made the evaluation request stored in the evaluation database 125 in accordance with the evaluation target conditions stored in the RAM 112 or the storage unit 120. For example, if the evaluation target condition is a hospital, a set of a hospital ID and a hospital score is read out and sorted in descending order of the hospital score. Further, for example, if the evaluation target condition is a doctor, a set of a doctor ID and a total score is read out and sorted in descending order of the total score. The CPU 111 stores the sorted result in the RAM 112 or the storage unit 120.
  • the CPU 111 determines a reservation candidate based on the sorted result stored in the RAM 112 or the storage unit 120, and transmits the reservation candidate to the user terminal 20 of the evaluation request source via the communication network NET by the communication interface 130. It is sufficient that the number of reservation candidates is at least one, but it is desirable that a plurality of reservation candidates be determined and transmitted in order to give the user options. Of course, the next candidates may be sequentially determined and transmitted according to a return instruction from the user terminal 20.
  • the reservation candidate is determined according to the evaluation target condition stored in the RAM 112 or the storage unit 120. For example, if the condition to be evaluated is a hospital, at least the hospital information including the name and address of the hospital and the score value of the hospital can be included.
  • the hospital information can be obtained from the hospital database 121. Also, for example, if the condition to be evaluated is a doctor, at least the doctor's name, gender, doctor information including the age and the score value of the doctor, and the hospital information of the hospital to which the doctor belongs and the score value of the hospital, Can be included. The doctor information and the hospital information can be obtained from the hospital database 121.
  • Step S2094 If it is determined in step S2093 that a reservation candidate has been received (step S2093, YES), the processor of the user terminal 20 advances the process to step S2094, and presents the received reservation candidate to the user via a user interface (not shown).
  • Step S114 After transmitting the reservation candidate in step S113, the CPU 111 of the service server 100 determines whether or not a reservation request from the user terminal 20 has been received by the communication interface 130 via the communication network NET. When determining that the reservation request has not been received (step S114, NO), the CPU 111 advances the process to step S115.
  • Step S2095 After presenting the reservation candidate received in step S2094 to the user, the processor (not shown) of the user terminal 20 accepts an end or reservation input by a user operation through a user interface (not shown).
  • the input of the reservation includes selection of a hospital or doctor who wants to make a reservation, and input of a desired date and time.
  • Step S2096 the processor of the user terminal 20 determines whether or not the received input is an end input. If it is determined that the accepted input is not an end input, that is, a reservation input (step S2096, NO), the processor advances the process to step S2097.
  • step S2097 If it is determined in step S2096 that the reservation input has been received (step S2096, NO), the processor of the user terminal 20 transmits a reservation request to the service server 100 via the communication network NET.
  • Step S2098 Thereafter, the processor of the user terminal 20 waits to receive a reservation result from the service server 100 via the communication network NET. That is, the processor determines whether or not the reservation result has been received, and if not received (step S2098, NO), the processing of step S2098 is repeated.
  • Step S116 If the CPU 111 of the service server 100 determines that the reservation request has been received in step S114 (step S114, YES), the process proceeds to step S116, and the hospital server of the hospital is connected by the communication interface 130 via the communication network NET. A reservation request is transmitted to the user 30 together with the PHR of the user stored in the user database 122. The latest biometric data may be used instead of the PHR including all biometric data. At this time, the CPU 111 refers to the hospital ID in the user database 122, and if it is confirmed that the user is a user having a management number in the hospital, the management number is added to the reservation request. Can be included.
  • Step S117 Thereafter, the CPU 111 waits for reception of the reservation result from the hospital server 30 of the corresponding hospital via the communication network NET by the communication interface 130. That is, the CPU 111 determines whether or not the reservation result has been received, and when it is determined that the reservation result has not been received (step S117, NO), the step S117 is repeated.
  • the hospital server 30 that manages the reservation of the patient performs a reservation process according to the reservation request. Then, the result is returned to the service server 100 via the communication network NET.
  • step S118 If it is determined in step S117 that the reservation result has been received (step S117, YES), the CPU 111 transmits the reservation result to the user terminal 20 of the reservation request source via the communication network NET by the communication interface 130. Thereafter, the CPU 111 returns the processing to step S114.
  • step S2099 If it is determined in step S2098 that the reservation result has been received (step S2098, YES), the processor of the user terminal 20 advances the process to step S2099, and presents the received reservation result to the user via a user interface (not shown). Thereafter, the processor returns the process to step S2095.
  • step S2095 the user can reset another desired reservation date and time or select another hospital, another doctor, or the like. It is.
  • the user inputs an end to end the medical evaluation process.
  • Step S20910 If the processor (not shown) of the user terminal 20 determines that the input received in step S2096 is the end input (step S2096, YES), the process proceeds to step S20910, and the end request is sent via the communication network NET. Send to the service server 100. Then, the processor returns the process to step S201.
  • Step S115 If the CPU 111 of the service server 100 determines that the reservation request has not been received in step S114 (step S114, NO), the CPU 111 of the service terminal 100 further transmits an end request from the user terminal 20 via the communication network NET via the communication interface 130. Is determined. If it is determined that the termination request has not been received (step S115, NO), the CPU 111 returns the process to step S114. When determining that the end request has been received (step S115, YES), the CPU 111 returns the process to step S101.
  • Step S210 When the processor (not shown) of the control unit 21 of the user terminal 20 determines that the operation performed in step S208 is not a medical evaluation acquisition instruction (step S208, NO), the CPU executes other processing according to the operation. I do.
  • the other processing includes, for example, processing corresponding to a new registration operation or an information update operation of the user for performing the update processing of the user database 122 in the above-described step S104 of the service server 100. Then, after executing the processing, the processor returns the processing to step S201.
  • the CPU 111 of the service server 100 collects the contents of each electronic medical record from the electronic medical record network 1 for sharing the electronic medical records among a plurality of hospitals.
  • a history of biometric data of each of a plurality of users is collected for a certain period of time from the user terminal 20 of each user, and based on the collected information, at least for each hospital, and further, for each medical department of each hospital or a doctor of each hospital.
  • a time score based on at least the medical treatment time and the waiting time per patient, and a symptom improvement degree score based on the improvement degree of the symptom of each user are calculated and stored in the evaluation database 125.
  • the CPU 111 transmits the evaluation score to the user terminal 20 and presents the evaluation score to the user, so that the user refers to the hospital, medical department or doctor who is going to receive medical treatment with reference to the presented score. And it can be selected.
  • the evaluation result is obtained by the numerical value of the evaluation value, that is, the score
  • the evaluation results can be ordered by the numerical value, and as a result, the reservation candidate suitable for the user is easily determined. be able to.
  • the correspondence database 123 by using the correspondence database 123, it is possible to easily and quickly limit the hospitals or doctors to be evaluated.
  • the user's biometric data can be easily collected.
  • a candidate more suitable for the user can be provided by adding an evaluation based on the symptom improvement status, ie, the degree of symptom improvement, in addition to the temporal evaluation.
  • the index for selecting a hospital to be reserved by the user is provided. Can be provided, and user selection can be facilitated.
  • the doctor suitable for the user can be highly evaluated, and the user can be more suitable. Physician can be a candidate.
  • hospitals that the user can go to are limited according to the current position of the user requesting the evaluation and the designated position designated by the user, so that an inappropriate hospital is presented to the user as a candidate. Can be reduced.
  • the number of patients waiting for medical treatment at the present time and the future reservation status are referred to, and a hospital or a physician who can perform medical treatment immediately with a short waiting time is higher.
  • a hospital or a physician who can perform medical treatment immediately with a short waiting time is higher.
  • the point When searching for a hospital that can be treated immediately, the point can be specified when inputting the conditions in step S2091 on the user terminal 20, so that the number of patients waiting for medical treatment and the number of reserved patients in step S1115 can be determined.
  • the weight of the correction based on the number may be increased, that is, the score value may be increased.
  • the weight of the correction based on the attribute information in step S1113 or the correction based on the priority condition in step S1114 may be reduced, or the correction may be skipped.
  • the service server 100 may have a charging process that can collect an introduction fee from the reservation destination hospital.
  • the hospital may provide a service such that the letter of introduction is unnecessary or reduced for the user reserved by the processing procedure of the service server 100 as described above.
  • FIG. 15 is a flowchart illustrating an example of a processing procedure of the service server 100 in the second embodiment. The same processes as those in FIG. 8 are denoted by the same reference numerals.
  • Step S119 the CPU 111 of the service server 100 determines whether it is time to collect biometric data and electronic medical records.
  • biometric data and electronic medical records are collected at a predetermined timing, for example, once a day. If it is determined that it is not time to collect the biometric data and the electronic medical record (step S119, NO), the CPU 111 advances the processing to step S103. If it is determined that it is time to collect the biometric data and the electronic medical record (step S119, YES), the CPU 111 advances the processing to step S102.
  • step S102 If it is determined in step S101 that it is time to collect the biometric data and the electronic medical record (step S101, YES), the CPU 111 first executes the same biometric data collection processing as in the first embodiment.
  • Step S120 the CPU 111 executes an electronic medical record collection process.
  • the target hospital is not limited, and thus the CPU 111 collects the contents of the electronic medical records of all hospitals without limitation.
  • FIG. 16 is a flowchart illustrating an example of the electronic medical record collection process.
  • Step S1201 In the electronic medical record collection process, the CPU 111 first selects one hospital ID from the hospital IDs registered in the hospital database 121 to determine the acquisition destination hospital.
  • Step S1202 the CPU 111 acquires the contents of the electronic medical record of the acquisition destination hospital from the data server 40 via the communication network NET by the communication interface 130.
  • the processing in step S1202 is the same as the processing in step S1102 in the first embodiment. That is, the CPU 111 refers to the hospital database 121 based on the hospital ID and reads out specific information for specifying the hospital, for example, the hospital ID, access information, hospital name, address, or telephone number. Then, the CPU 111 requests the control unit 41 of the data server 40 via the communication network NET via the communication interface 130 to transmit the contents described in the electronic medical record together with the specific information. The CPU 111 receives the contents of the electronic medical chart transmitted from the data server 40 in response to the request via the communication interface 130.
  • the CPU 111 registers information in the hospital database 121 and the collection database 124 based on the contents of the received electronic medical record. For example, the CPU 111 stores, in the collection database 124, information on each medical treatment described in the electronic medical record for each patient ID, that is, the appointment date and time, the reception, the medical treatment start, the doctor ID, the medical treatment end, the accounting end, the first medical examination flag, and the symptoms.
  • the CPU 111 stores, in the collection database 124, information on each medical treatment described in the electronic medical record for each patient ID, that is, the appointment date and time, the reception, the medical treatment start, the doctor ID, the medical treatment end, the accounting end, the first medical examination flag, and the symptoms.
  • Step S1204 the CPU 111 determines whether or not the collection of the contents of the electronic medical record has been completed for all the hospitals indicated by the hospital ID registered in the hospital database 121. If it is determined that there is a hospital that has not been collected yet (step S1204, NO), the CPU 111 returns the process to step S1201 and performs the process for the next hospital. If it is determined that the collection of the contents of the electronic medical record has been completed from all registered hospitals (step S1204, YES), the CPU 111 advances the processing to step S103.
  • step S103 determines in step S119 that it is not the time to collect the biometric data and the electronic medical record (step S119, NO), or after the electronic medical record collection processing in step S110 ends.
  • the CPU 111 determines The same processing of [Step S101] to [Step S106] is performed. However, when it is determined in step S106 that the evaluation request has not been received (step S106, NO), the process returns to step S119. That is, the CPU 111 performs an update process of the hospital database 121 and an update process of the user database 122. Then, the CPU 111 determines whether a PHR or an evaluation request has been received from any of the user terminals 20.
  • the CPU 111 returns the process to step S119. If it is determined that the PHR has been received, the CPU 111 updates the date and biometric data (“blood pressure”, “pulse”, etc.) of the corresponding user in the user database 122 based on the received PHR. . When determining that the evaluation request has been received, the CPU 111 performs user authentication using the user ID and the password included in the received evaluation request, and then includes the location information and the evaluation information included in the evaluation request. The user database 122 is updated according to the priority condition.
  • Step S109 After receiving the evaluation request and updating the user database 122, the CPU 111 limits the hospital to be evaluated as in the first embodiment.
  • Step S121 After that, the CPU 111 performs a number collection process of counting the number of patients waiting for medical treatment and the number of reserved patients at the current time in each hospital limited in step S109. That is, in step S120, the contents of the electronic medical record are collected at a predetermined timing, for example, once a day. Therefore, the number of patients waiting for medical treatment and the number of reserved patients are not counted. Therefore, the CPU 111 collects the numbers.
  • FIG. 17 is a flowchart illustrating an example of the number collecting process.
  • Step S1211 In the headcount collection process, the CPU 111 first selects one hospital ID from the list of limited hospital IDs stored in the RAM 112 or the storage unit 120 to determine the acquisition destination hospital.
  • the CPU 111 acquires the number of patients waiting for medical treatment and the number of reserved patients from the acquisition hospital via the communication network NET by the communication interface 130.
  • the CPU 111 reads the access information of the hospital by referring to the hospital database 121 based on the hospital ID, and sends the current information about each doctor to the control unit 31 of the hospital server 30 of the hospital via the communication network NET by the communication interface 130. Inquire about the number of patients waiting for medical treatment at the time and the number of reserved patients. Then, the CPU 111 receives, via the communication interface 130, information on the number of patients waiting for medical treatment and the number of reserved patients transmitted from the hospital server 30 in response to the inquiry.
  • Step S1213 Next, according to the received information on the number of patients waiting for medical treatment and the number of reserved patients for each doctor at the current point in time, the CPU 111 associates each of the doctor IDs in the hospital database 121 with the items of “waiting” and “reservation status”. Remember each person.
  • Step S1214 the CPU 111 determines whether or not the collection of the number of persons has been completed for all hospitals indicated by the hospital ID list stored in the RAM 112 or the storage unit 120. If it is determined that there is a hospital that has not been collected yet (step S1214, NO), the CPU 111 returns the process to step S1211 and performs the process for the next hospital. When it is determined that the collection of the number of persons from all the listed hospitals is completed (step S1214, YES), the CPU 111 advances the processing to step S111.
  • the CPU 111 performs the same processing of [Step S111] to [Step S113] as in the first embodiment. That is, the CPU 111 calculates the evaluation value only based on the contents of the limited hospital out of the contents of the electronic medical record of each hospital stored in the collection database 124. After that, the CPU 111 reads out and sorts the evaluation result corresponding to the user ID of the user of the evaluation request source stored in the evaluation database 125 according to the evaluation target condition included in the evaluation condition, and sorts the sorted result and the evaluation target condition. The reservation candidates are determined in accordance with. Then, the CPU 111 transmits the determined reservation candidate to the user terminal 20 of the evaluation request source via the communication network NET by the communication interface 130.
  • FIG. 18 is a flowchart illustrating an example of a processing procedure of the service server 100 according to the third embodiment. The same processes as those in FIG. 15 are denoted by the same reference numerals.
  • Step S119 the CPU 111 of the service server 100 determines whether or not it is time to collect biometric data and electronic medical records, as in the second embodiment. If it is determined that it is time to collect the biometric data and the electronic medical record (step S119, YES), the CPU 111 performs the same processes of [step S102] and [step S120] as in the second embodiment. That is, the CPU 111 executes the same biological data collection processing as in the first embodiment and the same electronic medical record collection processing as in the second embodiment.
  • Step S122 Thereafter, the CPU 111 executes a first evaluation calculation process of calculating an evaluation value based on the contents of the electronic medical record of each hospital stored in the collection database 124.
  • a time score for each doctor is calculated as an evaluation value.
  • FIG. 19 is a flowchart illustrating an example of the first evaluation calculation process.
  • Step S1221 In the first evaluation calculation process, the CPU 111 first determines a hospital to be processed by selecting one hospital ID from hospital IDs registered in the hospital database 121.
  • the CPU 111 refers to the collection database 124 based on the hospital ID and calculates a time score for each doctor at the hospital to be processed.
  • the CPU 111 stores the calculated time score for each doctor in the RAM 112 or the storage unit 120.
  • Step S1222 the CPU 111 registers the calculated and stored time score of each doctor belonging to the hospital in the RAM 112 or the storage unit 120 in the item of the total score corresponding to the corresponding doctor ID in the evaluation database 125.
  • Step S1223 the CPU 111 determines whether the calculation of the evaluation value has been completed for all the hospitals indicated by the hospital IDs stored in the hospital database 121. If it is determined that there is a hospital for which an evaluation value has not yet been calculated (step S1223, NO), the CPU 111 returns the process to step S1211 and performs the process for the next hospital. When it is determined that the calculation of the evaluation values has been completed for all hospitals (step S1223, YES), the CPU 111 advances the processing to step S103.
  • Step S109 After receiving the evaluation request and updating the user database 122, the CPU 111 of the service server 100 determines the position in the information stored in the priority condition item of the corresponding user in the user database 122, as in the first embodiment. Limit the hospitals to be evaluated based on the specified information.
  • Step S121 the CPU 111 inquires about the number of patients waiting for medical treatment and the number of reserved patients in each of the hospitals limited in step S109, and registers the result in the hospital database 121. Perform collection processing.
  • Step S123 Thereafter, the CPU 111 executes a second evaluation calculation process of calculating an evaluation value based on the contents of the electronic medical record of each hospital stored in the collection database 124.
  • FIG. 20 is a flowchart illustrating an example of the second evaluation calculation process.
  • Step S1111 In the second evaluation calculation process, the CPU 111 first selects one hospital ID from the list of hospital IDs stored in the RAM 112 or the storage unit 120, as in the first embodiment, thereby obtaining the hospital to be processed. To determine.
  • Step S1231 the doctor ID of each doctor belonging to the hospital to be processed is acquired from the hospital database 121, the time score corresponding to the doctor ID is read out from the item of the total score corresponding to the doctor ID in the evaluation database 125, and the RAM 112 is read. Alternatively, it is stored in the storage unit 120.
  • Step S1113] to [Step S1119] Subsequent processes in [Step S1113] to [Step S1119] are the same as those in the first embodiment. That is, the CPU 111 corrects the time score for each doctor stored in the RAM 112 or the storage unit 120 based on the attribute information and the priority condition, and further corrects based on the number of patients waiting for medical treatment and the number of reserved patients. Further, the CPU 111 refers to the user database 122 and the collection database 124 to calculate a symptom-based improvement degree score for each doctor. Then, the CPU 111 calculates an overall score from the symptom improvement degree score for each doctor and the corrected time score, and further calculates a medical department score and a hospital score from the comprehensive score for each doctor.
  • the obtained scores are registered in the evaluation database 125 in association with the user ID. Thereafter, the CPU 111 determines whether or not the calculation of the evaluation value has been completed for all the hospitals indicated by the hospital ID list stored in the RAM 112 or the storage unit 120. The process returns to step S1111 to perform the process for the next hospital. If it is determined that the calculation of the evaluation values has been completed for all the hospitals listed, the CPU 111 proceeds with the process to step S112.
  • the present invention is not limited to the above-described embodiments as they are, and can be embodied by modifying constituent elements in an implementation stage without departing from the scope of the invention.
  • Various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the above embodiments. For example, some components may be deleted from all the components shown in the embodiment. Further, components of different embodiments may be appropriately combined.
  • processing procedure described with reference to the flowchart is merely an example, and each processing may be changed as much as possible. Further, in the processing procedure described above, steps can be omitted, replaced, and added as appropriate according to the embodiment.
  • An electronic medical record network (1) for sharing the electronic medical record among the plurality of hospitals;
  • An electronic medical record collection unit (11) for collecting the contents of the electronic medical record from the electronic medical record network;
  • a biometric data collection unit (12) for collecting biometric data of each of a plurality of users via a communication network (NET);
  • a receiving unit (13) for receiving a request from the user terminal (20) via the communication network;
  • a hospital control unit (31) provided at each of the plurality of hospitals for managing reservations of patients;
  • the reception unit receives the reservation request.
  • a hospital reservation system comprising:
  • Appendix 2 A hospital reservation method executed by a server device having a processor (111) and memories (112, 120), By the processor, in each of the plurality of hospitals, at least, patient information on the patient and, for each medical treatment, medical treatment information including reception date and time, medical treatment start date and time, medical treatment end date and time, medical doctor, and accounting end date and time are described.

Landscapes

  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

病院予約システムは、評価要求元のユーザの生体データと予め収集した複数ユーザの生体データとに基づいて限定した上で、電子カルテネットワークから収集した電子カルテの記載内容に基づく、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって病院又は医師を評価して決定した予約候補を、要求元のユーザ端末に提示させる提示部と、当該ユーザ端末からの予約要求に応じて、該当する病院に設けられた、患者の予約管理を行う病院制御部へ予約を依頼する予約部と、を具備する。

Description

病院予約システム及びサーバ装置
　本発明は、病院予約システム及びサーバ装置に関する。
　例えば、特許文献１は、複数の医師それぞれに対する評価に基づいて、患者が自己の病気に関する治療を受ける上で適切な医師を選定できるようにした技術を提案している。
日本国特開２０１７－２１６４１号公報
　上記特許文献１では、医師の評価は、その医師に関する情報を他の複数の医師に提示して、この情報に基づいて他の医師が評価するというものであり、主観的な評価になり易い。客観的な指標に基づいてユーザに適する医師又は医師が所属する病院の候補をユーザに提示し、その中からユーザが選定して予約することはできていない。
　本発明は、上記の事情に着目してなされたものであり、その目的は、客観的な指標に基づいてユーザに適する病院または医師の候補を提示でき、ユーザの選定に応じて病院を予約することができる病院予約システム及びサーバ装置を提供することである。
　本発明は、上述した課題を解決するために、以下の構成を採用する。
　本開示の一態様では、病院予約システムは、複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークと、前記電子カルテネットワークから前記電子カルテの記載内容を収集する電子カルテ収集部と、通信ネットワークを介して、複数のユーザそれぞれの生体データを収集する生体データ収集部と、前記通信ネットワークを介して、ユーザ端末から要求を受け付ける受付部と、前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部と、前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部と、前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部と、前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部と、前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部と、を具備する。　
　なお、病院とは、ある建物の一室と言った小規模の病院から、一つの敷地内に複数の病棟が配置された大規模病院、更には、複数地域に分散した系列病院を含む病院グループであって良い。病院グループの場合、電子カルテは、グループ内の病院毎に分散配置される場合もある。また、電子カルテは、病院内ではなく、電子カルテネットワーク内に設けられたデータセンタに配置されても良い。ここで、配置とは、記憶媒体を備える記憶部に記憶されることを含む。電子カルテのデータフォーマットは、病院毎に異なっていても良く、各病院の電子カルテが電子カルテネットワーク内の統一フォーマットに変換されて、データセンタの記憶部に蓄積されることができる。各病院とデータセンタとの間の電子カルテの送受信においては、データ暗号化などにより、秘匿性が担保される。電子カルテネットワーク内では、医療従事者毎に制限されたアクセス権限が与えられて、各医療従事者が操作する医療端末から当該病院またはデータセンタに配置された電子カルテの情報の閲覧や更新が可能になっている。また、電子カルテネットワーク内では、患者であるユーザ毎に制限されたアクセス権限が与えられて、各ユーザが操作するユーザ端末からデータセンタに配置された自身の電子カルテの情報を閲覧できるようになっている場合もある。この場合も、ユーザ端末とデータセンタとの間のデータ送受信においては、データ暗号化などにより、秘匿性が担保されることが望ましい。　
　上記の構成の病院予約システムによれば、任意のユーザ端末からの評価要求に応じて、そのユーザ端末のユーザの生体データと収集した複数のユーザの生体データとに基づいて限定した病院又は医師を時間という客観的な指標によって評価し、その評価結果に基づいて予約候補をユーザに提示し、評価要求元のユーザ端末のユーザの選定に従って、病院の予約を行うので、客観的な指標に基づいてユーザに適する病院または医師の候補を提示して、ユーザが容易に病院を選定でき、また、その選定に応じて病院を簡便に予約することができるようになる。
　なお、上記一態様において、前記評価部は、前記複数の病院又は医師の評価結果を表す評価値を算出し、前記提示部は、前記評価部が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、前記抽出した前記予約候補をその評価値と共に前記要求元の前記ユーザ端末に提示させることができる。　
　当該構成によれば、評価値という数値を用いることで評価値の順番に並べ替えることができ、ユーザに適した予約候補を容易に提示することができる。
　また、上記一態様において、病院予約システムは、前記生体データ収集部によって収集した前記生体データの属性に応じて病院又は医師をデータベース化した対応関係データベースを更に具備し、前記限定部は、前記要求元の前記ユーザ端末の前記ユーザの前記生体データの属性により、前記対応関係データベースを参照して、前記評価対象となる前記複数の病院又は医師を限定するようにしても良い。　
　当該構成によれば、データベースを用いることで、容易且つ迅速に評価対象の病院又は医師を限定することができるようになる。
　また、上記一態様において、前記生体データ収集部は、それぞれユーザの生体データを収集する複数のユーザ端末それぞれから送信されたユーザの生体データを、前記通信ネットワークを介して受信することができる。　
　当該構成によれば、病院予約サービスに加入するユーザの各ユーザ端末から生体データを収集することで、生体データを容易に収集することができる。
　また、上記一態様において、前記生体データ収集部は、前記複数のユーザそれぞれの生体データの履歴を収集し、前記評価部によって評価する評価項目は、更に、前記生体データ収集部によって収集した前記生体データの一定期間の履歴に基づく症状の改善度を含むことができる。　
　当該構成によれば、症状の改善度という症状の改善状況に基づいた評価を加えることで、よりユーザに適した候補を提供することができるようになる。
　また、上記一態様において、前記評価部は、評価項目毎の評価結果を点数化し、医師については合計点数を評価値とし、病院についてはその病院に属する医師の評価値の平均値を評価値とし、前記提示部は、前記評価部が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、前記抽出した前記予約候補をその評価値と共に前記要求元の前記ユーザ端末に提示させることができる。　
　当該構成によれば、点数化した評価値を用い、予約候補をその数値と共に提示することで、ユーザが予約する病院を選定する際の指標を提供することができ、ユーザの選定を容易にすることが可能となる。
　また、上記一態様において、病院予約システムは、前記各病院に所属する各医師について、少なくとも性別及び年齢を含む公開可能な医師属性情報を取得する医師属性取得部を更に具備し、前記受付部は、更に、前記要求元の前記ユーザ端末の前記ユーザの属性情報を受け付け、前記評価部によって評価する評価項目は、更に、前記医師属性取得部により取得される前記医師の属性情報と、前記受付部によって受け付けた前記要求元の前記ユーザ端末の前記ユーザの属性情報との関係を含むことができる。　
　当該構成によれば、評価値を提示するべきユーザの性別又は年齢と医師の性別又は年齢とにも基づいて評価するので、ユーザに適した医師を高く評価することができ、ユーザにより適した医師を候補とすることができるようになる。
　また、上記一態様において、前記受付部は、更に、前記要求元の前記ユーザ端末から位置情報を受け付け、前記限定部は、前記受付部によって受け付けた前記要求元の前記ユーザ端末からの前記位置情報に基づいて、前記評価対象となる前記複数の病院又は医師を限定し、前記評価部によって評価する評価項目は、更に、前記受付部によって受け付けた前記要求元の前記ユーザ端末からの前記位置情報と、前記評価対象の前記病院の位置との関係を含むことができる。　
　当該構成によれば、評価要求元のユーザの現在位置やユーザが指定した指定位置に応じて、ユーザが通い得る病院を限定することで、ユーザに不適切な病院を候補として提示する可能性を小さくすることができる。
　また、上記一態様において、前記病院制御部は、更に、前記病院の時事の滞在中患者の時間管理を行い、前記評価部は、前記病院制御部にアクセスして、各病院の、現時点における少なくとも診療待ち患者人数と、今後の予約患者数とを取得し、前記評価部によって評価する評価項目は、更に、前記取得した診療待ち患者人数及び予約患者数を含むことができる。　
　当該構成によれば、各病院の現時点での待ち時間を考慮して病院または医師の候補を提示することが可能になる。
　本開示の別の態様では、サーバ装置は、複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークから、前記電子カルテの記載内容を収集する電子カルテ収集部と、通信ネットワークを介して、複数のユーザそれぞれの生体データを収集する生体データ収集部と、前記通信ネットワークを介して、ユーザ端末から要求を受け付ける受付部と、前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部と、前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部と、前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部と、前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部の内、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部と、を具備する。　
　当該構成によれば、任意のユーザ端末からの評価要求に応じて、サーバ装置において、そのユーザ端末のユーザの生体データと収集した複数のユーザの生体データとに基づいて限定した病院又は医師を時間という客観的な指標によって評価し、その評価結果に基づいた予約候補を評価要求元のユーザ端末に送信してユーザに提示し、また、そのユーザ端末のユーザの選定に従って、病院の予約を行うので、客観的な指標に基づいてユーザに適する病院または医師の候補を提示して、ユーザが容易に病院を選定できるようになり、また、その選定に応じて病院を簡便に予約することができるようになる。
　本発明によれば、客観的な指標に基づいてユーザに適する病院または医師の候補を提示でき、ユーザの選定に応じて病院を予約することができる技術を提供することができる。
図１は、実施形態に係る病院予約システムの構成の一例を模式的に例示するブロック図である。 図２は、第１実施形態に係る病院予約システムの全体構成の一例を示すブロック図である。 図３は、病院データベースの記憶内容の一例を示す図である。 図４は、ユーザデータベースの記憶内容の一例を示す図である。 図５は、対応関係データベースの記憶内容の一例を示す図である。 図６は、収集データベースの記憶内容の一例を示す図である。 図７は、評価データベースの記憶内容の一例を示す図である。 図８は、サービスサーバの処理手順の一例を例示するフローチャートである。 図９は、ユーザ端末の処理手順の一例を例示するフローチャートである。 図１０は、図９中の評価処理の一例を例示するフローチャートである。 図１１は、図８中の電子カルテ収集処理の一例を例示するフローチャートである。 図１２は、図８中の評価算出処理の一例を例示するフローチャートである。 図１３は、生体データの履歴の一例を説明するための図である。 図１４は、生体データの履歴の別の例を説明するための図である。 図１５は、第２実施形態に係る病院予約システムにおけるサービスサーバの処理手順の一例を例示するフローチャートである。 図１６は、図１５中の電子カルテ収集処理の一例を例示するフローチャートである。 図１７は、図１５中の人数収集処理の一例を例示するフローチャートである。 図１８は、第３実施形態に係る病院予約システムにおけるサービスサーバの処理手順の一例を例示するフローチャートである。 図１９は、図１８中の第１評価算出処理の一例を例示するフローチャートである。 図２０は、図１８中の第２評価算出処理の一例を例示するフローチャートである。
　以下、本発明の実施形態を、図面に基づいて説明する。
　［適用例］
　まず、図１を参照して、本発明が適用される場面の一例について説明する。図１は、実施形態に係る病院予約システムの構成の一例を模式的に例示する。
　［適用例の構成］
　図１の例では、病院予約システムは、インターネットなどの通信ネットワークＮＥＴにそれぞれ接続された、電子カルテネットワーク（ＥＨＲ：Electronic Health Records）１とサービスサーバ１０とを含む。サービスサーバ１０は、通信ネットワークＮＥＴを介して、複数のユーザ端末２０と接続され得る。
　電子カルテネットワーク１は、複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテ（ＥＭＲ：Electronic Medical Records）を、複数の病院の間で共有するためのネットワークである。電子カルテネットワーク１は、例えば、複数の病院それぞれに設けられた病院サーバ３０と、データセンタに設けられたデータサーバ４０とが、通信ネットワークＮＥＴを介して接続されて構成される。なお、電子カルテネットワーク１は、通信ネットワークＮＥＴとして、インターネットではなくて、専用の通信回線を使用するものであっても構わない。但し、データサーバ４０は、サービスサーバ１０が通信ネットワークＮＥＴを介して当該データサーバ４０にアクセスできるようにする構成を持つ必要がある。
　各病院の病院サーバ３０は、例えば、制御部３１と、この制御部３１に接続された記憶部３２と、図示しない通信インタフェースを有することができる。また、病院サーバ３０には、例えば、病院内の医師、看護師、検査技師、事務員などの医療従事者が操作するパーソナルコンピュータ（ＰＣ）、来院した患者が操作する自動受付機や自動会計機、などの各種の医療端末３３が、病院内ＬＡＮ（Local Area Network）などを介して接続されている。病院内ＬＡＮは、有線ＬＡＮであっても良いし、無線ＬＡＮであっても良く、また、有線と無線とが混在したＬＡＮであっても良い。なお、特に図示はしていないが、病院サーバ３０には、患者の血圧値などの生体データを計測する生体データ計測装置、患者の内部画像を撮影するＣＴ（Computerized Tomography）装置などの内部画像撮影装置、などを含む各種の検査機器も病院内ＬＡＮなどを介して接続可能となっている。
　病院は、ある建物の一室と言った小規模の病院から、一つの敷地内に複数の病棟が配置された大規模病院、更には、複数地域に分散した系列病院を含む病院グループであって良い。病院グループの場合、グループ内の病院毎に病院サーバ３０が配されても良いし、一つの病院サーバ３０が一つの主管病院に配置され、各系列病院の医療端末３３が専用通信回線などを介して病院サーバ３０に接続されていても良い。或いは、グループ内の病院毎に病院サーバ３０の制御部３１のみが設けられ、記憶部３２は、一つの主管病院の病院サーバ３０にのみ配置されても良い。
　病院サーバ３０における制御部３１は、図示はしないが、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などのプロセッサと、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）などのメモリと、を含むことができる。ＲＯＭは、例えば、プロセッサが実行するプログラムを記憶する。ＲＡＭは、例えば、プロセッサがワークメモリとして使用するメモリである。プロセッサが必要なプログラムを実行することによって、制御部３１は、様々な動作を行うことができる。
　記憶部３２は、例えば、制御部３１のプロセッサにより実行されるプログラム、プログラムを実行するために必要な設定データ、及び各種データベースを記憶することができる。制御部３１のプロセッサにより実行されるプログラムは、例えば、電子カルテの閲覧や更新を行う電子カルテ管理プログラム、患者の予約を管理する予約管理プログラム、病院に滞在中の各患者についての受付時間などを管理する時間管理プログラム、などを含むことができる。プログラムを実行するために必要な設定データは、例えば、データセンタのデータサーバ４０のアクセスアドレス、などを含むことができる。データベースは、例えば、医療端末３３を操作する医療従事者の権限やパスワードなどを含む各医療従事者情報を記憶する医療従事者データベース、各患者の電子カルテ（ＥＭＲ）を記憶する電子カルテデータベース、予約状況を記憶する予約データベース、などを含むことができる。なお、各病院の記憶部３２は、上記したようなプログラム、設定データ、及びデータベースの全てを記憶することは必須ではなく、また、上記した以外のプログラム、設定データ、及びデータベースを記憶していても良い。記憶部３２が備える記憶媒体は、コンピュータや機械などが記録されたプログラムなどの情報を読み取り可能なように、当該プログラムなどの情報を、電気的、磁気的、光学的、機械的又は化学的作用によって蓄積する媒体であれば、どのようなものであっても良い。例えば、記憶部３２が備える記憶媒体は、ＥＥＰＲＯＭ（登録商標）（Electrically Erasable, Programmable Read-Only Memory）などを使用することができる。なお、この記憶部３２についても、制御部３１のプロセッサがワークメモリとして使用するようにしても良い。
　制御部３１のプロセッサは、例えば、記憶部３２に記憶された電子カルテ管理プログラムを実行することで、各医療端末３３の操作に応じて、記憶部３２に記憶している電子カルテの記載内容を医療端末３３に表示させたり、電子カルテの記載内容を更新したりすることができる。また、制御部３１のプロセッサは、例えば、図示しない検査機器からの検査データを、電子カルテに追記することも可能である。さらに、制御部３１のプロセッサは、例えば、図示しない通信インタフェースにより、通信ネットワークＮＥＴ又は専用の通信回線を介してデータサーバ４０と通信することができる。通信インタフェースによる通信は、特定の通信方式に限定されるものではない。但し、データサーバ４０との通信においては、データ暗号化などにより、秘匿性を担保することが必要である。制御部３１のプロセッサは、例えば、記憶部３２に記憶している電子カルテを、データセンタのデータサーバ４０に送信することができる。この場合、制御部３１のプロセッサは、電子カルテを、電子カルテネットワーク１の共通のデータフォーマットに変換し、例えば暗号化した上で、送信することができる。逆に、制御部３１のプロセッサは、他の病院で作成されてデータサーバ４０に共通フォーマットで蓄積されている電子カルテを、データサーバ４０から受信して、それを例えば復号化し、当該病院の電子カルテのフォーマットに変化した上で、記憶部３２の電子カルテデータベースに登録することができる。
　また、制御部３１のプロセッサは、例えば、記憶部３２に記憶された予約管理プログラムを実行することで、医療端末３３からの予約、或いは通信ネットワークＮＥＴを介したサービスサーバ１０又はユーザ端末２０からの予約を受け付けて、予約データベースを時事更新することができる。
　更に、制御部３１のプロセッサは、例えば、記憶部３２に記憶された時間管理プログラムを実行することで、各患者の受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を取得して、その病院の時事の滞在中患者それぞれの時間管理を行うこともできる。なお、制御部３１のプロセッサは、例えば、上記電子カルテ管理プログラムを実行することで、この取得した各患者の受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報を各患者の電子カルテに記載することができる。
　データセンタのデータサーバ４０は、例えば、制御部４１と、この制御部４１に接続された記憶部４２と、図示しない通信インタフェースを有することができる。制御部４１は、図示はしないが、例えば、ＣＰＵやＭＰＵなどのプロセッサと、ＲＡＭやＲＯＭなどのメモリと、を含むことができる。ＲＯＭは、例えば、プロセッサが実行するプログラムを記憶する。ＲＡＭは、例えば、プロセッサがワークメモリとして使用するメモリである。プロセッサが必要なプログラムを実行することによって、制御部４１は、様々な動作を行うことができる。
　記憶部４２は、例えば、制御部４１のプロセッサにより実行されるプログラム、プログラムを実行するために必要な設定データ、及び各種データベースを記憶することができる。制御部４１のプロセッサにより実行されるプログラムは、例えば、各病院サーバ３０から通信ネットワークＮＥＴ又は専用の通信回線を介して送信されてきた電子カルテを処理する電子カルテ処理プログラム、サービスサーバ１０やユーザ端末２０と送信するための通信プログラム、などを含むことができる。データベースは、例えば、医療端末３３を操作する医療従事者やユーザ端末２０を操作するユーザの権限やパスワード、サービスサーバ１０の権限などを記憶するアクセス権限データベース、病院サーバ３０から受信した各患者の電子カルテ（ＥＭＲ）を記憶する電子カルテデータベース、などを含むことができる。なお、記憶部４２は、上記した以外のプログラムやデータベースを記憶していても良い。記憶部４２が備える記憶媒体は、コンピュータや機械などが記録されたプログラムなどの情報を読み取り可能なように、当該プログラムなどの情報を、電気的、磁気的、光学的、機械的又は化学的作用によって蓄積する媒体であれば、どのようなものであっても良い。例えば、記憶部４２が備える記憶媒体は、ＥＥＰＲＯＭなどを使用することができる。なお、この記憶部４２についても、制御部４１のプロセッサがワークメモリとして使用するようにしても良い。
　制御部４１のプロセッサは、例えば、記憶部４２に記憶された電子カルテ処理プログラムを実行することで、通信ネットワークＮＥＴ又は専用の通信回線を介して、各病院サーバ３０と通信し、それぞれの病院サーバ３０から送信されてきた例えば暗号化された電子カルテを例えば復号化して、記憶部４２の電子カルテデータベースに登録することができる。逆に、制御部４１のプロセッサは、各病院の病院サーバ３０からの要求に応じて、記憶部４２の電子カルテデータベースに共通フォーマットで蓄積されている電子カルテを、例えば暗号化して、要求元の病院サーバ３０に送信することができる。
　また、図１の例では、病院Ｃは、病院サーバ３０の記憶部３２が電子カルテデータベースを備えていない。このような構成の病院サーバ３０では、データサーバ４０の記憶部４２に記憶された電子カルテが、仮想的に、その病院Ｃの病院サーバ３０が備える電子カルテとして使用されることができる。そのため、制御部４１のプロセッサは、例えば、記憶部４２に記憶された電子カルテ処理プログラムを実行することで、通信ネットワークＮＥＴ又は専用の通信回線とその病院Ｃの病院サーバ３０とを介して、医療端末３３からの操作情報を取得して、電子カルテに対する処理が行えるようになっている。また、制御部４１のプロセッサは、例えば、記憶部４２に記憶された通信プログラムを実行することで、通信ネットワークＮＥＴを介して、サービスサーバ１０或いはユーザ端末２０と通信することができる。
　なお、上記のように、病院サーバ３０の制御部３１が電子カルテネットワーク１の共通のデータフォーマットに、記憶部３２に記憶している独自のデータフォーマットの電子カルテを変換してから送信することは必須ではない。各病院の病院サーバ３０からは独自のデータフォーマットの電子カルテを、例えば暗号化した上で、データセンタに送信しても良い。この場合には、それを受信したデータサーバ４０の制御部４１において、受信した電子カルテを例えば復号化し、データフォーマットを電子カルテネットワーク１の共通のデータフォーマットに変換して、記憶部４２の電子カルテデータベースに記憶すれば良い。また、逆に、各病院の病院サーバ３０へ電子カルテを送信する際には、データサーバ４０の制御部４１において、共通データフォーマットの電子カルテを各病院独自のデータフォーマットに変換してから、例えば暗号化して、送信するようにすれば良い。
　電子カルテネットワーク１内では、医療従事者毎に制限されたアクセス権限が与えられて、各医療従事者は、医療端末３３から、アクセスが許可された自病院の病院サーバ３０の記憶部３２又はデータセンタのデータサーバ４０の記憶部４２に記憶された電子カルテの情報を閲覧できる。また、権限が与えられていれば、各医療従事者は、医療端末３３から、電子カルテの更新も可能である。
　ユーザ端末２０は、通信ネットワークＮＥＴへの接続機能を備えた一般的なスマートホン（スマホ）やタブレット型端末のようなスマートデバイスであって良い。ユーザ端末２０は、例えば、制御部２１と、この制御部２１に接続された測定部２２及び記憶部２３と、図示しない通信ネットワークＮＥＴに接続するための通信インタフェースと、ユーザインタフェースと、を有することができる。また、ユーザ端末２０は、生体データ計測装置２４と接続されることができる。通信インタフェースは、例えば、Ｗｉ－Ｆｉ（登録商標）モジュールを含むことができる。通信インタフェースは、例えば、図示しないＷｉ－Ｆｉ基地局を経由して、インターネットなどの通信ネットワークＮＥＴに接続され、通信ネットワークＮＥＴを介して、サービスサーバ１０及び電子カルテネットワーク１のデータサーバ４０と通信することができる。ユーザインタフェースは、液晶ディスプレイとその表示画面上に配置されたタッチパネル、及びスマートデバイスの筐体に設けられた操作ボタンを含む。
　ユーザ端末２０における制御部２１は、図示はしないが、例えば、ＣＰＵやＭＰＵなどのプロセッサと、ＲＡＭやＲＯＭなどのメモリと、を含むことができる。ＲＯＭは、例えば、プロセッサが実行するプログラムを記憶する。ＲＡＭは、例えば、プロセッサがワークメモリとして使用するメモリである。
　測定部２２は、ユーザの各種生体データを測定する。例えば、測定部２２は、一般にスマートデバイスが備えるカメラとＬＥＤフラッシュライトを光電脈波計（ＰＰＧ（Photo Plethysmography）センサ）として利用して、脈拍数を測定することができる。また、圧力センサを加えることで、血圧測定を行い得るスマートデバイスも知られている。
　生体データ計測装置２４は、心電や脈拍、血圧、体重、体脂肪率、など様々な生体データを、一つ又は複数計測可能な機器である。この生体データ計測装置２４は、例えば、ユーザ端末２０の制御部２１との間で近距離無線通信する。例えば、ユーザ端末２０及び生体データ計測装置２４は、それぞれ、Bluetooth（登録商標）などの近距離無線データ通信規格を採用したＢＬＥ通信モジュールを有することができるが、これに限定されない。また、生体データ計測装置２４とユーザ端末２０の制御部２１は、有線接続されても良い。
　記憶部２３は、Ｗｅｂブラウザや各種のアプリケーションプログラム（スマホアプリ）を記憶する。プロセッサが、ＲＯＭ又は記憶部２３に記憶されたプログラムを実行することによって、制御部２１は、様々な動作を行うことができる。例えば、制御部２１は、スマホアプリやＷｅｂブラウザなどにより、サービスサーバ１０にアクセスすることができる。また、電子カルテネットワーク１内では、患者であるユーザ毎に制限されたアクセス権限が与えられて、各ユーザは、ユーザ端末２０からデータサーバ４０にアクセスして、記憶部４２に記憶されている自身の許可された電子カルテの情報を閲覧できるようになっている場合もある。ユーザ端末２０は、ＧＰＳ（Global Positioning System）受信機を有しても良い。ユーザ端末２０は、ＧＰＳ受信機またはＷｉ－Ｆｉモジュールによって取得した当該ユーザ端末の位置情報を、スマホアプリで利用することができ、必要に応じて通信ネットワークＮＥＴを介してサービスサーバ１０などに送信可能となっている。
　また、記憶部２３は、測定部２２及び生体データ計測装置２４によって取得したユーザの生体データを、ＰＨＲ（Personal Health Records）として蓄積することができる。すなわち、当該ユーザ端末２０のユーザは、記憶部２３に、自身が自ら管理する医療・健康記録を一定期間以上に渉って保存しておくことができる。
　サーバ装置として動作するサービスサーバ１０は、特に図示はしないが、例えば、制御部と、この制御部に接続された記憶部と、通信ネットワークＮＥＴに接続するための通信インタフェースと、を有することができる。通信インタフェースは、通信ネットワークＮＥＴを介して、ユーザ端末２０及び電子カルテネットワーク１のデータサーバ４０や病院サーバ３０と通信することができる。通信インタフェースによる通信は、特定の通信方式に限定されるものではない。制御部は、例えば、ＣＰＵやＭＰＵなどのプロセッサと、ＲＡＭやＲＯＭなどのメモリと、を含むことができる。ＲＯＭは、例えば、プロセッサが実行するプログラムを記憶する。ＲＡＭは、例えば、プロセッサがワークメモリとして使用するメモリである。プロセッサが必要なプログラムを実行することによって、制御部は、電子カルテ収集部１１、生体データ収集部１２、受付部１３、限定部１４、評価部１５、提示部１６、予約部１７、対応関係データベース１８、及び医師属性取得部１９の動作を行うことができる。
　電子カルテ収集部１１は、例えば、通信ネットワークＮＥＴを介して電子カルテネットワーク１におけるデータセンタのデータサーバ４０にアクセスして、記憶部４２に記憶された各病院の電子カルテの記載内容を収集することができる。例えば、電子カルテ収集部１１は、データサーバ４０の制御部４１に電子カルテの記載内容の送信を依頼し、データサーバ４０から送信されてくる電子カルテを受信することで、電子カルテの記載内容を収集する。
　生体データ収集部１２は、例えば、通信ネットワークＮＥＴを介して各ユーザ端末２０の記憶部２３に蓄積された生体データを収集することができる。例えば、ユーザ端末２０において測定部２２又は生体データ計測装置２４によって生体データが取得される毎に、ユーザ端末２０からその取得した生体データをサービスサーバ１０に送信することで、生体データ収集部１２は、各ユーザ端末２０の記憶部２３に記憶された生体データを収集することができる。あるいは、生体データ収集部１２は、各ユーザ端末２０の制御部２１に記憶部２３に記憶されている少なくとも一定期間の生体データの送信を依頼し、各ユーザ端末２０から送信されてくる少なくとも一定期間の生体データを受信することで、生体データを収集することも可能である。
　受付部１３は、例えば、通信ネットワークＮＥＴを介してユーザ端末２０から要求を受け付ける。この受付部１３が受け付ける要求は、病院候補の提示を要求する評価要求や病院への予約を要求する病院予約要求を含むことができる。なお、ユーザ端末２０の制御部２１は、評価要求をサービスサーバ１０に送信する際、位置情報など、サービスサーバ１０での評価動作に必要な情報を併せて送信することができる。このとき、記憶部２３にＰＨＲとして蓄積している生体データの内の最新のものも併せて送信するようにしても良い。ただし、これは、ユーザ端末２０において生体データが取得される毎に、ユーザ端末２０からサービスサーバ１０に送信されているので、必ずしも必要というわけではない。また、病院予約要求には、予約を依頼する病院又は医師を示す情報が含まれる。
　限定部１４は、例えば、受付部１３によって通信ネットワークＮＥＴを介してユーザ端末２０から評価要求とユーザ端末２０のユーザの生体データとが受け付けられたとき、評価を行うべき評価対象を限定する。例えば、限定部１４は、評価要求の要求元のユーザ端末２０のユーザの生体データと、生体データ収集部１２によって収集した複数のユーザから収集した生体データとに基づいて、複数の病院又は複数の病院に所属する複数の医師の中から、評価を行うべき評価対象を限定することができる。
　評価部１５は、例えば、限定部１４によって評価対象として限定された複数の病院又は医師を、電子カルテ収集部１１によって収集した電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって評価する。例えば、診療時間は、患者の診療開始から診療終了までの時間であり、待ち時間は、患者の受付から診療開始までの時間と、診療終了から会計終了までの時間との合計である。
　提示部１６は、例えば、評価部１５による評価結果に基づいて、評価された複数の病院又は医師の中から少なくとも一つを予約候補として、通信ネットワークＮＥＴを介して評価要求元のユーザ端末２０へ送信することで、当該ユーザ端末２０に予約候補を提示させることができる。
　予約部１７は、例えば、受付部１３によって通信ネットワークＮＥＴを介して評価要求元のユーザ端末２０から、提示された予約候補の中からユーザによって選択された病院又は医師に対する病院予約要求が受け付けられたとき、当該ユーザの予約を該当する病院へ依頼する。例えば、予約部１７は、病院予約要求で示される病院又は医師に該当する病院の病院サーバ３０の、患者の予約管理を行う病院制御部として動作する制御部３１に、通信ネットワークＮＥＴを介して病院予約要求元の、すなわち評価要求元のユーザ端末２０のユーザの予約を依頼することができる。
　対応関係データベース１８は、例えば、生体データ収集部１２によって収集した生体データの属性に応じて病院又は医師をデータベース化したものである。限定部１４は、評価要求元のユーザ端末２０のユーザの生体データの属性により、この対応関係データベース１８を参照して、評価対象となる複数の病院又は医師を限定することができる。
　医師属性取得部１９は、例えば、各病院に所属する各医師について、少なくとも性別及び年齢を含む公開可能な医師属性情報を取得することができる。データサーバ４０は、特に図示はしていないが、各病院に所属する医師の医師属性情報を登録したデータベースを有しており、このデータベースが、例えば、各病院の病院サーバ３０の制御部３１により、所属する医師の変更がある度に更新されるようになっている。よって、医師属性取得部１９は、例えば、通信ネットワークＮＥＴを介して、データサーバ４０の制御部４１から医師属性情報を取得することができる。また、多くの病院は、病院サーバ３０によって或いは他のＷｅｂサーバによって、病院紹介のためのＷｅｂページなどを提供しており、そこに所属医師の公開可能な医師属性情報を公開している。よって、医師属性取得部１９は、例えば、通信ネットワークＮＥＴを介してＷｅｂページより、医師属性情報を取得することもできる。
　なお、受付部１３は、更に、通信ネットワークＮＥＴを介して評価要求元のユーザ端末２０のユーザの属性情報を受け付けることができ、評価部１５によって評価する評価項目は、更に、医師属性取得部１９により取得される医師の属性情報と、この受付部１３によって受け付けた評価要求元のユーザ端末２０のユーザの属性情報との関係を含むことができる。ユーザの属性情報は、ユーザ端末２０からの評価要求と共に送信されるようにしても良いし、サービスサーバ１０が提供するサービスへのユーザ加入時に受付部１３によって受け付けて、加入者であるユーザの情報を登録しておく図示しないユーザデータベースに登録しておくようにしても良い。
　［適用例の動作］
　次に、病院予約システムの動作の一例について説明する。
　各病院においては、患者は、まず、自動受付機や受付カウンタで受け付けを行う。すると、例えば、自動受付機や医療従事者が操作するＰＣなどの医療端末３３から、患者を特定するための患者ＩＤなどを含む患者情報が制御部３１に入力される。制御部３１は、例えば、この患者情報に基づいて、記憶部３２に記憶された電子カルテデータベースにおける該当患者の電子カルテに、受付日時を記載つまり記憶する。また、医師による患者の診療、診断、治療などの診療行為や、看護師や検査技師による患者の検査行為が行われると、例えば、医療従事者が操作する医療端末３３から、診療開始日時、診療終了日時、診療医師、診療内容、処方、検査結果、などの情報が制御部３１に入力される。制御部３１は、例えば、その入力された情報を、記憶部３２に記憶された電子カルテデータベースにおける該当患者の電子カルテに記載つまり記憶する。また、制御部３１は、例えば、記憶部３２に記憶した会計プログラムなどにより、記憶部３２に記憶した電子カルテの記載内容に基づいて、各患者の支払額を算出する。患者が自動会計機や会計カウンタでその支払額を支払うと、例えば、自動会計機や医療従事者が操作するＰＣなどの医療端末３３から、決済情報が制御部３１に入力される。制御部３１は、例えば、この決済情報を記憶部３２に記憶すると共に、記憶部３２に記憶された電子カルテデータベースにおける該当患者の電子カルテに、会計終了日時を記載つまり記憶する。なお、記憶部３２に電子カルテデータベースを記憶せずに、データセンタのデータサーバ４０に電子カルテを保存する形態を採る病院では、制御部３１は、例えば、電子カルテに記載するべき情報を、通信ネットワークＮＥＴ又は専用回線を介して、データサーバ４０に送信する。データサーバ４０の制御部４１は、例えば、この受信した情報に基づいて、記憶部４２に記憶している電子カルテデータベースの該当する患者の電子カルテの記載内容を更新する。
　また、制御部３１は、例えば、各患者の電子カルテの記載内容が更新される度、あるいは一定時間おきに、更新が有った電子カルテについて、その電子カルテ全体又は更新内容を通信ネットワークＮＥＴ又は専用回線を介して、データサーバ４０に送信する。データサーバ４０の制御部４１は、例えば、この受信した情報に基づいて、記憶部４２に記憶している電子カルテデータベースの該当する患者の電子カルテの記載内容を更新する。
　サービスサーバ１０の電子カルテ収集部１１は、例えば、一定時間おきに、図示しない通信インタフェースにより通信ネットワークＮＥＴを介して、電子カルテネットワーク１におけるデータセンタのデータサーバ４０の制御部４１に電子カルテ記載内容送信要求を送信することができる。そして、これに応じて、データサーバ４０から送信されてくる電子カルテの記載内容を受信し、図示しない記憶部に記憶する。データサーバ４０の記憶部４２に設けられる電子カルテデータベースにおける各電子カルテには、氏名や住所などの患者個人を特定する個人情報と、その患者に関する検査情報と、を含む患者情報が記載されている。更に、各電子カルテには、その患者の各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時、などを含む診療情報が記載されている。データサーバ４０に送信する電子カルテ記載内容送信要求は、収集するべき情報を特定する収集対象情報を含み、電子カルテ収集部１１は、この収集対象情報に、少なくとも、診療情報を含める。また、既に収集済みの電子カルテの記載内容の送受信は、通信資源の浪費であるので、電子カルテ記載内容送信要求は、情報を収集するべき期間を示す収集期間情報を含むことができる。電子カルテ収集部１１は、受信した電子カルテの記載内容により、図示しない記憶部の記憶内容を更新する。
　各ユーザ端末２０において測定部２２又は生体データ計測装置２４によってユーザの生体データが取得されると、制御部２１は、その取得した生体データを記憶部２３にＰＨＲとして記憶する。また、制御部２１は、その取得した生体データを、図示しない通信インタフェースにより通信ネットワークＮＥＴを介してサービスサーバ１０に送信することができる。
　サービスサーバ１０の生体データ収集部１２は、例えば、図示しない通信インタフェースにより、各ユーザ端末２０から通信ネットワークＮＥＴを介して送信されてきた生体データを受信し、図示しない記憶部に記憶している各ユーザ端末２０のユーザ毎の生体データの履歴に、その受信した生体データを追加記憶する。あるいは、生体データ収集部１２は、各ユーザ端末２０の制御部２１に記憶部２３に記憶されている少なくとも一定期間の生体データの送信を依頼し、各ユーザ端末２０から送信されてくる少なくとも一定期間の生体データを受信することで、生体データを収集する。
　いずれかのユーザ端末２０が、スマホアプリやＷｅｂブラウザなどにより、サービスサーバ１０にアクセスして、評価要求を送信すると、受付部１３は、図示しない通信インタフェースにより、この評価要求を受け付ける。受付部１３がこの評価要求を受け付けたとき、それに応答して、限定部１４は、評価要求と共に受け付けた評価要求元のユーザ端末２０のユーザの生体データと、図示しない記憶部に記憶している複数のユーザから収集した生体データとに基づいて、複数の病院又は複数の病院に所属する複数の医師の中から、評価を行うべき評価対象を限定する。例えば、限定部１４は、評価要求元のユーザ端末２０のユーザの生体データの属性により対応関係データベース１８を参照して、評価対象となる複数の病院又は医師を限定することができる。
　また、ユーザ端末２０からの評価要求には、ＧＰＳ受信機またはＷｉ－Ｆｉモジュールによって取得した当該ユーザ端末２０の現在位置や、図示しないユーザインタフェースを介して入力されたユーザ指定の指定位置などの位置情報を含めることができる。指定位置は、例えばユーザの自宅や勤務地などの住所情報を含むことができる。また、指定位置は、予めユーザ毎に登録し、サービスサーバ１０の図示しない記憶部に記憶しておくことも可能である。限定部１４は、この位置情報に基づいて、評価対象となる複数の病院又は医師を限定することができる。
　評価部１５は、電子カルテ収集部１１によって収集して図示しない記憶部に記憶した電子カルテの記載内容の内、このように限定部１４によって評価対象として限定された病院又は医師に対応する電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって評価することで、それら限定された複数の病院又は医師を評価し、その評価結果を図示しない記憶部に記憶する。なお、評価部１５によって評価する評価項目は、生体データ収集部１２によって収集して図示しない記憶部に記憶した生体データの一定期間の履歴に基づいた症状の改善度を含むことができる。更に、前記評価部１５によって評価する評価項目は、評価要求元のユーザ端末２０からの位置情報と評価対象として限定された病院の位置との関係を含んでも良い。
　なお、診療を行うために検査を実施した場合には、病院での滞在時間が長くなるため、病院又は医師の評価に際して、待ち時間をそのまま利用することは望ましくない。よって、電子カルテ収集部１１によって収集して図示しない記憶部に記憶した電子カルテの記載内容に検査実施の記録が存在する場合には、その診療回の時間情報を病院又は医師の評価に利用しない、或いは、時間に何らかの係数を乗じて利用するものとする。また、電子カルテ収集部１１での電子カルテの記載内容の収集の際に、検査実施の記録が存在する診療回の情報を収集しないようにしても良い。
　また、ユーザ端末２０からの評価要求には、当該ユーザ端末２０のユーザについての、少なくとも性別及び年齢を含むユーザ属性情報を含めることができる。或いは、ユーザ属性情報は、予めユーザ毎に登録し、サービスサーバ１０の図示しない記憶部に記憶しておくことも可能である。また、医師属性取得部１９は、各病院に所属する各医師について、少なくとも性別及び年齢を含む公開可能な医師属性情報を取得して、図示しない記憶部に記憶する。評価部１５によって評価する評価項目は、これら図示しない記憶部に記憶したユーザ属性情報と医師属性情報との関係を含むことも可能である。
　また、病院サーバ３０の制御部３１は、当該病院の時事の滞在中患者の時間管理を行っている。評価部１５は、図示しない通信インタフェースにより、通信ネットワークＮＥＴを介して限定された病院又は限定された医師が所属する病院の病院サーバ３０の制御部３１に、各病院の、現時点における少なくとも診療待ち患者人数と、今後の予約患者数とを問い合わせて取得することができる。評価部１５によって評価する評価項目は、この取得した診療待ち患者人数及び予約患者数を含むことができる。
　提示部１６は、例えば、評価部１５による評価結果に基づいて、評価された複数の病院又は医師の中から少なくとも一つを予約候補として、図示しない通信インタフェースにより、通信ネットワークＮＥＴを介して評価要求元のユーザ端末２０へ送信する。この予約候補を受信したユーザ端末２０のスマホアプリやＷｅｂブラウザなどでは、それをユーザに提示する。
　なお、評価部１５は、評価対象として限定された複数の病院又は医師の評価結果を表す評価値を算出し、提示部１６は、この評価値が高い方から複数の病院又は医師を予約候補として抽出して、抽出した予約候補をその評価値と共に評価要求元のユーザ端末２０に送信するようにしても良い。
　また、評価部１５は、評価項目毎の評価結果を点数化し、医師については合計点数を評価値とし、病院についてはその病院に属する医師の評価値の平均値を評価値とするようにしても良い。この場合、提示部１６は、評価部１５が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、抽出した予約候補をその評価値と共に評価要求元のユーザ端末２０に送信することができる。
　ユーザ端末２０に提示された予約候補を見た評価要求元のユーザ端末２０のユーザである患者が、スマホアプリやＷｅｂブラウザなどにおいて図示しないユーザインタフェースにより、所望の病院の予約操作を行うと、ユーザ端末２０の制御部２１は、病院予約要求を、図示しない通信インタフェースにより通信ネットワークＮＥＴを介してサービスサーバ１０に送信する。
　サービスサーバ１０の受付部１３が図示しない通信インタフェースによりこの病院予約要求を受け付けると、それに応答して、予約部１７は、病院予約要求に含まれるユーザによって選択された病院又は医師が所属する病院を特定し、その病院へ当該ユーザの予約を依頼する。例えば、予約部１７は、特定した病院の病院サーバ３０の制御部３１に、図示しない通信インタフェースにより通信ネットワークＮＥＴを介して、病院予約要求元の、すなわち評価要求元のユーザ端末２０のユーザの予約を依頼する。患者の予約管理を行う病院制御部として動作する病院サーバ３０の制御部３１は、この予約の可否を判別し、予約可能であれば、その患者の予約を登録する。そして、予約結果を通信ネットワークＮＥＴを介してサービスサーバ１０に返す。サービスサーバ１０の予約部１７は、図示しない通信インタフェースにより予約結果を受信して、予約要求元のユーザ端末２０に結果を返す。なお、予約部１７から病院サーバ３０に送信する予約要求に、予約要求元ユーザ端末２０のユーザの電子メールアドレスなどを含めることで、病院サーバ３０からユーザへ直接、予約結果を報知できるようにしても良い。
　［適用例の効果］
　以上のように、適用例に係る病院予約システムによれば、任意のユーザ端末２０からの評価要求に応じて、サービスサーバ１０の評価部１５が、そのユーザ端末２０のユーザの生体データと収集した複数のユーザの生体データとに基づいて限定した病院又は医師を時間という客観的な指標によって評価し、提示部１６が、その評価結果に基づいて予約候補をユーザに提示する。そして、評価要求元のユーザ端末２０のユーザの病院又は医師の選定に従って、予約部１７が病院の予約を行う。よって、客観的な指標に基づいてユーザに適する病院または医師の候補を提示して、ユーザが容易に病院を選定でき、また、その選定に応じて病院を簡便に予約することができるようになる。
　＜１＞　第１実施形態　
　以下に、第１実施形態について説明する。
　＜１－１＞構成
　図２を用いて、第１実施形態に係る病院予約システムの構成例について説明する。第１実施形態に係る病院予約システムは、上記適用例で説明したように、インターネットなどの通信ネットワークＮＥＴにそれぞれ接続された、電子カルテネットワーク１と、複数のユーザ端末２０と、サーバ装置として動作するサービスサーバ１００と、を含む。図２は、第１実施形態に係る病院予約システムの全体構成の一例を示すブロック図である。
　電子カルテネットワーク１は、上記適用例で説明したように、各病院の病院サーバ３０と、データセンタのデータサーバ４０とを含む。病院サーバ３０は、上記適用例で説明したように、制御部３１と、記憶部３２と、図示しない通信インタフェースと、を備え、医療端末３３と接続されている。データサーバ４０は、上記適用例で説明したように、制御部４１と、記憶部４２と、図示しない通信インタフェースと、を含む。
　ユーザ端末２０は、上記適用例で説明したように、制御部２１と、測定部２２と、記憶部２３と、図示しない通信インタフェースと、図示しないユーザインタフェースと、を備え、生体データ計測装置２４と接続可能である。
　サービスサーバ１００は、図２の例では、制御部１１０と、記憶部１２０と、通信インタフェース１３０と、を含む。なお、図２では、通信インタフェースを「通信Ｉ／Ｆ」と記載している。
　制御部１１０は、例えば、ＣＰＵ１１１、ＲＡＭ１１２、ＲＯＭ１１３などを含み、情報処理に応じてサービスサーバ１００の各構成要素の制御を行う。ＣＰＵ１１１の代わりに、ＭＰＵなどの他のプロセッサであっても良い。ＲＯＭ１１３は、例えば、ＣＰＵ１１１が実行するオペレーティングシステムや他のプログラム（例えば、病院予約プログラム）を記憶する。ＲＡＭ１１２は、例えば、ＣＰＵ１１１がワークメモリとして使用するメモリである。
　ＣＰＵ１１１が必要なプログラムを実行することによって、上記適用例で説明したような電子カルテ収集部１１、生体データ収集部１２、受付部１３、限定部１４、評価部１５、提示部１６、予約部１７、及び医師属性取得部１９の処理を実行して良い。当該プログラムは、例えば、ＲＯＭ１１３ではなく、記憶部１２０に記憶されていても良い。ＣＰＵ１１１が必要なプログラムを実行する際は、例えば、ＲＯＭ１１３及び／又は記憶部１２０に記憶された対象となるプログラムをＲＡＭ１１２に展開する。そして、ＣＰＵ１１１は、例えば、ＲＡＭ１１２に展開された当該プログラムを解釈及び実行して、各構成要素を制御する。
　記憶部１２０は、例えば、制御部１１０により実行されるプログラム（例えば、病院予約プログラム）、プログラムを実行するために必要な設定データ（例えば、データサーバ４０のアドレス情報）、各種のデータベース、などを記憶することができる。記憶部１２０が備える記憶媒体は、コンピュータや機械などが記録されたプログラムなどの情報を読み取り可能なように、当該プログラムなどの情報を、電気的、磁気的、光学的、機械的又は化学的作用によって蓄積する媒体であれば、どのようなものであっても良い。例えば、記憶部１２０が備える記憶媒体は、例えば、ＥＥＰＲＯＭなどを使用することができる。なお、この記憶部１２０についても、ＣＰＵ１１１がワークメモリとして使用するようにしても良い。記憶部１２０が記憶するデータベースは、病院データベース１２１、ユーザデータベース１２２、対応関係データベース１２３、収集データベース１２４、評価データベース１２５、などを含むことができる。なお、図２では、病院データベース、ユーザデータベース、対応関係データベース、収集データベース及び評価データベースを「病院ＤＢ」、「ユーザＤＢ」、「医療ＤＢ」、「収集ＤＢ」及び「評価ＤＢ」と記載している。
　通信インタフェース１３０は、制御部１１０の制御の下、通信ネットワークＮＥＴを介して、ユーザ端末２０、病院サーバ３０及びデータサーバ４０との間でデータ通信を行う。通信プロトコルは、通信ネットワークＮＥＴで規定されたプロトコルを使用する。具体的にはＴＣＰ／ＩＰ（Transmission Control Protocol／Internet protocol）やＵＤＰ／ＩＰ（User Datagram Protocol／Internet protocol）等が使用され得る。
　図３は、病院データベース１２１の記憶内容の一例を示す図である。図３に示す例では、病院データベース１２１は、病院ＩＤ、アクセス情報、病院情報、病院評判、診療科、医師ＩＤ、氏名、性別、年齢、滞在人数、予約状況、医師評判、などの項目名に対応する各病院の情報を記憶する。図３では、医師評判を「評判」と記載し、滞在人数を「待ち」と記載している。
　「病院ＩＤ」は、サービスサーバ１００が提供する病院予約サービスにおいて病院それぞれに一意に割り当てられる管理番号である。「アクセス情報」は、病院サーバ３０や病院のＷｅｂページにアクセスするためのアドレス情報である。「病院情報」は、病院の名称、住所、電話番号、営業時間、休日（営業日）、駐車場情報、などの病院それぞれに関する一般的な情報である。「病院評判」は、各ユーザ端末２０において任意に入力された、及び／または、インターネット上の各種の病院評価Ｗｅｂページなどから取得した、主観的な病院評価情報である。「診療科」は、内科や皮膚科といった、病院が有する診療科の情報である。
　「医師ＩＤ」は、病院に所属する各医師に一意に割り当てられる管理番号である。この医師ＩＤは、病院ＩＤと紐付くことで、各医師が区別可能であるが、医師が別の病院に移ることもあるので、サービスサーバ１００が提供する病院予約サービスにおいて一意に設定される。各病院で独自の医師ＩＤを使用している場合には、記憶部１２０に別途、医師データベースを用意し、病院独自の医師ＩＤを本病院予約サービス用の医師ＩＤに変換できるようにしておけば良い。「氏名」は、各医師の氏名である。「性別」は、各医師の性別である。「年齢」は、各医師の年齢である。「待ち」は、各医師についての現時点における診療待ち患者人数である。「予約状況」は、各医師についての今後の予約患者数である。この予約状況については、例えば、１日を午前と午後に分けるなど、任意の期間に分けて、それぞれの予約患者数が記憶される。「医師評判」は、各ユーザ端末２０において任意に入力された、及び／または、インターネット上の各種の病院評価Ｗｅｂページなどから取得した、主観的な医師評価情報である。
　図４は、ユーザデータベース１２２の記憶内容の一例を示す図である。図４に示す例では、ユーザデータベース１２２は、項目として、ユーザＩＤ、パスワード、氏名、ユーザ情報、病院毎ＩＤ、地点、優先条件、日付、通院フラグ、生体データ（例えば、血圧、脈拍、など）、症状パターンなどを有している。図４では、パスワードを「ＰＷ」と、通院フラグを「通院Ｆ」と、症状パターンを「症状Ｐ」と、それぞれ記載している。
　「ユーザＩＤ」は、サービスサーバ１００が提供する病院予約サービスへのユーザ加入時に一意に割り当てられるユーザの管理番号である。「パスワード」は、ユーザが認証のために任意に設定する値である。「氏名」は、ユーザの氏名である。「ユーザ情報」は、ユーザに関する情報であり、メールアドレス、電話番号、性別及び年齢を含む。「病院毎ＩＤ」は、当該ユーザの各病院での管理番号を示す情報であり、病院ＩＤと当該病院でのユーザ管理番号とを組み合わせたものである。この病院毎ＩＤにより、各ユーザと各病院の電子カルテとを紐付けることが可能となる。「地点」は、ユーザの位置情報であり、現在の位置、自宅住所、職場住所、登録位置を含むことができる。現在の位置は、例えばユーザ端末２０から送信されてくる現在位置が必要に応じて登録される。自宅住所、職場住所、登録位置は、ユーザが任意に指定する指定位置である。「優先条件」は、ユーザが優先条件として、予め決められた選択肢から選択した或いは任意に指定した情報である。
　「日付」は、ユーザ端末２０において生体データを取得した日付である。「通院フラグ」は、ユーザがいずれかの病院に通院したか否かを示すもので、通院した場合に「１」がセットされる。生体データ（「血圧」、「脈拍」、など）は、ユーザ端末２０において取得された生体データである。「症状パターン」は、生体データに含まれる各種の測定値又は計測値の関係を含む生体データの属性、つまり生体データのパターンに基づいて設定される症状を示している。「日付」、「通院フラグ」、生体データ（「血圧」、「脈拍」、など）、「症状パターン」は、各ユーザに対して割り当て得るデータ容量が決まっているので、予め決められた期間分が記憶され、それ以上の情報を追加する際には、最も古い情報が削除される。期間ではなく、予め決められた数であっても良い。いずれにしても、この期間又は数は、少なくとも後述する一定期間以上の生体データが保存されるように決められていれば良い。ユーザデータベース１２２は、その他に、ユーザが過去に診療を受けた医師ＩＤの記録などを記憶しても良い。
　図５は、対応関係データベース１２３の記憶内容の一例を示す図である。対応関係データベース１２３は、上記適用例で説明したような対応関係データベース１８に対応するものである。図５に示す例では、対応関係データベース１２３は、項目として、症状パターン、病院ＩＤ、及び医師ＩＤを有している。図５では、症状パターンを「症状Ｐ」と記載している。この対応関係データベース１２３は、症状パターンに対応する病院及び医師をデータベース化したものである。
　「症状パターン」は、ユーザデータベース１２２の症状パターンに対応している。「病院ＩＤ」は病院を特定するための管理番号である。「医師ＩＤ」は医師を特定するための管理番号である。これら病院ＩＤ及び医師ＩＤは、病院データベース１２１のそれらと対応している。
　図６は、収集データベース１２４の記憶内容の一例を示す図である。図６に示す例では、収集データベース１２４は、項目として、病院ＩＤ、患者ＩＤ、予約日時、受付、診療開始、医師ＩＤ、診療終了、会計終了、初診フラグ、症状、などを有している。図６では、初診フラグを「初診Ｆ」と記載している。
　「病院ＩＤ」は、病院を特定するための管理番号であり、この病院ＩＤにより、病院データベース１２１と収集データベース１２４の情報がリンク可能となる。「患者ＩＤ」は、各病院が独自に割り当てた患者の管理番号である。「予約日時」は、患者が予約した日時である。「受付」は、患者が来院して受付を行った時間である。例えば、各病院において、医療端末３３、例えば、受付事務員が操作するＰＣや患者が操作する自動受付機によって受付を行うことで、受付時間が当該患者に対応する電子カルテに記載される。「診療開始」は、患者に対する医師の診療が開始された時間である。「医師ＩＤ」は、診療を行う医師を特定する情報である。この医師ＩＤにより、病院データベース１２１と収集データベース１２４の情報がリンク可能となる。「診療終了」は、患者に対する医師の診療が終了した時間である。例えば、各病院において、医療端末３３、例えば、医師又は看護師が操作するＰＣによって診療開始時間、医師ＩＤ、診療終了時間を入力することで、それらの情報が当該患者に対応する電子カルテに記載される。「会計終了」は、患者が会計を済ませた時間である。例えば、各病院において、医療端末３３、例えば、会計事務員が操作するＰＣで支払い終了を入力することで、あるいは、患者が操作する自動会計機によって支払いを行うことで、会計終了時間が当該患者に対応する電子カルテに記載される。「初診フラグ」は、診療が初診であるか否かを示すもので、初診である場合に「１」がセットされる。「症状」は、患者の病名である。
　なお、この図６の例は、電子カルテの記載内容の収集の際に、検査実施の記録が存在する診療回の情報を収集しないようにした場合を示している。検査を実施した診療回の情報も収集する場合には、収集データベース１２４は、例えば、項目として、更に検査実施の有無を示すフラグを設ける。多くの場合、初診の際に検査も実施されるので、この検査実施の有無を示すフラグとしては、「初診フラグ」が兼用されても良い。
　図７は、評価データベース１２５の記憶内容の一例を示す図である。図７に示す例では、評価データベース１２５は、項目として、ユーザＩＤ、病院ＩＤ、病院スコア、診療科、診療科スコア、医師ＩＤ、総合スコア、時間スコア、症状別改善度スコア（例えば、高血圧改善度スコア、糖尿病改善度スコア、じんま疹改善度スコア、など）、などを有している。図７では、症状別改善度スコアの内の高血圧改善度スコアのみを示し、「高血圧」と記載している。
　「ユーザＩＤ」は、ユーザを特定するための管理番号であり、このユーザＩＤにより、ユーザデータベース１２２と評価データベース１２５の情報がリンク可能となる。「病院ＩＤ」は、病院を特定するための管理番号であり、この病院ＩＤにより、病院データベース１２１と収集データベース１２４と評価データベース１２５の情報がリンク可能となる。「病院スコア」は、病院の評価結果を数値化した評価値である。ここでは最高点を１００点とした数値で示しているが、この数値表現は一例である。例えば、星５つを最高点として星の数で示したり、偏差値で表したりするなど、どのようなものであっても構わない。この「病院スコア」は、当該病院が有する全診療科の評価値の平均値とすることができる。「診療科」は、病院が有する診療科の情報であり、この診療科により、病院データベース１２１と評価データベース１２５の情報がリンク可能となる。「診療科スコア」は、診療科毎の評価値である。この「診療科スコア」は、当該診療科に属する全医師の評価値、例えば後述する総合スコア、の平均値とすることができる。
　「医師ＩＤ」は、診療を行う医師を特定する情報である。この医師ＩＤにより、病院データベース１２１と収集データベース１２４と評価データベース１２５の情報がリンク可能となる。「総合スコア」は、医師毎の評価値である。この「総合スコア」は、当該医師についての時間評価値と、全改善度評価値の平均値や加重平均値との、加算値とすることができる。
　「時間スコア」は、医師毎の、一患者当たりの診療時間と待ち時間とから評価した時間評価値である。時間評価値は、例えば、一患者当たりの診療時間の平均値と一患者当たりの待ち時間との平均値とに基づいて評価する。例えば、一患者当たりの診療時間の平均値については、予め決めた時間範囲に応じて、その平均値が長い程高い評価値とする。例えば、一患者当たりの診療時間の平均値が１０分以上であれば満点である１０点とし、１分減る毎に１点減らす、などとすることができる。また、一患者当たりの待機時間の平均値については、例えば、予め決めた時間範囲に応じて、その平均値が短い程高い評価値とする。例えば、一患者当たりの待機時間の平均値が３０分以内であれば満点の５０点とし、時間が２分増える毎に１点減らす、などとすることができる。「時間スコア」は、こうして得られた一患者当たりの診療時間の平均値による点数と一患者当たりの待ち時間の平均値による点数との合計点数とすることができる。
　「症状別改善度スコア」は、各症状の改善度から評価した改善度評価値である。改善度評価値は、例えば、当該医師の診療を受けた患者の内、ユーザデータベース１２２に登録されていて生体データの一定期間の履歴を取得可能な患者について、その生体データの一定期間の履歴に基づいて症状がどれだけ改善したかにより、症状の改善度の評価値を求め、全ユーザの評価値の平均点とすることができる。例えば、症状が高血圧であれば、血圧値のデータから、一定期間、例えば一ヶ月間に、収縮期血圧が２０ｍｍＨｇ下がっていれば満点である１０点とし、低下量が１ｍｍＨｇ少なくなる毎に１点減らす、などとすることができる。
　なお、「総合スコア」は、「時間スコア」と全「症状別改善度スコア」から算出されることができるが、本実施形態では、後述するように、更に、病院予約を求めるユーザが指定する優先条件や、ユーザの属性情報などを評価項目に加えることで、算出した「時間スコア」を補正し得る。
　＜１－２＞動作
　次に、図８及び図９を用いて、第１実施形態に係る病院予約システムの動作例について説明する。
　図８は、サービスサーバの処理手順の一例を例示するフローチャートであり、図９は、ユーザ端末の処理手順の一例を例示するフローチャートである。
　＜１－２－１＞生体データ収集動作
　［ステップＳ１０１］
　サービスサーバ１００のＣＰＵ１１１は、先ず、生体データを収集するべきタイミングになったか否かを判断する。本実施形態では、例えば、１日１回など、予め決めたタイミングで生体データを収集する。生体データを収集するべきタイミングであると判断した場合（ステップＳ１０１、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１０２に進める。生体データを収集するべきタイミングではないと判断した場合（ステップＳ１０１、ＮＯ）、ＣＰＵ１１１は、処理をステップＳ１０３に進める。
　［ステップＳ１０２］
　上記ステップＳ１０１において生体データを収集するべきタイミングであると判断した場合（ステップＳ１０１、ＹＥＳ）、ＣＰＵ１１１は、生体データ収集処理を実行する。この生体データ収集処理においては、ＣＰＵ１１１は、通信インタフェース１３０により、ユーザデータベース１２２に登録されている各ユーザのユーザ端末２０に、当該ユーザ端末２０の記憶部２３に記憶されているＰＨＲの送信を依頼するＰＨＲ要求を送信し、これに応じて各ユーザ端末２０から送信されてきたＰＨＲを、ユーザデータベース１２２の対応するユーザの生体データ（「血圧」、「脈拍」、など）の項目に登録する。また、ＣＰＵ１１１は、ユーザデータベース１２２に登録した生体データの各項目の測定値又は計測値の関係を含む生体データの属性、つまり生体データのパターンに対応する症状を決定し、それをユーザデータベース１２２の症状パターンの項目に登録する。なお、この症状の決定は、どのような手法を用いても良い。例えば、予め生体データの多数のパターンに対し症状を選定して、データベース化しておき、このデータベース化されたパターンとユーザデータベース１２２に登録した生体データのパターンとのパターンマッチングにより、最も近似するパターンの症状を採用することができる。或いは、生体データの大量のパターンを機械学習しておくことで、ユーザデータベース１２２に登録した生体データのパターンに対応する症状を判定するようにしても良い。この生体データ収集処理終了後、ＣＰＵ１１１は、処理をステップＳ１０３に進める。
　［ステップＳ２０１］
　すなわち、ユーザ端末２０の制御部２１の図示しないプロセッサは、電子メールプログラムなどと同様にバックグラウンドで実行するアプリケーションプログラムの一つとして病院予約プログラムを実行しており、図示しない通信インタフェースによりサービスサーバ１００からＰＨＲ要求を受信したか否かを判断することができる。ＰＨＲ要求を受信していないと判断した場合（ステップＳ２０１、ＮＯ）、プロセッサは、処理をステップＳ２０２に進める。また、ＰＨＲ要求を受信したと判断した場合（ステップＳ２０１、ＹＥＳ）、プロセッサは、処理をステップＳ２０３に進める。
　［ステップＳ２０２］
　ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０１において、サービスサーバ１００からＰＨＲ要求を受信していないと判断した場合（ステップＳ２０１、ＮＯ）、図示しないユーザインタフェースを通じたユーザ操作が有ったか否かを判断する。何も操作が無いと判断した場合（ステップＳ２０２、ＮＯ）、プロセッサは、処理を上記ステップＳ２０１に戻す。また、何らかの操作が有ったと判断した場合（ステップＳ２０２、ＹＥＳ）、プロセッサは、処理をステップＳ２０４に進める。
　［ステップＳ２０３］
　ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０１において、サービスサーバ１００からＰＨＲ要求を受信したと判断した場合（ステップＳ２０１、ＹＥＳ）、ＰＨＲ送信処理を実行する。このＰＨＲ送信処理においては、プロセッサは、ＰＨＲ要求を受信したことをポップアップなどによりユーザ端末２０のユーザに報知する。これを確認したユーザが、送信を許可する操作を行ったならば、プロセッサは、図示しない通信インタフェースにより、記憶部２３に記憶しているＰＨＲをサービスサーバ１００に送信する。この場合、サービスサーバ１００からの要求に応えるため、ユーザ認証処理は行わなくても良い。また、送信を許可する操作が行われなかった場合には、ＰＨＲ要求を無視する、或いは、受信から所定時間待機後に拒否応答をサービスサーバ１００に返す。したがって、サービスサーバ１００の動作の上記ステップＳ１０２においては、生体データを収集できないユーザ端末が存在する。このＰＨＲ送信処理終了後、プロセッサは、処理を上記ステップＳ２０１に戻す。
　＜１－２－２＞登録情報更新動作
　［ステップＳ１０３］
　サービスサーバ１００のＣＰＵ１１１は、上記ステップＳ１０１において生体データを収集するべきタイミングではないと判断した場合（ステップＳ１０１、ＮＯ）、或いは、上記ステップＳ１０２の生体データ収集処理の終了後、病院データベース１２１の更新処理を実行する。例えば、ＣＰＵ１１１は、通信インタフェース１３０により、病院サーバ３０又はデータサーバ４０に更新の問合せを行って、或いは、病院サーバ３０又はデータサーバ４０から病院情報の更新要求を確認することで、更新が必要な病院について、病院データベース１２１を更新する。また、ＣＰＵ１１１は、新たな病院について、病院データベース１２１に追加することができる。この新規登録については、例えば、サービスサーバ１００の管理者が、サービスサーバ１００に直接又は通信ネットワークＮＥＴを介して接続された図示しない管理者端末を操作して実施できるようになっている。なお、このステップＳ１０３の更新処理では、病院データベース１２１の項目の内、病院ＩＤ、アクセス情報、病院情報、診療科、医師ＩＤ、性別、年齢を更新或いは新規登録するものであり、滞在人数や予約状況については更新しない。また、ＣＰＵ１１１は、任意のＷｅｂページなどから、主観的な病院評価情報や医師評価情報を検索し、その結果を、病院データベース１２１の病院評判及び医師評判の項目に登録することができる。なお、このステップＳ１０３の更新処理では、特に変更するべき情報が無く、病院データベース１２１の内容を何ら更新しない場合もあり得る。
　［ステップＳ１０４］
　サービスサーバ１００のＣＰＵ１１１は、ユーザデータベース１２２の更新処理を実行する。例えば、ＣＰＵ１１１は、通信インタフェース１３０により、ユーザ端末２０、或いは図示しない管理者端末からの操作により、更新が必要なユーザについて、ユーザデータベース１２２を更新する。ユーザ端末２０からの操作に応じた更新を行うには、ユーザ認証が必要であり、このステップＳ１０４の更新処理は、ユーザ認証処理を含む。また、ＣＰＵ１１１は、新たなユーザについて、ユーザデータベース１２２に追加することができる。なお、このステップＳ１０４の更新処理では、ユーザデータベース１２２の項目の内、ユーザＩＤ、パスワード、氏名、ユーザ情報、病院毎ＩＤ、地点、優先条件を更新或いは新規登録するものであり、生体データなど更新しない情報もあり得る。なお、病院毎ＩＤについては、ユーザ端末２０からの操作による入力を受け付けても良いし、ユーザ情報や地点（自宅住所）などをキーにして、当該ユーザの管理番号を各病院サーバ３０に問い合わせることで収集しても良い。なお、このステップＳ１０４の更新処理では、特に変更するべき情報が無く、ユーザデータベース１２２の内容を何ら更新しない場合もあり得る。
　［ステップＳ１０５］
　サービスサーバ１００のＣＰＵ１１１は、通信インタフェース１３０により、通信ネットワークＮＥＴを介して何れかのユーザ端末２０からＰＨＲを受信したか否かを判断する。ＰＨＲを受信していないと判断した場合（ステップＳ１０５、ＮＯ）、ＣＰＵ１１１は、処理をステップＳ１０６に進める。ＰＨＲを受信したと判断した場合（ステップＳ１０５、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１０７に進める。
　［ステップＳ１０６］
　サービスサーバ１００のＣＰＵ１１１は、上記ステップＳ１０５において何れかのユーザ端末２０からＰＨＲを受信していないと判断した場合（ステップＳ１０５、ＮＯ）、通信インタフェース１３０により、通信ネットワークＮＥＴを介して何れかのユーザ端末２０から評価要求を受信したか否かを判断する。なお、この判断は、ユーザ認証処理を含む。評価要求を受信していないと判断した場合（ステップＳ１０６、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１０１に戻す。ユーザ認証がなされて評価要求を受信したと判断した場合（ステップＳ１０６、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１０８に進める。
　［ステップＳ２０４］
　ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０２において何らかの操作が有ったと判断した場合（ステップＳ２０２、ＹＥＳ）、その操作は、測定部２２による生体データの取得指示であるか否かを判断する。この生体データの取得指示は、ユーザ端末２０が備える測定部２２による生体データの測定の指示を含むことができる。また、生体データの取得指示は、ユーザ端末２０と通信可能な生体データ計測装置２４で計測された生体データの取得の指示であっても良い。生体データの取得指示が有ったと判断した場合（ステップＳ２０４、ＹＥＳ）、プロセッサは、処理をステップＳ２０５に進める。行われた操作は生体データの取得指示ではないと判断した場合（ステップＳ２０４、ＮＯ）、プロセッサは、処理をステップＳ２０８に進める。
　［ステップＳ２０５］
　ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０４において生体データの取得指示が有ったと判断した場合（ステップＳ２０４、ＹＥＳ）、生体データ取得処理を実行する。この生体データ取得処理においては、ユーザ端末２０が備える測定部２２によって生体データを測定することで、生体データを取得する。或いは、ユーザ端末２０と通信可能な生体データ計測装置２４で生体データを計測し、その計測した生体データを通信により取得する。
　［ステップＳ２０６］
　ユーザ端末２０の制御部２１の図示しないプロセッサは、記憶部２３に蓄積しているＰＨＲに、この取得した生体データを追加記録する。
　［ステップＳ２０７］
　そして、ユーザ端末２０の制御部２１の図示しないプロセッサは、この記憶部２３に蓄積したＰＨＲを、図示しない通信インタフェースにより通信ネットワークＮＥＴを介してサービスサーバ１００に送信する。この場合、そのＰＨＲが誰の生体データであるのかを特定し得るように、ユーザＩＤを付して、ＰＨＲを送信する。また、必ずしも記憶部２３に記憶しているＰＨＲの全データを送信しなくても良い。例えば、最新の生体データのみを送信するようにしても良いし、最新から一定期間あるいは一定数の生体データを送信するのであっても良い。その後、プロセッサは、処理を上記ステップＳ２０１に戻す。
　［ステップＳ１０７］
　サービスサーバ１００のＣＰＵ１１１は、上記ステップＳ１０５において何れかのユーザ端末２０からＰＨＲを受信したと判断した場合（ステップＳ１０５、ＹＥＳ）、その受信したＰＨＲに基づいて、ユーザデータベース１２２の、対応するユーザの日付や生体データ（「血圧」、「脈拍」、など）、症状パターンの項目を更新する。この場合、受信したＰＨＲとユーザデータベース１２２に登録されている生体データとを比較して、差分のみを追加更新することができる。既に予め決められた期間分又は予め決められた数の生体データがユーザデータベース１２２の対応するユーザに対し記憶されている場合には、最も古い情報が削除されて追加される。また、受信したＰＨＲが、１日に当たり何回分もの生体データを含む場合には、最初の１回分の生体データのみを追加するようにしても良いし、最後の１回分の生体データのみを追加するようにしても良い。例えば、血圧は、起床後の測定データが特に有効な情報であるため、最初の１回分の生体データを用いることが望ましい。よって、複数回分の何れを採用するかは、生体データの種類により決めても良い。このユーザデータベース１２２の更新が終了したならば、ＣＰＵ１１１は、処理を上記ステップＳ１０６に進める。
　＜１－２－３＞電子カルテ収集及び評価動作
　［ステップＳ２０８］
　ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０４において行われた操作は生体データの取得指示ではないと判断した場合（ステップＳ２０４、ＮＯ）、行われた操作は医療評価の取得指示であるか否かを判断する。医療評価の取得指示が有ったと判断した場合（ステップＳ２０８、ＹＥＳ）、プロセッサは、処理をステップＳ２０９に進める。行われた操作は医療評価の取得指示ではないと判断した場合（ステップＳ２０８、ＮＯ）、プロセッサは、処理をステップＳ２１０に進める。
　［ステップＳ２０９］
　ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０８において医療評価の取得指示が有ったと判断した場合（ステップＳ２０８、ＹＥＳ）、評価処理を実行する。図１０は、この評価処理の一例を例示するフローチャートである。
　　［ステップＳ２０９１］
　ユーザ端末２０の図示しないプロセッサは、図示しないユーザインタフェースを通じたユーザ操作による、評価条件の入力を受け付ける。評価条件は、優先条件を含むことができる。また、評価条件は、評価結果を提示する対象が病院であるのか、医師であるのかを示す評価対象条件を含むことができる。なお、病院が複数の診療科を有する場合が有るので、評価対象条件は、病院の代わりに診療科であっても良い。
　　［ステップＳ２０９２］
　そして、ユーザ端末２０のプロセッサは、その入力された評価条件を付けて、評価要求を、通信ネットワークＮＥＴを介してサービスサーバ１００に送信する。この際、評価要求には、ユーザ認証のためのユーザＩＤ及びパスワードと、ユーザ端末２０の現在位置を示す位置情報とが含まれることができる。また、記憶部２３にＰＨＲとして蓄積している生体データの内の最新のものも併せて送信するようにしても良い。
　　［ステップＳ２０９３］
　その後、ユーザ端末２０のプロセッサは、通信ネットワークＮＥＴを介してサービスサーバ１００からの予約候補を受信するのを待つ。すなわち、プロセッサは、予約候補を受信したか否かを判断し、受信していない場合（ステップＳ２０９３、ＮＯ）、このステップＳ２０９３の処理を繰り返す。
　［ステップＳ１０８］
　サービスサーバ１００のＣＰＵ１１１は、上記ステップＳ１０６において評価要求を受信したと判断した場合（ステップＳ１０６、ＹＥＳ）、受信した評価要求に含まれるユーザＩＤ及びパスワードによりユーザ認証を行った上で、同じく評価要求に含まれる位置情報と、評価要求と共に送られる評価条件に含まれる優先条件とにより、ユーザデータベース１２２を更新する。すなわち、ＣＰＵ１１１は、ユーザデータベース１２２の、該当するユーザに関する地点における現在位置と優先条件とを、受信した情報に更新する。また、ＣＰＵ１１１は、受信した評価条件に含まれる評価対象条件を、ＲＡＭ１１２または記憶部１２０に記憶する。なお、最新の生体データも送信されてきた場合には、ユーザデータベース１２２に登録されている生体データと比較し、必要であれば追加登録する。
　［ステップＳ１０９］
　ここで、ＣＰＵ１１１は、評価対象とする病院又は医師を限定する。例えば、ＣＰＵ１１１は、まず、ユーザデータベース１２２の該当するユーザの最新の生体データに対応する症状パターンの項目から症状を読み出し、読み出した症状を検索キーにして対応関係データベース１２３を検索し、病院又は医師を限定する。そして更に、ＣＰＵ１１１は、この生体データの属性、つまり生体データのパターンによって限定した病院又は医師の中から評価対象とする病院又は医師を、ユーザデータベース１２２の該当するユーザの優先条件項目に記憶された情報の内、位置を規定する情報によって限定する。すなわち、ＣＰＵ１１１は、例えば優先条件が「現在地」であれば、ユーザデータベース１２２の該当するユーザの地点項目に記憶されている現在位置により、病院データベース１２１の病院情報に記憶されている住所との距離が所定範囲内の病院又は医師を、評価対象として限定する。同様にして、優先条件が「自宅」であれば自宅の住所、「職場」であれば職場の住所、「登録位置」であれば登録位置により、評価対象の病院又は医師を限定することができる。
　なお、この評価対象の病院又は医師の絞り込みの手法に関しては、先に位置情報により限定し、その後に生体データのパターンによって限定するようにしても構わない。また、病院と医師の何れを評価対象とするかは、ＲＡＭ１１２または記憶部１２０に記憶した評価要求元のユーザ端末２０からの評価対象条件に従う。
　ＣＰＵ１１１は、この限定した評価対象病院の病院ＩＤのリスト又は評価対象医師の医師ＩＤと該当医師が所属する病院の病院ＩＤのリストを、ＲＡＭ１１２または記憶部１２０に記憶する。評価対象が医師であっても、病院側が医師を指定した予約ができない場合が有り得るので、評価対象の医師が所属する病院も評価対象としている。
　［ステップＳ１１０］
　ＣＰＵ１１１は、限定した病院の電子カルテの内容を収集する電子カルテ収集処理を実行する。図１１は、この電子カルテ収集処理の一例を例示するフローチャートである。
　　［ステップＳ１１０１］
　電子カルテ収集処理においては、ＣＰＵ１１１は、まず、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストの中から一つの病院ＩＤを選択することで、取得先病院を決定する。
　　［ステップＳ１１０２］
　次に、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、データサーバ４０からその取得先病院の電子カルテの内容を取得する。例えば、ＣＰＵ１１１は、病院ＩＤにより病院データベース１２１を参照して、当該病院を特定する特定情報、例えば病院ＩＤ、アクセス情報、病院名、住所または電話番号を読み出す。そして、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介してデータサーバ４０の制御部４１に、この特定情報と共に電子カルテの記載内容の送信を依頼する。ＣＰＵ１１１は、これに応答してデータサーバ４０から送信されてきた電子カルテの内容を通信インタフェース１３０により受信する。
　なお、取得先病院の電子カルテの数が多い場合には、処理時間が掛かることが想定されるため、電子カルテのタイムスタンプにより最新のものから、人数や期間を限定した送信を依頼するようにしても良い。
　　［ステップＳ１１０３］
　次に、ＣＰＵ１１１は、受信した電子カルテの内容に基づいて、病院データベース１２１及び収集データベース１２４に情報を登録する。例えば、ＣＰＵ１１１は、患者ＩＤ毎に、電子カルテに記載された、各回の診療に関する情報、つまり予約日時、受付、診療開始、医師ＩＤ、診療終了、会計終了、初診フラグ、症状を収集データベース１２４に記憶する。なお、本実施形態では、受信した電子カルテに検査実施が記録されている場合には、ＣＰＵ１１１は、その診療回の診療に関する情報を収集データベース１２４に記憶しないようにしている。また、ＣＰＵ１１１は、電子カルテの内容に基づいて、医師ＩＤ毎に、現時点の診療待ち患者人数を集計し、病院データベース１２１の各医師ＩＤに対応させて集計した人数を「待ち」の項目に記憶する。
　　［ステップＳ１１０４］
　次に、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、その取得先病院から予約患者数を取得する。例えば、ＣＰＵ１１１は、病院ＩＤにより病院データベース１２１を参照して当該病院のアクセス情報を読み出し、通信インタフェース１３０により通信ネットワークＮＥＴを介して当該病院の病院サーバ３０の制御部３１に、各医師についての現在時点の予約患者数を問い合わせる。現在時点の診療待ち患者人数は電子カルテの内容を集計することで判るが、初診の予約を依頼した患者については未だ電子カルテが存在しないので、受信した電子カルテの内容からだけでは予約患者数を把握することができない。そのため、取得先病院へ予約患者数の問合せが必要となる。ＣＰＵ１１１は、この問い合わせに応答して病院サーバ３０から送信されてきた予約患者数の情報を通信インタフェース１３０により受信する。
　　［ステップＳ１１０５］
　次に、ＣＰＵ１１１は、受信した各医師についての現在時点での予約患者数の情報に従って、病院データベース１２１の各医師ＩＤに対応させて「予約状況」の項目に予約患者数を記憶する。
　　［ステップＳ１１０６］
　次に、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストで示される病院の全てについて電子カルテの内容の収集が終了したか否かを判断する。未だ収集していない病院があると判断した場合（ステップＳ１１０６、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１１０１に戻し、次の病院に対する処理を行う。リストアップした全ての病院から電子カルテの内容の収集が終了したと判断した場合（ステップＳ１１０６、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１１１に進める。
　［ステップＳ１１１］
　ＣＰＵ１１１は、収集データベース１２４に記憶した限定した病院それぞれの電子カルテの内容に基づいて評価値を算出する評価算出処理を実行する。図１２は、この評価算出処理の一例を例示するフローチャートである。
　　［ステップＳ１１１１］
　評価算出処理においては、ＣＰＵ１１１は、まず、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストの中から一つの病院ＩＤを選択することで、処理対象病院を決定する。
　　［ステップＳ１１１２］
　次に、ＣＰＵ１１１は、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって医師を評価する。例えば、ＣＰＵ１１１は、病院ＩＤにより収集データベース１２４を参照して、処理対象病院の医師毎の時間スコアを算出する。時間スコアは、例えば、一患者当たりの診療時間の平均値による点数と待ち時間の平均値による点数との合計に基づいて算出されることができる。診療時間は、収集データベース１２４に記憶された診療開始から診療終了までの時間であり、待ち時間は、収集データベース１２４に記憶された受付から診療開始までの時間と、診療終了から会計終了までの時間との合計である。ＣＰＵ１１１は、算出した医師毎の時間スコアを、ＲＡＭ１１２または記憶部１２０に記憶する。なお、多くの場合、初診の際には診療時間が長くなるので、収集データベース１２４の「初診フラグ」により初診か否かを判定し、時間スコアの算出に用いる時間は、初診であれば予め決められた係数を乗じた上で用いられるようにしても良い。
　　［ステップＳ１１１３］
　次に、ＣＰＵ１１１は、医師の属性情報とユーザの属性情報との関係を含む評価項目によって医師を評価する。例えば、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した医師毎の時間スコアを、属性情報に基づいて補正する。属性情報は、例えば、性別や年齢を含む。ＣＰＵ１１１は、病院データベース１２１に記憶された各医師の属性情報と、ユーザデータベース１２２に記憶された、評価要求元のユーザのユーザＩＤに対応する属性情報とを比較する。そして、例えば同性であればスコアを高くしたり、年齢が近いほどスコアを高くしたりする等、予め決めた規則に則って、スコア値を補正する。ＣＰＵ１１１は、補正した医師毎の時間スコアを、ＲＡＭ１１２または記憶部１２０に記憶する。
　　［ステップＳ１１１４］
　次に、ＣＰＵ１１１は、ユーザ端末２０から優先条件として指定された位置情報と病院の位置との関係を含む評価項目によって医師を評価する。例えば、ＣＰＵ１１１は、上記属性情報に基づいて補正してＲＡＭ１１２または記憶部１２０に記憶した医師毎の時間スコアを、優先条件に基づいて補正する。ＣＰＵ１１１は、ユーザデータベース１２２に記憶された、評価要求元のユーザのユーザＩＤに対応する優先条件を参照し、優先条件として指定された位置情報が、病院データベース１２１に記憶された当該病院の住所に対して一定の距離以内である場合には、スコア値を高くする。ＣＰＵ１１１は、補正した医師毎の時間スコアを、ＲＡＭ１１２または記憶部１２０に記憶する。
　　［ステップＳ１１１５］
　その後、ＣＰＵ１１１は、時事の診療待ち患者人数及び予約患者数を含む評価項目によって医師を評価する。例えば、ＣＰＵ１１１は、上記優先条件に基づいて補正してＲＡＭ１１２または記憶部１２０に記憶した医師毎の時間スコアを、診療待ち患者人数及び予約患者数に基づいて補正する。ＣＰＵ１１１は、病院データベース１２１に記憶された医師毎の診療待ち患者人数と予約患者数とを集計し、その集計した人数が少ないほど、スコア値を高くする。ＣＰＵ１１１は、補正した医師毎の時間スコアを、ＲＡＭ１１２または記憶部１２０に記憶する。
　　［ステップＳ１１１６］
　次に、ＣＰＵ１１１は、ユーザデータベース１２２と収集データベース１２４とを参照して、医師毎の症状別改善度スコアを算出する。例えば、ユーザデータベース１２２の各ユーザの病院毎ＩＤに基づいて、収集データベース１２４から当該ユーザの症状を取得し、その症状と同じ症状のユーザを特定する。また、その症状に応じて参照するべき生体データを決定する。そして、ＣＰＵ１１１は、その特定されたユーザが、ユーザデータベース１２２に登録されていれば、そのユーザの症状により決定された生体データの一定期間の履歴をユーザデータベース１２２から読み出して評価する。例えば、症状が高血圧であれば、ＣＰＵ１１１は、一定期間の血圧値を読み出して評価する。
　図１３は、この読み出した生体データの履歴の一例を示す図である。この図の例では、一定期間Ｐの間に、収縮期血圧がＤだけ下がっている。例えば、収縮期血圧の一定期間Ｐ、例えば一ヶ月間の低下量Ｄが２０ｍｍＨｇ以上であれば満点である１０点とし、低下量が１ｍｍＨｇ少なくなる毎に１点減らす、などとスコアを決定する。
　図１４は、生体データの履歴の別の例を示す図である。この図の例も、一定期間Ｐの間の収縮期血圧の低下量Ｄが、図１３の例と同じスコアとなる範囲であったとする。しかしこの例では、一時的に悪化した履歴が含まれている。このような場合、そのまま図１３の例と同じスコアとしても良いが、図１３の例よりも低く算出しても良い。特に、一時的に悪化した状態から改善へ転じたタイミングが、別の病院や医師への切り替わりが有ったタイミングであった場合、一時的に悪化した状態が誤診によるものである可能性が高い。ＣＰＵ１１１は、例えば、収集データベース１２４の予約日時項目に記録された日付と、ユーザデータベース１２２の日付項目に記録された日付及び通院フラグ項目に記録された通院の記録とに基づいて、この誤診の可能性を判断し、その結果に応じてスコアを修正することができる。
　ＣＰＵ１１１は、こうして算出した医師毎の症状別改善度スコアをＲＡＭ１１２または記憶部１２０に記憶する。
　　［ステップＳ１１１７］
　次に、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した医師毎の、症状別改善度スコアと補正後の時間スコアとから、総合スコアを算出する。更に、ＣＰＵ１１１は、医師毎の総合スコアから、診療科スコア及び病院スコアを算出する。ＣＰＵ１１１は、こうして算出した医師毎の総合スコア、診療科スコア及び病院スコアをＲＡＭ１１２または記憶部１２０に記憶する。
　　［ステップＳ１１１８］
　そして、ＣＰＵ１１１は、こうして算出してＲＡＭ１１２または記憶部１２０に記憶した各スコアを、評価データベース１２５に、ユーザＩＤに対応させて登録する。このように、属性情報や優先条件などに基づいて時間スコアを補正することで、図７に示すように、同じ医師、診療科、病院であっても、ユーザ毎に異なるスコア値が評価データベース１２５に登録されることになる。
　　［ステップＳ１１１９］
　次に、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストで示される病院の全てについて評価値の算出が終了したか否かを判断する。未だ評価値を算出していない病院があると判断した場合（ステップＳ１１１９、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１１１１に戻し、次の病院に対する処理を行う。リストアップした全ての病院について評価値の算出が終了したと判断した場合（ステップＳ１１１９、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１１２に進める。
　［ステップＳ１１２］
　ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した評価対象条件に従って、評価データベース１２５に記憶されている評価要求元のユーザのユーザＩＤに対応する評価結果を読み出してソートする。例えば、評価対象条件が病院であれば、病院ＩＤと病院スコアの組を読み出して、病院スコアが高い順にソートする。また、例えば、評価対象条件が医師であれば、医師ＩＤと総合スコアの組を読み出して、総合スコアが高い順にソートする。ＣＰＵ１１１は、ソートした結果を、ＲＡＭ１１２または記憶部１２０に記憶する。
　［ステップＳ１１３］
　そして、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶しているソートした結果に基づいて予約候補を決定して、通信インタフェース１３０により通信ネットワークＮＥＴを介して、評価要求元のユーザ端末２０に送信する。予約候補の数は、少なくとも一つ有れば良いが、ユーザに選択肢を与えるために複数決定して送信することが望ましい。勿論、ユーザ端末２０からの折り返しの指示により、順次に次候補を決定して送信するようにしても構わない。予約候補は、ＲＡＭ１１２または記憶部１２０に記憶した評価対象条件に従って決定される。例えば、評価対象条件が病院であれば、少なくとも病院の名称や住所を含む病院情報と、その病院のスコア値とを含むことができる。病院情報は、病院データベース１２１より取得することができる。また、例えば、評価対象条件が医師であれば、少なくとも医師の氏名、性別、年齢を含む医師情報及び当該医師のスコア値と、当該医師が所属する病院の病院情報及び当該病院のスコア値と、を含むことができる。医師情報及び病院情報は、病院データベース１２１より取得することができる。
　［ステップＳ２０９４］
　上記ステップＳ２０９３において予約候補を受信したと判断した場合（ステップＳ２０９３、ＹＥＳ）、ユーザ端末２０のプロセッサは、処理をステップＳ２０９４に進め、その受信した予約候補を図示しないユーザインタフェースによりユーザに提示する。
　＜１－２－４＞予約動作
　［ステップＳ１１４］
　上記ステップＳ１１３において予約候補を送信後、サービスサーバ１００のＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、当該ユーザ端末２０からの予約要求を受信したか否かを判断する。予約要求を受信していないと判断した場合（ステップＳ１１４、ＮＯ）、ＣＰＵ１１１は、処理をステップＳ１１５に進める。
　［ステップＳ２０９５］
　また、ユーザ端末２０の図示しないプロセッサは、上記ステップＳ２０９４において受信した予約候補をユーザに提示した後、図示しないユーザインタフェースを通じたユーザ操作による、終了又は予約の入力を受け付ける。予約の入力は、予約を望む病院または医師の選択と、希望日時の入力とを含む。
　［ステップＳ２０９６］
　そして、ユーザ端末２０のプロセッサは、受け付けた入力が終了の入力であるか否かを判断する。受け付けた入力が終了の入力ではない、つまり予約の入力であると判断した場合（ステップＳ２０９６、ＮＯ）、プロセッサは、処理をステップＳ２０９７に進める。
　［ステップＳ２０９７］
　上記ステップＳ２０９６において予約の入力を受け付けたと判断した場合（ステップＳ２０９６、ＮＯ）、ユーザ端末２０のプロセッサは、予約要求を、通信ネットワークＮＥＴを介してサービスサーバ１００に送信する。
　［ステップＳ２０９８］
　その後、ユーザ端末２０のプロセッサは、通信ネットワークＮＥＴを介してサービスサーバ１００からの予約結果を受信するのを待つ。すなわち、プロセッサは、予約結果を受信したか否かを判断し、受信していない場合（ステップＳ２０９８、ＮＯ）、このステップＳ２０９８の処理を繰り返す。
　［ステップＳ１１６］
　サービスサーバ１００のＣＰＵ１１１は、上記ステップＳ１１４において予約要求を受信したと判断した場合（ステップＳ１１４、ＹＥＳ）、処理をステップＳ１１６に進め、通信インタフェース１３０により通信ネットワークＮＥＴを介して、該当病院の病院サーバ３０へ、予約要求を、ユーザデータベース１２２に記憶されている当該ユーザのＰＨＲと共に送信する。全生体データを含むＰＨＲではなく、最新の生体データのみで有っても良い。またこのとき、ＣＰＵ１１１は、ユーザデータベース１２２の病院毎ＩＤを参照して、もし当該ユーザが該当病院における管理番号を有するユーザであることが確認できた場合には、この予約要求にその管理番号を含めることができる。
　［ステップＳ１１７］
　その後、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、該当病院の病院サーバ３０からの予約結果を受信するのを待つ。すなわち、ＣＰＵ１１１は、予約結果を受信したか否かを判断し、受信していないと判断した場合（ステップＳ１１７、ＮＯ）、このステップＳ１１７を繰り返す。
　患者の予約管理を行う病院サーバ３０では、この予約要求に応じた予約処理を行う。そして、その結果を通信ネットワークＮＥＴを介してサービスサーバ１００に返す。
　［ステップＳ１１８］
　上記ステップＳ１１７において予約結果を受信したと判断した場合（ステップＳ１１７、ＹＥＳ）、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、予約要求元のユーザ端末２０へ予約結果を送信する。その後、ＣＰＵ１１１は、処理を上記ステップＳ１１４に戻す。
　［ステップＳ２０９９］
　上記ステップＳ２０９８において予約結果を受信したと判断した場合（ステップＳ２０９８、ＹＥＳ）、ユーザ端末２０のプロセッサは、処理をステップＳ２０９９に進め、その受信した予約結果を図示しないユーザインタフェースによりユーザに提示する。その後、プロセッサは、処理を上記ステップＳ２０９５に戻す。
　もし、所望の予約が取れないという予約結果であったならば、ステップＳ２０９５において、ユーザは別の予約希望日時を再設定したり、別の病院、別の医師などを選択したりすることが可能である。また、所望の予約が取れた場合には、ユーザは医療評価の処理を終了するために、終了の入力を行う。
　＜１－２－５＞終了動作
　［ステップＳ２０９１０］
　ユーザ端末２０の図示しないプロセッサは、上記ステップＳ２０９６において受け付けた入力が終了の入力であると判断した場合（ステップＳ２０９６、ＹＥＳ）、処理をステップＳ２０９１０に進め、終了要求を、通信ネットワークＮＥＴを介してサービスサーバ１００に送信する。そして、プロセッサは、処理を上記ステップＳ２０１に戻す。
　［ステップＳ１１５］
　サービスサーバ１００のＣＰＵ１１１は、上記ステップＳ１１４において予約要求を受信していないと判断した場合（ステップＳ１１４、ＮＯ）、更に、通信インタフェース１３０により通信ネットワークＮＥＴを介して、当該ユーザ端末２０からの終了要求を受信したか否かを判断する。終了要求を受信していないと判断した場合（ステップＳ１１５、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１１４に戻す。終了要求を受信したと判断した場合（ステップＳ１１５、ＹＥＳ）、ＣＰＵ１１１は、処理を上記ステップＳ１０１に戻す。
　＜１－２－６＞その他の処理
　［ステップＳ２１０］
　ユーザ端末２０の制御部２１の図示しないプロセッサは、上記ステップＳ２０８において行われた操作は医療評価の取得指示ではないと判断した場合（ステップＳ２０８、ＮＯ）その操作に応じた、その他の処理を実行する。このその他の処理は、例えば、サービスサーバ１００の上記ステップＳ１０４でのユーザデータベース１２２の更新処理を行うための当該ユーザの新規登録操作や情報更新操作に応じた処理を含む。そして、処理実行後、プロセッサは、処理を上記ステップＳ２０１に戻す。
　＜１－３＞効果
　上述した第１実施形態によれば、サービスサーバ１００のＣＰＵ１１１が、複数の病院の間で電子カルテを共有するための電子カルテネットワーク１から各電子カルテの記載内容を収集すると共に、各ユーザのユーザ端末２０から複数のユーザそれぞれの生体データの一定期間の履歴を収集し、これら収集した情報に基づいて、少なくとも病院毎、更には各病院の診療科毎または各病院の医師毎に、少なくとも一患者当たりの診療時間及び待ち時間に基づく時間スコアと、各ユーザの症状の改善度に基づく症状別改善度スコアとを算出して、評価データベース１２５に記憶する。よって、時間という客観的な指標と症状の改善度というユーザの症状の改善状況とに基づいて、少なくとも病院を、更には病院の診療科または医師を評価することができるようになる。そして、ＣＰＵ１１１は、この評価スコアをユーザ端末２０に送信してユーザに提示することで、ユーザは、自身が診療を受けようとする病院、診療科又は医師を、この提示されたスコアを参考にして、選定することが可能となる。
　また、第１実施形態によれば、評価結果を評価値つまりスコアという数値で求めていることで、その数値により評価結果を順番付けでき、その結果、ユーザに適した予約候補を容易に決定することができる。
　また、第１実施形態によれば、対応関係データベース１２３を用いることで、容易且つ迅速に評価対象の病院又は医師を限定することができる。
　また、第１実施形態によれば、病院予約サービスに加入するユーザの各ユーザ端末２０からＰＨＲを収集することで、ユーザの生体データを容易に収集することができる。
　また、第１実施形態によれば、時間的評価だけでなく、症状の改善度という症状の改善状況に基づいた評価を加えることで、よりユーザに適した候補を提供することができる。
　また、第１実施形態によれば、スコア値という点数化した評価値を用い、予約候補をその数値と共にユーザ端末２０に送信して提示することで、ユーザが予約する病院を選定する際の指標を提供することができ、ユーザの選定を容易にすることが可能となる。
　また、第１実施形態によれば、評価要求元のユーザの性別又は年齢と医師の性別又は年齢とにも基づいて評価するので、ユーザに適した医師を高く評価することができ、ユーザにより適した医師を候補とすることができるようになる。
　また、第１実施形態によれば、評価要求元のユーザの現在位置やユーザが指定した指定位置に応じて、ユーザが通い得る病院を限定することで、ユーザに不適切な病院を候補として提示する可能性を小さくすることができる。
　また、第１実施形態によれば、病院又は医師の評価値を算出する際に、現時点における診療待ち患者人数と今後の予約状況とを参照し、待ち時間少なく直ぐに診療可能な病院や医師ほど高スコアとすることで、ユーザが予期せず空き時間が取れたときや、急に具合が悪くなったときなど、今すぐ診療可能な病院を探す場合に、有効な手段を提供することができる。
　なお、今すぐ診療可能な病院を探す場合には、ユーザ端末２０における上記ステップＳ２０９１の条件入力の際に、その点を指定できるようにすることで、上記ステップＳ１１１５における診療待ち患者人数及び予約患者数に基づいた補正の重みを重くする、つまりスコア値を高くするようにしても良い。あるいは、上記ステップＳ１１１３の属性情報に基づく補正や上記ステップＳ１１１４における優先条件に基づく補正の重みを軽くしたり、それらの補正をスキップしたりできるようにしても良い。
　また、上述したような病院予約システムによってユーザが病院予約を行った場合、サービスサーバ１００は、予約先の病院から紹介料金を徴収できる課金処理の手順を有しても良い。
　また、病院は、上述したようなサービスサーバ１００の処理手順によって予約されたユーザに対しては、紹介状を不要又は減額とするようなサービスを提供するようにしても良い。
　＜２＞第２実施形態
　次に、第２実施形態について説明する。
　＜２－１＞構成及び＜２－２＞動作
　本第２実施形態に係る病院予約システムの基本的な構成及び基本的な動作は、上述した第１実施形態に係る病院予約システムと同様である。従って、上述した第１実施形態で説明した事項及び上述した第１実施形態から容易に類推可能な事項についての説明は省略する。
　図１５は、第２実施形態におけるサービスサーバ１００の処理手順の一例を例示するフローチャートである。図８と同様の処理については同じ参照符号を付す。
　＜２－２－１＞収集動作
　［ステップＳ１１９］
　サービスサーバ１００のＣＰＵ１１１は、先ず、生体データ及び電子カルテを収集するべきタイミングになったか否かを判断する。本実施形態では、例えば、１日１回など、予め決めたタイミングで生体データ及び電子カルテを収集する。生体データ及び電子カルテを収集するべきタイミングではないと判断した場合（ステップＳ１１９、ＮＯ）、ＣＰＵ１１１は、処理をステップＳ１０３に進める。生体データ及び電子カルテを収集するべきタイミングであると判断した場合（ステップＳ１１９、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１０２に進める。
　［ステップＳ１０２］
　上記ステップＳ１０１において生体データ及び電子カルテを収集するべきタイミングであると判断した場合（ステップＳ１０１、ＹＥＳ）、ＣＰＵ１１１は、先ず、上記第１実施形態と同様の生体データ収集処理を実行する。
　［ステップＳ１２０］
　次に、ＣＰＵ１１１は、電子カルテ収集処理を実行する。この場合、上記第１実施形態におけるステップＳ１１０の電子カルテ収集処理と異なり、対象病院の限定を行っていないので、ＣＰＵ１１１は、限定されない、つまり全ての病院の電子カルテの内容を収集することとなる。図１６は、この電子カルテ収集処理の一例を例示するフローチャートである。
　　［ステップＳ１２０１］
　電子カルテ収集処理においては、ＣＰＵ１１１は、まず、病院データベース１２１に登録されている病院ＩＤの中から一つの病院ＩＤを選択することで、取得先病院を決定する。
　　［ステップＳ１２０２］
　次に、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、データサーバ４０からその取得先病院の電子カルテの内容を取得する。このステップＳ１２０２の処理は、上記第１実施形態におけるステップＳ１１０２の処理と同様である。すなわち、ＣＰＵ１１１は、病院ＩＤにより病院データベース１２１を参照して、当該病院を特定する特定情報、例えば病院ＩＤ、アクセス情報、病院名、住所または電話番号を読み出す。そして、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介してデータサーバ４０の制御部４１に、この特定情報と共に電子カルテの記載内容の送信を依頼する。ＣＰＵ１１１は、これに応答してデータサーバ４０から送信されてきた電子カルテの内容を通信インタフェース１３０により受信する。
　なお、取得先病院の電子カルテの数が多い場合には、処理時間が掛かることが想定されるため、電子カルテのタイムスタンプにより最新のものから、人数や期間を限定した送信を依頼するようにしても良い。
　　［ステップＳ１２０３］
　次に、ＣＰＵ１１１は、受信した電子カルテの内容に基づいて、病院データベース１２１及び収集データベース１２４に情報を登録する。例えば、ＣＰＵ１１１は、患者ＩＤ毎に、電子カルテに記載された、各回の診療に関する情報、つまり予約日時、受付、診療開始、医師ＩＤ、診療終了、会計終了、初診フラグ、症状を収集データベース１２４に記憶する。
　　［ステップＳ１２０４］
　次に、ＣＰＵ１１１は、病院データベース１２１に登録されている病院ＩＤで示される病院の全てについて電子カルテの内容の収集が終了したか否かを判断する。未だ収集していない病院があると判断した場合（ステップＳ１２０４、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１２０１に戻し、次の病院に対する処理を行う。登録されている全ての病院から電子カルテの内容の収集が終了したと判断した場合（ステップＳ１２０４、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１０３に進める。
　＜２－２－２＞登録情報更新動作
　［ステップＳ１０３］～［ステップＳ１０８］
　ＣＰＵ１１１は、上記ステップＳ１１９において生体データ及び電子カルテを収集するべきタイミングではないと判断した場合（ステップＳ１１９、ＮＯ）、或いは、上記ステップＳ１１０の電子カルテ収集処理の終了後、上記第１実施形態と同様の［ステップＳ１０１］乃至［ステップＳ１０６］の処理を行う。但し、上記ステップＳ１０６において評価要求を受信していないと判断した場合（ステップＳ１０６、ＮＯ）の処理の戻り先は、上記ステップＳ１１９である。すなわち、ＣＰＵ１１１は、病院データベース１２１の更新処理とユーザデータベース１２２の更新処理とを行う。そして、ＣＰＵ１１１は、何れかのユーザ端末２０からＰＨＲ又は評価要求を受信したか否かを判断する。何れも受信していないと判断した場合、ＣＰＵ１１１は、処理を上記ステップＳ１１９に戻す。ＰＨＲを受信したと判断した場合には、ＣＰＵ１１１は、受信したＰＨＲに基づいて、ユーザデータベース１２２の、対応するユーザの日付や生体データ（「血圧」、「脈拍」、など）の項目を更新する。また、評価要求を受信したと判断した場合には、ＣＰＵ１１１は、受信した評価要求に含まれるユーザＩＤ及びパスワードによりユーザ認証を行った上で、同じく評価要求に含まれる位置情報及び評価要求に含まれる優先条件により、ユーザデータベース１２２を更新する。
　＜２－２－３＞評価動作
　［ステップＳ１０９］
　評価要求を受信してユーザデータベース１２２を更新した後、ＣＰＵ１１１は、上記第１実施形態と同様に、評価対象の病院を限定する。
　［ステップＳ１２１］
　その後、ＣＰＵ１１１は、上記ステップＳ１０９で限定した病院それぞれにおける現在時点の診療待ち患者人数と予約患者数を集計する人数収集処理を行う。すなわち、上記ステップＳ１２０では、例えば、１日１回など、予め決めたタイミングで電子カルテの内容を収集するので、診療待ち患者人数と予約患者数の集計は行っていない。そこで、ＣＰＵ１１１は、それら人数を収集する。図１７は、この人数収集処理の一例を例示するフローチャートである。
　　［ステップＳ１２１１］
　人数収集処理においては、ＣＰＵ１１１は、まず、ＲＡＭ１１２または記憶部１２０に記憶した限定した病院ＩＤのリストの中から一つの病院ＩＤを選択することで、取得先病院を決定する。
　　［ステップＳ１２１２］
　次に、ＣＰＵ１１１は、通信インタフェース１３０により通信ネットワークＮＥＴを介して、その取得先病院から診療待ち患者人数及び予約患者数を取得する。例えば、ＣＰＵ１１１は、病院ＩＤにより病院データベース１２１を参照して当該病院のアクセス情報を読み出し、通信インタフェース１３０により通信ネットワークＮＥＴを介して当該病院の病院サーバ３０の制御部３１に、各医師についての現在時点の診療待ち患者人数と予約患者数とを問い合わせる。そして、ＣＰＵ１１１は、この問い合わせに応答して病院サーバ３０から送信されてきた診療待ち患者人数及び予約患者数の情報を通信インタフェース１３０により受信する。
　　［ステップＳ１２１３］
　次に、ＣＰＵ１１１は、受信した各医師についての現在時点での診療待ち患者人数及び予約患者数の情報に従って、病院データベース１２１の各医師ＩＤに対応させて「待ち」及び「予約状況」の項目にそれぞれの人数を記憶する。
　　［ステップＳ１２１４］
　次に、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストで示される病院の全てについて人数の収集が終了したか否かを判断する。未だ収集していない病院があると判断した場合（ステップＳ１２１４、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１２１１に戻し、次の病院に対する処理を行う。リストアップした全ての病院から人数の収集が終了したと判断した場合（ステップＳ１２１４、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１１１に進める。
　［ステップＳ１１１］～［ステップＳ１１３］その後、ＣＰＵ１１１は、上記第１実施形態と同様の［ステップＳ１１１］乃至［ステップＳ１１３］の処理を行う。すなわち、ＣＰＵ１１１は、収集データベース１２４に記憶した各病院の電子カルテの内容の内、この限定した病院の内容に基づいてのみ、評価値を算出する。その後、ＣＰＵ１１１は、評価条件に含まれる評価対象条件に従って、評価データベース１２５に記憶されている評価要求元のユーザのユーザＩＤに対応する評価結果を読み出してソートし、そのソートした結果と評価対象条件に従って予約候補を決定する。そしてＣＰＵ１１１は、その決定した予約候補を、通信インタフェース１３０により通信ネットワークＮＥＴを介して、評価要求元のユーザ端末２０に送信する。
　＜２－２－４＞予約動作、＜２－２－５＞終了動作
　［ステップＳ１１４］～［ステップＳ１１８］
　その後の［ステップＳ１１４］乃至［ステップＳ１１８］の処理は、上記第１実施形態と同様である。但し、上記ステップＳ１１５において終了要求を受信したと判断した場合（ステップＳ１１５、ＹＥＳ）の処理の戻り先は、上記ステップＳ１１９である。
　＜２－３＞効果
　上述した第２実施形態によれば、上記第１実施形態と同様の効果を奏することができる。また、この第２実施形態では、電子カルテの記載内容を予め全ての病院について収集しておくので、ユーザからの評価要求に応じて直ちに評価値の算出処理を実行でき、レスポンス良くユーザに評価結果を提示することが可能になる。
　＜３＞第３実施形態
　次に、第３実施形態について説明する。
　＜３－１＞構成及び＜３－２＞動作
　本第３実施形態に係る病院予約システムの基本的な構成及び基本的な動作は、上述した第２実施形態に係る病院予約システムと同様である。従って、上述した第２実施形態で説明した事項及び上述した第２実施形態から容易に類推可能な事項についての説明は省略する。
　図１８は、第３実施形態におけるサービスサーバ１００の処理手順の一例を例示するフローチャートである。図１５と同様の処理については同じ参照符号を付す。
　＜３－２－１＞収集動作及び第１評価動作
　［ステップＳ１１９］、［ステップＳ１０２］、［ステップＳ１２０］
　サービスサーバ１００のＣＰＵ１１１は、先ず、上記第２実施形態と同様に、生体データ及び電子カルテを収集するべきタイミングになったか否かを判断する。生体データ及び電子カルテを収集するべきタイミングであると判断した場合（ステップＳ１１９、ＹＥＳ）、ＣＰＵ１１１は、上記第２実施形態と同様の［ステップＳ１０２］及び［ステップＳ１２０］の処理を行う。すなわち、ＣＰＵ１１１は、上記第１実施形態と同様の生体データ収集処理と上記第２実施形態と同様の電子カルテ収集処理とを実行する。
　［ステップＳ１２２］
　その後、ＣＰＵ１１１は、収集データベース１２４に記憶した各病院の電子カルテの内容に基づいて評価値を算出する第１評価算出処理を実行する。この第１評価算出処理においては、評価値として、医師毎の時間スコアを算出する。図１９は、この第１評価算出処理の一例を例示するフローチャートである。
　　［ステップＳ１２２１］
　第１評価算出処理においては、ＣＰＵ１１１は、まず、病院データベース１２１に登録されている病院ＩＤの中から一つの病院ＩＤを選択することで、処理対象病院を決定する。
　　［ステップＳ１１１２］
　次に、ＣＰＵ１１１は、上記第１実施形態と同様に、病院ＩＤにより収集データベース１２４を参照して、処理対象病院の医師毎の時間スコアを算出する。ＣＰＵ１１１は、算出した医師毎の時間スコアを、ＲＡＭ１１２または記憶部１２０に記憶する。
　　［ステップＳ１２２２］
　次に、ＣＰＵ１１１は、算出してＲＡＭ１１２または記憶部１２０に記憶した当該病院に所属する各医師の時間スコアを、評価データベース１２５における該当する医師ＩＤに対応する総合スコアの項目に登録する。
　　［ステップＳ１２２３］
　そして、ＣＰＵ１１１は、病院データベース１２１に記憶されている病院ＩＤで示される病院の全てについて評価値の算出が終了したか否かを判断する。未だ評価値を算出していない病院があると判断した場合（ステップＳ１２２３、ＮＯ）、ＣＰＵ１１１は、処理を上記ステップＳ１２１１に戻し、次の病院に対する処理を行う。全ての病院について評価値の算出が終了したと判断した場合（ステップＳ１２２３、ＹＥＳ）、ＣＰＵ１１１は、処理をステップＳ１０３に進める。
　＜３－２－２＞登録情報更新動作
　［ステップＳ１０３］～［ステップＳ１０８］
　［ステップＳ１０３］乃至［ステップＳ１０８］の処理は、上記第１実施形態と同様である。
　＜３－２－３＞第２評価動作
　［ステップＳ１０９］
　評価要求を受信してユーザデータベース１２２を更新した後、サービスサーバ１００のＣＰＵ１１１は、上記第１実施形態と同様、ユーザデータベース１２２の該当するユーザの優先条件項目に記憶された情報の内、位置を規定する情報により、評価対象の病院を限定する。
　［ステップＳ１２１］
　次に、ＣＰＵ１１１は、上記第２実施形態と同様に、上記ステップＳ１０９で限定した病院それぞれにおける現在時点の診療待ち患者人数と予約患者数の問合せを行って、結果を病院データベース１２１に登録する人数収集処理を行う。
　［ステップＳ１２３］
　その後、ＣＰＵ１１１は、収集データベース１２４に記憶した各病院の電子カルテの内容に基づいて評価値を算出する第２評価算出処理を実行する。図２０は、この第２評価算出処理の一例を例示するフローチャートである。
　　［ステップＳ１１１１］
　第２評価算出処理においては、ＣＰＵ１１１は、上記第１実施形態と同様に、まず、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストの中から一つの病院ＩＤを選択することで、処理対象病院を決定する。
　　［ステップＳ１２３１］
　そして、その処理対象病院に所属する各医師の医師ＩＤを病院データベース１２１により取得し、その医師ＩＤに対応する時間スコアを、評価データベース１２５における該当医師ＩＤに対応する総合スコアの項目から読み出し、ＲＡＭ１１２または記憶部１２０に記憶する。
　　［ステップＳ１１１３］～［ステップＳ１１１９］
　その後の［ステップＳ１１１３］乃至［ステップＳ１１１９］の処理は、上記第１実施形態と同様である。すなわち、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した医師毎の時間スコアを、属性情報及び優先条件に基づいて補正し、更に、診療待ち患者人数及び予約患者数に基づいて補正する。また、ＣＰＵ１１１は、ユーザデータベース１２２と収集データベース１２４とを参照して、医師毎の症状別改善度スコアを算出する。そして、ＣＰＵ１１１は、医師毎の、症状別改善度スコアと補正後の時間スコアとから、総合スコアを算出し、更に、この医師毎の総合スコアから、診療科スコア及び病院スコアを算出し、算出した各スコアを、評価データベース１２５に、ユーザＩＤに対応させて登録する。その後、ＣＰＵ１１１は、ＲＡＭ１１２または記憶部１２０に記憶した病院ＩＤのリストで示される病院の全てについて評価値の算出が終了したか否かを判断し、未だ評価値を算出していない病院があれば、処理を上記ステップＳ１１１１に戻し、次の病院に対する処理を行う。そして、リストアップした全ての病院について評価値の算出が終了したと判断した場合、ＣＰＵ１１１は、処理をステップＳ１１２に進める。
　［ステップＳ１１２］、［ステップＳ１１３］
　その後の［ステップＳ１１２］及び［ステップＳ１１３］の処理は、上記第１実施形態と同様である。すなわち、ＣＰＵ１１１は、評価条件に含まれる評価対象条件に従って、評価データベース１２５に記憶されている評価要求元のユーザのユーザＩＤに対応する評価結果を読み出してソートし、そのソートした結果と評価対象条件に従って予約候補を決定する。そしてＣＰＵ１１１は、その決定した予約候補を、通信インタフェース１３０により通信ネットワークＮＥＴを介して、評価要求元のユーザ端末２０に送信する。
　＜３－２－４＞予約動作、＜３－２－５＞終了動作
　［ステップＳ１１４］～［ステップＳ１１８］
　その後の［ステップＳ１１４］乃至［ステップＳ１１８］の処理は、上記第１実施形態と同様である。但し、上記ステップＳ１１５において終了要求を受信したと判断した場合（ステップＳ１１５、ＹＥＳ）の処理の戻り先は、上記ステップＳ１１９である。
　＜３－３＞効果
　上述した第３実施形態によれば、上記第２実施形態と同様の効果を奏することができる。また、この第３実施形態では、ユーザに依存しない評価値を予め算出しておくので、ユーザからの評価要求に応じて直ちにユーザに依存する評価値の算出処理を実行でき、レスポンス良くユーザに評価結果を提示することが可能になる。
　この発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除しても良い。さらに、異なる実施形態に亘る構成要素を適宜組み合せても良い。
　例えば、フローチャートを参照して説明した処理手順は一例に過ぎず、各処理は可能な限り変更されて良い。また、説明した処理手順について、実施の形態に応じて、適宜、ステップの省略、置換、及び追加が可能である。
　上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られるものではない。
　（付記１）
　複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワーク（１）と、
　前記電子カルテネットワークから前記電子カルテの記載内容を収集する電子カルテ収集部（１１）と、
　通信ネットワーク（ＮＥＴ）を介して、複数のユーザそれぞれの生体データを収集する生体データ収集部（１２）と、
　前記通信ネットワークを介して、ユーザ端末（２０）から要求を受け付ける受付部（１３）と、
　前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部（１４）と、
　前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部（１５）と、
　前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部（１６）と、
　前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部（３１）と、
　前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部（１７）と、
　を具備する、病院予約システム。
　（付記２）
　プロセッサ（１１１）及びメモリ（１１２，１２０）を有するサーバ装置が実行する病院予約方法であって、
　前記プロセッサにより、複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークから、前記電子カルテの記載内容を収集して前記メモリに記憶する過程（Ｓ１１０）と、
　前記プロセッサにより、通信ネットワークを介して、複数のユーザそれぞれの生体データを収集して前記メモリに記憶する過程（Ｓ１０２）と、
　前記プロセッサにより、前記通信ネットワークを介して、ユーザ端末から評価要求を前記ユーザ端末のユーザの生体データと共に受け付ける過程（Ｓ１０６）と、
　前記ユーザ端末からの前記評価要求に応じて、前記プロセッサにより、前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記メモリに記憶された前記複数のユーザそれぞれの前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する過程（Ｓ１０９）と、
　前記プロセッサにより、前記メモリに記憶された前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記評価対象として限定された前記複数の病院又は医師を評価し、その評価結果を前記メモリに記憶する過程（Ｓ１１１）と、
　前記プロセッサにより、前記メモリに記憶された前記複数の病院又は医師の評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる過程（Ｓ１１３）と、
　前記プロセッサにより、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求を、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付ける過程（Ｓ１１４）と、
　前記要求元の前記ユーザ端末からの前記病院又は医師に対する予約要求に応じて、前記プロセッサにより、前記通信ネットワークを介して、その依頼された前記病院又は医師に該当する病院が備える患者の予約管理を行う病院制御部に、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する過程（Ｓ１１６）と、
　を備える病院予約方法。
　（付記３）
　請求項１０に記載のサーバ装置が具備する前記電子カルテ収集部（１１）、前記生体データ収集部（１２）、前記受付部（１３）、前記限定部（１４）、前記評価部（１５）、前記提示部（１６）、及び前記予約部（１７）としてプロセッサを機能させる病院予約プログラム。
　１…電子カルテネットワーク
　１０…サービスサーバ
　１１…電子カルテ収集部
　１２…生体データ収集部
　１３…受付部
　１４…限定部
　１５…評価部
　１６…提示部
　１７…予約部
　１８…対応関係データベース
　１９…医師属性取得部
　２０…ユーザ端末
　２１，３１，４１，１１０…制御部
　２２…測定部
　２３，３２，４２，１２０…記憶部
　２４…生体データ計測装置
　３０…病院サーバ
　３３…医療端末
　４０…データサーバ
　１００…サービスサーバ
　１１１…ＣＰＵ
　１１２…ＲＡＭ
　１１３…ＲＯＭ
　１２１…病院データベース
　１２２…ユーザデータベース
　１２３…対応関係データベース
　１２４…収集データベース
　１２５…評価データベース
　１３０…通信インタフェース

Claims (10)

  1. 　複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークと、
    　前記電子カルテネットワークから前記電子カルテの記載内容を収集する電子カルテ収集部と、
    　通信ネットワークを介して、複数のユーザそれぞれの生体データを収集する生体データ収集部と、
    　前記通信ネットワークを介して、ユーザ端末から要求を受け付ける受付部と、
    　前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部と、
    　前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部と、
    　前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部と、
    　前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部と、
    　前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部と、
    　を具備する、病院予約システム。
  2. 　前記評価部は、前記複数の病院又は医師の評価結果を表す評価値を算出し、
    　前記提示部は、前記評価部が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、前記抽出した前記予約候補をその評価値と共に前記要求元の前記ユーザ端末に提示させる、請求項１に記載の病院予約システム。
  3. 　前記生体データ収集部によって収集した前記生体データの属性に応じて病院又は医師をデータベース化した対応関係データベースを更に具備し、
    　前記限定部は、前記要求元の前記ユーザ端末の前記ユーザの前記生体データの属性により、前記対応関係データベースを参照して、前記評価対象となる前記複数の病院又は医師を限定する、請求項１に記載の病院予約システム。
  4. 　前記生体データ収集部は、それぞれユーザの生体データを収集する複数のユーザ端末それぞれから送信されたユーザの生体データを、前記通信ネットワークを介して受信する、請求項１に記載の病院予約システム。
  5. 　前記生体データ収集部は、前記複数のユーザそれぞれの生体データの履歴を収集し、
    　前記評価部によって評価する評価項目は、更に、前記生体データ収集部によって収集した前記生体データの一定期間の履歴に基づく症状の改善度を含む、請求項１に記載の病院予約システム。
  6. 　前記評価部は、評価項目毎の評価結果を点数化し、医師については合計点数を評価値とし、病院についてはその病院に属する医師の評価値の平均値を評価値とし、
    　前記提示部は、前記評価部が算出した評価値が高い方から複数の病院又は医師を前記予約候補として抽出し、前記抽出した前記予約候補をその評価値と共に前記要求元の前記ユーザ端末に提示させる、請求項１に記載の病院予約システム。
  7. 　前記各病院に所属する各医師について、少なくとも性別及び年齢を含む公開可能な医師属性情報を取得する医師属性取得部を更に具備し、
    　前記受付部は、更に、前記要求元の前記ユーザ端末の前記ユーザの属性情報を受け付け、
    　前記評価部によって評価する評価項目は、更に、前記医師属性取得部により取得される前記医師の属性情報と、前記受付部によって受け付けた前記要求元の前記ユーザ端末の前記ユーザの属性情報との関係を含む、請求項１に記載の病院予約システム。
  8. 　前記受付部は、更に、前記要求元の前記ユーザ端末から位置情報を受け付け、
    　前記限定部は、前記受付部によって受け付けた前記要求元の前記ユーザ端末からの前記位置情報に基づいて、前記評価対象となる前記複数の病院又は医師を限定し、
    　前記評価部によって評価する評価項目は、更に、前記受付部によって受け付けた前記要求元の前記ユーザ端末からの前記位置情報と、前記評価対象の前記病院の位置との関係を含む、請求項１に記載の病院予約システム。
  9. 　前記病院制御部は、更に、前記病院の時事の滞在中患者の時間管理を行い、
    　前記評価部は、前記病院制御部にアクセスして、各病院の、現時点における少なくとも診療待ち患者人数と、今後の予約患者数とを取得し、
    　前記評価部によって評価する評価項目は、更に、前記取得した診療待ち患者人数及び予約患者数を含む、請求項１に記載の病院予約システム。
  10. 　複数の病院それぞれにおける、少なくとも、患者に関する患者情報と、各回の診療に関する、受付日時、診療開始日時、診療終了日時、診療医師、及び会計終了日時を含む診療情報と、を記載した、患者毎の電子カルテを、前記複数の病院の間で共有するための電子カルテネットワークから、前記電子カルテの記載内容を収集する電子カルテ収集部と、
    　通信ネットワークを介して、複数のユーザそれぞれの生体データを収集する生体データ収集部と、
    　前記通信ネットワークを介して、ユーザ端末から要求を受け付ける受付部と、
    　前記受付部によって前記ユーザ端末から評価要求と前記ユーザ端末のユーザの生体データとが受け付けられたとき、前記受付部が受け付けた前記評価要求の要求元の前記ユーザ端末の前記ユーザの前記生体データと、前記生体データ収集部によって収集した前記生体データとに基づいて、前記複数の病院又は前記複数の病院に所属する複数の医師の中から、評価対象を限定する限定部と、
    　前記電子カルテ収集部によって収集した前記電子カルテの記載内容に基づいて、少なくとも一患者当たりの診療時間及び待ち時間を含む評価項目によって、前記限定部によって前記評価対象として限定された前記複数の病院又は医師を評価する評価部と、
    　前記評価部による評価結果に基づいて、前記評価された複数の病院又は医師の中から少なくとも一つを予約候補として、前記通信ネットワークを介して前記要求元の前記ユーザ端末に提示させる提示部と、
    　前記受付部によって、前記予約候補の中から前記ユーザによって選択された病院又は医師に対する予約要求が、前記通信ネットワークを介して前記要求元の前記ユーザ端末から受け付けられたとき、前記複数の病院それぞれに設けられ、患者の予約管理を行う病院制御部の内、前記受付部で受け付けた前記病院又は医師に該当する病院の前記病院制御部に、前記通信ネットワークを介して、前記要求元の前記ユーザ端末の前記ユーザの予約を依頼する予約部と、
    　を具備する、サーバ装置。
PCT/JP2019/026079 2018-07-24 2019-07-01 病院予約システム及びサーバ装置 Ceased WO2020021973A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018-138465 2018-07-24
JP2018138465A JP7131164B2 (ja) 2018-07-24 2018-07-24 病院予約システム及びサーバ装置

Publications (1)

Publication Number Publication Date
WO2020021973A1 true WO2020021973A1 (ja) 2020-01-30

Family

ID=69181640

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/026079 Ceased WO2020021973A1 (ja) 2018-07-24 2019-07-01 病院予約システム及びサーバ装置

Country Status (2)

Country Link
JP (1) JP7131164B2 (ja)
WO (1) WO2020021973A1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113241162A (zh) * 2021-05-11 2021-08-10 海南益丰互联网医院有限公司 一种互联网医院管理平台
WO2021199146A1 (ja) * 2020-03-30 2021-10-07 株式会社Ｐｅｃｏ 予約受付システム、プログラムおよび方法
CN115641946A (zh) * 2022-09-29 2023-01-24 江苏省计算机技术服务有限公司 基于大数据的智慧医疗管理系统及方法
WO2023155437A1 (zh) * 2022-02-15 2023-08-24 康键信息技术（深圳）有限公司 基于在线问诊的数据处理方法、装置和计算机设备
CN116646065A (zh) * 2023-05-25 2023-08-25 浙江蕙康科技有限公司 互联网医院数据安全管理方法和装置
US20240404681A1 (en) * 2023-05-31 2024-12-05 Lee Memorial Health System System, method, and computer program product for displaying and identifying actions for medical providers

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7287613B2 (ja) * 2020-05-21 2023-06-06 株式会社eBase Solutions Laboratory 支援サーバ、患者向けコンピュータプログラム及びサービス支援方法
JP7005086B1 (ja) * 2020-06-12 2022-02-14 株式会社Peco 動物患者用待ち時間提供システム、動物患者用待ち時間提供方法、プログラム
KR102234025B1 (ko) * 2020-07-10 2021-03-31 진수진 전세계 통합 헬스케어 서비스 제공 시스템
JP7117688B1 (ja) * 2021-02-02 2022-08-15 株式会社iCARE 健康診断予約管理システム、健康診断管理方法及びプログラム
KR102382541B1 (ko) * 2021-07-15 2022-04-08 주식회사 에이더블유시스템즈 고객 정보를 처리하는 방법 및 디바이스
KR20230172367A (ko) 2022-06-14 2023-12-22 연세대학교 산학협력단 건강 기록에 기반한 생체 정보의 가용성 및 우선 순위 판단 장치 및 그 방법
KR102953151B1 (ko) 2023-05-18 2026-04-15 인제대학교 산학협력단 개인 맞춤형 인공지능 의료 검사 및 진료 예약 시스템 및 방법

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003303238A (ja) * 2002-04-09 2003-10-24 Oki Electric Ind Co Ltd 病院選択支援サービス提供システム
JP2004355275A (ja) * 2003-05-28 2004-12-16 Nippon Telegr & Teleph Corp <Ntt> 救急医療用車載装置、医療機関装置および救急医療機関検索システム
JP2005196510A (ja) * 2004-01-08 2005-07-21 Hitachi Ltd 医療機関検索システム
JP2018112941A (ja) * 2017-01-12 2018-07-19 株式会社ＩｎｔｅｒＭｅｄ 医療検索プログラム及びそのシステム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003303238A (ja) * 2002-04-09 2003-10-24 Oki Electric Ind Co Ltd 病院選択支援サービス提供システム
JP2004355275A (ja) * 2003-05-28 2004-12-16 Nippon Telegr & Teleph Corp <Ntt> 救急医療用車載装置、医療機関装置および救急医療機関検索システム
JP2005196510A (ja) * 2004-01-08 2005-07-21 Hitachi Ltd 医療機関検索システム
JP2018112941A (ja) * 2017-01-12 2018-07-19 株式会社ＩｎｔｅｒＭｅｄ 医療検索プログラム及びそのシステム

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021199146A1 (ja) * 2020-03-30 2021-10-07 株式会社Ｐｅｃｏ 予約受付システム、プログラムおよび方法
JPWO2021199146A1 (ja) * 2020-03-30 2021-10-07
JP7093594B2 (ja) 2020-03-30 2022-06-30 株式会社Peco 予約受付システム、プログラムおよび方法
CN113241162A (zh) * 2021-05-11 2021-08-10 海南益丰互联网医院有限公司 一种互联网医院管理平台
CN113241162B (zh) * 2021-05-11 2022-03-08 海南益丰互联网医院有限公司 一种互联网医院管理平台
WO2023155437A1 (zh) * 2022-02-15 2023-08-24 康键信息技术（深圳）有限公司 基于在线问诊的数据处理方法、装置和计算机设备
CN115641946A (zh) * 2022-09-29 2023-01-24 江苏省计算机技术服务有限公司 基于大数据的智慧医疗管理系统及方法
CN115641946B (zh) * 2022-09-29 2023-10-31 江苏省计算机技术服务有限公司 基于大数据的智慧医疗管理系统及方法
CN116646065A (zh) * 2023-05-25 2023-08-25 浙江蕙康科技有限公司 互联网医院数据安全管理方法和装置
CN116646065B (zh) * 2023-05-25 2024-03-19 浙江蕙康科技有限公司 互联网医院数据安全管理方法和装置
US20240404681A1 (en) * 2023-05-31 2024-12-05 Lee Memorial Health System System, method, and computer program product for displaying and identifying actions for medical providers

Also Published As

Publication number Publication date
JP2020016994A (ja) 2020-01-30
JP7131164B2 (ja) 2022-09-06

Similar Documents

Publication Publication Date Title
JP7131164B2 (ja) 病院予約システム及びサーバ装置
JP5669250B2 (ja) 情報アクセス制御システムとそのサーバ装置及び情報アクセス制御方法
JP2020080126A (ja) 評価システム、情報処理装置、評価方法及びコンピュータプログラム
JP2017079065A (ja) 医療機関マッチングシステム
JPH09135816A (ja) 広域医療情報システム
JP6132639B2 (ja) 健康情報利用システム及びそれに用いるプログラム
KR20170043273A (ko) 통신망을 이용한 원격 헬스케어 시스템 및 방법
JP2020016995A (ja) 医療評価システム及びサーバ装置
KR20190006754A (ko) 가족 관리 기능을 구비한 병원 예약시스템
JP6592321B2 (ja) 診診連携方法および診診連携用コンピュータプログラム
KR20130014884A (ko) 진료 일정 관리 방법과 이를 이용한 진료 예약 시스템
KR101919236B1 (ko) 스마트 요양간호를 지원하는 시스템 및 방법
JP2020016993A (ja) 医療評価システム及びサーバ装置
JP2001265877A (ja) 検査予約サービス方法、検査・診断画像データサービス方法、検査データ解析処理サービス方法、画像・検査データサービス方法
JP2020052457A (ja) 利用者情報管理システム、利用者情報管理装置、権限管理装置、利用者端末装置、コンピュータプログラム、利用者情報管理方法及びシステムの構築方法
WO2001097111A1 (en) Second opinion acquisition assisting system and second opinion acquiring method
JP2015103231A (ja) 医療モール管理システム
JP6100668B2 (ja) 医療管理装置、医療管理装置の制御方法、及びプログラム
JP2018112941A (ja) 医療検索プログラム及びそのシステム
JP2001299767A (ja) アレルギー疾患情報処理システム、アレルギー疾患情報処理方法およびその方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体
EP4443443A1 (en) Process and system for connecting a patient and a specialist based on a pathology
JP2003203117A (ja) 診療予約システム、診療予約方法、コンピュータ装置、端末装置、およびコンピュータプログラム
JPH11306261A (ja) 患者情報共有システム
KR20170062130A (ko) 한의학 3d 인체 모델을 이용한 원격 의료 지원 방법 및 시스템
KR100614033B1 (ko) 온라인 의료정보 제공 시스템 및 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19840168

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19840168

Country of ref document: EP

Kind code of ref document: A1