JP2016126798A - Information processing system, method for controlling information processing system, and computer program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a doctor with thread information about each patient as far as possible while ensuring security about information of the patient, in the case when an acquisition request for the thread of the patient is received from the doctor who performs image reading of inspection with the patient as a target.SOLUTION: When an acquisition request for information of a thread about a patient is received from a doctor, a scree including the information of the thread about the patient is generated. In such a case, when the acquisition request for the thread about the patient is an acquisition request from the doctor who performs image reading of inspection with the patient as a target, a screen which also includes information of threads not related to the image reading doctor among threads about the patient is generated.SELECTED DRAWING: Figure 5

Description

  Information processing system, control method for information processing system, and computer program, and in particular, when a thread acquisition request for each patient is received from a doctor who interprets an examination for the patient, thread information about the patient Is provided to the doctor as much as possible while ensuring the security of the patient information.

  In recent years, with the development of computer networks represented by the Internet, various services have been provided on servers connected to the network, and systems in the medical field are also provided on the Internet. It has become to.

  In the medical field, for example, digitization of medical images of patients taken with modalities (also called medical image generation devices) such as CT (Computed Tomography) and MRI (Magnetic Resonance Imaging) has been realized. As stored on the server.

Usually, medical images stored in the server are interpreted by specialists who can interpret medical images. However, because specialists are overwhelmingly short of personnel, in recent years, medical images that have been taken have not been networked. Therefore, a system (also referred to as a remote interpretation system) that requests interpretation from an out-of-hospital specialist has become widespread.
In such a remote interpretation system, it is required to ensure security regarding patient information.

  Patent Document 1 discloses an image display request from a patient image data list (including examination information such as image data ID, image data shooting date, examination facility ID, image modality, and examination person ID) in a remote interpretation system. Is received from an interpreting doctor, and a technique for determining whether or not to allow display of patient image data in accordance with the medical information access right set for each interpreting doctor is disclosed.

JP 2006-198042 A

  By the way, in the remote interpretation system as described above, in recent years, when creating a report of the interpretation results of the patient in charge of the interpreting doctor, it is possible to exchange opinions with other interpreting doctors, request to the clerk of the interpretation center, etc. Services that can exchange messages (so-called SNS) are also available.

  In such a service for exchanging messages, an acquisition request for a message exchange screen (a screen containing thread information related to examinations for each patient, hereinafter referred to as a thread screen) is read for patients. When a request (examination) is received from an interpreting doctor (hereinafter referred to as an interpreting interpreter) who interprets the interpretation request (examination), the security related to the patient is ensured while ensuring the security of the patient information. There is a need to display a thread screen for the patient that can provide as much information as possible to the interpreting physician.

  However, the technique of Patent Document 1 described above is based on the medical information access right set for each interpretation doctor when displaying image data selected by the user from the patient image data list (corresponding to a thread screen). Therefore, at the time when the image data list is displayed, the information to be displayed is not changed depending on whether or not he / she is an interpreting doctor. That is, even if the technique of Patent Document 1 is used, on the thread screen, the user who received the thread screen acquisition request may or may not be the responsible interpreting doctor, but the information displayed on the thread screen may be the same. Conceivable.

  When the present invention receives a thread acquisition request for each patient from a doctor who interprets the examination for the patient, the thread information about the patient can be obtained while ensuring security about the patient information. It is to provide a mechanism that can be provided to the doctor as long as possible.

  The present invention relates to a storage means for storing a thread managed in association with patient information including an examination, user information for managing a user who can view each thread, and doctor information for managing a doctor associated with an examination. Receiving means for receiving a thread acquisition request from a doctor using patient information as a key; specifying means for specifying a thread associated with the patient information from the storage means according to patient information received by the receiving means; and the specifying means If the thread identified in (1) is a thread that can be browsed by the user information stored in the storage means by the doctor who made the acquisition request by the accepting means, a screen that can refer to the contents of the thread is generated. Generating means, wherein the thread specified by the specifying means is stored in the storage means by a doctor who has made an acquisition request by the receiving means. Even if the thread is determined not to be viewable by the user information, if the doctor who has made an acquisition request by the receiving means is included in the doctor information, a screen capable of identifying the thread is generated. Features.

  In addition, the present invention stores a thread that is managed in association with patient information including an examination, user information that manages a user who can view each thread, and doctor information that manages a doctor associated with an examination. The information processing system control method includes a receiving step in which the receiving unit of the information processing system receives a thread acquisition request from a doctor using patient information as a key, and the specifying unit of the information processing system includes: According to the patient information received in the accepting step, the identifying step for identifying the thread associated with the patient information from the storage unit, and the generating unit of the information processing system are the thread identified in the identifying step in the accepting step. If the doctor who made the acquisition request is a thread that can be viewed by the user information in the storage means, A generating step for generating a screen that can be referred to, and the generating step can be browsed by the user information in the storing step by the doctor who has made an acquisition request in the receiving step by the thread specified in the specifying step If the doctor who has made an acquisition request in the reception process is included in the doctor information, a screen capable of identifying the thread is generated.

According to the present invention, when an acquisition request for a thread for each patient is received from a doctor who interprets an examination for the patient, while securing thread information about the patient, security about the patient information, It can be provided to the doctor as much as possible.

The system block diagram which shows an example of a structure of a remote interpretation system. The hardware block diagram of the computer as an information processing apparatus applicable to the request terminal 109, the image interpretation terminals 112-114, and each server 101-107,116. The figure which shows an example of the report preparation screen 401 displayed on PC301. The figure which shows an example of the report data 400 managed by the database. The figure which shows an example of the thread | sled list screen 501 displayed on PC301. The figure which shows an example of the thread data 600 managed by the database. The figure which shows an example of the thread detail screen 701 displayed on PC301. The figure which shows an example of the thread message data 800 managed by the database. The figure which shows an example of the thread participation request screen 901 displayed on PC301. The figure which shows an example of the user data 100 managed by the database. The figure which shows an example of the patient data 110 managed by the database 108 The figure which shows an example of the flowchart which displays the list screen of a thread | sled on PC301. The figure which shows an example of the flowchart which shows the detail of the process of step S1204. The figure which shows an example of the flowchart which shows the detail of the process of step S1205. The figure which shows an example of the flowchart which shows the detail of the process of step S1206. The figure which shows an example of the flowchart which shows the detail of the process of step S1211. The figure which shows an example of the flowchart which shows the detail of the process of step S1213.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. The embodiment described below shows an example when the present invention is specifically implemented, and is one of the specific examples of the configurations described in the claims.

