JP2012014224A - Medical data editing system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To allow a plurality of operators to edit the same medical data in the same timing, and to reflect editing contents of each of the operators under an agreement among operators who edit the target medical data.SOLUTION: A medical data editing system includes: a medical data storage section for storing medical data; an editing section for editing medical data in accordance with editing instructions from a plurality of terminals; a history information storage section for storing, for the unit of medical data, history information containing user identification information identifying an operator who performs editing each time the editing is completed; a production section for producing third medical data by matching second medical data which are created by editing first medical data through the editing section, with the first medical data in response to an instruction from a terminal; and a notification section for distributing an inquiry of whether to update the first medical data stored in the medical data storage section with the third medical data, to an operator who edits the first medical data in the past, on the basis of the history information.

Description

  Embodiments of the present invention can edit medical data on a server from a plurality of terminals in a medical data editing system that centrally manages storage and management of medical data including medical images and the like and processing on the medical data. It relates to the technology.

  2. Description of the Related Art In recent years, with the improvement of network computer technology and cost reduction, medical systems that request processing from a client to a server via a network and display the result on the client have been introduced.

  By introducing such a medical system, data and software can be centrally managed by a server. As a result, when the medical data on the server is shared by a plurality of operators (operator terminals), or when a plurality of operators edit the data via the terminals, the editing contents are unified. It becomes possible to manage. The medical system also has an advantage that the functions of the server can be used from a plurality of terminals using a common interface via a network regardless of the terminal performance.

  On the other hand, in the system as described above, a plurality of operators may edit the same medical data almost at the same time. In such a case, the editing content of one operator may be overwritten by the editing of another operator due to differences in the timing of reading the medical data to be edited by multiple operators and the timing of writing the medical data after editing. May occur. In order to avoid such a situation, when an operator updates medical data, the editing content performed by the operator is matched with the editing content performed by another operator. A mechanism for updating medical data is required.

  As one method for solving this problem, when a certain operator is editing data, there is a method in which access restriction is provided for the data so that other operators cannot edit the data. Thereby, since only one operator can update each medical data at the same time, the edited contents of each operator are not overwritten. However, in such a case, there is a problem that other operators cannot edit the data until the operation of the operator who is editing the data is completed, and the work efficiency is lowered.

JP 2008-77600 A

  The embodiment of the present invention solves the above-described problem, and enables a plurality of operators to edit the same medical data at the same time and merges editing contents performed by each operator. And confirming the validity of the contents of the merge work, thereby enabling the data to be updated under the agreement between the operators who edited the data.

In order to achieve the above object, according to a first aspect of the present invention, a plurality of terminals, a medical data storage unit for storing medical data, and the medical data can be edited according to an editing instruction from the plurality of terminals. A medical data editing system including a server including an editing unit that performs history information including user identification information for identifying an operator who performed the editing each time the editing is completed. A history information storage unit stored for each, and matching the second medical data created by editing the first medical data by the editing unit with the first medical data in accordance with an instruction from the terminal And generating the third medical data and storing the first medical data in the medical data storage unit to the operator who edited the first medical data in the past based on the history information. The in which the first medical data is a medical data editing system characterized by comprising a notification unit that distributes whether the query is updated with the third medical data.
According to a second aspect of the present invention, a plurality of terminals, a medical data storage unit that stores medical data including one or both of medical images and reports, and an editing instruction from one or more of the terminals, A medical data editing system comprising: an editing unit for editing the medical data, the server each time the editing using one of the plurality of terminals is completed A history information storage unit that stores, for each medical data, history information including user identification information that identifies an operator who has performed editing, and the editing unit is stored in the medical data storage unit based on an instruction from the terminal. When the second medical data is generated by editing the first medical data, the medical data storage unit stores the second medical data at the time when the second medical data is generated. The first medical data and the second medical data are matched to each other to create a third medical data, and at least after the second medical data is generated Based on the history information stored in the history information storage unit, one or more operators who have edited the first medical data in the past are specified, and the specified operator is addressed to the medical data storage unit. Based on a response to the inquiry from the identified operator and a notification unit that distributes an inquiry as to whether or not to update the stored first medical data with the third medical data, the medical data A determination unit for determining whether or not the first medical data stored in the storage unit is updated with the third medical data; and the medical data storage unit when the determination unit determines to update Remembered The first medical data are a medical data editing system characterized by comprising an updating unit that updates at the third medical data.
According to a third aspect of the present invention, the second medical data is created by editing the medical data storage unit for storing the medical data and the first medical data stored in the medical data storage unit. An editing unit, a creation unit that creates third medical data by matching the first medical data and the second medical data, and an operator who edited the first medical data in the past In addition, a notification unit that distributes an inquiry as to whether or not to update the first medical data stored in the medical data storage unit with the third medical data, a display unit, and a display area of the display unit Is divided into three areas, the first medical data at the end of editing and the second medical data are displayed side by side so that they can be compared in the first area, and the editing is completed in the second area Said first medical data and said second An alignment operation key for aligning the medical data, and the third medical data in which the first medical data and the second medical data are aligned by the operation of the alignment operation key; In the third area, the medical data editing system includes a display control unit that displays an instruction key that instructs the notification unit to deliver the inquiry.

1 is a block diagram of a medical data editing system according to an embodiment. It is an example of the data structure of history information. It is an example of the screen which merges a medical image. It is an example of the screen which merges a medical image. It is an example of the screen which merges a medical report. It is a figure for demonstrating the flow of a process in the case of editing and merging medical data with the client 2A. It is an example of the master data of a medical image. It is an example of the data which the operator edited the master data of the medical image. It is a figure for demonstrating the flow of a process at the time of merging with the client 2A, when master data is updated by the other client while editing medical data with the client 2A. It is an example of the data of the medical image in which the edit by the other operator was updated. It is an example of merge data of a medical image that has been merged by an operator. It is an example of the data for an update determination part to manage the weighting of a response. It is an example of the data for an update determination part to manage the weighting of a response.

(First embodiment)
A medical data editing system according to a first embodiment will be described with reference to FIG. As shown in FIG. 1, the medical data editing system according to the present embodiment includes a server 1 and a plurality of clients 2A to 2C (the clients 2A to 2C correspond to “terminals”). In the medical data editing system according to the present embodiment, a server 1 and clients 2A to 2C are connected to be communicable via a network.

  In the medical data editing system according to the present embodiment, the operator edits medical data stored on the server 1 via any one of the clients 2A to 2C. At this time, the edited medical data is hereinafter referred to as “edit data”. When the medical data editing system according to the present embodiment updates medical data (hereinafter referred to as “master data”) that is the basis of editing data stored on the server 1 based on an instruction from the operator, The user compares the edited data with the master data at the time when the edited data is created, and creates data (hereinafter referred to as “merge data”) in which the editing contents applied to the edited data are matched. Hereinafter, this matching operation is referred to as “merge”.

  The medical data editing system according to the present embodiment is characterized in that it is inquired of another operator who has edited the master data in the past whether or not the master data on the server 1 is updated with the merge data. Details of this embodiment will be described below. First, the configuration of the medical data editing system according to the present embodiment will be described with reference to FIG. In the following description, it is assumed that the operator edits and merges medical data via the client 2A.

  The server 1 includes a medical data storage unit 11, a transmission / reception unit 16, a history information storage unit 18, a temporary data storage unit 12, a data editing unit 13, a merge data creation unit 14, a control unit 15, and a merge result. And an updating unit 17. Details of each configuration of the server 1 will be described below, focusing on the configuration that operates at each opportunity, divided into “editing medical data” and “merging medical data”.

