US20170235850A1

US20170235850A1 - System and methods for metadata management in content addressable storage

Info

Publication number: US20170235850A1
Application number: US15/331,775
Authority: US
Inventors: John C. Canessa; Giancarlo Canessa; Gino G. Canessa
Original assignee: Datcard Systems Inc
Current assignee: Datcard Systems Inc
Priority date: 2008-10-24
Filing date: 2016-10-21
Publication date: 2017-08-17
Also published as: US20240111812A1; US20150106401A1; US20220197954A1; WO2010048531A1; US20100138446A1; US20200125604A1; US8788519B2

Abstract

Provided is a content addressable storage (CAS) system that allows a user to request, either through an application server or directly to one or more CAS servers, files and content related to a query. In some embodiments, the content can be discovered by searching previously-stored metadata related to each file at the content addressable storage server. The search can also be replicated across multiple content addressable storage servers in order to obtain varied results and redundant results. Duplicate results may be flagged or omitted, ˜d the results are returned to the requester.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 14/335,813, filed Jul. 18, 2014, which is a continuation of U.S. patent application Ser. No. 12/605,036, filed Oct. 23, 2009, now U.S. Pat. No. 8,788,519, which claims priority to U.S. Provisional Application No. 61/108,341, filed Oct. 24, 2008. The entire disclosures of these priority applications are hereby incorporated by reference herein in their entireties for all purposes.

BACKGROUND

Field

This disclosure relates to Content Addressable Storage for handling, storing, and distributing medical imaging information and, more specifically, to metadata management for CAS systems.

Description of the Related Art

Many files stored in computer systems represent data that is not expected to change over time. In some systems, the percentage of files that are expected to not change can range up to 90% of the total files in the system. Examples of data and files that are expected not to change include medical images, images of cancelled bank checks, images collected by oil and gas exploration, surveillance videos, television news clips, and many types of archive and historical data. This is in strong contrast to files that are expected to change regularly, such as a database file, a word processing document that is being edited, and any type of file that represents current state, such as a file holding cumulative email messages as they arrive.
Content Addressable Storage (CAS) technology can be used to store different types of data including, by way of example, data that does not change over time. Generally, a “handle” (not necessarily a file location) or a GUID (globally unique identifier) is created for each stored object. This handle can be created based on known techniques. In one embodiment, CAS stores information that can be retrieved based on its content, not its storage location.
For example, in some embodiments a CAS system comprises storage nodes, where data is physically kept, and access nodes, where information on the data's location on the storage nodes are kept. As new documents are passed to a CAS device, they are hashed, then stored based on that hash rather than with a directory table. Data is stored and retrieved with the resulting hash rather than based on a physical storage location or by using a hierarchical file system.
As content, such as an image, is received, it can be received by an application server and stored locally at the application server, or if the data meets whatever criteria are set up for CAS storage, stored in the CAS storage. Any metadata or other searchable data is stored on the application server or its local storage. The problem with current systems that utilize CAS, however, is that an end user searches for data on an application server and that application server must know about the content stored in the CAS (e.g., the specific GUID) in order to retrieve it. Metadata, even if it were embedded in or part of the content to be stored in the CAS, would not be searchable. If the application server did not itself store a particular image or other content to a CAS, then it would not know the GUID or handle of the content and would not be able to retrieve it.
These and other problems are addressed by the embodiments described herein.

SUMMARY

