WO2015159404A1 - Retrieval system, retrieval method, and recording medium - Google Patents

Abstract

[Problem] To provide a retrieval system, retrieval method and recording medium with which it is possible to retrieve data stored in an operations-based system and an information-based system, without imposing a load on the operations-based system. [Solution] The retrieval system is characterized in that it is provided with: storage which, if data and a transmission schedule have been received from an operations system, stores the received data and, meanwhile, generates and stores alternative data on the basis of the received transmission schedule; and a retrieval server which, if a retrieval request has been received from a user terminal, retrieves data stored in the storage, on the basis of the received retrieval request. If data satisfying the retrieval request are stored in the storage, the retrieval server transmits the data to the user terminal. If data satisfying the retrieval request are not stored in the storage and alternative data satisfying the retrieval request are stored in the storage, the retrieval server transmits attribute information of the data which are scheduled to be stored, contained in the alternative data, to the user terminal.

Description

SEARCH SYSTEM, SEARCH METHOD, AND RECORDING MEDIUM

The present invention relates to a search system, a search method, and a recording medium.

Generally, an enterprise computer system is composed of two systems: a business system for performing main business and an information system for maintaining and managing the business system. The business system sequentially generates data necessary for daily business, and periodically stores the generated data in the information system according to a predetermined schedule.

Information systems are required to effectively use data from business systems, find work-effective knowledge, and return them to work. There is a retrieval system as a system for retrieving valid data from data stored in an information system.

Patent Document 1 relates to a moving unit that moves an electronic document that is not updated over a certain period from an original storage area of a storage unit to a specific storage area for a document, and the movement of the electronic document by the moving unit. When an electronic document that exists in a specific storage area for storing attribute information and a specific storage area for documents is searched, it exists in a specific storage area for documents based on the attribute information stored by the storage means. An information processing apparatus including a control unit that includes an electronic document to be included in a search target is disclosed.

According to the information processing apparatus described in Patent Document 1, even if the user does not know the archive destination of past electronic documents that are no longer updated, the electronic document can be distinguished without distinguishing whether or not it has been archived. Can be searched efficiently.

JP 2013-239058 A

By the way, it is possible to reduce the load on the business system by searching the data stored in the information system rather than directly searching the data stored in the business system. However, the data stored in the business system goes through a process of being stored in the information system after a predetermined time has elapsed since it was generated. Therefore, if only the data stored in the information system is targeted for retrieval, there is a problem that the latest data generated in the business system cannot be retrieved.

On the other hand, when the technology described in Patent Document 1 is adopted, desired data is searched across the business system and the information system regardless of whether the data is archived from the business system to the information system. can do. However, this imposes a search processing load on the business system, and may impede business execution.

The present invention has been made in consideration of the above points, and a search system, a search method, and a record that can search all data stored in a business system and an information system without imposing a load on the business system. Suggest a medium.

In order to solve such a problem, in the search system of the present invention, when data and a transmission schedule are received from a business system, the received data is stored, while alternative data is generated based on the received transmission schedule. Storage and a search server that searches for data stored in the storage based on the received search request when a search request is received from the user terminal. The search server stores data that satisfies the search request. When stored in storage, when data is sent to the user terminal, data that satisfies the search request is not stored in storage, and alternative data that satisfies the search request is stored in storage Sends the attribute information of the data to be stored included in the alternative data to the user terminal. And butterflies.

In order to solve such a problem, in the search method of the present invention, when the storage receives the data and the transmission schedule from the business system, the storage stores the received data, but substitutes based on the received transmission schedule. A first step of generating and storing data, and a second step of searching for data stored in the storage based on the received search request when the search server receives the search request from the user terminal; In the second step, the search server transmits the data to the user terminal when the data satisfying the search request is stored in the storage and the data satisfying the search request is not stored in the storage. If alternative data that satisfies the search request is stored in the storage, it is included in the alternative data. And transmits the attribute information of the data storage plan to the user terminal.

In order to solve such a problem, in the recording medium of the present invention, when the storage receives data and a transmission schedule from the business system, the storage stores the received data on the basis of the received transmission schedule. A first procedure for generating and storing alternative data, and a second search for data stored in the storage based on the received search request when the search server receives the search request from the user terminal. In the second procedure, when the search server stores data satisfying the search request in the storage, the search server stores the data in the user terminal. The data that is transmitted and satisfies the search request is not stored in the storage, and If the substitute data which satisfies the request is stored in the storage, and transmits the attribute information of the data storage will be included in an alternate data to the user terminal.

According to the present invention, it is possible to search all data stored in the business system and the information system without imposing a load on the business system.

1 is an overall configuration diagram of a search system in the present embodiment. It is an internal block diagram of a search system. It is a logical block diagram of an image management table. It is a logical block diagram of image data. It is a logic block diagram of a schedule table. It is a logic block diagram of a process log. It is a logic block diagram of a data source table. It is a logical block diagram of a reception log. It is a conceptual block diagram of a data recording area and a metadata recording area. It is a data format figure of alternative metadata. It is a screen block diagram. It is a flowchart of an alternative metadata production | generation process. It is a flowchart of a search process. It is an internal block diagram of an electronic medical record server. It is a logical block diagram of a business schedule table. It is a logical block diagram of a patient table. It is a flowchart of an alternative metadata production | generation process. It is an internal block diagram of a document server. It is a logical block diagram of the document management table after an update. It is a flowchart of a metadata update process. It is a whole storage block diagram in other embodiments.

Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

(1) First Embodiment (1-1) Overall Configuration FIG. 1 shows the overall configuration of a search system 100 according to this embodiment. Here, the search system 100 is assumed to be a system constructed in a hospital, and is a system that manages electronic records related to a plurality of patients in a searchable manner. Electronic recording includes, for example, image data, electronic medical record data, document data, and the like.

As shown in FIG. 1, the search system 100 includes a storage 1, a search server 2, a user terminal 3, an image server 4 (business system), imaging devices 51 and 52, an electronic medical record server 7, and a document server 8. These are communicably connected to each other via a network 6. Since the electronic medical record server 7 and the document server 8 will be described in detail in the second and third embodiments, description thereof is omitted here.

The storage 1 can store data in various files in accordance with, for example, the CIFS (Common Internet File System) protocol, the NFS (Network File System) protocol, or other protocols for file sharing, and can retrieve the stored data. It is a general storage device.

The search server 2 is a computer that searches data stored in the storage 1 as a search target in response to a search request from the user terminal 3, acquires a search result from the storage 1, and notifies the user terminal 3. . The user terminal 3 is a computer that transmits a search request to the search server 2 and displays a search result from the search server 2 on a display screen.

The image server 4 is a storage device for storing images used in the medical field. More specifically, it is a storage device called PACS (Picture Archiving and Communication Systems) that implements the DICOM (Digital Imaging and Communication in Medicine) protocol.

The imaging devices 51 and 52 are medical devices such as an X-ray imaging device and an MRI (Magnetic Resonance Imaging) device. The imaging devices 51 and 52 image a subject to generate image data, and store the generated image data in the image server 4.

Here, an outline of a series of processes in the present embodiment will be described. First, when the imaging devices 51 and 52 generate image data, the generated image data is stored in the image server 4. Next, the image server 4 stores the image data from the imaging devices 51 and 52 and then periodically stores the image data in the storage 1 according to a predetermined schedule.

The schedule for the image server 4 to periodically store the image data is determined in consideration of the influence of the main business and the communication speed between the image server 4 and the storage 1. The image server 4 also stores the attribute information of the image data in the storage 1 when storing the image data periodically. The attribute information is information including, for example, an image ID, a patient name, a patient ID, and an imaging time.

