For years, we in the software business have worked to create leaner, more efficient processes by pushing decision-making “left” into the hands of those who develop software. Our thoughts are that the sooner we can discover and correct issues, make significant decisions, and consequently eliminate thrashing, the more time and money we will save on wasted efforts and the low quality of monumental “big-bang” failures. In this blog, we will explore taking an innovative approach to the healthcare space by applying effective software engineering methodologies.

We’ve created organizational constructs, cross-functional development squads and DevOps that utilize faster and more precise automation. We test, validate, assemble, package, deploy, and test again, with the overall goal to deploy innovative features to the marketplace while balancing the competing dimensions of good, fast, and cheap. Developers know much more about their software than a downstream centralized committee. We don’t send paperwork back and forth and wait for those who aren’t familiar with our situation to make a decision.

I believe this “push left” philosophy should translate to healthcare. Our healthcare system balances a triad of the provider who provides care, a health plan that pays for insured care, and members like you who may require care. It’s a triad that is trying to achieve a goal of reaching satisfactory patient outcomes within the competing dimensions of good, fast, and cheap. But honestly, we still see substantial inefficiencies caused by not having enough useful information to make effective, timely decisions. To recap, in 2017, nearly 18% of our US GDP was spent on healthcare costs, by far the most significant percentage on the planet. That’s over $10,000 per person. One example is in the area of prior authorizations, which are required to ensure that insurance will cover a patient for medical treatment before receiving that treatment.



The American Medical Association (AMA) has documented several inefficiencies with prior authorization, such as lack of automation, lack of transparency, discontinuing coverage, inexplicable denials, and lack of timeliness – the list goes on. The AMA reports that the vast majority of prior authorizations are accomplished by staff personnel faxing, phoning, emailing and snail mailing information between each other. For example, only 20% of the EHRs used by physicians to order medications offer electronic prior authorizations for those prescriptions. This means that a physician can write a prescription and still need to submit lots of paperwork to see if it is covered. Studies indicate that a medical office’s clinical staff can spend 20 hours a week obtaining prior authorizations. Imagine the time that is spent at the payer’s office. The lack of timely information is especially damaging in high-risk cases that consume a large part of the spend. In 2016, 5% of our population accounted for over 50% of our healthcare spending. You want to act quickly when those patients have healthcare situations to provide the right care to minimize the long-term cost of care. Consequently, the AMA has published a set of reform principles for prior authorization, which is ripe for a “push left” movement.

So how could a software engineering methodology of “pushing left” possibly make a difference here?

Well, let’s consider a use case of you as a patient. Let’s say you go to Dr. Smith for a problem with your wrist. She diagnoses you as having carpal tunnel and tells you she would like you to have endoscopic carpal tunnel surgery. You feel relieved that you are on the path to recovery. You are so confident you make your winter vacation skiing plans. But wait, now the fun begins. When will you know if your insurance covers the procedure? Does your insurance cover the surgeon, facilities, labs, and ancillary specialists? How much will the procedure cost? And when will you know the full cost? Will this all wreck your ski vacation? Today the answers are non-deterministic, meaning that you can’t say when you will know the answer and even if the answer will be the same each time you ask the question. Chances are you may be getting random bills from various providers for the procedure long afterward. Why is this?


Source: American Medical Association |


The answer is that there are several wasteful, non-timely steps for determining what you are allowed to do, and ultimately, how much you owe. The steps go something like this. Dr. Smith’s office staff submits a request to your payer to perform a procedure on you as a member (patient). Dr. Smith’s staff asks your payer if you are eligible and what benefits you have for the procedure. Dr. Smith’s staff and the payer determine if an authorization is needed. If authorization is required, Dr. Smith’s staff gathers and submits paperwork justifying the authorization. Dr. Smith’s staff and the Health Plan sends requests, denials, and justification paperwork back and forth (sometimes including having the Health Plan’s staff come to the office to pull paper charts) until the procedure is either approved or denied. The Health Plan determines the approximate amount that Dr. Smith will be paid and the patient’s portion of that payment. Dr. Smith’s staff schedules you for the procedure. Dr. Smith performs the procedure. Each provider involved in the process submits claims for their part of the procedure, which are each denied, approved, or require further information, etc. The Health Plan decides how much of each claim it will pay the provider, and each provider decides how much they will charge you.  At some point, the total bill settles to an equilibrium, and the Health Plan pays the providers, and the providers bill you for the excess – which may be an accurate accounting – who knows for sure.

OK, stop! What other industry gets away with quoting you a price for a service and then bills you for a different cost (via a stream of bills) well after the service has been provided? What other industry keeps you waiting for weeks before you can decide if and where to receive the service? Could you imagine a software engineering process working like this? Well, maybe in 1970. But not now.

So why not push left?

Fortunately our healthcare industry has been working on this problem. There is a concerted effort to close the gap between the provider and payer systems. In the prior authorization use case described above, providers use systems classified as EHRs (Electronic Health Record) and Health Plan use systems classified as UMs (Utilization Management). Industry working groups like the Davinci project and CAQH Core have defined interoperability standards for providers using their EMRs to obtain electronic authorization for a procedure from a UM – while the provider is actually ordering the procedure. This means that ostensibly the patient would know if they were approved for the procedure and how much it costs before they leave the office. Sounds cool. Here’s how it works.



Let’s try your scenario again. (Warning, this part gets marginally technical.) During your office visit, Dr. Smith uses her EMR’s ordering module to order your endoscopic carpal tunnel procedure. There’s a point in the process where she is asked to do a “review” of the order. During order review, the EMR sends a message (via  clinical decision support technology CDS hook) to the Health Plan’s UM system to discover coverage requirements for the procedure. Your information, including your procedure, diagnoses, and the like are passed to the Health Plan’s medical policy component (likely in the UM) that determines if an authorization is required, and if it is, what documentation needs to be provided. The Health Plan’s component returns those documentation requirements in something called a CDS card.

At this point, the EMR launches a SMART on FHIR app that specializes in negotiating a prior authorization. The beauty of the app is that it can be launched in context by the EMR and can use OAuth2 tokens to assert security claims, which basically allows the app to act as a proxy for the EMR. The app is now authorized to talk to the EMR and will determine how to get the information it needs. If the EMR uses FHIR APIs, the app can map the documentation requirements from the CDS card into FHIR requests that it will make to the EMR to get your patient information. The app makes a series of calls into the EMR and bundles up the documentation (as FHIR resources) for review. If additional information is required, the app can prompt Dr. Smith or her staff to enter it.

Finally, the app sends the bundle of documentation required for prior authorization to the Health Plan’s UM, done via protocols like EDI or FHIR. The Health Plan’s UM policy engine returns an FHIR authorization status, and if the order is approved, the EMR submits the request along with the approval code. Dr. Smith’s staff may also receive additional information about your coverage and financial obligation, which means that you would happily leave Dr. Smith’s office with an appointment for an approved procedure and an amount that you would owe. Your skiing plans are safe. Now that’s pushing left!