Embodiments of the systems, methods, and devices described herein overcome problems of the prior art by allowing a user to search for content that has been stored in content addressable storage, or CAS, even if that content was not stored by the local application server. Systems with multiple application servers, and perhaps even application servers that are of a heterogeneous nature, receive content to be stored and, if certain criteria are met, store the content in a CAS repository. In some cases, the content may be stored in more than one CAS repository and will therefore be replicated in order to provide some redundancy of the data. When storing the data to a CAS repository, the CAS server also collects and stores metadata associated with the content. The metadata can also be replicated over multiple CAS systems.
When a user later attempts to search for data, the search can be performed directly on the application server, which may then search the metadata for content that it has stored. In some embodiments, the application server may also send queries to CAS servers, which can then perform the search on the metadata associated with the CAS content stored there. The CAS content can then all be sent back to the application server, compiled (perhaps deleting or flagging duplicates of CAS content returned), and returned as a results set to the user. In other embodiments, a user can search the distributed CAS servers directly and can receive compiled results directly from the CAS servers.
In one embodiment a computer-implemented method for managing metadata in a content addressable storage system includes receiving a file for storage at a content addressable storage server, the file comprises a header and data, and wherein the content addressable storage server stores and retrieves the data based on content of the data rather than with a hierarchical file system; automatically obtaining with one or more computer processors metadata associated with the data from the header of the file; storing the metadata in a metadata storage device, wherein the metadata is stored in association with the data stored in the content addressable storage server; receiving a query from a requester for content at the content addressable storage server; searching the metadata storage device for content related to the received query; and when the metadata associated with the file is indicated by the query retrieving the file stored in the content addressable storage; and sending the retrieved file to the requester.
In another embodiment, a computer-implemented method for managing metadata in a content addressable storage system, includes: receiving one or more files for storage at a content addressable storage server, wherein each of the one or more files comprises a header and data, and wherein the content addressable storage server stores and retrieves the data based on content of the data rather than with a hierarchical file system; automatically obtaining with one or more computer processors metadata associated with the data from the header of each of the one or more files; storing the metadata in a metadata storage device, wherein the metadata is stored in association with the data stored in the content addressable storage server; receiving a first query from a requester for content at an application server; searching locally at the application server for one or more files related to the first query; sending a second query, related to the first query, to the content addressable storage server; receiving one or more files related to the second query from the content addressable storage server; and sending to the requester the one or more files found locally based on the first query and the one or more files received from the content addressable storage server based on the second query.
In yet another embodiment, a computer-implemented system for managing metadata in a content addressable storage system, includes a content addressable storage system configured to: receive a file for storage, said file to be stored using content addressable storage; store metadata associated with the file in a storage mechanism for storing metadata for content addressable storage; receive a query from a requester for content; search the metadata storage mechanism for content related to the received query; and when the metadata associated with the file is indicated by the query: retrieve the file stored in the content addressable storage; and send the retrieved file to the requester.
In yet another embodiment, a computer-implemented system for managing metadata in a content addressable storage system, comprising: a content addressable storage system configured to receive a file for storage, said file to be stored using content addressable storage; and store metadata associated with the file in a storage mechanism for storing metadata for content addressable storage; and an application server configured to: receive a first query from a requester for content; search locally for content related to the first query; send a second query, related to the first query, to the content addressable storage system; receive one or more files related to the second query from the content addressable storage system; and send to the requester the one or more files found locally based on the first query and the one or more files received from the content addressable storage system based on the second query.
These and other features and advantages of the invention will become apparent from the following description of embodiments. Neither this summary nor the following detailed description purports to define the invention. The invention is defined only by the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features will now be described with reference to the drawings summarized below. These drawings and the associated description are provided to illustrate specific embodiments, and not to limit the scope of the invention.

FIG. 1 illustrates a block diagram of a system for metadata management in a content addressable storage system.

FIG. 2 is a block diagram representing an exemplary process for storing metadata in one or more CAS servers.

FIG. 3 is a block diagram of an exemplary process for replicating objects and metadata.

FIG. 4 depicts a block diagram of an exemplary process for retrieving CAS content from a CAS server.

FIG. 5 depicts a block diagram of an exemplary process for retrieving CAS data via an application server.

DETAILED DESCRIPTION

