Remote image diagnosis comprehensive support device, remote image diagnosis comprehensive support method, and program

Abstract

The present invention allows more doctors to participate in medical care as an image interpreter while keeping confidentiality of information. A remote image diagnosis comprehensive support device (100) for requesting image interpretation externally of a medical image via a predetermined network comprises: a request reception unit (111) for receiving a request; a settlement processing unit (132) for executing settlement by a requester and executing a transfer to an order recipient; a storage area creation unit (121) for creating a storage area (125) on the predetermined network for securely storing information; an access right granting unit (122) for granting an access right to the storage area to the requester and the order recipient, and notifying the requester and the order recipient of the address of the storage area; and a storage information management unit (123) for managing the entry and removal of information to and from the storage area by the requester and the order recipient.

Description

Remote image diagnosis comprehensive support device, remote image diagnosis comprehensive support method and program

[0001] The present disclosure relates to a remote image diagnosis comprehensive support device, a remote image diagnosis comprehensive support method, and a program.

[0002] BACKGROUND ART With the development of X-ray technology and the advancement and widespread use 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 (hereinafter referred to as medical images) taken by these medical examination devices has increased.

[0003] In light of this situation, in recent years, there has been an increasing number of cases in which clinicians have asked specialized doctors (hereinafter referred to as radiologists) to interpret medical images in order to reduce their own burden and make more accurate diagnoses.

[0004] Typically, when a clinician who directly diagnoses a patient or the medical institution to which the clinician belongs (hereinafter collectively referred to as the client) requests an interpretation from a radiologist or a specialized radiology company (hereinafter collectively referred to as the contractor), the patient's personal information, such as age, gender, and medical history, 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 over this dedicated line.

[0005] JP 2023-102155 A JP 2023-114242 A

[0006] However, in the conventional system, which connects the client and the contractor via a dedicated line, there are high hurdles for doctors who want to open their own practice as radiology doctors, such as the initial cost, maintenance costs after implementation, and ease of operation after implementation.As a result, even if doctors have the skills to read images, they have not yet actively participated in medical care as radiology doctors.

[0007] Furthermore, when a specialized radiology company acts as the contact point for receiving orders, it incurs a great deal of work and intermediate costs, such as distributing the radiology system to each radiology doctor, allocating work to each radiology doctor, billing clients and checking payments, calculating and paying salaries to each radiology doctor, etc. This makes it difficult for new entrants to enter the market, and creating an environment in which more doctors can participate as radiology doctors has been difficult.

[0008] Therefore, the present disclosure has been made in consideration of the above-mentioned problems, and aims to provide a remote image diagnosis comprehensive support device, a remote image diagnosis comprehensive support method, and a program that enable more doctors to participate in medical care as radiology doctors while maintaining the confidentiality of information.

[0009] A remote image diagnosis comprehensive support device according to an embodiment of the present disclosure is a remote image diagnosis comprehensive support device that requests interpretation of medical images from an external device via a predetermined network, and includes a request receiving unit that receives an interpretation request from a requester, a payment processing unit that executes payment by the requester for the request and transfers the payment to a contractor who has uploaded an interpretation report that is a deliverable for the request, a storage area creation unit that creates a storage area on the predetermined network for securely storing highly confidential request information including the medical images, and a storage area creation unit that grants the requester access rights to the storage area and assigns an address for accessing the storage area. an access right granting unit that notifies the requester of the response, grants access rights to the storage area to the contractor who has accepted the request, and notifies the contractor of the address for accessing the storage area; and a storage information management unit that stores the request information uploaded by the requester in the storage area, downloads the request information in the storage area to the contractor in response to a request from the contractor, stores the radiology report on the medical image uploaded by the contractor in the storage area, and downloads the radiology report in the storage area to the requester in response to a request from the client.

[0010] A method for comprehensive support of remote image diagnosis according to one embodiment of the present disclosure is a method for comprehensive support of remote image diagnosis for requesting an external party to interpret medical images via a predetermined network, the method including: accepting a request for interpretation from a requester; executing payment for the request by the requester; creating a storage area on the predetermined network for securely storing highly confidential request information including the medical images; 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 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 the request information in the storage area to the contractor in response to a request from the contractor; storing an interpretation report on the medical images uploaded by the contractor in the storage area; executing a transfer to the contractor who uploaded the interpretation report; and downloading the interpretation report in 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 that requests an external party to interpret a medical image via a predetermined network, the program including a process of accepting an interpretation request from a requester, a process of executing a payment by the requester for the request, a process of creating a storage area on the predetermined network for securely storing highly confidential request information including the medical image, a process of granting the requester access rights to the storage area, a process of notifying the requester of an address for accessing the storage area, and a process of storing the request information uploaded by the requester in the storage area. the processor executes the following processes: granting access rights to the storage area to the contractor who 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; storing an interpretation report on the medical image uploaded by the contractor in the storage area; transferring funds to the contractor who uploaded the interpretation report; and downloading the interpretation report in the storage area to the client in response to a request from the client.