FIG. 1 is a system configuration diagram showing an example of the configuration of a remote interpretation system.
The remote interpretation system according to the present embodiment includes a medical institution (request facility) such as a hospital that requests interpretation, an interpretation center that performs requested interpretation and returns the result, and a medical institution (request) Facilities) and a data center that acts as an intermediary between the interpretation center and equipment in each organization.

The devices in each organization are connected to a network 117 such as the Internet, and can perform data communication with each other via the network 117 (communicable).
First, the equipment in the requested facility will be described.

  Reference numeral 109 denotes a request terminal used by a doctor at a request facility requesting interpretation. The interpretation request person in charge at the requested facility uses the request terminal 109 to input interpretation request information. The input request information is processed by the remote interpretation server 101, and the request information is stored in the database 108.

  The image data used for remote interpretation is transmitted from the modality 111 to the terminal device 110, and the terminal device 110 archives the image data transmitted from the modality 111 and then transmits it to the receiving server 107 in the data center.

  The image data transmitted from the modality 111 is processed by the receiving server 107 and sent to the storage management server 105.

The storage management server 105 issues a unique ID for the image data and stores the image data in the external storage device 115.
Next, the interpretation center will be described.

  112 and 113 are interpretation terminals, and the interpretation doctors at the interpretation center that have received the interpretation request from the requested facility are the interpretation images downloaded from the external storage device 115 using the distribution server 106 at the interpretation terminals 112 and 113. The report of the interpretation result is created using a report application (also called a report client) that operates on the interpretation terminals 112 and 113. The created report is processed by the report server 103 and stored in the database 108. The interpreting doctor can also use the system from the interpretation terminal 114 at the interpreting doctor's home.

  In the description after FIG. 3, the request terminal 109 and the interpretation terminals 112 to 114 are collectively referred to as a PC 301.

  In this interpretation system, when an access request from the request terminal 109 and the interpretation terminals 112 to 114 is received in accordance with an instruction of a user who uses the remote interpretation system, the authentication of the user is performed by the authentication server 116 in the data center via the network 117. Done.

  After passing the authentication, on the screens of the request terminal 109 and the interpretation terminals 112 to 114, the interpretation screen provided by the portal server 102 and the portal screen including the main menu are displayed.

  In addition, the interpretation doctor accesses the SNS (so-called social networking service, which is a WEB site where users can exchange messages) server 104 from the interpretation terminals 112 to 114, When creating a report, the interpretation terminal 113 can exchange opinions with other interpretation doctors and exchange messages such as requests to the interpretation center clerk.

  Note that message exchange is processed by the SNS server 104 in units of “threads” in which the participants, titles, and messages are grouped together. The contents of the thread are stored in the database 108.

The users who use the SNS are doctors at the requesting hospital that requests the interpretation, interpretation doctors that perform the interpretation, clerk at the interpretation center that distributes the interpretation requests from the requested hospital to the interpretation doctors, and the like.
The servers related to the present invention are the SNS server 104 and the database 108.

  In this embodiment, the server for managing images and the server for managing SNS are separate servers. However, as another embodiment, the processing performed by each of the servers 101 to 107 and 116 is performed by one server. May be.

Next, with reference to FIG. 2, an example of a hardware configuration of a computer as an information processing apparatus that can be applied to the request terminal 109, the interpretation terminals 112 to 114, and the servers 101 to 107 and 116 will be described with reference to the block diagram of FIG. 2. I will explain.
The configuration illustrated in FIG. 2 is an example, and any configuration may be adopted as long as each configuration described below can be realized.

  In FIG. 2, reference numeral 201 denotes a CPU that comprehensively controls each device and controller connected to the system bus 204. Further, the ROM 202 or the external memory 211 is necessary to realize a BIOS (Basic Input / Output System) or an operating system program (hereinafter referred to as an OS), which is a control program of the CPU 201, or a function executed by each server or each PC. Various programs to be described later are stored.

  A RAM 203 functions as a main memory, work area, and the like for the CPU 201. The CPU 201 implements various operations by loading a program or the like necessary for execution of processing from the ROM 202 or the external memory 211 into the RAM 203 and executing the loaded program.

  An input controller 205 controls input from a keyboard (KB) 209 or a pointing device such as a mouse (not shown). A video controller 206 controls display on a display device such as a CRT display (CRT) 210. The display device is not limited to the CRT, and may be another display device such as a liquid crystal display. These are used by the administrator as needed.

  A memory controller 207 is provided in an external storage device (hard disk (HD)), flexible disk (FD), or PCMCIA card slot for storing a boot program, various applications, font data, user files, editing files, various data, and the like. Controls access to an external memory 211 such as a compact flash (registered trademark) memory connected via an adapter.

  A communication I / F controller 208 is connected to and communicates with an external device via a network (for example, the network 117 shown in FIG. 1), and executes communication control processing on the network. For example, communication using TCP / IP is possible.

  Note that the CPU 201 enables display on the display 210 by executing outline font rasterization processing on a display information area in the RAM 203, for example. Further, the CPU 201 enables a user instruction with a mouse cursor (not shown) on the display 210.

  Various programs to be described later for realizing the present invention are recorded in the external memory 211 and executed by the CPU 201 by being loaded into the RAM 203 as necessary. Furthermore, definition files and various information tables used when executing the program are also stored in the external memory 211, and a detailed description thereof will be described later.

