Request support method and program

Abstract

To enhance secrecy of information in an online request.SOLUTION: A request support method via the internet is configured to: receive a request from a client to implement settlement; prepare a storage area securely storing request information high in secrecy including data serving as an objective of the request on the Internet; give the client an access right to the storage area to notify the client of an address of the storage area; store the request information in the storage area; give a contractor receiving the request the access right to the storage area; notify the contractor an address of the storage area; notify the contractor of the request information; store, by the contractor, deliverables to the request in the storage area; implement transferring to the contractor; and notify the client of the deliverables. The settlement is configured to: manage the number of requests the client orders during a prescribed period; and send, to the client, a bill of a sum of request amounts the client orders during the prescribed period. The settlement is configured to: manage the number of requests the contractor receives during the prescribed period; and transfer, to the contractor, the sum of the request amounts the contractor receives during the prescribed period.SELECTED DRAWING: Figure 37

Description

[Technical field]

[0001] The present disclosure relates to a request support method and program. [Background technology]

[0002] With the development of X-ray technology and the advancement and spread of technologies such as CT (Computed Tomography), MRI (Magnetic Resonance Imaging), and PET (Positron Emission Tomography), the burden on doctors (hereinafter also referred to as clinicians) who clinically diagnose patients based on images taken with these medical testing devices (hereinafter referred to as medical images) has increased.

[0003] In light of this situation, in recent years, there has been an increase in cases where clinicians request specialized doctors (hereinafter referred to as image interpreters) to interpret medical images in order to reduce their own burden and make more accurate diagnoses.

[0004] Usually, when a clinician who directly diagnoses a patient or a medical institution to which the clinician belongs (hereinafter collectively referred to as the client) requests an image interpretation from a radiologist or an image interpretation specialist company (hereinafter collectively referred to as the contractor), the patient's personal information such as age, gender, medical history, etc. is provided to the contractor along with the medical images. Therefore, in the past, in consideration of the confidentiality of the information, a dedicated line was used to connect the client and the contractor, and information was exchanged via this dedicated line. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2023-102155 A [Patent Document 2] JP 2023-114242 A Summary of the Invention [Problem to be solved by the invention]

[0006] In the past, when a novel, manga, or music (hereinafter referred to as a work) was to be proofread or edited, the author would save the work on a storage medium such as a CD (Compact Disc)-ROM (Read Only Memory) or USB (Universal Serial Bus) memory, and deliver the storage medium to the editor directly or by mail, or send it as an attachment to an email, etc. However, this method had the problem that the unpublished work could be lost or unintentionally made public due to the storage medium being lost or stolen, or leaked through an email, etc.

[0007] In recent years, so-called online lessons, in which lessons or coaching in sports, music, etc., as described above, are conducted using video calls, etc., have begun to become popular. However, online lessons have the problem of binding teachers and students for the same amount of time. Therefore, there is an increasing demand for so-called offline lessons, in which students send videos of themselves demonstrating sports or music, or paintings or calligraphy they have created, or copies or photos of such, to their teachers, and receive lessons or coaching from the teachers who have viewed these later. However, offline lessons have the problem that, like requests for proofreading or editing of works, things that the student does not want to be made public may be unintentionally made public due to loss or theft of storage media, or leaks from emails.

[0008] Therefore, the present disclosure has been made in consideration of the above problems, and aims to provide a request support method and program that can increase the confidentiality of information in offline requests. [Means for solving the problem]

[0009] A request support method according to one embodiment of the present disclosure is a request support method for making a request to an external expert via an open internet, comprising the steps of: accepting the request from a requester; executing a payment by the requester for the request; creating a storage area on the internet for securely storing highly confidential request information including data that is the subject of the request; granting the requester access rights to the storage area; notifying the requester of an address for accessing the storage area; storing the request information uploaded by the requester in the storage area; granting the access rights to the storage area to a contractor who has accepted the request; notifying the contractor of the address for accessing the storage area; downloading information to the contractor in response to a request from the contractor, storing a deliverable for the request uploaded by the contractor in the storage area, executing a transfer to the contractor who uploaded the deliverable, and downloading the deliverable in the storage area to the client in response to a request from the client, the settlement includes managing the number of one or more requests placed by the client within a specified period and invoice the client for the amount of the one or more requests placed by the client within the specified period, and the transfer includes managing the number of one or more requests received by the contractor within a specified period and transferring the amount of the one or more requests received by the contractor within the specified period to the contractor.

[0010] Another remote support method according to an embodiment of the present disclosure is a request support method for making a request to an external expert via an open Internet, comprising the steps of: accepting the request from a requester; executing a payment by the requester for the request; creating a storage area on the Internet for securely storing highly confidential request information including data that is the subject of the request; granting the requester access to the storage area; notifying the requester of an address for accessing the storage area; storing the request information uploaded by the requester in the storage area; determining a priority order of a plurality of order-receiving candidates; The method includes notifying order candidates in order of the receipt of the request, determining the first order candidate who accepts the order as the contractor who has accepted the request, granting the contractor access rights to the storage area, notifying the contractor of the address for accessing the storage area, downloading the request information in the storage area to the contractor in response to a request from the contractor, storing a deliverable for the request uploaded by the contractor in the storage area, executing a transfer to the contractor who uploaded the deliverable, and downloading the deliverable from the storage area to the client in response to a request from the client.

[0011] A program according to an embodiment of the present disclosure is a program for causing a processor to function for making a request to an external expert via the open Internet, the program including a process for accepting the request from a requester, a process for the requester to execute a payment for the request, a process for creating a storage area on the Internet for securely storing highly confidential request information including data that is the subject of the request, a process for granting access rights to the storage area to the requester, a process for notifying the requester of an address for accessing the storage area, a process for storing the request information uploaded by the requester in the storage area, a process for granting access rights to the storage area to a contractor who has received the request, a process for notifying the contractor of the address for accessing the storage area, and a process for storing the request information in the storage area in the storage area. The method has the processor execute a process of downloading the deliverables in the storage area to a client in response to a request from the client, a process of storing in the storage area a deliverable for the request uploaded by the client, a process of making a transfer to the client who uploaded the deliverables, and a process of downloading the deliverables in the storage area to the client in response to a request from the client, the process of executing settlement has the processor execute managing the number of one or more requests placed by the client within a specified period, and invoicing the client all together for the amounts of the one or more requests placed by the client within the specified period, and the process of executing transfer has the processor execute managing the number of one or more requests received by the client within a specified period, and transferring the amounts of the one or more requests received by the contractor all together to the contractor within the specified period.

[0012] Another program according to an embodiment of the present disclosure is a program for causing a processor to function for making a request to an external expert via the open Internet, the program including a process for accepting the request from a requester, a process for the requester to execute a payment for the request, a process for creating a storage area on the Internet for securely storing highly confidential request information including the data to be the target of the request, a process for granting the requester access rights to the storage area, a process for notifying the requester of an address for accessing the storage area, a process for storing the request information uploaded by the requester in the storage area, a process for determining the priority order of a plurality of order-receiving candidates, and a process for determining the priority order of the requester. The processor is caused to execute the following processes: notifying the order candidates in order that the request has been received; determining the first order candidate who approves the order as the contractor who has received the request; granting the contractor access rights to the storage area; notifying the contractor of the address for accessing the storage area; downloading the request information in the storage area to the contractor in response to a request from the contractor; storing a deliverable for the request uploaded by the contractor in the storage area; transferring money to the contractor who uploaded the deliverable; and downloading the deliverable in the storage area to the client in response to a request from the client. [Brief description of the drawings]