[0012] FIG. 1 is a schematic diagram showing an example of a schematic configuration of a remote image diagnosis comprehensive support system for realizing a remote image diagnosis comprehensive support service according to a first embodiment of the present disclosure. FIG. 2 is a functional block diagram showing an example of a schematic configuration of an order receiving management server according to the first embodiment of the present disclosure. FIG. 3 is a diagram showing an example of a request management table according to the first embodiment of the present disclosure. FIG. 4 is a functional block diagram showing an example of a schematic configuration of an information storage server according to the first embodiment of the present disclosure. FIG. 5 is a functional block diagram showing an example of a schematic configuration of a payment server according to the first embodiment of the present disclosure. FIG. 6 is a diagram showing an example of a schematic configuration of a user management server according to the first embodiment of the present disclosure. FIG. 7 is a diagram showing an example of items managed in a requester DB according to the first embodiment of the present disclosure. FIG. 8 is a diagram showing an example of items managed in a contractor DB according to the first embodiment of the present disclosure. FIG. 9 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. 10 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 2). FIG. 11 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 3). FIG. 12 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. 1 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). 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 6). FIG. 3 is a diagram showing an example of a request plan selection screen according to the first embodiment of the present disclosure. FIG. 4 is a diagram showing an example of a login screen according to the first embodiment of the present disclosure. FIG. 5 is a diagram showing an example of a client new registration screen according to the first embodiment of the present disclosure. FIG. 6 is a diagram showing an example of an image reading request registration screen for diagnosis purposes according to the first embodiment of the present disclosure. FIG. 7 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. FIG. 8 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. FIG. 9 is a diagram showing an example of request information according to the first embodiment of the present disclosure (part 1). FIG. 10 is a diagram showing an example of request information according to the first embodiment of the present disclosure (part 2). FIG. 11 is a diagram showing an example of a registration information management screen according to the first embodiment of the present disclosure.1 is a diagram showing an example of a request summary confirmation screen according to the first embodiment of the present disclosure. FIG. 1 is a diagram showing an example of an interpretation report according to the first embodiment of the present disclosure (Part 1). FIG. 2 is a diagram showing an example of an interpretation report according to the first embodiment of the present disclosure (Part 3). FIG. 1 is a diagram showing another example of an interpretation report according to the first embodiment of the present disclosure (Part 1). FIG. 2 is a diagram showing another example of an interpretation report according to the first embodiment of the present disclosure (Part 3). FIG. 3 is a diagram showing another example of an interpretation report according to the first embodiment of the present disclosure (Part 4). FIG. 4 is a diagram showing another example of an interpretation report according to the first embodiment of the present disclosure (Part 5). FIG. 5 is a diagram showing another example of an interpretation report according to the first embodiment of the present disclosure (Part 6). A schematic diagram showing an example of a schematic configuration of a remote image diagnosis comprehensive support system for realizing a remote image diagnosis comprehensive support service according to a second embodiment of the present disclosure. 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. A sequence diagram showing an example of the operation of the remote image diagnosis comprehensive support system according to a modified example of the second embodiment of the present disclosure. A diagram showing an example of a schematic configuration of a request support system for realizing a request support service according to a third embodiment of the present disclosure. FIG. 1 is a block diagram illustrating an example of a schematic configuration of each information processing device according to each embodiment of the present disclosure.

[0013] Hereinafter, the remote image diagnosis comprehensive support device, the remote image diagnosis comprehensive support method, and the program according to the present disclosure will be described in detail by illustrating several embodiments.