Now, each screen displayed on the display 210 of the PC 301 in the present invention will be described.
First, FIG. 3 will be described.

  FIG. 3 is a diagram showing an example of a report creation screen 300 displayed on the PC 301 in the present invention, and the interpretation doctor creates a report of interpretation results from the report creation screen 300.

  Reference numeral 302 denotes a work list, which is obtained from a search result obtained by searching for an interpretation request for which an interpretation doctor who has logged in to the remote interpretation system is in charge of interpretation from the report data 406 of FIG. 4 managed by the database 108. A list of interpretation requests for which the interpretation doctor is in charge is displayed.

  When an image interpretation doctor performs an image interpretation request for an examination for a patient, the image interpretation doctor manages the image interpretation request in charge in the data table of FIG. 4 described later in association with the image interpretation request.

  When the interpretation doctor selects a report in the work list 302, details of the request are displayed in 304. In the work list 302, when an interpreting doctor selects a report and operates a mouse or the like to press the patient thread button 303, the PC 301 sends an SNS server 104 to the SNS server 104 for an interpretation request (examination) for the patient. , A thread list display request including information indicating that the doctor is in charge of interpretation of the interpretation request (examination) is transmitted, and the thread list screen of FIG. 5 is transmitted from the SNS server and displayed on the PC 301. The

FIG. 4 is a diagram illustrating an example of report data 400 managed by the database 108.
The report data 400 is created by assigning an interpretation request to an interpretation doctor at the interpretation center when the interpretation request arrives at the interpretation center from the requesting facility.

  The report data 400 includes a “report ID” 401 that is information for identifying the report, a “request facility name” 402 that indicates the name of the requested facility that requested the interpretation, and a “request No” 403 that identifies the interpretation request. “Patient name” 404 indicating the name of the patient who is the subject of the interpretation request, “Status” 405 indicating the status of the current interpretation, and “Interpretation interpretation” indicating the name of the interpretation doctor in charge of interpretation request (examination) "Doctor" 406 (doctor information for managing a doctor associated with the examination) is stored in association with it.

  FIG. 5 is a diagram showing an example of a thread list screen 501 displayed on the PC 301 in the present invention. The thread list screen 501 is displayed on the PC 301 when the interpretation doctor operates the mouse or the like and presses the patient thread button 303 on the report creation screen 300 displayed on the PC 301.

  The thread list screen 501 in FIG. 5 is obtained when the user “Taro Yomitsu” who is an interpreting physician selects the report “patient A” from the work list 302 and presses the patient thread button 303 on the report creation screen 300. It is a display example.

  The thread list screen 501 is generated by the SNS server 104 based on the thread data 600 of FIG.

  Specifically, first, a thread whose patient name 609 in the thread data 600 of FIG. Next, among the threads of the patient A, the thread owner 603 or the thread in which the participant 604 includes Yomi Ryokan is displayed in 502, and among the threads of the patient A, the thread owner 603 or Taro Yuki is sent to the participant 604. A thread list screen 501 is generated so that threads that do not include are displayed on 502.

  In 502, among the threads included in the thread data 600, a thread related to the patient A and a thread whose Taro Yomikage is a thread owner (the creator of the thread) or a participant (also referred to as a viewable thread or a participating thread). It is displayed in a list (threads with thread IDs 1, 9, and 10 in the thread data 600).

  Reference numeral 504 denotes a thread title. The title 504 is a link, and when the title 504 is clicked by an operation of the interpreting doctor with a mouse or the like, a thread detail screen 701 in FIG. 7 is displayed.

  In 503, Taro Yomikage is not included in either the thread owner or the participant, but a thread related to patient A (also referred to as a thread without viewing authority or a non-participating thread) is displayed in a list (thread data 600). Thread ID2 and thread 5).

  For the thread included in 503, the title is not a link, and the details of the thread cannot be viewed. In order to view the details of the thread, the participation request button 507 needs to be clicked by an operation of a mouse or the like by the interpretation doctor, and then the participation needs to be approved by the thread owner.

  However, by showing the title of the thread in which the responsible interpreting doctor is not participating to the interpreting doctor in charge of the interpretation request for patient A, other messages regarding patient A are exchanged with the responsible interpreting doctor. And can be guided to the thread of the patient A who is not participating.

  Moreover, about the thread | sled which the said radiographer in charge does not participate, the disclosure range of a patient's personal information can be managed exactly by not browsing a detail, unless it is approved by the thread owner. That is, security can be enhanced in terms of protecting patient personal information.

  Heretofore, an example has been described in which the thread list screen 501 is displayed on the PC 301 when the interpretation doctor operates the mouse or the like and presses the patient thread button 303 on the report creation screen 300 displayed on the PC 301. However, the thread list screen 501 displays a thread search screen (a screen in which only 506 in FIG. 5 is displayed) from the portal screen, and executes a search by patient name selection from the search item input field of the thread search screen. Thus, even a user other than the responsible interpreting doctor (such as an clerk or an interpreting doctor other than the responsible interpreting doctor) can retrieve the patient thread.

  In that case, only the thread in which the user who executed the search participates is displayed on the thread list screen 501. That is, 503 is not displayed.

  This is because, for the interpreting doctor in charge of the interpretation request (examination) for the patient who is the target of the search, what kind of message is exchanged in another thread for the patient when interpreting the patient However, for users other than the interpreting doctor in charge of the interpretation request (examination) for the patient, what message is being exchanged in another thread for the patient This is because it is considered that it is not preferable in terms of protecting the personal information of the patient to show the user information of a thread other than the thread in which the user is participating.

  If a patient thread is searched from the thread search screen, 503 may not be displayed regardless of whether or not he / she is in charge of interpretation, but the above-described effects obtained by displaying 503 are considered. Then, if the responsible interpreting doctor searches for the patient in charge from the thread search screen, 503 may be displayed. In that case, from a thread search screen (a screen displaying only 506 in FIG. 5), a user who searches for a patient thread (a user who is logged in to the remote interpretation system) requests an interpretation of the patient ( Whether or not it is a radiographer in charge of (examination) is determined by the SNS server based on the report data 400 of FIG. 4 managed by the database 108 and the thread data 600 of FIG. 6, and the thread list screen 501 of FIG. 5 is generated. Is done.

  Specifically, by referring to the patient name 404 of the report data 400 of FIG. 4, the report of the patient who is the display target is specified, and then the responsible interpreting doctor 406 of the request for the patient. 503 is displayed if the user who performed the search (a user who has logged in to the remote interpretation system) is included. Alternatively, the patient's thread to be displayed is identified from the thread data 600 of FIG. 6, and the radiogram doctor in charge of the request No. 403 of the report data 400 of FIG. 4 that matches any of the related request IDs 607 of the identified thread. If the user who performed the search (a user who has logged in to the remote interpretation system) is included in 406, 503 may be displayed.

In this embodiment, the report data 400 of FIG. 4 is used to specify whether or not the patient is in charge of interpretation. However, as another embodiment, the patient data in FIG. The information of the interpreting doctor in charge of the interpretation request (examination) is linked and stored, and it is determined from the patient data in FIG. 11 whether or not it is the interpreting doctor in charge of the interpretation request (examination) for the patient. Also good.
Next, data used to generate the screen of FIG. 5 will be described with reference to FIG.

  FIG. 6 is a diagram illustrating an example of thread data 600 managed by the database 108.

  The thread data 600 includes a thread ID 601 which is information for identifying a thread, a thread title 602 indicating a thread title, a thread owner 603 indicating a user who created the thread (thread owner), and a user participating in the thread (participation request). Participants 604 (user information for managing users that can be viewed for each thread) indicating that the user has been approved), and participation requests indicating users who are requesting participation in the thread by pressing 504 in FIG. Medium 605, participation denial 606 indicating a user who is refused to participate in the thread from the thread owner, ID of request data related to the thread, name of the requested facility, and name of the target patient.

  Here, the definition of “thread” in the present invention will be described. A “thread” in the present invention is a collection of posts related to a specific topic on an electronic bulletin board (in this embodiment, the thread list screen 501 and the thread detail screen 701 in FIG. 5 provided by the SNS server 104). Indicates. Taking the line with thread ID 601 of thread data 600 of FIG. 6 as “8” as an example, a reply from the user indicated by participant 604 is received for the thread of the topic “finding change request” created by office worker A. When a reply is further received in response to the reply, a topic thread called a finding change request is formed. The thread is associated with patient information including the examination.

  4 and thread data 600 shown in FIG. 6 managed by the database 108 include threads managed in association with patient information including examinations, user information for managing users who can view each thread, It is an example of the memory | storage means which memorize | stores the doctor information which manages the doctor linked | related with a test | inspection.

  In 502 of FIG. 5, the patient whose patient name 609 is the display target in the thread data 600 of FIG. 6 and who made the display request (the user who is logged in to the remote interpretation system) Threads included in the thread owner 603 or the participant 604 are displayed.

  In 503 of FIG. 5, the user whose patient name 609 is the display target in the thread data 600 of FIG. 6 and who made the display request (the user who is logged in to the remote interpretation system) Are not included in the thread owner 603 or the participant 604.

  Next, a screen displayed on the PC 301 when the title 504 is pressed by the operation of the interpretation doctor's mouse or the like on the thread list screen 501 in FIG. 5 will be described with reference to FIG.

  FIG. 7 is a diagram showing an example of the thread detail screen 701 displayed on the PC 301 in the present invention. The thread detail screen 701 is displayed on the PC 301 when the interpretation doctor operates the mouse or the like to press the title 504 on the thread list screen 501 of FIG. 5 displayed on the PC 301.

  The thread detail screen 701 is generated by the SNS server 104 based on the thread message data 800 of FIG.

  Reference numeral 702 denotes a message display unit. In the message display unit 702, each message exchanged on the thread is displayed together with the name and date of the user who wrote the message.

  Reference numeral 703 denotes an approval / rejection button for the participation request. The approval / rejection button 703 for participation request is a button for approving / rejecting the participation request displayed when there is a request for participation in the thread. A participation request message is displayed on the left side of 703.

  When the approval button among the approval / rejection buttons 703 is pressed according to the operation of the mouse or the like by the user, the user is added to the participant 604 of the thread in FIG.

