A Roadmap to Interoperability | Healthcare Informatics Magazine | Health IT | Information Technology Skip to content Skip to navigation

A Roadmap to Interoperability

March 21, 2008
by George Gides and Pete Rivera
| Reprints
True system interoperability is the Holy Grail that every healthcare enterprise is searching for. Here are some ideas of how to get there.



When you think about your own healthcare or “patient” experience, you will most likely remember filling out multiple forms, entering the same demographic information in each form and having to repeat this process at each ancillary service. This hallmark of healthcare is due to lack of interoperability across the organization’s various systems. In other words, the technology systems do not “talk” to each other.

However, when you think of your experience with other industries, such as banking, you probably do not remember filling out different forms with the same information for each type of account. System interoperability has been an expected experience in most industries for years. Healthcare is just catching up.

Historically, healthcare organizations have used short-term solutions to deal with interoperability issues, such as building interfaces between systems when needed. In addition, since each facility or department may work with a different vendor, there are multiple vendor relationships. This evolves into managing hundreds of interfaces from separate vendors, which becomes a problem.

The chaos associated with managing multiple interfaces and vendors is the antithesis of interoperability’s purpose. The purpose of interoperability is to create a seamless flow of information across the enterprise that is easy to manage, access and use. Interoperability helps improve quality, reduce throughput time, and ultimately saves money through its efficiency. While we in healthcare strive for improved clinical outcomes, the fact is that unless we can connect our systems, continuity and quality of care remains largely dependent on an error-prone paper process and people.

The remedy is to achieve a seamless flow of information across the enterprise — and beyond to other constituents, including community physicians, clinics, suppliers and patients. The interoperability advocate must demonstrate the urgency of the need for the initiative – enough to overcome the barriers inherent in healthcare, including lack of resources, competing priorities, short-term thinking and the endemic “silo” paradigm in which each department plans for its own needs.

To build the business case for interoperability, locate the organization’s “pain points” such as patient safety, patient and physician satisfaction, etc. Then, show how interoperability can help improve the problem. It is imperative that the interoperability initiative is aligned with the organization’s strategic goals. Therefore, the interoperability advocate must be able to answer these questions, to start:

  • How does the organization define itself?
  • What is the organization’s mission?
  • What are the organization’s goals?
  • What are the challenges and pain points it faces? What does the CEO worry about?

Then, define the mission of the interoperability initiative:

  • How can interoperability support the organization’s strategic goals?
  • What are some strategies to accomplish these goals?
  • What are the tactics needed to accomplish each strategy?
  • What activities are involved in each tactic, and, finally,
  • How will each tactic, strategy and goal be measured and assessed as successful?

Here is a case in point. Due to mergers and acquisitions, a client healthcare network grew to 50 sites, including two hospitals, physician practices and community clinics – supported by various best-in-breed IT systems. Fortunately, a strategic plan for interoperability was included in the organization’s mission. So we bypass the buy-in process and go straight to developing and executing the plan.

This client’s answers to the aforementioned organization questions were as follows:

  • How does the organization define itself? We are a large healthcare network serving both an inpatient and an outpatient population at over 50 sites.
  • What is its mission? To provide the best healthcare and the best patient experience possible.
  • What are its goals? To be the best network in the geographic region in which we serve.

It is very easy to get stuck in wanting to be “the best.” But what exactly does that mean? Adjectives need to be clarified, attainable, and measurable. For this organization, “best” meant the best patient experience and the best quality of care.

The next exercise was defining “best patient experience.” For the interoperability initiative, it meant that the patient was “known” by all the departments that were part of the visit(s). It also meant that there were no surprises, delays, misinformation, redundant processes or frustration. It meant that the patient experienced “being taken care of” not only physically, but in regards to logistics such as registration and billing as well.

From a patient’s standpoint, an organization with the same name across the enterprise should have the same information system. Having to repeat information at various check-in points is a perceived sign of lower quality.

With that clarified, the mission of interoperability can be defined:

§ How can interoperability support the organizational goals and mission?

    • By providing an integrated user experience throughout the delivery system so that the patient is “known” by all who see him/her, and information about the patient is easily accessible so as to eliminate delays or extra work by the patient.

