The seven levels of PACS integration
The contents of this whitepaper are public domain.
PACS integration means different things to different people. One can distinguish between seven different levels of integration, ranging from No Integration up to API Level Integration. The current trend seems to gravitate towards the use of messaging standards (e.g. DICOM) and integration profiles (e.g. IHE). All integration levels have their advantages and disadvantages.
1. IntroductionWhen people think about PACS integration, they typically seem to relate it to the type of integration that is covered by Integrating the Healthcare Enterprise (IHE) effort [IHE]. Integration means different things to different people.
Some vendors claim that their system is seamlessly integrated, only to find upon closer inspection that they indeed use interface boxes, or conversion software between the systems. Other applications are totally integrated. A claim by a vendor that they support DICOM [NEMA] doesn't necessarily mean that the system can be integrated into a PACS.
This whitepaper discusses the different levels of integration, their advantages and disadvantages, the role of standards, and current trends.
2. Levels of System IntegrationWithin a PACS system one can distinguish six levels of integration (and one level of non-integration):
2.1 Level 1: API Level IntegrationThis type of integration resides on a computer, and links two software applications. It is called API (Application level Programming Interface) level integration because the interface consists of a well-documented software library.
A good example of this interface is a scheduling application/database that talks with a DICOM Toolkit software package, to provide a DICOM Modality Worklist, which contains a schedule for a particular modality. This is the tightest integration level possible.
2.2 Level 2: Procedure-Call IntegrationIn this case, an application on a device, issues a remote procedure call, or a standard command such as a SQL (Structured Query Language) to another application. An example is a PACS workstation, issuing a SQL query, to a PACS archive having an Oracle database, requesting a list of the studies for a particular patient including study date, modality type, and number of images, displayed in a mini-image (postage stamp) directory for a physician.
This is a rather tight integration because the workstation must know the exact database scheme, and supported record in order to be successful. Except for the fact that SQL is an ANSI accredited, standard database language, the user must know a lot of information about the particular software product, requiring intimate knowledge of the vendors� specifications.
2.3 Level 3: Messaging IntegrationThis level of integration is probably most familiar to people. It is achieved by using standard messaging, and protocols between applications, such as DICOM for imaging; or HL7 for patient demographics, orders, and results.
An example is the usage of an HL7 order message from an order entry application to a scheduling system. In principle, vendor A, providing the order entry software, does not need to know anything about the specifics of the scheduling software provided by vendor B, but must know sufficient detail about what type of HL7 message it supports.
Unfortunately, there is a lot of variation in HL7 messaging, often requiring the usage of interface engines to map certain HL7 attributes to those required by the receiver. The good news is that ongoing conformance activities within the HL7 standardization are addressing this, and the new version of HL7 3.0 it is much tighter defined.
DICOM messaging is better defined, and DICOM-compatible devices require a conformance statement, which exactly defines, in a pre-described format, the services, and messaging content.
2.4 Level 4: Integration ProfilesJust supporting a messaging standard is not sufficient: the definition of standard �profiles�, defining a specific subset of the standard is required to enable seamless integration.
An example of this integration is the usage of a DICOM Modality Worklist and Performed Procedure Step to exchange patient demographics, and scheduling information from a scheduling system to a modality such as a CT or MRI, and image management information to the PACS.
The IHE integration profile specifies exactly which attributes, i.e. information should be exchanged, the timing of a service in relationship with other DICOM services, and even mapping between different standards, i.e. DICOM and HL7 messaging.
2.5 Level 5: Context IntegrationThis level is similar to the previous one. One could actually argue that it is the same, because two applications also exchange messaging. However, the applications by themselves are more disjoint than when using standards such as DICOM or HL7.
An example is a physician workstation that runs multiple applications, such as an image viewer, a viewer to display EKGs, and one that displays lab results. The information exchanged among these applications is limited to their context information.
A �context manager� functions as an intermediary, passing any context changes between applications. For example, as soon as a physician switches from Mr. John Smith to Mrs. Jones on the image viewing directory, the application signals the context change to the context manager which passes it to the other application so it also automatically displays the EKG, and lab tests for Mrs. Jones.
As with Messaging Integration, vendor A, who provides the imaging software, does not require knowledge of the lab, or EKG system from Vendor B, but can use the information exchange as defined by the CCOW (Clinical Context Object Working group) standard.
3. Advantages and DisadvantagesAdvantages and Disadvantages of the Different Integration Levels include:
4. ConclusionsWhat is the current trend? As shown in the Figure below, the integration seems to gravitate to the center levels, i.e. towards the messaging and profiling levels (levels 3 and 4), and from physical integration to context integration (level 6 to level 5).
Figure 2. Trends in PACS integration
The push to context integration (level 5) is caused by:
The ultimate goal of integration is to facilitate an Electronic Health Record (EHR) whereby a user can access the complete patient record from a single location, which today is typically a terminal, but tomorrow may be by wireless PDA. This will allow a physician to be able to assess a patient from an integrated view, having access to not only lab tests, but also dental records, diagnostic images, previous reports, etc. This fits the trend that physicians are starting to look at a patient as a whole whereby realizing that an infected tooth can cause a headache, impact the person�s laboratory result, or even affect vision and hearing. The support of standards and the converging of the different integration levels to profiles is critical to make this happen.
5. References[IHE] "IHE Radiology Technical Framework", http://www.ihe.net
[NEMA] "Digital Imaging and Communications in Medicine", http://medical.nema.org
About Ringholm bvRingholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.