Next, the storage 1 analyzes the image data from the image server 4, generates metadata corresponding to the image data, and stores the image data and the metadata in association with each other. Metadata is data in which attribute information is recorded. Next, the storage 1 generates alternative metadata according to a predetermined schedule.

The alternative metadata is data in which attribute information of image data that is not currently stored in the storage 1 but is scheduled to be stored in the storage 1 in the future is recorded. The flow of processing for generating alternative metadata is as follows.

First, the storage 1 acquires a list of image data stored in the image server 4. Next, the storage 1 specifies image data that has not been received at the present time from the list of acquired image data, and acquires attribute information of the specified image data from the image server 4. Then, the storage 1 generates alternative metadata based on the acquired attribute information. The above is the flow of processing for generating alternative metadata.

On the other hand, when receiving a search request operation from the user, the user terminal 3 transmits the search request to the search server 2. The search server 2 searches for metadata and alternative metadata that satisfy the search request from the metadata and alternative metadata stored in the storage 1.

When the search server 2 obtains metadata and alternative metadata that satisfy the search request as a result of the search, the search server 2 acquires the metadata, corresponding image data, and alternative metadata as search results and transmits them to the user terminal 3. To do. The user terminal 3 displays the search result from the search server 2 on the display screen.

When displaying the search result on the display screen, the user terminal 3 displays the metadata and the corresponding image data in a display mode indicating that they are stored in the storage 1, and the alternative metadata is currently stored in the storage 1. Although it is not stored, it is displayed in a display form indicating that it is scheduled to be stored in the storage 1 in the future.

For example, since the image data corresponding to the alternative metadata is not currently stored in the storage 1, the frame line may be displayed with a broken line, and a message such as “NO Image” may be displayed within the frame line.

By executing a series of processes as described above, even when image data is not stored in the storage 1 at the time of search, it is possible to search for data that is scheduled to be stored in the future by generating alternative metadata. can do.

(1-2) Internal Configuration FIG. 2 shows the internal configuration of the search system 100. Hereinafter, the storage 1, the search server 2, the user terminal 3, and the image server 4 will be described in this order.

The storage 1 includes a memory 11, a CPU (Central Processing Unit) 12, and an auxiliary storage 13. The CPU 12 executes various processes in cooperation with various programs stored in the memory 11. The memory 11 stores a data input / output unit 111, an unsent data detection unit 112, a schedule acquisition unit 113, a metadata generation unit 114, and an alternative metadata generation unit 115 as various programs.

In response to input / output requests from various devices connected to the network 6, the data input / output unit 111 receives data and writes it to the auxiliary memory 13, or reads data from the auxiliary memory 13 and sends it to the requesting device. Send.

The unsent data detection unit 112 makes an inquiry to the image server 4 and detects unsent data that is stored in the business system but not yet stored in the storage 1.

The schedule acquisition unit 113 inquires of the image server 4 about the schedule information and acquires the time when the untransmitted data is stored in the storage 1.

The metadata generation unit 114 extracts attribute information from the data received by the data input / output unit 111 and stored in the auxiliary storage 13, generates the extracted attribute information as metadata, and stores it in the auxiliary storage 13.

The alternative metadata generation unit 115 makes an inquiry to the image server 4 to acquire attribute information of untransmitted data, generates the acquired attribute information as alternative metadata, and stores it in the auxiliary storage 13.

In addition to the above-described various programs, the memory 11 stores a reception log 116 and a data source table 117 as various information.

Although details of the reception log 116 and the data source table 117 will be described later (FIGS. 7 and 8), a brief description will be given here. The reception log 116 is processed by the data input / output unit 111 and the metadata generation unit 114. Stores information related to the processing result in the case of being executed.

In addition, the data source table 117 stores information on an inquiry to the image server 4 when processing is executed by the unsent data detection unit 112.

The auxiliary storage 13 is, for example, one or more HDDs (Hard Disk Drives), and is one or more nonvolatile storage devices. The auxiliary storage 13 includes a data recording area 131 and a metadata recording area 132.

In the data recording area 131, data received from the image server 4 by the data input / output unit 111 is stored. The metadata recording area 132 stores metadata generated by the metadata generation unit 114 and alternative metadata generated by the alternative metadata generation unit 115.

Here, the auxiliary storage 13 is configured with a file system, and the data recording area 131 and the metadata recording area 132 are managed as independent directories. The metadata recording area 132 may be managed by different databases, or may be managed by a logical partition.

The search server 2 includes a memory 21 and a CPU 22. The CPU 22 executes various processes in cooperation with various programs stored in the memory 21. The memory 21 stores a metadata search unit 211 and a search screen generation unit 212 as various programs.

The metadata search unit 211 searches for metadata stored in the storage 1 in response to a search request from the user terminal 3. The search screen generation unit 212 generates data to be displayed on the display screen of the user terminal 3 based on the search result when processing is executed by the metadata search unit 211.

Note that HTTP (Hyper Text Transfer Protocol) is used as a protocol for providing the functions of the metadata search unit 211 and the search screen generation unit 212 to the user terminal 3. As data to be displayed on the display screen of the user terminal 3, HTML (Hyper Text Markup Language) is used.

The user terminal 3 includes a memory 31 and a CPU 32. In addition, input devices such as a display screen, a keyboard and a mouse are provided. The CPU 32 executes various processes in cooperation with various programs stored in the memory 31. The memory 31 stores a search screen display unit 311 as various programs.

The search screen display unit 311 issues a search request to the metadata search unit 211 of the search server 2 and displays the display data generated by the search screen generation unit 212 on the display screen.

The image server 4 includes a memory 41 and a CPU 42. The CPU 42 executes various processes in cooperation with various programs stored in the memory 41. The memory 41 stores a data transfer unit 411, an image management unit 414, a communication unit 415, and a management unit 416 as various programs.

The data transfer unit 411 stores the image data stored in the auxiliary storage 43 in the storage 1 according to the schedule recorded in the schedule table 412.

The image management unit 414 stores the attribute information of the image data in the image management table 432 when storing the image data received from the imaging devices 51 and 52 in the auxiliary storage 43. Further, the image management unit 414 transmits the attribute information stored in the image management table 432 to the storage 1 in response to a request from the communication unit 415.

When the communication unit 415 receives the image data storage request from the photographing devices 51 and 52, the communication unit 415 stores the image data in the auxiliary storage 43 and requests the image management unit 414 to store the attribute information of the image data.

Further, when receiving a search request for image data from the storage 1, the communication unit 415 transmits the image data and attribute information to the storage 1. Note that the communication unit 415 communicates with the image capturing apparatuses 51 and 52 and the storage 1 using an appropriate image transfer protocol such as the DICOM protocol.

The management unit 416 includes a user interface for performing various settings in the image server 4. For example, the management unit 416 sets a schedule for the data transfer unit 411 to store the image data in the storage 1 in response to a request from a maintenance terminal (not shown) of the search system 100 and stores the schedule in the schedule table 412. The schedule stored in the schedule table 412 is provided.

The memory 41 stores the above-described various programs, and also stores a schedule table 412 and a processing log 413 as various information.

Although details of the schedule table 412 and the processing log 413 will be described later (FIGS. 5 and 6), briefly described here, the schedule table 412 stores a schedule in which the data transfer unit 411 stores image data in the storage 1. To do. The processing log 413 stores processing results obtained when various programs of the image server 4 are executed.

The auxiliary storage 43 is configured by storing a plurality of image data (here, image data 431a, 431b, 431c, and 431d) and an image management table 432.

Although details of the image data and the image management table 432 will be described later (FIGS. 3 and 4), briefly described here, the image data is data generated by the imaging devices 51 and 52. After being generated by 52, it is stored in the auxiliary memory 43 via the communication unit 415. The image management table 432 manages attribute information generated by the image management unit 414 in association with image data.