(Editing medical data)
First, the operation when editing medical data will be described. Note that a part of this description includes a description of a configuration that operates in common at other occasions. Hereinafter, in the description of other triggers (when merging medical data), unless otherwise specified, each component operates in the same manner as described in this section.

  The medical data storage unit 11 stores medical data such as medical reports and medical images so that they can be read based on information included in the medical data. For example, in the case of a medical image, a desired medical image can be specified and extracted from “image ID”, “examination number”, “patient ID”, and the like.

  In addition, collection of medical images is performed one or more times for each examination. Further, one or a plurality of images are acquired as a series of images in one collection. Therefore, the medical image is composed of a plurality of images, and a part of the images constituting the medical image can be read out. Therefore, the medical image data associated with the examination number includes medical images associated with each collection unit. Accordingly, for example, a series of image data corresponding to the collection number can be extracted, or only image data can be specified and extracted.

  In the case of a medical report, a desired medical report can be specified and extracted from, for example, “patient ID”, “patient name”, “sex”, “birth date”, and the like. The medical data storage unit 11 may be configured to store, as a medical report, an interpretation report that summarizes findings on medical images, a patient chart, and the like.

  The transmission / reception unit 16 is configured so that each component in the server 1 transmits / receives data to / from a configuration other than the server 1 (for example, each configuration of the clients 2A to 2C) via the network. Thereafter, when each configuration in the server 1 transmits / receives data and commands to / from a configuration other than the server 1, each configuration in the server 1 transmits / receives data and commands via the transmission / reception unit 16.

  The temporary data storage unit 12 is a storage area for temporarily storing the editing data created by the data editing unit 13 and the merge data created by the merge data creating unit 14 (the data editing unit 13 and the merge data creating unit). 14 will be described later). The temporary data storage unit 12 only needs to be configured to store each data separately from the medical data stored in the medical data storage unit 11, and to identify and read each data. Therefore, the temporary data storage unit 12 and the medical data storage unit 11 may be configured by different storage devices, or the storage area of one storage device is divided into a plurality of areas, and each area is divided into the temporary data storage unit 12. Or it is good also as a structure allocated to the medical data storage part 11. FIG.

  The history information storage unit 18 is a storage area for storing history information related to the update of each medical data stored in the medical data storage unit 11. When the medical data (master data) that is the basis of editing stored in the medical data storage unit 11 is updated with the medical data edited based on an instruction from any of the operators of the clients 2A to 2C, at least History information including user identification information for identifying the updated operator is stored. At this time, the history information may include information indicating the date and time when the update is performed. Thereby, it becomes possible to distinguish history information based on information indicating date and time.

  For example, FIG. 2 is an example of a data structure of history information stored in the history information storage unit 18. In the example of FIG. 2, the data D1 indicates that the data is edited by the doctors Ua and Ub. Specifically, FIG. 2 shows that the doctor Ua creates or edits data D1 on 2011.10.10. In addition, the doctor Ub is editing the data D1 at 2010.01.13. Similarly, the data D2 indicates that the data has been edited by the doctor Uc, the doctor Ud, and the doctor Ue in the past.

  The history information stored in the history information storage unit 18 may be associated with terminal identification information for specifying a client (for example, one of the clients 2A to 2C) operated by an operator corresponding to the user identification information. Thereby, for example, it is possible to specify a client operated by the operator specified by the history information, and to transmit / receive data to / from the specified client. The history information may be associated with the operator's email address corresponding to the user identification information, so that a notification can be sent to the operator by email. In the following description, it is assumed that the terminal identification information is associated with history information, and the client operated by the operator is specified by specifying the operator based on the history information.

  When receiving an instruction for editing medical data from the client 2A via the control unit 15, the data editing unit 13 first extracts the specified medical data to be edited from the medical data storage unit 11 (the control unit 15 will be described later). To do). The data editing unit 13 outputs the extracted medical data to the control unit 15. Thereby, the control unit 15 can display the medical data extracted by the data editing unit 13 on a UI (User Interface) for editing the medical data.

  Next, the data editing unit 13 receives a notification regarding editing contents from the client 2A via the control unit 15, applies the editing specified by the notification to the extracted medical data, and creates editing data. For example, when the addition of annotation is instructed as editing content, editing data is created by adding data corresponding to the annotation (for example, data composed of tags) based on the extracted medical data .

  The data editing unit 13 stores the created editing data in the temporary data storage unit 12 (the temporary data storage unit 12 will be described later). At this time, the data editing unit 13 may be configured to output the created editing data to the control unit 15. Thereby, the control unit 15 can display the editing data on the UI as a result of the editing process. The data editing unit 13 corresponds to an editing unit.

  The control unit 15 includes an editing UI generation unit 151 and a merge UI generation unit 152. Based on an instruction from a client (for example, the client 2A), a UI for editing medical data or a merge of medical data Is transmitted to the client 2A receiving the instruction and displayed. First, details of the editing UI generation unit 151 will be described, and then a series of operations of the control unit 15 at the time of editing medical data will be described. The merge UI generation unit 152 will be described later.

  The editing UI generation unit 151 generates a UI for editing medical data (hereinafter referred to as “editing UI”) based on an instruction from the control unit 15. The editing UI generated by the editing UI generation unit 151 is transmitted to the UI control unit 22 of the client 2A and displayed as a UI on the client 2A (the UI control unit 22 will be described later). At this time, the editing UI generation unit 151 may be configured to receive medical data to be edited from the control unit 15 and display the medical data on the editing UI. In addition, when editing data is received from the control unit 15 as a result of editing the medical data, the editing data may be displayed on the editing UI.

  Next, the operation of the control unit 15 when editing medical data will be described. When editing of medical data is instructed from the client 2A, the control unit 15 first instructs the data editing unit 13 to extract the instructed medical data to be edited. When receiving the medical data to be edited from the data editing unit 13, the control unit 15 outputs the received medical data to the editing UI generation unit 151 and instructs the editing UI generation unit 151 to generate the editing UI.

  The control unit 15 transmits and displays the editing UI generated by the editing UI generation unit 151 to the UI control unit 22 of the client 2A (the UI control unit 22 will be described later). Thus, the operator can edit the extracted medical data and create edit data by operating the edit UI on the client 2A.

  Next, when the operator gives an instruction to edit medical data via the editing UI, the control unit 15 receives the editing content from the UI control unit 22. The control unit 15 notifies the data editing unit 13 of the received editing content, and instructs the data editing unit 13 to edit medical data. In response to an instruction from the control unit 15, edited data created by editing the medical data by the data editing unit 13 is stored in the temporary data storage unit 12.

  When receiving the editing data as the editing result from the data editing unit 13, the control unit 15 outputs the editing data to the editing UI generation unit 151 and displays the editing data on the editing UI. The control unit 15 transmits the editing UI on which the editing data is displayed by the editing UI generation unit 151 to the UI control unit 22 of the client 2A and displays it. As a result, the operator can confirm the editing result (editing data) on the editing UI.

