John Gomez 7/30/12

HIT Integration Analysis Guide

Over the past several months, one of the biggest questions I have gotten regarding the state of HIT is related to platform and technical integration. Specifically, the debate related to single platform vs. an integrated platform. Typically the question is posed by someone who is not technical and who is concerned about separating vendor hyperbole from reality.

In order to try and shed some light on this topic (which is not a simple one), I have developed what I am tentatively calling the “HIT Integration Analysis Guide,” which I outline below. The purpose of the guide is to provide those analyzing single vs. integrated platforms a means to better understand the true nature and ability of integration. I will provide further light on this shortly, but for right now, let’s create some definitions for what I mean by single vs. integrated.

A “single platform” is one that provides a single set of technologies and database across a set of applications. The common example of this is where you have an EMR which relies on a single database across ED, lab, surgery, OB/GYN, pharmacy, acute, ambulatory, physician and nursing documentation, CPOE, and other venues. In a single platform offering, you have a single technical offering with all data being shared across the different venues of care.

An “integrated platform” is one which uses technical and architectural approaches to “integrate” the various venues of care together. Data and other features may or may not be shared, depending on the level of integration.

To help clarify this a little, let’s consider an analogy.

A store such as Target is a good example of a single platform system. When you shop at a Target (or similar department store), you are able to have most of your needs met (to varying degrees of satisfaction) while never leaving the store. You can get a DVD, clothes, food, household items, and appliances. Regardless of the department in the store, you expect consistent signage, vocabulary, customer service, and support. When you check out, you can use a single method of payment. You have more than likely have saved time by simply dealing with a single vendor. If you need to return an item or have another issue, you can resolve it with a single vendor — the department store.

In contrast to this is the mall (such as the Mall of America), which is representative of the “integrated platform” experience in HIT. In this model, you go to the mall, and although everything is housed in a single location with similar look and feel in common areas, similar operating hours, and other shared services, the experience you have with each vendor in the mall is unique to that vendor. Customer service levels, return policies, product quality, and other attributes are specific to the store you enter within the mall. Although there is some commonality throughout the mall, it ends at the door of the individual store.

Each of these models has its pros and cons. What is important to keep in mind is that the tradeoff is often on depth of service vs. convenience and “good enough” service. For instance, you are apt to get better service regarding an iPad at the Apple store in the mall then you would for the same iPad at Target. Yet the number of people and level of chaos at the Apple store may not make it right for you.

Unlike this analogy, in the world of HIT there are some hidden factors which need to be evaluated when you are deciding the “single platform” vs. “integrated platform.” This bring us to the “Integration Analysis Guide” and the meat of this diatribe. Although there may be other tests, criteria, or scorecards for measuring how well things integrate, I think it is important to have something that is simple to understand, that provides some key and direct questions you can ask your vendor’s executive management, and that removes the complexity and the “marketecture” from your vendor’s presentation.

Single Platform Analysis

The key concern here is related to understanding if the vendor’s system is truly on a single platform and using a single set of technologies. This should not take long to determine. To be honest, the technologies they are using are not as important for this analysis as to whether or not there is a single set of technologies. Here is what I would be asking:

1. Do all your applications run from a single database?
2. Do you have a single technical stack across all of your applications?
3. Do you employ a single programming language across your technical stack?
4. Do you have a single configuration system, help system, HIE system, HL7 sub-system, reporting system, security framework, and user documentation across your platform?

That’s pretty much it. The answer should be a resounding “yes” to each question for a vendor to declare a single platform architecture with single database. Are there are other things to consider? Of course, but to keep this simple, those are the big things to understand.

If the answer is “no” or “we are working on it,” then start asking for percentages of completion. “What percent of your system is on a single security framework?” for instance.

Integrated Platform Analysis