(1-3) Table Configuration FIGS. 3 to 8 show configurations of various data and various tables included in the storage 1 and the image server 4. Hereinafter, the image management table 432, the image data 431d, the schedule table 412, the processing log 413, the data source table 117, and the reception log 116 will be described in this order.

FIG. 3 shows a logical configuration of the image management table 432. The image management table 432 is a table that holds attribute information of image data stored in the auxiliary storage 43. Specifically, the image management table 432 includes an image ID column 4321, a patient ID column 4322, a patient name column 4323, an examination ID column 4324, A device ID column 4325, a photographing device column 4326, a photographing time column 4327, and an image file column 4328 are configured.

In the image ID column 4321, identification information of image data is stored. This identification information is assigned when image data is generated by the photographing devices 51 and 52. In the patient ID column 4322, patient identification information is recorded. This identification information is assigned in advance by a patient information management database (not shown) or the like.

In the patient name column 4323, the name of the subject is stored. The examination ID column 4324 stores unique identification information assigned for each image photographing process. For example, when the image is taken by a CT (Computed Tomography) apparatus, a plurality of pieces of image data are generated by one image pickup, and the same examination ID is assigned to these image data.

In the apparatus ID column 4325, identification information of the photographing apparatus that generated the image data is stored. The imaging device column 4326 stores the type of imaging device that generated the image data. The shooting time column 4327 stores the time when the image data was generated. The image file field 4328 stores the file name on the auxiliary storage 43 in which image data is stored.

Therefore, in the case of FIG. 3, for example, the image data with the image ID “7999” has the patient ID “1999”, the patient name “TUUV”, the examination ID “0000”, the device ID “51”, and the imaging device “ “CT” and the photographing time are associated with attribute information “2013/12/31 13:00”, and the file name “A.dcm” is stored in the auxiliary memory 43.

FIG. 4 shows a logical configuration of the image data 431d. Each image data is data stored in the auxiliary storage 43 as a file on the file system configured on the auxiliary storage 43, and specifically includes attribute information and pixel data.

The attribute information is information including the image ID, patient ID, patient name, examination ID, apparatus ID, imaging apparatus, and imaging time described with reference to FIG. In addition, information such as resolution of image data may be included. The pixel data is data representing each pixel of the image data with a numerical value. In addition, each image data includes data that is determined to be retained according to the DICOM protocol, for example, header information for determining the type of data.

FIG. 5 shows a logical configuration of the schedule table 412. The schedule table 412 is a table that holds information on a schedule executed by the image server 4. Specifically, the schedule table 412 includes a schedule ID field 4121, a minute field 4122, a time field 4123, a day field 4124, a day field 4125, a month field 4126, The column includes a year column 4127, a processing column 4128, and a frequency column 4129.

The schedule ID column 4121 stores schedule identification information. The minute column 4122, hour column 4123, day of week column 4124, day column 4125, month column 4126, and year column 4127 store the time at which the schedule is executed.

If “*” is stored, it means an arbitrary value. For example, if “*” is stored in the month column 4126, it means every month. When “*” is stored in only one of the day of the week column 4124 and the day column 4125, the time when “*” is not stored is preferentially adopted.

The processing column 4128 stores the processing content executed by the image server 4. Here, since the image server 4 executes the process of copying the image data and storing it in the storage 1, “duplicate” is stored. The number of times column 4129 stores the number of times the schedule is executed. When “*” is stored, it means that the schedule is executed without an upper limit.

Accordingly, in the case of FIG. 5, for example, the schedule with the schedule ID “SCHED_1” is a schedule of processing in which the image server 4 duplicates the image data and stores it in the storage 1 at “21:00” of “Tue, Thu, Sat”. It is shown that.

FIG. 6 shows a logical configuration of the processing log 413. The process log 413 is data in which an execution result when the image server 4 executes a process according to a schedule is recorded. Specifically, a process ID field 4131, a schedule ID field 4132, a start time field 4133, an end time field 4134, The processing number column 4135, the processing byte number column 4136, and the final processing position column 4137 are configured.

In the process ID column 4131, identification information of an execution result when the image server 4 executes a process according to the schedule is stored. The schedule ID column 4132 stores the identification information of the executed schedule. The start time column 4133 and the end time column 4134 store the start time and end time of the process.

In the processing number column 4135, the number of processed image data is stored. The processing byte number column 4136 stores the total number of bytes of processed image data. The final processing position column 4137 stores the image ID of the image data last processed when the processing is completed.

Therefore, in the case of FIG. 6, for example, the process with the process ID “PR_1” starts the schedule of “SCHED_1” at “2013/12/31 21:00” and ends at “2013/12/31 21:30” It is shown to be a process. Further, it is indicated that the number of image data processed in this process is “1”, the number of bytes of this image data is “100 KB”, and the image ID is “7999”.

The image server 4 processes the image data held in the image management table 432 (FIG. 3) in order from the top. Since the image ID of the image data last processed in the process of “PR_1” is “7999”, the image data of the image ID “8000” is processed first in the process of “PR_2”.

FIG. 7 shows a logical configuration of the data source table 117. The data source means a device that is a transmission source of image data stored in the storage 1, and corresponds to the image server 4 here. The data source table 117 is a table that holds information for specifying the data source. Specifically, the data source ID column 1171, the type column 1172, the IP address column 1173, the port number column 1174, and the authentication information column 1175 are stored. Consists of

The data source ID field 1171 stores data source identification information. The type column 1172 stores the type of the data source. For example, when the data source is the image server 4, “PACS” is stored.

The IP address column 1173 stores the IP address assigned to the communication interface device of the data source. The port number column 1174 stores a port number in the TCP / IP protocol. The authentication information column 1175 stores information related to authentication transmitted to establish a communication connection with the data source.

Therefore, in the case of FIG. 7, the data source whose data source ID is “PACS01” is assumed to be the image server 4 here, so the type is “PACS” and the IP address is “10.0.0.10”. The port number is “11112”. Further, it is shown that authentication information “AE: P0” is transmitted to establish communication.

FIG. 8 shows a logical configuration of the reception log 116. The reception log 116 is data in which a reception result when the storage 1 receives image data from the image server 4 is recorded, and specifically, a processing ID column 1161, a reception time column 1162, a file ID column 1163, a metadata ID. A column 1164, a data source ID column 1165, a key item name column 1166, and a key item value column 1167 are configured.

The processing ID column 1161 stores identification information of a reception result when the storage 1 receives image data from the image server 4. The reception time column 1162 stores the time when image data is received by the data input / output unit 111.

The file ID column 1163 stores the full path name of the file on the data recording area 131 where the received image data is stored. In FIG. 8, only the file name is shown so that the description is not redundant.

In the metadata ID column 1164, a path name of a file on the metadata recording area 132 in which metadata is stored is stored. When metadata is stored using a database, corresponding identification information on the database is stored.

In the data source ID column 1165, identification information of the data source that is the transmission source of the received image data is stored. The key item name column 1166 stores an item name used as a key when uniquely identifying the received image data with the data source of the transmission source. For example, when the received data is image data, since the image server 4 identifies the image data by the image ID, the key item name field 1166 stores “image ID”.

Note that the item name used as a key for each data type is defined in the storage 1 in advance. When the data input / output unit 111 of the storage 1 receives the image data from the image server 4, the data input / output unit 111 determines the data type of the image data and determines an image ID defined in advance in association with the image data as a key item name. To do. This definition can be set and changed by a management unit (not shown) included in the storage 1.

In the key item value field 1167, the value of the attribute specified in the key item name field 1166 is stored. In the case of image data, since the key item is an image ID, the key item value field 1167 stores the image ID of the image data.