(Merging medical data)
Next, an operation when merging medical data will be described.

  When the merge data creation unit 14 receives an instruction to merge edit data and master data (hereinafter simply referred to as “merge”) from the client 2A via the control unit 15, the merge data creation unit 14 first stores the designated edit data as temporary data. The master data that is the basis of the edited data is extracted from the medical data storage unit 11. The merge data creation unit 14 outputs the extracted edit data and master data to the control unit 15. Thus, the control unit 15 can display the edit data and the master data on the UI for creating merge data.

  Next, the merge data creation unit 14 receives a notification regarding the contents of the merge process from the client 2A via the control unit 15, and executes the merge process instructed by the notification based on the extracted edit data and master data. Create merge data. Specifically, based on the master data or edit data, edit contents already applied to the master data (for example, addition of annotations and ROI: Region Of Interest) and edit contents applied to the edit data Then, merge data is created by adding desired edit contents (instructed by the operator) to the base medical data or deleting them from the base medical data.

  The merge data creation unit 14 stores the created merge data in the temporary data storage unit 12. At this time, the merge data creation unit 14 may be configured to output the created merge data to the control unit 15. Thereby, the control unit 15 can display the merge data on the UI as a result of the merge process. The merge data creation unit 14 corresponds to a creation unit.

  Next, the configuration of the control unit 15 will be described. First, details of the merge UI generation unit 152 will be described, and then a series of operations of the control unit 15 at the time of merging medical data will be described.

  The merge UI generation unit 152 merges the edit data and the master data when reflecting the edit contents applied to the medical data when the edit data is created in the base medical data (master data). A UI for creating merge data for updating the master data (hereinafter referred to as “merge UI”) is generated.

  For example, FIG. 3 is an example of a screen for merging medical images. First, the merge UI generation unit 152 receives edit data and master data that is the basis of the edit data from the control unit 15, and displays a comparison display area V1 that displays both of them in a comparable manner on the merge UI. At this time, the control unit 15 outputs the latest master data to the merge UI generation unit 152 when the operator starts the merge operation, that is, when the merge UI generation unit 152 is instructed to create the merge UI. For example, in FIG. 3, the master data Da3 (in-DB image) and the edit data Da2 (user image) are displayed in the comparison display area V1 so that they can be compared. At this time, the master data Da3 displayed in the comparison display area V1 is the latest master data at this time, and it is confirmed that ROIM2 and M3 have been added by another operator during the creation of the edit data Da2. Show.

  In addition, the merge UI generation unit 152 merges the edit data and the master data, and displays a temporary data creation area V2 for creating and displaying the merge data on the merge UI. For example, in FIG. 3, merge data Da4 obtained by merging master data Da3 (in-DB image) and edit data Da2 (user image) is displayed in the temporary data creation area V2. In FIG. 3, ROIM2 and M3 added to the master data Da3 and annotation M1 added to the edit data Da2 are added to the merge data Da4. At this time, the merge UI generation unit 152 displays the medical data reflecting all the editing contents applied to both the master data and the edit data, such as the merge data Da4, as the medical data to be displayed first when the merge UI is displayed. It is good also as a structure to display, and it is good also as a structure which displays the medical data in which edit content is not reflected at all.

  In addition, the merge UI generation unit 152 displays an Add button associated with each of the master data and the edit data and a Delete button associated with the merge data. For example, in FIG. 3, the operator selects necessary edit contents from the edit contents applied to the master data Da3 or the edit contents applied to the edit data Da2 by the Add button, and adds them to the merge data Da4. Is possible. Further, the operator can select and delete unnecessary editing contents from the editing contents added to the merge data Da4 by using the Delete button.

  For example, FIG. 4 shows an example of a screen for merging medical images, and shows an example in which a part of the edited contents of the master data is not reflected on the merged image. Specifically, in FIG. 4, only ROIM3 added to the master data Da3 and the annotation M1 added to the edited image are reflected in the merge data Da5. That is, when a medical image such as the merge data Da4 in FIG. 3 is displayed in the initial display, the operator selects ROIM2 displayed on the merge data and operates the Delete button to merge ROIM2. Indicates that the data has been deleted.

  Further, for example, an operation means for correcting existing editing contents may be provided, such as the Modify button in FIG.

  The merge UI generation unit 152 also displays an update instruction unit V3 for transmitting an instruction to update the master data stored in the medical data storage unit 11 with the merge data created by the merge UI. The medical data editing system according to the present embodiment inquires of the operator who has edited the master data in the past whether or not to update the master data that is the basis of the created merge data (for details of this operation) Will be described later). For example, in FIG. 3, when the update instruction unit V3 is operated, whether or not to update the master data Da3 stored in the medical data storage unit 11 with the merge data Da4 depends on the operator who edited the master data Da3 in the past ( For example, it is transmitted to the client operated by the doctor Ua and the doctor Ub).

  The merge UI generation unit 152 is configured to display a history display area V4 for displaying the editing history of the master data Da3 on the merge UI so as to be able to confirm the operator who is the inquiry transmission destination. Also good. In this case, the history information may be extracted from the history information storage unit 18.

  Similarly, when merging medical reports, the merge UI generating unit 152 displays the comparison display area V1, the temporary data creation area V2, and the update instruction means V3 on the merge UI. For example, FIG. 5 is an example of a screen for merging medical reports. In FIG. 5, the medical report master data Ra3 and the medical report editing data Ra2 are displayed in the comparison display area V1 so as to be comparable.

  Further, as shown in FIG. 5, the editing data Ra2 and the master data Ra3 are merged, and a temporary data creation area V2 for creating and displaying the merge data Ra4 is displayed on the merge UI. When the merge data Ra4 is displayed, the contents of the merge process may be displayed in an identifiable manner. For example, as shown in FIG. 5, the edited content M4 indicates that a part of the content of the master data Ra3 has been modified. The editing content M5 indicates that a part of the master data Ra3 has been deleted. The editing content M6 indicates that part (or all) of the editing data Ra2 has been added.

  Next, a series of operations of the control unit 15 at the time of merging medical data will be described. When the editing of the medical data is completed, the control unit 15 executes processing related to the display of the merge UI. This will be specifically described below. First, the control unit 15 instructs the merge data creation unit 14 to extract edit data to be merged and master data that is the basis of the edit data. Upon receiving edit data and master data from the merge data creation unit 14, the control unit 15 outputs the received edit data and master data to the merge UI generation unit 152, and instructs the merge UI generation unit 152 to generate a merge UI. To do.

  The control unit 15 transmits and displays the merge UI generated by the merge UI generation unit 152 to the UI control unit 22 of the client 2A. Thus, the operator can merge the edit data and the master data and create merge data by operating the merge UI on the client 2A.

  When the operator instructs to merge edit data and master data via the merge UI, the control unit 15 receives the contents of the merge process from the UI control unit 22. The control unit 15 notifies the merge data creation unit 14 of the contents of the received merge process, and instructs the merge data creation unit 14 to create merge data. Based on an instruction from the control unit 15, merge data created by merging edit data and master data by the merge data creation unit 14 is stored in the temporary data storage unit 12.

  When receiving merge data as a merge result from the merge data creation unit 14, the control unit 15 outputs the merge data to the merge UI generation unit 152 and displays the merge data on the merge UI. The control unit 15 causes the merge UI generation unit 152 to transmit and display the merge UI on which the merge data is displayed to the UI control unit 22 of the client 2A. As a result, the operator can check the merge result (merge data) on the merge UI.

  Next, when the operator is instructed to update the master data with the merge data via the merge UI, the control unit 15 notifies the merge result update unit 17 of the master data and the merge data, and the master data is transferred to the merge data. An instruction is given to update the data (the merge result update unit 17 will be described later).

  The merge result update unit 17 includes an inquiry notification unit 171 and an update determination unit 172. When the merge result update unit 17 receives an instruction from the control unit 15 regarding the update of the master data with the merge data, the merge result update unit 17 first extracts the merge data instructed by the control unit 15 from the temporary data storage unit 12. Next, the merge result update unit 17 outputs the extracted merge data to the query notification unit 171 and instructs the query notification unit 171 to distribute a query related to master data update. The merge result update unit 17 may be configured to directly receive merge data from the control unit 15.

  When the query notification unit 171 is instructed by the merge result update unit 17 to deliver a query regarding master data update, the query notification unit 171 first extracts history information corresponding to the master data to be updated from the history information storage unit 18. The inquiry notifying unit 171 specifies an operator who has edited the master data to be updated in the past from the extracted history information. Next, the inquiry notification unit 171 distributes the merge data received from the merge result update unit 17 to a client (for example, any one of the clients 2A to 2C) operated by each identified operator, and also updates the master data to be updated. A query for confirming whether update is possible with merge data (hereinafter referred to as “update confirmation query”) is distributed to the client operated by each identified operator.

  The inquiry notifying unit 171 may be configured not to distribute the update confirmation inquiry to the client operated by the operator who created the merge data. In this case, the inquiry notification unit 171 may receive the user identification information of the operator who created the merge data from the control unit 15. As a result, the inquiry notifying unit 171 can exclude the client operated by the operator corresponding to the user identification information from the clients that deliver the update confirmation inquiry.

  Further, the inquiry notifying unit 171 may be configured to transmit master data together as a comparison target of merge data. In this case, the merge result update unit 17 may extract the master data from the medical data storage unit 11 and output the master data to the inquiry notification unit 171 together with the merge data. As a result, the inquiry notifying unit 171 can distribute the master data together with the merge data when distributing the update confirmation inquiry.

  Also, the inquiry notifying unit 171 outputs a list of operators who have delivered the update confirmation inquiry to the update determining unit 172 (the update determining unit 172 will be described later). When each client (any one of the clients 2A to 2C) is operated and an answer is made to the update confirmation inquiry, the inquiry response unit 24 of each client transmits a response to the update determination unit 172 (inquiry response unit) 24 will be described later). Based on the list of operators received from the query notification unit 171, the update determination unit 172 can tabulate responses to the update confirmation query transmitted to each operator (details of this operation will be described later). To do).

  The inquiry notifying unit 171 may be configured to provide a response time limit for the update confirmation inquiry when the update confirmation inquiry is distributed to the client operated by each operator. This response time limit may be set in advance in the inquiry notification unit 171 or may be configured so that the operator can set it from the client 2A via the UI. In the case of providing a response time limit, the inquiry notifying unit 171 may output the response time limit to the update determining unit 172 when an update confirmation inquiry is distributed to each client. As a result, the update determination unit 172 determines that there is no response to the update confirmation inquiry within the response time limit, and can execute processing in the case of no response without waiting for a response. (An example of processing in the case of no response will be described later). The inquiry notification unit 171 corresponds to a notification unit. When configured so that the operator can set the response time limit, the inquiry notification unit 171 may be configured to receive the response time limit specified by the operator via the UI via the control unit 15.

  The update determination unit 172 first receives a list of operators that have delivered an update confirmation query from the query notification unit 171. Thereafter, the update determination unit 172 receives a response to the update confirmation query from the client operated by each operator who has delivered the update confirmation query. The update determination unit 172 aggregates the received responses, and determines that the master data can be updated with the merge data when the response that the master data can be updated with the merge data exceeds the number of responses that are not. Is output to the merge result update unit 17. When the response that the master data can be updated with the merge data is less than the number of responses that are not, the update determination unit 172 determines that the master data cannot be updated with the merge data. For example, when an inquiry for update confirmation is delivered to the client operated by three operators by the query notifying unit 171, when a response indicating that the update is possible from the client operated by two operators, which is a majority, The update determination unit 172 determines that the master data can be updated with the merge data.

  Note that, when the number of responses that can be updated with merge data is the same as the number of responses that are not, the operation may be determined to be updatable or may be determined to be unupdatable. However, it may be configured so that it can be changed by an instruction from the operator.

  Further, the update determination unit 172 is configured to be provided with a time limit for waiting for a response to an update confirmation inquiry, that is, a response time limit. The update determination unit 172 receives the instruction from the inquiry notification unit 171 and sets a response time limit. By providing this response time limit, if there is no response to the update confirmation inquiry within the response time limit, the update determination unit 172 determines that there is no response and can divide the processing. For example, if an update confirmation query is delivered to doctors Ua, Ub, and Uc who are operators who have edited master data in the past, and there is a response only from doctors Ua and Ub within the response time limit, an update to doctor Uc Confirmation queries are processed as no response.

  The operation of the update determination unit 172 when no response is detected may be configured to be set in advance. For example, the update determination unit 172 may be configured to perform determination only in a range where there is a response when no response is detected. Further, the update determination unit 172 may be configured to determine that update is not possible when there is no response. In this case, the update determination unit 172 may be configured to determine that the update is possible when the response that the update is possible occupies a majority of the operators who have delivered the update confirmation inquiry. Further, the update determination unit 172 may be configured to determine that the update is possible when the response that the update is possible occupies a majority of the received responses.

  The operation when the update determination unit 172 detects no response may be configured so that the operator can set the operation from the client 2A via the UI. In this case, the update determination unit 172 may be configured to receive, via the control unit 15, an operation when a no-response specified by the operator via the UI is detected. The update determination unit 172 corresponds to a determination unit.

  The merge result update unit 17 receives the determination result from the update determination unit 172, and when the master data can be updated with merge data, the merge result update unit 17 uses the merge data instructed from the control unit 15 and the medical data also instructed from the control unit 15. The master data on the data storage unit 11 is updated. The merge result update unit 17 may be configured to store the merge data in the medical data storage unit 11 as medical data different from the master data when the update determination unit 172 determines that the update is not possible. The merge data may be discarded without being stored in the unit 11.

  Note that the edit data and merge data stored in the temporary data storage unit 12 become unnecessary after the merge result update unit 17 completes the above processing. For this reason, the edit data and the merge data stored in the temporary data storage unit 12 may be discarded at the timing when the above-described processing by the merge result update unit 17 is completed, or may be discarded after a predetermined period has elapsed. It is good also as a structure. The merge result update unit 17 corresponds to an update unit.

  Next, the configuration of the client 2A will be described. The client 2A includes a transmission / reception unit 21, a UI control unit 22, a UI 23, and an inquiry response unit 24. The client 2B and the client 2C have the same configuration.

  The transmission / reception unit 21 is configured so that each configuration in the client 2A transmits and receives data via a network with a configuration other than the client 2A (for example, each configuration of the server 1). Thereafter, when each configuration in the client 2A transmits / receives data and commands to / from a configuration other than the client 2A, each configuration in the client 2A transmits / receives data and commands via the transmitting / receiving unit 21.

  The UI 23 includes an input unit 231 that receives an input from the operator and an output unit 232 that outputs information to the operator.

  The UI control unit 22 causes the control unit 15 to transmit an editing UI or a merge UI (or information for displaying each UI) based on an instruction from the operator, and receives the UI 23 from the control unit 15. Switch to UI. As a result, the UI operation screen received by the UI control unit 22 is displayed on the output unit 232. The UI control unit 22 transmits an operation instruction input by the operator via the input unit 231 to the control unit 15 along the editing UI or the merge UI. The operation of the UI control unit 22 will be specifically described below.

  When the operator is instructed to edit the medical data, the UI control unit 22 causes the control unit 15 to generate an editing UI for editing the medical data (master data) instructed by the operator. To send. When receiving the editing UI from the control unit 15, the UI control unit 22 switches to the editing UI that has received the UI 23.

  When the operator is instructed to edit medical data via the editing UI, the UI control unit 22 receives the editing content instructed from the input unit 231 and transmits the received editing content to the control unit 15. The control unit 15 receives the edited content and instructs the data editing unit 13 to edit the medical data.

  When the UI control unit 22 receives the editing UI reflecting the editing result from the control unit 15, the UI control unit 22 updates the UI 23 with the received editing UI. As a result, the operator can confirm the editing result (editing data) on the editing UI.

  When the editing of the medical data is completed and the merge UI is received from the control unit 15, the UI control unit 22 switches to the merge UI that has received the UI 23.

  When the operator is instructed to merge the edit data and the master data via the merge UI, the UI control unit 22 receives the contents of the merge process instructed from the input unit 231 and displays the contents of the received merge process. Transmit to the control unit 15. In response to the contents of the merge process, the control unit 15 instructs the merge data creation unit 14 to merge the edit data and the master data.

  When the UI control unit 22 receives from the control unit 15 the merge UI reflecting the merged result of the edited data and the master data (displays the merge data), the UI control unit 22 updates the UI 23 with the received merge UI. As a result, the operator can check the merge result (merge data) on the merge UI.

  Next, when the operator is instructed to update the master data by the merge data via the merge UI, the UI control unit 22 notifies the control unit 15 of the update instruction. Upon receiving this notification, the control unit 15 notifies the merge result update unit 17 of the master data and the merge data, and instructs the master data to be updated with the merge data.

  The inquiry response unit 24 receives merge data and an update confirmation inquiry from the inquiry notification unit 171 (that is, an inquiry for checking whether or not the update target master data can be updated with the merge data). The inquiry response unit 24 displays the received merge data so as to be visible on the output unit 232, displays the contents of the update confirmation inquiry, and displays the response means for the inquiry together. The response means may be, for example, a button for selecting whether or not the master data to be updated can be updated with merge data, and displays a link for each response of whether or not the update is possible, depending on the clicked link It may be configured to recognize which response has been selected.

  When the response to the update confirmation query displayed on the output unit 232 is input from the operator via the input unit 231, the query response unit 24 transmits the input response to the update determination unit 172. The update determination unit 172 counts the responses and determines whether or not the update target master data can be updated with the merge data.