[0013] [Figure 1] 1 is a schematic diagram showing an example of a schematic configuration of a remote image diagnosis total support system for realizing a remote image diagnosis total support service according to a first embodiment of the present disclosure. [Diagram 2] 2 is a functional block diagram showing a schematic configuration example of an order management server according to the first embodiment of the present disclosure. FIG. [Diagram 3] FIG. 4 is a diagram illustrating an example of a request management table according to the first embodiment of the present disclosure. [Figure 4] 2 is a functional block diagram illustrating a schematic configuration example of an information storage server according to the first embodiment of the present disclosure. FIG. [Diagram 5]2 is a functional block diagram illustrating a schematic configuration example of a payment server according to the first embodiment of the present disclosure. FIG. [Figure 6] 2 is a functional block diagram illustrating a schematic configuration example of a user management server according to the first embodiment of the present disclosure. FIG. [Figure 7] 2 is a diagram showing an example of items managed in a client DB according to the first embodiment of the present disclosure; FIG. [Figure 8] A figure showing examples of items managed in a contractor DB according to the first embodiment of the present disclosure. [Figure 9] 1 is a sequence diagram showing an example of an operation of the remote image diagnosis comprehensive support system according to the first embodiment of the present disclosure (part 1). FIG. [Figure 10] FIG. 2 is a sequence diagram showing an example of the operation of the remote image diagnosis comprehensive support system according to the first embodiment of the present disclosure (part 2). [Figure 11] FIG. 3 is a sequence diagram showing an example of the operation of the remote image diagnosis comprehensive support system according to the first embodiment of the present disclosure (part 3). [Figure 12] FIG. 4 is a sequence diagram showing an example of the operation of the remote image diagnosis comprehensive support system according to the first embodiment of the present disclosure (part 4). [Figure 13] FIG. 5 is a sequence diagram showing an example of the operation of the remote image diagnosis comprehensive support system according to the first embodiment of the present disclosure (part 5). [Figure 14] FIG. 6 is a sequence diagram showing an example of the operation of the remote image diagnosis comprehensive support system according to the first embodiment of the present disclosure (part 6). [Figure 15] FIG. 11 is a diagram showing an example of a request plan selection screen according to the first embodiment of the present disclosure. [Figure 16] FIG. 4 is a diagram showing an example of a login screen according to the first embodiment of the present disclosure. [Figure 17] FIG. 2 is a diagram showing an example of a new client registration screen according to the first embodiment of the present disclosure. [Figure 18] FIG. 11 is a diagram showing an example of an image reading request registration screen for diagnostic purposes according to the first embodiment of the present disclosure. [Figure 19]FIG. 13 is a diagram showing an example of an image reading request registration screen for research purposes according to the first embodiment of the present disclosure. [Figure 20] FIG. 13 is a diagram showing an example of an image reading request registration screen for verification purposes according to the first embodiment of the present disclosure. [Figure 21] FIG. 1 is a diagram showing an example of request information according to the first embodiment of the present disclosure (part 1). [Figure 22] FIG. 2 is a diagram showing an example of request information according to the first embodiment of the present disclosure (part 2). [Figure 23] FIG. 2 is a diagram showing an example of a registration information management screen according to the first embodiment of the present disclosure. [Figure 24] FIG. 13 is a diagram showing an example of a request summary confirmation screen according to the first embodiment of the present disclosure. [Diagram 25] FIG. 1 is a diagram showing an example of an image interpretation report according to the first embodiment of the present disclosure (part 1). [Figure 26] FIG. 2 is a diagram showing an example of an image interpretation report according to the first embodiment of the present disclosure (part 2). [Figure 27] FIG. 3 is a diagram showing an example of an image interpretation report according to the first embodiment of the present disclosure (part 3). [Figure 28] FIG. 11 is a diagram showing another example of the radiology report according to the first embodiment of the present disclosure (part 1). [Figure 29] FIG. 2 is a diagram showing another example of the radiology report according to the first embodiment of the present disclosure (part 2). [Diagram 30] FIG. 11 is a diagram showing another example of the image interpretation report according to the first embodiment of the present disclosure (part 3). [Diagram 31] FIG. 4 is a diagram showing another example of the radiology report according to the first embodiment of the present disclosure (part 4). [Diagram 32] FIG. 5 is a diagram showing another example of the radiology report according to the first embodiment of the present disclosure. [Diagram 33] FIG. 6 is a diagram showing another example of the radiology report according to the first embodiment of the present disclosure. [Diagram 34]11 is a schematic diagram showing an example of a schematic configuration of a remote image diagnosis total support system for realizing a remote image diagnosis total support service according to a second embodiment of the present disclosure. FIG. [Diagram 35] FIG. 11 is a sequence diagram showing an example of the operation of the remote image diagnosis comprehensive support system according to the second embodiment of the present disclosure. [Diagram 36] FIG. 11 is a sequence diagram showing an example of an operation of a remote image diagnosis comprehensive support system according to a modified example of the second embodiment of the present disclosure. [Figure 37] FIG. 11 is a diagram illustrating a schematic configuration example of a request support system for realizing a request support service according to a third embodiment of the present disclosure. [Figure 38] FIG. 2 is a block diagram showing a schematic configuration example of each information processing device according to each embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Hereinafter, the remote image diagnosis total support device, the remote image diagnosis total support method, and the program according to the present disclosure will be described in detail with reference to several exemplary embodiments.

[0015] <First embodiment> First, a first embodiment of the present disclosure will be described in detail with reference to the drawings. In this embodiment, a remote image diagnosis comprehensive support system that supports a clinician (which may include other doctors such as a pathologist, an internist, or a surgeon) or a medical institution (hereinafter also referred to as a requester) in requesting image interpretation from an image interpretation doctor or a company (hereinafter also referred to as a contractor) that provides a remote image diagnosis support service will be described as an example.

[0016] In addition, a specific contract for requesting and receiving an order for image interpretation may or may not exist between the requester and the recipient. For example, a requester such as a clinician or a medical institution may request image interpretation for each case from an unspecified image interpretation doctor or image interpretation specialist company with whom they have not entered into a specific contract, or from a specific image interpretation doctor or image interpretation specialist company with whom they have entered into a specific contract, or may request image interpretation for a set number of cases periodically (for example, once a week). In other words, this embodiment can be applied to a system that mediates between the requester and the recipient, regardless of the contents of the contract exchanged between the requester and the recipient.

[0017] In addition, the purposes of interpreting medical images include diagnosing patients, conducting research in research institutions, and verifying evidence when medical trouble occurs or during a judicial autopsy. In this embodiment, for the sake of simplicity, we will take the example of diagnosing patients.

[0018] In this embodiment, a case is exemplified in which one or more requesters request interpretation of medical images from one contractor. For clarification, the following will be exemplified as an example in which the contractor is an individual radiologist. The requester may be an individual doctor who directly diagnoses the patient or his / her assistant staff, or a medical institution such as a hospital or research institute to which the doctor belongs. For clarification, the following will be exemplified as an example in which the contractor is a medical institution.

[0019] Here, the "medical image" may be various image data or video data acquired by a medical examination device, such as an X-ray image (X-ray image), a CT image, a PET-CT image, an MRI image, an echo image, an endoscopic image, an electrocardiogram, or a pathological image. However, the medical image according to the present embodiment is not limited to this, and may include various image data and video data used by a doctor for diagnosis. In addition, as a data format of the medical image, the following embodiment exemplifies the DICOM (Digital Imaging and Communication in Medicine) format. However, the medical image is not limited to this, and may be in various data formats such as still images and videos, such as JPEG, TIFF, GIF, BMP, and MP4.

[0020] (System Configuration) First, a schematic configuration example of a remote image diagnosis comprehensive support system according to the present embodiment will be described in detail with reference to the drawings.

[0021] ·Remote image diagnosis comprehensive support system 1 FIG. 1 is a schematic diagram showing an example of a schematic configuration of a remote image diagnosis total support system for realizing a remote image diagnosis total support service according to the present embodiment. As shown in FIG. 1, the remote image diagnosis total support system 1 has a configuration in which various servers 110, 120, 130, and 140 constituting a service providing site 100, a requester client 210 installed in a medical institution 200, and a contractor client 310 owned by an image interpretation doctor 300 are connected to each other so as to be able to communicate with each other via a network 400. Here, one or more of the various servers 110, 120, 130, and 140 constituting the service providing site 100 may constitute a remote image diagnosis total support device according to the present embodiment. In addition, the network 400 may be a wide-area network such as the Internet or a mobile communication system, a limited network such as a LAN (Local Area Network) or a WAN (Wide Area Network), or a network in which these are combined.

[0022] Medical institution 200 and requester client 210 The requester client 210 may be, for example, a desktop type, a notebook type, a tablet type, or any other type of personal computer (hereinafter, also simply referred to as a PC) introduced in a medical institution 200 such as a hospital or a research institute. The requester client 210 has, for example, a communication function for connecting to a network 400 via a LAN constructed in the medical institution 200, and a web browser function for browsing web pages published on the network 400 by the service providing site 100 or the like. Doctors and their assistant staff belonging to the medical institution 200 access the service providing site 100 from the requester client 210 to request interpretation of medical images from an outside source (for example, a radiological interpretation doctor 300 located in a remote location) and obtain an interpretation report created by the requested radiological interpretation doctor 300. The medical images may be medical images acquired by a medical examination device installed in the medical institution 200, or may be medical images acquired by a medical examination device installed in an external medical institution, research institute, or the like.

[0023] Image interpretation doctor 300 and order-receiving client 310 The contractor client 310 may be, for example, various types of PCs, such as desktop type, notebook type, tablet type, etc., installed in the workplace or home of the image interpretation doctor 300 (hereinafter referred to as the workplace). The contractor client 310 has, for example, a communication function for connecting to the network 400 via a LAN constructed in the workplace, and a web browser function for browsing web pages published on the network 400 by the service providing site 100 or the like. The image interpretation doctor 300 receives a request registered in the service providing site 100 by accessing the service providing site 100 from the contractor client 310, and acquires medical images to be interpreted. Then, the image interpretation doctor 300 interprets the acquired medical images, and stores the image interpretation report created as a result in the service providing site 100.

