Creating interoperable IT systems in healthcare

C.W. Corbijn van Willenswaard
Interoperability Architect
Philips Electronics India Limited

Before creating interoperable IT systems in healthcare, it is important to understand the meaning of interoperability. ‘Conceptual interoperability’ and ‘Data Information Knowledge Wisdom (DIKW) Pyramid’ are two terms used in a more generic context to indicate the exchange of data/information and its usage between different systems. DIKW Pyramid provides the basic difference between data and information.1 Data is just a stream of bytes that is exchanged. It is turned into information by a system through addition of knowledge to the data.

Institute for Electrical and Electronics Engineering (IEEE) defines interoperability as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged.”2 According to the definition two systems just need to be able to use the data that is exchanged and turn it into information in their own functional context. This means interoperability depends on the functionality of the systems involved.

For example, Figure 1 shows the way IEEE interoperability definition looks in a standard web browser:

Figure 1: Information displayed in a standard web browser

When the same content is taken in the editor it appears like:

Figure 2: Information displayed in a text editor

Here, the text editor displays all the data including the text highlighting and the web browser turns it into information and displays it in a readable format. As many people cannot understand the full data with highlighting provided by the text editor, it shows the HTML structure only on request.

This everyday life example shows that information taken from internet requires systems to be interoperable. Given the dominance of a few big players in this area, it becomes relatively easy to validate web pages. However, considering the number of vendors involved and the larger variety of data in the healthcare environment, it almost seems impossible to handle interoperability in this sector.

Presence of different systems within a hospital and the fact that these very often are provided by different vendors makes it clear that the creation of interoperable systems is not a simple task. However, not all systems need to be interoperable and the expected functionality can also be different. The basic function of interoperability would be to display data in a correct, readable, and meaningful way on the target system.

For imaging systems, this would typically mean viewing the acquired images as on the acquisition station. A typical example of two systems not being interoperable for this is shown in Figure 3 and Figure 4. While the first image is the original one, the second is the one seen at the receiving system when all the data necessary for displaying it is not utilized. Depending on certain parameters, the result can vary from being almost completely black to completely white. Due to the changes in gray level, viewing and correct interpretation of the image may not be possible. This means, for basic viewing capabilities of medical images it is necessary to process a part of the dataset. Further processing of the dataset will require two systems to function at a higher level and indicate a next step in interoperability.

In this context, the image is part of a set acquired to determine the brain functionality. To create a corresponding functional map of the brain, the application needs more information from the dataset. The application must be able to recognize that this is a time series created to measure brain activity. Also, the data describing the time sequence and the way the brain was activated is needed. This means interpretation of the data, is again more complex. The result is however, an image that reveals more information to the user (Figure 5).

Figure 3:
Original gray-scale image
Figure 4:
Transferred gray-scale image
Figure 5:
Processed image

Courtesy: Philips Electronics India Limited

When it comes to products, it is very important to decide on the means and extent to which interoperability can be supported because for many products interoperability is just one of the supporting features. Interoperability for data creating systems means focus on the external environment, in addition to the core activity of creating images. For receiving systems (archives and processing workstations), this is more a part of the core functionality as these images are part of the inputs that needs to be processed and interpreted by a clinician for diagnosis. As the integration of hospital systems is increasing, extension of system borders is gaining importance. Normally, development of a feature is dependent only on the developing organization; however, this is not the case for the interoperability feature.

Interoperability problem is neither new nor specific to healthcare. It is normally handled by standardizing interfaces. Standard interfaces used for the exchange of data will reduce the effort of implementation and validation by limiting the number of choices a vendor can make. With the use of standardized interfaces validation can focus on the implementation of the standard and will be independent of the systems using the data. There will however, still be the issue of different vendors having different interpretations of the standard that makes validation not straightforward. This is applicable for all standardized interfaces, but the wide range of products in healthcare results in a large variety of data using the interfaces. Hence, testing interoperability with a set of real products will be necessary.

Achieving Interoperability
There are two major mechanisms used to achieve interoperable IT systems in healthcare:
standardization of interfaces and content, and validation of the systems as early and broadly as possible.

Standardization is an important requirement to achieve interoperability at a reasonable expense and effort. Interoperability can be achieved using globally defined standards. The three major standards used in the healthcare environment are:

  • Health Level Seven International (HL7): Having members in over 55 countries, HL7 focuses on creating standards for the exchange, management and integration of electronic healthcare information.3
  • Digital Imaging and Communication in Medicine (DICOM): It is an international standard for the storage and exchange of medical images and related information. It specifies the format for exchanging images and quality for its clinical utilization.4 With many global companies, users and general organizations associated with DICOM, it is possible to create a standard that is defined by producers and users.
  • Integrating the Healthcare Enterprise (IHE): It is a consortium of healthcare industry and professionals to improve the way systems share information. While HL7 and DICOM supply the means (connectivity), IHE describes the workflows (interoperability) in a hospital.5 By describing the workflows it bridges the gap between the generic descriptions in the HL7 and DICOM standard and the real-time usage. IHE is focusing on the cooperation of different products by defining the functions and data used by the products in a specific workflow. These hospital workflows are described in profiles. Each profile is describing a specific workflow in the hospital and limits the options available in the HL7 and DICOM standard. Thus, IHE specifies a method to establish interoperability between different IT systems in a hospital based on available standards.

Below figure represents different standards used in a hospital for achieving interoperability among various systems.

Figure 6: Different standards used in a hospital