(Operation 1)
Next, a series of operations of the medical data editing system according to the first embodiment will be described with reference to FIGS. First, with reference to FIG. 6, the operation when the master data is edited by the client 2A and the edited master data and the master data on the server 1 are merged will be described. FIG. 6 is a diagram for explaining the flow of processing when medical data is edited and merged by the client 2A.

(Step S11)
When the operator is instructed to edit medical data, the UI control unit 22 causes the control unit 15 to generate an editing UI for editing medical data (master data) instructed by the operator. Send it.

(Step S21)
When editing of medical data is instructed from the client 2A, the control unit 15 first instructs the data editing unit 13 to extract the instructed medical data to be edited. The data editing unit 13 extracts medical data (master data) to be edited from the medical data storage unit 11 based on an instruction from the control unit 15. FIG. 7 is an example of medical image master data. In the following, the medical image master data Da1 shown in FIG. 7 will be described as master data to be updated.

  When receiving the medical data to be edited from the data editing unit 13, the control unit 15 outputs the received medical data to the editing UI generation unit 151 and instructs the generation of the editing UI. The control unit 15 transmits the editing UI generated by the editing UI generation unit 151 to the UI control unit 22 of the client 2A and displays it.

(Step S12)
When receiving the editing UI from the control unit 15, the UI control unit 22 switches to the editing UI that has received the UI 23. At this time, the master data Da1 is displayed on the editing UI as master data to be edited. When the operator is instructed to edit medical data via the editing UI, the UI control unit 22 receives the editing content instructed from the input unit 231 and transmits the received editing content to the control unit 15. The control unit 15 receives the edited content and instructs the data editing unit 13 to edit the medical data. FIG. 8 is an example of edited data obtained by editing the master data of the medical image by the operator. In the following description, it is assumed that the editing data Da2 shown in FIG. 8 is editing data created based on an operator's instruction.

  When the UI control unit 22 receives the editing UI reflecting the editing result from the control unit 15, the UI control unit 22 updates the UI 23 with the received editing UI. At this time, editing data Da2 is displayed on the editing UI as a result of editing. As a result, the operator can confirm the editing result (editing data) on the editing UI.