Therefore, in the case of FIG. 8, it is indicated that the processing IDs “RCV_1”, “RCV_2”, “RCV — 3”, and “PCV — 1” are recorded as reception results. Among these reception results, the reception results of “RCV_1”, “RCV_2”, and “RCV — 3” indicate that the image data has been received because the file name is stored in the file ID column 1163. ing.

On the other hand, in the process of “PCV_1”, since the file name is not stored in the file ID column 1163, it is indicated that the image data is not received at the present time.

(1-4) Configuration of Recording Area FIG. 9 shows a conceptual configuration of each recording area of the data recording area 131 and the metadata recording area 132. The data recording area 131 is configured as one directory of the file system configured on the auxiliary storage 13. For example, when three pieces of image data are received by the data input / output unit 111, each piece of image data is recorded in files 1312, 1314 and 1315 located in the lower part of the data recording area 131 (directory).

The files 1312, 1314, and 1315 have file names DATA_1, DATA_2, and DATA_3, respectively. Referring to the reception log 116 (FIG. 8), it can be seen that the files 1312, 1314, and 1315 record image data having image IDs 7999, 8000, and 8001, respectively.

These files 1312, 1314, and 1315 are located immediately below the data recording area 131, and are stored in directories 1311 and 1313 corresponding to the reception time. The directory names of the directories 1311 and 1313 are 2013-12-31 and 2014-01-02, respectively, and correspond to the received year-month-day.

Further, the metadata recording area 132 is configured as one directory of the file system configured on the auxiliary storage 13. Similar to the data recording area 131, directories 1321 and 1323 corresponding to the reception time are created immediately below the metadata recording area 132, and files 1332, 1324, and 1325 for recording metadata are stored in the respective directories. .

The files 1322, 1324, and 1325 have file names DATA_1_META, DATA_2_META, and DATA_3_META, respectively. Referring to the reception log 116, it can be seen that each of the files 1322, 1324, and 1325 records metadata corresponding to image data having image IDs 7999, 8000, and 8001, respectively.

A directory 1326 corresponding to the reception time is newly created immediately below the metadata recording area 132 after the alternative metadata is stored. The directory 1326 stores a file 1327 for recording alternative metadata.

(1-5) Data Structure FIG. 10 shows the data format of alternative metadata. The XML file 14 is alternative metadata recorded in a file in an XML (Extensible Markup Language) format. The XML file 14 records alternative metadata corresponding to the image data with the image ID “8002” because “8002”, which is the attribute value of the image ID, is recorded in the child element of the “tag” element. is doing.

Further, the XML file 14 includes a “data” element having an attribute of “type =“ schedule-info ””. In this “data” element, information on a schedule for receiving image data associated with alternative metadata is recorded. When the text element of the “tag” element having the attribute “name =“ state ”” is “not received”, this means that the corresponding image data has not been received.

Also, the scheduled reception date and time of the corresponding image data is recorded in the text element of the tag element having the attribute “name =“ reception schedule ””. Here, “20140104 2100” is recorded, which indicates that reception is scheduled at 21:00 on January 4, 2014.

Although the case where the alternative metadata is recorded in the XML format has been described here, the metadata is similarly recorded in the XML format. Further, the alternative metadata and the metadata are not necessarily recorded in the XML format, and may be recorded in, for example, a database configured on the auxiliary storage 13.

(1-6) Screen Configuration FIG. 11 shows a screen configuration displayed on the display screen of the user terminal 3. The display screen includes a search condition input screen 33 and a search result screen 34.

The search condition input screen 33 is a display screen in which the search screen generation unit 212 of the search server 2 generates display data in response to a user request, and the search screen display unit 311 of the user terminal 3 interprets the display data. It is a screen displayed by outputting to.

The search condition input screen 33 is a screen displayed so that the attribute information of the image data can be input as a search condition. On the search condition input screen 33, the user operates the input device such as a keyboard or a mouse of the user terminal 3 to input the search condition.

The drop-down list 333 is a control for selecting an item name of attribute information of image data. When the drop-down list 333 is expanded on the screen, a list of item names of attribute information such as imaging date, patient name, patient ID, and device ID is displayed in a selectable manner.

The drop-down list 334 is a control for selecting an operator that determines the condition of the attribute information of the image data. When the drop-down list 334 is expanded on the screen, a list of selectable operators such as “is following”, “is before”, “includes next”, “is less than”, and the like is selectably displayed. The

The text field 335 is a control for inputting a value that determines a condition of attribute information of image data. The user can input an arbitrary character string by operating an input device such as a keyboard or a mouse of the user terminal 3.

If the buttons 336 and 337 are pressed, search conditions can be added and deleted. When a plurality of search conditions are input, the radio button 331 or 332 is selected to search for image data satisfying all the input search conditions, or any one of the input search conditions It is possible to specify whether to search all image data satisfying.

In the case of FIG. 11, it is shown that “shooting date” “is next” or “2013/12/31” is input. This input content means that “image data whose shooting date is after December 31, 2013” is designated as a search condition. When the button 338 is pressed with this content, a search request based on this search condition is issued to the metadata search unit 221 of the search server 2.

When the button 338 of the search condition input screen 33 is pressed and a search request is issued to the metadata search unit 211 of the search server 2, the metadata search unit 211 searches the storage 1 and acquires the search result. Then, the metadata search unit 211 generates display data based on the acquired search result, and transmits the display data to the user terminal 3.

The search result screen 34 is a screen displayed when the search screen display unit 311 of the user terminal 3 interprets the display data and outputs it to the display screen.

The data summary areas 341 and 342 correspond to the image data having the image IDs 7999 and 8002, respectively, and are areas on the screen for displaying the attribute information of the corresponding image data and the reduced image of the image. The displayed attribute information is information stored in the metadata recording area 132 of the storage 1 and is recorded in metadata associated with each image data or alternative metadata.

In the data summary area 341, the frame line is drawn with a solid line. On the other hand, in the data summary area 342, the frame line is drawn with a broken line. When the frame line is a solid line, it indicates that the image data has already been stored in the storage 1, and when the frame line is a broken line, it indicates that the image data has not been stored in the storage 1.

Also, “scheduled storage time” and “2014/1/4 21:00” are displayed in the data summary area 342 whose frame line is a broken line. This means that the image data with the image ID 8002 is scheduled to be stored in the storage 1 on January 4, 2014 at 21:00. The scheduled storage time displayed here is the value of the reception schedule recorded in the alternative metadata.

Note that the data summary areas 343 and 344 will be described in detail in the second and third embodiments, and a description thereof will be omitted here.

(1-7) Flowchart Here, the processing flow in the present embodiment will be described. As a premise, a process when the image server 4 transfers image data to the storage 1 (data transfer process) and a process when the storage 1 receives image data from the image server 4 (data reception process) will be described. Subsequently, the alternative metadata generation process (FIG. 12) and the search process (FIG. 13) will be described.

First, the data transfer process will be described. The data transfer unit 411 of the image server 4 refers to the schedule table 412 (FIG. 5), extracts a record whose process content is “duplicate”, and records the record in the extracted record. Wait until the start time arrives.

When the start time arrives, the data transfer unit 411 refers to the processing log 413 (FIG. 6), extracts the record with the latest end time, and acquires the image ID of the final processing position included in this record. The data transfer unit 411 then refers to the image management table 432 (FIG. 3) and extracts a record including the image ID next to the acquired image ID at the final processing position.

The data transfer unit 411 acquires the image file name included in the extracted record, reads the image data stored in the auxiliary storage 43 based on the file name, and transmits the read image data to the storage 1. Next, the data transfer unit 411 refers to the image management table 432 and determines whether there is a record immediately below the record corresponding to the previously transmitted image data.

