Seven Reasons Why That Beautiful Informatics Architecture Won’t Deliver

Every organization has one: the informatics diagram.  It flows from left to right, starting with a few source systems and ending with users doing incredible things in browsers and mobile devices.  It looks well thought out, comprehensive, and flexible.  I’ve created a fair number of these pictures myself.  They often make sense even to the least technical people in the room.

Typical Informatics Architecture


There is only one problem with the standard picture: real transformation from advanced analytics won’t work that way.  Here are the reasons why:

1.  Data will be federated.  I know we don’t like to hear that.  We like the control and convenience of our own data buckets.  And we will have plenty of data to manage.  But not all of it.

2.  Your data is not analyzable.  I know many people think it is, but it’s not.  The data are incomplete and inconsistent.  It lacks clinical context of some primary measures and endpoints.  The structure does not lend itself to real analytics, and you are missing information that your analysts will need.

3.  All data are not created equal, and you don’t know a priori which is valuable.  If you operate under the assumption that you amass as much information as possible on an ongoing basis, you should also assume that you will be amassing costs on an ongoing basis — costs that are not tied to any specific return on investment.  That doesn’t make sense.  You need a mechanism for understanding what data is actually important.

4.  Extremely high data volumes require extremely high analytical computing capacity.  If you really need high-performance computing (i.e., your questions require analyzing these high data volumes), that infrastructure is a very different architecture.  If you don’t really need high-performance computing (i.e., your questions can be answered with more modest data sets), then your plan (and diagram) needs to account for data triage (see #3).

5.  There is no provision in that diagram for a learning system.  Insightful intelligence in health — like any other discipline — is iterative.  You need a feedback loop from the users and their work back into the architecture and data, a way of capturing what we learn that should both influence and contribute to subsequent analytical exercises and insights.

6.  Clinical decision support in the future will not be purely based on business rules and published practice guidelines.  First, it takes too long to deploy those practices and rules (10 years or more by some estimates).  Second, the question is not whether practice guidelines and rules add value; the question is whether any standardized guideline can reflect the natural heterogeneity that exists in patient populations.  We already know that the multiplicity of factors influencing a given patient’s health outcomes and costs are beyond the cognitive capacity of single medical practitioners, and much more extensive than can easily be documented in standardized treatment plans.  The future of medical best practices will be driven by real-world, real-time analytics — predictive models that do not supplant business rules and policies, but that more accurately inform and guide collaborative care teams (including patients and family members) about treatment options and outcome propensities based on “patients that look like this one”, not broad-based patient populations.

7.  The challenges aren’t technical.  Though these diagrams serve well to educate people about the opportunity, the challenges are not related to hardware, software, or networking.  Organizations need new competencies.  Cultures will need to evolve: a tolerance for exploring the unknown, a comfort in risk taking, a thirst for knowledge, a willingness and ability to operate in real-time, and a discipline for managing electronic information and insights as evolutionary assets.

In a future post, I’ll share some ideas for what an advanced analytics architecture for health informatics might look like in the future.