(Step S13)
When the editing of medical data is completed, processing related to the merge of the edited data and master data starts.

(Step S22)
When the editing of the medical data is completed, the control unit 15 executes processing related to the display of the merge UI. First, the control unit 15 instructs the merge data creation unit 14 to extract edit data to be merged and master data that is the basis of the edit data. At this time, the control unit 15 receives the master data Da1 shown in FIG. 7 as master data and the edit data Da2 shown in FIG. 8 as edit data from the merge data creation unit 14. The control unit 15 outputs the received editing data Da2 and master data Da1 to the merge UI generation unit 152, and instructs the merge UI generation unit 152 to generate a merge UI.

  The control unit 15 transmits and displays the merge UI generated by the merge UI generation unit 152 to the UI control unit 22 of the client 2A.

(Step S14)
When receiving the merge UI from the control unit 15, the UI control unit 22 switches to the merge UI that has received the UI 23. At this time, the edit data Da2 and the master data Da1 are displayed in a comparison display area on the merge UI (for example, the comparison display area V1 in FIG. 3) so as to be compared.

  Next, when the operator is instructed to merge the editing data and the master data via the merge UI, the UI control unit 22 receives the contents of the merge processing instructed from the input unit 231 and performs the received merge processing. The contents are transmitted to the control unit 15. In response to the contents of the merge process, the control unit 15 instructs the merge data creation unit 14 to merge the edit data Da2 and the master data Da1. The merge data created at this time is a medical image similar to the edit data Da2 shown in FIG. Hereinafter, this merge data is referred to as merge data Da2.

  When the UI control unit 22 receives the merge UI reflecting the merge result of the edit data Da2 and the master data Da1 from the control unit 15, the UI control unit 22 updates the UI 23 with the received merge UI. At this time, merge data Da2 is displayed in the temporary UI data creation area V2. As a result, the operator can confirm the merge result (merge data Da2) on the merge UI.

