A major contributing factor to the conversion of vendors for any HIS or EMR application is the consideration of data integration. System integration is always one area of the project that experiences some compromise and most organizations typically see as a black box. I’d like to take a look at a couple of strategies that can help any organization that is converting to systems that require new HL7 interfaces.
Initially the thought about converting systems is the all around system and user impact. After the initial assessments are complete and the actual work is divided among the applications, integration, server, and other relevant teams, it becomes apparent that integration is highly impacted. The black box mentality of data getting from the source to destination becomes very transparent when the amount of integration man hours bubbles it’s way to the top as one of the highest burn rates on the project.
The critical factors for successful data integration come down to understanding the current state of interface data flow and configuration, as well as the future state of interfaces with the new system. Having well documented interfaces and dataflow eases the process of defining what the future state interfaces will look like. Working with your vendor of choice to understand the data flow and integration options during the purchase process will help define the future of what interfaces are purchased or need to be purchased so that your organization maintains it’s current level of support. The level of support is not only for the peer system owners but also the end users as this helps maintain their confidence in the project and that their data will be where it’s needed, when they need it.
One approach to converting system integration is to work with your new vendor to define messages that look similar to your existing vendor. This approach is possible in some case but not all. This is a great spot to fully utilize your middleware integration engine. By taking the data in from the source and then standardizing it to the existing specification you can save a lot of time and man hours initially. An example of this would be to take your new HL7 2.5 interfaces and turn it back into a 2.2b (HBOCHI) interface specification for utilization by the existing translations and peer systems. The downside to this approach is that as new systems come on-line you should be coding to your new specification, so your have multiple system variants and specifications to maintain. Eventually the enterprise would need to convert all the legacy interfaces over to the new standard as defined by the vendor and integration group. So while there is an initial savings up front, it will be more costly on the back end as you plan individual testing cycles and sessions with each connected system as they are converted.
Another approach is to take all the systems and reconfigure the interfaces to use the new specification as supplied by the vendor. This approach allows for more customization, especially if data is coming over in custom “Z” segments. Utilizing this approach also makes it possible to include all the systems in a single integrated test. The manpower for the conversion is much higher, as you need to meet with each peer system to ensure that the data flow is appropriate and message formats still meet the needs of the users and system.
The rebuild approach can actually be broken down into two other sub categories as well. The first is to maintain the existing messages to the peer systems with no customization allowed, or changes made to they outgoing interface. This requires that the integration team be very knowledgable and look into the source system data so they can correctly map the data without peer involvement. This approach has been proven to get the interfaces about 90% correct on the first pass. The peer system owners will still be involved in integrated testing and may find minor differences in formatting or data structure that need correction.
The second approach is to work with each peer and have dedicated specification meetings and re-design each interface to work for their needs based on new data. This gives them the opportunity to get new data such as allergy information if they didn’t get it before, but have a spot to store it now. This is a much longer process and this requires as higher staff number to meet with all the peers and complete the documents in a timely manner. The cost of the build is also higher as each interface is starting from scratch and rebuilt from the ground up.
Additional consideration should be given to the setting of standards for project coding and documentation as the project kicks off. Regardless of the approach used each enterprise should create a set of standards that they will use for the integration project. The integration team should also be following either an enterprise or group change control process so that code or changes are not lost due to user error or accidental overwriting of configuration files. Having a single point for maintaining the testing site integrity has shown to be very successful in all the cases above. The integration team should also be transparent in their coding and needs. Openly discussing the needs for filters or setup of data routes becomes another high need for the team to be successful with complete system replacement.
Santa Rosa Consulting maintains a staff that can help with integration level needs, from architecture to policy and procedure setting. The integration team is well versed on taking both approaches and has successfully managed multi-hospital implementations of both HIS and EMR replacement projects.