[0024] ··100 service providers The service providing site 100 may be composed of, for example, an order management server 110, an information storage server 120, a payment server 130, and a user management server 140. As shown in FIG. 1, the service providing site 100 may be composed of a plurality of servers (including a cloud server), or may be composed of a single server or two or more servers in which at least two of the servers 110, 120, 130, and 140 are integrated. The service providing site 100 may be a dedicated EC site (also called a company's own EC site) constructed for the purpose of providing the remote image diagnosis comprehensive support service according to the present embodiment, or may be a mall-type EC site that can be used by unspecified users for various purposes. For such a service providing site 100, an existing EC (Electronic Commerce) site such as Shopify (registered trademark) may be used. In that case, by using an EC site that provides not only ordering / receiving services but also payment services, it is possible to simplify the effort required of the requester and the recipient.

[0025] Order management server 110 Fig. 2 is a functional block diagram showing an example of the schematic configuration of the order management server according to this embodiment. As shown in Fig. 2, the order management server 110 includes a request reception unit 111, a request management unit 112, a payment processing request unit 113, a storage area creation request unit 114, and an information storage notification unit 115, and manages requests for interpretation from a requesting medical institution 200 and orders of requests from an image interpretation doctor 300 using a request management table 116, which will be described later.

[0026] The request receiving unit 111 receives a request from a requester (in this example, a medical institution 200).

[0027] The request management unit 112 registers the requests received by the request receiving unit 111 in a request management table 116 and manages them.

[0028] The settlement process request unit 113 requests the settlement server 130, which will be described later, to execute a payment process (settlement) by the client and a transfer process to the contractor for each request.

[0029] When a request is received from a client, the storage area creation request unit 114 requests the information storage server 120 to create a dedicated storage area.

[0030] When information is stored in a storage area (see storage area 125 in FIG. 4) secured in the information storage server 120, the information storage notification unit 115 notifies the requester and / or the order recipient of this fact.

[0031] 3 is a diagram showing an example of a request management table according to the present embodiment. As shown in Fig. 3, in the request management table 116, for example, a request ID, a requester ID, basic request information, and a contractor ID are managed in association with each other.

[0032] The request ID is identification information for uniquely identifying a request, and may be a value given by the order management server 110 each time a request is registered by a requester (the medical institution 200 in this example).

[0033] The requester ID may be identification information for uniquely identifying the requester. This requester ID may be a value that is assigned to the requester (the medical institution 200 in this example) by the user management server 140 described later when the requester is newly registered (including pre-registration) in the requester database (DB). Note that this requester ID may be a value used as an access ID (also called a login ID) when the requester accesses a storage area (see the storage area 125 in FIG. 4 and the registration information management screen shown in FIG. 23) described later.

[0034] The request basic information, which will be described later, may include information such as the name of the requesting medical institution 200 (if the requesting medical institution is an individual doctor, the name), the medical department that will diagnose the medical image to be interpreted (in other words, the medical department that the patient is visiting), the requesting doctor, the patient's age, the patient's sex, the modality, and the request date and time. In addition, the request basic information may include the patient's name, the patient's ID, the patient's date of birth, the clinical course, and the points that the requesting medical institution wants to have interpreted in particular. However, since at least the patient's name, the patient's ID, the patient's date of birth, the clinical course, and the points that the requesting medical institution wants to have interpreted in particular are information that may correspond to the patient's personal information, they may be encrypted and registered in the request management table 116. In this case, the items to be encrypted may include at least one of the name of the medical institution 200 (if the requesting medical institution is an individual doctor, the name), the medical department that will diagnose the medical image to be interpreted (in other words, the medical department that the patient is visiting), the requesting doctor, the patient's age, the patient's sex, the modality, the request date and time, the request ID, the requester ID, and the contractor ID.

[0035] The contractor ID may be identification information for uniquely identifying the contractor. This client ID may be a value that is assigned to the contractor (the image interpretation doctor 300 in this example) by the user management server 140 described later when the contractor is newly registered (including pre-registration) in the contractor DB. The contractor ID may be left blank (Null) if the contractor is undecided. The client ID may be a value used as an access ID (also called a login ID) when the contractor accesses a storage area (a registration information management screen shown in FIG. 23) described later.

[0036] Information storage server 120 Fig. 4 is a functional block diagram showing a schematic configuration example of the information storage server according to this embodiment. As shown in Fig. 4, the information storage server 120 includes a storage area creation unit 121, an access right granting unit 122, a stored information management unit 123, and a storage unit 124, and stores various data such as medical images to be interpreted registered by a client and interpretation reports registered by a contractor as interpretation results of medical images.

[0037] When the storage area creation unit 121 accepts creation of a storage area from the order management server 110, it creates in the memory unit 124 a dedicated storage area (also called a data box or BOX) 125 associated with the request ID for each request.

[0038] The access right granting unit 122 grants access rights to the storage area 125 associated with the request ID to the requester (in this example, the medical institution 200) who made the request and the recipient (in this example, the radiology doctor 300) who accepted the request.

[0039] The storage information management unit 123 manages and executes the storage of various data such as medical images uploaded by a client (in this example, the medical institution 200) and various data such as image interpretation reports uploaded by a contractor (in this example, the image interpretation doctor 300) in the storage area 125, as well as the reading and downloading of various data such as medical images requested by the contractor and various data such as image interpretation reports requested by the client from the storage area 125.

[0040] Such information storage server 120 may be a server capable of securely storing information, such as cloud storage, and an existing cloud service or the like may be used for this information storage server 120.

[0041] Payment server 130 Fig. 5 is a functional block diagram showing an example of a schematic configuration of the payment server according to this embodiment. As shown in Fig. 5, the payment server 130 includes an information acquisition unit 131, a payment processing unit 132, and a receipt issuing unit 133, and manages and executes payment processing such as payment by the requester and remittance to the contractor. In addition, when the payment by the requester is completed, the receipt issuing unit 133 issues a receipt to the requester or the medical institution to which the requester belongs (medical institution 200 in this example). An existing payment site may be used for this payment server 130.

[0042] User management server 140 Fig. 6 is a functional block diagram showing a schematic configuration example of a user management server according to this embodiment. As shown in Fig. 6, the user management server 140 includes a user management unit 141, a client DB 142, a contractor DB 143, and a user authentication unit 144, and manages information about client and contractor, and performs login authentication of the client and / or contractor to this system.

[0043] For example, the user management server 140 manages information about requesters using a requester DB 142 as exemplified in Fig. 7, and manages information about contractors using a contractor DB 143 as exemplified in Fig. 8. The user management unit 141 performs processes such as registering, updating, and deleting information about requesters in the requester DB 142, registering, updating, and deleting information about contractors in the contractor DB 143, and notifying necessary information in response to requests from the order management server 110, the settlement server 130, etc.

[0044] In addition, the user authentication unit 144, for example, in response to a request from the order management server 110, performs authentication of a user (a requester and / or a contractor) who attempts to access the system, using information registered in the requester DB 142 or the contractor DB 143.

[0045] Information about potential clients who request image interpretation may be registered in advance in the user management server 140. By registering information about clients in advance, in other words, by making it a registration system for individuals or medical institutions who may be potential clients, it is possible not only to guarantee the identity of the client, but also to obtain benefits such as reducing the effort required for settlement (payment).

[0046] Similarly, information about contractors may be registered in advance in the user management server 140. By registering information about contractors in advance, in other words, by making it a registration system for potential contractors, not only can the identity of the contractor be guaranteed, but also merits such as reduced effort at the time of payment (transfer) can be obtained.

[0047] ····Client database (DB) Fig. 7 is a diagram showing an example of a requester DB managed by the user management server according to this embodiment. As shown in Fig. 7, in the requester DB 142, information such as a requester ID, password, medical institution, medical department, requesting doctor's name, contact information, payment information, request record, etc. is associated with each registered requester and managed.

[0048] The requester ID may be identification information for uniquely identifying the requester, as described above. This requester ID may be used as a login ID for logging in to this service.

[0049] The password may be a password set by the client, and may be information used for authentication when logging in to this service.

[0050] The medical institution may be the name of the medical institution to which the requesting doctor belongs (or identification information for uniquely identifying the medical institution).

[0051] The medical department may be information about the medical department to which the requesting physician belongs, or the medical department to which the interpretation is requested. For example, if the requesting clinician is a doctor belonging to the radiology department, the radiology department may be specified, and if the requesting clinician is a doctor belonging to the internal medicine department, the internal medicine department may be specified. In addition, if the requester has multiple medical departments, such as a general hospital, one or more medical departments that may be requested to interpret the images may be specified.

[0052] The name of the requesting physician may be information that identifies a natural person responsible for the request.

[0053] The contact information may be information required to contact the requester, such as the requester's address, telephone number, and email address.

[0054] The payment information may be information for the client to make a settlement (payment), such as information on a withdrawal account, credit card information, or information on an online payment service such as Paypay (registered trademark). By managing the client's payment information in advance at the service providing site 100, it is possible to eliminate the trouble and risk of inputting payment information for each request. Note that the payment information is not limited to one, and multiple pieces of payment information may be registered.

[0055] The request record may be information regarding the number of requests for image interpretation in the past for each field (for example, medical department).

[0056] ····Contractor database (DB) Fig. 8 is a diagram showing an example of a contractor DB managed by the user management server according to this embodiment. As shown in Fig. 8, in the contractor DB 143, information such as contractor ID, password, name, contact information, order field, order record, compatible medical image analysis software, and transfer destination information is associated and managed for each registered contractor.

[0057] The contractor ID may be identification information for uniquely identifying the contractor, as described above. This contractor ID may be used as a login ID for logging in to this service.

[0058] The password may be a password set by the client, and may be information used for authentication when logging in to this service.

[0059] The name may be the name of the contractor if the contractor is an individual, or the name of the organization if the contractor is an organization such as a company or corporation.

[0060] The contact information may be information required to contact the contractor, such as the contractor's address, telephone number, and email address.

[0061] The order field may be information about a field in which image interpretation can be accepted, such as a medical department. For example, if the image interpretation doctor 300 who is the recipient is a doctor who specializes in radiology, the radiology department may be specified, and if the doctor is an internal medicine doctor, the internal medicine department may be specified. In addition, if the recipient is capable of handling multiple medical departments, multiple medical departments may be specified.

[0062] The order record may be information regarding the number of orders received in the past for each field (e.g., medical department) for which orders for image interpretation have been received, the accuracy of image interpretation, etc. The accuracy of image interpretation may reflect the client's evaluation, etc.

[0063] The available medical image analysis software may be a list of medical image analysis software that can be used for image interpretation by the contractor, the image interpretation doctor 300. For example, if the image interpretation doctor 300 can use one or more of medical image analysis software such as OsiriX (registered trademark), DICOM Library, IMAIOS DICOM Viewer, PostDICOM, Voxelx, and FViewer, one or more available software may be listed.

[0064] The transfer destination information may be information for the contractor to receive payment (transfer), such as a bank account to which the transfer will be made or information on an online payment service. By managing the contractor's transfer destination information in advance at the service providing site 100, it is possible to eliminate the trouble and risk of inputting the transfer destination information for each order. Note that the transfer destination information is not limited to one, and multiple pieces of transfer destination information may be registered.

[0065] (Example of operation) Next, an example of the operation of the remote image diagnosis total support system 1 according to this embodiment will be described in detail with reference to the drawings. Fig. 9 to Fig. 14 are sequence diagrams showing an example of the operation of the remote image diagnosis total support system according to this embodiment.

[0066] 9, in this operation, the medical institution 200 first uses the requester client 210 to access a website (see the request plan selection screen shown in FIG. 15) provided by the order management server 110 of the service provider site 100, and selects a request plan prepared in advance at the service provider site 100 (steps S2101->S1101). The request plan may be a product prepared in advance by the service provider site 100 based on the rough type of the request (for example, the above-mentioned diagnostic purpose, research purpose, verification purpose, etc.), the fee, etc.

[0067] The types of request content may be categorized, for example, by purpose such as the above-mentioned diagnostic purpose, research purpose, verification purpose, etc., by medical department, by modality used to acquire the medical image, by data format of the medical image to be interpreted (DICOM, JPEG, TIFF, GIF, BMP, MP4, etc.), by application used for interpretation (OsiriX, DICOM Library, IMAIOS DICOM Viewer, PostDICOM, Voxelx, FViewer, etc.), based on other factors, or by categories combining two or more of these.

[0068] Furthermore, the fee for the request plan is not limited to one request, but may be a fee for packaging multiple requests, for example, five requests, or may be a fee for a period, for example, one month or one year. When the fee is per period, an upper limit on the number of requests per period (for example, 10 requests in January) may be set.

[0069] Here, the requested plan selection screen will be described with reference to Fig. 15. Fig. 15 is a diagram showing an example of the requested plan selection screen according to this embodiment. As shown in Fig. 15, the requested plan selection screen may display a list of one or more requested plans. Each requested plan is displayed as a selectable icon, and a requested plan may be selected by the requester performing an operation such as double-clicking on the icon of a desired requested plan.

[0070] In this way, when a request plan is selected, the request reception unit 111 of the order management server 110 displays a login screen (see FIG. 16) for logging in to the service on the web browser of the requester client 210, and requests the medical institution 200 to log in to the service (steps S1102→S2102). In response, the medical institution 200 inputs the login ID and password given to the medical institution 200 into the login screen using the requester client 210, and selects the "Login" button, thereby requesting login authentication from the order management server 110 (steps S2103→S1103).

[0071] As described above, the login ID may be the requester ID given to the medical institution 200 when it is registered as a requester. Alternatively, an email address may be used instead of the login ID. If the medical institution 200 is not registered as a requester in this service, the request receiving unit 111 of the order management server 110 may cause the requester client 210 to display a new requester registration screen as shown in Fig. 17 and have the medical institution 200 input necessary information, thereby registering the medical institution 200 as a requester in the requester DB 142.

[0072] Next, the request receiving unit 111 of the order management server 110 notifies the user management server 140 of the login information (login ID and password) entered by the medical institution 200, and requests authentication processing for the medical institution 200 (steps S1104->S1404). In response, the user authentication unit 144 of the user management server 140 compares the notified login information with the login information (login ID and password) registered in the requester DB 142, thereby authenticating whether or not the requester is a registered legitimate requester (step S1405).

[0073] Next, the user authentication unit 144 notifies the order management server 110 of the authentication result (step S1406→S1106). In response to this, if the user authentication is successful, the request receiving unit 111 of the order management server 110 permits the medical institution 200 (specifically, the requester client 210) to log in (step S1107→S2107). Note that if the login authentication fails in step S1405, a login request may be executed again (step S1102→2102).

[0074] When the requester client 210 is permitted to log in, a screen (see image reading request registration screen shown in FIG. 18) for inputting basic information on the request (basic request information) to the medical institution 200 is displayed on the requester client 210 as shown in FIG. 10, and the medical institution 200 registers the basic request information in accordance with the image reading request registration screen (steps S2108→S1108). The image reading request registration screen may be made public on the network 400 generated by the request receiving unit 111 of the order management server 110, for example.

[0075] Here, the basic request information registered by the medical institution 200 at the time of request will be described using an image reading request registration screen for inputting this basic request information. FIG. 18 is a diagram showing an example of an image reading request registration screen for diagnosis purposes according to this embodiment. As shown in FIG. 18, the image reading request registration screen has fields for inputting the name of the requesting medical institution (if the requesting medical institution is an individual doctor, the name of the requesting medical institution), the medical department, the name of the requesting doctor, the patient's name, the patient's ID, the patient's date of birth, the patient's age, the patient's sex, the modality, the clinical course, and points that the requesting medical institution wants to read in particular. The modality may be information on the type of medical examination device that obtained the medical image to be read. The modality may include information on the file format of the medical image. The request date and time may be automatically set when a predetermined action is performed by the requester (the medical institution 200 in this example), such as when the requester accesses the image reading request registration screen or when the request button is clicked.

[0076] However, since the patient name, patient ID, patient date of birth, clinical course, and specific points desired for interpretation may correspond to the patient's personal information, they may be configured to be registered in the image reading request form described below (see Figures 21 and 22) rather than on the image reading request registration screen.

[0077] Moreover, Fig. 19 shows an example of an image reading request registration screen for research purposes according to this embodiment, and Fig. 20 shows an example of an image reading request registration screen for verification purposes according to this embodiment. As shown in Fig. 19 and Fig. 20, the contents of the request basic information registered on the image reading request registration screen may differ for each purpose. In that case, the items managed in the request management table 116 exemplified in Fig. 3 may differ for each purpose.

[0078] The basic request information (including the request date and time) thus inputted on the image reading request registration screen is inputted as a character string to the order management server 110, and is registered and managed in a predetermined record of the request management table 116 by the request management unit 112 of the order management server 110. At that time, the request management unit 112 may generate a request ID and store it in the predetermined record. In addition, the requester ID may be inputted by a requester by providing an input field on the image reading request registration screen, or may be identified from the requester DB 142 managed by the user management server 140 based on the basic request information inputted on the image reading request doctor registration screen. Furthermore, the contractor ID may be left blank (Null) when the contractor is undecided, and may be identified from the contractor DB 143 managed by the user management server 140 after the contractor is decided.

[0079] Next, the settlement process request unit 113 of the order management server 110 accesses the user management server 140 based on the name of the medical institution 200, the medical department, the name of the requesting doctor, etc. included in the basic request information, and inquires about the requester information registered in advance in the requester DB 142 for the corresponding medical institution 200 (step S1109→S1409). In response to this, the user management unit 141 of the user management server 140 acquires the information about the requester of the corresponding medical institution 200 by referring to the requester DB 142 (see FIG. 7) based on the name of the medical institution 200, the medical department, the name of the requesting doctor, etc. notified by the order management server 110, and notifies the order management server 110 of the acquired information (step S1410→S1110).

[0080] In addition, if the requester, the medical institution 200, has not yet been registered in the requester DB 142 (for example, if it is the first request from the medical institution 200), a step may be added in which the order management server 110 provides the requester client 210 with a screen for registering information about the medical institution 200, notifies the user management server 140 of the information entered on this screen, and the user management section 141 of the user management server 140 newly registers the notified information in the requester DB 142.

[0081] Next, the payment processing request unit 113 of the order management server 110 requests the payment server 130 to perform payment processing for this request based on the payment information included in the information on the requester notified from the user management server 140 (steps S1111->S1311). At this time, the payment information may be notified from the order management server 110 to the payment server 130, or the information acquisition unit 131 of the payment server 130 may access the user management server 140 and acquire it.

[0082] Next, the payment processing unit 132 of the payment server 130 requests the medical institution 200 to make payment for this request by providing a payment screen to the requester client 210 (steps S1312->S2112). At this time, the order management server 110 may automatically switch the access destination of the requester client 210 to the payment server 130, thereby guiding the medical institution 200 to make payment smoothly.

[0083] Next, the medical institution 200 executes the payment for this request by inputting a predetermined operation according to the payment screen displayed on the web browser of the requester client 210 (step S2113→S1313). In this embodiment, payment information such as withdrawal account and credit card information is managed in advance at the service providing site 100, and the requester (the medical institution 200 in this example) can use this managed payment information for payment. This makes it possible to avoid the risk that would arise from having the requester input payment information every time a request is made, and to realize a safe transaction.

[0084] Next, when the receipt issuing unit 133 of the payment server 130 confirms the completion of the payment procedure by the medical institution 200, it issues a receipt for this request to the requester client 210 (step S1314). In response to this, the medical institution 200 can download (DL) the receipt from the payment server 130 using the requester client 210 as necessary (step S1315→S2115). Note that the receipt issued by the payment server 130 may be, for example, an electronic file such as a portable document format (PDF). In addition, the service providing site 100 may mail a paper receipt to the medical institution 200 upon request. Thereafter, the payment processing unit 132 of the payment server 130 notifies the order management server 110 that the payment procedure by the medical institution 200 has been completed (step S1316→S1116).

[0085] 11, the storage area creation request unit 114 of the order management server 110 requests the information storage server 120 to create (including reserve) a storage area 125 for securely storing information including highly confidential information such as the patient's name and date of birth, and medical images to be interpreted (steps S1117->S1217). At this time, the order management server 110 may notify the information storage server 120 of part of the information about the requester (for example, the requester ID, email address, etc.).

[0086] Next, the storage area creation unit 121 of the information storage server 120 creates (or secures) the storage area 125 accessible via the network 400 in the memory unit 124 (step S1218). Next, the access right granting unit 122 of the information storage server 120 grants the medical institution 200 the access right to the created (or secured) storage area 125 (step S1219). For example, when the information storage server 120 is a cloud storage, the information storage server 120 may create a data box accessible via the network 400 (see step S1218) and grant the medical institution 200 (which may be the requester client 210) the access right to the data box (see step S1219).

[0087] Next, the access right granting unit 122 of the information storage server 120 notifies the medical institution 200 of an address (e.g., URL (Uniform Resource Locator)) for accessing the created (or secured) storage area 125 via the network 400 (steps S1220->S2120). The information storage server 120 may notify the medical institution 200 of the storage destination address by e-mail or the like.

[0088] When the storage address is notified in this way, the medical institution 200 accesses the storage area 125 from the requester client 210 using the storage address, and uploads (UL) more detailed information on the request contents (hereinafter, also referred to as request information) to this storage area 125 (step S2121 → S1221). The request information may also include information such as an electronic medical record (for example, an electronic medical record output as a PDF). In addition, the request information may be encrypted with a randomly generated password when stored in the storage area 125. The encryption of the request information may be executed, for example, in the requester client 210, or may be executed in the stored information management unit 123 of the information storage server 120. The password used for encryption may be appropriately notified to the medical institution 200 that uploaded the request information and / or the radiology interpreter 300 who accepted the request. For example, the password may also be notified when the storage address is notified in steps S1131 → S3131 of FIG. 13 described later.

[0089] Here, the request information stored in the storage area 125 will be described in detail with reference to Fig. 21 and Fig. 22. Fig. 21 and Fig. 22 are diagrams showing an example of request information according to this embodiment. Note that, although Fig. 21 and Fig. 22 show an example of request information excluding medical images, the request information according to this embodiment may include medical images to be interpreted.

[0090] 21 and 22, the request information excluding medical images may be stored as a file entitled, for example, "image reading request form" in the storage area 125. This request information may include, for example, information such as "requester information," "patient information," "clinical progress," and "points particularly desired for image reading."

[0091] The "requester information" may include, for example, information such as the name of the medical institution 200, the medical department, the requesting doctor, and the date and time of the request. The "patient information" may include, for example, information related to the patient ID and modality, as well as information such as the patient's name, date of birth, age, and sex. Of the requester information and patient information, information included in the basic request information entered on the image reading request registration screen may be reused from this information.

[0092] In addition, the "clinical course" may be information regarding the medical treatment that has been performed on the patient up to now, and the "points that the requesting physician wishes the radiologist to specifically interpret" may be information regarding the points that the requesting physician wishes the radiologist to specifically interpret.

[0093] An image reading request form containing the above information may be stored in storage area 125 as a file saved in a document format such as a text file, Word file, or PDF, an image format such as JPEG, GIF, TIFF, or PNG, or a video format such as MP4.

[0094] The uploading of the request information to the storage area 125 may be performed, for example, via a registration information management screen provided by the stored information management unit 123 of the information storage server 120. Fig. 23 is a diagram showing an example of the registration information management screen according to this embodiment.

[0095] As shown in FIG. 23, the registration information management screen may be provided with, for example, a field for selecting a file to be uploaded to the secured storage area 125, an “Upload” button for uploading the selected file to the secured storage area 125, a field for displaying a list of files stored in the storage area 125, a “Download” button for individually downloading a file selected from the list, and a “Bulk Download” button for downloading all the files stored in the storage area 125 at once.

[0096] When uploading request information to the storage area 125 prepared for the medical institution 200, the medical institution 200 uses the web browser function of the requester client 210 to view the registration information management screen, selects the files to be uploaded (image reading request form, one or more medical images, audio files, etc.) on this registration information management screen, and clicks the "Upload" button. As a result, the selected files are uploaded to the information storage server 120 and stored in the specified storage area 125 by the stored information management unit 123.

[0097] Returning to the description of the operation, as described above, when the request information is stored in the storage area 125 in the memory unit 124, the stored information management unit 123 of the information storage server 120 notifies the order management server 110 that the request information has been stored, as shown in Fig. 12 (steps S1222 -> S1122).

[0098] Next, the information storage notification unit 115 of the order management server 110 inquires of the user management server 140 about the information of the image interpretation doctor who will be the contractor (information about the contractor) (step S1123→S1423). At that time, the information storage notification unit 115 notifies the user management server 140 of the request basic information or a part of the information. In response to this, the user management unit 141 of the user management server 140 refers to the contractor DB 143 based on the information notified by the order management server 110 at the time of the inquiry, thereby identifying the image interpretation doctor 300 who will be the contractor of this request (specifically, information about the contractor), and notifies the order management server 110 of at least the contact information (e.g., email address) of the identified information about the contractor (step S1424→S1124).

[0099] Next, the information storage notification unit 115 of the order management server 110 notifies the image interpretation doctor 300 (specifically, the contact address) notified by the user management server 140 that a request has been made (steps S1125->S3125). For example, when an e-mail address is notified from the user management server 140 to the order management server 110 as the contact address of the image interpretation doctor 300, the information storage notification unit 115 automatically sends an e-mail to that address to notify that a request has been made. For example, a URL may be attached to this e-mail to guide the image interpretation doctor 300, who is the order recipient, to a request summary confirmation screen (see FIG. 24) for confirming the summary of the request contents.

[0100] Here, Fig. 24 is a diagram showing an example of a request summary confirmation screen according to this embodiment. As shown in Fig. 24, the request summary confirmation screen may be provided with an area for displaying information (e.g., request basic information) for the contractor (radiography doctor 300 in this example) to understand the summary of the request, and a button for the contractor to select whether or not to accept the request. Such a request summary confirmation screen may be automatically generated in the information storage notification unit 115 of the order management server 110 when the medical institution 200 registers the request basic information using the requester client 210 (see steps S2108 to S1108).

[0101] The image interpretation doctor 300, who has been notified of the request, checks the request summary confirmation screen from the notified URL using the order-receiving party client 310 (steps S3126→S1126) and determines whether to accept the order. If accepting the order, the image interpretation doctor 300 approves the order by, for example, clicking the "Accept Order" button on the request summary confirmation screen (steps S3127→S1127). Note that if the image interpretation doctor 300 clicks the "Reject Order" button, the requester client 210 may be notified via the order management server 110 that the image interpretation doctor 300 did not accept the request.

[0102] When the radiologist 300 accepts the request, as shown in FIG. 13, the information storage notification unit 115 of the order management server 110 requests the information storage server 120 to grant the radiologist 300 access to the secured storage area 125 (step S1128→S1228). At that time, the information storage notification unit 115 notifies the information storage server 120 of at least the contractor ID among the information on the contractor. In response to this, the access right granting unit 122 of the information storage server 120 grants the radiologist 300 (e.g., the contractor ID assigned to the radiologist 300) access to the storage area 125 (step S1229), and notifies the order management server 110 that the access right has been granted (step S1230→S1130). At this time, the information storage server 120 may notify the order management server 110 again of the address (e.g., URL) of the storage area 125.

[0103] Next, the information storage notification unit 115 of the order management server 110 notifies the order-receiving client 310 of the image interpretation doctor 300 who has received the request of an address (e.g., URL) for accessing the storage area 125 via the network 400 as described above. At this time, if the request information is encrypted as described above, the password used for the encryption may also be notified.

[0104] Next, the image interpretation doctor 300 accesses the registration information management screen (see FIG. 23) from the notified URL using the contractor client 310 (steps S3132→S1232), and downloads (DL) the file (request information) stored in the storage area 125 (steps S3133→S1233). When the image interpretation doctor 300 accesses the registration information management screen (see FIG. 23) using the contractor client 310, login authentication processing may be performed using, for example, a contractor ID and a password, similar to the login authentication processing (steps S1102 to S2107) for the requester (the medical institution 200 in this example).

[0105] In this way, the image interpretation doctor 300 who has acquired the request information (image interpretation request form, one or more medical images, audio file, etc.) interprets one or more medical images according to the contents of the request and creates an image interpretation report (step S3134). Note that the information processing device used for interpretation of the medical images is not limited to the contractor client 310, and various information processing devices may be used.

[0106] Here, a specific example will be described of the image interpretation report created by the image interpretation doctor 300. Figures 25 to 27 and Figures 28 to 33 are diagrams showing examples of image interpretation reports according to this embodiment.

[0107] 25 to 27 and 28 to 33, the image interpretation report includes, for example, client information, patient information, clinical course, findings, and a summary. The client information, patient information, and clinical course may be quoted from the image interpretation request form. The findings may be prepared by the image interpretation doctor 300 as a result of interpreting the medical image based on the patient information and clinical course, and the summary may be prepared by the image interpretation doctor 300 as a result of an overall judgment including other information.

[0108] In addition, one or more medical images may be attached to the image interpretation report (especially the findings and summary) as necessary to facilitate understanding of the image interpretation report. The medical images may be edited with arrows, enclosures, coloring, or color coding to indicate areas noted during image interpretation, areas mentioned in findings, or summary, etc. Note that the medical images that have already been interpreted are not limited to being attached to the image interpretation report, and may be stored in the storage area 125 as a separate file, for example.

[0109] Returning to the description of the operation. As described above, when the image interpretation report is created, as shown in FIG. 14, the image interpretation doctor 300 accesses the registration information management screen (see FIG. 23) from the notified URL using the order receiving client 310, and uploads the created image interpretation report to the storage area 125 secured in the memory unit 124 of the information storage server 120 (step S3135→S1235). In response to this, the stored information management unit 1123 of the information storage server 120 notifies the order receiving management server 110 that the image interpretation report has been stored (step S1236→S1136). The image interpretation report may be encrypted with a randomly generated password when stored in the storage area 125. The image interpretation report may be encrypted, for example, in the order receiving client 310 or in the stored information management unit 123 of the information storage server 120. The password used for encryption may be appropriately notified to the image interpretation doctor 300 who uploaded the image interpretation report and / or the medical institution 200 who placed the request. For example, the password may be notified when notifying storage of the interpretation report in steps S1140 and S2140 in FIG. 14, which will be described later.

[0110] Next, the payment processing request unit 113 of the order management server 110 requests the payment server 130 to perform payment processing for the image interpretation doctor 300 (step S1137→S1337). At this time, the order management server 110 may notify the payment server 130 of the transfer destination information, or the payment server 130 may access the user management server 140 to obtain it. When the payment request is received from the order management server 110, the payment processing unit 132 of the payment server 130 executes the payment (transfer) processing of the amount set in this request according to the payment information (step S1338). Then, when the payment processing is completed, the payment processing unit 132 notifies the order management server 110 that the payment processing is completed (step S1339→S1139).

[0111] Furthermore, when the information storage notification unit 115 of the order management server 110 is notified by the information storage server 120 that the image interpretation report has been stored in the storage area 125 (see steps S1236->S1136), it notifies the medical institution 200 that the image interpretation report has been stored in the storage area 125 based on the contact information in the information about the client (steps S1140->S2140). At this time, if the image interpretation report has been encrypted as described above, the password used for this encryption may also be notified.

[0112] Next, the medical institution 200 accesses the registration information management screen (see FIG. 23) using the requester client 210 (steps S2141→S1241) and downloads the image interpretation report stored in the storage area 125 (steps S1242→S2142). As a result, the medical institution 200, which is the requester, obtains the image interpretation report for this request.

[0113] The above operations allow highly confidential information such as the patient's personal information and image interpretation reports to be exchanged between the requester (medical institution 200) and the orderee (radiography doctor 300) via the storage area 125 capable of securely storing information, thereby realizing a secure remote image diagnosis total support system 1 in which confidentiality of information is maintained. According to this embodiment, the service providing site 100 can consistently support the process from receiving the request to settlement and registering (delivering) the image interpretation report, thereby significantly reducing the hurdle for doctors to participate in medical practice as image interpretation doctors. As a result, it is possible to provide a remote image diagnosis total support device, a remote image diagnosis total support method, and a program that enable more doctors to participate in medical practice as image interpretation doctors.

[0114] Furthermore, according to this embodiment, by utilizing the order management service and settlement service provided by the service providing site 100, it is possible to significantly reduce the effort required for request / order processing and accounting processing for the requester and the recipient, and therefore it is possible to significantly reduce intermediate costs such as personnel expenses and management expenses. Furthermore, according to this embodiment, recipients such as the image interpretation doctor 300 can directly contract with the requesting medical institution 200 and receive requests, so it is possible to significantly reduce intermediate costs such as sales expenses.

[0115] In addition, conventionally, clinicians or medical institutions who wish to request a diagnosis are required to enter into a fixed-term contract with a specialized image interpretation company, paying an initial fee and monthly usage fee, and there was no on-demand service that allows them to request a diagnosis only when they wish to do so. Also, clinicians who request image interpretation would like to select an image interpretation doctor who is skilled in diagnosing difficult or complex cases, but due to issues such as an environment in which it is difficult for image interpretation doctors to freely enter the market and image interpretation companies having the right to assign work, there are cases where it is not possible to request the desired image interpretation doctor, making it difficult to make a diagnosis.

[0116] In contrast, according to this embodiment, the clinician, the medical institution 200 requesting the diagnosis, and the image interpretation doctor 300 can work on an on-demand basis, so that the diagnosis requesting side and the image interpretation side can operate freely. Even in this case, the accounting at the diagnosis requesting side and the image interpretation side can be automatically performed, so that the intermediate cost can be significantly reduced.

[0117] In this embodiment, the case where a fee is paid to the image-reading doctor 300 each time an image-reading report is stored in the storage area 125, that is, each time a request is received and fulfilled, is exemplified, but the payment of the fee to the image-reading doctor 300 is not limited to this form. For example, the order management server 110 may be configured to manage the number of orders for each image-reading doctor 300 and each plan for each predetermined period (e.g., one month), and pay the image-reading doctor 300 an amount according to the number of orders at or after the predetermined period has elapsed (e.g., at the end of the month).

[0118] In addition, in the present embodiment, an example has been given of a case in which the medical institution 200 bills for an amount according to a selected plan each time the medical institution 200 makes a request, but billing to the medical institution 200 is not limited to this form. For example, the order management server 110 may be configured to manage the number of requests for each medical institution 200 and each plan for each predetermined period (e.g., January), and bill the medical institution 200 for an amount according to the number of requests at or after the predetermined period has elapsed (e.g., at the end of the month, etc.).

[0119] (Modification of the first embodiment) In the above-mentioned first embodiment, the case where the contractor is an individual image interpretation doctor 300 is exemplified, but for example, when the contractor is a specialized image interpretation company that employs multiple image interpretation doctors, the work of assigning the received request to each image interpretation doctor occurs within the specialized image interpretation company. Therefore, in this modified example, an example of a configuration for automating the assignment of requests to each image interpretation doctor within the specialized image interpretation company will be described.

[0120] The automatic allocation of requests to each image-reading doctor may be performed, for example, by the contractor client 310. In this case, the contractor client 310 may manage information (also called image-reading doctor information) such as the identification number (also called image-reading doctor ID) of each image-reading doctor, medical department, specialty (head, chest, abdomen, etc.), image-reading record (the field and number of times of medical images read), specialty modality (X-ray, CT, PET-CT, MRI, etc.), and application used for image reading (OsiriX, DICOM Library, IMAIOS DICOM Viewer, PostDICOM, Voxelx, FViewer, etc.), and may automatically assign an appropriate image-reading doctor to each request based on the image-reading doctor information from the request information. For example, the contractor client 310 may assign requests in the order of image-reading doctor IDs consisting of numbers, may assign requests based on specialty, may assign requests based on specialty modality, or may assign requests based on two or more items in the image-reading doctor information.

[0121] The download of the request information from the service providing site 100 may be executed from the contractor client 310 of the image interpretation professional company, or may be executed from the client of the image interpretation doctor to which the request is assigned. When executed from the image interpretation doctor's client, the access right to the storage area 125 may be given to this client as well.

[0122] Similarly, the image interpretation company may upload the image interpretation report to the service provider site 100 from the contractor client 310 of the image interpretation company, or from the client of the image interpretation doctor to which the request is assigned. If the upload is from the client of the image interpretation doctor, the access right to the storage area 125 may also be granted to this client.

[0123] The other configurations, operations, and effects may be similar to those of the first embodiment described above, and therefore detailed description thereof will be omitted here.

[0124] <Second embodiment> Next, a second embodiment of the present disclosure will be described in detail with reference to the drawings. In the following description, for clarity, the differences from the remote image diagnosis comprehensive support system 1 according to the first embodiment will be focused on.

[0125] In this embodiment, a case where one or more clients request interpretation of medical images from multiple contractors is exemplified. In the following, as in the first embodiment, for clarity, a case where each of the multiple contractors is an individual image interpretation doctor and the contractor is a medical institution is exemplified.

[0126] (System Configuration) Fig. 34 is a schematic diagram showing an example of the schematic configuration of a remote image diagnosis total support system for realizing the remote image diagnosis total support service according to this embodiment. As is clear from comparing Fig. 34 with Fig. 1, the remote image diagnosis total support system 1 according to the first embodiment illustrates a case in which the relationship between the requester (e.g., medical institution 200) and the order-receiving party (e.g., image-reading doctor 300) is one-to-one, whereas the remote image diagnosis total support system 2 according to this embodiment illustrates a case in which the relationship between the requester (e.g., medical institution 200) and the order-receiving party (e.g., image-reading doctors 300A to 300C) is one-to-multiple.

[0127] The configurations of the various servers 110, 120, 130, and 140 constituting the service providing site 100 according to this embodiment and the requester client 210 of the medical institution 200 may be similar to those according to the first embodiment. Also, the configurations of the contractor clients 310A-310C of the image interpretation doctors 300A-300C according to this embodiment may be similar to the contractor client 310 of the image interpretation doctor 300 according to the first embodiment.

[0128] (Example of operation) Next, an example of the operation of the remote image diagnosis total support system 2 according to this embodiment will be described. Fig. 35 is a sequence diagram showing an example of the operation of the remote image diagnosis total support system according to this embodiment. In the following description, steps similar to those in the operation of the remote image diagnosis total support system 1 according to the first embodiment will be cited to omit redundant description. However, in the example of the operation of the remote image diagnosis total support system 2 according to this embodiment, the contractor client 310, which was one in the first embodiment, is replaced by multiple contractor clients 310A to 310C.

[0129] In this embodiment, first, the same operations as those described in the first embodiment with reference to Figures 9 to 11 are executed to store the request information in the storage area 125 secured in the memory unit 124 of the information storage server 120. Then, as shown in Figure 35, the stored information management unit 123 of the information storage server 120 notifies the order management server 110 that the request information has been stored (steps S1222 -> S1122).

[0130] Next, the information storage notification unit 115 of the order management server 110 inquires of the user management server 140 about information of one or more radiological doctors who are candidates for the order recipient (information about the order recipient) (step S1123-1→S1423-1). At that time, similar to step S1123→S1423 in FIG. 12, the information storage notification unit 115 notifies the user management server 140 of the request basic information or a part of the information. In response to this, the user management unit 141 of the user management server 140 refers to the order recipient DB 143 based on the information notified by the order management server 110 at the time of the inquiry, thereby identifying one or more radiological doctors 300A-300C who are candidates for the order recipient for this request (specifically, information about the order recipient), and notifies the order management server 110 of at least contact information (e.g., email address) of each of the information about the identified one or more order recipient candidates (step S1424-1→S1124-1).

[0131] Next, the information storage notification unit 115 of the order management server 110 notifies each of the one or more image interpretation doctors 300A-300C (specifically, their contact information) notified by the user management server 140 of the request (steps S1125→S3125A, S3125B, and S3125C). Note that the request summary confirmation screen to which each of the one or more image interpretation doctors 300A-300C is directed by the notification may be similar to the example shown in FIG.

[0132] Each of the one or more image interpretation doctors 300A-300C who have been notified of the request checks the request summary confirmation screen from the notified URL using the order-receiving party clients 310A-310C (steps S3126A→S1126A, S3126B→S1126B, and S3126C→S1126C) and determines whether to accept the order. If accepting the order, the image interpretation doctor (in this example, the image interpretation doctor 300A) accepts the order by, for example, clicking the "Accept Order" button on the request summary confirmation screen (steps S3127A→S1127A). Note that FIG. 35 illustrates a case where the image interpretation doctor 300A first accepts the order.

[0133] Next, the information storage notification unit 115 of the order management server 110 identifies the image interpretation doctor (in this case, the image interpretation doctor 300A) who first accepts the order from among one or more order acceptance candidates, and determines this image interpretation doctor 300A as the contractor (step S1127-1).Then, the information storage notification unit 115 notifies the image interpretation doctors 300B and 300C other than the image interpretation doctor 300A determined as the contractor that the contractor has been determined (step S1127-2→S3127B / S3127C).

[0134] In this manner, once one contractor is selected from one or more contractor candidates, in this embodiment, an operation similar to that described in the first embodiment using Figures 13 to 14 is performed, and the radiological report prepared by the radiological interpreter 300A is provided to the requesting medical institution 200 via a storage area 125 secured in the memory unit 124 of the information storage server 120.

[0135] As described above, according to this embodiment, even if there are multiple candidates for receiving an order, highly confidential information such as the patient's personal information and image interpretation reports can be exchanged between the requester (medical institution 200) and the contractor (radiography doctor 300A, 300B or 300C) via the storage area 125, which can store information securely, making it possible to realize a secure remote image diagnosis comprehensive support system 2 in which the confidentiality of information is maintained.

[0136] The other configurations, operations, and effects may be similar to those of the first embodiment, and therefore detailed description thereof will be omitted here.

[0137] (Modification of the second embodiment) Next, a modified example of the second embodiment, that is, another embodiment in which one requester has one or more order receiving candidates, will be described with reference to the drawings. The remote image diagnosis total support system according to this modified example may be similar to the remote image diagnosis total support system 2 illustrated in FIG. 34. However, in this modified example, the operation illustrated in FIG. 35 may be replaced with the operation illustrated in FIG. 36.

[0138] 36, in this embodiment, first, by executing the same operations as those described in the first embodiment using Figures 9 to 11, request information is stored in the storage area 125 secured in the memory unit 124 of the information storage server 120. Then, by executing the same operations as those described in the second embodiment using steps S1222 to S1124-1 of Figure 35, at least contact information (e.g., email address) of each of the information related to one or more radiological interpretation doctors 300A to 300C (specifically, information related to the contractor) who are candidates for receiving the current request is notified to the order management server 110.

[0139] Next, the information storage notification unit 115 of the order management server 110 determines the priority order for one or more image interpretation doctors 300A to 300C notified by the user management server 140 (step S1124-2). Note that the priority order may be determined by the information storage notification unit 115 based on, for example, the request contents, the order field, order record, and available medical image analysis software for each contractor managed in the contractor DB 143, or may be determined in advance and managed in the contractor DB 143.

[0140] When the priority order is determined, the information storage notification unit 115 first notifies the image interpretation doctor with the highest priority order (image interpretation doctor 300A in this example) that a request has been made (step S1125A-2→S3125A-2). Note that the request summary confirmation screen to which the image interpretation doctor 300A is directed by the notification may be the same as the example shown in FIG.

[0141] The image interpretation doctor 300A who has been notified of the request checks the request summary confirmation screen from the notified URL using the order-receiving party client 310A (step S3126A-2 → S1126A-2) and judges whether to accept the order. If the order is not accepted, the image interpretation doctor 300A notifies the order management server 110 that the order is not accepted by, for example, clicking the "Not accepting order" button on the request summary confirmation screen (step S3127A-2 → S1127A-2).

[0142] In this way, if the order-receiving candidate with the next highest priority refuses to accept the order, the information storage notification unit 115 of the order management server 110 notifies the image interpretation doctor with the next highest priority (image interpretation doctor 300B in this example) that there has been a request (step S1125B-2 → S3125B-2). In response to this, the image interpretation doctor 300B checks the request summary confirmation screen from the notified URL using the order-receiving client client 310B (step S3126B-2 → S1126B-2) and decides whether to accept the order, and if so, approves the order by clicking, for example, the "Accept Order" button on the request summary confirmation screen (step S3127B-2 → S1127B-2).

[0143] In this manner, once one contractor is selected from one or more contractor candidates, in this embodiment, an operation similar to that described in the first embodiment using Figures 13 to 14 is performed, and the radiological report prepared by the radiological interpreter 300B is provided to the requesting medical institution 200 via the storage area 125 secured in the memory unit 124 of the information storage server 120.

[0144] As described above, according to this embodiment, even if there are multiple candidates for receiving an order, highly confidential information such as the patient's personal information and image interpretation reports can be exchanged between the requester (medical institution 200) and the contractor (radiography doctor 300A, 300B or 300C) via the storage area 125, which can store information securely, making it possible to realize a secure remote image diagnosis comprehensive support system 2 in which the confidentiality of information is maintained.

[0145] The other configurations, operations, and effects may be similar to those of the first or second embodiment, and therefore detailed description thereof will be omitted here.

[0146] <Third embodiment> Next, the third embodiment of the present disclosure will be described in detail with reference to the drawings. In the following description, for the sake of clarity, the configurations, operations, and effects similar to those of the first or second embodiment or their modified examples will be cited and redundant description will be omitted.

[0147] In the above-mentioned embodiment and its modified example, a case where highly confidential information such as a patient's personal information is exchanged between a client and a contractor in the medical field is exemplified. In contrast, in this embodiment, an example is given of a case where the above-mentioned embodiment is generalized and applied to the e-commerce market.

[0148] In addition, generalization may mean that the requester is a general consumer (regardless of whether professional or amateur), the recipient is an expert, and the request content is general. By generalizing, it becomes possible to apply the request support system according to this embodiment to various categories of e-commerce in which various data such as image data, video data, audio data, and document data can be exchanged between the requester and the recipient, such as requests for lessons and coaching for musical instruments such as piano, guitar, and violin, requests for lessons and coaching for sports such as golf, baseball, soccer, billiards, classical ballet, and ballroom dancing, requests for lessons and coaching for painting, calligraphy, and karaoke, requests for foreign language lessons such as English conversation and English speech, requests for songwriting, composing, and arranging, requests for the production, editing, and proofreading of novels and manga, and requests for the production and debugging of apps.

[0149] In the past, when a novel, manga, or music (hereinafter referred to as a work) was to be proofread or edited, the author would save the work on a storage medium such as a CD (Compact Disc)-ROM (Read Only Memory) or USB (Universal Serial Bus) memory, and deliver the storage medium to the editor directly or by mail, or send it as an attachment to an email, etc. However, this method had the problem that the unpublished work could be lost or unintentionally made public due to the storage medium being lost or stolen, or leaked through an email, etc.

[0150] In recent years, so-called online lessons, in which lessons or coaching in sports, music, etc., as described above, are conducted using video calls, etc., have begun to become popular. However, online lessons have the problem of binding teachers and students for the same amount of time. Therefore, there is an increasing demand for so-called offline lessons, in which students send videos of themselves demonstrating sports or music, or paintings or calligraphy they have created, or copies or photos of such, to their teachers, and receive lessons or coaching from the teachers who have viewed these later. However, offline lessons have the problem that, like requests for proofreading or editing of works, things that the student does not want to be made public may be unintentionally made public due to loss or theft of storage media, or leaks from emails.

[0151] Therefore, this embodiment has been developed in consideration of the above-mentioned problems, and aims to provide a request support device, a request support method, and a program that can increase the confidentiality of information when requesting offline lessons or coaching.

[0152] Fig. 37 is a diagram showing a schematic configuration example of a request support system for realizing a request support service according to this embodiment. As shown in Fig. 37, the request support system 3 according to this embodiment has a configuration similar to that of the remote image diagnosis total support system 1 illustrated in Fig. 1, in which the medical institution 200 is replaced by a general consumer 500 and the image interpretation doctor 300 is replaced by an expert 600. The general consumer 500 can access the service providing site 100 using a requester client 510, and the expert 600 can access the service providing site 100 using a contractor client 610. The requester client 510 and the contractor client 610 may be similar to the requester client 210 and the contractor client 310 according to the first embodiment.

[0153] In the above configuration, the general consumer 500, who is a requester, registers a request to the expert 600 in the service providing site 100 using the requester client 510, similar to the medical institution 200 in the first or second embodiment. Meanwhile, the expert 600, who is a contractor, receives a request from the expert 600 using the contractor client 610, similar to the image interpretation doctor 300 in the first or second embodiment, and stores a deliverable in the service providing site 100. Then, the general consumer 500 accesses the service providing site 100 using the requester client 510 and acquires the registered deliverable.

[0154] The process from the general consumer 500 registering a request at the service providing site 100, to the expert 600 receiving the request and storing the deliverable at the service providing site 100, to the general consumer 50 acquiring the deliverable from the service providing site 100 may be the same as in the first or second embodiment or a variation thereof.

[0155] However, in this embodiment, the medical images that were the subject of interpretation in the first embodiment may be replaced with data (also called requested data) that the expert 600 will analyze and provide advice on, such as video data of playing a musical instrument or playing sports (e.g., a golf swing), audio data such as singing or playing an instrument, or document data such as novels, manga, or programs.

[0156] Furthermore, the items stored in the request management table 116, the requester DB 142, and the contractor DB 143 exemplified in the first embodiment may be changed as appropriate according to the category of the request contents.

[0157] As described above, even in the generalized case, highly confidential information such as personal information and information that the requester wishes to keep secret, such as video data, can be exchanged between the requester (general consumer 500) and the contractor (expert 600) via the storage area 125 capable of securely storing information, thereby making it possible to realize a secure request support system 3 in which the confidentiality of information is maintained.

[0158] The other configurations, operations, and effects may be similar to those according to the first or second embodiment or the modified examples thereof, and therefore detailed description thereof will be omitted here.

[0159] <Hardware configuration> The order management server 110, the information storage server 120, the settlement server 130, the user management server 140, the requester clients 210 and 510, the contractor clients 310, 310A, 310B, 310C, and 610, and the like, according to the above-described embodiments and their modifications, can be realized by an information processing device 1000 having a configuration as shown in Fig. 38, for example. Fig. 38 is a hardware configuration diagram showing an example of the information processing device 1000 that realizes the functions of the order management server 110, the information storage server 120, the settlement server 130, the user management server 140, the requester clients 210 and 510, the contractor clients 310, 310A, 310B, 310C, and 610, and the like. The information processing device 1000 has a CPU 1100, a ROM (Read Only Memory) 1200, a RAM (Random Access Memory) 1300, a recording device 1400, an input / output interface (I / F) 1500, and a communication unit 1600. The various components of the information processing device 1000 are connected via a bus 1700 .

[0160] The CPU 1100 operates based on a program stored in the ROM 1200 or the recording device 1400, and controls each unit. For example, the CPU 1100 loads the program stored in the ROM 1200 or the recording device 1400 into the RAM 1300, and executes processing corresponding to the various programs.

[0161] The ROM 1200 stores a boot program such as a basic input output system (BIOS) executed by the CPU 1100 when the information processing device 1000 is started, and programs that depend on the hardware of the information processing device 1000, and the like.

[0162] Recording device 1400 is a computer-readable recording medium that non-temporarily records programs executed by CPU 1100 and data used by such programs, etc. Specifically, recording device 1400 is a recording medium that records programs for executing each operation related to the present disclosure, which is an example of program data.

[0163] The communication unit 1600 is an interface for connecting the information processing device 1000 to an external network 1650 (e.g., the Internet). For example, the CPU 1100 receives data from other devices and transmits data generated by the CPU 1100 to other devices via the communication unit 1600.

[0164] The input / output I / F 1500 is an interface for connecting the input / output device 1550 and the information processing device 1000. For example, the CPU 1100 receives data from an input device such as a keyboard or a mouse via the input / output I / F 1500. The CPU 1100 also transmits data to an output device such as a display, a speaker, or a printer via the input / output I / F 1500. The input / output I / F 1500 may also function as a media interface that reads a program or the like recorded on a predetermined recording medium.

[0165] For example, when the information processing device 1000 functions as the order management server 110, the information storage server 120, the settlement server 130, the user management server 140, the requester clients 210 and 510, the contractor clients 310, 310A, 310B, 310C, and 610, etc. according to the above-mentioned embodiment, the CPU 1100 of the information processing device 1000 executes the programs loaded on the RAM 1300 to realize the functions of the order management server 110, the information storage server 120, the settlement server 130, the user management server 140, the requester clients 210 and 510, the contractor clients 310, 310A, 310B, 310C, and 610, etc. In addition, the recording device 1400 stores the programs and the like according to the present disclosure. Note that the CPU 1100 reads and executes the program data from the recording device 1400, but as another example, these programs may be obtained from other devices via the external network 1650. [Explanation of symbols]

[0166] 1, 2 Remote image diagnosis comprehensive support system 3. Request Support System 100 Service Provider Sites 110 Order Management Server 111 Request Reception Department 112 Request Management Department 112 113 Payment processing request unit 114 Storage area creation request section 115 Information storage notification section 116 Request Management Table 120 Information storage server 121 Storage area creation section 122 Access Rights Granting Unit 123 Storage information management unit 123 124 Storage section 125 Storage Area 130 Payment Server 131 Information Acquisition Department 132 Payment processing unit 133 Receipt Issuance Section 140 User Management Server 141 User Management Department 142 Client Database 143 Contractor Database 144 User authentication section 200 Medical Institutions 210, 510 Requester Client 300, 300A, 300B, 300C Image interpretation physician 310, 310A, 310B, 310C, 610 Contractor Client 400 Network 500 General consumers 600 Experts

Claims

1. A method for requesting an external expert via the public internet, comprising: Accepting the request from a requester; effecting payment by said requester for said request; creating a storage area on the Internet for securely storing highly confidential request information including data that is the subject of the request; granting access rights to the storage area to the requester; notifying the requester of an address for accessing the storage area; storing the request information uploaded by the requester in the storage area; granting an access right to the storage area to a contractor who has received the request; notifying the contractor of the address for accessing the storage area; downloading the request information in the storage area to the contractor in response to a request from the contractor; storing the deliverables for the request uploaded by the contractor in the storage area; Execute a transfer to the contractor who uploaded the deliverable, Downloading the deliverables in the storage area to a client in response to a request from the client. Including, The settlement includes managing the number of one or more requests placed by the requester within a specified period, and billing the requester for the amount of the one or more requests placed by the requester within the specified period, The transfer includes managing the number of one or more requests that the contractor has received within a specified period, and transferring the amount of the one or more requests that the contractor has received within the specified period to the contractor in a lump sum. How to request assistance.

2. A method for requesting an external expert via the public internet, comprising: Accepting the request from a requester; effecting payment by said requester for said request; creating a storage area on the Internet for securely storing highly confidential request information including data that is the subject of the request; granting access rights to the storage area to the requester; notifying the requester of an address for accessing the storage area; storing the request information uploaded by the requester in the storage area; Determine the priority of multiple candidates for the order, Notify the applicant of the request in order of priority, The first candidate to accept the order is determined to be the person who has accepted the request; granting access rights to the storage area to the contractor; notifying the contractor of the address for accessing the storage area; downloading the request information in the storage area to the contractor in response to a request from the contractor; storing the deliverables for the request uploaded by the contractor in the storage area; Execute a transfer to the contractor who uploaded the deliverable, Downloading the deliverables in the storage area to a client in response to a request from the client. A method of requesting assistance, comprising:

3. Storing the request information uploaded by the requester in the storage area includes encrypting the request information uploaded by the requester using a randomly generated first password, storing the encrypted request information in the storage area, and notifying the contractor of the first password. Storing the deliverable uploaded by the contractor in the storage area for the request includes encrypting the deliverable uploaded by the contractor using a randomly generated second password, storing the encrypted deliverable in the storage area, and notifying the client of the second password. The request support method according to claim 1 or 2.

4. The method of claim 1 or 2, further comprising issuing a receipt to the requester when the payment for the request is made by the requester.

5. The method further includes managing in advance first information including payment information for executing the settlement with respect to the client, and managing in advance second information including transfer destination information for executing the transfer with respect to the contractor, The settlement is performed using the payment information that is managed; The transfer is carried out using the transfer destination information that is managed. The request support method according to claim 1 or 2.

6. The contractor has multiple experts. Manage expert information including at least one of information on the medical department, specialty, track record, preferred modality, and application used for each of the experts; Based on the request information downloaded from the storage area and the managed expert information, the received request is assigned to one of the plurality of experts. The method for supporting a request according to claim 1 or 2, further comprising:

7. A program for causing a processor to function to make requests to external experts via the public internet, A process of accepting the request from a requester; executing a payment by the requester for the request; creating a storage area on the Internet for securely storing highly confidential request information including data that is the subject of the request; granting the requester access to the storage area; notifying the requester of an address for accessing the storage area; storing the request information uploaded by the requester in the storage area; A process of granting an access right to the storage area to a contractor who has accepted the request; notifying the contractor of the address for accessing the storage area; downloading the request information in the storage area to the contractor in response to a request from the contractor; A process of storing a deliverable for the request uploaded by the contractor in the storage area; A process of executing a transfer to the contractor who uploaded the deliverable; downloading the deliverable in the storage area to a requester in response to a request from the requester; causing the processor to execute The process of executing the settlement includes managing the number of one or more requests placed by the requester within a predetermined period, and causing the processor to execute a process of billing the requester for the amount of the one or more requests placed by the requester within the predetermined period, The process of executing the transfer includes managing the number of one or more requests received by the contractor within a predetermined period, and causing the processor to transfer the amount of the one or more requests received by the contractor within the predetermined period to the contractor in a lump sum. program.

8. A program for causing a processor to function to make requests to external experts via the public internet, A process of accepting the request from a requester; executing a payment by the requester for the request; creating a storage area on the Internet for securely storing highly confidential requested information including the target data; granting the requester access to the storage area; notifying the requester of an address for accessing the storage area; storing the request information uploaded by the requester in the storage area; A process of determining a priority order for a plurality of candidate recipients; a process of notifying the receipt of the request in order of the order-receiving candidates with the highest priority; A process of determining the first candidate who has approved the order as the contractor who has accepted the request; A process of granting access rights to the storage area to the contractor; notifying the contractor of the address for accessing the storage area; downloading the request information in the storage area to the contractor in response to a request from the contractor; A process of storing a deliverable for the request uploaded by the contractor in the storage area; A process of executing a transfer to the contractor who uploaded the deliverable; downloading the deliverable in the storage area to a requester in response to a request from the requester; A program for causing the processor to execute the above.

Images