If the data transfer unit 411 obtains a positive result in this determination, it repeats the process of reading the image data from the auxiliary storage 43 based on the image file name included in the next record and transmitting the read image data to the storage 1. On the other hand, if a negative result is obtained in this determination, the data transfer unit 411 determines that all image data to be transmitted to the storage 1 in the current schedule has been transmitted, and records the current process in the process log 413. This data transfer process is terminated.

Next, the data reception process will be described. When the data input / output unit 111 of the storage 1 receives the image data from the image server 4, it stores the received image data in the auxiliary storage 13. Next, the data input / output unit 111 refers to the head portion of the image data stored in the auxiliary storage 13 and determines that the data type is image data.

Next, the data input / output unit 111 analyzes the content of the image data according to the DICOM protocol, extracts attribute information such as an image ID, a patient ID, and a patient name from the image data, and generates metadata on the memory 11. The data input / output unit 111 stores the metadata generated on the memory 11 in the auxiliary storage 13. At this time, the metadata may be expressed in XML format data and written to a file, or the metadata may be stored in a database constructed in the auxiliary memory 13.

When the data input / output unit 111 completes a series of processing from receiving image data to storing metadata in the auxiliary storage 13, the data input / output unit 111 records the reception result in the reception log 116 (FIG. 8), and this data reception processing Exit.

FIG. 12 shows the processing procedure of the alternative metadata generation process. The alternative metadata generation process is executed by the alternative metadata generation unit 115 according to a predetermined schedule or when the storage 1 accepts an operation from the user.

First, the alternative metadata generation unit 115 refers to the data source table 117 (FIG. 7) and acquires a list of image data from the image server 4 (SP1). The image data list is, for example, a list of image IDs recorded in the image management table 432.

Note that the alternative metadata generation unit 115 may record the time at which the processing of step SP1 is executed every time, and acquire a list of image IDs generated after the last execution time. Here, the alternative metadata generation unit 115 acquires the image IDs of 7999, 8000, 8001, and 8002.

Next, the alternative metadata generation unit 115 selects any one image ID as a processing target from the list of acquired image IDs (SP2). Then, the alternative metadata generation unit 115 refers to the reception log 116 (FIG. 8) and determines whether or not the image data corresponding to the selected image ID has not been received (SP3).

Specifically, the alternative metadata generation unit 115 refers to the key item value field 1167 of the reception log 116 and determines whether an ID that matches the image ID selected in step SP2 is stored. The alternative metadata generation unit 115 determines that the image data corresponding to the image ID selected in step SP2 has been received when there is a matching ID, and has not received it when there is no matching ID. to decide.

If the alternative metadata generation unit 115 obtains a negative result in the determination at step SP3, the replacement metadata generation unit 115 proceeds to step SP7. On the other hand, if the alternative metadata generation unit 115 obtains a positive result in the determination at step SP3, the alternative metadata generation unit 115 transmits a transmission request for attribute information corresponding to the selected image ID to the image server 4, and selects the image selected from the image server 4. The attribute information corresponding to the ID is acquired (SP4).

Next, the alternative metadata generation unit 115 acquires a transmission schedule by which the image data corresponding to the selected image ID is transmitted from the image server 4 to the storage 1 by the schedule acquisition unit 113 (SP5).

Specifically, the alternative metadata generation unit 115 instructs the schedule acquisition unit 113 to acquire a transmission schedule of image data. The schedule acquisition unit 113 transmits a transmission request for the schedule table 412 (FIG. 5) to the image server 4. The management unit 416 of the image server 4 transmits the schedule table 412 to the storage 1 in response to this transmission request. As a result, the alternative metadata generation unit 115 acquires the transmission schedule recorded in the schedule table 412.

Next, the alternative metadata generation unit 115 generates alternative metadata including the attribute information acquired in step SP4 and the transmission schedule acquired in step SP5, and stores the alternative metadata in the auxiliary storage 13 (SP6).

Next, the alternative metadata generation unit 115 records a reception result indicating that the alternative metadata has been generated and stored in the reception log 116 (SP7). Next, the alternative metadata generation unit 115 determines whether there is an unselected image ID in the list acquired in step SP1 (SP8).

When the alternative metadata generation unit 115 obtains a positive result in the determination at step SP8, it proceeds to step SP3 and repeats the above-described processing. In contrast, when the alternative metadata generation unit 115 obtains a negative result, the alternative metadata generation process ends.

FIG. 13 shows the processing procedure of the search process. The search process is executed by the metadata search unit 211 and the search screen generation unit 212 when the search server 2 accepts an operation from the user in the user terminal 3.

First, the metadata search unit 211 receives a search request issued from the user terminal 3 (SP11). The search request includes the search condition input on the search condition input screen 33 (FIG. 11).

Next, the metadata search unit 211 searches for metadata satisfying the search condition from the metadata stored in the metadata recording area 132 of the storage 1, and creates a list of metadata obtained as a search result. (SP12). The metadata list is a list of metadata IDs recorded in the reception log 116, for example.

Note that when the metadata search unit 211 searches for metadata, the attribute information recorded in the metadata may be registered in an index database (not shown), and the index database may be searched. The index database may be stored in the auxiliary storage 13 of the storage 1 or may be stored in the auxiliary storage (not shown) of the search server 2. If the metadata recording area 132 is configured as a database, index information may be assigned to each column of the metadata recording area 132.

The metadata search unit 211 selects one metadata ID as a processing target from the list of metadata created in step SP12 (SP13). Then, the metadata search unit 211 acquires the metadata corresponding to the selected metadata ID from the metadata recording area 132 of the storage 1, and temporarily configures the attribute information included in the acquired metadata on the memory 21. The data is recorded in the display data which is correct data (SP14).

Next, the metadata search unit 211 determines whether or not the acquired metadata is alternative metadata (SP15). Whether the metadata is alternative metadata is determined based on whether the metadata includes schedule information or whether image data corresponding to the metadata has already been stored in the storage 1. .

If the metadata search unit 211 obtains a negative result in the determination at step SP15, the metadata search unit 211 selects a display mode indicating stored as the display mode of the data summary area (FIG. 11) corresponding to the metadata ID selected at step SP13. (SP16). Specifically, the metadata search unit 211 selects a display mode in which the frame line is displayed as a solid line.

On the other hand, when the metadata search unit 211 obtains a positive result in the determination at step SP15, it selects a display mode indicating unstored as the display mode of the data summary area corresponding to the metadata ID selected at step SP13 ( SP17). Specifically, the metadata search unit 211 selects a display mode in which the frame line is displayed with a broken line.

Next, the metadata search unit 211 acquires schedule information included in the alternative metadata, and records it in display data so that the schedule is displayed in the data summary area (SP18). Next, the metadata search unit 211 records the display mode selected in step SP16 or SP17 in the display data (SP19).

Next, the metadata search unit 211 determines whether there is an unselected image ID in the list created in step SP12 (SP20). If the metadata search unit 211 obtains a positive result in this determination, the metadata search unit 211 proceeds to step SP14 and repeats the processing described above. In contrast, when the metadata search unit 211 obtains a positive result, the metadata search unit 211 transmits display data to the search screen generation unit 212.

Then, the search screen generation unit 212 transmits the display data received from the metadata search unit 211 to the search screen display unit 311 of the user terminal 3 (SP21), and ends this search process. When the search screen display unit 311 receives the display data, the search screen display unit 311 interprets the display data and displays it on the display screen, thereby presenting the search result to the user.

(1-8) Effects According to First Embodiment As described above, according to the search system 100 according to the first embodiment, even if the data is not stored in the storage 1 that is an information system, business If the image data is stored in the image server 4 that is a related system and is scheduled to be stored in the storage 1 in the future, the alternative metadata is generated in the storage 1 and the alternative metadata is searched for the search request from the user terminal 3 Thus, data stored in the business system and the information system can be searched as a search target without imposing a load on the business system.