[0014] First Embodiment First, a first embodiment of the present disclosure will be described in detail with reference to the drawings. In this embodiment, an example of a remote image diagnosis comprehensive support system that supports a clinician (which may include other physicians 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 physician or a company (hereinafter also referred to as a contractor) that provides a remote image diagnosis support service will be described.

[0015] Note that a specific contract for requesting and receiving an order for image interpretation may or may not exist between the requester and the contractor. For example, a requester such as a clinician or medical institution may request image interpretation for each case from an unspecified image interpretation doctor or image interpretation company with whom they have not entered into a specific contract, or from a specific image interpretation doctor or image interpretation company with whom they have entered into a specific contract, or may request image interpretation for a large number of cases on a regular basis (e.g., once a week). In other words, this embodiment can be applied to a system that acts as an intermediary between the requester and the contractor, regardless of the content of the contract between the requester and the contractor.

[0016] Furthermore, the purposes of interpreting medical images include diagnosing patients, conducting research at research institutions, and verifying evidence in the event of a medical problem or during a forensic autopsy. However, in this embodiment, for the sake of simplicity, we will use the example of diagnosing patients.

[0017] In this embodiment, an example is given in which one or more client requests interpretation of medical images from one contractor. For clarity, the following example is given in which the contractor is an individual radiologist. The client may also be an individual doctor or his / her assistant who directly diagnoses the patient, or a medical institution such as a hospital or research institute to which the doctor belongs. For clarity, the following example is given in which the contractor is a medical institution.

[0018] Here, "medical images" may refer to various image data or video data acquired by medical examination devices, such as X-ray images (X-ray images), CT images, PET-CT images, MRI images, echo images, endoscopic images, electrocardiograms, and pathological images. However, without being limited thereto, medical images according to this embodiment may include various image data and video data used by doctors for diagnosis. Furthermore, in the following embodiments, the DICOM (Digital Imaging and Communication in Medicine) format is exemplified as the data format of medical images. However, without being limited thereto, various data formats such as still images and videos, such as JPEG, TIFF, GIF, BMP, and MP4, may also be used.

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

[0020] Remote Image Diagnosis Comprehensive Support System 1 FIG. 1 is a schematic diagram illustrating an example of the overall configuration of a remote image diagnosis comprehensive support system for realizing a remote image diagnosis comprehensive support service according to this embodiment. As shown in FIG. 1 , the remote image diagnosis comprehensive support system 1 includes various servers 110, 120, 130, and 140 constituting a service providing site 100, a client client 210 installed at a medical institution 200, and a contractor client 310 owned by an image interpreter 300, all of which are communicably connected via a network 400. One or more of the various servers 110, 120, 130, and 140 constituting the service providing site 100 may constitute a remote image diagnosis comprehensive support device according to this embodiment. Furthermore, the network 400 may be a wide-area network such as the Internet or a mobile communication system, a limited network such as a local area network (LAN) or a wide area network (WAN), or a combination thereof.

[0021] Medical Institution 200 and Requester Client 210 The requester client 210 may be, for example, a desktop, notebook, tablet, or other type of personal computer (hereinafter simply referred to as a PC) installed in the medical institution 200, such as a hospital or research institute. The requester client 210 has, for example, a communication function for connecting to the network 400 via a LAN established within the medical institution 200 and a web browser function for browsing web pages published on the network 400 by the service provider site 100 or the like. Doctors and their assistants at the medical institution 200 access the service provider site 100 from the requester client 210 to request interpretation of medical images from an external party (e.g., a radiological interpreter 300 located in a remote location) and obtain an interpretation report created by the requested radiological interpreter 300. The medical images may be medical images acquired by a medical examination device installed within 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.

[0022] The contractor client 310 may be, for example, a desktop, notebook, tablet, or other type of PC installed at the workplace or home of the radiologist 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 established in the workplace, and a web browser function for browsing web pages published on the network 400 by the service provider site 100 or the like. The radiologist 300 accesses the service provider site 100 from the contractor client 310 to receive a request registered on the service provider site 100 and acquire medical images to be interpreted. The radiologist 300 then interprets the acquired medical images and stores the resulting interpretation report in the service provider site 100.

[0023] Service Providing Site 100 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 multiple servers (including cloud servers), or may be composed of a single server or two or more servers integrating at least two of the servers 110, 120, 130, and 140. The service providing site 100 may be a dedicated e-commerce site (also referred to as a company's own e-commerce site) built specifically for the purpose of providing the remote image diagnosis comprehensive support service according to this embodiment, or a mall-type e-commerce site accessible to unspecified users for various purposes. Such a service providing site 100 may be an existing e-commerce (EC) site, such as Shopify (registered trademark). In this case, using an e-commerce site that provides not only ordering / receiving services but also payment services can simplify the work required of both the client and the recipient.

[0024] ...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 image interpretation requests from the requesting medical institution 200 and orders of requests from the image interpretation doctor 300 using a request management table 116, which will be described later.

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

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

[0027] For each request, the settlement process request unit 113 requests the settlement server 130 (described later) to execute payment process (settlement) by the client and to execute transfer process to the contractor.

[0028] 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.

[0029] 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.

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

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

[0032] The requester ID may be identification information for uniquely identifying the requester. This requester ID may be a value assigned to the requester (in this example, the medical institution 200) when the user management server 140 (described later) newly registers (including pre-registration) the requester in the requester database (DB). Note that this requester ID may be a value used as an access ID (also referred to as 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).

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

[0034] The contractor ID may be identification information for uniquely identifying the contractor. This client ID may be a value assigned to the contractor (radiography doctor 300 in this example) when the user management server 140, which will be described later, newly registers (including pre-registration) the contractor in the contractor DB. The contractor ID may be left blank (null) if the contractor has not yet been determined. The client ID may also be a value used as an access ID (also called a login ID) when the contractor accesses a storage area (the registration information management screen shown in FIG. 23), which will be described later.

[0035] 4 is a functional block diagram showing an example of the schematic configuration 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 memory 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 the results of interpreting the medical images.

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

[0037] 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 contractor (in this example, the radiologist 300) who accepted the request.

[0038] The storage information management unit 123 manages and executes the storage of various data such as medical images uploaded by the client (in this example, the medical institution 200) and various data such as radiological reports uploaded by the contractor (in this example, the radiological interpretation physician 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 radiological reports requested by the client from the storage area 125.

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

[0040] ...Payment Server 130 Fig. 5 is a functional block diagram showing an example of the 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 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.

[0041] 6 is a functional block diagram showing an example of the schematic configuration of the 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 related to client and contractor, and performs login authentication for client and / or contractor to this system.

[0042] 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.

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

[0044] 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 requiring individuals or medical institutions who may be potential clients to register, it becomes possible to guarantee the identity of the client, and also to obtain benefits such as reducing the hassle of settlement (payment).

[0045] 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 requiring potential contractors to register, it is possible to not only guarantee the identity of the contractor, but also obtain benefits such as reducing the hassle of making payments (transfers).

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

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

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

[0049] 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).

[0050] 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. Furthermore, 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.

[0051] The name of the requesting physician may be information for identifying the natural person responsible for the request.

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

[0053] The payment information may be information used by the client to make a payment, such as a debit account, credit card information, or information related to an online payment service such as Paypay (registered trademark). By managing the client's payment information in advance on the service providing site 100, it is possible to eliminate the effort 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.

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

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

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

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

[0058] 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 enterprise.

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

[0060] The order field may be information about a field for which an order for interpretation can be accepted, such as a medical department. For example, if the order recipient, the image interpretation doctor 300, is a doctor specializing in radiology, the radiology department may be specified, and if the order recipient is an internal medicine doctor, the internal medicine department may be specified. Furthermore, if the order recipient can handle multiple medical departments, multiple medical departments may be specified.

[0061] 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 the image interpretation, etc. The accuracy of the image interpretation may reflect the client's evaluation, etc.

[0062] 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 physician 300. For example, if the image interpretation physician 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.

[0063] 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 on the service provider site 100, it is possible to eliminate the effort and risk of having to enter the transfer destination information for each order. Note that the transfer destination information is not limited to one, and multiple transfer destination information may be registered.

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

[0065] 9, in this operation, first, the medical institution 200 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 by 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 general type of request content (for example, the above-mentioned diagnostic purpose, research purpose, verification purpose, etc.), price, etc.

[0066] 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.

[0067] Furthermore, the fee for a request plan is not limited to a single request, but may be a fee for a package of multiple requests, such as five requests, or may be a fee per period, such as one month or one year. When a fee is charged per period, an upper limit on the number of requests per period (for example, 10 requests for one month) may be set.

[0068] The requested plan selection screen will now 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 the requester may select a requested plan by performing an operation such as double-clicking on the icon of the desired requested plan.

[0069] When a request plan is selected in this manner, the request receiving 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 uses the requester client 210 to input its assigned login ID and password into the login screen and selects the "Login" button, thereby requesting login authentication from the order management server 110 (steps S2103-S1103).

[0070] As described above, the login ID may be the requester ID assigned to the medical institution 200 when it registers as a requester. Alternatively, an email address may be used instead of the login ID. Furthermore, if the medical institution 200 has not yet registered as a requester with 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 enter the necessary information, thereby registering the medical institution 200 as a requester in the requester DB 142.

[0071] 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 of 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 the requester is a registered legitimate person (step S1405).

[0072] Next, the user authentication unit 144 notifies the order management server 110 of the authentication result (step S1406 → S1106). In response, 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 made again (step S1102 → S2102).

[0073] 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 content (basic request information) to the medical institution 200 is displayed on the requester client 210, as shown in FIG. 10, and the basic request information is registered by the medical institution 200 in accordance with this image reading request registration screen (steps S2108-S1108). The image reading request registration screen reference may be made public on the network 400 generated by the request receiving unit 111 of the order management server 110, for example.

[0074] 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 the image reading request registration screen for diagnostic purposes according to this embodiment. As shown in FIG. 18 , the image reading request registration screen includes fields for inputting the name of the requesting medical institution (or the name, if the requesting physician is an individual physician), the medical department, the requesting physician's name, the patient's name, the patient ID, the patient's date of birth, the patient's age, the patient's gender, the modality, the clinical course, and specific points desired for interpretation. The modality may be information regarding the type of medical examination device that acquired the medical image to be read. The modality may also include information regarding the file format of the medical image. The request date and time may be automatically set when the requester (the medical institution 200 in this example) performs a predetermined action, such as when the requester accesses the image reading request registration screen or clicks the "Request" button.

[0075] However, since the patient name, patient ID, patient date of birth, clinical course, and points that the patient wishes to have interpreted are information that may correspond to the patient's personal information, they may be configured to be additionally registered in the interpretation request form (see Figures 21 and 22) described below, rather than on the interpretation request registration screen.

[0076] 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 FIGS. 19 and 20, the content of the basic request information registered on the image reading request registration screen may differ for each purpose. In this case, the items managed in the request management table 116 shown in FIG. 3 may differ for each purpose.

[0077] The basic request information (including the date and time of request) entered into the image reading request registration screen in this manner is entered as a character string into the order management server 110, and is registered and managed by the request management unit 112 of the order management server 110 in a predetermined record in the request management table 116. At this time, the request management unit 112 may generate a request ID and store it in the predetermined record. The requester ID may be entered by the requester in an input field provided 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 entered into the image reading requesting physician registration screen. Furthermore, the contractor ID may be left blank (null) if a contractor has not yet been determined, or may be identified from the contractor DB 143 managed by the user management server 140 after a contractor has been determined.

[0078] Next, the payment processing 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 information about the requester pre-registered in the requester DB 142 for the relevant medical institution 200 (steps S1109-S1409). In response, the user management unit 141 of the user management server 140 acquires information about the requester of the relevant 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 (steps S1410-S1110).

[0079] In addition, if the requesting medical institution 200 has not yet been registered in the requester DB 142 (for example, if this 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.

[0080] 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 about the client notified by the user management server 140 (steps S1111-S1311). At this time, the payment information may be notified to the payment server 130 by the order management server 110, or the information acquisition unit 131 of the payment server 130 may access the user management server 140 and acquire it.

[0081] 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.

[0082] Next, the medical institution 200 executes payment for this request by inputting a predetermined operation according to the payment screen displayed on the web browser of the requester client 210 (steps S2113->S1313). Note that in this embodiment, payment information such as debit account and credit card information is managed in advance at the service provider site 100, and the requester (in this example, the medical institution 200) can use this managed payment information for payment. This makes it possible to avoid the risks that arise from requiring the requester to input payment information each time a request is made, and enables secure transactions.

[0083] Next, upon confirming that the payment procedure has been completed by the medical institution 200, the receipt issuing unit 133 of the payment server 130 issues a receipt for this request to the requester client 210 (step S1314). In response, the medical institution 200 can download (DL) the receipt from the payment server 130 using the requester client 210 as needed (steps S1315-S2115). The receipt issued by the payment server 130 may be, for example, an electronic file such as a portable document format (PDF). Alternatively, the service provider 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 has been completed by the medical institution 200 (steps S1316-S1116).

[0084] 11, the storage area creation request unit 114 of the order management server 110 requests the information storage server 120 to create (including allocating) 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 some of the information about the requester (for example, the requester ID, email address, etc.).

[0085] Next, the storage area creation unit 121 of the information storage server 120 creates (or reserves) a 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 access rights to the created (or reserved) storage area 125 (step S1219). For example, if 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) access rights to this data box (see step S1219).

[0086] Next, the access right granting unit 122 of the information storage server 120 notifies the medical institution 200 of an address (e.g., a uniform resource locator (URL)) for accessing the created (or reserved) 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.

[0087] Once the storage address is notified in this manner, the medical institution 200 accesses the storage area 125 from the requester client 210 using the storage address and uploads (UL) more detailed information regarding the request (hereinafter also referred to as request information) to this storage area 125 (steps S2121-S1221). The request information may also include information such as an electronic medical record (e.g., an electronic medical record output as a PDF). Furthermore, 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 performed, for example, by the requester client 210 or by 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 radiologist 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).

[0088] The request information stored in the storage area 125 will now be described in detail with reference to Fig. 21 and Fig. 22. Fig. 21 and Fig. 22 are diagrams showing examples of request information according to this embodiment. Note that Fig. 21 and Fig. 22 show examples of request information excluding medical images, but the request information according to this embodiment may include medical images to be interpreted.

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

[0090] The "requester information" may include, for example, information such as the name of the medical institution 200, the medical department, the requesting physician, 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 gender. 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.

[0091] Furthermore, the "clinical progress" may be information about the treatments that have been performed on the patient up to now, and the "points that the requesting physician wants the radiologist to particularly interpret" may be information about the points that the requesting physician wants the radiologist to particularly interpret.

[0092] 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.

[0093] 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.

[0094] 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 reserved storage area 125, an "Upload" button for uploading the selected file to the reserved 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 this list, and a "Bulk Download" button for downloading all the files stored in the storage area 125 at once.

[0095] When the medical institution 200 uploads request information to its own storage area 125, it uses the web browser function of the requester client 210 to view the registration information management screen, selects the files to be uploaded (radiography 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 storage information management unit 123.

[0096] Returning to the explanation 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).

[0097] Next, the information storage and notification unit 115 of the order management server 110 queries the user management server 140 for information about the radiological doctor who will be the contractor (information about the contractor) (step S1123 → S1423). At that time, the information storage and notification unit 115 notifies the user management server 140 of the basic request information or part of the information. In response, 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 radiological doctor 300 who will be the contractor for 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 contractor (step S1424 → S1124).

[0098] Next, the information storage notifying unit 115 of the order management server 110 notifies the image-interpreting physician 300 (specifically, the contact address) notified by the user management server 140 that a request has been made (steps S1125-S3125). For example, if the user management server 140 notifies the order management server 110 of an email address as the contact address of the image-interpreting physician 300, the information storage notifying unit 115 automatically sends an email to that address notifying that a request has been made. This email may include, for example, a URL attached thereto for guiding the image-interpreting physician 300, who is the order recipient, to a request summary confirmation screen (see FIG. 24) where the image-interpreting physician 300 can confirm the summary of the request contents.

[0099] Here, Figure 24 is a diagram showing an example of a request summary confirmation screen according to this embodiment. As shown in Figure 24, the request summary confirmation screen may be provided with an area for displaying information (e.g., basic request information) that allows 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 by the information storage and notification unit 115 of the order management server 110 when the medical institution 200 registers the basic request information using the requester client 210 (see steps S2108 → S1108).

[0100] The image-reading 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 (step S3126 → S1126) and determines whether to accept the order. If accepting the order, the image-reading doctor 300 approves the order by, for example, clicking the "Accept Order" button on the request summary confirmation screen (step S3127 → S1127). Note that if the image-reading doctor 300 clicks the "Reject Order" button, the requester client 210 may be notified via the order management server 110 that the image-reading doctor 300 has not accepted the request.

[0101] 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 rights to the secured storage area 125 (steps S1128-S1228). At this time, the information storage notification unit 115 notifies the information storage server 120 of at least the contractor ID among the information related to the contractor. In response, 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 rights to the storage area 125 (step S1229) and notifies the order management server 110 that the access right has been granted (steps S1230-S1130). At this time, the information storage server 120 may again notify the order management server 110 of the address (e.g., URL) of the storage area 125.

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

[0103] Next, the image-interpreting 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-interpreting 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 password, similar to the login authentication processing (steps S1102-S2107) for the requester (the medical institution 200 in this example).

[0104] 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 in accordance with 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.

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

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

[0107] Furthermore, one or more medical images may be pasted into the radiology report as needed to facilitate understanding of the radiology report (especially the findings and summary). These medical images may be edited with arrows, boxes, coloring, or other markings to indicate areas of interest during interpretation, or areas mentioned in the findings or summary. Note that interpreted medical images are not limited to being pasted into the radiology report, and may be stored in the storage area 125 as separate files, for example.

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

[0109] Next, the payment processing request unit 113 of the order management server 110 requests the payment server 130 to process payment to the radiology 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 obtain it by accessing the user management server 140. Upon receiving the payment request from the order management server 110, the payment processing unit 132 of the payment server 130 executes payment (transfer) processing for the amount set for this request in accordance with the payment information (step S1338). Then, upon completion of the payment processing, the payment processing unit 132 notifies the order management server 110 that the payment processing has been completed (step S1339->S1139).

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

[0111] 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 requesting medical institution 200 obtains the image interpretation report for this request.

[0112] The above operations enable the exchange of highly confidential information, such as the patient's personal information and radiology reports, between the requester (medical institution 200) and the order-taker (radiography doctor 300) via the storage area 125, which can securely store information. This makes it possible to realize a secure remote image diagnosis comprehensive support system 1 in which the confidentiality of information is maintained. Furthermore, according to this embodiment, the service providing site 100 can consistently support the entire process from receiving a request to payment and registering (delivering) the radiology report, thereby significantly reducing the hurdles for doctors to participate in medical practice as radiology doctors. This makes it possible to provide a remote image diagnosis comprehensive support device, a remote image diagnosis comprehensive support method, and a program that enable more doctors to participate in medical practice as radiology doctors.

[0113] Furthermore, according to this embodiment, by utilizing the order management service and payment service provided by the service provider site 100, it is possible to significantly reduce the effort required for request and order processing and accounting processing for the requester and the recipient, thereby significantly reducing intermediate costs such as labor costs and management costs. Furthermore, according to this embodiment, recipients such as the radiology doctor 300 can directly contract with the requesting medical institution 200 and receive requests, which also makes it possible to significantly reduce intermediate costs such as sales expenses.

[0114] Furthermore, in the past, clinicians or medical institutions wishing to request a diagnosis were required to enter into a fixed-term contract with a specialized image interpretation company, paying an initial fee and monthly usage fees, and there was no on-demand service that allowed them to request a diagnosis only when they wanted to. 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 in which it is not possible to request the desired image interpretation doctor, making diagnosis difficult.

[0115] In contrast, according to this embodiment, clinicians, medical institutions 200 requesting diagnoses, and image-reading physicians 300 can work on an on-demand basis, allowing the diagnosis requesting side and the image-reading side to operate freely. Even in this case, accounting can be automatically performed at both the diagnosis requesting side and the image-reading side, making it possible to significantly reduce intermediate costs.

[0116] In this embodiment, the example has been given of a case in which a fee is paid to the radiological doctor 300 each time an interpretation report is stored in the storage area 125, that is, each time a request is received and completed, but the payment of the fee to the radiological 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 radiological doctor 300 and each plan for each predetermined period (e.g., one month), and pay the radiological 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).