(Step S15)
Next, when the operator is instructed to update the master data by the merge data via the merge UI, the UI control unit 22 notifies the control unit 15 of the update instruction.

(Step S23)
When the control unit 15 receives the notification regarding the update of the master data by the merge data from the UI control unit 22, the control unit 15 notifies the corresponding master data (master data Da1) and the merge data (merge data Da2) to the merge result update unit 17, The merge result update unit 17 is instructed to update the master data Da1 with the merge data Da2.

  Upon receiving an instruction from the control unit 15, the merge result update unit 17 first extracts merge data Da <b> 2 from the temporary data storage unit 12. Next, the merge result update unit 17 outputs the extracted merge data Da2 to the inquiry notification unit 171, and instructs the inquiry notification unit 171 to distribute the inquiry related to the update of the master data.

  When the query notification unit 171 is instructed by the merge result update unit 17 to distribute a query regarding master data update, the query notification unit 171 first extracts history information corresponding to the master data Da1 to be updated from the history information storage unit 18. The inquiry notifying unit 171 specifies an operator who has edited the master data Da1 in the past from the extracted history information. Next, the inquiry notification unit 171 distributes the merge data Da2 received from the merge result update unit 17 to the client operated by each identified operator, and also distributes an update confirmation query to the client operated by each operator. . In the following description, it is assumed that an update confirmation query has been distributed to the client 2B.

(Step S31)
The merge data Da2 and the update confirmation query distributed from the query notification unit 171 are received by the query response unit 24 of the client 2B. The inquiry response unit 24 displays the received merge data Da2 on the output unit 232 so as to be visible, displays the contents of the update confirmation inquiry, and displays response means for the inquiry together.

  In response to an update confirmation query displayed on the output unit 232, the query response unit 24 transmits the input response to the update determination unit 172 when a response is input from the operator via the input unit 231.

(Step S24)
The update determination unit 172 receives a list of operators who have distributed update confirmation queries from the query notification unit 171 in advance. Thereafter, the update determination unit 172 receives a response to the update confirmation query from the client 2B that has delivered the update confirmation query. The update determination unit 172 aggregates the received responses, and determines that the master data can be updated with the merge data when the response that the master data can be updated with the merge data exceeds the number of responses that are not. Is output to the merge result update unit 17.

  The merge result update unit 17 receives the determination result from the update determination unit 172, and when the master data Da1 can be updated by the merge data Da2, the merge result Da2 is instructed from the control unit 15 with the merge data Da2 instructed from the control unit 15. The master data Da1 on the medical data storage unit 11 is updated. Thereby, the master data Da1 is overwritten with the merge data Da2, and is stored in the medical data storage unit 11 as new master data Da2.

(Operation 2)
Next, with reference to FIG. 9, the operation when the master data stored in the server 1 is updated while the editing of the master data from another client is reflected while the master data is being edited by the client 2 </ b> A. To do. FIG. 9 is a diagram for explaining the flow of processing when merging is performed by the client 2A when the master data is updated by another client while the medical data is being edited by the client 2A.

(Step S25)
For example, it is assumed that another operator different from the operator who operates the client 2A operates another client (for example, the client 2C) and creates merge data Da3 of medical images as shown in FIG. FIG. 10 is an example of medical image data in which editing by another operator is updated. At this time, it is assumed that master data Da1 as shown in FIG. 7 is stored in the medical data storage unit 11.

  The control unit 15 receives a notification regarding the update of the master data Da1 by the merge data Da3 from the UI control unit 22 of the client 2C, and instructs the merge result update unit 17 to update the master data Da1 with the merge data Da3.

  The inquiry notifying unit 171 receives an instruction related to the delivery of the inquiry related to the update of the master data from the merge result update unit 17 and extracts the history information corresponding to the master data Da1 from the history information storage unit 18. The inquiry notifying unit 171 identifies an operator (an operator of the client 2B) who has edited the master data Da1 in the past from the extracted history information.

  Next, the inquiry notification unit 171 distributes the merge data Da3 received from the merge result update unit 17 to the client 2B operated by the identified operator, and distributes an update confirmation query to the client 2B. Hereinafter, this query is referred to as “query Q1” to distinguish it from other queries.

(Step S11)
Next, it is assumed that editing of medical data is instructed by the operator of the client 2A before the update of the master data by the inquiry Q1 is confirmed.

(Step S21)
When editing of medical data is instructed from the client 2A, the control unit 15 first instructs the data editing unit 13 to extract the instructed medical data to be edited. The data editing unit 13 extracts medical data (master data) to be edited from the medical data storage unit 11 based on an instruction from the control unit 15. At this time, master data Da1 is extracted from the medical data storage unit 11 as master data.

  The control unit 15 receives the master data Da1 from the data editing unit 13, outputs the received master data Da1 to the editing UI generation unit 151, and instructs generation of the editing UI. The control unit 15 transmits the editing UI generated by the editing UI generation unit 151 to the UI control unit 22 of the client 2A and displays it.

