Decisioning in healthcare

A few years ago, when I lived in Canada, I had an interesting healthcare experience.  My right eye was bloodshot and irritated.  It was quite uncomfortable, so after a couple of days I decided to go see my physician. He took a look, prescribed an antibiotic ointment, and sent me home with the comment: "Come back and see me if it hasn't cleared in 24 hours."  So, a day later, I'm back on his doorstep.  He takes another look, and sends me to the ER of the local hospital.  At the ER, another doc peers thoughtfully into my eye with some contraption.  She says: "Well, I guess he sent you down here because he is worried that you may have iritis, but I really don't see it."  Iritis is an inflammation of the iris that can lead to numerous vision problems.  She continued: "You're lucky, our ophthalmologist happens to be in today (it was a Saturday), I'm going to send you up to see him, just in case."  So I wander through the deserted hospital corridors and find the eye-specialist.  He's packing up for the day, but is happy to take a look, so I sit in his chair.  He takes one look and pronounces the diagnosis: "Rip-roaring iritis."  In fact, it is apparently so severe, that he is considering the ultimate treatment, which is a steroid injection straight into the eye.  Just to be sure, he wants this to be confirmed with another ophthalmologist in Toronto, who is the preeminent eye-guy in the land.  So, I go see the uber-eye-guy in Toronto.  His recommendation: "Here's some topical steroid ointment, we'll watch it for a while to see what happens."

This experience was quite the "eye-opener" for me regarding decisioning in healthcare.  Four doctors, arguably all considered authorities in some fashion, with four different opinions.

Following some discussions with esteemed colleagues around the use of analytics in healthcare, I decided to read the book "How doctors think" by Jerome Groopman.  This is a very enlightening book describing how errors in diagnosis occur.  Apparently some 10% to 15% of diagnoses are incorrect, which is rather frightening.  Interestingly though, the very large majority of mistakes do not come from lack of knowledge, but are rather ascribable to cognitive errors by the physicians.  So, the question becomes: how can we help doctors make fewer mistakes?

In banking, which is my background, predictive analytics are of course used far and wide, and have been shown to be extremely effective at "diagnosing" risk.  Naturally you expect that you'll make some mistakes, but the nice thing is that you can adjust the price for everyone, so that the goods make up for the bads.  This is called risk-based pricing.  So, this has been used for decades in the financial industry, why isn't it used in healthcare? Surely there is enough data around to build fantastic models.  Automation of decisioning could be a huge cost saver and it could free up physicians from mundane ailments, right?

As I read the book mentioned above it dawned on me that the analogy with the financial industry is flawed.  The problem is this: in banking the cost of an error is relatively small, in healthcare that cost is catastrophic.  In banking, the 999 good decisions make up for the one bad decision.  In healthcare, the 999 right diagnoses do not pay for the one that you missed. This, I think, is why there is so much resistance to analytics based decisioning in healthcare.

Obviously this does not discount the benefits that analytics in medicine diagnostics can have.  What's required is to tailor analytics for use in healthcare.  In this sense, it seems to me that the easiest thing that could be done  is some sort of system that helps physicians by keeping them honest.  Most of the mistakes in diagnosis occur due to all the familiar cognitive traps that causes the human brain to focus on one answer while discounting other possibilities.  Many great physicians force themselves to religiously ask themselves "What else could it be?" every time, with every patient.

So it seems to me that a good place to start would be to create a system that, given certain symptoms, would produce a list of possible causes.  Critically, it should also list the statistical confidence in each of the hypothesized causes.  This would ensure that doctors keep an open mind, and it would ensure that they keep questioning their hypothesis, in particular if the data shows low confidence in their hypothesis.

Nexus 2

Decisions as a Service sits at the center of another web, see the diagram below.  It is where data comes together from numerous data sources, including:

• Third party data - one of the benefits of this type of approach is that you can pick and choose the data you need and get it when you need it.  This also ensures that the data you have is always fresh.
• Internal data - obviously internal data is always valuable when making decisions.  Particularly proprietary data can give competitive advantages.
• Internal systems - data may be generated real-time and might be pushed to the decisioning system, or requested by the decisioning system.

Results from the decisioning system can be pushed back to the internal systems or databases of the end user, or they may be pushed to third party service providers such as:

• Call centers
• Printers
• Content providers
• Suppliers

A complete Decisions-as-a-Service system allows the end user to tie all of this together and create tremendous value.

Beneficiaries

I see two groups of companies deriving benefit from Decisions-as-a-Service.

