New interface selection: a big decision
Is your team selecting a new interface engine? If so, you’re in good company. With DataGate/eGate and eBiz at the end-of-life mark, many hospitals and health systems are faced with major conversion and migration decisions. The engines they have in place now are responsible for the flow and orchestration of financial, administrative, and clinical data. They can’t afford to disrupt their current capabilities. And the smartest organizations are working to expand their interoperability.
This leaves hospitals and IDNs with some major decisions. Which vendor should you go with? What should the selection committee look for? When you implement, what should you prioritize? The wrong decision can have a devastating impact on interoperability and how data flows – short-term and long-term.
Interface engine selection guidance
Which is why there is a lot of guidance out there on how to pick a new engine. One of the better resources we’ve come across (and it’s vendor-neutral) is a 37-page white paper from OTB Solutions, a consulting firm. The paper pays a lot of attention not just to technical requirements but also business requirements. And it offers great advice on communicating the selection and the accompanying change management. Download the OTB Solutions white paper on interface engine selection.
High risk: interface migration
One area we see a need to expand on: the actual migration process. It’s a risky process. And depending on your needs, not all engine vendors are created equal here. You have to pay attention to documenting your needs and your requirements.
How do you reduce risk and cost?
When you’re purchasing a new interface engine, the biggest investment isn’t the engine software licensing or your incremental hardware costs. Your biggest line items will be the development and implementation time – labor costs. Look for solutions that will reduce complexity and development risk, and you’ll automatically impact cost.
Just as Agile methodologies have reduced project risk in software development, interface lifecycle management can reduce risk with interface development. And it starts with better requirements. Read this article on HL7 requirements to learn more.
Also, consider purpose-built software such as connectors and converters. You can automate the migration process by pulling messages and schemas directly from the legacy engine, and generate requirements, including specifications for new development easily. Learn more about interface conversion projects and connectors.
What are some ideas you’ve successfully used to overcome migration risk? Let us know in the comments.