CA2440730A1 - Reconciling assets within a computer network - Google Patents
Reconciling assets within a computer network Download PDFInfo
- Publication number
- CA2440730A1 CA2440730A1 CA002440730A CA2440730A CA2440730A1 CA 2440730 A1 CA2440730 A1 CA 2440730A1 CA 002440730 A CA002440730 A CA 002440730A CA 2440730 A CA2440730 A CA 2440730A CA 2440730 A1 CA2440730 A1 CA 2440730A1
- Authority
- CA
- Canada
- Prior art keywords
- data
- router
- network communication
- network
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000004891 communication Methods 0.000 claims abstract description 89
- 238000010200 validation analysis Methods 0.000 claims abstract description 4
- 238000002059 diagnostic imaging Methods 0.000 claims description 76
- 238000000034 method Methods 0.000 claims description 24
- 238000012795 verification Methods 0.000 claims description 21
- 230000004044 response Effects 0.000 claims description 5
- 239000000872 buffer Substances 0.000 claims description 4
- 238000003860 storage Methods 0.000 abstract description 74
- 238000013507 mapping Methods 0.000 abstract description 3
- 238000003384 imaging method Methods 0.000 description 10
- 230000008859 change Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 238000012546 transfer Methods 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 5
- 238000007726 management method Methods 0.000 description 5
- 239000000284 extract Substances 0.000 description 4
- 230000010354 integration Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000002123 temporal effect Effects 0.000 description 3
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000002591 computed tomography Methods 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 229940079593 drug Drugs 0.000 description 2
- 239000003814 drug Substances 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000014759 maintenance of location Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- ZUDXFBWDXVNRKF-UHFFFAOYSA-N 5,11-dihydroindolo[3,2-b]carbazole-12-carboxaldehyde Chemical compound N1C2=CC=CC=C2C2=C1C=C1C3=CC=CC=C3NC1=C2C=O ZUDXFBWDXVNRKF-UHFFFAOYSA-N 0.000 description 1
- 241000555293 Bassariscus astutus Species 0.000 description 1
- 230000002730 additional effect Effects 0.000 description 1
- 238000010923 batch production Methods 0.000 description 1
- 230000033228 biological regulation Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- JFUIHGAGFMFNRD-UHFFFAOYSA-N fica Chemical compound FC1=CC=C2NC(C(=O)NCCS)=CC2=C1 JFUIHGAGFMFNRD-UHFFFAOYSA-N 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000010422 painting Methods 0.000 description 1
- 238000003908 quality control method Methods 0.000 description 1
- 238000002601 radiography Methods 0.000 description 1
- 238000012958 reprocessing Methods 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000002604 ultrasonography Methods 0.000 description 1
Landscapes
- Medical Treatment And Welfare Office Work (AREA)
- Measuring And Recording Apparatus For Diagnosis (AREA)
Abstract
A router includes a computer-readable medium storing routing information mapping destinations to routes within a network. A storage manager software module executing within an operating environment provided by the router receives a network communication including an asset having a pixel data and non-pixel data, and stores the asset to a storage device. A validation software module validates the non-pixel data in parallel with the storage of the asset. A routing module forwards the storage asset to a network destination in accordance with the routing information upon the validation of the non-pixel data.
Description
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 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
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 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 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.
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 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.
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
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 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 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 " ~ ~<
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 ' , ~ 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.:.
.>
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 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 ' 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 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 ' 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 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.:.
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 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-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~~
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
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.
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 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.
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
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 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 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 " ~ ~<
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 ' , ~ 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.:.
.>
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 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 ' 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 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 ' 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 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.:.
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 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-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~~
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
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 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).
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 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 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 t..:
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
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 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).
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 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 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 t..:
Claims (29)
1. A router comprising:
a computer-readable medium storing routing information for destination within a network;
a verification module to validate data of a network communication;
a reconciliation manager that displays a user interface for reconciling any invalid data; and a routing module to forward the network communication to a destination according to the routing information.
a computer-readable medium storing routing information for destination within a network;
a verification module to validate data of a network communication;
a reconciliation manager that displays a user interface for reconciling any invalid data; and a routing module to forward the network communication to a destination according to the routing information.
2. The router of claim 1, wherein the data comprises medical data, and the reconciliation manager comprises a patient manager.
3. The router of claim 2, wherein the medical imaging data comprises patient information, session information and study information
4. The router of claim 1, wherein the verification module semantically and syntactically validates the data, and issues a reconciliation event to the reconciliation manager based on the validation.
5. The router of claim 1, wherein the routing module forwards the network communication upon reconciliation by the reconciliation manager.
6. The router of claim 1, wherein the verification module issues a reconciliation event to the reconciliation manager based on the validation.
7, The router of claim 6, wherein the user interface displays an event list listing reconciliation events received from the verification module.
8. The muter of claim 6, wherein for each reconciliation event, the user interface displays an identifier for the corresponding invalid data, a source medical imaging modality producing the network communication, and a date and time of the event.
9. The router of claim 8, wherein for each reconciliation event, the user interface further displays, an event identifier, a patient identifier, a study identifier, a series identifier, and an image identifier.
10. The router of claim 8, wherein the user interface provides an input area by which an operator can edit the data of the network communication prior to forwarding the network communication.
11. The router of claim 1, wherein the reconciliation manager queries the destinations of the network based on the routing information to reconcile the invalid data.
12. The router of claim 1, further including a Hospital Information System /
Radiology Information System (HIS/RIS) interface, and further wherein the reconciliation manager queries the HIS/RIS to reconcile the invalid data.
Radiology Information System (HIS/RIS) interface, and further wherein the reconciliation manager queries the HIS/RIS to reconcile the invalid data.
13. The router of claim 1, wherein the reconciliation manager displays information received from the HIS/RIS for selection by a user.
14. The router of claim 1, wherein the verification module maintains a database of tags defined by the data of the network communication.
15. The router of claim 14, wherein for each tag, the verification module stores a source medical imaging modality producing the network communication, and a unique identifier for the tag.
16. A method comprising:
storing routing information describing routes within a network;
receiving a network communication comprising data and destination information;
identifying invalid data of the network communication;
displaying a user interface for reconciling the invalid data;
upon reconciling the data, forwarding the network communication according to the routing information.
storing routing information describing routes within a network;
receiving a network communication comprising data and destination information;
identifying invalid data of the network communication;
displaying a user interface for reconciling the invalid data;
upon reconciling the data, forwarding the network communication according to the routing information.
17. The method of claim 16, wherein receiving a network communication comprises receiving a network communication according to the DICOM protocol.
18. The method of claim 16, wherein identifying invalid data comprises semantically and syntactically validating the data.
19. The method of claim 16, further including issuing a reconciliation event based on the identification.
20. The method of claim 19, wherein displaying a user interface includes displaying a list of reconciliation event.
21. The method of claim 16, wherein displaying a user interface includes displaying an identifier for the corresponding invalid data, a source medical imaging modality producing the network communication, and a date and time of network communication.
22. The method of claim 21, wherein displaying a user interface includes displaying a patient identifier, a study identifier, a series identifier, and an image identifier.
23. The method of claim 16, further including:
receiving input from a user via the user interface; and updating the data of the network communication prior to forwarding the network communication.
receiving input from a user via the user interface; and updating the data of the network communication prior to forwarding the network communication.
24. The method of claim 16, further including:
querying destinations of the network based on the routing information; and updating the data of the network communication based on responses to the queries.
querying destinations of the network based on the routing information; and updating the data of the network communication based on responses to the queries.
25. The method of claim 24, wherein querying destinations of the network comprises querying a Hospital Information System / Radiology Information System (HIS/RIS).
26. The method of claim 16, wherein receiving a network communication includes receiving a network communication according to the DICOM protocol, the method further including maintaining a database of DICOM tags defined by the data of the network communication.
27. The method of claim 26, further including storing in the database a source medical imaging modality producing the network communication.
28. A system comprising:
router that receives network communications according to the DICOM protocol, and routes the network communication, wherein the muter includes a tracing module to buffer the network communications to a computer-readable medium; and a debug software module executes on a computing environment to receive the buffered network communications from the router, wherein the debug software module displays data encapsulated by the network communications and corresponding DICOM
commands.
router that receives network communications according to the DICOM protocol, and routes the network communication, wherein the muter includes a tracing module to buffer the network communications to a computer-readable medium; and a debug software module executes on a computing environment to receive the buffered network communications from the router, wherein the debug software module displays data encapsulated by the network communications and corresponding DICOM
commands.
29. The system of claim 28, wherein the network communications include assets having routing information, original medical imaging data, and patch data, and further wherein the debug software displays the assets in hexadecimal format as wells as corresponding DICOM commands decoded into an English-readable format.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US22058600P | 2000-07-25 | 2000-07-25 | |
| US60/220,586 | 2000-07-25 | ||
| CA002416783A CA2416783A1 (en) | 2000-07-25 | 2001-07-24 | Routing medical images within a computer network |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002416783A Division CA2416783A1 (en) | 2000-07-25 | 2001-07-24 | Routing medical images within a computer network |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2440730A1 true CA2440730A1 (en) | 2002-01-31 |
Family
ID=29271313
Family Applications (3)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002440688A Abandoned CA2440688A1 (en) | 2000-07-25 | 2001-07-24 | Routing and storage within a computer network |
| CA002440730A Abandoned CA2440730A1 (en) | 2000-07-25 | 2001-07-24 | Reconciling assets within a computer network |
| CA002440702A Abandoned CA2440702A1 (en) | 2000-07-25 | 2001-07-24 | Asset communication format within a computer network |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002440688A Abandoned CA2440688A1 (en) | 2000-07-25 | 2001-07-24 | Routing and storage within a computer network |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002440702A Abandoned CA2440702A1 (en) | 2000-07-25 | 2001-07-24 | Asset communication format within a computer network |
Country Status (1)
| Country | Link |
|---|---|
| CA (3) | CA2440688A1 (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111367665B (en) * | 2020-02-28 | 2020-12-18 | 清华大学 | Parallel communication route establishing method and system |
-
2001
- 2001-07-24 CA CA002440688A patent/CA2440688A1/en not_active Abandoned
- 2001-07-24 CA CA002440730A patent/CA2440730A1/en not_active Abandoned
- 2001-07-24 CA CA002440702A patent/CA2440702A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| CA2440702A1 (en) | 2002-01-31 |
| CA2440688A1 (en) | 2002-01-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1303951B1 (en) | Routing and storage within a computer network | |
| US8850057B2 (en) | Healthcare semantic interoperability platform | |
| US8015256B2 (en) | Method and apparatus for parallel sequencing of messages between disparate information systems | |
| US20060282447A1 (en) | Ndma db schema, dicom to relational schema translation, and xml to sql query transformation | |
| RU2409858C2 (en) | Connections control system based on messaging | |
| US9471751B1 (en) | Telemedicine system for preliminary remote diagnosis of a patient | |
| EP3891690B1 (en) | Intelligent meta pacs system and server | |
| US20090157837A1 (en) | Ndma socket transport protocol | |
| AU9432401A (en) | Method and system of managing the information for a hospital | |
| US20100205011A1 (en) | Enterprise imaging worklist server and method of use | |
| EP1351455B1 (en) | Routing and storage within a computer network | |
| CA2440730A1 (en) | Reconciling assets within a computer network | |
| CN115834650A (en) | DICOM object storage remote query retrieval system and use method | |
| CN111145874A (en) | Medical image underlying basic data management system and management method thereof | |
| JP5148357B2 (en) | Image data communication apparatus and image data communication system | |
| US20040078226A1 (en) | Medical data processing system | |
| CN113778560B (en) | Method, system, equipment and medium for custom development and execution of hospital treatment process | |
| Yiu et al. | Network management for picture archiving and communication systems | |
| TW202336775A (en) | Method and apparatus for clinical data integration | |
| TW200422908A (en) | DICOM processing server | |
| Noor et al. | Redesign CORBA Framework for distributed Medical Informatics model development | |
| WO2010048343A2 (en) | System and method for accepting and processing a facsimile image |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Dead |