By: Palmer Hamilton on August 23rd, 2017
Revenue Cycle Consolidation Causes Heartburn For Hospitals
For hospitals contemplating revenue cycle solutions, it’s important to make sure your revenue cycle solutions aren’t half-baked.
Have you ever bought a bunch of ingredients and gadgets to duplicate what the pros make on a cooking show? They make it look easy…but it’s not. There are nuanced skills with timing, technique, temperature, and other subtle variables related to sequence and presentation.
Cooking shows are similar to industry consolidation; be it energy, automotive, or even healthcare.
So, what do we get with consolidation?
Efficiencies? Check!
Leverage? Check!
Market share? Check!
Integrated Solutions? Not so much.
Despite due diligence and planning, most consolidators don’t really know how to use what they’ve gotten until they live with it for a while.
In healthcare consolidation, there are many clinical and business decisions. These decisions influence hierarchy and medical practice culture as well as group purchasing contracts, maintenance contracts, purchasing protocols, and branding.
For healthcare IT, leadership must address integration of disparate legacy systems. For example, will the health system require everyone to convert to EPIC?
Most of us have experienced the awkward phases of consolidation. There are surprises. It tests leadership. It tests our patience and flexibility. It helps if we are selfless with our egos. It helps if individuals with institutional memory embrace change. These cultural behaviors mitigate surprises.
The last surprise you want is to realize that your Vendor/Partners are also in the process of consolidating. Suppose that Enterprise Solution you purchased was not as integrated as you thought.
It happens, particularly in Revenue Cycle. Private equity and venture capital groups create organizations that are really Holding Companies masquerading as Operating Companies. They have neat names- progressive sounding made-up words evoking technology and results. They sound helpful- like an independent third party simply here to usher in new “solutions” that “talk” to each other.
Back to the cooking show. This is the Recipe for Disaster- an acquiring/consolidating health system that is engaging a revenue cycle firm that is also acquiring/consolidating.
Besides the known and unknown variables within the changing health system, there are exponential increases in known and unknown variables because of the Revenue Cycle Management consortium. Imagine a front-end application packaged with a back-end application and they have no common development. Rebranded and impressive looking in simplistic flow charts and marketing material, they actually have unrelated DNA, nomenclature, and architecture. Further, instability of selling the firms to the holding company creates turnover in customer support. For the customer support that is retained, the front-end (Patient Access) support team has no knowledge or understanding of who, what, or where the back-end (Patient Accounting) is.
Who gets the most heartburn from this?
The Hospital staff? Nope.
The Revenue Cycle / Vendor sales rep? Not really.
The Patient? Bingo and Bon Appetite!
Buyer Beware
The take-away is to question deeply the interoperability of the vendors who call on you. If they cannot demonstrate deep layers of integration, be cautious. The quality of their customer service unfortunately is often the lagging indicator. This delicious looking cobbler is really just cobbled together.
For your patients, it will be the difference between rave reviews and “let’s try some place else”.
About Palmer Hamilton
Palmer Hamilton has over 25 years of healthcare experience with hospitals and insurers. He has a BA in English from VMI as well as an MBA from Wake Forest University, and he served as a Captain in the US Army. He has spoken at several HFMA events and has been published as well. His experience includes most aspects of the Revenue Cycle, and he is currently product manager for Online Analytics, a web-based solution for healthcare finance benchmarking.