When the reject button of the approval / rejection button 703 is pressed according to the operation of the mouse or the like by the user, the user is added to the participation rejection 606 of the thread in FIG.
Note that the approval / rejection button for the participation request is displayed only when the thread owner displays the thread detail screen 701.
Reference numeral 704 denotes a message input field in which a message can be input.
Next, data used to generate the screen of FIG. 7 will be described with reference to FIG.

  FIG. 8 is a diagram showing an example of thread message data 800 managed by the database 108. In the thread message data 800, a message ID 801, a thread ID 802, a user name 803, and a message text 804 are managed in association with each other.

  Reference numeral 801 denotes a message ID for identifying a message. Reference numeral 802 denotes a thread ID 802 indicating which thread the message is.

  Reference numeral 803 denotes a user name 803 indicating the name of the user who created the message. Reference numeral 804 denotes the content of the message.

  In the thread detail screen 701 of FIG. 7, the message text of the thread ID 802 that matches the thread ID of the title 504 pressed by the image interpretation doctor operating the mouse or the like on the thread list screen 501 of FIG. 804 is displayed.

  Next, a screen displayed on the PC 301 when the participation request button 507 is pressed by the operation of the interpretation doctor's mouse or the like on the thread list screen 501 in FIG. 5 will be described with reference to FIG.

  FIG. 9 is a diagram showing an example of a thread participation request screen 901 displayed on the PC 301 in the present invention. The thread participation request screen 901 is a thread list screen 501 of FIG. 5 displayed on the PC 301. When the interpretation doctor operates the mouse or the like and presses the participation request button 507, the thread participation request screen 901 is generated by the SNS server 104 and displayed on the PC 301. The

  The thread participation request screen 901 includes an information display unit 902 that displays the title of the thread for which the participation request button 507 has been pressed by the operation of the mouse or the like by the interpreting doctor, and related patient information. A message input unit 903 capable of inputting a message to be sent to the owner is provided.

  A user who wants to participate in the thread inputs a message for requesting participation in the message input unit 903 and then presses a send button 904 to transmit the message for requesting participation to the SNS server 104.

