Like any critical project, the process of migrating your integration engine requires a strong plan, one that not only documents the project’s scope, technical requirements, dependencies, and timeframe, but supports all of it with a concise checklist.
Your migration project’s scope may be quite narrow, limited only to replacing discontinued products and re-implementing affected interfaces, but it also may be quite wide, especially if your organisation sees the project as an opportunity to improve existing interfaces, deploy new interfaces, and/or consolidate interfaces onto a single platform.
As these scoping decisions are finalised, a clear picture will begin to emerge around how many interfaces should be implemented on the new platform. This number will become the most basic measure of the scope, as well as a reference to help your organisation determine the size and expertise the project requires.
But how do you get to that point? How do you define both the functional and non-functional requirements that will guide your team’s decisions and set them up for success?
First, you have to answer the following questions:
- Which clinical systems need to connect to which other systems?
- In which technical environments will the integration tool run (e.g., hardware, software, operating system, etc.)?
- What type of, and how many, environments are needed to support the organisation’s processes (e.g., development, test, production, etc.)?
- Which existing policies around security, auditing, disaster recovery, and uptime will the new technology need to conform to?
- Which performance metrics are needed in terms of scalability, throughput, and uptime?
- What future considerations need to be taken into account (e.g., emerging healthcare standards such as FHIR, JSON, and REST)?
- What other technologies could be folded into the new engine (e.g., FTP movers, file listeners, email generators, web-service utilities, etc.)?
- What messaging standards do the interfaces need to adhere to?
- What messaging, protocol, and security standards need to be supported?
Second, since your project won’t be executed in a vacuum, you should consider all of the dependencies created by your other projects.
For example, a growing trend in the healthcare industry involves combining engine migration with other system-migration initiatives. Could a dependency like this significantly affect your project?
Absolutely! So to account for it, be sure to roll out your legacy-migration plan first, or concurrently, to eliminate extra interface re-work.
Finally, be sure to develop a planning checklist, like the one below, that summarises all the necessary steps:
- Step 1: Determine the project’s scope—broad, narrow, or in-between—using the number of interfaces to be completed as your guideline
- Step 2: Document key technical requirements
- Step 3: Determine project dependencies
- Step 4: Plan the project completion dates
- Step 5: Establish your resource requirements using the number of interfaces and the project timeline as a guide
While the process of planning your engine’s migration may seem daunting, it doesn’t have to be. With a well-thought-out plan guided by the questions and checklist above and backed by a quality integration engine, you and your team will achieve a successful migration while empowering your organisation to leverage cloud and mobile technologies. You won’t need to rely on costly developers with specific knowledge of specialised algorithmic programming languages, and you’ll eliminate the obligation to support platforms that have been discontinued, are no longer supported, or do not support today’s integration requirements.
Discover a five-step approach to migrating from a legacy engine. Download the white paper now!