Run time changeable for dummies: “liveware”

by Marty Staszak, CEO, Voluware, Inc.

Anyone else get frustrated when you have to stop work in progress because some application needs to upgrade itself?

 

Lost all hope that the key feature you want will miraculously show up in some future product release?

 

Wish you could get a software vendor to just add the features you want?

 

If you’re already a Voluware customer, you have already embraced a whole new service delivery model for software and left these concerns in the past.

 

Because I have to explain “run-time changeable software” to everyone, I have come to realize that it is difficult to do without some pain context.

 

Our VALER platform is designed to automate payer-provider transactions using forms and portals. Forms and portals that we don’t have any control over and can change at any time.

 

If we had to do software releases every time a payer changed a form, or updated the demographics in a web portal, then our service would not be loved. In fact, it would not even be feasible.

 

To solve the “change at any time” requirements, we developed a platform that could be upgraded “immediately,” meaning, while it was running. Having solved the “change while it’s running” problem for the forms and portal transactions, we went a step further and extended it to pretty much all VALER business logic.

 

The end result is that many of the cool little feature updates our customers want are not just doable, they can often be implemented within a few days, or sometimes, a few hours, and in a lot of cases, a few minutes, with no service downtime.

 

Can you imagine a software vendor that continuously updated your application according to your specifications on a release cycle measuring in days, with no downtime? Can you imagine if this is the way the relationship worked over the lifetime of your deployment?

 

Unfortunately, a lot of prospective clients have trouble imagining this kind of world as it is so unlike the experience they get with other software products, especially in health care. We have a lot of other software vendors to thank for conditioning the health care industry to expect so little, and to suffer a lot of pain just to get what they want.

 

“Liveware” refers to a software application that can be continuously modified while running. Each VALER instance we deploy is liveware. Liveware applications can be evolved so fast that they allow for new project management practices to come to fruition. We call it “hyper-iteration.” A process that delivers 100 micro-updates to an application on a continuous basis over the course of a year keeps the application continuously stable and dramatically outpaces any other managed release process in terms of new features realized. It also allows us to immediately revert any new features that our customers change their minds about. It also allows us to juggle priorities and continuously change requirements.

 

Feature creep got you down? VALER eats feature creep for breakfast!

 

We like talking about liveware. We love when our customers brag about it.

Why are prior authorizations so manual?

So why are prior authorizations such a manual process?  Whether it’s the joy of filling out paper fax forms, the carpal-tunnel inducing manual entry of data into payer web portals, or being on endless hold on the phone, prior authorizations today remain the bane of most practices:
  • The American Medical Association estimated that $31 billion is spent annually on prior authorizations by providers.
  • The Kaiser Family Foundation estimated 868.4 million hours are spent annually obtaining prior authorizations.
  • According to Milliman, manual prior authorizations cost $10.78 per transaction vs. $2.07 for an electronic transaction.  That’s $8.71 in savings per electronic transaction.
So one would think that in this day and age, that prior authorization transactions should be as easy as paying bills on your smartphone.  Guess again.  So why are prior authorizations still stuck in the  world of 1980’s fax tones?
1) Like politics, all healthcare is local.  Each geography has its own unique mix of providers, payers, and plans.  What that means, is that it is impossible to have any semblance of standardized workflows.  Each payer has its own fax form or clunky home-grown web portal that maps to its own internal workflows.
2) Local business requirements are always changing.  There are constantly changing forms or payer web portals.  Keeping up with change in today’s EHRs or practice management systems is impossible.  (How fast does your EHR vendor make changes? months? years? at all?)  Remember, these systems were never designed to manage change at the pace of the real world.
3) Everyone has their own system. None talk to each other today.   Whether it’s siloed provider EHRs or ancient payer systems, none meaningfully transacts electronic data with all their business partners.   It’s hard enough to get Cerner systems to talk to each other, let alone with say an Epic, Allscripts, or NextGen EHR.  And don’t even think about interoperating with a DOS payer system.
So, all healthcare is local, local business requirements are constantly changing, and none of our systems talk to each other.  What you get is $31 billion of last mile work-arounds to get anything done. We pay people to transcribe data on paper fax and type data into outdated systems.
This. Is. Insane.  As a physician working in the trenches, this is appalling and offensive.
This is why we have spent years studying the prior authorization problem. This is why VALER delivers automation today for prior authorizations, referrals, and eligibility.
To learn more, shoot me an email or message me: www.voluware.com steve@voluware.com @steveskim @voluware

