I've been working on a project to replace existing interfaces to our old practice management system and redirect them to the replacement PM system. We're also adding new functionality and interfaces, too. Sometimes, it's important to think about what the business use of the messages is. Many times, the old system did things the way that it does because it made sense to do it that way ten or fifteen years ago. Simply replicating that process with the new system may not be the best way to go.
Here is an example.
Our doctors practice in several local hospitals. Our agreement with the hospitals is that we will bill for the procedures that our doctors perform there. We will bill for the professional charges, and the hospital will bill for the administrative charges. The trick is to figure out what we should bill for.
Our doctors use the hospital's computer systems when they deliver care there.
This hopital sends us a stream of scheduling messages. We do not get a stream of ADT messages from this hospital. That would be too easy.
The current system looks through the scheduling messages to see if there were appointments today that we do not have encounters in the practice management system. If not, it creates one. This will create an empty encounter that someone in the billing office will notice. They will follow up with the doctor to see what procedures were performed so that we can figure out what to bill.
Now, the scheduling stream is every appointment at the hospital clinics. Some patients will schedule a procedure up to a year in the future. This could be an annual mammogram, for example. Now, that appointment can, and probably will, change many times before the patient actually has that encounter. Keeping track of this in an interface engine will be very difficult.
I decided that I would save all of the messages and would have another process that would look at messages for encounters that are scheduled for today and check those against existing encounters in the practice management system. This would involve a database lookup. If there was no encounter, I would translate the scheduling message into a registration message and send that to the practice management system to create the encounter.
As I was trying to decide how I would replicate the existing logic, I realized that it would be very error prone. I could have the original appointment message for an encounter today, but if there is a later message that rescheduled or cancelled that appointment, this logic would create an encounter that never happened.
So, as I thought about how I would implement a system that would manage the appointments, I wondered if there might be a better way. Why should I have to create a logic in the interface engine to manage appointments and schedules? Could I find a system that would do that for me?
Then, it hit me. What if I simply sent the scheduling messages to the Practice Management system and let it manage the appointments? After all, that is one of the functions of a PM system.
Hmmmm.... I thought about it for a few moments.
Then, I asked Pam, our PM expert, how the PM system would handle an appointment without an encounter. She said that it would show up as a "no show" in an audit report. So, the business owners could use this "no show" report to follow up with the doctors to determine the billable procedures that occurred in this encounter.
This has the advantage of also having the schedule for these locations in our PM system.
We still need to follow up with the business owners to see if getting the information in this way would meet their needs.
We are building a mock-up of the new system to see what it might look in a test environment. I will create this schedling interface and we can see if this will work.
The moral to this story is that implementing a new system is an opportunity to do things better. If you keep your head down and simply replicate existing functions, you lose an opportunity to improve things. Of course, this requires that you actually understand what the old system does at an operational level, and not simply at a tactical level.