When the SNS server 104 receives the participation request message, the SNS server 104 adds the user who transmitted the participation request message to 605 of the thread data 600 in FIG. 6, and further adds the received participation request message to the thread message data 800. Is registered with the thread ID of the thread to which is sent.
Next, other data managed by the database 108 will be described with reference to FIGS.

FIG. 10 is a diagram illustrating an example of user data 100 managed by the database 108.
The user data 100 includes a user ID set for each user, a user name, and a user role for the system.

FIG. 11 is a diagram illustrating an example of patient data 110 managed by the database 108.
The patient data 110 includes the ID of the requested facility to which the patient belongs, the ID assigned to the patient by the requested facility, and the patient name.

The normal patient ID is usually different for each requested hospital even if it is the same patient, but by introducing a mechanism such as My Number, the same patient ID is assigned to the same patient even if the requested facility is different. You may do it.
Now, each process executed in the PC 301 or the SNS server 104 in the present invention will be described.

FIG. 12 is a diagram showing an example of a flowchart for displaying a thread list screen on the PC 301 in the present invention.
The process of each step shown in the flowchart shown in FIG. 12 and the sub-flows of FIGS. 13 to 17 are executed by loading the program stored in the external memory 211 into the RAM 203 and executed by the CPU 201 of the PC 301 or the SNS server 104. It is realized by doing.

  Before executing the processing of FIG. 12, the PC 301 accepts input of information (user ID, password, etc.) for logging in to the remote interpretation system from the user, and performs login processing using the information. And

  In step S1201, the PC 301 accepts selection of the target report from the work list 302 of the report creation screen 300 of FIG. 3 displayed on the display 210 of the PC 301, and then the patient thread button 303 is operated by the interpretation doctor's mouse or the like. When a thread search request based on a patient name is received from the user on the thread search screen, a request for acquiring a thread list for the patient is transmitted to the SNS server 104.

  The request for acquiring the thread list of the patient includes the name of the patient who displays the list of threads and the information of the user who executed the request for acquiring the thread list. In the following description of the embodiment, it is assumed that the thread of patient A is searched.

  Step S1201 is an example of a receiving unit that receives a thread acquisition request from a doctor using patient information as a key in the present invention.

  In step S1202, the SNS server 104 that has received the patient thread list request from the PC 301 analyzes the contents of the patient thread list acquisition request.

  In step S1203, the SNS server 104 determines whether or not the thread list acquisition request for the patient is from the interpretation doctor in charge of the interpretation request (examination) for the patient. If the patient's thread list acquisition request is from the responsible interpreting doctor, in step S1204, among the patient threads, the responsible interpreting doctor who has made the thread list acquisition request executes a thread search including a non-participating thread. If the request for acquiring the thread list of the patient is not from the responsible interpreting doctor, in step S1205, a participation thread search is performed in which the user who has made the request for acquiring the thread list participates in the thread of the patient. Search results are stored in the RAM 203.

  Details of the processing in step S1204 will be described with reference to FIG. Details of the processing in step S1205 will be described with reference to FIG.

  In step S1203, when the SNS server 104 determines that the thread list acquisition request of the patient is from the interpreting doctor in charge, it is as described with reference to FIG. Specifically, four methods are conceivable. First, when a patient thread list acquisition request is made by pressing the patient thread button 303 in FIG. 3 after selecting a report from the work list created based on the report data 400 in FIG. If it is determined that the doctor is the responsible interpreting physician (since the work list only displays the report that the interpreting physician is the responsible interpreting physician), the patient thread list is requested when the thread search screen is requested. This is a method for determining that the doctor is not an interpretation doctor.

  Second, when a thread list acquisition request for a patient is made from the thread search screen, the report data 400 in FIG. 4 is searched (specifically, refer to the patient name 404), thereby targeting the patient. Identify the report. Then, referring to the assigned radiographing doctor 406 of the identified report, if the user who made the thread list acquisition request is included in the assigned radiology doctor 406, the user is specified as the responsible radiology doctor.

Third, in addition to the second method, after selecting a report from the work list created based on the report data 400 in FIG. 4, the patient thread button 303 in FIG. When a thread list acquisition request is made, it is determined that the doctor is in charge of interpretation.
Fourth, when a thread list acquisition request is made for a patient, the thread data 600 of FIG. 6 is searched (specifically, refer to the patient name 609) to identify the thread of the patient. Next, the report data 400 shown in FIG. 4 that matches the related request ID 607 of one of the specified threads (specifically, report data whose request No. 403 matches the related request ID 607) is specified. This is a method of determining that the person in charge is the responsible interpreting doctor if the responsible interpreting doctor 406 of the specified report data includes the user who has made a thread list acquisition request.

  In step S1206, the SNS server 104 generates the thread list screen of FIG. 5 based on the search result data, and transmits the thread list screen of FIG. Details of the processing in step S1206 will be described with reference to FIG.

  In step S <b> 1207, the PC 301 displays the thread list screen of FIG. 5 transmitted from the SNS server 104 on the display 210 of the PC 301.

  In step S1208, the PC 301 determines whether an operation has been received from the user via the thread list screen in FIG. If an operation is accepted from the user, the process proceeds to step S1209. If an operation is not accepted from the user, the process waits until an operation is accepted from the user.

  In step S1209, the PC 301 transmits the content of the operation accepted from the user to the SNS server 104 via the thread list screen of FIG.

  The SNS server 104 that has received the content of the user operation from the PC 301 determines the operation content in step S1210, step S1212, and step S1214.

  When the participation request button (507 in FIG. 5) is pressed (YES in step S1210), the participation request process in step S1211 is executed. Details of the processing in step 1211 will be described with reference to FIG. When the process of step S1211 ends, the process returns to step S1208.

  When the thread title link (504 in FIG. 5) on the thread list screen is pressed (YES in step S1212), the message display process in step S1213 is executed. Details of the processing in step 1213 will be described with reference to FIG. When the process of step S1213 ends, the process returns to step S1208.

  If an operation other than the two operations other than the end instruction is performed, the other process of step S1215 is executed. When the process of step S1215 ends, the process returns to step S1208.