Analyzing the Integrated platform is not as simple as the single platform analysis, but I will do what I can to keep it as simple as possible. For the techies among you, please note that I am deliberately pushing topics related to technical integration to the bottom of the list, because unlike single platforms, the specifics of workflow are more important then what technology or programming language is being utilized. At the end of the day, the goal of embracing an integrated platform by a healthcare system should be that the individual specialties of the system (ED, lab, CPOE, etc.) are much more advanced then that offered by a single platform vendor. Hence we will focus first on workflow and then on technical integration.

Level 0 Integration – The Basics

If we think of this as a set of building blocks, the most basic building block is the exchange of rudimentary information among the various components and application offered by the integrated platform vendor. How this integration occurs is not as important as the fact that it does occur reliably. To understand how well your vendor is doing this, here are some questions to ask and the right answers:

• Question: please list for me the basic data you are sharing among your modules and applications. Answer: problems, allergies, immunizations, history, orders, demographics, family history, billing information, and care team. This is a pretty basic list, and to be honest, most of it is what is required to effectively support HIE systems (regardless of what the government thinks.) Also, much of this can be done via HL7 or other simple data exchange. The point being that if your vendor cannot exchange this information, then regardless of how advanced their technology, you are in for serious workflow challenges.
• Question: what is the latency encountered with sharing data? This is how long it will take for data to show up that is entered in one application in another application. For instance if you update an allergy in the ED system, how long before it shows up in the ambulatory system? Answer: three minutes. I know three minutes sounds like forever in healthcare, right? But it is realistic, and without a major infrastructure investment by you the healthcare provider, you should consider this an adequate answer.
• Question: what occurs if there is an application outage? If we enter an allergy in the ED system and the ambulatory system is down for maintenance, what happens? Answer: the applications will resynchronize after an outage to assure all information is correct. Simply stated, all the data is always up to date give or take three minutes, even after a system outage.
• Question: how does integration support workflow? Answer: any data that is exchanged is treated as if it was entered by a human, and so all workflow remains effective. The goal here is to assure that when data is passed back and forth behind the scenes between systems, it does what is supposed to do. For example if you have a rule in your ambulatory system that if a patient’s body weight drops more then 12 pounds a blood test should be drawn, then that rule should fire even if the data was entered in an ED system and sent to the ambulatory system behind the scenes.

Level I Integration – Content Integration

Assuming your vendor can fully support your needs for Level 0, then you should begin Level I analysis. If the vendor cannot support Level 0, there is no need to consider Level I or continue your analysis of the vendor, if your goal is to hope for a truly integrated platform that is not on a single platform.

Level I is concerned with content integration and how critical it is that information that is heavily relied on by the care team is always available, regardless of how it was entered. To be frank, most vendors can do Level 0, but they cannot do Level 1 unless they are on a single platform. Level I is by far the most difficult part of integration, and frankly, the most critical to get right.

• Question: do you exchange all nursing and physician observations and are they editable? Answer: yes. All nursing and physician observations are exchanged among all systems. You can edit them and update them in any application. Let’s walk through an example. A nurse inputs an observation in a surgery system. That observation should now be in the acute care system. If the nurse using the acute system needs to amend that observation, they should be able to do so without issue. (Editing is something debatable, but the point is the observation should be exchanged and should act as if it was entered by a human.)
• Question: do you exchange all nursing and physician documentation and allow it to be edited? Answer:  yes. All nursing and physician documentation is exchanged among all systems in our platform. You can edit them and update them in any application. Again, the issue here is that you need to share content. A physician sees a patient in their office, makes some notes on the patient, admits the patient, and then later sees them in the hospital. They need to see that note and then continue updating it. Same goes for the nurses’ needs related to documentation.
• Question: is your content ubiquitous throughout your system? Answer:  yes. We provide the same level of content across our system. You want to make sure that all content is the same. You don’t want a situation where one application on the platform supports oncology content and then another application does not or doesn’t support it to the same level.
• Question: do you support the same vocabulary throughout all your applications on your platform? Answer: yes. If you are going to eventually be doing analytics related to performance, cost management, and compliance, you are going to need a single vocabulary shared among all the applications.
• Question: does personalization follow the user? Answer: yes. Things like patient list layout, favorites, order sets, documentation sets,  and personal rules and shortcuts follow the user regardless of the application they are using. Users tend to spend a good deal of time once they get to know a system setting it up to meet their needs. If their personal settings are not available or don’t follow them, you need to know this upfront.

