JP2016206758A - Medical image management system, control method of medical image management system, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a mechanism that can easily identify an inspection including output data not specific to a viewer, such as three-dimensional shape data created from a medical image, from an inspection not including the output data.SOLUTION: A medical image management system creates a list screen displaying, as a list, inspection information on data in a file format specific to a viewer created from medical image data or medical image data stored in storage means that stores output data in a file format not specific to the viewer, such that whether data in a file format specific to the viewer or output data in a file format not specific to the viewer is included can be identified.SELECTED DRAWING: Figure 8

Description

  The present invention relates to a medical image management system, a control method for a medical image management system, and a program, and in particular, easily distinguishes between examinations that include three-dimensional shape data generated from medical images and examinations that do not. It relates to the mechanism to do.

  Medical image data of a patient taken with a modality (also referred to as a medical image generation device) such as an X-ray CT (Computed Tomography) device or an MRI (Magnetic Resonance Imaging) device is used for a client terminal connected to the modality or a medical image display. In response to a distribution request from a client terminal such as a device, the medical image data can be stored in a server for realizing a medical image management system (PACS: Picture Archiving and Communication System) that can be transferred.

  The medical image captured by the modality is a three-dimensional medical image visualized three-dimensionally on a two-dimensional plane using a computer graphics technique or the like in order to grasp the three-dimensional structure of a patient's organ. Data (such as a volume rendering image) can be generated, and a two-dimensional image generated based on three-dimensional medical image data can be reconstructed.

  As such a technique, in Patent Document 1, volume data is generated from two-dimensional image data (tomographic image data) captured by a modality such as an X-ray CT apparatus, and volume rendering processing, MPR is performed based on the volume data. A viewer technology is disclosed that performs image processing such as processing, MIP processing, and the like to generate three-dimensional image data for display, MPR image data, MIP image data, and the like.

JP 2006-280598 A

  The 3D medical image data generated by such a viewer and the medical image generated from the 3D medical image data are also stored in the server so that they can be viewed from other than the generated client terminal. It is demanded.

  By the way, in recent viewers, when performing 3D-PDF display in STL format, which is a file format for storing 3D shape data used when outputting from medical image data captured by a modality by a 3D printer or the like. It is also possible to output in a file format that is not an image to be displayed by a viewer, such as the VRML format, which is a file format for storing the three-dimensional shape data used. Furthermore, it is possible to output in a data format unique to the viewer.

  It can be said that the three-dimensional shape data and viewer-specific data generated based on such medical images are preferably stored on the server so that they can be confirmed and acquired from other than the generated client terminal.

  In other words, the inspection information stored on the server is a mixture of inspections that include viewer-specific data formats and 3D shape data and inspections that do not.

  In such a situation, if it is not possible to identify which inspection contains such data without downloading information about the inspection from the server, such data is included on the server. There is a need for a mechanism that can identify whether or not

  In view of the above problems, the present invention is a mechanism capable of easily discriminating examinations that include output data other than the viewer, such as viewer-specific data and three-dimensional shape data generated from medical images, and examinations that are not included. The purpose is to provide.

  The medical image management system of the present invention is storage means for storing medical image data in units of examinations, and can also store data in a viewer-specific file format generated from medical image data or output data other than the viewer. A generating unit for generating a list screen for displaying a list of examination information of the medical image data stored in the storage unit; Generating means for generating whether or not output data is included in an identifiable manner.

  According to the present invention, an examination that includes output data other than a viewer such as three-dimensional shape data generated from a medical image can be easily distinguished from an examination that is not included.