In addition, when the alternative metadata is obtained as a search result, the attribute information and schedule included in the alternative metadata are displayed on the display screen, so that the data stored in the image server 4 can be quickly known. At the same time, the available time of this data can be easily known. If it is desired to acquire data without waiting for the available time, it can also be acquired directly from the image server 4. In this case, since the number of data directly acquired with reference to the search result can be reduced, the influence on the business of the image server 4 can be minimized.

(2) Second Embodiment In the second embodiment, in addition to the configuration described in the first embodiment, even image data that is not currently stored in the image server 4 is generated in the future. It is provided with a configuration for generating alternative metadata for image data that is clearly displayed. Hereinafter, a specific configuration in the second embodiment will be described.

(2-1) Overall Configuration The search system 100 according to the second embodiment includes an electronic medical record server 7 for detecting image data that will be generated in the future. The electronic medical record server 7 has a function of managing a work schedule such as photographing and medical examination.

In addition, the alternative metadata generation unit 115 in the second embodiment has an extended function for detecting data that is clearly generated in the future by referring to the business schedule and generating alternative metadata for this data.

(2-2) Internal Configuration FIG. 14 shows the internal configuration of the electronic medical record server 7. The electronic medical record server 7 includes a memory 71, a CPU 72, and an auxiliary storage 73. The memory 71 stores a communication unit 711 and a work schedule management unit 712.

The communication unit 711 communicates with various devices connected to the network 6. The business schedule management unit 712 registers and queries business schedules in response to requests from various devices connected to the network 6.

The auxiliary memory 73 is configured to store a work schedule table 731 and a patient table 732. The details of the work schedule table 731 and the patient table 732 will be described later (FIGS. 15 and 16), but will be briefly described here. The work schedule such as the date and time to be recorded is recorded.

In addition, the patient table 732 records basic information related to patients necessary for work such as personal information of patients and hospitalized hospital rooms.

(2-3) Table Configuration FIG. 15 shows a logical configuration of the work schedule table 731. The work schedule table 731 includes a reservation ID column 7311, a type column 7312, a device ID column 7313, a doctor column 7314, a date / time column 7315, and a patient ID column 7316.

The reservation ID column 7311 stores reservation (business schedule) identification information. The type column 7312 stores the type of business to be executed in the business schedule. For example, “imaging” and “diagnosis” are stored. The device ID column 7313 stores identification information of the imaging devices 51 and 52 used when the type of business is “imaging”.

The doctor column 7314 stores the name of the doctor who performs the work. The date and time column 7315 stores the date and time when business is performed. The patient ID column 7316 stores identification information of a patient who is a subject of work.

Accordingly, in the case of FIG. 15, for example, the work schedule with the reservation ID “R_1” is a work for “photographing” by the photographing device 51 or 52 of “CT01”, and the photographing time is “2014/1/6 13:00”. It is planned that the patient ID is “1000”.

FIG. 16 shows a logical configuration of the patient table 732. The patient table 732 includes a patient ID column 7321, a patient name column 7322, a date of birth column 7323, and a hospital room column 7324. The patient ID column 7321 stores patient identification information. The patient name column 7322 stores the name of the patient. The birth date column 7323 stores the date of birth of the patient. The hospital room column 7324 stores the room number of the hospital room when the patient is an inpatient.

Therefore, in the case of FIG. 16, for example, a patient whose patient ID is “1000” has a name “Mn Op”, a date of birth “1970/2/2”, and a room “A101”. It is shown.

Here, it is assumed that the work schedule 731 (FIG. 15) and the patient table 732 (FIG. 16) are stored separately in the auxiliary storage 73, but all the information stored in these tables is stored in the work schedule 731. It may be stored. Information stored in the work schedule 731 may be included in the electronic medical record data. In this case, the storage 1 acquires electronic medical record data from the electronic medical record server 7, and extracts information stored in the work schedule 731 from the acquired electronic medical record data.

(2-4) Data Structure Illustration of the data format of alternative metadata generated in the second embodiment is omitted. In the second embodiment, even if the image data is not currently stored in the image server 4, alternative metadata is to be generated for image data that is clearly generated in the future. Therefore, in the alternative metadata, schedule information for generating image data associated with the alternative metadata is recorded.

Specifically, in the “data” element having the attribute “type =“ schedule-info ”, the corresponding image data is not generated in the text element of the“ tag ”element having the attribute“ name = “state” ”. “Not generated” is recorded.

Also, the scheduled reception date and time of the corresponding image data is recorded in the text element of the tag element having the attribute “name =“ reception schedule ””. In addition, the scheduled generation date and time of the corresponding image data is recorded in the text element of the tag element having the attribute “name =“ generation schedule ””.

(2-5) Screen Configuration FIG. 11 shows a screen configuration displayed on the display screen of the user terminal 3 in the second embodiment. The data summary area 343 is different from the data summary area 342 in that “scheduled creation time” and “2014/1/6/13: 00” are displayed inside.

“Display of“ scheduled creation time ”and“ 2014/1/6 / 13:00 ”means that image data is scheduled to be generated on January 6, 2014, 13:00. The data summary area 343 and the data summary area 342 are displayed differently by distinguishing the alternative metadata corresponding to the ungenerated image data and the alternative metadata corresponding to the generated but not received image data. You may make it display in a mode.

(2-6) Flowchart FIG. 17 shows a processing procedure for the alternative metadata generation processing. This alternative metadata generation process is executed when the storage 1 accepts an operation from a user according to a predetermined schedule after executing the alternative metadata generation process (FIG. 12) in the first embodiment. Is executed by the alternative metadata generation unit 115.

First, the alternative metadata generation unit 115 acquires a list of business schedules from the business schedule management unit 712 of the electronic medical record server 7 (SP31). The business schedule list is, for example, a list of entries in the business schedule table 731.

Here, the alternative metadata generation unit 115 acquires a list of business schedules from the electronic medical record server 7. However, the present invention is not limited to this, and for example, when the business schedule is included in the electronic medical record data, The medical record data may be acquired, and the work schedule included in the acquired electronic medical record data may be extracted.

Next, the alternative metadata generation unit 115 selects any one business schedule as a processing target from the list of acquired business schedules (SP32). Next, the alternative metadata generation unit 115 acquires information such as the type, date and patient ID included in the selected business schedule (SP33). Then, the alternative metadata generation unit 115 determines the type of business in the business schedule selected in step SP32 (SP34).

The alternative metadata generation unit 115 proceeds to step SP38 when the job type of the job schedule selected in step SP32 is other than shooting. On the other hand, the alternative metadata generation unit 115 generates alternative metadata on the memory 11 when the job type of the job schedule selected in step SP32 is shooting (SP35).

Next, the alternative metadata generation unit 115 requests the work schedule management unit 712 of the electronic medical record server 7 to transmit the patient information corresponding to the patient ID acquired in step SP33, and acquires the patient information from the electronic medical record server 7. (SP36).

The business schedule management unit 712 receives the request from the alternative metadata generation unit 115 and refers to the patient table 732 to acquire corresponding patient information. Then, the work schedule management unit 712 transmits the acquired patient information to the alternative metadata generation unit 115. As a result, the alternative metadata generation unit 115 acquires patient information.

Next, the alternative metadata generation unit 115 records the patient information acquired in step SP36 in the alternative metadata on the memory 11, and stores the alternative metadata in the metadata recording area 132 of the auxiliary storage 13 (SP37).

When the alternative metadata is stored in the metadata recording area 132 in step SP37, if the metadata has already been generated by the data reception process in the first embodiment, or the alternative metadata is generated by the alternative metadata generation process (FIG. 12). If the metadata has already been generated, the alternative metadata is not stored here.

