Recently, we had the opportunity to gain insights from three customers regarding their participation in HIEs. Each organization is quite different, both in types of clinical systems they are using and in the way each is participating. The following perspectives are offered from:
- Michael Mover, CIO, Riverview Hospital
- Kim Kiefer, Application Development Supervisor, Hendricks Regional Health
- Marty Buening, Director of Information Technology, Northwest Radiology Network
Which Health Information Exchanges (HIEs) are you currently involved with?
Mover: Indiana Health Information Exchange (IHIE)
Kiefer: Indiana Health Information Exchange (IHIE)
Buening: Indiana Network for Patient Care (INPC)
What were your initial activities and steps in planning for your participation in the information exchange? Were the initial activities different between the various HIEs?
Mover: Our initial activities involved discussions and the exchange of specifications, benefits, usage of data, etc. Currently, we are only involved in one HIE.
Kiefer: Some of our planning was mandated by state requirements. Other decisions were by choice. Our ultimate goal was to help get information to doctor practices.
Buening: INPC came to us and asked us to participate. We are a radiology practice so our role and value in an HIE is a little different than a hospital. I think we tend to add more value to an HIE than we get. Initial activities included identifying gaps between the needs of INPC and the data coming from our RIS.
What type of workflow discussions did you have internally, and with the HIE, to get the data flow design right?
Mover: IHIE had a lot of what was needed already worked out. We made some minor changes to the process but, since there were already a lot of other customers involved in the project, they had good suggestions for us.
Kiefer: The IHIE had HL7 specifications that we worked from.
Buening: INPC hadn’t worked with many radiology or lab providers before we connected. A big part of INPC’s process was the admission of the patient, but being an outpatient provider we don’t admit patients. Therefore, INPC had to re-engineer some parts of their system to work off of appointment scheduled date and time in order for us to utilize the system effectively.
What was the role of technology within your organization after the workflow discussions? What new capabilities did you need? What existing capabilities did you leverage?
Mover: Corepoint Integration Engine was critical in our success. It enabled us to quickly meet their specification and send data to the HIE. Having a robust interface engine that we could leverage was the number one factor for us.
Kiefer: Our role was developing the interface to get current data to the organization. We leveraged our existing interface engine along with HL7 feeds coming out of MEDITECH. We learned that with all the systems we were being asked to communicate with things like the ADT feed from MEDITECH needing to be everything they could send us. This way we can include or strip off what various systems do or do not need. Initially we leveraged only HL7 feeds and later we included other input methods to supply information to other vendors.
Buening: We were already using Corepoint Integration Engine to receive orders and send results with a number of organizations, so for INPC we just needed to establish a VPN and create a couple more connections and action lists in the engine.
What key functions does Corepoint Integration Engine offer in meeting the HIE connectivity and data exchange requirements?
Mover: It allowed us to quickly meet their specifications with little-to-no cost for us, because the work was done internally. This is the value of having an interface engine like Corepoint.
Kiefer: Corepoint has allowed us to customize and provide current data to the HIE as it is available based on their needs. It has also given us the power to turn out interfaces extremely fast due to the simplicity of the system.
Buening: Our integration engine receives a lot of data from our RIS. Within the engine we are able to parse and reformat that data such that it meets INPC’s requirements and we only send what is needed and necessary.
What type of patient data is being exchanged through the HIE today? Any patient summary records (CCD or CCR)? What do you see being added in the near future?
Mover: We send demographics, lab results and dictated results. These can be turned into a CCD, and we suspect we may send them in a CCD form in the future. We may also look for methods to link images in the future.
Kiefer: We currently send ADTs, Radiology Reports, Lab Results, and Transcription Reports. We are not currently looking at adding more information just continuing to better the feeds we currently have established.
What overall value does Corepoint Integration Engine deliver in participating in an HIE?
Mover: The interface engine was integral in keeping the cost for entry down, and it allows us to quickly respond to changes needed as new types of data are collected for new state and federal initiatives.
Kiefer: Corepoint allows us to leverage a MEDITECH feed for each type of information and make changes based on the needs of the receiver. We do not need to contact a third party for changes required by our HIE. Since we have the ability to implement changes and monitor the connection to our HIE, we are able to provide them with most current valid data.
Buening: The integration engine allowed us to quickly connect with INPC and allows us to adjust to their needs going forward. We can do all the work in house saving money and time.
What advice would you give other organizations who are considering or pursuing a connection into an HIE?
Mover: Get an interface engine or expect to spend a lot of money on individual interfaces. Having one integration engine to consolidate and send out your data is a huge benefit instead of having multiple interfaces from lab, radiology and your registration system.
Kiefer: Establish a good relationship with a contact person. Have open and clear communications to ensure what is required is understood on both sides before code is ever started. This will save you rework and frustrations. Have a VPN setup for secure delivery and know IP/ports and addresses on both sides prior to starting. It is also helpful to have a test site as well as a production site. In the event that you need to make changes, you can get a feed with new information to validate before moving to production.
Finally, there are times that our connection is interrupted and stops whether that is something on our end or theirs, so having a way to monitor the connection to ensure they are receiving up to date information is always a good idea.
Buening: Know your data and workflow, learn the needs and requirements of the HIE and identify any functional gaps as early in the process as possible. If you don’t have an interface engine already, use the opportunity of connecting to an HIE as leverage to get one. It will be well worth it.
riverview hosptial case study (pdf): provided independence from application vendors and improved workflow by connecting and exchanging patient data between their keane his and outpatient clinic applications and offsite partners.
hendricks regional health case study (pdf): replaced their interface engine with one capable of efficiently integrating enterprise-wide with meditech, offering robust features to build and deploy interfaces quickly and to proactively monitor connections, in real-time
Print or Download a PDF of this HIE Discussion.