Intelligent Meta PACS System and Server
20210265041 · 2021-08-26
Inventors
Cpc classification
G06F16/58
PHYSICS
G16H40/20
PHYSICS
G06F21/6218
PHYSICS
G16H50/20
PHYSICS
G16H15/00
PHYSICS
G16H10/60
PHYSICS
International classification
G06F21/62
PHYSICS
G16H15/00
PHYSICS
G16H40/20
PHYSICS
Abstract
A system to transparently and efficiently coordinate a process across at least two independent Picture Archiving and Communication System (PACS) to allow interoperability of the PACS to acquire, retrieve, transmit, store and/or display medical images of patients. The system includes: (1) a rule engine defining a set of transformation rules for data related to the images; (2) a data unification and transformation engine identifying and resolving any conflict of the data, and tracking and assigning a unique super-identity or super-value to the data; (3) at least one database storing a list of the data and the tracking and assignment of the super-identities or super-values; (4) a security framework that controls access to the data; and (5) a control engine performing the process steps.
Claims
1. A system for coordinating a process across at least two independent Picture Archiving and Communication System (PACS) to allow interoperability of the PACS, with each PACS handling the acquisition, retrieval, transmission, storage, and display of patients medical images using the Digital Imaging and Communications in Medicine (DICOM) standard, wherein each PACS includes at least one modality that acquires DICOM images, at least one workstation that retrieves and displays DICOM images, and at least one server that transmits, manages, and stores images and controls the at least one modality and the at least one workstation, wherein each image has an associated DICOM tag and an associated patient tag unique to each PACS, wherein the process from one PACS to another PACS includes at least one process step defined by at least one modality, workstation, server, DICOM tag, or patient tag, comprising: a. a rules engine defining a set of transformation rules for each image, modality, workstation, server, DICOM tag, patient tags, and process step from each PACS; b. a data unification and transformation engine identifying and resolving any conflict on the identities or values of the modalities, workstations, servers, DICOM tags, patient tags, and process step from all PACS using said rules engine by tracking and assigning a unique super-identity or super-value as applicable to each modality, workstation, server, DICOM tag, patient tag, and process step for all PACS; c. at least one database storing a list of the DICOM tags of each image from each PACS, and storing the tracking and assignment of the super-identities or super-values by said data unification and transformation engine; d. a security framework that controls access to each image from each PACS based on the assignment of the super-identities or super-values by said data unification and transformation engine and stored in said at least one database; and e. a control engine performing the process steps to acquire, retrieve, transmit, store and/or display the images from any of said at least two PACS based on the DICOM tag and the assignment of the super-identities or super-values stored in said at least one database.
2. The system of claim 1, further comprising a DICOM tag replication engine that replicates each DICOM tag of each image from each PACS, and a DICOM tag database for storing a copy of each DICOM tag of each image from each PACS.
3. The system of claim 1 wherein each PACS further includes at least one user who can access certain DICOM images, said data unification and transformation engine further identifying and resolving any conflict on the identities of the users from all PACS using said rules engine by tracking and assigning a unique super-identity to each user for all PACS, and storing the assignment of the super-identities by said data unification and transformation engine in a user/role/group database.
4. The system of claim 3 wherein said security framework controls access by each of said at least one user to each image from each PACS based on the assignment of the super-identities stored in said user/role/group database.
5. The system of claim 1 further comprising a tag map/override database for storing the tracking and assignment of the super-values of each DICOM tag by said data unification and transformation engine using said rules engine.
6. The system of claim 1 further comprising a modality map database for storing the tracking and assignment of the super-identities of each modality by said data unification and transformation engine using said rules engine.
7. The system of claim 1 further comprising a workstation map database for storing the tracking and assignment of the super-identities of each workstation by said data unification and transformation engine using said rules engine.
8. The system of claim 1 further comprising a patient tag database for storing the tracking and assignment of the super-identities of each patient tag by said data unification and transformation engine using said rules engine.
9. The system of claim 2, wherein each PACS further includes a modality that acquires or generates non-DICOM images, further comprising an extensible process engine that assigns a DICOM tag to each of said non-DICOM image, and said assigned DICOM tags are stored in said DICOM tag database.
10. The system of claim 1 further comprising an interface that handles the acquisition, retrieval, transmission, storage, and display of DICOM images from each of said at least two PACS.
11. The system of claim 1 further comprising an extensible process engine that analyzes and optimizes said process steps performed by said control engine.
12. A system for coordinating a process for a Picture Archiving and Communication System (PACS) that handles the acquisition, retrieval, transmission, storage, and display of patients medical images using the Digital Imaging and Communications in Medicine (DICOM) standard, wherein said PACS includes at least one modality that acquires DICOM images, at least one workstation that retrieves and displays DICOM images, and at least one server that transmits, manages, and stores DICOM images and controls the at least one modality and the at least one workstation, wherein each image has an associated DICOM tag and an associated patient tag unique to each PACS, wherein the process includes at least one process step defined by at least one modality, workstation, server, DICOM tag, or patient tag, comprising: a. a rules engine defining a set of transformation rules for each image, modality, workstation, server, DICOM tag, patient tags, and process step from said PACS; b. a data unification and transformation engine identifying and resolving any conflict on the identities or values of the modalities, workstations, servers, DICOM tags, patient tags, and process step from said PACS using said rules engine by tracking and assigning a unique super-identity or super-value to each modality, workstation, server, DICOM tag, patient tag, and process step for said PACS; c. at least one database storing a list of the DICOM tags of each image from said PACS, and storing the tracking and assignment of the super-identities or super-values by said data unification and transformation engine; d. a security framework that controls access to each image from said PACS based on the assignment of the super-identities or super-values by said data unification and transformation engine and stored in said at least one database; and e. a control engine performing the process steps to acquire, retrieve, transmit, stores and/or displays the images from said PACS based on the DICOM tag and the assignment of the super-identities or super-values stored in said at least one database.
13. A method for coordinating a process across at least two independent Picture Archiving and Communication System (PACS) to allow interoperability of the PACS, each PACS handles the acquisition, retrieval, transmission, storage, and display of patients medical images using the Digital Imaging and Communications in Medicine (DICOM) standard, wherein each PACS includes at least one modality that acquires DICOM images, at least one workstation that retrieves and displays DICOM images, and at least one server that transmits, manages, and stores DICOM images and controls the at least one modality and the at least one workstation, wherein each image has an associated DICOM tag and an associated patient tag unique to each PACS, wherein the process from one PACS to another PACS includes at least one process step defined by at least one modality, workstation, server, DICOM tag, or patient tag, comprising the steps of: a. providing a rules engine that defines a set of transformation rules for each image, modality, workstation, server, DICOM tag, patient tags, and process step from each PACS; b. providing a data unification and transformation engine that identifies and resolves any conflict on the identities or values of the modalities, workstations, servers, DICOM tags, patient tags, and process step from all PACS using said rules engine and tracking and assigning a unique super-identity or super-value to each modality, workstation, server, DICOM tag, patient tag, and process step for all PACS; c. providing at least one database; d. storing a list of the DICOM tag of each image from each PACS in said at least one database; e. storing the tracking and assignment of the super-identities or super-values by said data unification and transformation engine in said at least one database; f. providing a security framework that controls access to each image from each PACS based on the assignment of the super-identities or super-values by said data unification and transformation engine stored in said at least one database; and g. providing a control engine that performs the process steps to acquire, retrieve, transmit, store and/or display the images from any of said at least two PACS based on the DICOM tag and the assignment of the super-identities or super-values stored in said at least one database.
14. The method of claim 13 further comprising the step of providing an interface that handles the acquisition, retrieval, transmission, storage, and display of DICOM images from each of said at least two PACS.
15. The method of claim 13 wherein said data unification and transformation engine does not alter the DICOM images stored in said at least one PACS.
16. The method of claim 13 wherein said data unification and transformation engine does not alter the DICOM tags stored in said at least one PACS.
Description
5 BRIEF DESCRIPTION OF THE DRAWINGS
[0058] Preferred embodiments of the present invention have been chosen for purposes of illustration and description and are shown in the accompanying drawings forming a part of the specification wherein:
[0059]
[0060]
[0061]
[0062]
[0063]
[0064]
[0065]
[0066]
[0067]
[0068]
[0069]
[0070]
[0071]
[0072]
[0073]
[0074]
[0075]
[0076]
[0077]
[0078]
[0079]
[0080]
[0081]
[0082]
[0083]
[0084]
[0085]
[0086]
[0087]
[0088]
[0089]
6 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0090] The Intelligent Meta PACS (IMPACS) system 200 of the present invention is essentially a process brain that is designed to work with the medical imaging process flow while interfacing with connected DICOM entities as a regular prior art PACS server 110 would. The existence of the process brain/control engine in the IMPACS 200 allows it to address the limitations of DICOM where it comes to interoperability as discussed above and other deficiencies in the prior art PACS systems.
[0091] The IMPACS system 200 is designed to manage the flow of images from a group of connected, disparate “Slave” PACS servers 110.sub.n to DICOM entities (such as users U.sub.n, workstations WS.sub.n, other external PACS servers 110.sub.n or modalities M.sub.n) that connect to the IMPACS system 200 as clients. The IMPACS system 200 serves as the Master Controller for its group of connected Slave PACS servers 110.sub.n and controls all access and image delivery for them when these functions are requested by clients connected to the IMPACS system 200.
[0092] The IMPACS system 200 is a combination of two main elements: [0093] A powerful and extensible central process “brain”/control engine 201 that is designed to work with medical images and can be adapted to handle any reasonable imaging workflow across providers, patients, insurers and other participants. This control engine is relatively lightweight and provides the controlling logic for dealing with images, maintaining all the needed data and mappings needed for the same. [0094] A standard PACS server interface 210 through which the control engine 201 interacts with connected DICOM entities such as modalities M.sub.n, users U.sub.n, workstations WS.sub.n and other PACS servers 110.sub.n that are not its slaves. Despite its PACS server interface 210, the IMPACS system 200 is unlike any prior art PACS server 110 in that its primary focus is not on storing images but rather to make it possible for one to access images on other PACS servers 110.sub.n connected to the IMPACS system 200 as Slaves as though they were resident on the IMPACS system 200 itself. It is in this respect that the IMPACS system 200 is a “meta” PACS.
[0095] Each connected client, connects to the IMPACS system 200 through its PACS server interface 210 that behaves in all respects like a standard PACS server 110. However, the existence of the process brain/control engine 201 allows the IMPACS system 200 to deliver a level of functionality that is simply not possible through any prior art PACS server 110. In particular, the IMPACS system 200 permits the sharing of image data resident across multiple PACS servers 110.sub.n while seamlessly handling the problems inherent in such interoperability such as inconsistent patient identifiers, non-standard security etc. as discussed at length above. Importantly, the IMPACS system 200 hides all these issues of DICOM interoperability from its various participants making it possible for them to use the images from a variety of sources without having to deal with the logistical issues that they might otherwise have to face with prior-art PACS systems 100 and servers 110.
[0096]
[0097] The IMPACS system 200 provides numerous functions and features that can be divided into functional groupings or layers (as illustrated in
[0102] From the perspective of a user U.sub.n, workstation WS.sub.n, or a modality M.sub.n, working with the IMPACS system 200 is identical to working with any standard PACS server 110 that supports the DICOM standard. The fact that there are many slave PACS servers 110.sub.n underlying the IMPACS system 200 is hidden from both the modalities M.sub.n and the users U.sub.n. The modalities M.sub.n and users U.sub.n interact with what they perceive to be a “standard” PACS server 110. Again, the slave PACS servers 110.sub.n of the IMPACS system 200, interact with their respective users U.sub.n and modalities M.sub.n almost exactly as they would were these entitites connected directly to them, even though such interaction is actually being conducted by the IMPACS system 200 on behalf of the users U.sub.n and modalities M.sub.n.
[0103] Fundamentally thus, the IMPACS system 200 is the antithesis of a peer-to-peer image-sharing system of the prior art because the authorizations, transport mechanisms and even the data transfers for all the interactions between the various participants be they consumers or providers of data are handled, tracked and maintained by the IMPACS system 200 in a fashion selected for efficiency based on the circumstances.
[0104] In the discussion below, when we refer to the IMPACS server, we typically mean the IMPACS system 200. Again, when we talk of DICOM entities (other than Slave PACS servers 110.sub.n) connected to the IMPACS system (or server) 200, it should be understood that we mean entities connected to the same through its PACS server interface 210. Finally, when we discuss programming the IMPACS system 200, it should be read as programming its brain/control engine 201. We will not distinguish between the IMPACS 200 (or IMPACS system 200), its brain/control engine 201 and its PACS server interface 210 unless warranted specifically by the context.
[0105] The various functional layers of the IMPACS system 200 are explained in detail in the sections below.
6.1 Emulation Layer 300
[0106] The IMPACS system 200 can emulate all the relevant functions of any of its underlying slave PACS servers 110.sub.n for any modality M.sub.n, user U.sub.n, or client/workstation WS.sub.n that was originally connected to that slave PACS server 110.sub.n. In this mode, the IMPACS system 200 is in-visible from the perspective of any modality M.sub.n, user U.sub.n, or client/workstation WS.sub.n connected to it because each such entity believes it is connected to a “standard” PACS server 110 which is what the IMPACS' PACS server interface 210 is. An overview of the IMPACS system 200's emulation layer 300 is shown in
[0107] As shown in
[0108] When the modalities M.sub.n are connected directly to the IMPACS system 200 instead of their slave PACS server 110.sub.a, the IMPACS system 200 will allow them to store the images they obtain directly into their corresponding slave PACS server 110.sub.a as well as recover or modify these images as needed using the same protocols they would in interacting with their local PACS server 110.sub.a. Importantly, the units connecting to the IMPACS system 200 would use the same patient, study, image and other DICOM identifiers that they would have normally used in their workflow assuming the IMPACS system 200 did not exist at all. The only change that would be made by modalities M.sub.n would be to replace the connection to their local PACS server 110.sub.n with one to the IMPACS system 200 through its PACS server interface 210 instead.
[0109] Again, for workstations WS.sub.n that need to access the images and work with them, having the IMPACS system 200 replace the local PACS 110.sub.n would be an equally seamless process. Workstations WS.sub.n would be able to access the DICOM images using all the same protocols that they were using prior to the existence of the IMPACS system 200, using the same identifiers for patients as before.
[0110] One limitation in emulation mode 300 in the IMPACS system 200 is where it comes to user roles. The IMPACS system 200 can have a number of underlying slave PACS servers 110.sub.n each of which may have its own set of authorized users and protocols for authentication of the same. These user roles and protocols will generally not be identical across slave PACS servers 110.sub.n.
[0111] When a user U.sub.n uses slave-PACS-provided credentials, the IMPACS system 200 will generally have no way to determine just from those credentials exactly which slave PACS system 100.sub.n (slave PACS server 110.sub.n) they apply to. The same username for example can be repeated in many of the underlying slave PACS servers 110.sub.n, and refer to entirely different users U.sub.n. The IMPACS system 200 however can provide some automatic support for slave-PACS-level credentials when certain conditions are met as will be discussed below.
[0112] The emulation layer 300 may appear to serve little purpose than to route a connected modality M.sub.n or workstation WS.sub.n to the appropriate slave PACS server 110.sub.n with the associated overhead. However, the IMPACS system 200 can also be configured to perform certain optimizations in emulation mode 300 thereby improving the efficiency of working with the old slave PACS server 110.sub.n. Specifically, the IMPACS system 200 can: [0113] perform some or all image searches using a cached copy of the slave PACS' 110.sub.n DICOM image tags leaving the slave PACS server 110.sub.n only with the task of serving up the final images to the IMPACS system 200. This would eliminate the need to upgrade the entire image storage system just to service more user search requests. [0114] cache and serve up frequently used images with no impact to the slave PACS servers 110.sub.n at all. [0115] allow modalities M.sub.n connected to it to operate at full speed even when their associated slave PACS server 110.sub.n is temporarily down or overloaded. This is because the IMPACS system 200 can also cache images stored for later upload to the slave PACS server 110.sub.n.
[0116] There are also other benefits to modalities M.sub.n operating using the emulation layer 300 that come from the fact that the IMPACS system 200 implementation becomes more efficient when full use is made of the intelligence of its process brain/control engine 201. These issues will be further discussed later.
6.2 Unification Layer 400
[0117] The IMPACS system 200 also has the ability to unify all the data in the slave PACS servers 110.sub.n in its framework so that all the data appear to be located within it and correctly organized by patient, study, series and other DICOM groupings just as in a monolithic PACS server 110. That is, the IMPACS system 200 can appear as a single PACS server 110 that appears to have all the data that is resident in the slave PACS servers 110.sub.n. In this mode, the slave PACS servers 110.sub.n are not visible from the perspective of any modality M.sub.n or client/workstation WS.sub.n connected to the IMPACS system 200.
6.3 Security Layer 500
[0124] The IMPACS system 200 can be configured to implement a powerful and extensible security framework 510 for the imaging workflow that can permit granular access at the level of a single DICOM image, study, series, patient or any subset thereof for any group of users, workstations WS.sub.n or other defined security roles. In performing its security layer functions 500 the IMPACS system 200 needs to recognize that: [0125] The slave PACS servers 110.sub.n may have their own security infrastructure that could require authentication. [0126] The unification layer 400 of the IMPACS system 200 will require the creation of new roles and users that have access to images across multiple slave PACS servers 110.sub.n. These super access roles have no analog in any of the connected slave PACS systems 100.sub.n or their associated servers 110.sub.n.
[0127] In its emulation layer 300, the IMPACS system 200 can be configured to guarantee that any workstation WS.sub.n or modality M.sub.n can search, view, or modify only those images that it is permissioned for in the specific slave PACS server 110.sub.n that it is associated with. In unification mode 400 the IMPACS system 200 can operate with its own user roles and identities and ensure that these identities can access only those images that they are permissioned for. In the unification layer 400 moreover, the IMPACS system 200 can allow for the possibility that specific users can be given authorizations to see more images across the slave PACS servers 110.sub.n, or alternatively, have these permissions revoked. Moreover, new slave PACS servers 110.sub.n can be brought into the IMPACS system 200 setup creating the need for extending user permissions across these new machines. Thus, the IMPACS system 200 permission scheme can be configured so that a specific identity's image/patient views are updated appropriately when permissions are granted or revoked.
[0128] The IMPACS system 200 is designed to make the permission scheme transparent to the users U.sub.n. Thus, a user U.sub.n accessing the IMPACS system 200 emulation layer 300 will see only what he is authorized to see in his slave PACS server 110.sub.n. When accessing the unification layer 400 with the appropriate identity, the user U.sub.n will see exactly those images he is permissioned for but now across all the connected slave PACS servers 110.sub.n. In either instance, any agent connected to the IMPACS system 200 will be able to see, list and search across only what he is authorized for and nothing else.
6.4 Extension Layer 600
[0129] The IMPACS system 200's brain/control engine 201 is set up to understand DICOM formats and workflows and can be configured to provide considerable functionality beyond just combining data from or emulating multiple slave PACS servers 110.sub.n. These additional functions that the IMPACS system 200 can provide makes up the extension layer 600. There are many such services the IMPACS system 200 can provide and its brain/control engine 201 can be extended to provide even more services as needs dictate. A non-exhaustive list of some of the functions that the IMPACS system 200 can provide with the extension layer 600 includes: [0130] Ensuring Image Redundancy. The IMPACS system 200 can be configured to seamlessly cache and send images from a connected modality M.sub.n to multiple slave PACS servers 110.sub.n for storage. This would mean thus, that it could implement a real-time hot-backup for a slave PACS server 110. [0131] Speeding up Image Access. If a primary slave PACS server 110.sub.a has a secondary backup PACS server 110.sub.b that is also set up as a slave PACS server 110.sub.b, the IMPACS system 200 can route image requests both to the primary and the backup servers 110.sub.a and 110.sub.b to speed up access. Thus, a hot-backup of a slave PACS server 110.sub.a can be put to good use at times of peak usage. Again, the IMPACS system 200 could cache heavily used images in its own local storage and serve up requests for these images without even accessing the corresponding slave PACS server 110.sub.n. [0132] DICOM-Enabling New Modalities. The DICOM standard is very flexible because it supports virtually any type of image as long as it has the right DICOM wrapper tags. However, not all image acquisition devices can provide the DICOM tag addenda and so most of those cannot work with a conventional PACS server 110. For example, a picture taken on a camera phone is not in DICOM format because the phone does not have the functions needed to convert these images into a DICOM format. However, such a phone can be configured as a “modality” M.sub.n in the IMPACS system 200 with the latter being programmed to provide all the DICOM tag wrappers for any image acquired from this phone when given some additional data as to the patient, and then dispatch the wrapped image for storage to the appropriate slave PACS server 110.sub.n. With this approach, any non-DICOM-aware device can be converted into a full-fledged and low-cost modality M.sub.n. This will be described in more detail below. [0133] PACS-Enabling Non-DICOM Image Stores. The IMPACS system 200 can DICOM-enable non DICOM modalities M.sub.n because of its ability to wrap an image delivered to it with the appropriate DICOM tags using a combination of information in the image already and its knowledge about the modality M.sub.n. If the images did not come from a modality M.sub.n but from a non-DICOM image storage server, the IMPACS system 200 could simply wrap all the images from such a server with DICOM tags and even convert the images, if they cannot be viewed by standard DICOM viewers, into formats that are easily viewable. If the IMPACS system 200 were configured to DICOM-wrap all the images from a non-DICOM image store and were to commit these DICOM tags into its internal databases, it could then permit searching for these images by any agent and serve up these images as well. Since the IMPACS system 200 can access and DICOM-wrap, and if needed convert images on the fly, it can easily serve them up as well on demand and deliver them not just to a slave PACS server 110 for storage when required but also to an accessing workstation WS. Thus the IMPACS system 200 can provide a PACS server 110 interface for a non-PACS image repository such as for example, a repository of non-DICOM pathology slides, converting it effectively into a “pseudo PACS” server 810. This will be further discussed below. [0134] Managing an Imaging Workflow When modalities M.sub.n, users U.sub.n or workstations WS.sub.n connect to the IMPACS system 200 the latter implements various rules that determine what exactly it needs to do to service their requests. At the minimum the IMPACS system 200 supports all DICOM requests. However, the IMPACS' brain/control engine 201 can be extended to handle more complex process functions. These could be sending messages to other PACS servers 110.sub.n when an image is stored, notifying users when images are changed etc. The IMPACS system 200 functionality can be extended to handle issues that might arise more generally in the handling of medical images. [0135] Filtering or Altering DICOM Tags For Specific Uses. This feature was briefly mentioned above in connection with the fixing, altering or adding DICOM tags. The IMPACS system 200 can anonymize the images from the various slave PACS servers 110.sub.n by overwriting the patient specific data on the images it serves up dynamically without altering the actual image data in any of its slave PACS servers 110.sub.n. As such, it can serve as a portal into any of the slave PACS servers 110.sub.n without the latter needing to do anything to their images to make this possible. This can be useful for research and other functions. For example, the IMPACS system 200, with some additional patient-specific data from the medical provider, can filter out only the images of cancer patients from its slave PACS servers 110.sub.n if it has to serve as the portal for a network of cancer specialists. Alternatively, it can be used to filter out only patients covered by a given insurer so that the latter can operate with single IMPACS system 200 for all of its patients etc. The important thing to note is much as the IMPACS system 200 unifies patients by creating its own patient identity, it can also filter by the same, as well as unify and filter using other DICOM tags. It can also write specific filter tags into its own tag database as custom DICOM tags, effectively storing the results of the filters. This will make future retrieval of the filtered results much faster.
[0136] The above functions/features are typically not provided by any typical PACS server 110. However, the IMPACS system 200 can seamlessly provide such functionality with the extension layer 600 while behaving in all respects like a regular PACS server 110 (through its PACS server interface 210) from the perspective of the user U.sub.n or modality M.sub.n.
6.5 Implementation of the IMPACS system 200
[0137] The IMPACS system 200 in its most general form can be viewed as a powerful and extensible process brain that can coordinate the entire DICOM process flow. As such, it is a DICOM-process-aware instance of the general Process Interoperability Platform (“PIPCO”) as described in pending application Ser. No. 16/037,249 for “System for Process Coordination and Interoperability across Different Systems, Platforms and/or Businesses” filed on Jul. 17, 2018.
[0138] The IMPACS system 200 of the present invention can do all of the following: [0139] emulate the behavior of one or more of the individual slave PACS servers 110.sub.n connected to it so connected users U.sub.n and modalities M.sub.n believe that they are actually connected directly to the slave PACS server 110.sub.n. [0140] unify images across all of the slave PACS servers 110.sub.n and permit searching across all of them as though all the images are actually resident in itself. To modalities M.sub.n connected to the IMPACS system 200 in this context, it will behave in all respects like a regular, standalone PACS server 110.
[0141] The implementation of the IMPACS system 200 of the present invention can be broken down into the broad functional areas or elements below, as shown in
[0147] Each of these implementation areas/elements are described in detail below.
6.5.1 Slave Control Engine 220
[0148] The IMPACS system 200 is intended to make a group of slave PACS servers 110.sub.n work as though their data were all in a single PACS server 110. As such, it needs to route requests on behalf of connected modalities M.sub.n, users U.sub.n, or workstations WS.sub.n to the appropriate underlying slave PACS servers 110.sub.n. It may also have to authenticate users U.sub.n and/or modalities M.sub.n with the slave PACS system 100.sub.n or servers 110.sub.n when used in emulation mode 300. To perform these so-called slave control functions, the Slave Control Engine 220, which is part of the IMPACS brain/control engine 201, of the IMPACS system 200 is configured to do all of the following:
6.5.1.1 Manage Connections and Routing to Slave PACS Servers 110.
[0149] The IMPACS system 200 is configured to connect seamlessly to the slave PACS servers 110.sub.n in its framework. It can accomplish this when it is aware of their existence and when it has the right protocols/credentials to connect to them for image recovery, storage, querying etc. as permitted. To this end, the IMPACS system 200 will: [0150] Establish a list of slave PACS servers 110.sub.n that are authorized to be part of the IMPACS framework 200. [0151] Maintain a list of relevant properties for each authorized slave PACS system 100.sub.n and its associated server 110.sub.n to permit connection. These properties would include the authentication and networking protocols to connect along with any authentication credentials that need to be used for the same. [0152] Implement the appropriate networking, authentication and connection protocols using the data from the above steps to permit access of the slave PACS servers 110.sub.n by any modalities M.sub.n or clients connected to the IMPACS system 200.
[0153] The first two items above can be handled using a standard relational database. The final step above can be easily implemented because virtually all of the required connection and other protocols are typically built into most modern computer operating systems—the only requirement is that these protocols be appropriately configured using the data collected in the first two steps. In some situations, it might be necessary to provide a customized framework for connectivity.
[0154] The above properties and implementations will be internal to the IMPACS system 200. Any client or modality M.sub.n connecting to the IMPACS system 200 will not be aware of the routing of requests to the slave PACS server 110.sub.n going on under the hood.
6.5.1.2 Incorporate Slave PACS Server 110. Security Protocols and Credentials for Connectivity
[0155] The slave PACS servers 110.sub.n underlying the IMPACS system 200 may operate with different security frameworks, roles and technologies, as illustrated in
[0156] Again, for connection, the slave PACS servers 110.sub.n might require the IMPACS system 200 to authenticate with the appropriate credentials. In emulation mode 300 (i.e., as implemented by emulation layer 300), such authentication will generally be with the IMPACS system 200 user's login credentials which just get passed on to the slave PACS server 110.sub.n. However, when providing the functions in its unification layer 400, the IMPACS system 200 will have to take care of the access permissions for users U.sub.n across servers 110.sub.n because each slave PACS server 110.sub.n's permissions relate only to the data that the latter has. In this situation, the IMPACS system 200 has to provide a more extensive user mapping to be discussed below.
[0157] In general, the IMPACS system 200 will likely have to authenticate to each slave PACS server 110.sub.n providing the appropriate credentials in a fashion consistent with the latter's security framework. To do this, the IMPACS system 200 stores these credentials in its internal databases for provision to the slave PACS servers 110.sub.n as needed. The IMPACS system 200 can be configured with the ability to establish connectivity and deliver these credentials to the slave PACS server 110.sub.n using the latter's own security protocols (be they LDAP, Azure, or anything else).
6.5.1.3 Establish an Optional Framework for Modalities M.SUB.n .Connecting to Emulation Layer 300
[0158] When a legacy modality M.sub.n connects to the IMPACS system 200 in emulation mode which means it connects to the latter's emulation layer 300, it expects the IMPACS PACS server interface 210 to behave like its original (now slave) PACS server 110.sub.n and the legacy modality M.sub.n continues to use DICOM tags appropriate to the slave PACS system 100.sub.n and server 110.sub.n (which may even be in conflict with the tags used by the IMPACS system 200 itself). Consider thus the case where an existing modality (say MRI machine M.sub.10 in Hospital A) is connected to a local PACS server 110.sub.a in that hospital (say cardiology PACS server 110.sub.a). Assume that the modality M.sub.10 connects directly to the IMPACS system 200 making its PACS server 110.sub.a into a slave of the IMPACS system 200. If the modality M.sub.10 continues to use the patient identifiers established within Hospital A, the IMPACS system 200 operates to route all the image storage requests emanating from this modality to slave PACS server 110.sub.a, the local PACS server that originally served this modality M.sub.10. Even if slave PACS server 110.sub.a is no longer available, the IMPACS system 200 will have to maintain its own subsidiary DICOM store corresponding to slave PACS server 110.sub.a which operates with the same patient identifiers used by the slave PACS server 110.sub.a. The IMPACS system 200 is configured with a number of features to provide the emulation layer 300 functionality. Specifically: [0159] The modality M.sub.10 in this case does not direct the IMPACS 200 to store the images it provides into PACS server 110.sub.a, nor does it specify that the images in question are even from Hospital A with the latter's patient identifiers. The IMPACS system 200 is configured to determine these relationships automatically. [0160] The modality M.sub.10 might communicate with its slave PACS server 110.sub.a using specific authentication mechanisms and protocols that might in some cases be defined and/or limited by its hardware. The IMPACS system 200 can be configured to be aware of these protocols and identify itself and behave exactly like the legacy modality M.sub.10 in connecting to the slave PACS server 110.sub.a so that the storage of the images is seamless. At the same time, the IMPACS system 200 would appear exactly like the slave PACS server 110.sub.a to the connected modality M.sub.10.
[0161] To pass through the modality's M.sub.10 request to the appropriate slave PACS system 100.sub.a (and its associated slave PACS server 110.sub.a), the IMPACS system 200: [0162] Creates a Modality Identity Map 310 that relates every legacy modality M.sub.n that connects to it to the appropriate slave PACS server 110.sub.n in its network. Thus for the example above, the map would relate modality M.sub.10 to slave PACS server 110.sub.a in Hospital A. The IMPACS system 200 as specified earlier, is also configured with the knowledge needed to connect to slave PACS server 110.sub.a. In some cases, rather than an explicit map that lists every modality M.sub.n connected to a slave PACS server 110.sub.n, a network address range can be used if such a specific range can be set up for modalities M.sub.n at the slave PACS server 110.sub.a level. [0163] Maintains or passes through the authentication, networking and other credentials each modality M.sub.n would have to use to store images into its slave PACS server 110.sub.n using the appropriate protocols. This will be needed by the IMPACS system 200 to authenticate the modalities M.sub.n or alternatively, permit the slave PACS server 110.sub.n to provide that function instead. [0164] Emulates the same authentication/connection schemes as the slave PACS server 110.sub.n when modalities M.sub.n connect to the IMPACS system 200. That is, the IMPACS system 200 will behave exactly like the slave PACS server 110.sub.n to the connecting modality M.sub.n. The latter thus will authenticate and connect to the IMPACS system 200 exactly as it did to its corresponding slave PACS server 110.sub.n. [0165] Behaves like the modality M.sub.n where it comes to connecting to the slave PACS server 110.sub.n on behalf of a modality M.sub.n. Thus, the IMPACS system 200 will maintain or pass through the authentication, networking and other credentials each modality M.sub.n would have to use to store images into its slave PACS server 110.sub.n.
[0166] As shown in
[0167] Many PACS servers 110.sub.n do not have any authentication for modalities M.sub.n which typically tend to be large machines hardwired to the PACS server 110.sub.n. However, many such modalities M.sub.n might be connected to the IMPACS system 200 for its emulation functions 300, and these modalities M.sub.n might belong to completely different providers with different (slave) PACS servers 110.sub.n. As such, the IMPACS system 200 in an embodiment is configured to ensure that the modality access is properly controlled with each modality M.sub.n being associated to the right slave PACS server 110.sub.n with no prospect of error using its Modality Identity Map 310. The IMPACS system 200 will manage this by tracking characteristics such as MAC addresses, network connections, network addresses etc. that can uniquely identify a modality M.sub.n, with no possibility of spoofing, so that the proper association to its slave PACS server 110.sub.n is always possible, recognizing that the latter might provide no security framework at all for this purpose. In some special cases, where the IMPACS is DICOM-enabling non-DICOM modalities such as personal smartphones, it may associate the “modality” with its appropriate slave PACS server 110 using user credentials for the purpose. This is discussed at greater length in later sections. The IMPACS system 200 can provide emulation functions 300 only for a modality M.sub.n that can be uniquely associated with its correct slave PACS server 110.sub.n.
6.5.1.4 Create and Maintain an Optional User Framework for Emulation Mode 300
[0168] In providing the functions in its emulation layer 300, the IMPACS system 200 can be configured to accept logins from users U.sub.n that are permissioned only on a specific slave PACS server 110.sub.n. In such an instance, the IMPACS system 200 will have to be able to authenticate such a user U.sub.n by passing through his authentication request to the appropriate slave PACS server 110.sub.n. However, given that usernames are often repeated across computers (like j smith for our proverbial John Smith), the IMPACS system 200 will generally not pass through authentication to a slave
[0169] PACS server 110.sub.n based on user name alone.
[0170] In the section above, a pass through for modalities M.sub.n is allowed because the latter are typically devices with fixed network and other characteristics that can be detected and located with reliability. However, the same is generally not true for users Un who are much more mobile. As shown in
[0171] In general, to maximize the benefit of the present invention, IMPACS system 200's emulation mode 300 for users U.sub.n should not be used and instead one should rely on the IMPACS's 200 own user security framework (to be discussed below) that can be used to create user identities and map them to equivalent identities at one or more slave PACS servers 110.sub.n.
[0172] The above-mentioned maps/credentials/protocols should be updated whenever a new slave PACS server 110.sub.n is connected to the IMPACS system 200. Similarly, when new modalities M.sub.n, users U.sub.n, or workstations WS.sub.n that require emulation functions 300 are connected to the IMPACS system 200, such maps/credentials/protocols also need to be updated. Once maps (e.g. Modality Identity Map 310 and Workstation Map 320) are configured, the IMPACS system 200 can seamlessly route requests to the appropriate slave PACS server 110.sub.n be they for its own unification functions 400 or for emulation purposes 300—all of the protocol conversions and authentications happen entirely within the IMPACS system 200.
[0173] A relational database is adequate for creating the Modality Identity Map 310 and Workstation Map 320 and authentication credentials/protocols for slave PACS servers 110.sub.n, modalities M.sub.n, users U.sub.n, or workstations WS.sub.n. However, the IMPACS system 200 will have to implement the actual protocols for connection to the slave PACS servers 110.sub.n managing the authentication as needed. The DICOM standard does not mandate a specific authentication protocol for PACS servers 110.sub.n. As such, most PACS servers 110.sub.n use a variety of common, standard mechanisms for this purpose and numerous free and commercial packages exist to support these mechanisms. The IMPACS system 200 will implement the authentication protocols required to connect to the slave PACS servers 110.sub.n and modalities M.sub.n and workstations WS.sub.n in its network using authentication software, with customization to varying degrees when necessary. Once the actual connection to the slave PACS server 110.sub.n has taken place, all image-related functions can be performed using standard DICOM protocols. In all cases the IMPACS system 200 (through its PACS server interface 210) appears to the connected client or modality M.sub.n as a regular PACS server 110.
6.5.2 DICOM Data Management (DICOM Tag Replication 410 and Data Unification and Transformation 420)
[0174] With the slave PACS servers 110.sub.n connected, the IMPACS system 200 can be configured to address a number of data issues that it has to overcome so as to provide its intended functionality. Many (though not all) of these issues come up because of the unification function layer 400 the IMPACS is called on to provide. Specifically: [0175] Identifying patients P.sub.n correctly across the slave PACS servers 110.sub.n is not straightforward because the locally unique MRN or PatientID tag is not unique across PACS servers 110.sub.n. A specific PatientID DICOM tag referencing a given patient P.sub.n in one slave PACS server 110 might refer to an entirely different patient P.sub.n in another. Again, the same patient P.sub.n can have different PatientID tags in his DICOM images across different slave PACS servers 110.sub.n. [0176] Searching for specific DICOM tags in the IMPACS system 200 will mean searching across all the associated slave PACS servers 110.sub.n. [0177] Fixing missing or incorrect tags will not be possible unless the IMPACS system 200 knows the tags that need fixing and their associated images and slave PACS servers 110.sub.n.
[0178] To address the above issues, the IMPACS system 200 can be configured to perform the various functions discussed in the sections below in its implementation.
6.5.2.1 Establish a Central Database of DICOM Tags 430
[0179] Most PACS servers 110.sub.n provide capabilities to search for DICOM images by patient P.sub.n, modality M.sub.n or other image tags. To support such functions, as shown in
[0180] The DICOM tag database 430 established by the IMPACS system 200 can take a variety of forms with DICOM Tag Replication 410. At the very minimum, it is a database that only has a list of the images from each slave PACS 110.sub.n along with their study, series and instance UIDs. At the other extreme, it is a database that replicates/copies every tag from every image in its slave PACS server 110.sub.n network. Even if some or all the tags are copied, the volume of data copied is still very small in comparison to the actual images. As such, the amount of data maintained in the IMPACS system 200 DICOM tag database 430 should be very small in comparison to a regular PACS server 110. The user permissioning and security for the IMPACS' 200 unification layer 400 have to be associated to individual images or image groups to permit access of images across the slave PACS servers 110.sub.n. As such, the IMPACS system 200 cannot implement most, if not all, of its unification functions 400 without at least a minimum tag database 430 that has image UIDs.
[0181] If none of the unification functions 400 are desired in a particular implementation, the IMPACS system 200 can execute queries on-the-fly across all the slave PACS servers 110.sub.n and combine them suitably with authorization filters that are determined by non-image-UID based rules. However, each query may impose a heavy network load that could impair performance both of the slave PACS servers 110.sub.n and the IMPACS system 200 itself. Even worse, if one or more slave PACS servers 110.sub.n are not available, the dynamically obtained results may not be comprehensive or accurate. Therefore, the IMPACS system 200 should be implemented, at a minimum, with DICOM tag replication (or copying) 410 of at least a reasonable subset of DICOM tags into the database 430 as described above to address these concerns.
[0182] When the Master DICOM tag database 430 is maintained at the IMPACS system 200 level it may be limited to a small subset of searchable tags during configuration, or, in its most comprehensive form, contain every permissible DICOM image tag. Even so, the tags in a DICOM image do not take up much storage especially relative to the image. As such, the tag database 430 in the IMPACS system 200 will be very lightweight. Importantly, the tags obtained from the images must be combined with additional information that links these images to a specific slave PACS server 110 in which it resides. Thus, in looking at the results of a tag search we can immediately determine just which slave PACS servers 110.sub.n the images returned belong to.
[0183] The Master DICOM tag database 430 at the IMPACS system 200 should be continually updated with current data. It serves for the IMPACS system 200 as the master image index. As such, when any images are added to a slave PACS server 110 and the IMPACS system 200 does not reflect the same in its database 430, the latter's data will not be up to date.
[0184] It should be noted that a huge advantage to using the IMPACS system 200 for its emulation layer 300 for modalities M.sub.n is that when images are stored/changed through the IMPACS system 200 in any of the slave PACS servers 110.sub.n, the IMPACS system 200 will automatically update its DICOM tag database 430 to reflect these changes. If all the modalities M.sub.n used the IMPACS' 200 emulation functions 300 exclusively instead of connecting to their slave PACS server 110.sub.n directly, the data between the IMPACS system 200 and the slave PACS server 110.sub.n will always be in sync without the need for constant polling of the slave PACS servers 110.sub.n by the IMPACS system 200. Of course, if some modalities M.sub.n directly connect to their own slave PACS server 110.sub.a instead of to the IMPACS system 200, the latter will have to be made aware every time an image is stored or modified in this slave PACS server 110.sub.a so that it can keep its Master DICOM tag databases 430 consistent with the image tags in that specific slave PACS server 110.sub.a.
[0185] The problem of tag database synchronization does not occur when modalities M.sub.n connect to the IMPACS system 200 in its unification mode 400. When images are stored or modified in this case, the IMPACS system 200 itself implements all the functions and updates its tag database 430 like a standalone PACS server 110.
6.5.2.2 Create and Maintain a Patient Super-Identity Map 431
[0186] A part of the Data Unification and Transformation 420 is related to patient identity as mentioned above. One of the key features of the IMPACS system 200 is its ability to unify patient records for a given patient P.sub.n across all of its slave PACS servers 110.sub.n. Thus, patients Jack McCoy P.sub.1 who are patient 71522 in Hospital A and 61894 in Hospital B are both actually the same individual. If the IMPACS system 200 has to unify his identities across the hospitals, it has to create a Jack McCoy P.sub.1 super identity (let us say this is JMC1151) that maps to his identities in Hospitals A and B. This new identity has to be given its own authentication credentials for the IMPACS system 200 and it will not be possible to use these credentials to connect to any of the slave PACS servers 110.sub.n without going through the IMPACS system 200.
[0187] The IMPACS system 200 also can be configured to support searching for a given patient's images across all its component slave PACS servers 110.sub.n. For this purpose, as discussed earlier, the IMPACS system 200 will shadow (or replace without overwriting) the PatientID DICOM tag of the images with its self-generated patient super-identity. The database of DICOM tags 430 that the IMPACS system 200 establishes by reading the tag data from all the slave PACS servers 110.sub.n is designed precisely for such searches. However, the IMPACS system 200 will be able to support additional functions relative to a standard PACS server 110 stemming from the fact that it connects to multiple PACS servers 110.sub.n: [0188] It can search for a patient's records by his/her super-identity. Thus for Jack McCoy P.sub.1, the IMPACS system 200 can pull all the images relating to him even though they have different patient identifiers in the slave PACS servers 110.sub.n. [0189] It can permit search for a patient's unified record if his/her identity is provided for a given hospital. So, the IMPACS system 200 can find all the images pertaining to Jack McCoy P.sub.1 across all the slave PACS servers 110.sub.n given only the patient identifier 71522 used in Hospital A as long as it knows that the identifier provided is the one assigned by Hospital A. In such a situation, the IMPACS system 200 will find the super-identity applicable to identity 71522 for Hospital A, and find the records for the right Jack McCoy P.sub.1 across all the hospitals. The IMPACS system 200 can do this efficiently because it does not overwrite any of the images or tags in any of the slave PACS servers 110.sub.n.
[0190] When searching for a given patient's list of studies, the IMPACS system 200 in its unification role 400 will operate with the patient's super-identity by default and provide all the studies pertaining to that patient across all slave PACS servers 110.sub.n that the user is allowed to see. To the querying user thus, it will appear to be storing all the underlying images from the slave servers 110.sub.n even though it does not. While the functionality to allow for querying with slave PACS-specific patient identifiers can be provided, it will generally be preferable for an IMPACS system 200 user to be completely unaware of these slave PACS server 110.sub.n patient identifiers.
[0191] As shown in
[0192]
[0193] The importance of patient unification cannot be stressed enough in the DICOM context given the non-global uniqueness of the patient identifier tag (PatientID) across images from different providers. PACS servers 110.sub.n always provide the PatientID tag information but vary in terms of additional patient data they provide. Typically, the name of the patient and the birth date are provided, but few DICOM images have many (or even any) of the other patient-related tags filled in. Practically speaking, it will generally be impossible to provide complete patient unification just with DICOM image data because there are usually too many of the proverbial John Smith patients who will share a common birthday.
[0194] The IMPACS system 200 acknowledges that patient unification from the image data alone will be impossible except perhaps within multiple slave PACS servers 110.sub.n all within a single hospital chain. As such, as illustrated in
6.5.2.3 Establish Tag Maps and Data Transformation
[0195] In establishing the database of Master DICOM image tags 430, the IMPACS system 200 can fix, alter or add tags as needed based on what the slave PACS server 110 provides. Thus, if a slave PACS server 110 does not fill in the tags for InstitutionName or InstitutionAddress which are standard DICOM tags, the IMPACS system 200 can fill in the values appropriate for that slave PACS server's 110 institution using its own tag database. Again, if the slave PACS' 110 tags reflect a modality type that is incorrect or archaic, the IMPACS system 200 can adjust these tags in its database 430 to have the correct values. When needed, the IMPACS system 200 can also add custom tags to its database 430 for all the images it incorporates into its tag database from the slave PACS servers 110.sub.n. Such custom tags could for example be specific use tags such as whether these images should be made available for research or not, which types of research they are usable for etc.
[0196] To provide the functionality for data transformation as part of the Data Unification and Transformation 420, the IMPACS system 200 has a Rules Engine 440 that implements the tag transformation using a defined set of transformation rules that it is provided. The rules might relate specific image instances, series or studies (by UID) and specific tags that need to be rewritten along with the correct values. Alternatively, the rules might be by slave PACS server 110 where a blanket rewrite of specific tags for all obtained images might be undertaken and so on. The specific rules will be determined by the slave PACS servers 110.sub.n and the tags in question that need fixing.
[0197] This rules engine 440 is essentially part of the IMPACS brain/control engine 201. It is a specific use case example for the Domain Specific Programming Language referred to in the pending application Ser. No. 16/037,249 for “System for Process Coordination and Interoperability across Different Systems, Platforms and/or Business” filed on Jul. 17, 2018.
[0198]
[0199]
[0200] When it comes to searching across images, the IMPACS system 200 can be programmed to override the tag values for the images being searched for with its custom values as set forth in its Tag Map/Override database 432, a process that is facilitated with the IMPACS system 200 having the Master DICOM tag database 430.
6.5.3 Security Framework 510
[0201] The map for the security frameworks 510 used by the various slave PACS servers 110.sub.n and the roles and/or super-identities to be created to permit access to the unification layer 400 were discussed above. There are two broad issues the IMPACS system 200 has to be configured for to implement proper security at both the emulation layer 300 and unification layer 400: [0202] User Authentication. The IMPACS system 200 should authenticate any user U.sub.n logging into it either in emulation mode 300 or unification mode 400 before he/she can be permitted to access any of its functions. [0203] Image Permissioning. Each slave PACS server 110 can determine and control which images an authenticated user U.sub.n within its own framework can access. However, when the IMPACS system 200 is operating in unification mode 400 provided by the unification layer 400 no slave PACS server 110 has any knowledge of users U.sub.n at the IMPACS system 200 level and their access permissions. In general, there will be no user U.sub.n in any slave PACS server 110 that is permissioned to access any other slave PACS server 110. The IMPACS system 200 can be configured to provide a separate framework for user permissioning in this case and determine which images each of these new users U can see across the slave PACS servers 110.sub.n connected to the IMPACS system 200.
[0204] How the IMPACS system 200 handles both these issues is described in detail below.
6.5.3.1 Creation of New Roles and Permissions
[0205] The unification of images across the slave PACS servers 110.sub.n made possible by the IMPACS system 200 requires a richer system of permissioning. This is because the IMPACS system 200 now allows greater access privileges than the slave PACS servers 110.sub.n individually can provide.
[0206] Thus for example, a doctor within hospital A may have access to patient Jack McCoy's P.sub.1 records as well as those of any patient in Hospital A. However, he may not have access to any images from Hospital B. When given a super-identity in the IMPACS system 200, this doctor will not have access to Jack McCoy's P.sub.1 images in Hospital B because his identity by default is not authorized to see images from Hospital B. If our doctor in Hospital A is permissioned by the patient McCoy P.sub.1 to see all his images across hospitals, we need to verify and associate these extended permissions with the doctor's super-identity. Then, any search by that doctor on the patient P.sub.n will retrieve the latter's images across all hospitals. Alternatively, if hospitals A and B merge so that all doctors in either hospital are authorized to see the images of all patients in the unified hospital, then the doctor will be permissioned at the IMPACS system 200 to see all images in Hospital A's and B's slave PACS servers 110.sub.n. In such an event, he would have automatic access to patient McCoy's P.sub.1 images in both hospitals without any additional permission being needed from the patient, though not from a third hospital (say Hospital C) unless explicitly authorized.
[0207] One can easily understand that there will be additional identities such as nurse, operator, etc. applicable to a single hospital that will have to be extended now across hospitals. The IMPACS system 200 will have to create some new super-roles to support an extension of these roles and manage the permissioning of the same. These roles could include the patient P.sub.n (who today almost never has direct access to hospital PACS servers) as well making it possible for him to see his images directly off the hospital's PACS system 100/server 110 instead of relying on a DVD-ROM of images.
[0208] To establish and track these new roles and the authentication needed for the same, the IMPACS system 200 will establish a User/Role/Group Map 518 that is designed to track the various clients that can access the IMPACS system 200 system and the access levels they will have for images in the IMPACS system 200 system once they are authenticated. The User/Role/Group Map 518 can be implemented with a relational database.
[0209] As illustrated in
6.5.3.2 Security Modes 500 for Authentication
[0210] With reference to
[0213] In most implementations, user authentication with flow-through security should be avoided at the IMPACS level 200, even though it can be implemented. User workstations WS.sub.n are rarely static and frequent changes in network addresses, etc. are typical. As such, a user workstation WS.sub.n cannot often be uniquely identified (unlike a fixed modality M.sub.n) which means such users U.sub.n under the emulation mode 300 will not be permitted access at all. For completeness, the IMPACS system 200 can also be configured to associate a local slave PACS server 110 user identity with one of its new roles created as described above to thereby convert an FTS authenticated user after login into an IMS-managed identity.
[0214] Implementing the IMS authorization framework for IMPACS-created users U.sub.n can be done with a commercially available authentication framework (OAuth2, LDAP etc.) or with an equivalent custom framework. The IMPACS system 200 can also be set up to connect seamlessly to an external authentication framework (such as LDAP) and create its users, roles etc. on this framework. Such a framework might already be in place for example in a larger medical system under which the IMPACS system 200 may have to operate.
6.5.3.3 Image Permissioning
[0215] Authentication of a user U.sub.n does not in itself allow the IMPACS system 200 to identify just what images he is authorized to see. To that end, the IMPACS system 200 has to be be configured to associate with every image (or study or series as desired) in its tag DICOM tag database 430 the list of users/roles/groups in its map 518 that are permissioned for that object and just what those permissions are. Given that the DICOM tags will be maintained in a relational database 430, the association of the users/roles/groups to the DICOM objects is an elaborate database many-to-one link.
[0216] The IMPACS system 200 will relate entities in its User/Role/Group map 518 to their permissioned images (along with the type of permissions that they are provided for the same) in the DICOM image tag database 430 by creating an Image Permissions Map 520 as illustrated in
[0217] The actual implementation of the user/role/group objects can (and usually will) be part of a much more extensive permissions hierarchy setup that the IMPACS system 200 may not even implement directly. All that the IMPACS system 200 requires for its function is that it can filter out from the DICOM tag database 430 all the image entries that are visible to a specific user or role Thus, for a specific DICOM object D.sub.j in the database, with a permission association list A.sub.j (which is a list of specific permissions such as read, write, edit etc), what needs to be implemented for the IMPACS system 200 to work correctly is the database function:
Has-Permission(User=U.sub.i,Object=D.sub.j,ObjectPermissions=A.sub.j) (6.1)
which returns True if the user has the permissions and False otherwise.
[0218] For the IMPACS system 200 to work as intended, this function should be implemented either at the level of the IMPACS system 200 itself or by accessing an external permissions framework. To manage authorizations for image access by patients, doctors and other such roles, the IMPACS system 200 will rely on a more elaborate authorization scheme as provided by a more comprehensive process engine such as the Process Knowledge Engine disclosed in the pending patent application Ser. No. 16/037,249.
6.5.4 Extensible Process Engine 610
[0219] As addressed above, implementing the IMPACS system 200 includes: [0220] determining the slave PACS servers 110.sub.n that are part of its network and understanding how to connect to them. [0221] establishing a database of DICOM tags 430 for easy searching across slave servers. [0222] unifying patient and other DICOM information with patient super-identities using the map 431 for this purpose to allow for seamless combination of patient data across the slave PACS servers 110.sub.n, as well as rewriting tag data in returned images. [0223] creating special user/role/group identities using map 518 for this purpose to allow access to the enhanced capabilities provided by the IMPACS system 200 and handle their authentication and image permissioning (via image permissions map 520).
[0224] The process engine 610 (which is part of the IMPACS brain/control engine 201) of the IMPACS system 200 implements the IMPACS system 200's various functions both at the emulation 300 and unification 400 layers and allows it to behave like a standalone PACS server 110 from the perspective of a user U.sub.n or modality M.sub.n. Some of the specifics regarding the execution of the above steps have already been addressed in the relevant sections. Discussed further below are: [0225] how the actual PACS server 110 interface functions are provided by the IMPACS system 200 interacting with the various slave PACS servers 110.sub.n, [0226] how the IMPACS system 200 can provide considerable additional capabilities beyond basic DICOM.
6.5.4.1 Implementing PACS Server 110 Capabilities
[0227] Where it comes to implementing its PACS server 110 capabilities, the IMPACS system 200 can be viewed as being made up of three parts as shown in
[0231] When modalities M.sub.n or workstations WS.sub.n are connected directly to the IMPACS system 200 without being associated with any of the underlying slave PACS servers 110.sub.n (which makes them clients under the unification layer 400 and reflected as such in the modality identity map 310), they operate only with IMPACS level credentials and tags. As such, all modalities M.sub.n connecting in this context operate with patient super-identities known to the IMPACS system 200 in the patient super-identity map 431. Images stored by such modalities M.sub.n will be saved in the self-PACS 710 which the IMPACS system 200 manages. The tags of the self-PACS 710 are managed by the IMPACS system 200 and as such are always kept in sync with the DICOM tag databases 430 maintained by its brain/control engine 201/process engine 610.
[0232] Importantly, it should be noted that the IMPACS system 200 will have to maintain its modality identity map 310 even for modalities M.sub.n that connect directly to the IMPACS system 200 because it has to authenticate all such modalities. Put differently, any modalities connected to the IMPACS system 200 directly without having an associated slave PACS server 110, will be connected to the IMPACS system 200's own self-PACS 710 and will be connecting to the latter in “emulation” mode.
[0233] For all practical purposes, the self-PACS 710 behaves like a slave PACS server 110 in the IMPACS system 200 context. As such, going forward, when we refer to the slave PACS servers 110.sub.n, they should be assumed to include the self-PACS 710 as well unless explicitly indicated otherwise. The DICOM tag databases 430, user maps and other implementation issues discussed earlier in this section relate only to the IMPACS' process brain/control engine 201 (and the process engine 610 part of this brain).
[0234] It may be possible to configure the IMPACS system 200 without a self-PACS 710 if certain functions such as image storage (under unification mode 400) are not needed. However, it is preferable to set up the self-PACS 710 and configure it for proper operation.
[0235] Implementing the PACS server 110 functions such as the retrieval and storage of images by the IMPACS system 200 process brain is relatively straightforward. This is because the IMPACS system 200 itself is not providing these functions—the slave PACS servers 110.sub.n are (with the self-PACS 710 being one of the “slaves” as well). The syntax of the DICOM function calls is governed by the DICOM standard which both the IMPACS system 200 and the slave PACS servers 110.sub.n observe. Thus, the instructions received by the IMPACS system 200 can be transmitted to the corresponding slave PACS server 110 that is to perform the function with some relatively simple translation of the actual function syntax at the IMPACS system 200 level. Put differently, in implementing the basic DICOM functions, the IMPACS system 200 acts primarily like a traffic policeman, routing the various DICOM calls it receives to the appropriate slave PACS servers 110 and transmitting back the results.
[0236] When the IMPACS system 200 provides any form of image storage or modification either through its emulation functions 300 or saving into its self-PACS 710 under unification mode 400, it has to update its DICOM tag database 430 to reflect the new images and tags. A flow chart of how the IMPACS system 200 stores images into its network of attached slave PACS servers 110.sub.n including its Self PACS 710 is shown in
[0237] When a new image is stored into a slave PACS server 110 by the IMPACS system 200 with its emulation layer 300, the latter will automatically update its DICOM tag databases 430 which means that the slave PACS image data will be in sync with that in the IMPACS system 200. Clearly images saved into the self-PACS 710 are always in sync. New images stored into a slave PACS 110 by modalities M.sub.n the IMPACS system 200 is not aware of can be recognized only by polling the slave PACS server 110 image database for changes and updating the Master DICOM tag database 430 and/or the Tag map/Override database 432 as needed when such storage occurs.
[0238] The examples below show particular implementation features using pseudo-DICOM function call syntax to highlight what exactly is being done.
Example 1
[0239] This example is discussed with reference to
[0240] In terms of a function call this request could be written as:
DICOM-Get-Object(RequestingUser=U.sub.i,RequestingUserPassword=ABCDE,Patient=JMC1151,Study=S.sub.j,Location=VP1) (6.ii)
[0241] Faced with this request, the IMPACS system 200 will do the following in order: [0242] 1. Check if the user U.sub.i is allowed to connect to the IMPACS system 200 by authenticating with the password ABCDE provided (steps 1 and 2). Such authentication might be done by the IMPACS system 200 itself using standard protocols using its user/role/group map 518 or by other authorization servers to which the IMPACS system 200 might be tied if it is part of a larger medical records system. [0243] 2. Check that the requesting user U.sub.1 has the credentials to access the study step 1904, 1905). This can be implemented as a function:
DICOM-Authenticate-User-For-Study(RequestingUser=U.sub.i,Patient=JMC1151,Study=S.sub.j) (6.iii) [0244] that will return True to authorize access and False if not, checking the Image Permissions Map 520 for this purpose. [0245] If the user U.sub.i is a doctor who has been authorized by the patient Jack McCoy to see all his images, the above request will return True. If the IMPACS system 200 receives an affirmative response, it allows the request to proceed to the next steps and aborts it otherwise. [0246] 3. Find the slave PACS server 110 that contains the requested DICOM object when we have an authenticated request (step 6). For this, the IMPACS system 200 will consult its DICOM tag database 430 which stores an extra attribute defining which slave PACS server 110 contains the said object. In function terms, the IMPACS 200 executes the following function that it has implemented:
DICOM-Locate-SlavePACS-for-DICOM-Object(Patient=JMC1151,Study=S.sub.j) (6.iv) [0247] Assume that this function call returns a value of SP.sub.k which identifies the slave PACS server 110 in which the image is located. [0248] 4. Get the appropriate authentication credentials (step 7) for the requesting user for the Slave PACS server 110 in which the image is consulting the user/role/group map 518 for this purpose if needed:
DICOM-Get-Authentication-For-User(RequestingUser=JMC1151,Location=SP.sub.k) (6.v) [0249] This call will return the username for the requesting user in the slave PACS server 110, as well as his password. Assume that this call returns Username=DOCTORp and Password=XXYYZ. This step will be unnecessary if the slave PACS server 110 trusts the IMPACS system 200 to perform all the required authentication and provides blanket access for the IMPACS system 200 to access all images deliverable to the IMPACS system 200. [0250] 5. Get the patient identifier corresponding to the object requested in the slave PACS server 110 if needed (step 7). This is an optional step that may not be required if UIDs are used for the Study, Series or Instance requested because these are globally unique already by the DICOM standard.
DICOM-Match-Patient-ID-To-SlavePACS(Patient=JMC1151,SlavePACS=SP.sub.k) (6.vi) [0251] In this example, assume the above call returns 71522 as the identifier for our patient. [0252] 6. Format and dispatch the DICOM request for the requested object (step 8). The DICOM request to the slave PACS can simply be sent as:
DICOM-Get-Object(RequestingUser=DOCTORp,RequestingUserPassword=XXYYZ,Patient=71522,Study=S.sub.j,Location=SP.sub.k) (6.vii) [0253] 7. Send the requested data back from the slave PACS server 110 with the appropriate tag rewrites as needed to the requesting workstation (step 9). The user workstation WS in this context will never connect to the slave PACS server 110 directly but only to the IMPACS system 200 itself.
Example 2
[0254] The IMPACS VP1 might also be queried for all studies pertaining to a given patient JMC1151 over some period say from 10/11/2017 to 10/11/2019 as permitted by DICOM. In this case again, the user is operating with an IMPACS system 200 provided super-identity. This example is discussed with reference to the flow chart provided in
[0255] The query in this case can be represented as:
DICOM-Filter-Objects(RequestingUser=U.sub.i,RequestingUserPassword=ABCDE,Patient=JMC1151,Location=VP1,DateRange=[10/11/2017,10/11/2019]) (6.viii)
[0256] The IMPACS system 200 will now have to contend with the fact that patient JMC1151 is a super-identity for Jack McCoy that has no analog in any slave PACS server 110. To execute this query, the IMPACS system 200 does the following, after authenticating the user in question: [0257] 1. Search its internal DICOM tag database 430 to find all the images that satisfy this query, or [0258] 2. Query all of the slave PACS servers 110.sub.n to dynamically generate the requested list of images. To perform a dynamic query, the IMPACS system 200 will: [0259] (a) Determine JMC1151's list of slave PACS servers 110.sub.n identities which in our case are 71522 in Hospital A and 61894 in Hospital B, and the slave PACS servers' 110.sub.n details which are linked to these identities. [0260] (b) Obtain the slave PACS servers' 110.sub.n locations from the details provided in the prior query. Assume these are SP.sub.a and SP.sub.b for Hospitals A and B respectively. [0261] (c) Format and dispatch the requests appropriately for each slave PACS server 110 fixing the patient identity as required. So for Hospital A, the generated query would be:
DICOM-Filter-Objects(Patient=71522,Location=SP.sub.a,DateRange=[10/11/2017,10/11/2019]) (6.ix) [0262] and for Hospital B it would be:
DICOM-Filter-Objects(Patient=61894,Location=SP.sub.b,DateRange=[10/11/2017,10/11/2019]) (6.x) [0263] Importantly, the user identifier U.sub.1 and the password ABCDE cannot be passed into the slave PACS servers 110.sub.n because they are not even aware of the existence of the IMPACS system 200 identity U.sub.1 which is JMC1151 here. [0264] (d) Collate the results from the above two queries (which follow standard DICOM formats) into a unified result list for further processing. Importantly, the list returned will have additional attributes listing which slave PACS server 110.sub.n contains the image. [0265] (e) Obtain the UIDs of the images from the collated list and check from the IMPACS-maintained DICOM tag database 430 and user/role/group map 518 and image permissions map 520 which of these images our user U.sub.1 has permission to see. Create a list of images that both satisfy our user's query and whose results he is permissioned to see. [0266] (f) Return the filtered list to the user. The query will not show any results he is not permissioned to see. [0267] 3. With the list of images (and slave PACS servers 110.sub.n where they are stored) obtained from either of the steps above, the IMPACS system 200 can now format the request for each image trivially as in the previous example. When delivering the actual image, any tag rewrites can be performed on the fly.
[0268] Given that the IMPACS system 200 maintains databases of DICOM tags 430 as well as an image permissions map 520 for images from all the slave PACS servers 110.sub.n, it is likely that the above queries can be handled entirely by the IMPACS system 200 itself without any access being made to the slave PACS server 110 except for the final retrieval of the images.
[0269] In both of the above examples the IMPACS system 200 performed the same set of steps which are: [0270] 1. parsing a standard DICOM request made to it by a user U.sub.n or modality M.sub.n. [0271] 2. determining from the request the correct slave PACS server(s) 110.sub.n that need to be involved in its fulfillment using its internal databases for that purpose. [0272] 3. obtaining the correct object and patient identifiers along with the right user credentials as needed for each involved slave PACS server 110.sub.n. [0273] 4. formatting the request properly for each slave PACS server 110 which, for the most part, merely involves rewriting the same with the right identifiers for that slave PACS server 110. [0274] 5. gathering the results, changing or fixing tags as needed, and delivering them to the requesting user U.sub.n.
[0275] The important thing to note is the structure of the query is already set by the DICOM standard which both the slave PACS server 110 and IMPACS system 200 implement. All that the IMPACS system 200 does is rewrite these queries into a form appropriate for each slave PACS server 110 using its internal databases and logic for that purpose as configured into its process brain/control engine 201.
6.5.4.2 Implementing Process Extension Layer 600
[0276] The IMPACS system 200 could also alter the images delivered to or obtained from the slave PACS server 110 by an agent, either by rewriting certain DICOM tags, converting the image formats or performing some other such transformation based on extensible rules set up within the IMPACS system 200 for this purpose. Thus, a modality M.sub.n that does not fill in specific DICOM tags might have such tags added by the IMPACS system 200 before delivery to the slave PACS server 110 if such a permanent tag is desired in the actual stored image. Again, an image with missing or incorrect tags might have its tags overwritten by the IMPACS system 200 using its Tag Map/Override database 432 without altering the actual stored image. In this context, the IMPACS system 200 behaves as a special case of the more general process knowledge engine discussed at length in the pending patent application Ser. No. 16/037,249. The IMPACS system 200 can be configured with a process specification language in which one could define multiple rules and its process knowledge engine can implement these rules for additional activities beyond its DICOM functions.
[0277] The rewriting of tags, which is a general issue that the IMPACS system 200 needs to address because it overrides the PatientID tag field, can be implemented as shown in
[0278] When an image is accessed, the IMPACS system 200 checks the returned image's Instance UID against its internal Tag map/Override database 432 using the logic provided by its Rules Engine 440 as described above. If a specific tag needs to be overwritten with one from the IMPACS' data transformation tag database 432, the IMPACS system 200 can update the tag of the image returned before passing it onto the requesting agent. The same logic will apply in reverse if a tag has to be altered for a new image created by a modality M.sub.n. In the latter case, the tag transformation associations will be maintained for each modality M.sub.n at the IMPACS system 200 level, with an association between the the modality identity map database 310 and the tag map override database 432. Based on the modality generating the image, the tag will be transformed before delivery for writing to the slave PACS server 110.
[0279] Not all tags can be re-written by the IMPACS system 200 when it comes to passing through images from a modality M.sub.n to be saved into a slave PACS server 110. Many of the tags in a DICOM image are set by the PACS server 110 itself when the image is saved (like the study, instance and series UIDs for example) and should not be changed. In general, when it comes to saving images, the IMPACS system 200 will rewrite only custom DICOM tags (including ones that it has created for specific image search filters) or other non-critical tags (such as for example the InstitutionName tag in some situations) before transmission of an image to the associated slave PACS server 110.
[0280] Where it comes to delivering images that have been accessed, the IMPACS system 200 may overwrite the PatientID tag if in unification mode 400 to permit consistent image viewing for a given patient across slave PACS servers 110.sub.n. Such overwriting is generally not essential but may be required in certain deployments. However, image UID tags for the image instance, study and series should not, in general, be rewritten.
6.5.4.3 Creating Audit Trails
[0281] Since the IMPACS system 200 has to manage authentication for all clients including users, modalities, workstations and patients using its respective maps 518, 310, 320 and 431, it is already configured to track access of any slave PACS server 110 by any of these client entities. As such, the IMPACS system 200 by simply logging such access, can provide an automatic audit trail of every access and every use of any DICOM resource by any user U.sub.n, workstation WS.sub.n or modality M.sub.n or patient P.sub.n. In addition, it provides a layer of authentication security that is over and above that provided by any slave PACS server 110.sub.n and that can be further enhanced as needed without altering the security models used by the slave servers 110.sub.n.
6.5.4.4 Transporting the Image Objects between Agents
[0282] After the authentication, image access and process extensions are completed, the IMPACS system 200 can seamlessly transport the queried/requested/stored image objects or groups to the client device, slave storage PACS server 110.sub.n or modality M.sub.n as appropriate to implement the full PACS server 110 functionality. Thus for example, the IMPACS system 200 may obtain the images from the slave PACS server 110.sub.n and deliver the images to the client. Again, it might receive the image from the acquiring modality M.sub.n and send it the appropriate slave PACS server 110.sub.n for storage managing all the confirmations and messaging for the same. In all these cases, the IMPACS system 200 will act as the supervising intermediary that manages the process providing all the control and oversight for this. In general, the accessing client (modality M.sub.n, workstation WS.sub.n or other entity) will not know that the slave PACS servers 110.sub.n even exist because the IMPACS system 200 effectively subsumes their functionality.
[0283] The IMPACS system 200 even at this level can be extended to perform certain optimizations because of its process intelligence. It can for example detect the nature of the querying device and apply image compression or transformation as appropriate to permit the quickest delivery of the image. Based on the capabilities of the requesting device, it can apply intelligent algorithms to permit better viewing. Thus for example, the IMPACS system 200 could detect that the querying device is a mobile telephone and apply both compression and image enhancement to the returned image so that it is delivered quickly and the image view on the poorer quality (relative to medical viewers) phone screen is optimized.
[0284] Thus, the IMPACS system 200 thanks to its process brain/control engine 201, is a powerful and extensible system for managing the DICOM process flow. The various maps that are maintained by the IMPACS system 200 are the data that define what its brain/control engine 201 needs to perform its many functions. Actually performing these functions requires that the IMPACS system 200 be programmed for these capabilities as discussed herein. These programs along with the logic needed to execute them, collectively make up the IMPACS' brain/control engine 201, and allow it to provide the IMPACS system 200's PACS server interface 210. All of this functionality makes up the entirety of the IMPACS system 200.
6.6 Using the Impacs System 200
[0285] Addressed below are various use scenarios and associated flow charts and diagrams.
6.6.1 Image Access for Client/Patient P.sub.n/Workstation WS.sub.n
[0286] A client or workstation WS requesting PACS images from a variety of slave PACS servers 110.sub.n would connect directly to the IMPACS system 200 and the IMPACS system 200 would perform the following actions: [0287] 1. Authenticate as his chosen agent/role into the IMPACS system 200 using standard protocols. When the client is a user U, for reasons discussed earlier, authentication is generally with IMPACS system 200 supplied credentials because the role identification might otherwise be impossible. The IMPACS system 200 can be configured to support most publicly available security protocols. While it may use some of the same protocols in use at one or more of its slave servers 110, the IMPACS system 200 can have a much richer security framework 510 than in the slave PACS servers 110.sub.n because the IMPACS system 200 provides a level of access across slave servers 110.sub.n which the latter do not permit. To permit the added functionality of the IMPACS system 200, new roles/permissions will likely have to be created as discussed earlier using the user/role/group map 518. [0288] 2. Query the studies/series/images etc. that his role has access to. The IMPACS system 200 will seamlessly determine which subset of data from all the slave PACS servers 110.sub.n can be made available for this agent to query and/or see by referring to its internal master DICOM tag database 430 and Image permissions map 520 which provides the permission matrix for a given image and its a user from the user/role/group map 518. It may also query the slave PACS servers 110 as needed for additional tag data. [0289] 3. Obtain and Display specific images or image groups to the software used by him for viewing the DICOM images. The IMPACS system 200 will seamlessly access the requested images from the slave PACS servers 110 providing the appropriate agent-specific security credentials to the slave servers 110 and deliver them to the client.
[0290] For a slave PACS server 110 user U.sub.n accessing the IMPACS' 200 emulation layer 300 without having an IMPACS system 200 created identity, the above steps are similar, but the query for the user's images will be done only at the slave PACS server 110 rather than at the IMPACS tag database 430.
[0291] Put differently, the IMPACS system 200 will in all respects behave like a “regular” PACS server 110 to a user U. Under the hood however, in unification mode 400, the IMPACS system 200 operates to combine the data from a plurality of slave PACS servers 110.sub.n in terms of patient identities, security protocols, access roles etc. without having to copy and itself store the actual (large) images from the slave PACS servers 110.sub.n or modify them in any way. In emulation mode 300, it is behaving like one of its component slave PACS servers 110.sub.n and the very existence of the IMPACS system 200 is something that the connected modalities M.sub.n and/or workstations WS.sub.n are generally totally unaware of.
6.6.2 Target Store for a Modality M.SUB.n
[0292] A modality M.sub.n that uses the IMPACS system 200 as the main PACS store in emulation mode 300 will simply continue to operate as it did before except that it will connect to the IMPACS system 200 instead of its local PACS server 110. The local PACS server 110 is now one of the slave servers 110.sub.n within the IMPACS framework 200. With reference to
[0301] In the examples above while the IMPACS system 200 has to do a lot of work to map patient identities, modalities, etc. to the appropriate slave PACS server 110. Once that work is done the actual access of images, queries etc. is relatively simple because the IMPACS system 200 will be operating using the DICOM standard with some translations of the function calls made to the various slave PACS servers 110. In performing these functions, the IMPACS system 200 can fully satisfy all the security requirements moreover of every slave PACS server 110.sub.n.
[0302] Even if the IMPACS system 200 were to route image storage requests into the slave PACS servers 110.sub.n for all its connected modalities M.sub.n, it could also simultaneously store images from these modalities M.sub.n into another slave PACS server 110 but using newly-created IMPACS-level patient identities. This will permit a provider with multiple archaic PACS servers 110.sub.n to create images in this new PACS server 110 using the new unified IMPACS identities while continuing to operate with the old PACS servers 110.sub.n as well over a transition period.
6.7 Progressive Implementation with IMPACS system 200 Hierarchies
[0303] In an embodiment, and as addressed further below, the IMPACS system 200 can be implemented in a progressive, hierarchical fashion that can scale across numerous slave PACS servers 110.sub.n without significantly impacting the complexity of the implementation or reducing its efficiency. Each slave PACS server 110 can belong to multiple IMPACS systems 200.sub.n with almost no additional overhead. Further, each IMPACS system 200 itself through its PACS server interface 210, can become a slave PACS server 110 to another IMPACS system 200.
6.7.1 Multiple IMPACS system 200 memberships for Single Slave PACS Server 110
[0304] The IMPACS system 200 is a lightweight layer intended to ensure interoperability across PACS servers 110.sub.n. As such, the same slave PACS server 110 can belong to multiple IMPACS systems 200.sub.n without any extra overhead or modification. In fact, two different IMPACS systems 200.sub.a and 200.sub.b can create their own unification tags for patients but still use data from the same underlying slave PACS servers 110.sub.n. This should prove a powerful mechanism to permit custom types of unification. Thus, for example, one might have an IMPACS system 200 that unifies only the data from patients of certain ethnicities or with certain ailments with extra logic for such patient filtration being provided by other external methodologies. Again, we might have a doctor/patient centric IMPACS system 200.sub.a that provides full patient unification, but another research focused IMPACS system 200.sub.b that provides the same unification while anonymizing all specifically identifiable patient data. In technical terms, all of these IMPACS systems 200.sub.n can run off a master DICOM tag database 430 that is created just once from the connected slave PACS servers 110.sub.n. The only changes that may be required to support these different IMPACS system 200 instances would be different filters applied to the master DICOM tag database 430 and different image delivery algorithms (with or without anonymization etc.) to permit selective viewing. Put differently, each of these multiple IMPACS system 200 instances will have essentially identical maps and data, but will differ in the programming of each of their process brains/control engines 201.
6.7.2 IMPACS System 200 as Member of Another IMPACS System 200
[0305] The IMPACS system 200 is a full-fledged PACS server 110 in its own right, both in emulation mode 300 and in unification mode 400. As such, any IMPACS system 200 through its PACS server interface 210 can itself serve as a slave PACS server 110 within a higher level IMPACS system 200.
[0306] With reference to
[0307] This functionality can be replicated again if needed with one or more Level 1 IMPACS servers being unified by a Level 2 IMPACS server etc. creating a natural unification hierarchy. The powerful feature is that an IMPACS server 200 at any level can be accessed both by its modalities M.sub.n and workstations WS.sub.n/users U.sub.r, as needed and can provide just the degree of unification it was intended to, along with all the emulation functions 300 it was configured for. Accessing a higher level IMPACS system 200 (at Level 1 instead of Level 0 for example) simply expands the degree of unification and emulation provided.
[0308] The beauty of the hierarchical IMPACS system 200 implementation is that it is organized intuitively for efficiency. Turning to
[0309] The hierarchical implementation of the IMPACS system 200 is possible even when only its emulation functions 300 are required. To permit this of course, every higher level IMPACS system 200 should have a copy of every modality M.sub.n connected to each lower level IMPACS server 200.
6.8 Non-DICOM Modalities M.SUB.n .and Non-PACS Storage
[0310] In discussing the extension layer functions 600 of the IMPACS system 200 above, we addressed the use of the IMPACS system 200 to enable new modalities M.sub.n for DICOM imaging, as well as to PACS-enable non-DICOM storage. These two features are discussed in more detail below.
6.8.1 Non-DICOM Modalities M.SUB.n
[0311] The cheap and ubiquitous availability of digital cameras, smart phones and computer webcams has made it very easy to use such devices for medical purposes. These consumer-grade devices are generally not certified for medical use. However, many doctors use images obtained from these sources to supplement their analysis of a patient. Thus, many dermatologists often take pictures of specific skin lesions using consumer-grade digital cameras. Yet others, such as otolaryngologists, use digital video cameras connected to their medical scopes to obtain full-motion video during their examination of a patient's pharynx, sinuses or other areas. The problem in using such user-centric, typically consumer-grade devices for medical image acquisition is that they cannot be incorporated into the standard medical imaging workflow which typically uses DICOM. As such, potentially helpful data about a patient are not easily accessible except through the capturing doctor's own custom process for the same. If these images could be added to the patient record within the hospital, ideally to the hospital's PACS server 110, they could be incorporated into the medical workflow. However, uploading such images to the provider's PACS server 110, while possible, is a difficult process with conventional systems for several reasons. A non-exhaustive list of these reasons is: [0312] The images and the imaging device are not DICOM compliant. In fact, the images have tags defined by some other standard such as JPEG or camera RAW, and cannot easily be wrapped into DICOM format. [0313] Converting the obtained images to DICOM involves both mapping current image tags to DICOM-equivalent tags, and adding numerous DICOM-specific tags in particular regarding the patient, the body parts imaged and the device. These tags typically have to be added manually which means the process is more error-prone. [0314] Connecting the imaging device to the PACS server 110 is a laborious process especially given the need to add tags manually. Typically, the images will be downloaded to a hospital computer, the tags will be added and then the images have to be be uploaded to the PACS server 110.
[0315] The IMPACS system 200 can address all the above problems and be configured to seamlessly convert and incorporate images from non-DICOM devices into a DICOM-centric medical workflow. A general example of this process is illustrated in
6.8.2 Non-PACS Image Storage
[0323] There are many image formats that are increasingly part of the medical workflow for which a DICOM framework may not be appropriate. For example, slide scanners for the digital imaging of tissue samples in pathology operate with complex image formats and proprietary tag schemes that are not DICOM compliant. Again, medical video devices often generate huge files requiring their own dedicated storage. Such images may be part of the patient's medical record, but are not handled by the DICOM standard (yet) and may not even be stored on the provider's PACS server.
[0324] The IMPACS system 200 as a process engine is agnostic to the types of images being stored and searched for. As described above it can take a non-DICOM image from a device and wrap it into DICOM for storage into a PACS server. In addition, the IMPACS system 200 can also do this process backwards and PACS-enable a non-PACS image storage repository converting it into what we refer to as a pseudo-PACS 810. The images in the pseudo-PACS 810, even though they are not DICOM compliant, can be made available to all connected DICOM workstations and become part of the DICOM workflow to the extent technically possible.
[0325]
[0326]
[0330] By including non-DICOM images served up by non-PACS servers into a DICOM/PACS workflow, the IMPACS system 200 allows the same communications hardware and protocols to be used. Again, it allows for the complete incorporation of all security, audit and permissioning frameworks in place for handling images. And it can handle such images using this pseudo-PACS framework 810 until such time they are properly incorporated into the DICOM standard if at all.
6.8.3 Advantages over Prior Art
[0331] The IMPACS system 200 systems and methods disclosed herein provide various advantages over the prior art. A primary advantage of the IMPACS system 200 is the interoperability functions it provides in its unification layer 400. Using its emulation functions 300 alone with a group of slave PACS servers 110.sub.n is possible, but there is less benefit to outweigh the overhead of implementing the IMPACS system 200 unless the use of some or all of the unification functions 400 is anticipated.
[0332] Where it comes to unification, the IMPACS system 200 provides numerous advantages and is a superior alternative to other methodologies for achieving this. These advantages include: [0333] Non-Disruptive Setup. The IMPACS system 200 can be introduced into a provider facility without disruption of the existing workflow. The IMPACS system 200 needs to build its maps of DICOM tags 430, patients 431, modalities 310 and client identities 518 as needed for each slave PACS server 110 before the latter can be added into the IMPACS framework 200. However, building these maps does not interfere with the provider's workflow at all. Even the data accesses needed to obtain the DICOM tags can be done during the provider's off hours so that there is no slow down of the PACS servers 110.sub.n in times of heavy use. [0334] Incremental Implementation. The IMPACS system 200 does not have to be implemented all at once for a given provider facility. A few modalities M.sub.n and/or clients can be switched over to the IMPACS system 200 to ensure that the system works as desired and that no problems occur before all the users U.sub.n and modalities M.sub.n are moved over. The existence of the emulation layer 300 in the IMPACS system 200 means that the various units attached to the IMPACS system 200 can continue to use their local (now slave) PACS' patient identifiers before migrating to the unified identifiers set up by the IMPACS system 200 as and when needed. [0335] No Modification of Images. The IMPACS system 200 does not overwrite the slave PACS servers' 110.sub.n existing images with new patient tags or any other information at all. In fact, the slave PACS servers' 110.sub.n data can remain completely untouched by the IMPACS system 200. As such, there is no risk of compromising the important patient image data. Yet, the unification functions 400 work exactly as one would expect if the slave PACS data were all migrated to a single PACS server 110. [0336] Minimal Data Replication. The IMPACS system 200 does not copy all the image data and as such does not require a dramatic increase in image storage requirements. What it does is copy some of the important DICOM tags from the slave PACS images to its own internal master DICOM tag databases 430 to permit high speed searching and retrieval of images and groupings from each slave PACS server 110. This limited copying and storage of tags can be minimized, though the cost for this will come in the form of slower image access because each of the slave PACS servers 110.sub.n will then have to queried dynamically for this purpose. [0337] Extensible Intelligence. The IMPACS system 200 can implement complex image rules that allow for multiple image backups in different PACS servers 110.sub.n, partitioning of storage by image type etc. It can also be made to send notifications to other PACS servers 110.sub.n or clients when new images are stored or accessed. Even better it can support brand new modalities M.sub.n such as camera phones and support DICOM tag creation for any such new modalities M.sub.n. In addition, it can incorporate non-DICOM images from a non-PACS image storage repository into a DICOM/PACS workflow. These extensions made possible by the IMPACS brain/control engine 201/process engine 610 make the IMPACS system 200 much more flexible for future medical imaging needs than any current PACS server 110.sub.n. [0338] Superior Performance. The IMPACS system 200 can perform as well as a regular PACS server 110.sub.n and could, in many cases, provide far better performance. This is because the IMPACS system 200 has a powerful engine that can be configured to provide all the patient mapping, image tag storage etc. all maintained within a high-performance database engine that many regular PACS servers 110.sub.n, especially in smaller provider facilities, lack. More importantly, the IMPACS system 200 has the ability to exploit multiple data stores to improve speeds. Thus, a regular PACS server 110 might have a backup PACS server 110 that it copies its images to, and the IMPACS system 200 can seamlessly optimize access by utilizing both stores to deliver the images to a workstation WS. Because of its extensible intelligence, the IMPACS system 200 can be taught to cache frequently used images or perform other access optimizations to improve performance even more.
[0339] The IMPACS system 200 is vastly different both in concept and in execution from conventional prior art approaches. The differences include at least the following: [0340] Explicit Patient Unification for Interoperability. The IMPACS system 200 addresses a limitation of DICOM which is the non-global uniqueness of the patient identifier tag (PatientID) across images. Patient unification is a complex process that will vary depending on what types of slave PACS servers 110.sub.n are being unified. Different techniques for unification will typically be needed based on the circumstances, geographic region, legal regulations etc. The IMPACS system 200 can handle a variety of mechanisms for patient unification be it using a separate subsystem or even a manual process. The unification provides the IMPACS system 200 with a specific patient's PatientID DICOM identifiers across all the slave PACS servers 110.sub.n that are part of its network. With this information, the IMPACS system 200 can permit any authorized user to access all the images he is permissioned to see for a given patient across all the provider (slave) PACS servers 110.sub.n exactly as though these images were all resident on the IMPACS system 200 itself. This will happen without any rewriting of any image tags in the slave PACS 110.sub.n. [0341] Centralized and not Peer-To-Peer Design. Contrary to conventional approaches, the IMPACS system 200 inserts its central intelligence between every relevant modality M.sub.n, workstation WS.sub.n, user U.sub.n or any other client connecting to any of its component slave PACS servers 110 and the former do not peer with any of the slave PACS servers 110. In an implementation, it is not possible for any agent connected to the IMPACS system 200 to access any of the slave PACS servers 110.sub.n except through the IMPACS system 200 itself, coming under its authentication and security frameworks. The connected entities are not even aware that the slave PACS servers 110.sub.n even exist. Even in emulation mode 300 where the IMPACS system 200 behaves like one of the slave PACS servers 110.sub.n it does not require that the actual slave PACS server 110 be connected, online or that it even actually exist, nor does this matter to the connecting agent. The emulation functions 300 provided by the IMPACS system 200, pertain to authentication and patient identifiers used for the images rather than explicit peering to a slave PACS server 110 and as such, the IMPACS system 200 can directly emulate the slave PACS server 110 (and its storage) internally in its software if needed. The image store in this context might be in a connected, yet separate database that may not even be able to function as a PACS server 110 except when serving images through the IMPACS system 200. [0342] Centralized Roles and Permissioning. By defining its own user identities, roles and permissioning (maps 518 and 520) which map into the slave PACS server's 110 authorizations, the IMPACS system 200 can support a wide variety of granular or hierarchical access to its slave PACS server's 110 data. In fact, the IMPACS system 200, with some configuration, can operate with any authorization or permissioning protocol that might be desired as long as the users and agents defined by such a scheme can be mapped into appropriate image permissions at the slave PACS servers 110.sub.n. Known prior art approaches either do not directly address permissioning at all or suggest a framework for a doctor to request patient authorizations for image access. In the latter case this permissioning has to be done at the level of every hospital where the patient P.sub.n has images, effectively on a peer-to-peer basis and the onus is on the doctor to determine all the locations at which the patient's images are. For a patient P.sub.n with a common name like John Smith this should prove a herculean task. The IMPACS system 200 is designed to handle roles, access and permissioning across all hospitals within its own framework for all agents connected to it. It can tie easily into a specialized permissioning system to manage permissions as well if needed. [0343] Complete Monitoring and Audit Trail of All Access. Since all access to any images has to go through the IMPACS system 200, the IMPACS system 200 can maintain a comprehensive audit trail and manage access at any level of granularity desired. As such, the IMPACS system 200 can also constantly monitor its connections for unusual access or hacks in a way that prevents any user, modality or workstation from bypassing such monitoring. Such an extensive degree of auditing, which might be needed for compliance with various government legal requirements for medical data, is simply not possible in conventional PACS systems 100 without adding on non-standard frameworks for the same. [0344] Extensible DICOM Tag Intelligence to Permit Wider Use. The central engine of the IMPACS can seamlessly handle DICOM tag modification, patient anonymization etc. all of which can be done on the fly on image delivery to the user U.sub.n/workstation WS.sub.n without modifying the images stored in the slave PACS servers 110.sub.n at all. This can all be done by additions to the IMPACS system 200 logic, programming its brain/control engine 201 appropriately, without the need to create any new infrastructure, network links etc. Put differently, once the core IMPACS system 200 is in place, it can handle most use cases that one can envision for DICOM images across a variety of potential users. Thus, the IMPACS system 200 can deliver images to radiologists with full patient information, to researchers with patient anonymization, to insurers with additional patient tags as needed regarding their insurance identifiers etc. All this can be done using the same tag database obtained from the slave PACS servers 110.sub.n when the IMPACS system 200 was set up. None of the conventional approaches to DICOM interoperability provides these features. [0345] Modality and Device Monitoring to Enable New Methods for Image Storage and Retrieval. The IMPACS system 200 can be extended to analyze images and detect if they are from devices such as smart phones and cameras rather than medical modalities. The IMPACS system 200 can be programmed to provide custom DICOM tags for such images to permit storage in a slave PACS server 110. The IMPACS system 200 can detect the type of workstation that is using the final requested DICOM image and the speed of the connectivity to that workstation. As such, IMPACS system 200 can seamlessly compress the images for delivery over a slower connection, process images for display on a lower resolution device etc. all of which are possible because of its intelligence as represented by its process brain/control engine 201. [0346] Lightweight Database that Can Easily be Tuned for Better Performance Using Replication, Caching and Other Techniques. Conventional approaches to DICOM interoperability take the speeds involved for image storage and delivery as a given. Many resort to peer-to-peer approaches for quicker image delivery recognizing that delivery of images from a PACS to a central system that sends it onward might be too slow. One known prior art approach addresses the problem of efficiency head-on with a completely new and disruptive networked file technology (that cannot be retrofitted onto existing PACS systems 100) with a central tag database. The IMPACS framework 200 is built for current computing environments where networking speeds are much faster. Bottlenecks because of the IMPACS' 200 internal processing can be dealt with by replicating its relatively lightweight implementation across multiple cloud-based servers. By analyzing its audit trails for image access, the IMPACS system 200 can cache frequently used images and deliver them quickly to requesting agents without even accessing the corresponding slave PACS 110. The IMPACS system 200 can even use advanced Web server methods to generate the speeds of peer-to-peer networking while still maintaining its centralized access and image delivery framework. While the IMPACS system 200 provides state of the art performance, it can be progressively improved for better performance based on the patterns of image access and use, and also be adapted to changes in technology. Conventional approaches do not provide for such usage-based improvements or provide a framework to capture such usage data, let alone enable tuning based on usage.
[0347] Accordingly, an IMPACS method and system 200 disclosed herein provides an improved, high performing, and extensible PACS server 110. Despite all its functionality, the IMPACS system 200 can appear to a user U.sub.n or modality M.sub.n just like a regular PACS server 110. No special configuration is needed for modalities M.sub.n or user workstations WS.sub.n (from a user's perspective) to connect to the IMPACS system 200 other than what a normal PACS server 110 might entail. The IMPACS system 200 can separate out the process of image access and handling from the images themselves in an efficient manner because of its lightweight central intelligence. The IMPACS system 200 can be deployed into a secure, cloud-based environment allowing it to be scaled without any modifications.