[0117] Furthermore, in the present embodiment, an example has been given of a case in which an amount according to a selected plan is billed each time a 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 (for example, January), and bill the medical institution 200 for an amount according to the number of requests at or after the predetermined period has elapsed (for example, at the end of the month).

[0118] (Modification of the First Embodiment) In the above-described first embodiment, the case where the contractor is an individual radiological doctor 300 is exemplified. However, if the contractor is, for example, a specialized radiological company employing multiple radiological doctors, the specialized radiological company will have to assign the received request to each radiological doctor. Therefore, in this modification, an example of a configuration for automating the assignment of requests to each radiological doctor within the specialized radiological company will be described.

[0119] The automatic assignment of requests to each radiologist may be performed, for example, by the contractor client 310. In this case, the contractor client 310 manages information (also referred to as radiologist information) such as each radiologist's identification number (also referred to as radiologist ID), medical department, specialty (e.g., head, chest, abdomen), radiology record (e.g., the field and number of times of medical image interpretation), specialty modality (e.g., X-ray, CT, PET-CT, MRI), and application used for radiology interpretation (e.g., OsiriX, DICOM Library, IMAIOS DICOM Viewer, PostDICOM, Voxelx, FViewer), and automatically assigns an appropriate radiologist to each request based on the radiologist information from the request information. For example, the contractor client 310 may assign requests in the order of the radiologist ID, which is composed of numbers, based on the specialty, based on the specialty modality, or based on two or more items in the radiologist information.

