We got a couple of kittens a few months ago. We like to take them with us when we travel. Believe it or not, they are great travelers. If you have ever raised a kitten, you know that there are times that you need to remind them of where the litter box is, especially if you haven’t been in this place in a while and the litter box is not visible to them. We keep our litter boxes in the storage room in the basement, so it is out sight, and hopefully out of smell, so it is definitely not visible. Thing is, when they can’t find the litter box, they try to tell you in whatever way they can.
One evening, the day after we had just returned home after a trip, one of the kittens, Olive, was very vocal. We thought nothing of it since she sometimes yells at the bugs on the window. When we went to bed, she seemed very playful. She likes to get up on our bed and slide or scratch and slide. It is all very cute, but she was scratching and was more vocal on that particular night. I get into bed and my wife is playing with Olive. Olive starts pawing at my knee and sits. She then starts crapping on my knee (I’m under the covers)! I don’t realize it immediately and my wife starts yelling “She’s crapping on your knee!” She grabs Olive and takes her downstairs to the litter box. I’m left with a big pile of crap on the bedspread on my knee. It looked like she had been holding it for at least a day.
We learned a couple of things with this poop adventure:
- When you are in a new place, take your cat to the litter box a few times a day.
- Pay attention to someone trying tell you something.
Now I’m going to tie this experience back into interfaces, so bear with me. Just like the work is never over when it comes to making sure my cats know where the litter box is, your work with your interface is not over when you have gone through the implementation process, testing, and you are now live with the interface. Now, it’s time to listen to it.
All interfaces have some sort of log or reconciliation process to handle errors. Many practices do not pay attention interface logs. Sometimes they don’t know they need to, don’t understand the logs, or just don’t want to. In any case, this is a recipe for trouble.
Before implementing an interface, practices should find out what is expected of them long term. Many practices ask about ongoing maintenance and support costs, but they do not ask about human resource requirements to manage the day to day processes of an interface. Make sure to get this information and plan for the resource requirements.
First, identify the person within the practice who will be managing the interface on a daily basis. This person should be involved in the testing process, and the practice needs to take ownership of the testing process. This interface is going to be part of your business process after it is implemented. The practice needs to understand the impact of the interface on the business. Too often practices learn about the interface weeks after the go-live. The time to test and determine the majority of different possible scenarios is during implementation and testing, not after go-live. It is also during this timeframe that potential issues and resolutions in daily use of the interface should be identified and documented along with resolutions and escalation procedures. This document should be used as your standard operation procedure manual for the interface.
After go-live, this interface standard operation procedure manual should be followed, regularly reviewed, and revised as necessary to keep the manual up to date. Part of this manual is the regular review of logs and reconciliation of messages and results. It is through these tools that a practice can catch issues with the interface or scenarios that were not originally scoped in the interface.
The dangers of not having this manual, and listening to what your interface is telling you, can be as devastating as me not listening to my cat. For example, we at Mi7 have a client that uses our HL7 DFT interface. Once a year, when new CPT’s come out, we get a call about a week later stating that the interface is not working. This has gone on for a few years now. The issue is that the new CPT is in the PM system, but had not yet been added to the fee schedule by the practice. The interface only adds CPT’s that have been added to the specified fee schedule. If the practice had been reconciling messages and reviewing the logs, they would have noticed errors adding this specific CPT to the claim. Well, the practice had some turn over in the past year, and the person that previously had been trained to review this particular issue last year was no longer there. Wouldn’t it have been nice if the previous person had given the new person their interface procedure manual?
Oh, and developers are sometimes human. We have had instances where practices that have done their daily reconciliation have found issues with the interface that should have been found in testing, or they’ve found new scenarios that were not originally scoped. For example, billing procedures can regularly change, and therefore, new scenarios always come up that need to be handled by these interfaces. Only by reviewing logs and reconciling can a practice be sure that an interface continues to properly support a business process. If you are not getting the logging needed to support your interface, have the interface developer add it. Remember that computers do what you tell them. It is your interface. Own it. Make sure it works for you.
Are you listening to your interface? We hope this story about Olive and her pile of crap has inspired you to do so. After all, your interface is probably managing many things in your medical practice, and your electronic health records system. Listen to your lab device interface. Pay attention to what your billing interface is telling you. Take heed when your custom interface puts up a red flag. Failure to do so could mean that you end up with a big pile of crap on your leg.
Contact us, we can teach you how to listen.