The conceptual diagram of the medical image management system in this invention. 1 is a system configuration diagram showing an example of a configuration of a medical image management system in the present invention. The hardware block diagram of the computer as an information processing apparatus applicable to a client terminal, a server, etc. 6 is a flowchart showing an example of a flow of processing for storing medical image data from the client terminal 100 to the server 105. The flowchart which shows the detail of a process of step S408 of FIG. 6 is a flowchart showing an example of a flow of processing for displaying a list screen of examination information of medical image data managed in examination units in the server 105 on the client terminal 100; The figure which shows an example of the screen displayed on the window of a viewer by step S406. The figure which shows an example of the 2nd test | inspection list screen displayed on the browser of the client terminal 100 by step S612. The figure which shows an example of the screen displayed on the browser of the client terminal 100 in step S615. A data table for managing medical image data transmitted from the modality 102 stored in the external memory 211 of the client terminal 100 in units of examinations. A data table for managing medical image data transmitted from the client terminal 100 stored in the external memory 211 of the server 105 in units of examinations.

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 embodiments having the configurations described in the claims.
FIG. 1 is a conceptual diagram of a medical image management system according to the present invention.

  The medical image management system in the present embodiment is a centralized management of medical image data transmitted from modalities (modalities 012 and 103 described later) and client terminals (client terminals 100 and 101 described later) by a server (server 105 described later). It is a system to do.

  In the medical image management system according to the present embodiment, medical image data 106 used for diagnosis is imaged by a modality 102 such as CT (Computed Tomography) or MRI (Magnetic Resonance Imaging) which is an imaging apparatus provided in a medical facility. Thereafter, the data is transmitted to the client terminal 100 used by the doctor for diagnosis or interpretation, the server 104 in the hospital, or the server 105 outside the hospital.

  Examples of the medical image data 106 include DICOM (Digital Imaging and Communication in Medicine) format image data.

  The client terminal 100 archives the medical image data 106 transmitted from the modality 102 and stores it in the external memory of the client terminal 100. Further, the client terminal 100 downloads the medical image data 106 stored in the server 101 or the server 105 in accordance with an operation of a doctor (or a radiologist) who uses the client terminal 100, and externally transmits the client terminal 100. Store in memory.

  A doctor who performs a diagnosis operation on the medical image data 106 uses the client terminal 100 used by the doctor, and the medical image data stored in the external memory of the client terminal is a dedicated viewer for browsing the medical image data. Perform diagnostic work while referring to it.

  The viewer not only displays two-dimensional medical image data imaged by the modality, but also generates various image data by generating three-dimensional volume data from the medical image data imaged by the modality. It can also be displayed. For example, volume data can be generated from two-dimensional medical image data (tomographic image data, hereinafter referred to as “medical image data”) with an X-ray CT apparatus or an MRI apparatus. Then, based on the volume data, image processing such as volume rendering processing, MPR processing, and MIP processing can be performed and displayed.

  Furthermore, it is possible to generate a medical image displayed on the screen of the client terminal 100 in a DICOM format (hereinafter referred to as a reconstructed image) in accordance with an operation of a user who uses the client terminal 100.

  Since this reconstructed image is stored in the DICOM format, it can be viewed by any viewer. Therefore, if the reconstructed image is stored in the server 105 from the client terminal 100 according to the user operation, the reconstructed image is downloaded from the server 105 to the client terminal using another viewer and read by the user. Is possible.

  The viewer also saves the result of 3D processing such as volume rendering processing as a data format unique to the viewer, or STL which is a file format for storing 3D shape data used when output by a 3D printer or the like. It is also possible to output in a file format that is not an image to be displayed by a viewer, such as a VRML format, which is a file format for storing 3D shape data used when creating a 3D-PDF.

  Such a client terminal 100 stores medical image data transmitted from the modality 102 and archived by the client terminal 100, a viewer-specific file, and a three-dimensional shape data file in accordance with an operation of a doctor who uses the client terminal 100. It is also possible to transmit to 104 or the server 105.

  The server 104 stores the medical image data 106 transmitted from the modality 102 in the external memory of the server 105, and transmits / receives the medical image data 106 to / from the client terminal 100 according to the operation of the client terminal 100 by the doctor. It is possible.

Further, the server 104 can transmit the medical image data 106 stored in the server 104 to the server 105 as a backup by setting the server 104 in advance.
The server 105 manages the medical image data 106 transmitted from the modality 102, the client terminal 100, and the server 104 for each examination.