[0120] The download of the request information from the service provider site 100 may be executed from the contractor client 310 of the specialized image interpretation company, or may be executed from the client of the image interpretation doctor to whom the request is assigned. When executed from the image interpretation doctor's client, the access right to the storage area 125 may also be granted to this client.

[0121] Similarly, the radiology company may upload the radiology report to the service provider site 100 from the contractor client 310 of the radiology company, or from the client of the radiology doctor to whom the request is assigned. If the upload is performed from the radiology doctor's client, the access right to the storage area 125 may also be granted to this client.

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

[0123] Second Embodiment Next, a second embodiment of the present disclosure will be described in detail with reference to the drawings. For clarity, the following description will focus on differences from the remote image diagnosis comprehensive support system 1 according to the first embodiment.

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

[0125] (System Configuration) Fig. 34 is a schematic diagram showing an example of the overall configuration of a remote image diagnosis comprehensive support system for realizing the remote image diagnosis comprehensive support service according to this embodiment. As is clear from a comparison of Fig. 34 with Fig. 1, the remote image diagnosis comprehensive 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 contractor (e.g., radiological interpreter 300) is one-to-one, whereas the remote image diagnosis comprehensive support system 2 according to this embodiment illustrates a case in which the relationship between the requester (e.g., medical institution 200) and the contractor (e.g., radiological interpreter 300A-300C) is one-to-multiple.