(Step S12)
When receiving the editing UI from the control unit 15, the UI control unit 22 switches to the editing UI that has received the UI 23. At this time, the master data Da1 is displayed on the editing UI as master data to be edited. When the operator is instructed to edit medical data via the editing UI, the UI control unit 22 receives the editing content instructed from the input unit 231 and transmits the received editing content to the control unit 15. The control unit 15 receives the edited content and instructs the data editing unit 13 to edit the medical data. Thereby, the edit data Da2 shown in FIG. 8 is created. The created editing data Da2 is displayed on the editing UI as an editing result (this operation is the same as the operation in step S12 described above).

(Step S32)
Next, while the medical data is being edited by the client 2A (before the processing related to merging of the master data and the edited data is started), the inquiry response unit 24 of the client 2B sends an inquiry Q1 to the update determination unit 172 of the server 1. As a response to this, it is assumed that the master data Da1 can be updated with the merge data Da3.

(Step S26)
The update determination unit 172 receives a response to the inquiry Q1 from the client 2B that has distributed the inquiry Q1. At this time, the update determination unit 172 determines that the master data Da1 can be updated with the merge data Da3.

  The merge result update unit 17 receives the determination result from the update determination unit 172 and updates the master data Da1 on the medical data storage unit 11 with the merge data Da3. Thereby, at this time, the master data Da1 is overwritten with the merge data Da3 and is stored in the medical data storage unit 11 as new master data Da3.

(Step S13)
Next, it is assumed that the editing of the medical data in the client 2A is completed and the process related to the merge of the edited data and the master data is started.

(Step S22A)
First, the control unit 15 instructs the merge data creation unit 14 to extract edit data to be merged and master data that is the basis of the edit data. At this time, the master data stored in the medical data storage unit 11 is updated to the master data Da3. Therefore, the control unit 15 receives master data Da3 (medical image data as shown in FIG. 10) as master data from the merge data creation unit 14, and edit data Da2 (medical image as shown in FIG. 8) as editing data. Data). The control unit 15 outputs the received editing data Da2 and master data Da3 to the merge UI generation unit 152, and instructs the merge UI generation unit 152 to generate a merge UI.

  The control unit 15 transmits and displays the merge UI generated by the merge UI generation unit 152 to the UI control unit 22 of the client 2A.

(Step S14A)
When receiving the merge UI from the control unit 15, the UI control unit 22 switches to the merge UI that has received the UI 23. At this time, the edit data Da2 and the master data Da3 are displayed in a comparison display area on the merge UI (for example, the comparison display area V1 in FIG. 3) so as to be compared.

  Next, when the operator is instructed to merge the editing data and the master data via the merge UI, the UI control unit 22 receives the contents of the merge processing instructed from the input unit 231 and performs the received merge processing. The contents are transmitted to the control unit 15. In response to the contents of the merge process, the control unit 15 instructs the merge data creation unit 14 to merge the edit data Da2 and the master data Da3. FIG. 11 is an example of merge data created at this time. Hereinafter, this merge data is referred to as merge data Da4.

  When the UI control unit 22 receives the merge UI reflecting the merge result of the edit data Da2 and the master data Da3 from the control unit 15, the UI control unit 22 updates the UI 23 with the received merge UI. At this time, merge data Da4 is displayed in temporary data creation area V2 of the merge UI.

(Step S15)
Next, when the operator is instructed to update the master data by the merge data via the merge UI, the UI control unit 22 notifies the control unit 15 of the update instruction. Subsequent processing (processing according to steps S23, S31, and S24) is the same as in FIG.

  The control unit 15 refers to the history information on the history information storage unit 18 when the editing of the medical data is completed, and the history information other than the operator who edited the medical data is included in the history information. In the case where it does not exist, the processing related to the display of the merge UI and the creation of the merge data may be omitted. In this case, the control unit 15 instructs the merge result update unit 17 to update the master data with the edit data. In response to the instruction from the control unit 15, the merge result update unit 17 operates to update the master data in the medical data storage unit 11 with the received edit data immediately without performing an inquiry related to the update of the master data. Good. This makes it possible to omit unnecessary queries when updating the master data.

  When the master data on the medical data storage unit 11 is not updated during the editing of the medical data by the operation from the client 2A, the control unit 15 omits the process related to the display of the merge UI and the creation of the merge data. It may be operated as follows. In this case, the control unit 15 stores in advance the time when medical data editing is started. As a result, when the history information corresponding to the master data does not include the history information after the stored time when the editing is completed, the control unit 15 does not update the master data during the editing of the medical data. Can be detected. At this time, the control unit 15 outputs the edit data to the merge result update unit 17 instead of the merge data. The merge result update unit 17 inquires of an operator who has edited the master data in the past whether or not the master data to be updated can be updated with the received edit data. Thereby, unnecessary merge work can be omitted.

  Further, the range in which the update confirmation inquiry is distributed may be changed in accordance with the contents of the merge processing instructed by the operator. For example, if the editing content applied to the master data that is the basis of the merge data is not deleted, the update history accumulated while the operator who created the merge data is creating the edit data An update confirmation inquiry may be distributed only to an operator corresponding to the above. In this case, it is preferable to store the time at the start of editing medical data in advance in the control unit 15 and notify the inquiry notification unit 171 of the time at the start of editing. As a result, the inquiry notifying unit 171 can specify an operator corresponding to the update history accumulated after the editing start time when distributing the update confirmation inquiry.

  The inquiry notifying unit 171 may be configured to notify the control unit 15 of an update confirmation inquiry together with the specified user identification information. In this case, the control unit 15 creates a response screen (UI) for confirming the contents of the inquiry and inputting a response, and displays the response screen on the operator's terminal corresponding to the notified user identification information. It may be configured as follows. Specifically, for example, when the operator logs in to the medical data editing system, the fact that an update confirmation inquiry has been received is displayed on the UI, and a response screen is displayed to be operable. Good. As a result, the operator can confirm the update confirmation query and respond to the query. In this case, each client may be configured not to include the inquiry response unit 24.

  Further, a plurality of work areas may be provided in the server 1, and each work area may be assigned as the clients 2A to 2C. In this case, each work area may be accessed from another terminal via a network and operated. The server 1 can be directly operated to access each work area. In this case, the update confirmation inquiry may be distributed to the work area assigned to each operator.

  Thus, the update confirmation inquiry delivery method can be changed based on the configuration of the medical data editing system. When the update confirmation inquiry delivery method differs depending on the configuration of the medical data editing system, these may be collectively expressed as “deliver update confirmation inquiry to the operator”.

  As described above, according to the medical data editing system according to the first embodiment, each of a plurality of operators can edit the same medical data at the same time without being limited to the work of other operators. It becomes. In addition, when updating the edits made by each operator, it becomes possible to compare and merge the edit data created by the operator with the master data at that time, and the validity of the merge result It is possible to make an inquiry to an operator who has edited the master data in the past. As a result, the contents edited by each operator can be reflected in the master data under the agreement between the operators who edited the master data.

