Catholic Health Initiatives, an 87-hospital, 18-state health system, headquartered in Colorado, was taking on a big project.
Its $2 billion OneCare initiative was launched to set up a universal shared electronic health record for patients. As Michael O’Rourke, CHI's senior vice president and CIO, told Healthcare IT News contributor Patty Enrado upon its launch in 2012, data was the lifeblood of the project.
"As we go forward, even though the provision of care is instrumental to the patient, running the business is going to be generated on the intelligence, the information we gather – information about patients, populations, diseases, how they’re being managed, whether they’re improving or not improving, and how we compare to others who are doing the same work so we can get the best practices,” he said.
Critical components of the OneCare project were its enterprise master person index and health information exchange. As such, "We needed an interface engine that could easily interact with both EMPI and CHI HIE," said CHI's Enterprise Integration Architect Linda Wilson.
At that point, CHI had "numerous engines with numerous versions," said Wilson. But with interface engines sunsetting, "operational costs were becoming unreasonable," she said. "We also continue to acquire hospitals that have additional interface engines."
CHI saw an opportunity to simplify, setting up on a single organization-wide platform that could offer economies of scale and be adaptable.
Supporting almost hospitals healthcare facilities over more than a dozen states, "We really needed one environment to manage all of our facilities, with ease and with the ability to interact between multiple engines," said Wilson. "Also monitoring was key. We need the ability to see what is going on within an engine at a glance."
Orion Health's Rhapsody integration engine offered "a clear cut path for a future," she said.
Drew Ivan, Orion's director of business technology, and Alan Haaksma, its director of national accounts, say a good integration engine should have the capability to handle all of an organization's current and future connectivity needs.
Current needs, as complex as they may be, are more or less easy to ascertain. Among the first tasks should be "determining the transport protocols and messaging standards in use by the clinical systems to be interfaced," said Ivan. "Organizations are increasingly seeing multiple generations of standards co-existing in their IT environment. HL7 over TCP/IP has been the standard for hospital integration for many years, but new standards like Web services, IHE and CDA are gaining prominence."
Having a handle on the organization's security and infrastructure requirements is equally important – as is taking into account the preferences of "the style of tool preferred by the team that will be using it."
Getting a handle on organizations' future needs requires a bit more forethought – identifying the integration requirements of new projects; thinking about goals that have remained unmet because of limitations of the current environment.
Integration engines are critical technologies nowadays, as clinicians use multiple, best-of-breed tools to support their work, said Ivan. "As the number and variety of tools in use at an organization increases, there is a corresponding need to share data among these systems, and the integration engine is the hub that ties them all together."
Beyond those exigencies, "one of the major changes in the past few years has been an increased emphasis on sharing data not only within, but also between organizations, driven in part by the meaningful use requirements," said Ivan. "When data starts to go beyond an organization's boundaries, new standards and requirements come into play."
When building for the future, it's critical to do one's homework.
"Integration projects last weeks or months, but once an interface is live, it will be in use for many years," said Haaksma. "Best practices for integration engine implementation involve: methodically defining, implementing, testing, and documenting interfaces. Testing is a particularly important phase of the implementation process, as it is much cheaper to catch a problem during the testing phase than to notice it in production and have to go back and resolve the issue later."
In CHI's case, those lessons seem to have been put to work. The migration is still ongoing and has had "very few bumps along the way," said Wilson. "The main thing I have learned along the way is, don't be afraid to tweak your process or revisit the drawing board. Start out with the easiest interfaces first and then move to more complex."
Asks for lessons similar health systems could follow, Wilson said to "think about what is best for your environment. Just because you have always done something a certain way, doesn't make it the best way. Logistically plan your interfaces and your architecture."
Also, "When choosing naming conventions, think about it from a support point of view," she said. "Think about what would make sense for someone supporting your interfaces and start there."
At CHI, the Rhapsody rollout is already starting to show benefits.
"Ease of use planning out the architecture and the simplicity of the install process allows you to get started in the migration process very quickly," said Wilson. "Training on and learning the coding for Rhapsody interfaces can be done faster than on previous integration engines. This has allowed us to combine the traditional analyst and developer roles into one job that is done by the same person. Migrating code into production is simple; code can be imported and live in two minutes, with very few steps."
ROI comes from several areas, she said.
"By consolidating to one interface engine, we reduce the skill sets that were needed to maintain a variety of engines," said Wilson. "Our analysts are able to develop code and we are becoming a more efficient machine."