Neither of those sound like good news for Oracle Health. After the lofty proclamations of the last couple years. still…
Readers Write: The Cost of Doing Nothing: Five Learnings from the Build versus Buy Debate
The Cost of Doing Nothing: Five Learnings from the Build versus Buy Debate
By Kimberly Hartsfield
Kimberly Hartsfield, MPA is EVP of growth enablement at VisiQuate of Santa Rosa, CA.
It’s a conundrum that health system executives regularly face. Build a much-needed software solution in-house or buy it from a vendor?
Once hospital leaders identify the need for a solution that requires new functionality, the debate is on. Revenue cycle management (RCM) solutions are no different. While many hospital IT departments are no doubt capable of designing, constructing, and implementing new RCM solutions, leadership must decide whether taking this route is likely to yield the best business results.
Often, it starts with hospital leaders surveying vendors, seeing the price tag, and deciding to embark on the journey to complete the project internally, with the premise that it will be at a much lower cost. The decision frequently backfires. Rather than making the investment and having the technology that hospitals need to support their RCM operations efficiently, do-it-yourself health IT projects often end up taking years to fail and costing hospitals far more than if they would have signed with a vendor in the first place.
Health IT leaders see a pretty Tableau or Qlik dashboard and think, “We can do this ourselves.” When it comes to data visualization, they probably can. What they don’t consider is that the data aggregation, normalization, and transformation work that happens under the hood is actually the challenging part of RCM transformation.
The following are factors to consider when considering whether to build or buy a new RCM solution.
Complex health IT projects require more than health IT
IT departments sometimes believe that because they have their own developers and analysts, they can design, build, and implement complex health IT systems on their own. However, complex health IT projects require far more than technical skills. There must be business knowledge and experience married to that technical skill. Frequently that is where the projects break down because the people with the business knowledge already have full time jobs in the organization that are not related to building a platform.
Indeed, the reality of large IT projects is that they frequently exceed timelines, go over budget, or sacrifice important functionality. For example, one in six large IT projects have an average cost overrun of 200% and a schedule overrun of almost 70%, according to Harvard Business Review. Similarly, 56% of IT projects fall short of the original vision, according to a study by McKinsey.
It’s all about speed to value
Leading RCM vendors have been waking up every day for years thinking about how they can work to evolve revenue cycle analytics and deliver value and ROI to clients. Vendors have the benefit of having seen and evaluated RCM systems from healthcare organizations of many different shapes and sizes across the country. They understand best practices, having implemented RCM solutions alongside numerous electronic health records systems. This experience enables the ability to identify idiosyncrasies that hide within data and frequently uncover gaps that clients didn’t know existed.
While hospital do-it-yourself RCM projects may take years to complete, leading vendors can perform an installation in 90 days, delivering immediate insights and ROI.
RCM processes are broken and technology is the fix
It’s an unprecedented time for healthcare. There is no model for the circumstances the industry is undergoing, given labor shortages, supply chain constraints, and the financial after-effects of the COVID-19 pandemic. Across the nation, hospitals are pushing for more automation to augment staffing issues, letting their staff focus on tasks that require decision making, not repetition.
In many cases, RCM processes are broken, and technology is the only route hospitals can take to do more with less. Hospitals must lean into technology and automation, leveraging data to build predictive models and using artificial intelligence and machine learning to boost efficiency.
Unless hospitals are large, mature, and complex, they typically don’t have the resources to handle a large RCM project internally. Smaller hospitals often lack resources like a database administrator, a data warehouse, and data scientists who can build predictive analytics models, for example.
RCM processes continually evolve
It’s easy to forget that RCM projects typically are not “build it and you’re done” solutions. In addition to building RCM solutions, hospital IT departments must provide ongoing support and maintenance. These projects continually evolve, with new requests for additional reports or functionality upgrades. This often requires analysts, engineers, and other highly paid technical resources that are difficult to find and are only growing more expensive.
Further, it’s an open question as to whether build-it-yourself solutions deliver enough value and differentiation to be worth the time, expense, and effort. For example, if all an organization’s competitors can simply build their own systems to accomplish a certain objective, then that system is hardly a source of competitive advantage.
Move from descriptive to predictive
RCM employees cannot manage by spreadsheets. The industry is moving beyond rows and columns. RCM employees need to be able to visualize data to detect patterns to quickly identify outliers and manage by exception. Additionally, hospitals must move their RCM processes beyond descriptive analytics to predictive and prescriptive analytics.
It is no longer acceptable for hospital leadership to simply understand what happened yesterday. Hospital leaders must look to the future with the ability to anticipate and predict what will happen tomorrow, next month, or even in six months. Through automation and advanced data analytics, leading RCM solutions drive those insights.
Kimberly, great insights on build vs buy debate! I hear this all the time for the data aggregation side that they wish they had bought instead of building in-house. There are a lot of hidden factors that people don’t think about that you have laid out here. One other point I would add is building in-house could be taking away from more important hospital initiatives!
I had to check the calendar to confirm that I haven’t accidentally travelled back in time to the 1990s.
Am I so out of touch with what is going on in the industry, and not realizing that there still is a debate of “buy” vs. “build”?
Yeah, I had been under the impression that the current debate was “enterprise solution vs. best of breed”, not “buy vs. build.”
No Eddie, I don’t think you are out of touch. There is no debate IMHO.
Custom built software has an advantage in that you can get exactly what you want, neither more nor less. The problem always is that you are building for a customer base of: One. You cannot amortize your costs across multiple customers.
This eventually led to a movement that is rarely talked about now, because it is so commonplace. That movement was Commercial Off The Shelf (COTS). Later came Free & Open Source Software (FOSS).
RCM is a pretty mature marketplace and there are adequate solutions out there.
Yes, there might be the odd business out there with truly unique requirements that cannot be met by 3rd party systems. However I’ve literally lost track of the number of customers I’ve dealt with who claim that “we are unique”, when really they weren’t very unique at all.
The other point I’d make is, let’s suppose you are unique. Somehow. Is that uniqueness important enough to fund an expensive software development project? One that likely has nothing to do with your core business?
Custom software tends to exhaust the organizations that make it. Eventually the rate of enhancements falls, and unmet needs start piling up. The original movers behind that custom software move on. Their replacements start to have gaps that are not filled.
Choosing the custom path is rarely met with long-term success. In the 1960’s, well sure! But not now.
The more things change, the more they remain the same!
I participated in this debate over 40 years ago. An every decade there after.
Kimberly makes some good points against inhouse development for RCM systems (In my day they were simply called BILLING systems, then marketing stepped in…) Anyway, having actually built a several RCM here’s my take.
The things that have changed for the ‘better’ are; more flexible and powerful data management tools, better GUI tools, far better communication tools, better hardware, more robust operating systems, and more powerful macro coding tools. (In my day they were called reusable subroutines!).
All that paints a surface picture that says “Hey we can wip up our own RCM real fast”. And off they go…
But what has not changed, in fact is even more complex today, is the core business logic. All the insurance/government capitation rules that underly producing a correct bill are, and have been, a ‘nightmare’. And they keep changing almost monthly.
It’s difficult (if not impossible) for a provider to keep up with these just for their own locale. But a vendor must do it for 50 states, a thousand local programs, hundreds of insurance companies and more. In my experience what all the systems companies do to make their life easier, and keep development costs down was to create ‘manual workarounds’ all of which drive providers nuts. This product /cost ‘strategy’ is what drives providers to hate their vendor and consider “build it ourselves”. The new tools are incentives, but the work around frustration is the real driver.
Both ‘solutions’ have inherent short comings. Pick your poison.
Whipping up is actually more feasible now a days with the cloud vendors taking care of most of the infra headache and data headache..But this quick whipping up comes at a pretty steep cost. almost 25% of the per dollar that passes through the RCM system.
The whole inhouse non-cloud approach the cost per dollar of services charged is in .0001 range even with salaries factored in.
Cloud native is very very expensive and control is with the vendor.