As one senior manager said, “We don’t want our patients educating our staff. We want to have patient information at our fingertips.”

  • What are some strategies to accomplish this goal? Here are two examples:
    1. Reduce the number of times a patient has to register.
    2. Reduce the number of systems clinical staff needs to access to obtain needed patient information.
    • What are the tactics needed to accomplish each strategy? First, an inventory of systems and interfaces must be performed. Then, tactics are associated with each strategy: Examples include:

    1a. Interface the system which captures registration data with all other patient-related systems in the network.

    2a. Provide clinical and administrative staff with a single patient view – one electronic record or screen that includes all the patient information, gathered automatically from multiple systems.

    • What activities are involved in each tactic? To begin with, each tactic should not be undertaken in a vacuum as they are very closely related. In other words, if the integrated display system (tactic 2) requires data elements which are not easily extracted from any of the system, its immediate failure is guaranteed. However, for the purpose of analyzing the tactics, they have been broken down as follows:

    1.a.1. Assess all interfaces involved with patient-related systems.

    This process involves “laying out” all of the various systems within a network, as well as the systems which interact with the network even if they are not technically part of it. This graphic display is then used to indicate which types of data are flowing in which direction and to which systems. This graphic should not be confused with a “network diagram” which focuses primarily on network hardware set up and communications. The graphic for this tactic is purely about application functionality and data exchange.

    1.a.2. Determine whether interfaces are the best solutions or if XML/Objects or Web services may serve the purpose more effectively.

    In conjunction with the functional requirements design which details the preferred patient data flow throughout the network, a determination needs to be made on what types of data need to flow between which systems, under which circumstances, and furthermore, via which mechanisms? Put plainly, if a enterprise-wide scheduling system requires certain clinical data elements to be available for viewing prior to a user scheduling a patient for an appointment, where will that data come from and does it need to be stored within the scheduling application or can it simply be displayed. Once questions like this are answered for each potential data transfer process, the actual mechanism by which the data is shared can be determined, and negotiated if need be. Granted, the outcome of this series of queries will be limited by each vendor’s ability to transfer data in and out of its system however, with the advent of Web-service and XML technologies, including but not limited to HL7 v3.0 many more options are available for clients which simply were not there even as recently as two years ago.

    1.a.3 Pinpoint dataflow “overlap

    Because it is rare that a HIS network’s interoperability is pre-planned prior to its installation, organizations often end up with multiple systems doing essentially the same thing for various departments. For example, registration may not only occur at the inpatient data collection unit, but may also occur at the doctor’s office that referred the patient to the hospital in the first place. Additionally, if the radiology department is politically independent, it may insist on re-registration to collect various “clinical” data elements that the “generic” registration system does not capture. The end result of all of this “common data-type” collection may be an interface overlap. This isn’t necessarily a bad thing if each component system adds to the core value of the patient experience as well as to the organization’s ability to collect payment on the back end however, as departments and physician organizations are added it is often preferable from an initial financial investment standpoint to simply “add” the systems which these new departments/physician organizations already use than it is to re-train them on the existing software. When this situation happens, it is often years, if ever, that an analysis of dataflow overlap is completed.

    1.a.4. Determine Interoperability Product Requirements.

    Once the dataflow requirements have been determined, the next step is to determine which products currently in use may be re-used or modified to meet the new strategic initiative and which new products are required to do so. In other words, if existing outbound ADT interfaces from you’re H.I.S. to the clinics only need a simple and cost-effective revision then a plan needs to be made to code, test and release the revision. If it is determined that a piece of interoperability software is missing, then a plan needs to be put into place to purchase and install the software as part of the strategic initiative.

    1.a.5. Remove any unnecessary interfaces.

    One very nice side-effect of this process is that often “old” interfaces are re-discovered. Most of these older interfaces do not meet any current industry standard and may not even have been in use for many years. However, it is often found that “maintenance” fees on these old interfaces are still being paid. So this may factor into your ROI.

    2.a.1. Assess all systems which hold patient information.

    2.a.2. Assess the most appropriate integration platform for the organization which will provide a single view from multiple systems.

    2.a.3. Design the view, possibly customized for various departments

    2.a.4. Install the integration platform.

    2.a.4. Train users.

    • How will each tactic, strategy and goal be measured and assessed as successful?

    1. Measurement: The reduction in the number of times a patient could potentially need to register across the enterprise.

    2. Measurement: The reduction in number of systems clinicians in each department need to access to obtain all needed patient information.

    This is not to say that the work of actually creating the interface structure is simple. It’s not. The IT technician must examine each integration point and determine what information is being exchanged, how it is exchanged, what system “handshakes” are taking place and the level of matching criteria being used to import or export the data. There is a balancing act between having too much matching criteria and not having enough to properly match the record. You can create a weighted ranking system for each data element and determine the level of confidence that the record would match automatically or what would be placed in an error log for manual intervention.

    Also, the IT technician needs to consider the user interface across the enterprise, or the “visual interoperability.” For example, if a physician works in multiple departments or facilities, it helps to have the user interface look similar. Use of the same color schemes and consistent placement of navigation controls on the user interface can enhance usability considerably, which, in turn, improves physician satisfaction. It also helps reduce the information errors that would cause records not to match across interfaces and resources expended in the pain-staking process of merging records.

    Interoperability improves healthcare’s “vital signs”: patient care, patient experience, physician and staff satisfaction, quality, continuum of care and competitive advantage. It is worth the time and effort to develop and implement a strategic plan for a seamless flow of information. Your organization’s future may depend on it.

    George Gides and Pete Rivera are senior consultants at Hayes Management Consulting in Newton, Mass.


    The Health IT Summits gather 250+ healthcare leaders in cities across the U.S. to present important new insights, collaborate on ideas, and to have a little fun - Find a Summit Near You!


    /article/roadmap-interoperability-0

    See more on

    betebet sohbet hattı betebet bahis siteleringsbahis