Also, in response to a medical image data acquisition request from the client terminal, the server 105 transmits a medical image data examination information list screen 108 managed for each examination unit to the client terminal 100, or from the list screen 108. The medical image data 106 of the examination selected by the doctor can be transmitted to the client terminal 100.
This is the end of the description of FIG.
Next, the system configuration of the medical image management system according to the present invention will be described with reference to FIG.
FIG. 2 is a system configuration diagram showing an example of the configuration of the medical image management system.
The server 105 outside the hospital is connected to each device of various medical institutions (in the case of FIG. 2, medical institution A and medical institution B) via a network.

  In each medical institution, a plurality of devices are connected via a network (in the medical institution A, the client terminal 100, the modality 102, and the server 104, and in the medical institution B, the client terminal 101, the modality 103).

  Next, a hardware configuration example of a computer as an information processing apparatus applicable to the client terminals 100 and 101 and the servers 104 and 105 will be described with reference to the block diagram of FIG.

  Note that the configuration shown in FIG. 3 is an example, and any configuration may be adopted as long as each processing described later can be realized.

  In FIG. 3, 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 connects and communicates with an external device via a network (for example, the network shown in FIG. 2), and executes communication control processing in 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.

  Next, a flow of processing for storing medical image data, a viewer-specific file, and a three-dimensional shape data file (hereinafter collectively referred to as medical image data) from the client terminal 100 to the server 105 will be described with reference to FIG. . The process for storing medical image data from the client terminal 101 to the server 105 is the same as this process.

  FIG. 4 is a flowchart illustrating an example of a flow of processing for storing medical image data from the client terminal 100 to the server 105 that is a server installed outside the hospital.

  Each step in FIG. 4 is executed by the CPU 201 of the client terminal 100 or the server 105. Note that the processing contents and processing order shown in FIG. 4 are merely examples, and are not limited thereto.

In step S401, the client terminal 100 activates a viewer for displaying medical image data in accordance with an operation of a user (for example, a doctor or a radiologist) who uses the client terminal 100.
In this embodiment, the client terminal 100 starts the viewer in step S401.

  In step S401, it is assumed that after the viewer is activated on the client terminal 100, the user authentication process for the viewer is performed using the user ID and password of the logged-in user.

  In step S <b> 402, the client terminal 100 displays an examination information list screen (hereinafter referred to as an examination list screen) in which medical image data is stored in the external memory 211 of the client terminal 100 on the display 210 of the client terminal 100. Displayed in a viewer window (list display).

  Here, in the examination list screen generated by the server 105 in step S402, the examination performed at the hospital to which the user who has logged into the viewer belongs, and medical image data corresponding to the examination is stored in the external memory of the client terminal 100. The examination stored in 211 is included.

  In addition, information related to each inspection (for example, information of 1001 to 1014 included in the data table of FIG. 10) is displayed on the inspection list screen. Information such as the patient, examination, and series related to the examination other than the viewer-specific data 1003 and the output data 1014 other than the viewer is specified from the supplementary information (DICOM supplementary information) of the medical image data transmitted from the modality.

  FIG. 10 is a data table stored in the external memory 211 of the client terminal 100, which manages medical image data transmitted from the modality 102 in units of examinations.

  The data table in FIG. 10 includes an inspection ID 1001 for identifying an inspection, an inspection date 1002 indicating the date of the inspection, viewer-specific image processing data 1003, output data 1014 other than the viewer, and the inspection target. A patient number 1004 for identifying a patient, a patient name 1005, a test type 1006 indicating the type of modality obtained by imaging medical image data, a part 1007 indicating a part of the patient imaged by the modality, and an object to be examined. An examination item 1008 indicating a part of a patient, a registration date 1009 indicating a date when the medical image data is stored in the client terminal 100, an image number 1010 indicating the number of medical image data included in the examination, a doctor in charge of the examination and an examination A registrant 1011 indicating an engineer, a client terminal storing the data table of FIG. Registration terminal 1012 indicating the information to another, and from the facility name 1013, and the like that is the name of the medical facilities that doctors and laboratory technicians that are registered in the registration's 1011 belongs.

  The registration terminal 1012 also includes information for specifying which type of viewer (for example, manufacturer name, product name) is used by the client terminal that is the transmission source of the medical image data.

  The viewer-specific data 1003 is a result of performing three-dimensional processing such as volume rendering processing for inspection, and is a column indicating the presence or absence of file format data that can be confirmed by the same image processing if the viewer is the same product. Yes, “Yes” is stored when there is a viewer-specific file format, and “No” is stored when there is no file format unique to the viewer.

  The information of the viewer-specific data 1003 is obtained by generating three-dimensional medical image data from the medical image data received from the modality in the client terminal 100 and performing image processing, and storing the result in the external memory 211 of the server or client terminal. Is stored when an instruction to save is received from the user.

  The output data 1014 other than the viewer includes STL format which is a file format for storing 3D shape data used when output by a 3D printer or the like, and 3D shape data used when creating 3D-PDF. A field indicating whether or not there is a file format that is not an image to be displayed by the viewer, such as a VRML format that is a file format to be saved, and is stored as “present” in the case of 3D shape data to be output by other than the viewer If not, “None” is stored.

  The information of the output data 1014 other than the viewer is generated by generating three-dimensional shape data from the medical image data received from the modality in the client terminal 100 and storing the three-dimensional medical image data in the external memory 211 of the server or client terminal. Is stored when an instruction to save is received from the user.