(Modification)
Next, a medical data editing system according to a modification will be described. In the medical data editing system according to the modified example, the importance of the response to the update confirmation query can be changed according to the operator of the transmission source, that is, the weighting can be changed in the first embodiment. This is different from the medical data editing system according to the above. As a result, in the medical data editing system according to the modified example, for example, the weighting of the response may be changed between an experienced doctor and an inexperienced resident to reflect the opinions of an experienced doctor. It becomes possible. Hereinafter, a medical data editing system according to a modification will be described by focusing on an update determination unit 172 that is different from the medical data editing system according to the first embodiment.

  The update determination unit 172 receives a response to the update confirmation query from the client (any one of the clients 2A to 2C) operated by each operator who has delivered the update confirmation query, and aggregates the received responses. The response weighting is changed for each operator. Specifically, at this time, the update determination unit 172 allocates points to each operator's response, and updates the master data with merge data when the points that can be updated as the total result exceed the points that are denied. It may be configured to determine that it is possible. The weighting may be set in advance in the update determination unit 172.

  In addition, the update determination unit 172 can change the weight of the response of each operator according to the type of medical data (master data) to be updated (for example, medical images such as CT images and MRI images, medical reports, etc.). You may comprise as follows. For example, FIG. 12 is an example of data for the update determination unit 172 to manage response weighting. In FIG. 12, medical data is managed separately for each type, CT images, MRI images, and medical reports.

  In FIG. 12, for example, when the doctor Ua responds to an update confirmation query for any of CT images, MRI images, and medical reports, the update determination unit 172 allocates 3 points to the response. Further, when the doctor Ub responds to the update confirmation inquiry, if the type of the medical data to be processed is a CT image, the update determination unit 172 allocates 3 points to the response. In addition, when the doctor Ub responds to the update confirmation inquiry and the target medical data is a medical report, the update determination unit 172 allocates 1 point to the response.

  In FIG. 12, weighting is performed for each operator (doctor) as a target. However, the weighting may be changed for each occupation type of the operator. For example, FIG. 13 is an example of data for the update determination unit 172 to manage the weighting of responses for each occupation type of the operator.

  In FIG. 13, for example, when the occupation of the operator who made the response is the attending physician, the update determination unit 172 allocates 2 points to each response to the update confirmation inquiry for the CT image and the MRI image. In addition, in the case of a response to an update confirmation query for a medical report, the update determination unit 172 allocates three points that are higher than those in the case of a CT image or an MRI image.

  When the job type of the operator who made the response is an engineer (CT), the update determination unit 172 assigns a high point of 3 points to the response to the update confirmation inquiry for the CT image. However, the update determination unit 172 allocates two points lower than those in the case of a CT image in response to an update confirmation inquiry for an MRI image or a medical report.

  Note that the data for the update determination unit 172 to manage the response weighting shown in FIGS. 12 and 13 is preferably stored so that the update determination unit 172 can refer to the data. For example, a storage area for storing data for managing response weighting may be provided separately, or a storage area may be provided in the update determination unit 172. Further, a management table for managing the information may be provided in the history information storage unit 18 and stored in association with the history information.

As described above, according to the medical data editing system according to the modification, it is possible to change the weight of the response to the update confirmation inquiry for each operator or for each occupation type of the operator.
As a result, in the medical data editing system according to the modified example, for example, it is possible to change the response weighting between an experienced doctor and an inexperienced trainee, and a higher weight (more experienced It is possible to reflect the opinions of doctors.

DESCRIPTION OF SYMBOLS 1 Server 11 Medical data memory | storage part 12 Temporary data memory | storage part 13 Data edit part 14 Merge data creation part 15 Control part 16 Transmission / reception part 17 Merge result update part 18 History information storage part 151 Edit UI production | generation part 152 Merge UI production | generation part 171 Query notification Unit 172 update determination unit 2A to 2C client 21 transmission / reception unit 22 UI control unit 23 UI 24 inquiry response unit 231 input unit 232 output unit

Claims (6)

Multiple devices,
A server comprising a medical data storage unit for storing medical data, and an editing unit capable of editing the medical data in accordance with an editing instruction from the plurality of terminals;
A medical data editing system comprising:
A history information storage unit that stores, for each medical data, history information including user identification information that identifies an operator who performed the editing each time the editing is completed;
In response to an instruction from the terminal, third medical data is generated by matching the second medical data created by editing the first medical data by the editing unit with the first medical data. A generation unit for
Whether to update the first medical data stored in the medical data storage unit with the third medical data to an operator who has edited the first medical data in the past based on the history information A medical data editing system comprising: a notification unit that distributes an inquiry about whether or not. Multiple devices,
A server comprising a medical data storage unit for storing medical data including one or both of a medical image and a report, and an editing unit for editing the medical data in accordance with an editing instruction from one or a plurality of the terminals; ,
A medical data editing system comprising:
The server
A history information storage unit that stores, for each medical data, history information including user identification information that identifies an operator who performed the editing each time the editing using any of the plurality of terminals is completed;
When the editing unit generates the second medical data by editing the first medical data stored in the medical data storage unit based on the instruction of the terminal, the second medical data is generated. A creation unit for generating third medical data by matching the first medical data stored in the medical data storage unit at the time with the second medical data;
Identifying at least one operator who has edited the first medical data in the past based on the history information stored in the history information storage unit since at least the second medical data was generated; A notification unit for delivering an inquiry as to whether or not to update the first medical data stored in the medical data storage unit with the third medical data to the identified operator;
A determination unit that determines whether or not to update the first medical data stored in the medical data storage unit with the third medical data based on a response to the inquiry from the specified operator. When,
An update unit that updates the first medical data stored in the medical data storage unit with the third medical data when the determination unit determines to update the medical data; Data editing system.   The determination unit converts the first medical data stored in the medical data storage unit to the third medical data based on the response and a weight of the response set in advance for each operator. The medical data editing system according to claim 1, wherein it is determined whether or not to update.   The determination unit is configured to store the first medical data stored in the medical data storage unit based on a weight of the response set in advance for each operator according to a type of the first medical data. The medical data editing system according to claim 2, wherein it is determined whether or not to update with the third medical data.   When the history information corresponding to the first medical data includes the user identification information of the other operator other than the operator who has instructed the generation of the second medical data, the notification unit 5. The medical data editing system according to claim 2, wherein the inquiry is distributed to the other operator. A medical data storage unit for storing medical data;
An editing unit for creating second medical data by editing the first medical data stored in the medical data storage unit;
A creation unit for creating third medical data by matching the first medical data and the second medical data;
An inquiry about whether or not to update the first medical data stored in the medical data storage unit with the third medical data is distributed to an operator who has edited the first medical data in the past. A notification unit;
A display unit;
The display area of the display unit is divided into three areas, and the first medical data at the end of editing and the second medical data are displayed side by side in a comparable manner in the first area. In the area, an alignment operation key for aligning the first medical data and the second medical data at the end of the editing, and an operation of the alignment operation key, the first medical data and the second medical data A display control unit that displays the third medical data matched with the medical data and displays an instruction key for instructing the notification unit to deliver the inquiry in the third area. A featured medical data editing system.

Images