Applied Big Data : The Freakonomics of Healthcare

 

I went with a less provocative title this time because my last blog post (http://brianoneill.blogspot.com/2014/04/big-data-fixes-obamacare.html) evidently incited political flame wars.   In this post, I hope to avoid that by detailing exactly how Big Data can help our healthcare system in a nonpartisan way. =)

First, lets decompose the problem a bit.

Economics:
Our healthcare system is still (mostly) based on capitalism: more patients + more visits = more money.  Within such a system, it is not in the best interest of healthcare providers to have healthy patients.  Admittedly, this is a pessimistic view, and doctors and providers are not always prioritizing financial gain.   Minimally however, at a macro-scale there exists a conflict of interest for some segment of the market, because not all healthcare providers profit entirely from preventative care.

Behavior:
Right now, with a few exceptions, everyone pays the same for healthcare.  Things are changing, but broadly speaking, there are no financial incentives to make healthy choices.  We are responsible only for a fraction of the medical expenses we incur.  That means everyone covered by my payer (the entity behind the curtain that actually foots the bills) is helping pay for the medical expenses I may rack up as a result of my Friday night pizza and beer binges.

Government:
Finally, the government is trying.  They are trying really hard.   Through transparency, reporting, and compliance, they have the correct intentions and ideas to bend the cost curve of healthcare.  But the government is the government, and large enterprises are large enterprises.  And honestly, getting visibility into the disparate systems of any large single large enterprise is difficult (ask any CIO).  Imagine trying to gain visibility into thousands enterprises, all at once.  It's daunting: schematic disparities, messy data, ETL galore.

Again, this is a pessimistic view and there are remedies in the works.  Things like high deductible plans are making people more aware of their expenses.  Payers are trying to transition away from fee-for-service models. (http://en.m.wikipedia.org/wiki/Fee-for-service).  But what do these remedies need to be effective?  You guessed it.  Data.  Mounds of it.
 

If you are a payer and want to reward the doctors that are keeping their patients healthy (and out of the doctors offices!), how would you find them?   If you are a patient, and want to know who provides the most effective treatments at the cheapest prices, where would you look?  If you are the government and want to know how much pharmaceutical companies are spending on doctors, or which pharmacies are allowing fraudulent prescriptions, what systems would you need to integrate?

Hopefully now, you are motivated.  This is a big data problem.  What's worse is that it is a messy data problem.  At HMS, its taken us more than three years and significant blood, sweat and tears to put together a platform that deals with the big and messy mound o' data.   The technologies had to mature, along with people and processes.  And finally, on sunny days, I can see a light at the end of the tunnel for US healthcare.

If you are on the same mission, please don't hesitate to reach out.

Ironically, I'm posting this from a hospital bed as I recover from the bite of a brown recluse spider.

I guess there are certain things that big data can't prevent. ;)

The Life(Cycles) of UX/UI Development

It recently occurred to me that not one of the dozens and dozens of user interfaces I've worked on over the years, had the same methodology/lifecycle.  Many of those were results of the environments under which they were constructed: startup, BIG company, government contract, side-project, open-source, freelance, etc.  But the technology also played a part in choosing the methodology we used.

Consider the evolution of UI technology for a moment.  Back in the early days of unix/x-windows, UI development was a grind.  It wasn't easy to relocate controls and re-organize interactions.  Because of that, we were forced to first spend some time with a napkin and a sharpie, and run that napkin around to get feedback, etc.   The "UX" cycle was born.

Then came along things like Visual Basic/C++ and WYSIWIG development.  The UI design was literally the application.  Drag a button here.  Double click.  Add some logic.  Presto, instant prototype...  and application.  You could immediately get feedback on the look and feel, etc.  It was easy to relocate, reorganize things and react to user feedback.   What happened to the "UX" cycle?  It collapsed into the development cycle.  The discipline wasn't lost, it was just done differently, using the same tools/framework used for development.

Then, thanks to Mr.Gore, the world-wide web was invented, bringing HTML along with it.  I'm talking early here, the days of HTML sans javascript frameworks. (horror to think!)  UI development was thrown back into the stone ages.  You needed to make sure you got your site right, because adjusting look and feel often meant "rewrite" the entire web site/application.  Many of the "roundtrip" interactions and MVC framework, even though physically separated from the browser,  was entwined in the flow/logic of the UI.  (Spring Web Flow anyone? http://projects.spring.io/spring-webflow/)

In such a world, again -- you wanted to make sure you got it right, because adjustments were costly.   Fortunately, in the meantime the UX discipline and their tools had advanced.  It wasn't just about information display, it was about optimizing the interactions.  The tools were able to not only play with look, but they could focus on and mock out feel.   We could do a full UX design cycle before any code was written.  Way cool.  Once blessed, the design is/was handed off to the development team, and implementation began.

Fast forward to present day.  JavaScript frameworks have come a long way.  I now know people that can mockup user experience *in code*, faster and more flexibly than the traditional wire-framing tools.  This presents an opportunity to once again collapse the toolset and smooth the design/development process into one cohesive, ongoing process instead of the somewhat disconnected, one-time traditional handoff.

I liken this to the shift that took place years ago for application design.   We used to sit down and draw out the application architecture and the design before coding: class hierarchies, sequence diagrams, etc. (Rational Rose and UML anyone?). But once the IDE's advanced enough, it became faster to code the design than to draw it out.   The disciplines of architecture and design didn't go away, they are just done differently now.

Likewise with UX.  User experience and design are still of paramount importance.  And that needs to include user research, coordination with marketing, etc.  But can we change the toolset at this point, so the design and development can be unified as one?  If so, imagine the smoothed, accelerated design->development->delivery (repeat) process we could construct!

For an innovative company like ours, that depends heavily on time-to-market, that accelerated process is worth a ton.  We'll pay extra to get resources that can bridge that gap between UX and development, and play in both worlds.  (Provided we don't need to sacrifice on either!)

On that note, if you think you match that persona.  Let me know.   We have a spot for you. :)

And if you are a UXer, it might be worth playing around with angular and bootstrap to see how easy things have become. We don't mind on the job training. ;)