Returning to the description of FIG.
In step S403, the client terminal 100 accepts an operation from the user via the screen displayed in the viewer window.

  Here, the screen displayed in the viewer window is the screen shown in FIG. 7 to be described later when the process proceeds from step S406 to step 403, and is the examination list screen in other cases.

  In step S404, it is determined whether or not the operation received from the user in step S403 is an instruction to specify examination from the examination list screen and generate three-dimensional medical image data. If it is an instruction to designate an examination and generate three-dimensional medical image data, the process proceeds to step S405. If it is not an instruction to designate an examination and generate three-dimensional medical image data, the process proceeds to step S407.

  In step S405, the client terminal 100 generates volume data from the medical image data of the examination designated by the user. Based on the volume data, for example, volume rendering processing is performed to generate three-dimensional medical image data for display, and the generated three-dimensional medical image data is displayed on the viewer window (step S406). The screen displayed in the viewer window in step S406 is, for example, FIG.

FIG. 7 is a diagram showing an example of a screen displayed in the viewer window in step S406.
The medical image 701 is two-dimensional medical image data (for example, a CT image) that is the basis of the three-dimensional medical image data.

  The DICOM save button 702 reconstructs a display screen such as a cross-sectional image of the three-dimensional medical image data from the three-dimensional medical image data displayed on the screen displayed in the viewer window in step S406 into a DICOM format. This is a button for saving the reconstructed image saved in this way. As the location of the save destination, it is possible to select whether to save in the server 105 outside the hospital or to save locally.

  The save 3D image processing button 703 is a result of three-dimensional processing such as volume rendering processing, and can be saved in a file format that can be confirmed by the same image processing if the viewer is the same product. is there. As the location of the save destination, it is possible to select whether to save in the server 105 outside the hospital or to save locally.

  Another format output button 704 is an STL format which is a file format for storing data of a three-dimensional shape used when outputting with a predetermined format (a 3D printer or the like), and a 3D format used when 3D-PDF display is performed. This button is used when saving in a VRML format which is a file format for saving shape data. As the location of the save destination, it is possible to select whether to save in the server 105 outside the hospital or to save locally.

An end button 705 is a button for ending the viewer.
Returning to the description of FIG.

  In step S407, the client terminal 100 determines whether the operation received from the user in step S403 is an instruction to transmit medical image data to the server 105 outside the hospital, for example, by storing the above-described DICOM storage or 3D image processing. Judgment is made according to the instruction to output in the format.

  If the operation received from the user in step S403 is an instruction to transmit medical image data to the server 105 outside the hospital, the process proceeds to step S408; otherwise, the process proceeds to step S411.

  In step S408, when the client terminal 100 determines that an external storage instruction has been given by the user, the client terminal 100 transmits the medical image data displayed in the viewer window and the data related to the three-dimensional medical image data from the client terminal 100 to the outside of the hospital. It is transmitted to the server 105 together with the inspection information (1001 to 1013 in the data table of FIG. 10). Details of the processing in step S408 will be described later with reference to FIG. In step S <b> 408, when transmitting the medical image data from the client terminal 100 to the server 105, the client terminal 100 receives an input of a user ID and password for logging in to the medical image management system from the user, and By transmitting, the user logs in to the medical image management system.

  In step S409, the server 105 receives the medical image data transmitted from the client terminal 100 and stores it in a data table (for example, FIG. 11) stored in the external memory 211 of the server 105.

  FIG. 11 is a data table stored in the external memory 211 of the server 105, which manages medical image data transmitted from the client terminal 100 in units of examinations.

  The data table in FIG. 11 includes an examination ID 1101 for identifying the examination, an examination date 1102 indicating the date of the examination, viewer-specific data 1103, and a patient number for identifying the patient who is the subject of the examination. 1104, patient name 1105, examination type 1106 indicating the type of modality in which medical image data was captured, part 1107 indicating the part of the patient imaged with the modality, examination item 1108 indicating the part of the patient to be examined, medical use A registration date 1109 indicating the date when the image data is stored in the client terminal 100, an image count 1110 indicating the number of medical image data included in the examination, a registrant 1111 indicating a doctor or laboratory technician in charge of the examination, and the medical image data Registered terminal 1112 and registrant 111 indicating information for identifying the client terminal that is the transmission source Doctors and laboratory technicians that are registered with the facility name 1113 indicating the name of the medical facility belonging, and an output for data 1114 and the like other than the viewer. The registration terminal 1112 includes information for identifying which type of viewer.

  The viewer-specific data 1103 is a result of three-dimensional processing such as volume rendering processing, and is a column indicating the presence / absence of file format data that can be confirmed by the same image processing if the viewer is the same product. When there is a file format unique to the viewer, “Yes” is stored, and when there is no file format, “No” is stored.

  The output data 1114 other than the viewer includes an STL format which is a file format for storing 3D shape data used when output by a 3D printer or the like, and 3D shape data used when creating 3D-PDF. Is a field indicating the presence / absence of a file format that is not an image to be displayed by a viewer, such as the VRML format, which is a file format for storing image data. If it is not stored, “None” is stored.