If an end instruction has been given (YES in step S1214), the process ends.
Above, description of FIG. 12 is complete | finished.
Next, details of the processing in step S1204 will be described with reference to FIG.

FIG. 13 is a diagram showing an example of a flowchart showing details of the processing in step S1204.
In step S1301, the SNS server 104 first analyzes a search condition.

In step S <b> 1302, the SNS server 104 uses the thread data 600 managed by the database 108 as a thread in which the user who has requested the thread list display, that is, the attending interpreting doctor (hereinafter referred to as interpreting doctor A) participates. Search with specified conditions (including at least patient name and hospital name). Specifically, in the thread data 600 of the hospital included in the search condition, a thread whose patient name 609 is included in the patient name 609 is specified, and among the identified patient A threads, the participant 604 includes the interpretation doctor A. Search for conversations.
Step S1302 is an example of a specifying unit that specifies a thread associated with the patient information from the storage unit according to the patient information received by the receiving unit in the present invention.

  In step S1303, the SNS server 104 searches the thread data 600 in the same hospital for a thread in which the patient name 609 is included in the patient name 609 and the interpretation doctor A is not included in the participant 604. Here, the reason why the patient is in the same hospital is that the patient ID is usually different for each requested hospital even if the patient is the same patient.

  However, if the patient information includes My Number (the number for identifying the patient and the same number if it is the same patient even in different hospitals), by specifying the patient with My Number, It is also possible to search for patient A's thread across multiple hospitals. In that case, the hospital name may not be included in the search condition.

Finally, in step S1304, the SNS server 104 merges the search results in steps S1302 and S1303 and stores them in the RAM 203 of the SNS server 104.
This is the end of the description of FIG.
Next, details of the processing in step S1205 will be described with reference to FIG.

FIG. 14 is a diagram showing an example of a flowchart showing details of the processing in step S1205.
In step S1401, the SNS server 104 first analyzes a search condition.

  Next, in step S1402, the SNS server 104 joins the user who requested the thread list display, that is, a user other than the responsible interpreting doctor (an interpreting doctor who is not in charge of the clerk or patient A, etc., hereinafter referred to as user B). Threads that are currently being searched are searched with the conditions (including at least the patient name and hospital name) specified from the thread data 600 managed in the database 108. Specifically, a thread in which patient A is included in patient name 609 is identified from hospital thread data 600 included in the search condition, and user B is included in participant 604 among the identified patient A threads. Find the thread that will be used.

  Step S1402 is an example of a specifying unit that specifies a thread associated with the patient information from the storage unit according to the patient information received by the receiving unit in the present invention.

Finally, in step S1403, the SNS server 104 stores the search result in step S1402 in the RAM 203 of the SNS server 104.
This is the end of the description of FIG.
Next, details of the processing in step S1206 will be described with reference to FIG.

  FIG. 15 is a diagram showing an example of a flowchart showing details of the processing in step S1206.

  In step S1501, the SNS server 104 acquires thread data that is the search result stored in the RAM 203 of the SNS server 104 in step S1304 in FIG. 13 or step S1403 in FIG.

Next, the SNS server 104 sequentially processes the thread data acquired in step S1501, and executes a loop (processing from step S1502 to step S1510) in which display data is generated and stored in the RAM 203.
In step S1502, one piece of thread data is extracted from the search result acquired from the RAM 203 of the SNS server 104.

  In step S1503, the SNS server 104 determines whether the retrieved thread data is a thread in which the user who requested the thread list display participates (whether the user is included in the participant 604 of the thread data 600 in FIG. 6). Judge whether. If the thread requesting the thread list display is a non-participating thread, the process proceeds to step S1504. If the thread requesting the thread list display is a participating thread, the process proceeds to step S1506.

  Note that if the search result acquired from the RAM 203 of the SNS server 104 is stored in the RAM 203 of the SNS server 104 in step S1403 of FIG. 14, the process proceeds to step S1506.

  In step S1504, the SNS server 104 includes the user who requested the thread list display as a participation refusal user in the thread data (the user is included in the participation rejection 606 of the thread data 600 in FIG. 6). ) Or not. If the user who requested the thread list display is included in the participation refusal users in the thread data, the process returns to the top of the loop. If the user who requested the thread list display is not included in the participation refusal user in the thread data, the process proceeds to step S1505.

  In step S1505, the SNS server 104 determines whether or not a display field of a thread (non-participating thread) that has no viewing authority, specifically, a frame 503 in FIG. 5 has been created. The SNS server 104 creates a display frame for a thread that does not have browsing authority.

In step S1510, the SNS server 104 creates display data for a thread that does not have browsing authority. The display data includes the association type of the thread, the title of the thread (504 in FIG. 5), and the patient name associated with the thread. Further, a participation request button (507 in FIG. 5) for requesting participation from the thread owner is also included. The state of the participation request button depends on the contents of the column of the user requesting participation of the thread data to be displayed (participation requesting 605 in the thread data 600 in FIG. 6), and the thread list display is requested in the requesting participation 605. When the user is included, the participation request button becomes an inoperable button.
Steps S1509 and S1510 are when the thread specified by the specifying unit in the present invention is a thread that cannot be browsed by the user information stored in the storage unit by the doctor who has made an acquisition request by the receiving unit. This is an example of a generation unit that generates a screen that can identify the thread when the doctor who has made an acquisition request by the reception unit is included in the doctor information.

  In step S1506, the SNS server 104 determines whether the viewable thread display field, specifically, the frame 502 in FIG. 5 has been created. If not created, the viewable thread display frame is set in step S1507. create. In step S1508, display data of a viewable thread is created.

  The display data includes the association type of the thread, the title of the thread (504 in FIG. 5), and the patient name associated with the thread. In the thread title 504, a link for displaying a message included in the thread is embedded.

  In Steps S1507 and S1508, in the present invention, the thread specified by the specifying unit is a thread that can be browsed by the doctor who has made an acquisition request by the receiving unit according to the user information of the storage unit This is an example of a generating unit that generates a screen capable of referring to the contents of a thread.

