U.S. patent application number 09/911844 was filed with the patent office on 2002-02-21 for routing medical images within a computer network.
Invention is credited to Gendron, David Pierre, Kingsbury, Dale Philip, Romatoski, Jeffrey Allen, Sitka, Larry Robert.
Application Number | 20020023172 09/911844 |
Document ID | / |
Family ID | 22824122 |
Filed Date | 2002-02-21 |
United States Patent
Application |
20020023172 |
Kind Code |
A1 |
Gendron, David Pierre ; et
al. |
February 21, 2002 |
Routing medical images within a computer network
Abstract
A router includes a 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 information 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.
Inventors: |
Gendron, David Pierre; (Coon
Rapids, MN) ; Kingsbury, Dale Philip; (Little Canada,
MN) ; Romatoski, Jeffrey Allen; (Woodbury, MN)
; Sitka, Larry Robert; (Stillwater, MN) |
Correspondence
Address: |
SHUMAKER & SIEFFERT, P. A.
150 GATEWAY CORPORATE CENTER 1
576 BIELENBERG DR.
ST. PAUL
MN
55125
US
|
Family ID: |
22824122 |
Appl. No.: |
09/911844 |
Filed: |
July 24, 2001 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60220586 |
Jul 25, 2000 |
|
|
|
Current U.S.
Class: |
709/238 |
Current CPC
Class: |
G16H 40/67 20180101;
G16H 30/20 20180101; H04L 9/40 20220501; H04L 45/00 20130101; H04L
67/06 20130101; H04L 69/26 20130101; H04L 67/565 20220501; H04L
67/12 20130101; H04L 67/563 20220501; H04L 67/564 20220501; H04L
45/54 20130101; H04L 45/306 20130101; H04L 69/329 20130101; G16H
10/60 20180101; H04L 67/568 20220501 |
Class at
Publication: |
709/238 |
International
Class: |
G06F 015/173 |
Claims
1. A method comprising: storing routing information mapping
destinations to routes within a network; storing a set of routing
rules; receiving a network communication comprising destination
information and data; comparing at least a portion of the data to
the set of routing rules; selecting a route from the routing
information based on the destination information of the network
communication and a result of the comparison; and forwarding the
network communication according to the selected route.
2. The method of claim 1, wherein the network comprises a medical
imaging network and the network communication complies with the
DICOM protocol, and further wherein storing routing information
comprises storing routing information mapping Application Entity
Names (AENames) to routes within the medical imaging network.
3. The method of claim 2, wherein selecting a route from the
routing information comprises comparing an AEName defined within
the network communication to the AEName defined within the routing
information.
4. The method of claim 1, wherein the network communication
complies with the DICOM protocol, and further wherein comparing at
least a portion of the medical imaging data comprises: parsing the
medical imaging data to identify a set of DICOM tags and
corresponding data; and assessing a routing rule from the set of
routing rules based on the DICOM tags and corresponding data.
5. The method of claim 1, wherein storing a set of routing rules
comprises storing an XML-based set of rules, wherein the rules
conform to a user-defined grammar for routing the medical imaging
data.
6. The method of claim 5, further comprising presenting an
interface for receiving user input that defines the user-defined
grammar.
7. A router comprising: a computer-readable medium storing routing
information mapping destinations to routes within a medical imaging
network, and storing a set of routing rules; and a routing module
that selects a route from the routing information 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.
8. The router of claim 7, wherein the routing information maps
DICOM Application Entity Names (AENames) to routes within the
medical imaging network.
9. The router of claim 7, wherein the routing 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.
10. The router of claim 7, wherein the set of rules includes rules
defined by the eXtensible Markup Language (XML), and which conform
to a user-defined grammar for routing the medical imaging data.
11. The router of claim 10, further comprising a user interface for
presenting an interface for receiving user input that defines the
user-defined grammar and the rules.
12. A computer-readable medium storing data comprising routing
information mapping destinations to routes within a medical imaging
network, wherein the routing information maps DICOM Application
Entity Names (AENames) to routes within the medical imaging
network.
13. The computer-readable medium of claim 12, further storing a set
of routing rules, wherein the set of rules includes rules defined
by the eXtensible Markup Language (XML), and which conform to a
user-defined grammar for routing the medical imaging data.
14. A computer-readable medium having instructions thereon to cause
a programmable processor to: store routing information mapping
destinations to routes within a medical imaging network; store a
set of routing rules; receive a network communication comprising
destination information and medical imaging data; compare at least
a portion of the medical imaging data to the set of routing rules;
select a route from the routing information based on the
destination information of the network communication and a result
of the comparison; and forward the network communication according
to the selected route.
15. The computer-readable medium of claim 14, wherein the network
communication complies with the DICOM protocol, and further wherein
the instructions cause the processor to store routing information
mapping Application Entity Names (AENames) to routes within the
medical imaging network.
16. The computer-readable of claim 15, wherein the instructions
cause the processor to compare an AEName defined within the network
communication to the AEName defined within the routing
information.
17. The computer-readable of claim 16, wherein the instructions
cause the processor to: parse the medical imaging data to identify
a set of DICOM tags and corresponding data; and assess the routing
rules based on the DICOM tags and corresponding data.
18. 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 XML-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.
19. The method of claim 18, wherein the user input defines a
grammar for routing medical images within a medical imaging
environment.
20. The method of claim 18, wherein the user input defines tags
including a patient identifier, an imaging modality.
22. A method comprising: detecting medical imaging application
information for a first domain within a medical imaging network;
receiving a network message having a destination within the first
domain; translating application information within the network
message to the application information for the first network
domain; and forwarding the network message to the destination.
23. The method of claim 22, wherein detecting medical imaging
application information includes establishing a temporary
association with a medical imaging device within the first
domain.
24. The method of claim 22, wherein detecting the medical imaging
application information includes detecting an Application Entity
Title (AETitle), a DICOM version and a unique identifier (UID).
25. The method of claim 22, wherein translating the application
information includes parsing data within the network message to
identify the application information of network message.
26. 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.
27. The method of claim 26, wherein retrieving the medical imaging
data comprises issuing move commands requesting the identified
storage systems move the medical imaging data to a destination
device.
28. The method of claim 27, wherein the destination device
comprises a medical imaging modality.
29. The method of claim 26, wherein retrieving the medical imaging
data comprises: scheduling a pre-fetch operation based on the exam
information; and issuing move commands based on the scheduled
pre-fetch operation.
30. The method of claim 29, further comprising issuing queries to
the identified storage systems to locate storage assets relating to
a patient.
31. The method of claim 30, wherein issuing queries comprises
issuing CFIND commands according to the DICOM protocol.
32. The method of claim 30, further comprising selecting at least
on of the storage systems based on characteristics of a network
link between the selected storage system and a destination
device.
33. A router comprising: a computer-readable medium storing routing
information mapping destinations to routes within a medical imaging
network; and a patient management module to receive examination
information for a patient, and to retrieve medical imaging data
prior to an examination of the patient based on the routing
information.
34. The router of claim 34, wherein the patient management module
examines the routing information to identify storage systems within
the medical imaging network.
35. The router of claim 34, wherein the patient management module
schedules a pre-fetch operation based on the examination
information, and issues move commands based on the scheduled
pre-fetch operation.
36. The router of claim 35, wherein the patient management module
issues queries to the identified storage systems to locate storage
assets relating to a patient.
37. The router of claim 36, wherein the patient management module
issues CFIND commands according to the DICOM protocol.
38. 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 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.
39. The method of claim 38, further comprising: receiving a new
storage asset from a medical imaging modality; and assigning the
global unique identifier (GUID).
40. The method of claim 38, wherein selectively retrieving the
requested asset comprises issuing a DICOM MOVE command to one of
the storage systems.
41. The method of claim 38, wherein selectively retrieving the
patient information comprises selecting one of the storage systems
based on a characteristic of a connection between the storage
system and a requesting device.
Description
[0001] This application claims priority from U.S. Provisional
Application Serial No. 60/220586, filed Jul. 25, 2000, the entire
content of which is incorporated herein by reference.
TECHNICAL FIELD
[0002] The invention relates to routing and storage within a
computer network.
BACKGROUND
[0003] A computer network includes a variety of computing devices
that communicate and share resources and data. A medical imaging
environment, for example, may include a number of networked devices
including a medical imaging modality that generates medical images
of a patient, a diagnostic view station for displaying the images,
an output device for printing 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 and Communications in Medicine (DICOM). In
general, DICOM defines vendor-independent data formats and data
transfer services for digital medical images.
[0004] In many conventional networks, the devices communicate over
a packet-based network by dividing the data 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 from the packets 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.
[0005] 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 router forwards the packet in
accordance with the routing information.
[0006] The routers 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 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.
SUMMARY
[0007] 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.
[0008] In one embodiment, the invention is directed to a router
that includes a 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 information 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.
[0009] 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.
[0010] 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
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.
[0011] 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 XML-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.
[0012] 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 from the
claims.
BRIEF DESCRIPTION OF DRAWINGS
[0013] 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.
[0014] FIG. 2 is a block diagram illustrating an example department
having a number of medical imaging devices coupled by routers.
[0015] FIG. 3 is a block diagram illustrating an example embodiment
of a router according to the principles of the invention.
[0016] FIG. 4 is a flowchart providing a high-level overview of the
routing process.
[0017] FIG. 5 is a flowchart illustrating the integration of
routing and storage functionality to manage medical imaging assets
within a medical imaging system.
[0018] 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.
[0019] FIG. 7 is a flowchart illustrating the integration of
multiple medical imaging departments.
[0020] FIG. 8 illustrates a unique communication format for
exchanging and interchanging data.
[0021] FIG. 9 is a flow chart illustrating routing of assets
according to routing information and an extensible markup language
(XML) based rule set.
[0022] FIG. 10 illustrates an example user interface presented by a
router by which an operator hierarchically defines routing logic
and constructs a rule for a rule set.
[0023] FIGS. 11-17 illustrates example user interfaces for
reconciling errors within medical imaging data.
[0024] FIGS. 18-19 illustrate example user interfaces for managing
patient information.
[0025] FIG. 20 illustrates an example display presented by such a
tool for debugging and configuring a medical imaging
environment.
DETAILED DESCRIPTION
[0026] 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, for 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.
[0027] 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 in detail below, router 10 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.
[0028] Router 10 provides additional interfaces to other systems
including a Hospital Information System/Radiology Information
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 18 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.
[0029] Although illustrated within a medical imaging environment,
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, router 10 may be used in systems for
managing assets generally, such as photographic assets, insurance
information, billing and accounting information.
[0030] 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. 1,
or using a point-to-point communication medium.
[0031] 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 environment.
[0032] 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 10A and facility router 10B 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
10B couples department 6A to department 6B and network 14, which
may be a private or public network.
[0033] As illustrated, routers 10 integrate multiple medical
imaging departments 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 CFIND 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 local archive
20. Router 10B may be configured to forward CFIND and CMOVE
requests to remote locations, including router 10A, remote clinic
16, remote physician 18 and one or more routers within department
6B.
[0034] 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.
[0035] 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% 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.
[0036] Furthermore, the operator may define additional information
for a "link" within system 2. Generally, a link may be any physical
connection between two 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 Windows.RTM. 2000, or one or more device
drivers. Based on this information, routers 10 may select
particular links and schedule network communications to minimize
cost.
[0037] FIG. 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 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.
In particular, routing information 34 describes routes between the
networked medical imaging devices within system 2. Although
illustrated within a medical imaging environment 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.
[0038] 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. In addition, router 10 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 10 to
present a multiple AE interface to a DICOM domain with which
medical imaging devices of system 2 can readily communicate.
[0039] Consequently, the AEName mapping supported by router 10
facilitates "collaborative" archiving in which requests are
automatically forwarded to a number 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:
[0040] Called AE Name--A name used to uniquely target (restrict)
access to specific destinations.
[0041] Request Type--Designates the type of request--i.e. "Store,
Query, or Move"
[0042] Type=Store (Transfer information to Archive(s))
[0043] List of routers to receive data on store requests from this
request name. This may be a list of 1-n Router Names.
[0044] Type=Query (Transfer Query to Archive(s))
[0045] List of 1 to N routers to receive request information for a
query request from this request name.
[0046] Type=Move (Transfer "Move Request" to Archive)
[0047] Router to request specific archive to retrieve data.
[0048] 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.
[0049] Port Number--Port number used for connection to this
router
[0050] Encryption--Enumerated field with the type of encryption to
be used on the connection. (i.e. Public/Private key
encryption.)
[0051] Compression--Enumerated field with the type of compression
to be used in this connection.
[0052] 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:
[0053] Called AE Name--Name used to uniquely target (restrict)
access to specific destinations.
[0054] New Called AE Name (Used by the Storage SCU agent as the
"Calling AE Name".)
[0055] Instance UID (To specifically identify an instance of an
application running on the target SCP system.)
[0056] HostName/IP address--Name/Address of the DICOM System to
receive the data. (A 0 in this field indicates that the data is
destined for an archive that is locally defined.
[0057] Port Number--Port number used to connect to the Locally
(LAN) attached DICOM Device.
[0058] Router 10 may also maintain a set of rules 38 to further
control routing of inbound network communications 32. Routing
module 36 may use rules 38 to 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.
[0059] Consequently, router 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 or more destinations. Rules 38 may also be used to map
or correct tagged data prior to routing. Router 10 may parse the
incoming data, and use rules 38 to map a tag to a new meaning or
format. A rule may be created, for example, to automatically
reformat patient identifiers as received from a medical imaging
modality. Furthermore, the rules may be used to selectively
propagate or filter messages or particular commands, such as DICOM
commands, along one or more specific routes.
[0060] 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
router 10 to immediately forward the asset to the 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.
[0061] 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.
[0062] 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 46 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.
[0063] 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.
[0064] Verification module 46 receives and processes 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. 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.
[0065] 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 10 does
not forward storage assets to destinations, such as central storage
system 12, until the encapsulated data has been fully
reconciled.
[0066] 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
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.
[0067] Upon validation of the encapsulated data by verification
module 46, routing module 36 examines non-pixel medical image data
from message queues 41, determines the appropriate route, and
enqueues a network communication within output queues 48 for
transmission to a destination by output interface 47. The 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 prior 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 local storage 49 to
form an outbound communication.
[0068] 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. If 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.
[0069] 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. In 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 within a storage asset, such as
the demographical information for a patient.
[0070] 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. In general, the patient management
functionality allows an operator to update patient information,
delete a 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.
[0071] FIG. 4 is a flowchart providing a high-level overview 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).
[0072] 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 38 (58). Router 10 forwards the network
communications in accordance with the destination information and
the results of the comparisons (59).
[0073] FIG. 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.
[0074] 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 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 "CFIND" commands to the storage
systems to determine which storage systems are currently storing
the requested asset, or copies thereof.
[0075] 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 requesting medical imaging device (67).
[0076] FIG. 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.
[0077] 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 identify
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 (74).
[0078] 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 interacting with the interface, the user can
view patient information and schedule pre-fetching the
corresponding assets.
[0079] At the scheduled time (78), router 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 10 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,
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.
[0080] 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 CFIND requests 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.
[0081] FIG. 7 is a flowchart illustrating the integration of
multiple departments 6 via router 10 in further detail. As
described above, each department 6 may include a number of
different 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 identifier, 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 10
detects the identifiers, and translates inbound and outbound
network communications to the department in accordance with the
identifiers.
[0082] 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 (81), 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).
[0083] Upon receiving an inbound or output network communication
(84), router 10 parses the network communication and translates the
encapsulated domain identifiers in accordance with the translation
table (85). Upon translating the identifiers, router 10 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.
[0084] FIG. 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 10 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-building"
and retention of thumbnail data so that the data can be quickly
retrieved and displayed.
[0085] Patch data 87E includes all 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 all 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.
[0086] 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.
[0087] 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 parts of the format. The contents may be as
follows:
[0088] Version [25]--Documents the version of this File."Format
V1.00"
[0089] CopyRight [120]--Legal Statement identifying the ownership
of this format.
[0090] StartOfHeader--Offset from beginning of file to start of
Header (Normally 0)
[0091] EndOfHeader--Offset from beginning of file to End of
Header
[0092] StartOfCommand--Offset from beginning of file to Start of
DICOM Command Data
[0093] EndOfCommand--Offset from beginning of file to End of DICOM
Command Data
[0094] StartOfData--Offset from beginning of file to Start of DICOM
Data
[0095] EndOfData--Offset from beginning of file to End of DICOM
Data
[0096] StartOfPixel--Offset from beginning of file to Start of
Pixel Data
[0097] EndOfPixel--Offset from beginning of file to End of Pixel
Data
[0098] StartOfThumbnail--Offset from beginning of file to Start of
Thumbnail Data
[0099] EndOfThumbnail--Offset v End of Thumbnail Data
[0100] StartOfPatches--Offset from beginning of file to Start of
Patch Data
[0101] EndOfPatches--Offset from beginning of file to End of Patch
Data
[0102] DestinationAPTitle [DILIB_VR_LENGTH_AE+1]--Called AE Name in
DICOM Association (Target for Storage of this Image)
[0103] ImageGUID [DILIB_GUIDLENGTH]--Image GUID within ADA
Database
[0104] SeriesGUID [DILIB_GUIDLENGTH]Series Folder GUID within ADA
Database
[0105] StudyGUID [DILIB_GUIDLENGTH]--Study Folder GUID within ADA
Database
[0106] PatientGUID [DILIB_GUIDLENGTH]--Patient Folder GUID within
ADA Database
[0107] ADASeriesToStudyGUID [DILIB_GUIDLENGTH]--Series to Study
GUID within ADA Database
[0108] ADAStudyToPatientGUID [DILIB_GUIDLENGTH]--Study to patient
GUID (Link) within ADA Database
[0109] Checksum--Checksum computed when data arrives at an
archive
[0110] Port--Port number used when data was transmitted
[0111] TransferSyntax--Transfer Syntax used to transfer this
data
[0112] ApplicationContextName [DILIB_VR_LENGTH_PN+1]--Application
Name (If Present) of device that stored this data to an
archive.
[0113] CallingAPTitle [DILIB_VR_LENGTH_AE+1]--Calling AE Name used
by calling device to create association
[0114] CalledAPTitle [DILIB_VR_LENGTH_AE+1]--Called AE Name used by
calling device to create association
[0115] RespondingAPTitle [DILIB_VR_LENGTH_AE+1]--Responding AE Name
when Association was internally generated.
[0116] MaxPDU--Max PDU Size as negotiated on the Association.
[0117] Result--DUL Result captured when Image Arrived
[0118] ResultSource--DUL ResultSource captured when Image
Arrived
[0119] Diagnostic--DUL Diagnostic Value captured when Image
Arrived
[0120] CallingPresentationAddress [DILIB_VR_LENGTH_UI+1]--Calling
HostName/IP address for association
[0121] CalledPresentationAddress [DILIB_VR_LENGTH_UI+1] Called
HostName/IP address for association
[0122] MaximumOperationsInvoked--Maximum Operations Invoked from
association information
[0123] MaximumOperationsPerformed--Maximum Operations Performed
from association information
[0124] CallingImplementationClassUID
[DICOM_UI_LENGTH+1]--Implementation Class UID of Calling
Software--captured during Association Negotiation
[0125] CallingImplementationVersionName
[DILIB_MAXIMPNAMELENGTH+1]Implemen- tation Name of Calling
Software--captured during Association Negotiation
[0126] CalledImplementationClassUID
[DICOM_UI_LENGTH+1]--Implementation Class UID of Called
Software--captured during Association Negotiation
[0127] CalledImplementationVersionName
[DILIB_VR_LENGTH_SH+1]--Implementat- ion Name of Called
Software--captured during Association Negotiation
[0128] PeerMaxPDU--Max PDU for transmission to Peer
Device--captured during Association Negotiation
[0129] EsopLength--Extended SOP Length--captured during Association
Negotiation
[0130] Medical imaging information 87B contains tags defined within
the DICOM as "Group 0" tags. These tags are part of Command
Request/Response information that must be present with each DICOM
Message. Medical imaging information 87B may 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:
[0131] <tag (group/element)><Length><Data>
[0132] <tag (group/element)><Length><Data>
[0133] <tag (group/element)><Length><Data>
[0134] .
[0135] .
[0136] .
[0137] <tag (group/element)><Length><Data>
[0138] 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 router 10 from an imaging modality.
[0139] Patch data 87E may be arranged as follows:
[0140] <tag
(group/element)><Length><Data><Change
Timestamp><Operator>
[0141] <tag
(group/element)><Length><Data><Change
Timestamp><Operator>
[0142] <tag
(group/element)><Length><Data><Change
Timestamp><Operator>
[0143] .
[0144] .
[0145] .
[0146] <tag (group/element)> <Length>
<Data><Change Timestamp><Operator>
[0147] FIG. 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 FIG. 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 routing 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 router 10.
[0148] Initially, router 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, router 10 generates a rule in XML format (91) and updates
rule set 24 (92).
[0149] 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 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).
[0150] 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 97, and hierarchically define
specific data tags, 95, logical operators 98 and corresponding data
values 99 for the rule as a complex grammar.
[0151] 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 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. For each event, the use may select and highlight
the event and elect to view the properties of the event.
[0152] 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 104, 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 116 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 DICOM database storing
medical imaging information, as well as an HIS/RIS database. Upon
selecting one of the resources, patient manager 48 polls the
selected resource and displays any identified relevant data in
order to assist the operator in reconciling the missing data in the
storage asset.
[0153] FIG. --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.
[0154] 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 patient manager
48 to automatically update the missing or invalid data of the
current medical imaging session. FIGS. 15, 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.
[0155] FIG. 18 illustrates an example user interface 132 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.
[0156] 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 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.
[0157] Router 10 includes tracing functionality to aid in
configuring, debugging and testing a medical imaging system 2. In
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 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.
[0158] Various embodiments of the invention have been described.
These and other embodiments are within the scope of the following
claims.
* * * * *