Level II Integration – Infrastructure

Here is where we start to look at the technical integration, but still from a business and user perspective. We are not going to concern ourselves with technical choices, but rather with technical implementation by the vendor. Most of these questions will be similar to those you ask of a single platform vendor.

• Question: do you have a single reporting and analytics system? Answer: yes. Regardless of the application you are using, we provide a means to access all data from a single location for purposes of reporting and analysis. It is important that reports, dashboards, and other analysis can be run across applications. If you are going to truly have a holistic view of your platform, the vendor most provide you with reporting tools that go across all integrated applications.
• Question: do you have single security framework? Answer: yes. You only need to define a single set of user groups and user IDs and you can centrally manage all users. If the vendor does not support this, it will mean that a physician using a system in their office will have a different user ID and password for that system than the one in the hospital. The vendor at a minimum should support a single sign-on solution, but keep in mind most SSO solutions don’t allow for role-specific management and policies across applications.
• Question: do you have a single configuration system? Answer: yes. You can manage all configuration some a single set of tools. Again, if this is not the case, you will need to figure out how you will manage and configure each system on the platform and how you will distribute changes. This becomes much more of an issue as you consider things like content changes, standardized care, reporting, and other workflow items.

Level III – TCO Analysis

This section is not so much a series of questions to the vendor, but more so a series of things to consider when you are evaluating a single vs. integrated platform. Each of these items relates to the impact of costs. How much of an impact and if it is of concern is left to you to determine. What is important is to consider the tradeoffs in depth versus breath that you get from a single platform vendor vs. that of an integrated platform.

• If the vendor doesn’t support a single look and feel across all their applications, will the cost of training different users on multiple systems be an issue? Most integrated platform vendors do not provide a single look and feel across all their applications. This means that a user who has to interact with multiple applications will need to learn different menus, commands, and layouts.
• Will you need to increase staff to manage different applications using different configuration tools if the vendor doesn’t have a single configuration system? If the vendor doesn’t support a single configuration toolset, what impact will that have on your staff in responding to changes and upgrades?
• Does the vendor require different technology for each application? Although we didn’t dive into technical architecture, you should understand if on a per application basis the vendor is using the same technology and database across all their systems. If not, you may have to maintain technical staff with different areas of expertise, different licensing agreements, and even manage different versions of a similar technology.

Although this is a rather lengthy article overall, I tried to keep it as short as practical and provide some focused questions that help you quickly determine what is right for you. And more importantly, to understand if your vendor is able to meet your needs. There is so much more that we could evaluate regarding either side of the coin, but I am rather confident that if you use the information above, you will quickly be able to pinpoint where your vendor stands and if they are able to deliver.

Lastly, yes you can and should analyze the single platform vendor as to if they can truly do all that we asked of the integrated platform vendor. Although chances are that they can, and it is probably harder for an integrated platform vendor to achieve the same level of ability, there is a chance that a single platform vendor made design choices that preclude them from sharing data among their applications in a way that you need. If you feel you need to dive deeper, you can certainly ask all of the “integrated platform” questions of the “single platform” vendor.

I will refrain from providing an opinion here on weather or not you should move in one direction or the other (single vs. integrated). What I will say is that you need to keep in mind that at some point you will need to integrate third-party systems into your ecosystem. Regardless of if you go single or integrated, you do need to consider the openness or closed nature of your vendor offerings.

I do believe there are many myths related to this topic in HIT. It is a topic I will think about exploring and writing about in the future. But for now, let me say that I do not see any one vendor being tremendously more open or closed then any other vendor. In fact, I would say that most HIT vendors offer closed systems, which is unfortunate.

All that aside, I hope that as you continue your journey the information here is somewhat helpful and useful.

John Gomez is CEO of JGo Labs.