Next, the alternative metadata generation unit 115 determines whether there is an unselected business schedule in the business schedule list acquired in step SP31 (SP38).

If the alternative metadata generation unit 115 obtains a positive result in the determination at step SP38, it proceeds to step SP33 and repeats the above-described processing. In contrast, when the alternative metadata generation unit 115 obtains a negative result, the alternative metadata generation process ends.

(2-7) Effects According to Second Embodiment As described above, according to the search system 100 according to the second embodiment, even image data that is not currently stored in the image server 4 is generated in the future. Since the alternative metadata is generated for the image data that is clearly displayed, and the alternative metadata is included in the search target in response to the search request from the user terminal 3, without burdening the business system, Data stored in the business system and the information system can be searched as a search target, and data that is not currently stored can also be searched as a search target.

(3) Third Embodiment In the third embodiment, in addition to the configuration described in the first embodiment, when the document data obtained as a search result is scheduled to be updated in the future, A configuration for presenting information is provided. Hereinafter, a specific configuration in the third embodiment will be described.

(3-1) Overall Configuration The search system 100 according to the third embodiment includes a document server 8 that stores document data created by a user. The document server 8 has a function of managing interpretation reports and progress reports by doctors and the like.

Further, the alternative metadata generation unit 115 in the second embodiment identifies data that has been stored in the storage 1 and has been updated on the document server 8 but not in the storage 1, and is used as metadata of this data. An extended function for recording a schedule for storing updated data is provided.

(3-2) Internal Configuration FIG. 18 shows the internal configuration of the document server 8. The document server 8 includes a memory 81, a CPU 82, and an auxiliary storage 83. The memory 81 stores a data transfer unit 811, a document management unit 814, a communication unit 815, and a management unit 816 as various programs.

The data transfer unit 811 transmits the document data stored in the document data recording area 831 to the storage 1 according to the schedule recorded in the schedule table 812. The data transfer unit 811 records the transmission result in the transmission log 813 after transmitting the document data to the storage 1.

The document management unit 814 provides the document data stored in the document data recording area 831 in response to a user request. When the document management unit 814 receives document data in response to a user request, the document management unit 814 stores the document data in the document data recording area 831 and records management information of the document data in the document management table 832.

The communication unit 815 performs communication processing with various devices connected to the network 6. The management unit 816 provides schedule information stored in the schedule table 812 in response to requests from various devices connected to the network 6.

The memory 81 stores the above-described various programs, and stores a schedule table 812 and a transmission log 813 as various information.

The schedule table 812 stores a schedule for sending document data to the storage 1 by the data transfer unit 811. The configuration of the schedule table 812 is the same as that of the schedule table 412 (FIG. 5) described in the first embodiment. The transmission log 813 stores the result of the document data transmission process executed by the data transfer unit 811. The configuration of the transmission log 813 is the same as that of the processing log 413 (FIG. 6).

The auxiliary storage 83 includes a document data recording area 831 and a document management table 832. The document data recording area 831 is configured as a directory on the file system configured in the auxiliary storage 83. The document data is stored as a file under the document data recording area 831.

(3-3) Table Configuration FIG. 19 shows a logical configuration of the document management table 832. The document management table 832 includes a document ID column 8321, a type column 8322, a creation time column 8323, a creator column 8324, a summary column 8325, an update time column 8326, and a file ID column 8327.

The document ID column 8321 stores document data identification information. The type column 8322 stores document data types. The type refers to a type indicating the content of a document such as “interpretation report” or “progress report”. The creation time column 8323 stores the time when the document data was created.

In the creator column 8324, the name of the user who created the document data is stored. The summary column 8325 stores document data summaries. The update time column 8326 stores the time when the document data was updated. In the file ID column 8327, the path name of the document data in the document data recording area 831 is stored.

Accordingly, in the case of FIG. 19, the document data whose document ID is “DOC_1” is a document of “interpretation report”, which is created by “DR GHI” at “2014/1/1 15:00” It is shown that the patient ID is about 1000 abdomen. In addition, since “Summary” has “additional items”, it is indicated that this document data has been updated after being created. The update time is “2014/1/2 13:00”, which indicates that this document data is stored in the document data recording area 831 with the file name “doc1.doc”.

(3-4) Data Structure The metadata data format corresponding to the document data generated in the third embodiment is not shown. Note that in the third embodiment, even if the updated document data is not stored in the storage 1 at this time, the document data that will be updated in the future is updated in the corresponding metadata. In the metadata, schedule information for updating the document data is recorded.

Specifically, in a “data” element having an attribute of “type =“ schedule-info ”, a text element of a“ tag ”element having an attribute of“ name = “state” ”includes corresponding document data as a document server. 8 is updated, but “not received (updated)” indicating that the storage 1 is not updated but not received is recorded.

Also, the scheduled reception date and time of the corresponding document data is recorded in the text element of the tag element having the attribute “name =“ reception schedule ””.

(3-5) Screen Configuration FIG. 11 shows a screen configuration displayed on the display screen of the user terminal 3 in the third embodiment. The data summary area 344 is an area indicating attribute information corresponding to the document data whose document ID is “DOC_1”. The document data “DOC — 1” is stored in the storage 1, but is updated in the document server 8. Therefore, the frame line of the data summary area 344 is drawn with a broken line.

In the data summary area 344, “scheduled storage time” and “2014/1/3 22:00” are displayed. This display means that the updated document data is scheduled to be stored in the storage 1 on January 3, 2014, 22:00. Further, “* updated” is displayed in the data summary area 344. This display means that the document data stored in the storage 1 has update data.

In the data summary area 344, a reduced image (icon) that visually represents document data is displayed. Regarding the display of the data summary area 344, the metadata search unit 211 regards the metadata corresponding to the document data as alternative metadata in step SP15 of the search process (FIG. 13), and proceeds to step SP17.

(3-6) Flowchart FIG. 20 shows a processing procedure for metadata update processing. This metadata update process is triggered by the fact that image data has been received (SP3: N) in step SP3 of the alternative metadata generation process (FIG. 12) in the first embodiment. It is executed by the generation unit 115.

As a premise, the alternative metadata generation unit 115 acquires the document management table 832 from the document server 8. The alternative metadata generation unit 115 compares the update time stored in the document management table 832 with the reception time stored in the reception log 116, and the document data to be processed is updated in the document server 8. However, it is determined whether the document data is not updated in the storage 1 (SP41).

When the document data version is managed in the search system 100, the alternative metadata generation unit 115 determines the document data version stored in the storage 1 and the document data version stored in the document server 8. To determine whether the document data to be processed has been updated.

When the alternative metadata generation unit 115 obtains a negative result in the determination at step SP41, the metadata update processing ends. On the other hand, if the alternative metadata generation unit 115 obtains a positive result in the determination at step SP41, it requests the document server 8 to transmit the attribute information of the document data, and acquires the attribute information from the document server 8 ( SP42).

Specifically, the alternative metadata generation unit 115 transmits an attribute information transmission request to the document server 8. When receiving the attribute information transmission request, the management unit 816 of the document server 8 transmits the attribute information of the document data stored in the document management table 832 to the alternative metadata generation unit 115. As a result, the alternative metadata generation unit 115 acquires the attribute information of the document data.

Next, the alternative metadata generation unit 115 requests the document server 8 to transmit the document data transmission schedule, and acquires the transmission schedule from the document server 8 (SP43).

Next, the alternative metadata generation unit 115 updates the metadata by recording the attribute information acquired in step SP42 and the transmission schedule acquired in step SP43 in the metadata corresponding to the document data to be processed (SP44), This metadata update process is terminated.