Why are prior authorizations so painful?

So why are prior authorizations so painful?  As a young pediatric surgeon trying to build a practice back in 2012, this was precisely the question I asked myself every month as I looked through my accounts receivables (AR) reports.  Prior authorizations were consistently my largest source of denied payments and write-offs.  On top of that, prior authorizations were a constant source of frustration for both my office staff and for my patients in getting care delivered.  Fast-forward five years and it doesn’t seem like things have gotten much better with prior authorizations.  Some would even say that it has gotten worse with time.   That’s why I co-founded Voluware (www.voluware.com) to create a smarter way to automate prior authorizations.
Here are some of the disturbing facts around the costs of managing prior authorizations:
1) The American Medical Association (AMA) reported an estimated $23 – $31 billion is spent annually by U.S. healthcare providers on prior authorizations.
2) A Health Affairs article in 2011 estimated that the $83,000 was the average spend per physician on interactions with insurance companies.
3) The Kaiser Family Foundation estimated that 864.8 million hours per year are spent by physicians on prior authorizations.
So why prior authorizations are so painful?  I’ll share some insights gained during my 5 year journey in understanding and fixing the thorny issues around prior authorizations:
1) Prior authorizations are extremely manual processes.  Whether it’s paper fax forms or typing data into a clunky payer web portal, the act of requesting a prior auth is an intensely manual activity.  In some of our time motion studies, it took around 16 minutes per authorization to fill out forms by hand and fax in.  It can be even worse when you need to call for an authorization as you face an eternity on hold.
2) Why are prior authorizations so manual?  Prior authorizations are so incredibly manual because of a fundamental lack of interoperability.   None of our existing information systems on the payer side and the provider side seem capable of meaningfully exchange data.  Within this gap, manual faxing or data entry into a web portal represents the lowest common denominator integration of the information the respective workflows of business partners.
3) Why is there no interoperability of information systems when it comes to prior authorizations?  Despite having an electronic standard for prior authorizations (EDI 278) for well over a decade, a fundamental inability handle the complexities of prior authorizations at a local level has hampered meaningful adoption.  Much like politics, all healthcare is, for the most part, fundamentally local.  That means local contractual agreements, local provider networks. and homegrown or outdated information systems never constructed to seamlessly transact data.
4) Why can’t information systems seamlessly transact data? This boils down to two very fundamental issues.  The first is that most systems, whether they are EHRs on the provider side or utilization management systems on the payer side, are old.  Like 1970’s MUMPS and DOS old.  These systems were never designed to keep up with the constantly changing business requirements and were certainly never built to talk to one another.   The second issue is the more challenging of the two.  Every system, whether it is on the provider side or payer side, is designed to act as its own source of truth.  Even if two systems were able to talk to each other, without an efficient method to reconcile and normalize the data between systems renders any brute force integration effort ineffectual.
Well, I hope that this was a useful primer on why prior authorizations are so painful.  Stay tuned as I delve deeper into the nuts and bolts of the above mentioned pain points, and show you how our VALER platform was designed to automate prior authorizations.  Please reach out if you would like to learn more.  steve@voluware.com  www.voluware.com @voluware #VALER #AutomatePriorAuth

FQHCs: Falling behind on specialty referrals?

We are currently working with FQHCs that had huge backlogs with specialty referrals due to the manual nature of obtaining prior auths and putting together referral packets. What we have done is to integrate their EHRs (NextGen, Intergy) with payer web portals and have digitized specialty referral fax forms to nearly automate the referrals process. We pull new physician referral orders directly from NextGen and auto-populate payer web portals for submission and retrieve authorization approvals. We have seen up to a 4X improvement in productivity around referrals with no increase in FTEs. Referral worklists that used to take a week to get through are done in days. We are also able to pull customized reporting on referrals productivity for managers. How are others handling this issue? I know that a lot of people are using i2i, but the integration with NextGen doesn’t seem that straightforward. If you have any interest in learning more please message me or email at steve@voluware.com