When the processing from step S1502 to step S1510 is executed for all the thread data acquired in step S1501, the processing in FIG. 15 ends.
Next, details of the processing in step S1211 will be described with reference to FIG.

  FIG. 16 is a diagram showing an example of a flowchart showing details of the processing in step S1211.

  In step S1601, the SNS server 104 generates display data of the thread participation request screen 901 of the thread whose participation request button 507 is pressed by a user's mouse operation or the like, and transmits the display data of the thread participation request screen 901 to the PC 301. .

  The PC 301 that has received the display data of the thread participation request screen 901 from the SNS server 104 displays the thread participation request screen 901 on the display 210 of the PC 301 in step S1602.

  In step S1603, the PC 301 stands by until an operation is received from the user via the thread participation request screen 901, a message is input, and the send button (904 of the thread participation request screen 901) is pressed by the user's operation of the mouse or the like. In step S1604, the PC 301 transmits to the SNS server 104 a request for participation in a thread in which the participation request button 507 is pressed by a user's mouse operation or the like.

  When the SNS server 104 receives a request for participation in a thread in which the participation request button 507 is pressed by a user's mouse operation or the like, the SNS server 104 analyzes the request in step S1605.

  In step S1606, the SNS server 104 adds a message indicating that a participation request has been made as a message from the system in the corresponding thread. Specifically, the received participation request message is registered in the thread message data 800 with the thread ID of the thread to which the participation request message is transmitted.

  Next, in step S1607, the SNS server 104 adds the user who transmitted the participation request message to 605 of the thread data 600 of FIG.

  Finally, in step S1608, the SNS server 104 regenerates the thread list screen 501 in which the participation request button 507 is changed to an inoperable button, and transmits the regenerated thread list screen 501 to the PC 301 in step 1109. .

In step S1610, after receiving the regenerated thread list screen 501 from the SNS server 104, the PC 301 updates the thread list screen 501 displayed on the display 210 of the PC 301 using the received thread list screen 501. The process of FIG. 16 is terminated.
Next, details of the processing in step S1213 will be described with reference to FIG.

  FIG. 17 is a diagram showing an example of a flowchart showing details of the processing in step S1213.

  In step S1701, the SNS server 104 analyzes the message display request. Specifically, in the thread list screen 501, the thread ID of the thread whose title 504 is pressed is specified by the user's operation with the mouse or the like.

  In step S1702, the SNS server 104 searches the thread message data 800, and acquires a message having the same thread ID and thread ID 802 specified in step S1701.

  In step S1703, the SNS server 104 generates screen data (thread detail screen 701 in FIG. 7) of the message list acquired in step S1702, and stores it in the RAM 203 of the SNS server 104.

  In step S1704, the SNS server 104 determines whether or not the message data acquired in step S1702 includes a thread participation request message from the system, and the message list display executor is the owner of the corresponding thread.

  There is a thread participation request message (in the example of thread message data 800, the message ID 1010 corresponds), and the message list display executor is the owner of the thread (the thread ID 802 of the message data acquired in step S1702) If the thread owner 603 of the thread ID 601 of the matching thread data 600 is the message list display executor), the process advances to step S1705, and there is no thread participation request message or the message list display executor is the owner of the corresponding thread. If not, the process proceeds to step S1706.

In step S1705, the SNS server 104 stores data of buttons for operating whether to participate in the thread in the corresponding part of the message on the thread detail screen 701 stored in the RAM 203 (apply / reject participation request button 703 in FIG. 7). Is added.
In step S1706, the SNS server 104 transmits a thread detail screen 701 to the PC 301.

  In step S1707, the PC 301 that has received the thread detail screen 701 from the SNS server 104 displays the thread detail screen 701 on the display 210 of the PC 301. Perform a loop. If there is an operation from the user, in step S1709, the PC 301 transmits the operation content from the user to the SNS server 104.

  In step S1710, when the SNS server 104 receives the operation content from the user from the PC 301, the SNS server 104 determines the operation content from the user.

  If it is determined in step S1710 that the operation content from the user is an operation for approving the participation request to the thread (when the “approval” button is pressed among the approval / rejection buttons 703 of the participation request in FIG. 7) ) In step S1711, the SNS server 104 adds the information of the user who has requested to participate in the thread to the participant 604 of the thread in the thread data 600 of FIG.

  If it is determined in step S1710 that the operation content from the user is an operation for rejecting the participation request, in step S1712, the SNS server 104 indicates the participation rejection 606 of the corresponding thread in the thread data 600 in FIG. Add information about the user who requested to join.

  In step S1713, the SNS server 104 adds a thread participation request approval / rejection message to the corresponding thread (in the example of the thread message data 800, the message ID 1011 corresponds).

  If it is determined in step S1710 that the operation is other operation, in step S1714, the SNS server 104 causes the message input operation by the user (a message is input to 704 in FIG. 7 and the send button is pressed by the user using the mouse or the like). Judgment)

  If it is determined in step S1714 that the message input operation is performed by the user, in step S1715, the SNS server 104 adds the message content input by the user to the thread message data 800.

  If it is determined in step S1714 that the operation is other than the message input operation by the user, in step S1716, the SNS server 104 determines whether the operation is an end operation, and performs processing for closing the thread details screen 701 if the operation is an end operation. If it is not an end operation, other processing is performed in step S1717.

  In step S1718, the SNS server 104 regenerates the thread detail screen 701, transmits the regenerated thread detail screen 701 to the PC 301, and the PC 301 repeats step S1707 and subsequent steps.

