Note: Descriptions are shown in the official language in which they were submitted.
CA 02440730 2003-09-16
RECONCILING ASSETS WITHIN A COMPUTER NETWORK
TECHNICAL FIELD
The invention relates to routing and storage within a computer network.
BACKGROUND
A computer network includes a variety of computing devices that
communicate and share resources and data Amedical imaging environment, for
example, may include a number of networked devices including a medical imaging
rilodality that generates medical images of a patient, a diagnostic view
station for
displaying the images, an output device for painting the images on film or
other
media, and an archive system. for storing the images. These devices are often
collectively referred to as a Picture Archival and Retrieval System (PACS),
and may
communicate using a number of protocols. The American College of Radiology and
National Electrical Manufacturers Association, for example, developed one such
protocol referred to as Digital Imaging arid Communications in Medicine
(DICOM).
In general, DICOM defines vendor-independent data formats and data transfer
services for digital medical images.
In many conventional networks, the devices comniuxiicate over a packet-based
network by dividing the dafa into small blocks called packets, which are
individually
routed across the network from a source device to a destination device. The
destination device extracts the data ~froa1 the pacl~ets and assembles the
data into its
original form. Dividing the data into packets enables the source device to
resend only
those individual packets that may be lost during transmission.
Certain devices, referred to as routers, maintain routing information that
describes routes through the network. A "route" can generally be defined as a
path
between two locations on the network. Upon receiving an incoming packet, the
router
examines information within the packet to identify the destination for the
packet.
Based on the destination, the roister forwards the packet in accordance with
the
routing information.
The roisters often maintain the routing information, typically in the form of
one or more routing tables. The form and contents of the routing tables often
depends
CA 02440730 2003-09-16
on the routing algorithm implemented by the router. Typically, networked
medical
imaging systems make use of general-purpose routers that perform the routing
functions without knowledge of the particular medical images and associated
patient
data.
S
SUMMARY
In general, the invention is directed to a router that provides for seamless
communication and distribution of medical images and other patient data
between the
medical modalities and other various medical imaging devices. As described in
detail
below, the router implements certain protocols and file formats to treat
network
communications as a self describing "assets" that encapsulate medical imaging
data.
For example, a self describing asset may include patient data, session data,
study data,
medical image data, private asset information, and the like.
In one embodiment, the invention is directed to a router that includes a
I 5 computer-readable medium storing routing information mapping destinations
to
routes within a medical imaging network, and storing a set of routing rules. A
routing
module executing within an operating environment provided by the router
selects a
route from the routing infozmation based on destination information of a
network
communication and a comparison of medical imaging data of the network
communication to the set of routing rules. The module parses the medical
imaging
data to identify a set of DICOM tags and corresponding data; and assesses the
routing
rules based on the DICOM tags and corresponding data.
in another embodiment, the invention is directed to a method comprising
receiving examination information for a patient, examining routing information
within
a network router to identify storage systems within a network, and retrieving
medical
imaging data from the identified storage systems prior to an examination of
the
patient.
In another embodiment, the invention is directed to a method comprising
receiving a request for an asset; determining a global unique identifier
{GUID)
associated with the requested asset; examining routing information to identify
storage
systems within a network, issuing queries to the storage system to determine
which
2
CA 02440730 2003-09-16
l , . 1
.1
storage systems have a local copy of the requested asset, wherein the queries
include
the associated GUID, and selectively retrieving one of the local copies of the
requested asset.
In another embodiment, the invention is directed to a method comprising
receiving user input defining routing information, generating a rule in
Extensible
Markup Language (XML) format based on the routing information, storing the XML-
based rule in a rule set, receiving a network communication comprising medical
imaging data, assessing the XNIL-based rule based on at least a portion of the
medical
imaging data, and routing the network communication based on the assessment of
the
XML-based rule.
The details of one or more embodiments of the invention are set forth in the
accompanying drawings and the description below. Other features, objects, and
advantages of the invention will be apparent from the description and
drawings, and
fi-om the claims.
BRIEF DESCRIPTION OF DRAWINGS
FIG. 1 is a block diagram illustrating an example system for communication
and storage of medical imaging data in accordance with the principles of the
invention.
FIG. 2 is a block diagram illustrating an example department having a number
of medical imaging devices coupled by routers.
FIG 3 is a block diagram illustrating an example embodiment of a router
according to the principles of the invention.
FIG. 4 is a flowchart providing a high-level overview of the routing process.
FIG. 5 is a flowchart illustrating the integration of routing and storage
functionality to manage medical imaging assets within a medical imaging
system.
FIG. 6 is a flowchart illustrating a mode of operation in which a router uses
routing information to facilitate the pre-fetching of storage assets.
FIG. 7 is a flowchart illustrating the integration of multiple medical imaging
departments.
FIG. 8 illustrates a unique communication format for exchanging and
interchanging data.
CA 02440730 2003-09-16
FIG. 9 is a flow chart illustrating routing of assets according to routing
information and an extensible markup language (XML) based rule set.
FIG. 10 illustrates an example user interface presented by a muter by which an
operator hierarchically defines routing logic and constructs a rule for a rule
set.
FIGS. 11-I7 illustrates example user interfaces for reconciling errors within
medical imaging data.
FIGS. 18-19 illustrate example user interfaces for managing patient
information.
FIG. 20 illustrates an example display presented by such a tool for debugging
and configuring a medical imaging environment.
DETAILED DESCRIPTION
FIG. 1 is a block diagram illustrating a system 2 for communication and
storage of medical imaging data. In particular, system 2 includes a health
care facility
having a number of departments 6 interconnected by router 10. Each department
6
may include a number of medical imaging devices. Departments 6 may include,
fox
example, medical modalities of different types, such as magnetic resonance
(MR),
computed tomography (CT), digital radiography (DR) or ultrasound. Each medical
modality may have different imaging characteristics and features, and may
generate
substantially different patient data and associated medical images. Each
department 6
may also include other medical imaging devices, such as a number of view
stations
for displaying and annotating medical images, an output device for printing
the
medical images, and a local archive for storing medical images.
In general, router 10 provides for seamless communication and distribution of
medical images and other patient data between the medical modalities and other
various medical imaging devices of departments 6. In particular, the medical
modalities and other various medical imaging devices communicate medical
imaging
"assets" to router 10 for routing to other devices within system 2. As
described it
detail below, router 10 implements certain protocols and file formats to treat
net<
communications as a self describing "assets" that encapsulate medical imaging
data.
For example, a self describing asset may include patient data, session data,
study data,
medical image data, private asset information, and the like.
4
CA 02440730 2003-09-16
Router 10 provides additional interfaces to other systems including a Hospital
Information System / Radiology Infozmation System (HIS/RIS) 8 that stores
patient
data, and a central storage system 12 that provides a central repository for
the storage
of medical assets. Router 10 also provides for remote communication of medical
imaging assets over network 14 to remote clinic 16 and, for example, a remote
physician 1 S wishing to remotely view medical assets. Network 14 may be any
Local
Area Network (LAN) or Wide Area Network (WAN) or may be a global network
such as the Internet.
Although illustrated within a medical imaging enviromnent, many of the
features and advantages of router 10 can be applied to a variety of
environments, and
to routing and data storage generally. For example, muter 10 may be used in
systems
for managing assets generally, such as photographic assets, insurance
information,
billing and accounting information.
The medical imaging devices of system 2 communicate the assets over
network 14 using a suitable network protocol. The medical modalities and other
devices may, for example, exchange data and information using a data
communications protocol developed by the American College of Radiology (ACR)
and the National Electrical.Manufacturers Association (NEMA) known as the
Digital
Imaging and Communications in Medicine (DICOM) protocol. Typically, the DICOM
protocol may be implemented using TCP/IP connections between medical devices
over a network, as illustrated in FIG. I, or using a point-to-point
communication
medium.
As described in detail below, router 10 integrates routing, network
management and storage functionality Router 10, for example, receives assets
and
intelligently routes the assets to medical devices within system 2 in
accordance with
routing information. In addition, router 10 provides interfaces to storage
systems by
implementing, for example, a set of storage "classes" required by the DICOM
protocol. In this manner, router 10 provides all functionality needed to
seamlessly
couple high-end imaging modalities and other medical devices directly to
storage
devices within a networked environraent.
FIG. 2 is a block diagram illustrating an example department 6A having a
number of medical imaging devices coupled to network 14 by department router 1
OA
CA 02440730 2003-09-16
and facility router l OB in accordance with the principles of the invention.
Department
router 10A routes images locally between, for example, medical modality 24,
view
station 26, local archive 20, and output device 28. Facility router ~1 OB
couples
department 6A to department 6B and network 14, which may be a private or
public
network.
As illustrated, routers I O integrate mulfiple medical imaging departwents 6.
Each department 6 may, for example, comprise a different DICOM "domain" having
a set of DICOM Application Entities (AEs), each having an AE Title. In this
manner,
routers 10 allow medical professionals to perform collaborative studies on
images,
even when the professionals may be in different facilities, even across the
country.
More particularly, router 10A provides DICOM CF>N'D and CMOVE services to
department 6A, and may be configured with a single AE for modality 24. In
addition,
router 10A may be configured to search for storage assets on Iocal archive 20.
Router
1 OB may be configured to forward CFIND and CMOVE requests to remote
locations,
1S including router IOA, remote clinic 16, remote physician 18 and one or more
routers
within department 6B.
In one embodiment, routers 10 manage the bandwidth consumed by medical
imaging data as assets are routed between departments 6 and network 14.
Medical
imaging data is inherently large compared with other network communications,
such
as electronic mail (email), that may also be present within system 2. To
minimize any
negative impact on the other network communications, routers 10 controls and
"throttles" medical imaging communications.
More specifically, to facilitate bandwidth management, routers 10 present user
interfaces by which an operator can limit maximum bandwidth consumption for
medical imaging network communications. The operator may 'indicate, for
example,
that such communications should consume no more than 60°l0 of the
available
network bandwidth. As each of routers 10 output network communications, the
routers 10 monitor the rates at which outbound data packets are transmitted,
and insert
sufficient time delays between transmissions to ensure the available
bandwidth, is
reserved.
Furthermore, the operator may define additional information for a "link"
within system 2. Generally, a link may be any physical connection between two
6
CA 02440730 2003-09-16
devices in a network. The operator may define; for example, times at which the
link
is available, or cost per megabyte of data on the link. In addition,.router 10
may
automatically detect the bandwidth of links to adjacent nodes within system 2,
typically by requesting such information from an operating system, such as
WindowsT"~ 2000, or one or more device drivers. Based on this information,
routers
may select particular links and schedule network communications to minimize
cost.
FICz 3 is a block diagram illustrating an example embodiment of router 10
according to the principles of the invention. In general, router 10 receives
inbound
10 network communication 32, often in the form of a storage asset communicated
in one
or more data packets, and forwards the network communication in accordance
with
routing information 34, which describes the topology of system 2. 1n
particular,
routing information 34 describes routes between the networked medical imaging
devices within system 2. Although illustrated within a medical imaging
environment
I 5 for exemplary purposes, the techniques described herein are not so
limited. Many of
the features and advantages of router 10 can be applied to a variety of
environments,
and to routing and data storage generally.
With respect to medical imaging environments that implement the DICOM
protocol, routing module 36 may arrange routing information 34 to map DICOM
"AENames" to default routes within system 2. Furthermore, routing information
34
may define a number of communication ports of the router, and within each port
a set
of acceptable AENames. This configuration can be particularly useful in
enforcing
security between medical imaging devices within the system 2. Tn addition,
router I O
may support a number of unique Internet Protocol (IP) addresses. For each IP
address, therefore, routing information 34 may define a number of ports, and a
number of corresponding AENames. In this manner, routing module 36 arranges
routing information 34 to provide access to the available AEs within one or
more
DICOM domains, thereby allowing router I 0 to present a multiple AE interface
to a
DICOM domain with which medical imaging devices of system 2 can readily
communicate.
Consequently, the AEName mapping supported by router 10 facilitates
"collaborative" archiving in which requests are automatically forwarded to a
number
7 " ~ ~<
CA 02440730 2003-09-16
of appropriate destinations. In particular, router 10 maps an AEName and a
type of
request to a list of destinations within system 2. In one embodiment, routing
information 34 includes two database tables to map a "called" AEName to a list
of
destinations. More specifically, routing module 36 maintains a "Basic
Connection
Information" table within routing information 34 to identify other devices
within
system 2 that need to receive a copy of an inbound asset. In one embodiment,
the
Basic Connection Information table contains the following Information:
1~ ~ Called AE Name - A name used to uniquely target (restrict) access
to specific destinations.
~ Request Type - Designates the type of.request - i.e. "Store,
Query, or Move"
o Type ~ Store (Transfer information to Archive(s))
~ List of routers to receive data on store requests from
this request name. This may be a list of 1-n Router
Names.
o Type = Query (Transfer Query to Archive(s))
~ List of 1 to N routers to receive request information for
a query request from this request name.
oType ~ Move tTransfer "Move Request" to Archive)
~ Router to request specific archive to retrieve data.
~ HostName/IP address - Address used to form a connection to this
Router. A zero in this field indicates that this router is a
"Destination" for this data:
Port Number - Port number used for connection to this router
Encryption - Enumerated field.with the type of encryption to be
used on the connection. (i.e. Public/Private key encryption.)
Compression - Enumerated field with the type of compression to be
used in this connection.
In addition, a "Local Destination" table within routing information 34 stores
the data
necessary for router 10 to form connections with the other devices in the
network. ~ In
one embodiment, the Local Destination table contains the following
information:
R ' ,
CA 02440730 2003-09-16
~ Called AE Name - Name used to uniquely target (restrict) access
to specific destinations.
~ New Called AE Name (Used by the Storage SCU agent as the
"Calling AE Name".)
S ~ Instance UID (To specifically identify an instance of an
application running on the target SCP system.)
HostName/IP address - Name/Address of the D2COM System to
receive the data. (A 0 in this field indicates that the data is
destined for an archive that is locally defined.
~ Port Number - Port number used to connect to the Locally (LAN)
attached DICOM bevice.
Roister 10 may also maintain a set of rules 38 to further control routing of
inbound network communications 32. Routing module 36 rnay use rules 38 to
1 S redirect a network communication to a different route, to evoke an
additional action,
such as deleting the data or reconciling the data, or to send the network
communication to one or more additional destinations.
Consequently, roofer 10 may implement a two-tier routing system in which
routing module 36 first examines destination information within an inbound
network
communication 32, and then applies rules 38 to the incoming data to determine
the
ultimate route(s). In this manner, routing module 24 may inspect at least a
portion of
the encapsulated non-pixel data before forwarding the asset to one oz more
destinations. Rules 38 may also be used to map or correct tagged data prior to
routing. Roister 10 may parse the incoming data, and use rules 38 to map a tag
to a
new meaning or format. A rule may be creaked, for example, to automatically
reformat patient identifiers as received from a medical imaging modality.
Furthezmore, the rules rnay be used to selectively propagate or filter
messages or
particular commands, such as DICOM commands, along one or more specific
routes.
In one embodiment, routing information 34 describes each route as either
"local" or "external." External routes may be further qualified as "direct" or
"batch."
A local route descriptor causes routing module 36 to route an inbound asset to
local
database 40. Conversely, an external route descriptor causes routing module 36
to
route an asset to a networked device within system 2. Furthermore, a "direct"
external route descriptor causes roister 10 to immediately forward the asset
to the
r
F.:.
CA 02440730 2003-09-16
.>
destination. Router 10 waits until receiving an acknowledgement from the
destination
before sending an acknowledgement back to .the source modality. In this
manner, the
asset is stored in multiple locations, and router 10 guarantees storage of the
asset to
the modality with a single acknowledgement. A "batch" descriptor for an
external
route, however, causes router 10 to store the asset locally and immediately
acknowledges the source modality. At a later point in time, router 10 batch
transfers
the buffered assets to their respective destinations, This mode may
advantageously
increase patient throughput at the modalities.
Connection manager 42 receives storage asset of inbound network
communication 32, typically from a medical modalities upon completion of an
exam,
and initiates the routing process of router 10. In particular, connection
manager 42
listens to a well-known communication port for communications from any network
device. Upon receiving a message from such a device, connection manager 42
immediately invokes two software modules, such as by instantiating two
threads, for
parallel processing the inbound storage asset. Connection manager 42
instantiates
storage manager 44, which is responsible for receiving and buffering an
incoming
asset to local storage 49, and verification module 46, responsible for
validating the
non-pixel data encapsulated within the storage asset.
After invoking storage manager 44 and verification module 46, connection
manager 42 directs the inbound communications to a new socket, and passes a
handle
to the socket to each of storage manager 44 and verification module 46. In
this
manner, storage manager 44 and verification module A6 receive data of an
inbound
asset in parallel, each processing selected portions of the asset.
Consequently, router
10 may be able to achieve higher utilization of network bandwidth by ensuring
that
assets are quickly and efficiently retrieved from network 14. This is
particularly
advantageous in the medical imaging environment where the data portions can be
significantly large. In one embodiment, storage manager 44 and verification
module
46 make use of a ringtail buffer that stores data of the inbound asset as
router 10
receives the from the network. The use of a single buffer allows verification
module.
46 and storage manager 44.to avoid multiple copies of the asset, which saves
processing time, memory space, and can reduce errors and discrepancies.
~n
CA 02440730 2003-09-16
Storage manager 44 receives the asset, including tagged data and pixel data,
and stores the asset to local storage 49 at a high rate. In one embodiment,
storage
manager 44 streams the incoming asset to a file located on a high-speed
computer
readable medium within the router, such as a hard disk.
S Verification module 46 receives and process the non-pixel data within the
asset to verify and validate all syntactical and semantical information.
Within a
medical imaging environment, for example, verification module may verify and
validate all syntactical and semantical information of the encapsulated
patient
information, session information, study information and image information.
I O Verification manager 46 extracts non-pixel data associated with each
image, and
stores the non-pixel data in temporal database 40A, permanent database 40B, or
both,
thereby allowing an operator to retrieve the information during a subsequent
examination. In one embodiment, temporal database 40A is configured to
automatically prune assets after a period of time.
15 Upon detecting missing or invalid data within an incoming asset,
verification
module 46 issues a reconciliation event 37 to patient manager 48, which
provides for
the reconciliation of medical imaging data, such as patient information,
session
information and the like. In one mode of operation, router I O does not
forward storage
assets to destinations, such as central storage system 12, until the
encapsulated data
20 has been fully reconciled.
In one embodiment, verification module 46 maintains a DICOM dictionary
within local database 40 for storing "private" (user-defined) DICOM tags that
are
defined by modalities and other devices within the system. When verification
module
46 encounters a new private tag, verification module 46 collects and stores
all
25 pertinent information related to the private tag including, for example, a
UID, a
version, and a source for the tag. In this manner, router 10 builds the DICOM
data
dictionary in "real-time." Based on this information, router 10 can uniquely
identify
where the private tags originate.
Upon validation of the encapsulated data by verification module 46, routing .
30 module 36 examines non-pixel medical image data from message queues 41,
determines the appropriate route, and enqueues a network communication within
output queues 4$ for transmission to a destination by output interface 47. The
. r!
'i
.j
11 '
CA 02440730 2003-09-16
queued outbound network communication contains pointers to corresponding non-
pixel data within message queues 41 and portions of the pixel data stored on
local
storage 49. In this manner, routing module 36 may ready a storage asset for
output
communication, even piior to storage manager 44 writing the entire pixel data
of the
asset to the local storage 49. Consequently, router 10 may commence an
outbound
network communication 45 of an asset prior to receiving all of the asset data
from
inbound network communication 32. While outputting the communication to the
network, output interface 47 uses the pointers to read the messages from
message
queues 41 and extracts the corresponding pixel data from the Iocal storage 49
to form
an outbound communication.
Furthermore, routing module 36 and output interface 47 are capable of sending
storage assets to multiple destinations in parallel such that the assets are
available
when needed by medical professionals. Tf a particular doctor works in two
hospitals
and a clinic, for example, routing module 36 may route the assets generated
from an
examination to multiple devices at both hospitals and the clinic. Output
interface 47
communicates the assets to the multiple destinations in parallel.
As discussed above, verification module 46 issues a reconciliation event 37
when encapsulated data of an inbound network communication 32 is invalid or
missing. Upon receiving a reconciliation event 37, patient manager 48 examines
routing information 34 to identify network destinations that may store
relevant patient
information, and queries the remote destinations in an attempt to
automatically
reconcile the data. Patient manager 48 may, for example, invoke HIS/RIS
interface
39 to retrieve patient data from a remote HIS/RIS system 8. Tn this manner,
patient
manager 48 may leverage routing information 34 to identify the available data
sources
within the system 2. In addition, as illustrated below, patient manager 48
provides a
user interface by which an operator can manually query the remote network
resources
and reconcile the non-pixel data rwithin a storage asset, such as the
demographical
information for a patient.
Patient manager 48 performs a number of quality control functions in addition
to reconciling data, including asset reprocessing, patient management, and pre-
fetching assets prior to an examination of a patient. Tn general, the patient
management functionality allows an operator.to update patient information,
delete a
Z2
CA 02440730 2003-09-16
patient, or otherwise manage patient data stored within the local database or
a master
database. In addition, patient manager 48 facilitates system wide searching by
leveraging routing information 34. By interacting with a user interface
presented by
patient manager 48, an operator can search local database 40 for images, or
direct
patient manager 48 to send search requests to other medical devices in
accordance
with routing information 34.
FICz 4 is a flowchart providing a high-level ovez-view of the routing process
carried out by router 10. As described above, router 10 stores routing
information 34
that describes routes between the networked medical imaging devices within
system 2
(50), and stores a set of rules 38 to further control routing of network
communications
(52).
Upon receiving a network communication comprising one or more medical
imaging assets (54), router 10 validates the encapsulated non-pixel medical
imaging
data (55) and buffers the pixel data to a local storage (56) in parallel. Upon
validating
the data, or upon reconciling and invalid or missing data (57), router 10
identifies
destination information within the assets, and compares the non-pixel medical
imaging data encapsulated within the assets to the set of rules 3 S (5 8).
Router 10
forwards the network communications in accordance with the destination
information
and the results of the comparisons (59).
FICx 5 is a flowchart illustrating the integration of routing and storage
functionality to manage medical imaging assets within a medical imaging
system.
Upon receiving a new asset from a source modality (60), such as upon
completion of
an examination of a patient, router 10 queries central storage system 12 for a
new
global unique identifier (GUID) (61). Upon receiving the new GUID for the
asset,
router 10 forwards the asset to one ore more storage devices, such as a local
archive
20 and central storage system 12 (62). In this manner, system 2 maintains
unique
global identifiers for each copy of a storage asset. This technique has many
advantages, including simplifying routing assets between multiple storage
systems
and medical imaging devices.
An operator, such as a physician, may periodically wish to view stored assets.
Upon receiving a subsequent request for the stored asset (63), router 10
examines
routing information 34 to identify storage systems within system 2 (64). In
other
13 '
CA 02440730 2003-09-16
1
words, router 10 leverages routing information 34 to facilitate identification
of
potential locations within system 2 for a requested asset. Upon identifying
the
Locations, router 20 queries the storage system to locate the requested asset
(65).
Router 10 may, for example, issue one or more "CFTND" commands to the storage
systems to determine which storage systems are currently storing the requested
asset,
or copies thereof.
Because multiple copies of the asset may exist within system 2, one or more of
the storage systems may respond to queries. Router 10 selects one of the
storage
systems based on a variety of criteria (66), including bandwidth of network
connections between the storage systems and the requesting device, speed and
type of
media used by the storage system, and whether the requested asset is
immediately
accessible by the storage systems, or must be retrieved from an offline
storage
medium, such as tape. Upon selecting one of the storage systems, router 10
issues a
move command to the selected storage system to move the requested asset to the
1 S requesting medical imaging device (67).
FICx 6 is a flowchart illustrating a mode of operation in which router 10 uses
routing information 34 to facilitate the pre-fetching of storage assets,
thereby making
the assets immediately available physicians and other operators. Router 10
may, for
example, pre-fetch storage assets for a patient prior to a follow=up
examination of the
patient.
Typically, an operator will interact with the HIS/RIS system 8 and schedule an
examination of a patient. In response, HIS/RIS system 8 will issue a
scheduling event
(70) through a standard communication protocol such as HL7. Upon receiving the
event, router 10 examines routing information 34 (72) to idenrify available
routes
within system 2, and issues queries, such as CFIND commands according to the
DICOM protocol, to locate the assets related to a particular patient ('~4).
After locating the assets, router 10 updates a pre-fetch schedule based on the
locations of the assets, the scheduled time for the examination, and
characteristics of
the links within system 2 including availability and cost (76). In particular,
router 10
may present a user interface by which an operator can identify and select the
particular patient information to be pre-fetched prior to the examination. By
14
CA 02440730 2003-09-16
interacting with the interface, the user can view patient information and
schedule pre-
fetching the corresponding assets.
At the scheduled time (78), muter 10 initiates the cooperative pre-fetching
and
movement of the assets by issuing 1 to N move commands to move the assets from
storage devices to the modality scheduled to perform the patient examination
and
imaging session (80). Typically, a batch move software module operating on
router
examines the pre-fetch schedule, and moves the assets as needed to an
appropriate
temporal storage within one or more departments 6. In particular, router 10
selects the
relevant assets to move in accordance with rule set 25. Router 10 may, for
example,
I 0 move a subset of the located assets based on the modality type, patient
ID,
examination area of a patient, and the like. In this manner, router 10 may not
necessarily move all of the assets for a given patient, but only those assets
relevant to
the scheduled examination.
Router 10 performs similar operations upon receiving a CFIND request from
another medical imaging device within system 10, such as another router. In
response
to receiving a CFIND request, for example, from another router, router 10
examines
routing information 34 to map the designated AEName to a route, and then to
one or
more locations. Router 10 then issues CFllVD r equests to the identified
locations in
accordance with routing information 34 in order to locate all of the assets
associated
with a particular find request. During prefetching operations, router 10
enforces
security and other policies to provide secure access to patient data.
FICx 7 is a flowchart illustrating~the integration bf multiple departments b
via
router 10 in further detail. As described above, each department 6 may include
a
number of digerent types of devices including an archive manager, a clinical
view
station, and a number of imaging modalities. According to the DICOM protocol,
proper communication with each of these devices requires a remote device to
have
knowledge of, and correctly use, a number of unique identifiers specific to
the
DICOM "domain" of each department. A DICOM compliant device may be
identified by, for example, a unique id~tifier, a version, and an AETtitle. In
order to
facilitate communications with a variety of network devices, router 10 can
operate in
an emulation mode in which router IO detects the identifiers, and translates
inbound
15 ~;
t.:.
CA 02440730 2003-09-16
and outbound network communications to the department in accordance with the
identifiers.
In particular, router 10 may establish a temporary connection, referred to as
an
"association" by the DICOM protocol, with one or more of the devices of the
department (8I), typically causing one of the devices to respond with a unique
identifier (UID), a version number, an AETitle. Router 10 extracts the domain
identifiers from the response (82) and builds a translation table for
translating inbound
and outbound communications from the department 6 (83).
Upon receiving an inbound or output network communication (84), muter 10
parses the network communication and translates the encapsulated domain
identifiers
in accordance with the translation table (85). Upon translating the
identifiers, muter
I 0 forwards the network communication based on routing information 34 (86).
In this
manner, router 10 presents dual interfaces that map external identifiers to
the assumed
domain identifiers of a department or other medical imaging domain and,
thereby,
allows external devices to seamlessly communicate with the devices within the
assumed domain. In other words, remote medical imaging devices need not know
the
specific domain identifiers of medical imaging devices within a department in
order to
communicate with the devices.
FICx 8 illustrates a unique communication format 86 supported by router 10
for exchanging and interchanging data. In the illustrated embodiment, format
86
includes asset meta information 87A, medical imaging information 87B, pixel
data
87C, thumbnail data 87D, patch data 87E, and error correction and detection
information 87F
Header information 87A includes all routing information necessary for router
I O to route the asset within system 2. Medical imaging information 87B
includes raw
data received from the modality that describes the recent examination,
including the
patient information, session information, study information and image
information.
Medical imaging information 87B may include, for example, related DICOM tags
and
messages. Pixel data 87C includes the medical images generated by the
examination,
while thumbnail data 87D includes low-resolution versions of the images for
quick
display. Thumbnail data 87D contains data that router 10 has extracted from
the pixel
data 87C, and stored for quick access by view stations. This allows for the
"pre-
16
CA 02440730 2003-09-16
building" and retention of thumbnail data so that the data can be quickly
retrieved and
displayed.
Patch data 87E includes aII modifications to medical imaging information
87B, which was originally generated by the source modality. In other words,
the
original data is not modified. Rather, the asset includes patch data 87E that
stores aII
of the updated data and, in particular, a revision history including the date
and time of
the change, and operator that made the change. In other words, during the
reconciliation process, patient manager 48 stores all updates and
modifications of an
asset within the patch data 87E of the exchange format 86. In this manner,
exchange
format 86 facilitates compliance with regulations that require change tracking
and
revision histories and furthermore, facilitates storages of the information
within a
single self-describing data asset.
When a view station presents the data to an operator, patch data 87E overrides
the medical imaging 87B. However; the operator may always view the revision
history and the original medical imaging data 87B. Error detection and
correction
information 87F, such as a cyclical redundancy check (CRC), includes
additional data
useful for detecting changes to data encapsulated by an asset, or errors
during
transmission. The following description provides further details an example
file
format 86 for use with DICOM storage assets.
?0 For use in a DICOM compliant environment, the contents of the header
information 87A is defined to document ownership and version control, and to
provide a mechanism to gain efficient access to other pai~ts of the format.
The
contents may be as follows:
Version [25] - Documents the version of this File." Format V1.00"
~5 CopyRight [120] - Legal Statement identifying the ownership of this
format.
StartOfHeader - Offset from beginning of file to start of Header
(Normally 0)
EndOfFieader - Offset from beginning of file to End of Header
30 StartOfCommand - Offset from beginning of file to Start of DICOM
Command Data
EndOfCommand - Offset from beginning of file to End of DICOM Command
s..
Dat a
StartOfData - Offset from beg3t~uiing of file to Start of DICOM Data
r~~
CA 02440730 2003-09-16
EndOfData ' Offset from beginning of file to End of DICOM Data
StartOfPixel - Offset from beginning of file to Start of Pixel Data
EndOfPixel - Offset frgm beginning of file to End of Pixel Data
StartOfThumbnail - Offset from beginning of file to Start of
Thumbnail Data
EndOfThumbnail - Offset v End of Thumbnail Data
StartOfPatches - Offset from beginning of file to Start of Patch Data
EndOfPatches - Offset from beginning of file to End of Patch Data
DestinationAPTitle [DILIB~VR'LENGTH~AE + Z]
- Called AE Name in DICOM Association (Target for Storage of this
Image)
ImageGUID [DILIB GUIDLENGTH] - Image GUTD within ADA Database
SeriesGUID [DILIB GUIDLENGTH~Series Folder GUID within ADA Database
StudyGUID [DILIB GUIDLENGTH] - Study Folder GUID within ADA Database
PatientGUID [DILIB GUIDLENGTH] - Patient Folder GUID within ADA
Database
ADASeriesToStudyGUID [DILIB GUIDLENGTH] - Series to Study GUID within
ADA Database
ADAStudyToPatientGUID [DILIB GUIDLENGTH] - Study to patient GUID
(Link) within ADA Database
Checksum - Checksum computed when data arrives at an archive
Port - Port number used when data was transmitted
TransferSyntax - Transfer Syntax used to transfer this data
ApplicationContextName [DILIB VR LENGTH_PN + 1) - Application Name
~5 (If Present) of device that stored this data to an archive.
CallingAPTitle [DILIB'VR LENGTH AE + 1] - Calling AE Name used by
calling device to create ~association~
CalledAPTitle [DILIBrVR LENGTH AE + 1] - Called AE Name used by
calling device to create association
3~ RespondingAPTitle [DILIB VR LENGTH AE + 1] -' Responding AE Name when
Association was internally generated.
MaxPDU - Max PDU Size as negotiated on the Association.
Result - DUL Result captured when Image Arrived
ResultSource - DUL ResultSource captured when Image Arrived
35 Diagnostic - DUL Diagnostic Value captured when Image Arrived
Ca111ngPresentationAddress [DILIB VR LENGTH~UI + 1] - Calling
HostName/IP address for association
Call,edPresentatidnAddress [DILIB,VR LENGTH_UI + 1] Called HostName/IP
address for association '
]R
CA 02440730 2003-09-16
MaximumOperationsInvoked - Maximum Operations Invoked from
association information
MaximumOperationsPerformed - Maximum Operations Performed from
association information
CallinglmplementationClassUID [DICOM UI~LENGTH + Z]- - Implementation
Class UID of Calling Software - captured during Association
Negotiation
CallinglmplementationVersionName [DILIB MAXIMPNAMELENGTH + 1]
Implementation Name of Calling Software - captured during
0 Association Negotiation
CalledImplementationClassUID [DICOM~UI LENGTH + 1] - Implementation
Class UID of Called Software - captured during Association
Negotiation
CalledlmplementationVersionName [DILIB VR LENGTH_SH + 1] -
5 Implementation Name of Called Software - captured during
Association Negotiation
PeerMaxPDU - Max PDU for transmission to Peer Device - captured
during Association Negotiation
EsopLength - Extended SOP Length - captured during Association
:0 Negotiation
Medical imaging information 8~B contains tags defined within the DICOM as
"Group 0" tags. These tags are part of Command Re~uest/Response information
that
must be present with each~DICOM Message. Medical imaging information 8~B may
,S also contain DICOM data tags that defined within the DICOM Standard from
Group
0002, Element 0000 through Group 7FE0 Element 0000. These tags are considered
the "payload" of a DICOM compliant message and contain a wide range of
information relating to the patient, physician, image characteristics, and the
like.
These tags may be saved within the a file and arranged as Follows:
<tag (group/element)> <Length> <Data> ,
<tag (group/element)> <Length> <Data>
j
<tag (group,/element)> <Length> <Data>
.I
<tag (group/element)> <Length> <Data>
~1
19
CA 02440730 2003-09-16
Pixel data 87C contains the DICOM data tag group 7FE0 Element 0010 that
designates the pixel data of the DICOM image(s). This tag and the
corresponding
pixel data are stored within pixel data 87C, which may be a "byte-for-byte"
copy of
the data as received by roister 10 from an imaging modality.
Patch data 87E may be arranged as follows:
<tag (group/element)> <Length> <Data><Change
Timestamp><Operator>
<tag (group/element)> <Length> <Data><Change
Timestamp><Operator>
<tag (group/element)> <Length> <Data><Change
Timestamp><Operator>
<tag (group/element)> <Length> <Data><Change
Timestamp><Operator>
FICA 9 is a flow chart illustrating routing of assets according to routing
information 34 and an XML-based rule set 38. As described above with reference
to
FICZ 3, routing module 36 implements a two-tier routing scheme in which
routing
module 36 first examines destination information within a network
communication,
such as an AEName~, and then applies rules 38 to the incoming data to
determine the
ultimate route(s). Advantageously, routing module 24 maintains the rule set in
eXtensible Markup Language format (XML) by which the user can easily create a
complex grammar for routing assets. For example, the user may create rules for
muting assets based on patient ID, modality, referring physician and the like.
In
addition, the user may define any number of tags to control routing of assets
by roister
10.
Initially, roister 10 presents a user interface by which a user defines a set
of
routing rules (90). In particular, the user interacts with the user interface
to define a
grammar and logic for a rule for routing assets within system 2. Based on the
received input, roister 10 generates a rule in XML format (91) and updates
rule set 24
(92).
CA 02440730 2003-09-16
Once router 10 has updated rule set 38, routine module 10 applies the XML-
based rules to network communications. In particular, router 10 receives a
network
l
communication (93), such as an asset containing medical imaging data, assesses
the
rules of rule set 24 based on the network communication, and routes the
network
communication accordingly (94).
FIG 10 illustrates an example user interface 95 presented by router 10 by
which an operator hierarchically defines routing logic and constructs a rule
for rule set
38. In particular, the operator can input a rule name 9'7, and hierarchically
define
specific data tags, 95, logical operators 98 and corresponding data values 99
for the
rule as a complex grammar.
FIG. 11 illustrates an example user interface presented by patient manager 48
upon detecting errors within medical imaging data received from the various
departments 6. In particular, user interface 100 displays a list of
reconciliation events
that have been generated by router 10 upon receiving and detecting mismatched
or
S otherwise invalid data. In the illustrated example, interface 100 displays
event list
102 having three events. For each event, interface 100 displays an identifier
for the
medical imaging tag corresponding to the data in error, a source medical
imaging
modality, an event identifier, a date and time of the event, a patient
identifier, a study
identifier, a series identifier, and an image identifier. Fox each event, the
use may
0 select and highlight the event and elect to view the properties of the
event.
FIG. 12 illustrates an example user interface 104 displayed by patient manager
48 when the user elects to view the properties of a particular reconciliation
event. In
particular, user interface 104 displays the data associated with the event in
hierarchical fashion. User interface I04, for example, displays patient data
106, study
data 108, series data 110, and image data 112 that relate to the event. In
addition, user
interface 104 highlights the tag 114 for which patient manager 48 has
identified
missing or invalid data. Upon selecting the tag, user interface 104 displays
window
1 I6 by which the user can reconcile the data. In particular, the user may
elect to edit
the data directly, or search a number of resources within system 2, including
a
0 DICOM database storing m~ical imaging information, as well as an HIS/RIS
database. Upon selecting one of the resources, patient manager 48 polls the
selected
n . ., 1
21
CA 02440730 2003-09-16
resource and displays any identified relevant data in order to assist the
operator in
reconciling the missing data in the storage asset.
FIG. 13 illustrates an example user interface 120 displayed by patient manager
48 when the user elects to edit data element directly. During this process
user
interface 120 displays an edit window 122 within which the operator may enter
the
relevant data, thereby reconciling and clearing the event. After receiving the
data
from the operator, patient manager 48 verifies that the data has been entered
in the
correct format.
FIG. 14 illustrates an example user interface 124 displayed by patient manager
48 upon retrieving patient information from a network resource such as a DICOM
database. In other Words, patient manager 48 queries a network resource in
order to
identify and retrieve any relevant patient information that may assist the
operator in
reconciling the mismatched data of the current medical imaging session, and
presents
the information to the user. Upon viewing user interface 124, the operator may
direct
1 S patient manager 48 to automatically update the missing or invalid data of
the current
medical imaging session. FIGS. 1 S, 16 and 17 illustrate similar user
interfaces 126,
128, 130 displayed by patient manager 48 when the operator reconciles image
information, series information and study information, respectively.
FIG. 18 illustrates an example user interface i32 displayed by patient manager
48 with which the operator interacts to batch process reconciliation events.
In
particular, user interface 132 allows the user to group similar events, i.e.,
events
originating from the same imaging session in which similar data is mismatched.
In
this manner, the operator can reconcile common mismatched or invalid data,
such as a
misspelled patient name, and immediately correct and reconcile the data
throughout
all of the assets related to a common session.
FIG. 19 illustrates an example interface 134 displayed by patient manager 48.
In particular, user interface 134 provides an interface to searching
functionality and
patient management functionality. The operator can enter a variety of search
criteria
within input area 136, directing router 10 to examine the routing information,
identify
remote storage devices within system 2, and retrieve patient information from
the
storage devices or other systems such as HIS/RIS system 14. Upon retrieving
relevant patient information, user interface 134 allows the operator to
manipulate and
22
CA 02440730 2003-09-16
otherwise maintain the patient information including initiating a new study,
editing an
existing patient, deleting a patient, viewing relevant patient data, and
merging a
number of patients into a common patient information.
Router 10 includes tracing functionality to aid in configuring, debugging and
testing a medical imaging system 2. Tn particular, upon enabling tracing,
router 10
captures binary data received in an inbound network communication and stores
the
data locally prior to processing and forwarding the asset. The trace output
can be
"piped" into debugging tools running on a local workstation or other computing
device, for simulation and debugging, In this manner, a remote technical
service
I 0 personnel can assist in the proper configuration of router 10 within a
medical imaging
system 2. FIG. 20 illustrates an example display 138 presented by such a tool,
including the raw hexadecimal data as well as the raw data translated into
DICOM
commands.
Various embodiments of the invention have been described. These and other
embodiments are within the scope of the following claims.
. , . ,:
c
23
t..:
