U.S. patent application number 14/335813 was filed with the patent office on 2015-04-16 for system and methods for metadata management in content addressable storage.
The applicant listed for this patent is Datcard Systems, Inc.. Invention is credited to Giancarlo Canessa, Gino G. Canessa, John C. Canessa.
Application Number | 20150106401 14/335813 |
Document ID | / |
Family ID | 42119704 |
Filed Date | 2015-04-16 |
United States Patent
Application |
20150106401 |
Kind Code |
A1 |
Canessa; John C. ; et
al. |
April 16, 2015 |
SYSTEM AND METHODS FOR METADATA MANAGEMENT IN CONTENT ADDRESSABLE
STORAGE
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, .about.d the results are
returned to the requester.
Inventors: |
Canessa; John C.; (Apple
Valley, MN) ; Canessa; Giancarlo; (Eagan, MN)
; Canessa; Gino G.; (Eagan, MN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Datcard Systems, Inc. |
Irvine |
CA |
US |
|
|
Family ID: |
42119704 |
Appl. No.: |
14/335813 |
Filed: |
July 18, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12605036 |
Oct 23, 2009 |
8788519 |
|
|
14335813 |
|
|
|
|
61108341 |
Oct 24, 2008 |
|
|
|
Current U.S.
Class: |
707/770 |
Current CPC
Class: |
G06F 16/185 20190101;
G06F 16/156 20190101; G06F 16/90339 20190101; G06F 16/1827
20190101; G06F 16/2471 20190101; G06F 16/152 20190101; G06F 15/16
20130101; G06F 16/137 20190101 |
Class at
Publication: |
707/770 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
Claims
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;
receiving one or more files related to the query from the second
content addressable storage server; and 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; 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.
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; receive one or more files related to
the query from the second content addressable storage system; and
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.
Description
[0001] This application is a continuation of U.S. patent
application Ser. No. 12/605,036 filed on Oct. 23, 2009, and claims
priority to U.S. Provisional Patent Application No. 61/108,341,
filed on Oct. 24, 2008. The entire disclosure of these priority
applications are hereby incorporated by reference herein in their
entirety for all purposes.
BACKGROUND
[0002] 1. Field
[0003] This disclosure relates to Content Addressable Storage for
handling, storing, and distributing medical imaging information
and, more specifically, to metadata management for CAS systems.
[0004] 2. Description of the Related Art
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] These and other problems are addressed by the embodiments
described herein.
SUMMARY
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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
[0017] 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.
[0018] FIG. 1 illustrates a block diagram of a system for metadata
management in a content addressable storage system.
[0019] FIG. 2 is a block diagram representing an exemplary process
for storing metadata in one or more CAS servers.
[0020] FIG. 3 is a block diagram of an exemplary process for
replicating objects and metadata.
[0021] FIG. 4 depicts a block diagram of an exemplary process for
retrieving CAS content from a CAS server.
[0022] FIG. 5 depicts a block diagram of an exemplary process for
retrieving CAS data via an application server.
DETAILED DESCRIPTION
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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).
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
* * * * *