In the following detailed description, references are made to the accompanying drawings that illustrate specific embodiments in which the invention may be practiced. Electrical, mechanical, programmatic and structural changes may be made to the embodiments without departing from the spirit and scope of the disclosure. The following detailed description is, therefore, not to be taken in a limiting sense and the scope of the disclosure is defined by the appended claims and their equivalents.
FIG. 1 illustrates a block diagram of a system for metadata management in a content addressable storage system. In FIG. 1, numerous computers and systems are all interconnected via a network 101. The network 101 may be the internet, an intranet, a dedicated wired network, one or more cables, a wireless network, or any other appropriate type of communication. The system may include one or more CAS servers 110A-C. Each of these CAS servers may include or have thereto attached one or more storage systems 120A-C. The storage systems 120A-C may include one or more RAID storage systems, cloud storage, tape storage, optical disks, magnetic disks, and/or any other appropriate type of storage. There may be any number of CAS servers and each may have any number of storage systems 120A-C. Two or more storage systems 120A-C may reside on the same physical disk or storage, or each storage system 120A-C may reside on one or more disks or other storage separate from all of the other storage systems 120A-C. In some embodiments, content stored in a CAS server 101A-C may be retrieved based on a GUID, as is known in the art, or based on a search, as discussed herein.
As noted herein, when a CAS server 110A-C receives content to store, it may store the content and metadata to the storage system 120A-C. The content may be stored in the format in which it is received, or in flat files, directories, databases, or the like. The metadata may be stored in any fashion, including in a database, flat file, directory of files, or the like. In some embodiments, the metadata may be stored in XML or other structured file as plain text and this plain text may be searchable. In some embodiments, the metadata is stored in a database, and this database may be searchable.
The CAS servers 110A-C may be coupled via the network to one or more application servers 130. The application server 130 may include or have thereto attached a storage system 150. The storage system 130, like the storage system 120A-C, may include one or more one or more RAID storage systems, cloud storage, tape storage, optical disks, magnetic disks, and/or any other appropriate type of storage. In some embodiments, the application server 130 is used to receive one or more files, make a decision to store the file in CAS and to send the file and or metadata to a CAS server 110A-C in order to store the CAS content and/or the metadata. In some embodiments, the application server 130 may be used by a user using a client computer, e.g., client system 140A, in order to query for content. The user may submit a query for content to the application server 130 and the application server may attempt to respond to that query both by looking locally, including on its storage system 135 and by sending the query to one or more CAS servers 110A-110C.
In some embodiments, one or more client systems 140B-140C are coupled to the network 101 and may allow a user to query the CAS servers 110A-110C via a client application directly without going through an application server 130.

Storing the CAS Content and Metadata

FIG. 2 is a block diagram representing an exemplary process for storing metadata in one or more CAS servers. In step 210, content is received. In some embodiments, receiving content may include receiving DICOM images, images, historical data, video or other content. The content may be received, e.g., at an application server 130.
Content Addressed Storage (CAS) is a technique by which a unit of data stored on a storage system is accessed using an address that is derived from the content of the unit of data. As an example, the unit of data may be provided as an input to a hashing function which generates a hash value that is used as the content address for the unit of data. When a host computer sends a request to a content addressable storage system to retrieve a unit of data, the host provides the content address (e.g., hash value) of the unit of data. The storage system then determines, based on the content address, the physical location of the unit of data in the storage system, retrieves the unit of data from that location, and returns the unit of data to the host computer.
If, in step 220, a determination is made to not store the content in CAS, then the application server 130 may store the content locally in a storage system 135. The application server may also store metadata associated with the content locally on the application server 130 or in the storage system 135. Further, the content and the metadata may be correlated. For example, the metadata may be stored in a database or an XML file and may include a pointer or reference to the content (such as a file location or unique database ID depending on the implementation and the type of data). The locally-stored metadata may later be searched and the content and metadata served to a searcher. Methods for choosing what data to store in CAS storage and what content to not store in CAS may include data types (e.g., PDF files, images, and medical records may be indicated as CAS candidates) last modification date, identity of the providing system, indications in the metadata, compliance with Sarbanes-Oxley, age of the file, status of a project related to the file, size of the file, or ways known to those skilled in the art.
If, in step 220, a determination is made to store the content at a CAS server 110A-C, then the content is sent to a CAS server in step 230, a metadata file is created in step 240, and the content and metadata are associated with each other in step 250. In the depicted embodiment of the process, the application server may send the content to the CAS server in step 230 and the CAS server may create the metadata file in step 240. In other embodiments, the metadata file is created at the application server and both are sent to the CAS server. Similarly, the metadata file may be associated with the content file (step 250) either at the application server or at the CAS server. In some embodiments, the application server may send the content and/or the metadata to more than one server.
The metadata corresponding to the CAS content may include any relevant data such as author, data owner, patient name (in the case of medical data), patient number, television episode title, creation date, etc. The metadata may be stored in a number of ways. For example, the data may be stored in an XML file, in an unformatted text file, in a formatted text file, in a database entry, or in any other of a myriad of appropriate manners. The metadata may come from a DICOM header, text in the file, analysis of the file (e.g., size and modification date of the file), summary or metadata fields in the document, descriptive or other files associated with received file, or other sources of metadata. This stored metadata may then later be searchable. Associating the metadata with the content in step 250 may comprise including the GUID for the content in the metadata file or having a separate file, database entry, etc. that includes references to the metadata and the content.
In the depicted embodiments, in step 260; the CAS content and metadata may be distributed to multiple CAS servers. The CAS content and metadata may be distributed to multiple servers simultaneously or sequentially, in a hierarchical fashion where each CAS server distributes the data to one or more other CAS servers, or in any other appropriate manner or topology. In other embodiments, as noted herein, the CAS content and metadata may not be distributed among CAS servers and step 260 may not be performed. In some embodiments, distributing the CAS content and the metadata can provide for redundancy benefits and/or communication benefits (given that, as the result of distribution, the CAS content may be replicated at a location that is close on the network).

