Curbside Consult with Dr. Jayne 11/13/17

Since I work with so many different healthcare organizations, I have a variety of behind-the-scenes views into various non-clinical applications. When we think about healthcare IT, most of our brains automatically jump to systems like EHR, laboratory information systems, PACS, etc. But there’s a lot more to keeping healthcare organizations and IT vendors on their feet – systems like scheduling, payroll, client management, accounting, and more.

One of the things that is often surprising to me is the variability with which various systems have been implemented, often to the detriment of their users. I’ll be working with a group that complains bitterly about how they have to log their hours, only to run across a different group happily using the same system.

One of the major pitfalls I see when comparing disparate installations of the same system is the level of customization or configurability available during implementation. Just as we see with clinical systems, those making the decisions on business systems often jump right to customization before even going live. Rather than using the implementation of a new system as an opportunity to refine work streams and reassess processes, I see organizations simply move their old data over and create more modern versions of the same old messes. Although we often see this with patient accounting systems when clients want to move their old accounts receivable to the new system so that they can decommission the legacy system more quickly, I recently saw it with a general ledger conversion, where the health system wanted to bring more than 15 years of accounting records into the new system.

The engineers involved were struggling with data integrity concerns about moving data that had been converted previously, as the organization was on its fourth accounting system in 20 years. They also had concerns about system performance and the size of some of the data tables. I asked about the business case for bringing that data across rather than archiving it, since most businesses don’t keep records in their current system longer than required by the law or generally accepted accounting principles. The engineers didn’t believe that there was a compelling business case since the old system was going to be archived, but were forced to go along with the project as scoped. The project also has other issues, such as being more than a year behind schedule, but that is a topic for another day.

I also see process improvement opportunities with respect to time-keeping software. Many of the time clock solutions out there are straightforward, but when you get to the point of having engineers and analysts log time against multiple concurrent projects, I’ve seen some messy systems. The most efficient systems seem to be those that can cross reference standard work streams against multiple clients or projects. The worst are those that require a subset of work streams be created under each client or project, resulting in potential errors in item creation and challenges for people trying to find the item where they need to enter their time. I saw that recently when a work item was misnamed when creating it under a new project and no one could find where to log their time because they were searching for “Requirements Creation” rather than “Create Requirements.” At a minimum, organizations need documented procedures and job aids for creating these types of entries so they don’t cause chaos for downstream resources.

One of my favorite vendors to hear people talk about is SAP. First, people don’t realize that SAP has multiple products. They also don’t realize that each product can be implemented in different ways. Corporate policy can also influence how a product is used and what level of access different users have. These types of policy differences can result in a graceful process to follow when mistakes are made or one that is arduous. They can result in empowerment for end users or multiple layers of control. It’s not just SAP, though – I hear the same types of comments about Kronos, Oracle, and pretty much anything that comes from IBM. Like many of our clinical and billing systems, there are significant dependencies on how these systems are implemented and how they are managed.

When I work with healthcare organizations, most of my billing is done through work orders, against which I document the hours my team renders based on assigned projects. Some organizations want third parties to work directly in their systems, logging hours as we go just like their employees do. This is where it gets interesting since they usually require a Social Security Number to set up an employee and there’s not a compelling reason for a third-party employee to necessarily provide that information. Once we get through the setup phase, the real fun starts, as we try to figure out project hierarchies and how to work through what can be less-than-straightforward instructions. As much as we champion role-based training for clinical and practice management systems, I don’t see it as much on the business / financial / management side. I’ve had to sit through trainings on parts of project management and time entry that I will never use. Although they’re not a great use of their time, it is sometimes fun to see what goes on in different kinds of organizations.

The other challenge I see in the behind-the-scenes world is having multiple systems in which employees have to work. There may be a payroll system, a time and attendance system, a credential management system for clinical employees, an internal help desk ticketing system, an expense reimbursement system, and a travel management system. Other organizations also add project management systems, customer relationship management software, external help desk systems, secure messaging, collaboration platforms, and more. And of course, there are the requisite email and calendaring systems that most of us use, along with instant messenger and other communications tools.

Sometimes we don’t think a lot about these systems, but they should be on the list when we think about competing priorities that our healthcare partners may have when they’re trying to perform major EHR upgrades, implementing new features, or other projects. I wouldn’t want to do an EHR go-live at the same time as a new time and attendance system. And if I was doing a new practice management system, I’d want to make sure other accounting systems are stable.

At one health system where I worked, the IT organization supported over 900 systems. The average user had permissions for between 15 and 20 of these. I’m curious how many systems an end user has to access in other organizations.

Are you taking steps to simplify and consolidate these functions, or just soldiering through? Leave a comment or email me.

Email Dr. Jayne.