Blog

Rhapsody Health Solutions Team

Hugh Chatham Memorial: A leading example of connected CPSI facility

Accolades keep piling up for Hugh Chatham Memorial Hospital, located in Elkin, NC. First the IT department was honored by Healthcare IT News in 2011 as the #1-ranked small hospital in their annual Best Hospital IT Departments list, an accomplishment they repeated in 2012. This year, the hospital was named a “Most Wired Hospital” by Hospitals and Health Networks magazine, alongside hospitals and health systems of all sizes.

Their success should come as no surprise because CIO Lee Powe emphasizes a family atmosphere that encourages both professional and personal development among their 11-person IT team. Lee was quoted in the Healthcare IT News article:

“We all try to take into consideration each other’s likes and dislikes and take the time to listen and learn about each other as individuals, not just technicians. Communication and conflict resolution are always being taught and worked on. The ability to change a [manual] process that has been around forever into a digital format without hurt feelings and making things personal is always being improved upon. As a result, morale is high because of the genuine rapport and positive attitude of everyone on the staff.”

I had the opportunity to speak with Josh Griswell, interface manager at Hugh Chatham Memorial Hospital, right before Corepoint Connect kicked off in October. Josh is in charge with leading the hospital’s integration and interoperability activities, namely overseeing the interfaces between the hospital’s CPSI system and their 21 physician clinics and several internal applications that produce data that must be gathered, compiled and integrated for caregivers’ use.

Just one note about Josh before the Q&A: prior to becoming an interface analyst at Hugh Chatham in 2012, he worked as a hardware tech and had no previous experience working in HL7 or connecting health tech applications. He’s a “one man show” at Hugh Chatham when it comes to creating interfaces in Corepoint Integration Engine. He has managed to help his department create a modern data infrastructure without a multi-million dollar budget and help from experienced HL7 programmers. Nice work, Josh!

One of the more interesting workflows Josh helped improve at Hugh Chatham was integrating vital signs from their Philips technology in use in patient care by utilizing Corepoint Integration Engine and Microsoft SQL servers. Be sure and read the full Q&A beneath this short video interview with Josh.

How are you using SQL databases for vital signs?

Josh: Hospitals produce an inordinate amount of vital signs throughout the day, even at our hospital. We have 81 beds. To illustrate just how many vital signs are generated, they probably account for 50% of our Corepoint message load every day – and that’s on a single interface.

Every patient in the hospital gets their vitals measured constantly. Everyone that’s on telemetry gets seven or eight messages all the time. CPSI, our EHR, can’t handle that much data because their server will crash. Plus, the messages generated by Philips don’t make any sense – Philips does some really weird things in its system. It generates seven or eight messages that might have pulse-ox, or heart rate, or pulse, or blood pressure, and these will be separate messages.

We take all of those messages and use Corepoint to put them into SQL to help make sense of them. Corepoint pulls it back out as a single message that can be incorporated into CPSI and make sense to the caregivers. That consolidated message is updated in the system every 90 seconds.

Vital sign processing is actually one of the driving reasons we partnered with Corepoint to begin with, because we had to get those vital signs into a digital format. Before Corepoint, you’d just have someone looking at the Philips system for the vitals. I think the nurses would take that data and manually put it into CPSI, randomly.

That all ended as soon as we created the interface to automatically send the data every five minutes. Now, nurses get to spend more time with patients, and there is less chance for entry error.

Any other interesting things you’ve been to accomplish with the data?

Corepoint allows us to use SQL to create various notifications. Whenever we get an AO1 on a patient it will write it to the SQL table and SQL will alert certain people that they have a new admission. For example, when someone arrives at the lab for tests, the alert will email key individuals and say, “This patient is waiting in the lobby for their test.”

We created alerts for admissions, for the lab, and I’ve got messages or emails that go out to people if somebody is transferred from the nursing floors into the ICU if the patient’s condition has degraded. When that happens, the administration also gets an email to tell them that the patient was admitted from the hospital into the ICU because that is a key quality measure.

Since you’re using CPSI, is there any additional value to use Corepoint Integration Engine to manage all your interfaces and provide insights on your data?

CPSI is very inconsistent as far as HL7 messages are concerned. They currently use some iteration of HL7 v2.1. They don’t abide by where things are supposed to be in the HL7 message – this value here, that value there, etc., and Corepoint Integration Engine helps us make sense of all that.

Another issue with relying on point-to-point interfaces through CPSI is monitoring – they don’t monitor your interfaces to ensure they are operating properly. Corepoint really keeps us informed when there is an issue so we can alert CPSI.

A common cause of interface downtime in CPSI is caused by patches. CPSI will implement a patch or we’ll load patches as a requirement for Meaningful Use or other issues. Those patches will break something within CPSI’s HL7 output that will cause Mirth [in use by CPSI] to generate messages that are garbled and cause downtime.

Everything will just completely stop and begin queuing because CPSI’s Mirth system doesn’t know what to do with the message, which I can actually see in the Corepoint admin console – I’ll see the idle time for all the CPSI connections change from 20 seconds to five minutes, then I know there’s something wrong.

At that point I have to call CPSI to actually alert them that their system has stopped processing messages. They’ll go in and modify the changed logic that is caused somewhere within their system.

So it really seems beneficial for CPSI hospitals to use Corepoint Integration Engine to gain insights over what’s going on with their patient data.

It’s also extremely cost beneficial. The ADT feed is a good example. We paid CPSI for one unidirectional ADT feed. I’ve used that same feed for around 13 outbound connections. If I were to rely on CPSI to build and maintain those connections, we would have to pay fees for each interface, and we would have no ability to monitor their status, like I mentioned before.

I also have the ability to go into Corepoint and make any modifications to the data that is input into CPSI. ICD-10 is a good example. I recently went in to modify the formatting to include a field the staff previously did not want in the system. I just went into Corepoint and changed it, no problem.

If I had to rely on the EHR vendor to make those changes it would take much longer and it could cause other unplanned problems.

Related Blogs

Natalie Sevcik

Congratulations to all award winners recognized at HIMSS24

Congrats to all the HIMSS award winners who are making global healthcare safer, more efficient, more equitable, and better for all populations.

Read more
MATCH IT

Drew Ivan

MATCH IT Act means better patient matching and safer, higher-quality care

The current Patient Matching and Transparency in Certified Health IT Act (MATCH IT Act) legislation focuses on improving person matching and data sharing throughout healthcare.

Read more

Lauren Usrey

Assessing the buy vs. build decision

Cameron Kerber of Monogram Health shares how his team made the decision to invest in a best of breed enterprise master person index rather than build the technology in house.

Read more