Replicating Content and Metadata

In some embodiments, a CAS server may be configured to replicate CAS objects. It may be useful to distribute the CAS content across multiple CAS servers for redundancy or other reasons. Depending on embodiment and other factors, a CAS server may replicate objects once it receives them, after a particular request for replications, during some preconfigured interval, or for any other appropriate reason. FIG. 3 is a block diagram of an exemplary process for replicating objects and metadata.
In step 310, a CAS server that has content to be replicated sends that content and the associated metadata to another CAS server. This can be accomplished, for example, using network 101. The metadata may be embedded within, appended to, or separate from the content.
In step 320, the content and metadata are received by the receiving CAS server and, in step 330, are parsed. After the data has been parsed, it is stored into a database in step 340. How the metadata is parsed will depend on the embodiment and how the data is formatted. For example, if the metadata is in an XML file, then the XML file may be parsed based on the known format of the file and stored, in step 340, into the metadata database.
In some embodiments, the metadata database may include separate fields for each of known element of metadata. For example, for a DICOM image, there are numerous known fields in the header, including patient name. The database that houses the metadata may have fields for these known elements of metadata. In some embodiments, the database may have one or more free text or other fields that will allow for storage of unknown or uncategorized metadata, such as a “notes” section of a patient chart or a “description” section of a television episode. In some embodiments, all of the database fields may later be searchable jointly or separately.
In some embodiments, the database that stores the metadata may be replicated, distributed, or otherwise available to multiple CAS servers and multiple application servers (such as those depicted in FIG. 1). Each CAS server may have its own database and the metadata for the content stored at that CAS server is stored therein. In some embodiments, a CAS server's database may also have metadata and information on finding associated CAS content for things that are stored at other CAS servers, even if that content is not also stored at that CAS server.
The metadata may also be stored, in some embodiments, in storage other than a database. For example, the metadata may be stored in a flat file, multiple flat files, or any other storage mechanism or searchable storage mechanism.

Retrieving CAS Data