This is the end of the description of FIG.
Above, description of each process performed in PC301 or SNS server 104 in this invention is complete | finished.

  As described above, according to the present invention, when a thread acquisition request for each patient is received from a doctor who interprets an examination for the patient, the thread information about the patient is secured with respect to the patient information. However, it can be provided to the doctor as much as possible.

  In addition, according to the present invention, by showing the title of a thread in which the responsible interpreting doctor is not participating to the interpreting doctor in charge of the interpretation request (examination) for a certain patient, the responsible interpreting doctor is informed about the patient. Threads that are not participating by the relevant interpreting physician will not be able to view the details unless approved by the thread owner, thereby protecting the patient's personal information. Can increase security.

  In addition, according to the present invention, information on a thread other than the thread in which the user is participating in a user other than the interpreting doctor in charge of the interpretation request (examination) for the patient who is the subject of the thread search is provided for the user. It is possible to accurately manage the disclosure range of the patient's personal information. That is, security can be enhanced in terms of protecting patient personal information.

  By showing the title of the thread for which the corresponding interpreting doctor is not participating to the interpreting doctor in charge of the interpretation request (examination) for the patient who is the subject of the thread search, In addition, it is possible to recognize that a message is being exchanged, and to obtain an effect of being able to guide to the thread of the patient who is not participating. Moreover, about the thread | sled which the said radiographer in charge does not participate, the disclosure range of a patient's personal information can be managed exactly by not browsing a detail, unless it is approved by the thread owner. That is, security can be enhanced in terms of protecting patient personal information.

  The present invention can be implemented as a system, apparatus, method, program, storage medium, or the like, and can be applied to a system including a plurality of devices. You may apply to the apparatus which consists of one apparatus.

  Note that the present invention includes a software program that implements the functions of the above-described embodiments directly or remotely from a system or apparatus. The present invention also includes a case where the system or the computer of the apparatus is achieved by reading and executing the supplied program code.

  Accordingly, since the functions of the present invention are implemented by computer, the program code installed in the computer also implements the present invention. In other words, the present invention includes a computer program itself for realizing the functional processing of the present invention.

  In that case, as long as it has the function of a program, it may be in the form of object code, a program executed by an interpreter, script data supplied to the OS, or the like.

  Examples of the recording medium for supplying the program include a flexible disk, hard disk, optical disk, magneto-optical disk, MO, CD-ROM, CD-R, and CD-RW. In addition, there are magnetic tape, nonvolatile memory card, ROM, DVD (DVD-ROM, DVD-R), and the like.

  As another program supply method, a browser on a client computer is used to connect to an Internet home page. The computer program itself of the present invention or a compressed file including an automatic installation function can be downloaded from the homepage by downloading it to a recording medium such as a hard disk.

  It can also be realized by dividing the program code constituting the program of the present invention into a plurality of files and downloading each file from a different homepage. That is, a WWW server that allows a plurality of users to download a program file for realizing the functional processing of the present invention on a computer is also included in the present invention.

  In addition, the program of the present invention is encrypted, stored in a storage medium such as a CD-ROM, distributed to users, and key information for decryption is downloaded from a homepage via the Internet to users who have cleared predetermined conditions. Let It is also possible to execute the encrypted program by using the downloaded key information and install the program on a computer.

  Further, the functions of the above-described embodiments are realized by the computer executing the read program. In addition, based on the instructions of the program, an OS or the like running on the computer performs part or all of the actual processing, and the functions of the above-described embodiments can also be realized by the processing.

  Further, the program read from the recording medium is written in a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer. Thereafter, the CPU of the function expansion board or function expansion unit performs part or all of the actual processing based on the instructions of the program, and the functions of the above-described embodiments are realized by the processing.

The above-described embodiments are merely examples of implementation in carrying out the present invention, and the technical scope of the present invention should not be construed as being limited thereto. That is, the present invention can be implemented in various forms without departing from the technical idea or the main features thereof.

104 SNS server 108 Database 301 PC

Claims (6)

Storage means for storing a thread managed in association with patient information including an examination, user information for managing a user who can view each thread, and doctor information for managing a doctor associated with an examination;
Accepting means for receiving a thread acquisition request from a doctor with patient information as a key;
In accordance with the patient information received by the receiving means, a specifying means for specifying a thread associated with the patient information from the storage means,
When the thread specified by the specifying means is a thread that can be viewed by the user information in the storage means by the doctor who has made an acquisition request by the receiving means, the contents of the thread can be referred to A generating means for generating a screen, and
The generating unit may be configured to receive the thread even if the thread specified by the specifying unit is a thread that is not viewable by the user information stored in the storage unit by a doctor who has made an acquisition request by the receiving unit. When the doctor who made the acquisition request in step 1 is included in the doctor information, a screen capable of identifying the thread is generated.   The generation means is a thread in which the thread specified by the specifying means cannot be viewed by the user information stored in the storage means by a doctor who has made an acquisition request by the receiving means, and acquired by the receiving means The information processing system according to claim 1, wherein when the doctor who made the request is not included in the doctor information, a screen not including the thread is generated. A browsing request accepting unit that accepts a request to browse the content of a thread that is not related to the doctor among the threads related to the patient;
A browsing permission instruction receiving means for receiving an instruction as to whether or not to allow a doctor who has received a browsing request for the thread by the browsing request receiving means to permit reference to the content of the thread;
When the generation unit receives an instruction to allow the browsing permission instruction receiving unit to refer to the content of the thread, the doctor who has made a request to browse the content of the thread by the browsing request receiving unit The information processing system according to claim 1, wherein a screen capable of referring to the content of the information is generated. The storage means further manages thread creation user information that created the thread,
The information processing system according to claim 3, wherein the browsing permission instruction receiving unit receives an instruction as to whether or not to permit reference to the contents of a thread from the thread creation user stored in the storage unit. Information processing system comprising storage means for storing a thread managed in association with patient information including an examination, user information for managing a user who can view each thread, and doctor information for managing a doctor associated with the examination Control method,
The accepting step of the information processing system accepts a thread acquisition request from a doctor using patient information as a key; and
A specifying step of specifying a thread associated with the patient information from the storage unit in accordance with the patient information received by the receiving step by the specifying unit of the information processing system;
When the generation unit of the information processing system is a thread that can be viewed by the user information stored in the storage unit by the doctor who has made an acquisition request in the reception step. Has a generation process for generating a screen that can refer to the contents of the thread,
The receiving step is also performed when the thread specified in the specifying step is a thread that cannot be viewed by the user information stored in the storage unit by the doctor who has made an acquisition request in the receiving step. When the doctor who made the acquisition request in step 1 is included in the doctor information, a screen capable of identifying the thread is generated. The computer program for functioning a computer as each means of the information processing system of any one of Claims 1 thru | or 4.

Images