[0126] 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 the same as those according to the first embodiment. Also, the configurations of the contractor clients 310A to 310C of the radiological interpreters 300A to 300C, respectively, according to this embodiment may be the same as the contractor client 310 of the radiological interpreter 300 according to the first embodiment.

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

[0128] In this embodiment, first, by executing the same operations as those described in the first embodiment using Figures 9 to 11, the request information is stored 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).

[0129] Next, the information storage and notification unit 115 of the order management server 110 queries the user management server 140 for information on one or more radiological doctors who are candidates for receiving orders (information about the order recipients) (step S1123-1→S1423-1). At this time, similar to step S1123→S1423 in FIG. 12 , the information storage and notification unit 115 notifies the user management server 140 of the request basic information or a portion thereof. In response, 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 one or more radiological doctors 300A-300C who are candidates for receiving orders for the current request (specifically, information about the order recipients), and notifies the order management server 110 of at least the contact information (e.g., email address) for each of the identified one or more order recipient candidates (step S1424-1→S1124-1).

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

[0131] Each of the one or more radiological interpreters 300A-300C notified of the request uses the order-receiving client client 310A-310C to check the request summary confirmation screen from the notified URL (steps S3126A-S1126A, S3126B-S1126B, and S3126C-S1126C) and decides whether to accept the order. If accepting the order, the radiological interpreter (in this example, radiological interpreter 300A) approves the order by, for example, clicking the "Accept Order" button on the request summary confirmation screen (steps S3127A-S1127A). Note that Figure 35 illustrates an example in which radiological interpreter 300A approves the order first.

[0132] Next, the information storage and notification unit 115 of the order management server 110 identifies the radiological doctor who first approved the order from among one or more candidate doctors (in this case, the radiological doctor 300A) and determines this radiological doctor 300A as the contractor (step S1127-1).The information storage and notification unit 115 then notifies the radiological doctors 300B and 300C other than the radiological doctor 300A who was determined as the contractor that the contractor has been determined (step S1127-2 → S3127B / S3127C).

[0133] In this way, once one contractor is determined from one or more contractor candidates, in this embodiment, the same operations as those described in the first embodiment using Figures 13 to 14 are performed, and the radiological report created by the radiological doctor 300A 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.

[0134] 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 radiology reports can be exchanged between the client (medical institution 200) and the contractor (radiography doctor 300A, 300B, or 300C) via storage area 125, which can securely store information, making it possible to realize a secure remote image diagnosis comprehensive support system 2 in which the confidentiality of information is maintained.

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