In the data table of FIG. 11, medical image data is managed in units of examination. However, if the series is different even for the same examination, the server 105 may save the data as a separate record. In this case, even if it is medical image data of the same examination, if the reconstructed image data is saved as a different series, the server 105 determines that the series is different and saves it as another record.
Returning to the description of FIG.

  In step S410, when the server 105 receives data from the client terminal 100, the server 105 stores the examination information (1001 to 1013 in the data table in FIG. 10) received together with the stored data in the data table in FIG. Store in the corresponding item.

  That is, the DICOM information of the medical image used when generating the image is stored even in the case of output data other than the viewer or data specific to the viewer.

  In step S411, the client terminal 100 determines whether the operation received from the user in step S403 is an instruction to transmit medical image data to the server 104 in the hospital.

  If the operation received from the user in step S403 is an instruction to transmit medical image data to the server 104 in the hospital, the medical image data or the three-dimensional medical image data displayed in the viewer window is transmitted from the client terminal 100 to the hospital. Information (1001 to 1013 in the data table of FIG. 10) is transmitted to the server 104 (step S412). Otherwise, the process proceeds to step S413.

  In step S413, the client terminal 100 determines whether the operation received from the user in step S403 is an instruction to close the viewer. The instruction to close the viewer is, for example, an operation in which the end button 705 is pressed by the user. If it is an instruction to close the viewer, the viewer is closed at step S415 to end the present process. If not an instruction to close the viewer, the process proceeds to step S415.

In step S415, the client terminal 100 executes other processing (for example, rotation of three-dimensional medical image data, setting of a viewer, etc.) according to the operation received from the user in step S403.
This is the end of the description of FIG.

  In this embodiment, the medical image data displayed in the viewer window and the data in a predetermined format are transferred from the client terminal 100 to the server 105 outside the hospital along with examination information (1001 to 1013 in the data table in FIG. 10). However, as another embodiment, when the user activates a report creation application for inputting a diagnosis result for the examination together with the viewer, the medical image data attached to the report is stored in the server 105. You may send it.

This is because the medical image data used when creating the report is required to be stored in the server 105 because the medical image data is required to be stored for a predetermined period of time under the Pharmaceutical Affairs Law. When the medical image data is attached to the server 105, the medical image data attached to the report is automatically transmitted from the client terminal 100 to the server 105, so that the user's trouble of transmitting the medical image to the server 105 can be saved.
Next, details of the processing in step S408 in FIG. 4 will be described with reference to FIG.

  FIG. 5 is a flowchart showing details of the processing in step S408 in FIG. 4, and shows an example of the flow of processing for storing medical image data from the client terminal 100 to the server 105, which is a server installed outside the hospital. It is a flowchart.

  Each step in FIG. 5 is executed by the CPU 201 of the client terminal 100. Note that the processing contents and processing order shown in FIG. 5 are merely examples, and are not limited thereto.

  In step S501, when either the DICOM save button 702, the save 3D image processing save button 703, or the output button 704 in another format is pressed by the user in step S403, the client terminal 100 is displayed in the viewer window. The three-dimensional medical image data generated from the medical image data is converted into the predetermined format described above.

  In step S502, the client terminal 100 extracts the information on the facility examination to which the user who has logged in to the medical image management system belongs (identified from 1113 in FIG. 11) from the data table in FIG. 11 managed by the server. Obtain from the server 105.

  In step S503, the client terminal 100 determines whether the medical image data that is the basis of the data generated in step S501 is stored in the server 105. Specifically, the medical image data examination ID (corresponding to the supplementary information in the present invention) that is the basis of the three-dimensional medical image data, and the examination ID included in the data table acquired from the server 105 (for example, FIG. 11). 1101), and if the examination IDs match, it is determined that the medical image data that is the basis of the data related to the three-dimensional medical image data is stored in the server 105.

  In this embodiment, the determination is made by using the examination ID, but the determination may be made by other DICOM incidental information (for example, patient ID, examination date, etc.).