Participating in these three standardization organizations is very important for a vendor to achieve interoperability of their products. By participating in different workgroups of these organizations vendors can:

  • Contribute to the definition of standards
  • Keep standards in-line with their products. New developments in standards will mostly be evolutionary and the resultant changes can most likely be implemented in an easy way. It can, however, take a lot of effort as some updates are extensions to the standards.
  • Get early information that can influence their roadmaps and products
  • Discussions in the work groups reveal different ways of interpreting a standard, which can be accepted or could need a description to make clear which one to use. By taking care of multiple interpretations before releasing the product, the vendor can avoid customer annoyance and the need to fix problems in the field.

Products will be validated against the applicable interoperability claims, which can be:

  • HL7 Claim
  • DICOM Conformance Statement
  • IHE Integration Statement

While IHE Integration Statement provides an overview of the IHE profiles supported by the system, HL7 claim and the DICOM conformance statement are documents describing the capabilities of the system. The interfaces used by the system are described in a standard way by HL7 and DICOM. Since most interfaces have different functional options, the choices made for these optional elements are also described.

Additionally, there is a description of the data model and data elements. Currently, most of the systems support either HL7 and/or DICOM (only systems that are working at both the hospital and the imaging level have to support both).

All three claims are made and validated by the vendor. For the IHE statement, vendors can validate their product against those of other vendors in accordance with specific IHE profiles at ‘IHE Connectathon Test Sessions’, an event hosted by IHE at several places in the world, throughout the year. Major events are those of the USA, Europe, and Asia. The set of vendors participating in these events vary per region as most of the events witness participation of local vendors and as such rotating the participation of the different events is very beneficial for many global vendors. Thousands of validation tests will be performed at the event and many errors will be identified, which are very often solved during the event itself to pass the IHE profile.6
The main advantage of this event is that it provides an opportunity to validate the products’ interoperability against systems it will face in the field before releasing them into the market. From a business point of view this will have following benefits:

  • High customer satisfaction as fewer defects reach the customer. If the defects reach the hospital, then the effect is directly visible through lost hours or extra hours for workarounds.
  • Save a lot of time and money spent on fixing the issues at customer site. Solving defects at the event is easier as involved systems and engineering knowledge are readily available. This could be very difficult or almost impossible to arrange when the products are released and the problem shows up at the customer’s place.

Figure 77 provides an overview on the cost of defect fixing and thus, demonstrates the advantages of early validation

Figure 7: Cost of fixing defects at various stages

With the cost of fixing a defect expected to increase by more than 150 times at the operations phase, as shown in the above graph, it is beneficial to identify the defects prior to the product release by participating in the ‘IHE Connectathon’ series.

Last year a Testathon was organized in Bangalore India as a trial as there is no Connectathon yet in India. Although smaller than the formal Connectathon, it showed that it is a very useful mechanism as most of the vendors found issues in their interoperability interfaces. With many large companies having development processes in India, Testathon might further bring down cost as traveling is minimized. Commenting on the role of Testathon in improving the overall productivity of the healthcare industry, Mr. A Vijayarajan, CEO Clintics & President HIMSS India said that “Interoperability not only streamlines workflow and enhances quality of care but improves the overall productivity in the hospital. This is an important first step needed by all in the Healthcare Ecosystem.” 8

As interoperability is still an evolving feature for most of the systems, standards may change with new insights. The main reason for the evolving interoperability features is that most of the products are still in the transition phase from standalone systems to being part of a fully integrated environment and requires a change in mentality for product developers. In a hospital, product is no longer the main system; it is just a part of the larger system called hospital workflow. So the hospital workflow system could be described as the combination of different products working seamlessly together.

Most of the products are capable of sending all the data they contain, but the hospital workflow might not be optimal if it cannot use all the available data as information. Hence, there is a need to look at the overall hospital workflow and figure out which information is missing. Standardization will need to make sure that this can be done with minimum impact for the different products.

Questions which pop up during this process are:

  • Can a generic pattern be identified for the workflows that need to be standardized?
  • Is the workflow pattern the same for all hospitals/countries and if yes, can it be used to mitigate the differences by making changes in the configuration of systems?
  • What does it take to fit products into the hospital’s workflows?
  • What does it take for the products in a workflow to use and supply the extra information needed for smooth interoperability?
  • What happens when the data is sent to a picture archiving and communication system (PACS) and then forwarded to a viewing/processing station?

The future course of interoperability is an interesting and challenging subject to discuss. With so many companies involved, there will be different views and it will take several years to develop a standard. The time to implement the standards in hospitals will be even longer as cost and safety do not allow changes to occur overnight. It is a very big challenge to create interoperable systems in healthcare, taking into account factors like cost cuts, quality improvement, and increased number of patients.


1. Rowley J. The wisdom hierarchy: representations of the DIKW hierarchy. JIS. 2007;33:163-180.
2. Federal Communications Commission. Tech Topic 1: Interoperability. Public Safety and Homeland Security Bureau. Accessed February 01, 2013.
3. Health Level Seven International. HL7 Backgrounder Brief. Health Level Seven International. Accessed February 01, 2013.
4. National Electrical Manufacturers Association (NEMA). About DICOM. DICOM Digital Imaging and Communications in Medicine. Accessed February 01, 2013.
5. IHE International. Welcome to Integrating the Healthcare Enterprise. IHE International. Accessed February 04, 2013.
6. IHE International. IHE Connectathons: A Unique Testing Opportunity. IHE International. Accessed February 04, 2013.
7. Boehm BW. Software Engineering Economics. Upper Saddle River, NJ: Prentice-Hall; 1989.
8. AmbalSoft InfoTech Private Ltd. TESTATHON: The First Healthcare Interoperability Testing Event in India. AmbalSoft InfoTech Private Ltd. Accessed February 04, 2013.

Comments are closed.

mhealth + Telehealth World 2013

mhealth + Telehealth World 2013