Saturday, November 23, 2013

Interfaces Abound


It is fun to think that there is one central hospital health information system (HIS); however, in reality, most organizations have a vast number of information products that connect to that HIS.  One of the most common interfaces is the admission/discharge/transfer (ADT) interface.  Most HIS systems use the HL7 standard to share information among third party systems. Once, I asked the interface engineers just how many interfaces they supported and was surprised to learn that there were hundreds of interfaces. This figure included the inbound, outbound, and bi-directional interfaces. Note that many systems have more than one interface. In my previous blog, I mentioned that an ADT interface had stopped working and the users had implemented an unexpected user work around. I was curious as to why the interface engineers didn’t realize that there was a problem and, instead, relied on the users to report the failure.  I suspected that, if you looked at the interface transaction log, you would be able to see that there was a problem. 

Generally, when you send an electronic message, there is an acknowledgement sent back from the receiving system. This information is stored in “log files.” So, how did we miss the failure of the ADT interface? Given that there are hundreds of interfaces and thousands of messages going back and forth, one can begin to understand how the log files containing the error messages were missed. I wondered if there was a seminal event that should have flagged an interface log review.  In wanting to understand the interface failure, I reviewed the logs and found that the errors began when the organization accepted a HIS software update. Along with the software update, the organization had made two small changes to the data format of two data fields. One change was to the unique patient identifier and the other the patient location code. One change involved expanding the cost center structure from four characters to six.  The second involved changing the data format for the patient identification number to include alpha characters; the number was previously exclusively numeric characters.  Once the HIS software update occurred, the ADT interface to the HIS failed.  Some ideas that would be helpful in this situation and similar ones, include:

·         Test interfaces after system updates are rolled out and before go-live

·         Predict potential failures knowing  that computers are very literal and follow parameters exactly as prescribed (e.g.,  data fields have prescribed data formats and changes to data formats suggest that changes to data field configuration might also be necessary)

·         Check with the interfaced product users post go-live to assess if there were any unforeseen impacts 

·         Monitor interface logs post go-live for error messages

Once we realized the interface failure occurred, the fix was quick.  Our investigation revealed two issues:   a) a reject message indicating the six character cost center did not exist, and b) a truncation of the patient identification number that removed the alpha character.

Lesson Learned: Changes to data format and structure may break interfaces.

Sunday, November 3, 2013

Users do unexpected things


I recently encountered an episode of unexpected user behavior. I was visiting one of the specialty departments that use a third party software to capture, record, and document procedures. This application has both an inbound ADT and outbound report interface with the primary hospital information system.  I arrived in the department to observe and discuss an upcoming conversion activity to upgrade the department’s software.  The vendor had notified us that they would be discontinuing software support of the current version. We were given six months to complete the software conversion to their newer product before the support ended.  This department has a small group of users, less than 20. I wanted to observe and validate their current workflow.
It has been my experience that workflows change over time and that changes are related to a number of influences and with good reason.  As I began to talk with the nursing staff about the upcoming software update, I reiterated to them that the success of the implementation of the software update relied on my full and accurate understanding of their current workflow.  I let them know that I assumed workflow changed had happened with this group of users.  I was here to document the current workflow, including their work processes (e.g., types of tasks, user behaviors) and desired outcomes. I let them know that as partners an optimal work solution could be designed. My objective was to give them tools to improve the quality of care delivery. 

The first activity I observed was “patient intake.”   According to the previously recorded workflow, the staff members would select a patient name from a list of outpatients (sent via an ADT interface) that had been pre-registered for their unit location.  The staff members were to verify the patient name, unit number, and DOB and then select the correct patient from the list.  What I witnessed was the staff manually entering in a patient name, DOB, unit number, date of service, and account number of all the scheduled procedure patients for that day.   Upon investigation, I discovered that 3 months prior to my visit, the ADT interface had stopped working.  Because the staff knew there was a way to manually enter a case, they adopted a workflow change in order to continue their process of seeing and treating patients.  Nurses are very resourceful and committed to achieving their mission of care delivery. When the ADT interface stopped working, in the heat of the moment, the staff worked to find a quick solution to complete their mission: providing care for the patients.  Notifying IT services wasn’t a priority and was something they could do later. Somehow later never came and the notification never happened. What I viewed as a simple and straightforward task, i.e., call and notify the IT helpdesk, was viewed by the staff as less or not important. 
Of course, the current user behavior I observed, although well intended, was a potential safety problem. The new workflow circumvented processes designed to support positive patient identification. My priority now would be to restore the functioning ADT, so that data entry errors could be mitigated and positive patient identification could be supported.  I suspect also that the 20 minutes the staff had been spending each morning building the patient list would now be available to them for reinvesting in other work.  

 Prudent practices help prevent and/or detect problems caused by duplicate records, patient mix-ups, and “comingled” (or “overlay”) records. Health IT can help mitigate issues associated with patient mis-identification by making sure that clinicians are able to select patient records from electronically generated lists based on specific criteria (e.g., user, location, time, service). Misidentifying patients is a known issue within healthcare delivery and creates a number of care issues to include:

a.       incomplete medical information to support clinical decision-making,

b.      incorrect patient information integrated into someone else’s (i.e. comingling) record the corrupts clinical decision-making,

c.       failure to notify a patient of a procedure result/outcome that may delay treatments/therapies, and/or

d.      notifying a patient of a medical condition that is false, creating undue stress and anxiety.   

This adventure taught me several things and, as a result, some of these lessons I will save for a future blog.  For today’s blog I will address “no reporting” and how to support issue discovery. After all, if users/staff don’t report, corrections will not happen, and well-intended workarounds will persist with the potential for patient harm lurking/waiting.  
Once again, I am reminded of a Patricia Benner’s nursing theory construct of nurse presence.  Benner writes about the benefits gained by all parties by nurses simply being present with the patient/family.  Her construct extrapolates to me and the users I support.  . My presence with nurse users will influence – hopefully in a positive way -- their perception and experience. In this journey of mine as an INS, I am in relentless pursuit of making people better at what they do. 

Lesson Learned:  Don’t assume staff will report software issues and don’t assume silence is golden.  The value of being present is so important.
 This experience got me thinking back to the days when I was a manager. One behavior I had adopted as a manager was rounding on my staff daily to “check in” with them.  I had specific questions I would ask them and I would record the replies and use my notes as a follow up tool to address staff concerns. I decided it was time to apply a similar technique to my INS role.  I developed a tool to provide a meaningful “rounding” of Health IT users.   This tool, a spread sheet that I could carry with me, focuses my questions to users and allows me to record the issues that were raised.  Currently, my question set is as follows:

1.     What in the system is working well for you today?

2.     Are there any system issues that you have identified that negatively impact quality or safety of care delivery?

3.     Is there one thing that the system does well for you in supporting the delivery of care that you hope never goes away?

4.     Do you have any concerns or suggestions for improvement that you would like to tell me about today?

I began to “round” with my users, collected responses, and looked for themes. The more frequently a topic appeared, the more I looked into it.  Occasionally, the staff would mention something that was not really related to Health IT. Quite familiar with the hospital departments, I passed this feedback on to the appropriate individual. My “rounding” activity has not and will not replace other reporting methods.  I am using it as a supplemental tool to keep me in touch with those unpredictable behaviors that users sometime demonstrate because … users do unexpected things