[0136] (Modification of the Second Embodiment) Next, a modification of the second embodiment, i.e., another embodiment in which one client has one or more order-receiving candidates, will be described with reference to the drawings. The remote image diagnosis comprehensive support system according to this modification may be similar to the remote image diagnosis comprehensive support system 2 illustrated in Fig. 34. However, in this modification, the operation illustrated in Fig. 35 may be replaced with the operation illustrated in Fig. 36.

[0137] 36, in this embodiment, first, by performing operations similar to those described in the first embodiment using Figures 9 to 11, request information is stored in a storage area 125 secured in the memory unit 124 of the information storage server 120. Then, by performing operations similar to those described in the second embodiment using steps S1222 to S1124-1 of Figure 35, at least contact information (e.g., email address) from among the information related to one or more radiological 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.

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

[0139] Once the priority is determined, the information storage notification unit 115 first notifies the image-reading physician with the highest priority (the image-reading physician 300A in this example) that a request has been made (steps S1125A-2 to S3125A-2). The request summary confirmation screen to which the image-reading physician 300A is directed by the notification may be the same as the example shown in FIG. 24.

[0140] The image-reading 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 determines whether to accept the order. If the order is not to be accepted, the image-reading doctor 300A notifies the order management server 110 that the order will not be accepted by, for example, clicking the "Reject Order" button on the request summary confirmation screen (step S3127A-2 → S1127A-2).

[0141] In this way, if the next highest priority candidate refuses to accept the order, the information storage notification unit 115 of the order management server 110 notifies the next highest priority radiologist (radiography doctor 300B in this example) that a request has been made (step S1125B-2 → S3125B-2). In response, the radiologist 300B checks the request summary confirmation screen from the notified URL using the contractor client 310B (step S3126B-2 → S1126B-2) and determines whether to accept the order. If the order is accepted, the order is approved by, for example, clicking the "Accept Order" button on the request summary confirmation screen (step S3127B-2 → S1127B-2).

[0142] In this way, once one contractor is determined from one or more contractor candidates, in this embodiment, the same operations as those described in the first embodiment using Figures 13 to 14 are performed, and the interpretation report created by the radiologist 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.

[0143] 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 radiology reports can be exchanged between the client (medical institution 200) and the contractor (radiography doctor 300A, 300B, or 300C) via storage area 125, which can securely store information, making it possible to realize a secure remote image diagnosis comprehensive support system 2 in which the confidentiality of information is maintained.

[0144] 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.

[0145] Third Embodiment Next, a third embodiment of the present disclosure will be described in detail with reference to the drawings. In the following description, for clarity, 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.

[0146] In the above-described embodiment and its modifications, a case where particularly 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 will be given of a case where the above-described embodiment is generalized and applied to the e-commerce market.

[0147] Note that generalization may mean that the requester is a general consumer (regardless of whether professional or amateur), the contractor is a specialist, 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 contractor, such as requests for lessons or coaching on musical instruments such as piano, guitar, and violin, requests for lessons or coaching on sports such as golf, baseball, soccer, billiards, classical ballet, and ballroom dancing, requests for lessons or coaching on 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 development and debugging of apps.

[0148] In the past, when a novel, manga, or musical piece (hereinafter referred to as a "product") 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 then deliver the storage medium to the editor either directly or by mail, or send it as an attachment to an email, etc. However, this method posed the problem of the possibility 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.

[0149] In recent years, so-called online lessons, in which lessons and coaching in sports, music, and other fields are conducted via video calls, have become popular. However, online lessons have the drawback of tying up both the teacher and the student for the same amount of time. Therefore, there has been an increasing demand for offline lessons, in which students send videos of themselves demonstrating sports, music, or other activities, or their own paintings or calligraphy, or copies or photos of such works, to their teachers, who then view the videos and provide lessons or coaching. However, offline lessons have the same drawback of requiring proofreading or editing of work: there is a risk that unwanted information may be unintentionally made public due to loss or theft of storage media or leaks via email.

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

[0151] Fig. 37 is a diagram showing a schematic configuration example of a request support system for realizing the 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 comprehensive support system 1 illustrated in Fig. 1, with the medical institution 200 replaced by a general consumer 500 and the radiology doctor 300 replaced by an expert 600. The general consumer 500 can access the service provider site 100 using a requester client 510, and the expert 600 can access the service provider 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.

[0152] In the above-described 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 radiological doctor 300 in the first or second embodiment, and stores the 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.

[0153] 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, and the general consumer 50 obtaining the deliverable from the service providing site 100 may be the same as in the first or second embodiment or a variation thereof.

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

[0155] 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 depending on the category of the request content.

[0156] As described above, even in the generalized case, highly confidential information such as personal information and information that the client 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, which can store information securely, making it possible to realize a secure request support system 3 in which the confidentiality of information is maintained.

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

[0158] <Hardware Configuration> The order management server 110, information storage server 120, settlement server 130, user management server 140, requester clients 210 and 510, contractor clients 310, 310A, 310B, 310C, and 610, etc., according to the above-described embodiments and their modifications can be realized by an information processing device 1000 having a configuration such as that shown in Fig. 38. 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, information storage server 120, settlement server 130, user management server 140, requester clients 210 and 510, contractor clients 310, 310A, 310B, 310C, and 610, etc. The information processing apparatus 1000 includes 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 units of the information processing apparatus 1000 are connected by a bus 1700.

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

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

[0161] 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 are examples of program data.

[0162] 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.

[0163] The input / output I / F 1500 is an interface for connecting the input / output device 1550 and the information processing apparatus 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 for reading programs and the like recorded on a predetermined recording medium.