1.  Direct users.  These are folks who wish to implement automated decisioning logic themselves.  Examples are far and wide, including in marketing, membership management, credit policy, fraud policy, and so forth. This normally requires some level of sophistication from the users as they have to get down into the nuts and bolts of formulating decision flows.  Depending on the platform used this may require significant IT resources or, for more business friendly applications, a decent business analyst.
2. End-solution providers.  For example, many smaller analytics shops do not have the facilities to host their models of solutions themselves.  So, what often happens is that they "partner" with large servicing providers to do the hosting for them.  The issue with this is that these "partners" in the final analysis really couldn't care less about the smaller shops, so time and again the smaller shops get thrown under the bus.  The smaller shops can benefit tremendously from an independent provider of hosting services specifically designed for the delivery of analytical decisioning solutions.

Nexus 1

It seems to me that Decisions as a Service comes together at the intersection as a set of exciting technologies that are about to hit center stage:

• Data as a Service.  New data sources are popping up all over the place, and access is becoming automated.  Gone are the days of loading your data warehouse with every morsel of data you can get your hands on.  In the new world, you reach out and get just the data that you need and when you need it.
• Web delivery of applications.  The presentation of full featured applications through the web is all but mature.  There is almost no reason that any application couldn't be delivered through a browser interface.
• Cloud computing.  I suppose it is fitting that the term cloud has been used for this nebulous concept.  I will take it to mean the execution of applications on a distributed platform the interface to which is essentially opaque to the user.  Amongst the benefits of this, in this context, are that resources become shared (i.e. cheap) and the distributed nature virtually guarantees universal accessibility.

Combining these technologies with a powerful decisioning system will results in a platform that can deliver superior automated decisioning capabilities to businesses.  This platform has the following features:

1. Decisioning power on demand, tailored to each business' cycle,
2. Instant and transparent access to data that is critical to making informed and competitive decisions, and
3. Very low entry barrier to sophisticated decisioning.

Nirvana.

Use case: real-time talk-track optimization

Today I will discuss my first use case example.  The objective is the creation of a dynamic talk-track for out-bound calling agents.  In this particular case, the company I'm talking to has a call center where they call their prospects and walk them through a list of offers.  The current state has the agent essentially walk through all the offers sequentially, hoping that we get to an offer that the prospect is interested in before the prospect calls it quits.

So, what we want to do is create a system that in real-time evaluates what we know about the prospect up to that point (including information gathered during the call) and what the best possible offer is given that information.  The proposed system is diagrammed in the figure below.

This system - which has been set up in pilot form - allows business analysts to implement and modify the business logic to select the next optimal offer entirely independent of the calling agents.  Additionally and extra level of independence is achieved by making the web content, in this case the offers, entirely database driven. This is a significant benefit, because it means that the content can be modified by simply changing fields in a database, rather than having to engage in web-page coding.

Because the decisioning can use any of the data that is stored in the prospect database in real-time fashion, and because data is saved into the database during the conversation with the prospect, the system becomes a dynamic optimizer of agent talk tracks.  It is anticipated that this solution will at least double the revenue generated from this particular endeavor. 

Stored procedures

I was having lunch with a good friend of mine the other day.  He recently took a new position as analytical big wig for a marketing company.  The company has a great deal of data, but he lamented that all the current business logic was coded as stored procedures in their databases.

To be sure, there are benefits to stored procedures.  A lot of the processing requirements get off-loaded to the database server which typically has plenty of power, and it reduces the volume of data transfer that may be required.  Additionally, in some cases it allows you to call business logic directly within SQL queries.

These benefits come at a steep price, however.  Stored procedures are typically very difficult to modify and any modification requires involvement of IT personnel.  This is a death knell in environments where competitive advantage relies on continuous learning and updating of business logic and strategies.  And really, show me an industry vertical where continuous learning and improvement is not essential to remain ahead of the game.  A decisioning platform that allows business analysts to control decision flows and strategies can take you to the next level if you're still doing your automated decisioning in stored procedures.

Benefits

In my view, the main benefit of Decisions-as-a-Service is that it levels the playing field between large and smaller players in terms of ability to implement sophisticated business logic.  No longer is it necessary to shell out millions of dollars in capital expenses to get access to a decent decisioning platform.  Instead, users can start designing and implementing automated decisioning through subscription or per-click models, essentially providing instant ROI.

A number of features are critical to make this model work:

• Shallow learning-curve business logic design interface.  The creation and deployment of decision flows needs to be intuitive and easy to learn, so that the users can truly be business analysts, instead of IT personnel. 
• Superior data connectivity.  Distributed data is essentially inherent in the hosted services model.  The platform must be able to access data easily wherever it is, given appropriate credentials.
• Superior system connectivity.  Decision platform do not just interface with data sources.  In many cases decisions need to be delivered to live systems that are likely to be remote.
• Shared resources.  While sharing of resources is not absolutely required, it does help to keep costs down.  This is important if small to medium-sized entities are to be able to afford access.

There are likely others, if you can think of them, please let me know.