In step S503, if it is determined that the medical image data that is the basis of the data related to the three-dimensional medical image data is stored in the server 105, the data in the predetermined format generated in step S501 in step S504. Is transmitted to the server 105, and when it is determined that the medical image data based on the predetermined format generated in S501 is not stored in the server 105, in step S505, the predetermined format data, The obtained medical image data is transmitted to the server 105.
By doing so, it is possible to prevent the medical image data from being registered twice on the server.
This is the end of the description of FIG.

  Next, a process for displaying on the client terminal 100 a list screen of information on examination of medical image data managed by the examination unit in the server 105 will be described with reference to FIG.

  FIG. 6 is a flowchart illustrating an example of a flow of processing for displaying on the client terminal 100 a list screen of examination information of medical image data managed in the examination unit in the server 105.

  Each step in FIG. 6 is executed by the client terminal 100 or the CPU 201 of the server 105. Note that the processing content and processing order shown in FIG. 6 are merely examples, and the present invention is not limited to this.

  In step S <b> 601, the client terminal 100 activates a browser according to an operation of a user using the client terminal 100, acquires a login screen for logging in to the medical image management system from the server 105, and logs in to the medical image management system. An authentication request is made to the server 105 using the user ID, password, etc. of the user.

  In the process of FIG. 6, the client terminal 100 automatically starts the browser at the timing when the medical image data is transmitted from the client terminal 100 to the server 105 in step S <b> 408 of FIG. 4, and the login screen of the server 105 is displayed on the client terminal 100. May be acquired from the server 105 and the process of each step in FIG. 6 may be executed.

  In step S602, the server 105 determines whether or not the server 105 has been logged in based on the user ID and password transmitted from the client terminal 100 in step S601.

  If the login to the medical image management system is successful, in step S605, the server 105 transmits the TOP screen of the medical image management system to the client terminal 100. If the login to the medical image management system is not possible, the server 105 generates an error screen. Then, the data is transmitted to the client terminal 100 (step S603), and the client terminal 100 displays an error screen on the browser (step S604), and ends this process.

  In step S606, the client terminal 100 displays the TOP screen of the medical image management system on the browser.

  In step S607, the client terminal 100 accepts an operation from the user via a screen displayed on the browser.

  Here, the screen displayed on the browser is the TOP screen of the medical image management system when the process proceeds from step S606 to step 607, and the screen described later when the process proceeds from step S612 to step 607. 8 is a screen of FIG. 9 to be described later when the process proceeds from step S615 to step 607, and when the process proceeds from step S619 to step 607, the TOP screen of the medical image management system, or will be described later. It is the screen of FIG. 8, FIG.

  In step S608, the client terminal 100 transmits the content of the operation received from the user in step S607 to the server 105.

  In step S609, the server 105 receives the operation content transmitted from the client terminal 100, and in step S610, the operation content is a list screen (hereinafter referred to as a second screen) of medical image data examination information managed in examination units. It is determined whether or not it is an acquisition request.

  If the operation content transmitted from the client terminal 100 is an acquisition request for the second examination list screen, in step S611, the server 105 generates a second examination list screen (FIG. 8 to be described later), and the client terminal To 100.

