HIMSS: Integrating systems? Plan carefully
ORLANDO, Fla.--System integration may not be a simple process, but it can be accomplished using a project management approach, according to Susan M. Houston, RN-BC, and Ryan D. Kennedy, BS, of the National Institutes of Health Clinical Center in Bethesda, Md. Houston and Kennedy, who work in the center’s department of clinical research informatics, made their case to a capacity audience at HIMSS11 Feb. 21.
The session, titled “Managing Integration Projects for Project Managers,” defined types of integration and explained how a standard project management process can launch system integration. The initiation stage of planning begins with a basic question, said Kennedy: “Is a complete system integration worth it?”
If the answer is yes, the organization must look carefully at formatting options, the limitations of the technology and end user needs. It also must consider its business and functional requirements as well.
This will take teamwork, whether a company decides to buy an interface engine or build one. “You want someone on your team with an interface background,” said Kennedy. “You many have your HIS [hospital information system] or ancillary application, and the vendor of that system may be able to provide some interface resources, but you really need someone in-house who knows this as well, so you have ownership of the data.”
Other team members might include a network expert, if it’s necessary to “punch holes in the firewall” to get data from one system to another, or system administrators, database administrators and testing personnel. “Even if you’re just sending information between two systems, there still may be a process change for your end users,” he added.
Likewise, it’s important to have clearly defined requirements. What kind of interface are you going to be implementing? How often do you need these messages to be sent in real time--hourly, daily? These are basic requirements you need to define to figure out how you’re going to proceed with the rest of the project.
Once you know how you’re going to proceed, be ready to change gracefully via scope management. “You want to have a clear, defined process for reviewing changes to your scope. As we go through a project, maybe we need to create a new result … a clearly defined scope and changes to that have a process associated with them,” he said.
Workflow analysis is equally critical because the impact on the end user is often uncertain.
It’s important to understand data flow as well, said Houston. “We have a number of data warehouses. If you’re sending data to your HIS, how is that going to impact your warehouse? It’s a data feed, but it’s another thread that needs to be examined.”
When development is done, the project manager should analyze where testing will occur. Multiple things need to be tested because typically, data doesn’t move from one system to the other without some sort of changes to the applications. “You may need to have changes to an order form, security or where documentation will display appropriately,” Houston said. These could be changes at either the source or destination, and those each need to be tested as well.
Begin planning early, and rehearse before going live, she said. Rehearsal is the time to make mistakes and refine before the point of no return and do lessons learned afterward. “Testing at this point is validating what should be in production: You’ve already been through the testing phase.”
After go-live, the transition to a support function should include a thorough transfer of knowledge to the support team, as well as monitoring logs and threads to identify issues before the user complains. Users need to know they can call a help desk if they encounter a problem. “A strong configuration management process helps manage changes after you go live,” she said.
Houston concluded with this advice for integration project managers:
The session, titled “Managing Integration Projects for Project Managers,” defined types of integration and explained how a standard project management process can launch system integration. The initiation stage of planning begins with a basic question, said Kennedy: “Is a complete system integration worth it?”
If the answer is yes, the organization must look carefully at formatting options, the limitations of the technology and end user needs. It also must consider its business and functional requirements as well.
This will take teamwork, whether a company decides to buy an interface engine or build one. “You want someone on your team with an interface background,” said Kennedy. “You many have your HIS [hospital information system] or ancillary application, and the vendor of that system may be able to provide some interface resources, but you really need someone in-house who knows this as well, so you have ownership of the data.”
Other team members might include a network expert, if it’s necessary to “punch holes in the firewall” to get data from one system to another, or system administrators, database administrators and testing personnel. “Even if you’re just sending information between two systems, there still may be a process change for your end users,” he added.
Likewise, it’s important to have clearly defined requirements. What kind of interface are you going to be implementing? How often do you need these messages to be sent in real time--hourly, daily? These are basic requirements you need to define to figure out how you’re going to proceed with the rest of the project.
Once you know how you’re going to proceed, be ready to change gracefully via scope management. “You want to have a clear, defined process for reviewing changes to your scope. As we go through a project, maybe we need to create a new result … a clearly defined scope and changes to that have a process associated with them,” he said.
Workflow analysis is equally critical because the impact on the end user is often uncertain.
It’s important to understand data flow as well, said Houston. “We have a number of data warehouses. If you’re sending data to your HIS, how is that going to impact your warehouse? It’s a data feed, but it’s another thread that needs to be examined.”
When development is done, the project manager should analyze where testing will occur. Multiple things need to be tested because typically, data doesn’t move from one system to the other without some sort of changes to the applications. “You may need to have changes to an order form, security or where documentation will display appropriately,” Houston said. These could be changes at either the source or destination, and those each need to be tested as well.
Begin planning early, and rehearse before going live, she said. Rehearsal is the time to make mistakes and refine before the point of no return and do lessons learned afterward. “Testing at this point is validating what should be in production: You’ve already been through the testing phase.”
After go-live, the transition to a support function should include a thorough transfer of knowledge to the support team, as well as monitoring logs and threads to identify issues before the user complains. Users need to know they can call a help desk if they encounter a problem. “A strong configuration management process helps manage changes after you go live,” she said.
Houston concluded with this advice for integration project managers:
- Understand the vendor’s capabilities.
- Ensure good documentation of all integration requirements.
- Use a systematic change management process.
- Ensure stringent testing and involve users.
- Ensure proper knowledge transfer for support.