(3-7) Effects of the Third Embodiment As described above, according to the search system 100 according to the third embodiment, even document data that has not been updated in the storage 1 at this time will be updated in the future. Document data that is scheduled to be updated is recorded and presented in the corresponding metadata, so that it can be quickly determined whether there is an update, and it is easy to know the scheduled update time of this data Can do. If it is desired to obtain the latest data before the scheduled update time, it can be obtained directly from the document server 8. In this case, since the number of data directly obtained by referring to the search result can be narrowed down, the influence on the work of the document server 8 can be minimized.

(4) Other Embodiments The storage 1 in the first to third embodiments is configured as a single device, but is not necessarily limited thereto, and is configured from, for example, a plurality of devices described below. It is good also as storage.

FIG. 21 shows the overall configuration of the storage in another embodiment. The storage in another embodiment is composed of a storage back end 1a and a storage gateway 1b. The storage back end 1 a includes a data input / output unit 111 a having the same function as the data input / output unit 111 of the storage 1.

The storage gateway 1b has the same function as the storage 1, but the data and metadata (including alternative metadata) stored in the auxiliary storage 13b are respectively stored in the data recording area 131a and the metadata recording area 132a of the storage back end 1a. Duplicate or delete regularly. The storage gateway 1b executes this duplication or deletion process immediately before the alternative metadata generation process described in the first embodiment.

The data sources such as the image server 4 and the document server 8 perform data transmission processing in the same manner as in the first to third embodiments. Here, the storage of the data transmission destination is the storage gateway 1b. The search server 2 may use the storage to be searched as the storage back end 1a or the storage gateway 1b.

In the first to third embodiments, the image server 4 (data transfer unit 411) and the document server 8 (data transfer unit 811) store data in the storage 1. However, the present invention is not limited to this. An archive server may be connected to the network 6, the archive server may acquire various data from the image server 4 and the document server 8, and the acquired various data may be stored in the storage 1.

In this case, the archive server includes a data transfer unit, a schedule table, a data source table, and a processing log. The schedule table, data source table, and process log are equivalent to the schedule table 412 (or 812), data source table 117, and process log 413 (or 813) described above.

In the first to third embodiments, the schedule for storing data in the storage 1 is determined based on the schedule acquired from various data sources (the image server 4 and the document server 8). However, the present invention is not limited to this. Further, the schedule may be determined by further referring to the maintenance schedule of the search system 100 and the operation schedule of various devices constituting the search system 100.

For example, the storage 1 acquires the operation schedule of the data source, compares the time zone when the data source is stopped with the schedule when the data is stored in the storage 1, and the data is stored in the time zone when the data source is not stopped. The scheduled time stored in the storage 1 can be detected, and this time can be recorded as alternative metadata or metadata as the time when the data is stored in the storage 1. The storage 1 may record the time zone when the data source stops in alternative metadata or metadata, and display the time zone when the data source stops on the search result screen 34 (FIG. 11).

In the first to third embodiments, the search server 2 may present data stored in the data recording area 131 of the storage 1 in response to a user request. In this case, when a user interface (clickable button or character string) provided on the search result screen 34 is operated, the search server 2 acquires data from the storage 1 and transmits it to the user terminal 3.

When data stored in the data source but not stored in the storage 1 or updated data is stored in the data source, but data before the update is stored in the storage 1 The storage 1 may transmit data acquired from the data source to the search server 2, and the search server 2 may transmit to the user terminal 3.

In the search result screen 34, data stored in the data source but not stored in the storage 1 or updated data is stored in the data source, but the data before update is stored in the storage 1. A user interface for instructing the storage 1 to preferentially store the stored data in the storage 1 may be provided.

When this user interface is operated, the search server 2 instructs the storage 1 to change the schedule in which the data source stores data in the storage 1. Upon receiving this instruction, the storage 1 requests various data sources to change the schedule.

For example, it is instructed to perform data storage processing with the number of executions as one in the time zone when the workload of work is reduced. The time period during which the work load is reduced can be preset in the storage 1 as information. At the same time, the storage 1 overwrites the alternative metadata and the metadata schedule with the time at which the schedule is requested from the data source, or adds the time as the priority storage time. The rewritten result may be displayed on the search result screen 34 as well.

DESCRIPTION OF SYMBOLS 100 Search system 1 Storage 2 Search server 3 User terminal 4 Image server 51, 52 Image pick-up device 6 Network 7 Electronic medical record server 8 Document server

Claims (10)

1. A storage for receiving data and a transmission schedule from a business system, storing the received data, generating and storing alternative data based on the received transmission schedule; and
   A search server that receives a search request from a user terminal and searches for data stored in the storage based on the received search request;
   The search server
   When data satisfying the search request is stored in the storage, the data is transmitted to the user terminal,
   If the data satisfying the search request is not stored in the storage, and the alternative data satisfying the search request is stored in the storage, the data to be stored included in the alternative data The attribute information is transmitted to the user terminal.
2. The alternative data is
   The attribute information of the data to be stored includes at least a type of the data to be stored and information on a scheduled storage date and time when the data to be stored is stored in the storage. Search system.
3. The storage is
   The search system according to claim 1, wherein a business schedule included in the data is extracted, and substitute data is generated and stored based on the extracted business schedule.
4. The search server
   When data satisfying the search request is stored in the storage, information indicating an overview of the data is transmitted to the user terminal in a displayable format,
   If the data satisfying the search request is not stored in the storage and the alternative data satisfying the search request is stored in the storage, it indicates that the data is scheduled to be stored. The search system according to claim 1, wherein an icon is transmitted to the user terminal in a displayable format.
5. The search server
   If the data satisfying the search request is not stored in the storage and the alternative data satisfying the search request is stored in the storage, information on the scheduled storage date and time of the data is displayed. The search system according to claim 4, wherein the search system is transmitted to the user terminal in a possible format.
6. The search server
   When the data satisfying the search request is stored in the storage and the data is the data before update, the data satisfying the search request is transmitted to the user terminal and is scheduled to be updated. The search system according to claim 1, wherein information indicating that the information is present is transmitted to the user terminal.
7. The storage is
   2. The search according to claim 1, wherein, when substitute data satisfying the search request is stored in the storage, the business system is requested to transmit data corresponding to the substitute data to the storage. system.
8. The storage is
   Compare the list of data stored in the business system with the reception log that records the received data to identify the data that is scheduled to be stored that has not been received at the present time, and the scheduled storage date and time of the identified data that is scheduled to be stored Is acquired based on the transmission schedule, and attribute information of the specified storage scheduled data is acquired from the business system. Based on the acquired storage scheduled date and time information and the attribute information, the alternative meta data is acquired. The search system according to claim 1, wherein data is generated.
9. A first step in which the storage receives data and a transmission schedule from the business system, stores the received data, and generates and stores alternative data based on the received transmission schedule;
   A search server receives a search request from the user terminal, and searches for data stored in the storage based on the received search request;
   In the second step,
   The search server
   When data satisfying the search request is stored in the storage, the data is transmitted to the user terminal,
   If the data satisfying the search request is not stored in the storage, and the alternative data satisfying the search request is stored in the storage, the data to be stored included in the alternative data The attribute information is transmitted to the user terminal.
10. On the computer,
    A first procedure in which the storage receives data and a transmission schedule from the business system, stores the received data, and generates and stores alternative data based on the received transmission schedule;
    A computer readable recording of a program for causing a search server to receive a search request from a user terminal and to execute a second procedure for searching for data stored in the storage based on the received search request Recording medium,
    In the second procedure,
    The search server
    When data satisfying the search request is stored in the storage, the data is transmitted to the user terminal,
    If the data satisfying the search request is not stored in the storage, and the alternative data satisfying the search request is stored in the storage, the data to be stored included in the alternative data The attribute information is transmitted to the user terminal.

Images