Curbside Consult with Dr. Jayne 12/3/18

My former employers at Big Hospital System recently reached out to me, requesting some assistance with practices they’ve acquired. In the years since I left, they’ve consolidated their empire onto a single EHR platform and have streamlined a number of IT departments including the EHR implementation team that I used to manage. The current implementation team is relatively green, having been hired with job descriptions that only allow them to address the new EHR, and not to think critically about or assist with any other systems. They’re also a relatively small team and their time is spoken for over the next 120 days. Whoever made the decisions to restructure the team this way apparently didn’t talk to the business owners of the employed physician group, which has continued to acquire independent practices at a rapid pace. These practices are then left in limbo because they can’t get a deployment slot on the new EHR for months and months, but they still have to try to run a practice either on their legacy system (if they owned rights to it and can keep it) or possibly even on paper.

The acquired physicians are frustrated and rightfully so. Being added to the main health system EHR platform was part of the decision-making for employment for many of these struggling independent practices, allowing them access to a repository of information about their patients along with professional referrals and communications. Several of them were already frustrated with their existing EHRs, and the idea of having to stay on broken systems for another six months is unacceptable. Unfortunately, they either didn’t understand or overlooked the contractual agreement regarding EHR migration, which clearly gives the health system control of the timeline for retirement of their current systems and movement to the mother ship’s platform.

I was asked to do some contract work with these practices, trying to reduce the frustration factor on their existing EHRs while they wait for migration. The health system also asked me to look at the installations from a support perspective, to determine the best strategy to handle upgrades and issues with the systems in the interim. I asked myself why this wasn’t done during the courtship process, and of course it has to do with money and convenience for the employer. That’s the way many physician contracts are these days, unless the contracting practice reads them with a careful eye and is willing to walk away if they don’t get an acceptable outcome. There’s also the factor of the physician group’s leadership assuming that the health system’s IT team would be willing and available to support the new practices and failure to gain an understanding of existing migration and implementation resources before setting a verbal (and unenforceable) timeline in front of the practices they were wooing.

I was happy to take on the work, not only because it was local and would keep me from having to travel much during the holiday season, but also because I know some of the impacted physicians personally, either on a professional basis or through community organizations. The work has been a flashback to my early days as a medical director for informatics, as I’d go out with recently-implemented physicians and try to optimize their day-to-day workflows. It’s always gratifying when you find quick wins that can impact physicians in a positive way – maybe they’re not using medication favorites or order sets. Those findings are common among small practices that may not have had dedicated EHR super users or that may not have spent the money and time needed for advanced training.

I’ve also had some flashbacks about working with systems that don’t seem to have a lot of clinical oversight. When I saw some of the workflows, they made me wonder whether a physician at the EHR vendor performed user acceptance testing before the content went out the door. One of the more obnoxious “features” I saw was part of a lab interface, where the ordering user has to handle those pesky but necessary “ask at order entry” (AOE) questions. For many tests, there should be a 1:1 relationship between the test code being ordered and the specimen type. For example, if you’re ordering “Stool for Ova and Parasites” the specimen type is “stool” and it should only have to be entered once. In one system I worked with, the ordering user (the provider in this case) had to enter “stool” as the specimen type twice for the same test. Since she was a GI doc and was ordering three different stool panels, she had to enter a specimen type of “stool” no less than seven times, even though each test was prefixed with “stool.”

I thought maybe it was just a configuration issue since there are situations where there still needs to be a more specific specimen type entered even though there is specimen information in the test name. For example, urine cultures – even though “urine” is in the test name, one has to specify whether it’s a clean-catch or catheterized specimen, etc. It was clear that it was a design issue, however, when we got to the blood tests, when the user had to select “venous draw” for all seven tests in the basic metabolic panel. That’s pushing absurdity, and no wonder the providers are frustrated since the BMP characteristically is performed using a single blood tube, not seven different samples.

I also ran into some examples of management absurdity. One practice has been performing weekly backups from their server, which resides in a data closet in the office. I asked them if they ever restore from the backups, and they said no. We talked a little bit about the need to practice downtime procedures and to make sure the backups are working properly. They agreed to do some downtime testing, and we restored the most recent backup to their test environment. I thought it was a bit weird that their test environment was hosted outside the practice but their production server was still in the closet. When we restored the backup, the most recent data entry was from June 2013. This led to some detective work, and after burning through some billable hours I was able to determine that they had been migrated from their self-hosted server to a cloud-based platform in the summer of that year. No one must have understood the significance of the migration, because the practice had been paying a third-party IT resource to perform regular backups of a server that was no longer being written to and had spent tens of thousands of dollars over the last five years for no reason. They were grateful that I figured out that they could stop with the backups, but were fairly aggravated about the whole situation.

I’m glad I can help some local physicians, but I hope they realize this is just the beginning of their relationship with Big Hospital System. The grass may have seemed greener on the corporate side of the fence, but now they’re just a handful of physicians among thousands. Despite what they may have been told during negotiations, they’re going to have to wait their turn for everything including migration to the shiny new EHR. In the meantime, I have a feeling we’re all going to get to know each other rather well as I spend some time on the helping side of the help desk.

How does your health system handle practice acquisitions? Are they live on the communal EHR day one? Leave a comment or email me.