[0164] For example, when the information processing device 1000 functions as the order management server 110, information storage server 120, payment server 130, user management server 140, requester clients 210 and 510, contractor clients 310, 310A, 310B, 310C, and 610, etc., according to the above-described embodiments, the CPU 1100 of the information processing device 1000 executes programs loaded onto the RAM 1300 to realize the functions of the order management server 110, information storage server 120, payment server 130, user management server 140, requester clients 210 and 510, contractor clients 310, 310A, 310B, 310C, and 610, etc. In addition, the recording device 1400 stores programs, etc., according to the present disclosure. Note that the CPU 1100 reads and executes program data from the recording device 1400. Alternatively, the CPU 1100 may obtain these programs from another device via an external network 1650.

[0165] 1, 2 Remote image diagnosis comprehensive support system 3 Request support system 100 Service providing site 110 Order management server 111 Request reception unit 112 Request management unit 112 113 Payment processing request unit 114 Storage area creation request unit 115 Information storage notification unit 116 Request management table 120 Information storage server 121 Storage area creation unit 122 Access right granting unit 123 Stored information management unit 123 124 Memory unit 125 Storage area 130 Payment server 131 Information acquisition unit 132 Payment processing unit 133 Receipt issuance unit 140 User management server 141 User management unit 142 Requester database 143 Order recipient database 144 User authentication unit 200 Medical institution 210, 510 Requester client 300, 300A, 300B, 300C Image interpretation doctor 310, 310A, 310B, 310C, 610 Order recipient client 400 Network 500 General consumer 600 Expert

Claims

1. A remote image diagnosis comprehensive support device that requests the interpretation of medical images in DICOM (Digital Imaging and Communication in Medicine) format from an external source via a specified network, comprising: a request receiving unit that receives the request for interpretation from a requester; a payment processing unit that executes payment by the requester for the request and transfers the money to a contractor who has uploaded the interpretation report, which is the deliverable for the request; a storage area creation unit that creates a storage area on the specified network for securely storing highly confidential request information including the medical images; an access right granting unit that grants access rights to the storage area to the requester and notifies the requester of an address for accessing the storage area, and grants access rights to the storage area to the contractor who has accepted the request and notifies the contractor of the address for accessing the storage area; a storage information management unit that stores the request information uploaded by the client in the storage area, downloads the request information in the storage area to the contractor in response to a request from the contractor, stores the image interpretation report on the medical image uploaded by the contractor in the storage area, and downloads the image interpretation report in the storage area to the client in response to a request from the client.

2. The remote image diagnosis comprehensive support device of claim 1, wherein the medical images include at least one of an X-ray image, a CT (Computed Tomography) image, a PET (Positron Emission Tomography)-CT image, an MRI (Magnetic Resonance Imaging) image, an echo image, an endoscopic image, an electrocardiogram, and a pathology image.

3. The remote image diagnosis comprehensive support device as described in claim 1, wherein the stored information management unit encrypts the request information uploaded by the client using a randomly generated first password, then stores it in the storage area and notifies the contractor of the first password, and encrypts the image interpretation report uploaded by the contractor using a randomly generated second password, then stores it in the storage area and notifies the client of the second password.

4. The remote image diagnosis comprehensive support device according to claim 1, further comprising a receipt issuing unit that issues a receipt to the requester when the payment for the request is made by the requester.

5. A remote image diagnosis comprehensive support device as described in claim 1, further comprising a user management unit which manages in advance first information including payment information for executing the settlement with respect to the client, and which manages in advance second information including transfer destination information for executing the transfer with respect to the contractor, wherein the settlement processing unit executes the settlement by the client using the payment information managed by the user management unit, and executes the transfer to the contractor using the transfer destination information managed by the user management unit.

6. The remote image diagnosis comprehensive support device as described in claim 1, wherein the settlement processing unit manages the number of one or more requests placed by the requester within a specified period, bills the requester for the amount of the one or more requests placed by the requester within the specified period, manages the number of one or more requests received by the contractor within a specified period, and transfers the amount of the one or more requests received by the contractor within the specified period to the contractor.

7. The remote image diagnosis comprehensive support device as described in claim 1, further comprising an information storage and notification unit that notifies a plurality of order acceptance candidates of the receipt of the request, and determines the order acceptance candidate among the plurality of order acceptance candidates who is the first to accept the order as the order acceptance candidate.

8. The remote image diagnosis comprehensive support device as described in claim 1, further comprising an information storage and notification unit which determines the priority order of multiple order acceptance candidates, notifies the order acceptance candidate with the highest priority in order of the receipt of the request, and determines the order acceptance candidate who first approves the order as the order acceptance candidate.

9. A method for comprehensively supporting remote image diagnosis, which requests an external party to interpret medical images in DICOM (Digital Imaging and Communication in Medicine) format via a specified network, comprising: accepting a request for interpretation from a client; executing a payment by the client for the request; creating a storage area on the specified network for securely storing highly confidential request information including the medical images; granting access rights to the storage area to the client; notifying the client of an address for accessing the storage area; storing the request information uploaded by the client in the storage area; granting 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 the request information in the storage area to the contractor in response to a request from the contractor; storing an interpretation report on the medical images uploaded by the contractor in the storage area; executing a transfer to the contractor who uploaded the interpretation report; and downloading the interpretation report in the storage area to the client in response to a request from the client. A remote image diagnosis comprehensive support device including the above.

10. A program for causing a processor to function that requests an external party to interpret medical images in DICOM (Digital Imaging and Communication in Medicine) format via a specified network, comprising: a process for accepting the request for interpretation from a requester; a process for the requester to execute payment for the request; a process for creating a storage area on the specified network for securely storing highly confidential request information including the medical images; 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 accepted the request; a process for notifying the contractor of the address for accessing the storage area; a process for downloading the request information in the storage area to the contractor in response to a request from the contractor; a process for storing an interpretation report on the medical images uploaded by the contractor in the storage area; and a process for executing a transfer to the contractor who uploaded the interpretation report. and a process of downloading the image interpretation report in the storage area to a client in response to a request from the client.

Images