Interface Conversion Projects: 10 or More Steps
If you’ve ever worked on converting from a legacy interface engine to a new one, you know one thing: this is one complex project. With a lot of moving parts. You’re easily facing 10 or more different workflow steps — per interface. The workflow can start with simply backing up the legacy production interface and can end with testing and deploying the new interface. But between Step 1 and 10, there is a lot of room for error and rework.
Documenting the legacy interface
After backup, you document the legacy interface. And that can be a chore. Some engine vendors simply state, “Open a text file.” Then you’re supposed to get a copy of the application specification from the application vendor (just bear in mind that the spec isn’t always available) and start reading to get a sense of which messages and content types are involved.
Was the spec fully implemented? No
Of course, you’ll also be aware that more often than not, the spec was either not fully implemented in the legacy interface or it was customized during implementation. So, with your text file still open and the specification on the screen, you have to go to the schema or definition in the old engine and start noting transformation rules, message structure, and message content including code sets.
Implement the new interface via trial and error
Once you’ve documented your interface, you’re supposed to re-read your notes. You then hunt through their HL7 standard library, and pick a schema that’s kind of close to your message structure. You start your coding based on this library schema.
Add more code and stir
Then you add transformations, routing, transport protocols.
And you’re meant to spend the next few days and weeks first, tweaking the schema, and second, coding until….
Then test
Finally you get to test. The testing is iterative. You test so you can check if your new interface comes close to matching the legacy interface.
What does this get you?
For all this work, you end up with:
- Incomplete requirements. Incomplete documentation. And no way to really compare your legacy interface with the new one.
- A lot of trial and error – especially since this whole process is manual. And that means you can end up introducing new errors with the click of a button. That’s the real slowdown.
There is a better way: automate conversions
With Caristix technology, you can automate and streamline this entire process. The technology that lets you do this is called a connector.
A connector lets you pull messages and schemas directly from the legacy interface engine into the Caristix platform, where you can generate a specification (what we call a profile) automatically. Some Caristix connectors can also extract the transformation and mapping code.
Using a connector for your new interface engine, you can generate a schema to import directly into the engine, saving multiple trial-and-error cycles.
The connector and platform also let you automate your requirements gathering. Learn more about HL7 requirements in this post.
As an add-on to Caristix Workgroup and other Caristix products, this technology can save an analyst hours during a conversion project and streamline the entire process. An IDN organization with 80 hospitals used Caristix connector technology on a major 1000+ interface conversion project. They saved 18 hours per interface – which multiplied out to millions in project savings. Interface conversion projects and connectors are an effective solution to the trial-and-error approach.
Learn more about Caristix connectors, including the engines we support. And contact us for a demo.