10 Questions to Ask When Evaluating an HIE

22

JUNE, 2017

Integration Engines

Most of the people in a healthcare organization went into the field because they wanted to save lives—not because they are experts in technology. That’s where you come in. They want it to “just work.” Your job is to help it do that. But that’s not always as easy as it should be—that’s especially true when it comes to integration engines, which is why we put together 10 questions to ask when evaluating an HIE.

Reviewing and documenting your responses to these questions will go a long way to ensuring you choose the integration engine that’s the right choice for your organization—and that you get it implemented in a way that allows for a smooth flow of data through your system. In fact, when done right, it’ll even seem like the technology “just works.”

1. What is your current corporate interoperability strategy? How will this factor into your decision?

Taking this into account now—even if it means sitting down to establish an interoperability goal—will save you time later that would otherwise be spent re-engineering the system. Deciding later to go back and do things a different way can be very expensive.

It’s easy to get locked into a tactical mindset, looking just at the electronic medical record (EMR) system you use and focusing exclusively on how to create interfaces there. Instead, take the time to evaluate what other systems might benefit from the data that you’re putting into the system. Anytime you exchange data between two systems, that data is now “at play” in the enterprise. So, where else can you send that data? Who else might want it? Who else can add to it?

2. What systems do you have an immediate need to integrate or create an interface between?

Most healthcare organizations at this point have some sort of integration tool in place; if you’re evaluating an HIE as a replacement, start by looking at all of the systems your current tool connects. Note anywhere that the existing interface operates in a way that is less than optimal.

Your first task, once you’ve chosen a new system, will likely be migrating these connections to the new platform. Having your existing interfaces listed out will not only ensure your new system can handle all of your existing systems, but it’ll also save you time when planning your implementation.

3. What additional systems are you likely to consider in the future?

Generally, companies don’t change systems without a reason. If part of your reason for migrating to a new engine is participating in a Health Information Exchange (HIE) or another new-to-you system, you’ll definitely want to look at how any engine you evaluate will work with that new platform.

You’ll also want to look at what outside web services you want to integrate with—systems like the CDC, local, state, and federal departments of health, and other government entities.

4.  What integration engine functionality is important to your organization?

Again, you’ll want to consider both the functionality you’re currently using and any functionality you’d like to gain when changing integration engines. For example, you may be looking for an engine that uses the CDA exchange protocol, or maybe you wanted to use web service connectivities. You should list out the functionality you’re looking for before looking at engines.

5. What data structure are you using now? What will you need in the future?

If your Critical Document Architecture (CDA) and Continuation of Care Document (CCD) are XML-based, it’s important to know whether the HIEs you’re evaluating can support that, whether doing so requires custom JavaScripts—and if it doesn’t support those file types, whether you have the option of using an alternative structure for those document types.

6. What kind of support will you need after implementing the new engine?

While evaluating an HIE, you’ll want to consider both the long-term investment the vendor is making in their platform and what your process will be if you run into a problem with your new system that can’t be solved in-house.

7. Once an HIE has been selected, what naming conventions will you use, best practices, governance systems?

Each of these things should make it into your implementation plan—and each is critical to ensuring the long-term health of your new HIE system.

8. Will you handle the migration in-house or outsource it? Bring in a consultant? Make a new hire?

When evaluating an HIE, you’ll also want to consider your team’s size, skills, and interests. Try to assess how much custom code will need the be written and whether you’ll need custom JavaScripts. Then, look at your team; do they have the skills sets necessary to make those customizations?

Consider how well you understand the underlying architecture of the new system and of your existing system. If you have a system you plan to “set and forget,” then outsourcing may be the answer. Most teams, however, will likely want to be able to handle at least some additional work in the future—making bringing in a consultant who can provide on-the-job training for your team or making a new full-time hire attractive options.

9. How will you get your team trained on the new HIE system? Will you pursue certifications?

Generally, your options here are generic training classes, paying for custom training, or including knowledge-transfer in an agreement with a consulting partner. Determine which choice makes the most sense for your team; this will likely rely heavily on how much experience your team has with the specific engine you’re choosing.

10. What will you do if you wind up with a problem your in-house team can’t solve?

It’s always important to have an escalation plan, but at no time is this more important than when establishing a new integration engine. People’s lives may depend on it—literally. Whether the solution is keeping an expert consultant on retainer, a consulting company on speed dial, or something else will depend on your existing team’s knowledge and experience and your comfort with risk.