In step S612, the client terminal 100 receives the second examination list screen transmitted from the server 100 and displays it on the browser of the client terminal 100.
Here, the second examination list screen displayed on the browser of the client terminal 100 will be described with reference to FIG.

  FIG. 8 is a second examination list screen generated by the server 105 and displayed on the browser of the client terminal 100.

  The second examination list screen includes examinations managed by the medical image management system and medical image data corresponding to the examinations being stored in the external memory 211 of the server 105.

  In addition, information (802 to 814) related to each examination is displayed on the second examination list screen.

  Information 802 to 804 is displayed based on information 1101 to 1113 in the data table of FIG.

  The examination ID 802 corresponds to the examination ID 1101, the examination date 803 corresponds to the examination date 1102, the viewer-specific data 804 corresponds to the viewer-specific data 1103, the patient number 805 corresponds to the patient number 1104, The patient name 806 corresponds to the patient name 1105, the examination type 807 corresponds to the examination type 1106, the part 808 corresponds to the part 1107, the examination item 809 corresponds to the examination item 1108, and the registration date 810 is Corresponding to the registration date 1109, the number of images 811 corresponds to the number of images 1110, the registrant 812 corresponds to the registrant 1111, the registration terminal 813 corresponds to the registration terminal 1112, and the facility name 814 The output data 816 other than the viewer corresponding to the name 1113 corresponds to the output data 1114 other than the viewer.

  If the series is different even if they are the same inspection, they are displayed as separate records on the second inspection list screen.

  By the way, as described above, the file format output based on the three-dimensional medical image data differs depending on the application to be used. For example, the three-dimensional medical image data created by the viewer A is B. There are cases where it cannot be displayed in the viewer, or in the first place it cannot be displayed in the viewer. Therefore, as shown in the viewer-specific data 804 in FIG. 8, when the three-dimensional medical image data is in the viewer-specific file format created, the fact is identified and displayed (for example, the data 804 in FIG. The user who viewed the second examination list screen uses, for example, the three-dimensional medical image data of the examination for which the viewer-specific data 804 in FIG. Whether or not it can be displayed by the viewer can be confirmed only by looking at the registration terminal 813 in FIG.

  Further, when the 3D medical image data of the examination in which the viewer-specific data 804 in FIG. 8 is “present” cannot be displayed by the viewer used by the user, the 3D data is displayed from the screen of FIG. 9 described later. A user who has registered medical image data can make a request to generate a reconstructed image (hereinafter referred to as a reconstructed image) in which the cross-sectional image of the three-dimensional medical image data is reconstructed and stored in DICOM format. In response to the request for generating a reconstructed image, a user who has registered 3D medical image data generates a reconstructed image using a client terminal using a viewer that has generated the 3D image. When registered in the server 105, it may be displayed so that it can be recognized that the reconstructed image is registered on the viewer of the record of the reconstructed image in FIG.

  In the column of output data 816 other than the viewer, in the case of an STL format file or a VRML format file, it is possible to identify which data format the stored data format is. “STL” or “VRML” may be displayed in “()” after the column of the output data 816 other than.

  In addition, when an image output in DICOM format is stored, a display that can identify that the image is a reconstructed image reconstructed from a medical image may be performed.

Note that the identification method when the reconstructed image is registered in the server 105, the identification method in the case of a viewer-specific file format, and the identification method in the case of output data other than the viewer are not limited to the above embodiments. Alternatively, the color of the examination record including the medical image data may be changed (for example, 814 in FIG. 8), or a pop-up may be notified to the user.
Returning to the description of FIG.

  In step S613, the server 105 determines whether or not the operation content transmitted from the client terminal 100 is an instruction to select an examination from the second examination list screen.

  If the operation content transmitted from the client terminal 100 is an instruction to select an inspection from the second inspection list screen, the process proceeds to step S614, and the operation content transmitted from the client terminal 100 is the second inspection list. If it is not an instruction to select an examination from the screen, the process proceeds to step S616.

In step S614, the server 105 transmits to the client terminal 100 a screen including thumbnails of medical image data included in the examination selected by the user in step S607.
At this time, medical image data (not thumbnails) included in the examination selected by the user in step S607 is also transmitted.

  In step S615, the client terminal 100 receives a screen including a thumbnail of the medical image data included in the examination selected by the user in step S607 from the server 105, and displays it on the browser of the client terminal 100. In step S615, the screen displayed on the browser of the client terminal 100 is, for example, FIG.

FIG. 9 is a screen displayed on the browser of the client terminal 100 in step S615.
In the inspection information column 901, the same information as in 802 to 816 in FIG. 8 is displayed.

  In the medical image data column 902, thumbnail images of medical image data included in the examination selected by the user in step S607 are generated and displayed (thumbnail list screen generation). When a thumbnail is selected by the user's mouse operation, the client terminal 100 activates the viewer, and medical image data is displayed on the viewer screen.

  Further, if the data included in the examination selected by the user in step S607 is data in a viewer-specific file format and can be displayed by the viewer used by the user, the client terminal 100 displays the screen in FIG. May be displayed and the viewer may be activated to display the three-dimensional medical image data in the viewer window.

  At this time, nothing may be displayed in the medical image data column 902, and medical image data of an examination having the same examination ID as that associated with the three-dimensional medical image data is stored in the server 105. If stored, the medical image data may be downloaded from the server 105 to the client terminal 100 and displayed.

  As mentioned above, if the data included in the examination selected by the user is in a viewer-specific file format and cannot be displayed by the viewer used by the user, an error display is displayed without opening the viewer window. You may be made to do. Further, a reconstruction image generation request button (not shown) is displayed on the screen of FIG. 9, and when the reconstruction image generation request button is pressed by a user's operation with a mouse or the like, the file format unique to the viewer is displayed. A request for generating a reconstructed image of the file is transmitted to the client terminal of the registered user.

  By providing the reconstructed image generation request button, the user can easily make a reconstructed image generation request even if the user cannot visually recognize the viewer-specific data.

  The 3D image generation button 903 is a button for generating a 3D medical image from the medical image data included in the examination selected by the user in step S607.

  When the 3D image generation button 903 is pressed by a user's operation with a mouse or the like, the client terminal 100 activates the viewer and displays the 3D medical image data in the viewer window.

The end button 904 is a button for ending the screen displayed on the browser of the client terminal 100 in step S615.
Returning to the description of FIG.

  In step S616, the server 105 terminates the screen displayed on the browser of the client terminal 100 in step S615, or the operation content transmitted from the client terminal 100 in step S608 is an instruction to end the second examination list screen. It is determined whether or not it is an instruction (operation in which 904 in FIG. 9 is pressed).

  If the operation content transmitted from the client terminal 100 in step S608 is an instruction to end the second examination list screen or the screen displayed on the browser of the client terminal 100 in step S615, the server 105 in step S617 The operation content transmitted from the client terminal 100 to the client terminal 100 gives an instruction to end the second examination list screen or the screen displayed on the browser of the client terminal 100 in step S615. The operation content transmitted from the terminal 100 ends the second examination list screen or the screen displayed on the browser of the client terminal 100 in step S615 (step S618).

If the operation content transmitted from the client terminal 100 in step S608 is not an instruction to end the second examination list screen or the screen displayed on the browser of the client terminal 100 in step S615, the server 105 in step S608 Then, processing corresponding to the operation content transmitted from the client terminal 100 is executed.
This is the end of the description of FIG.
As described above, according to the present invention, it is possible to prevent the same medical image data from being registered on the server.

  In addition, according to the present invention, it is possible to easily identify an examination that includes data unique to a viewer generated from a medical image or three-dimensional shape data in an output format other than the viewer, and an examination that is not included.

  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.

100 Client terminal 101 Server 102 Modality

Claims (8)

Storage means for storing medical image data in units of examination, the storage means capable of storing data in a viewer-specific file format generated from medical image data or output data other than the viewer;
Generation means for generating a list screen for displaying a list of examination information of the medical image data stored in the storage means, the list screen including data in a file format unique to the viewer or output data other than the viewer A medical image management system, comprising: generating means for generating whether or not it is identifiable.   The generation unit generates the list screen so that a file format of output data other than the viewer can be identified when output data other than the viewer is included. The medical image management system described in 1. An accepting means for accepting selection of an examination from the list screen;
The medical image according to claim 1, further comprising: a thumbnail list screen generation unit that generates a thumbnail list screen of medical image data included in the examination when the examination unit accepts the examination selection. Management system.   5. The medical image management system according to claim 1, wherein the generation unit generates the list screen so that a terminal that transmits data or an image to the storage unit can be identified. 6. .   5. The storage unit according to claim 1, wherein the storage unit can store data in a file format unique to the viewer or output data other than the viewer together with medical image data used to generate the data. The medical image management system described.   The medical image management system according to claim 1, wherein the generation unit generates the list screen so that a part of DICOM information is also displayed. A storage process for storing medical image data in a unit of examination, storing data in a file format unique to the viewer generated from the medical image data or output data other than the viewer,
Whether or not the list screen includes data in a viewer-specific file format or output data other than the viewer when generating a list screen that displays a list of examination information of the medical image data stored in the storage step And a generation step of generating the information in an identifiable manner. A control method for a medical image management system, comprising: A program executable by a medical image management system,
The medical image management system;
Storage means for storing medical image data in units of examination, and storage means for storing data in a viewer-specific file format generated from medical image data or output data other than the viewer,
Generation means for generating a list screen for displaying a list of examination information of the medical image data stored in the storage means, the list screen including data in a file format unique to the viewer or output data other than the viewer Generating means for generating identifiable whether or not
A program characterized by functioning.

Images