Once the content is stored on the CAS servers, then, as depicted in FIG. 4, data can be retrieved from the CAS storage. FIG. 4 depicts a block diagram of an exemplary process for retrieving CAS content from a CAS server.
In step 410, a query is received, perhaps from a user using a client system 140B. The query can be in SQL, a Boolean search string, a natural language search, or any other appropriate format. In this embodiment, in step 420, the search is sent to other CAS servers. For example, as depicted in FIG. 1, after receiving a query from a user using a client system 140B, a CAS server 110B may send the query to other CAS servers 110A and 110C. In other embodiments, and perhaps based on the search request, the search might be performed only on the local metadata, looking only for locally-stored content.
In some embodiments, after the search is sent to the remote CAS servers in step 420, the search is performed locally in step 430. The local search can then be compiled and sent to the requester immediately, or, as depicted, combined with any results received from remote CAS servers and then sent to the requester in step 450. In some embodiments, the local search is performed before or simultaneously with the forwarding of the query to other CAS servers. For example, in some embodiments, a local query is first made for a file and if the query is completely satisfied, then no query is distributed to the other CAS servers.
The local query performed in step 430 can take any appropriate form and will depend on the embodiment and the format of the received query. For example, if the received query is an SQL query and the metadata is stored in a database, then the received SQL query or some modification thereof may be used to query the local data. If the received query is a Boolean search and the metadata is stored in a flat file, then a text search based on the Boolean query may be performed. Once matching metadata is found, then the associated CAS content is retrieved and made ready to send to the requester.
In steps 440 and 450, the CAS server may await results from the other CAS servers. All of the received results are combined and forwarded in step 460. For example, if a CAS server storing DICOM images requested more results for a particular patient name and patient ID, then the DICOM CAS server may send the request to multiple CAS servers in order to get any results for that patent stored on any of the other servers. The results may be checked for validity via a checksum or other assurance mechanism built into the system, or any other appropriate CAS procedures. Corrupted or otherwise invalid files may be excluded from or flagged in the CAS or in the result set sent to the requester.
Given the nature of the redundancy and distribution that may be possible with embodiments herein, multiple copies of the same CAS data may be received from multiple CAS servers. In such cases, any duplicate files may be excluded from or flagged in the result set sent to the requester. Additionally, in some embodiments, if the remote CAS server does not send a response within a particular timeout period, the CAS server may no longer await results and may send out any received results in step 450.
The results sent to the requester in step 460 can take any appropriate form, including a single compressed file, a pointed to one or more accessible pieces of data that comprise the complete data set, or any other appropriate mechanism.
FIG. 5 depicts a block diagram of an exemplary process for retrieving CAS data via an application server. The process depicted in FIG. 5 is similar to that depicted in FIG. 4, except that the search is initiated first by a user to an application server. The application server then sends the request to multiple CAS servers. For example, a user using a client system 140A sends a request for data to an application server 130, the application server 130 receives the request (step 510), the application server 130 forwards the request to the CAS servers 110A-C (step 520), the application server searches locally (step 530), and receives or times out waiting for results from the CAS servers (steps 540 and 550). Once all of the results are received and compiled as above, the results are sent to the client system 140A (step 560).
The local search in step 530 at the application server may be for CAS data, or it may be for other application data. For example, if the CAS servers 110A-C store DICOM images and the application server 130 stores patient demographic and billing information, then the local results may be related to the demographics and billing history of the results and the results from the CAS servers 110A-C may be DICOM images.
As above, the results from the CAS servers (and the application server if it stores replicated data) may be checked not only for integrity (via checksums, e.g.), but also for duplicates. The duplicate results may be flagged or omitted from the search results sent.
The processes and systems described herein may be performed on or encompass various types of hardware, such as computer systems. In some embodiments, the computer systems such as the client system 140A-C, the application server 130, and the content addressable storage systems 110A-C may include a bus or other communication mechanism for communicating information, and a processor coupled with the bus for processing information. The computer systems may have a main memory, such as a random access memory or other dynamic storage device, coupled to the bus. The main memory may be used to store instructions and temporary variables. The computer systems may also include a read-only memory or other static storage device coupled to the bus for storing static information and instructions. The computer systems may also be coupled to a display, such as a CRT or LCD monitor. Input devices may also be coupled to the computer system. These input devices may include a mouse, a trackball, or cursor direction keys. Each computer system may be implemented using one or more physical computers or computer systems or portions thereof. The instructions executed by the computer system may also be read in from a computer-readable medium. The computer-readable medium may be a CD, DVD, optical or magnetic disk, laserdisc, carrier wave, or any other medium that is readable by the computer system. In some embodiments, hardwired circuitry may be used in place of or in combination with software instructions executed by the processor.
As will be apparent, the features and attributes of the specific embodiments disclosed above may be combined in different ways to form additional embodiments, all of which fall within the scope of the present disclosure.
Conditional language used herein, such as, among others, “can,” “could,” “might,” “may,” “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be performed in any particular embodiment.
Any process descriptions, elements, or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those skilled in the art.
All of the methods and processes described above may be embodied in, and fully automated via, software code modules executed by one or more general purpose computers or processors, such as those computer systems described above. The code modules may be stored in any type of computer-readable medium or other computer storage device. Some or all of the methods may alternatively be embodied in specialized computer hardware.
It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.

Claims

What is claimed is:

1. A computer-implemented method for managing metadata in a content addressable storage system, comprising:

receiving a file for storage at a content addressable storage server, the file comprises a header and data, and wherein the content addressable storage server stores and retrieves the data based on content of the data rather than with a hierarchical file system;

automatically obtaining with one or more computer processors metadata associated with the data from the header of the file;

storing the metadata in a metadata storage device, wherein the metadata is stored in association with the data stored in the content addressable storage server;

receiving a query from a requester for content at the content addressable storage server;

searching the metadata storage device for content related to the received query; and

when the metadata associated with the file is indicated by the query:

retrieving the file stored in the content addressable storage; and

sending the retrieved file to the requester.

2. The method of claim 1, wherein the method further comprises:

sending the query to a second content addressable storage server;

receiving one or more files related to the query from the second content addressable storage server; and

sending to the requester the retrieved file and the one or more files related to the query from the second content addressable storage server.

3. The method of claim 1, wherein the method further comprises:

sending the query to a second content addressable storage server;

determining whether any of the retrieved file and the one or more files received from the second content addressable storage server are duplicates.

4. The method of claim 3, wherein the method further comprises:

sending to the requester one or more files that are not duplicates.

5. The method of claim 1, wherein the content addressable storage server stores DICOM images and the metadata is related to the DICOM images.

6. The method of claim 1, wherein the method further comprises:

distributing the file and the metadata to a second content addressable storage server.

7. The method of claim 1, wherein the method further comprises:

distributing the file and the metadata to a plurality of content addressable storage servers in a hierarchical fashion.

8. The method of claim 7, wherein the method further comprises:

sending the query to the plurality of content addressable storage servers, based on the metadata;

receiving one or more files related to the query from the plurality of content addressable storage servers; and

sending to the requester the retrieved file and the one or more files related to the query from the plurality of content addressable storage servers.

9. A computer-implemented method for managing metadata 1D a content addressable storage system, comprising:

receiving one or more files for storage at a content addressable storage server, wherein each of the one or more files comprises a header and data, and wherein the content addressable storage server stores and retrieves the data based on content of the data rather than with a hierarchical file system;

automatically obtaining with one or more computer processors metadata associated with the data from the header of each of the one or more files;

receiving a first query from a requester for content at an application server;

searching locally at the application server for one or more files related to the first query;

sending a second query, related to the first query, to the content addressable storage server;

receiving one or more files related to the second query from the content addressable storage server; and

sending to the requester the one or more files found locally based on the first query and the one or more files received from the content addressable storage server based on the second query.

10. The method of claim 9, wherein the method further comprises:

determining whether any of the one or more files found locally based on the first query and the one or more files received from the content addressable storage server based on the second query are duplicates.

11. The method of claim 10, wherein the method further comprises:

sending to the requester one or more files that are not duplicates.

12. The method of claim 9, wherein the method further comprises:

sending the second query to a second content addressable storage server;

receiving one or more files related to the second query from the second content addressable storage server; and

sending to the requester the one or more files received from the second content addressable storage server based on the second query.

13. The method of claim 9, wherein the content addressable storage server stores DICOM images and the metadata is related to the DICOM images.

14. A computer-implemented system for managing metadata in a content addressable storage system, comprising:

a content addressable storage system configured to:

receive a file for storage, said file to be stored using content addressable storage;

store metadata associated with the file in a storage mechanism for storing metadata for content addressable storage;

receive a query from a requester for content;

search the metadata storage mechanism for content related to the received query; and

when the metadata associated with the file is indicated by the query:

retrieve the file stored in the content addressable storage; and

send the retrieved file to the requester.

15. The system of claim 14, wherein the content addressable storage system is further configured to:

send the query to a second content addressable storage system;

receive one or more files related to the query from the second content addressable storage system; and

send to the requester the retrieved file and the one or more files related to the query from the second content addressable storage system.

16. The system of claim 14, wherein the content addressable storage system is further configured to:

send the query to a second content addressable storage system;

determine whether any of the retrieved file and the one or more files received from the second content addressable storage system are duplicates.

17. The system of claim 16, wherein the content addressable storage system is further configured to:

send to the requester one or more files that are not duplicates.

18. The system of claim 14, wherein the content addressable storage system stores DICOM images and the metadata is related to the DICOM images.