An HIT Framework for ACOs: where is the IT?

Powerline framework

A few weeks ago, CCHIT released it’s HIT Framework for Accountable Care.  The 42-page document is “designed as a starting point for provider groups developing HIT roadmaps, for payers looking to assess or complement the HIT capabilities of their provider partners and for HIT developers designing products to fill gaps in currently available technology.”  And I really like the document.  It puts the first stake in the ground in terms of how to consider an IT strategy that supports accountable models of care delivery.

But I have one big gripe with CCHIT’s ACO HIT framework: there is very little IT in the HIT framework.

CCHIT HIT Framework for ACOs

Summary view of CCHIT’s HIT Framework for ACOs

Now, before I continue, let me acknowledge 4 things.  First, we are still pretty early in understanding ACO requirements.  Second, it is really hard to develop a useful first IT framework on the best of days.  Third, any time you put “early days” and “first framework” together in a project, you will have at least a few people looking to nitpick (which, appearances to the contrary, is not my goal).  And fourth, some people might consider a higher-level approach right now a good thing.  So I acknowledge all of that, and the obvious hard work it took to put this together.  It is a bold first step and I’m not sure I could have done better as a starting point.

That being said, in my opinion at this point in the game, we need more than high-level requirements if we are going to successfully support the contract models on the table today.  I believe any IT framework should at least address some fundamental questions such as business process flows (not just process goals) and architecture (not just functionality).  Such specificity does not need to “lock you in” to a particular strategy or software approach, and serves to make planning discussions more tangible.

It is a careful balancing act for sure — prescriptive vs. facilitative guidance.  To further their cause, I think CCHIT may be well served to leverage the discipline of enterprise architecture (EA).  The domain of EA is rich with approaches in developing and managing strategies that strongly align business priorities / processes and IT plans.  Though EA is usually applied within the walls of an organization, the concepts are equally applicable across industry-level requirements.  And since any HIT framework for accountable care by definition will be deployed as an enterprise strategy, EA is a great fit as a planning framework. Note that I am not suggesting CCHIT bring in software architects.  At this point, we need leadership in the alignment of business and technology perspectives using proven methodologies (not just brainstorming).

So what are some of the key questions that an enterprise architecture version of CCHIT’s framework should address?  I would start by looking at the topics most early ACO organizations are asking:

  • Business process mapping.  Across the industry, there are some emerging themes on what should generally be happening within the context of ACOs.  It is no doubt early, but defining some meta-models for what and when patients, providers, and payers are doing various activities can aid considerably in figuring what and how IT should support those models: patients get assessed according to some standardized health risk assessment instrument, then they are assigned membership in a population, then a treatment protocol is selected, etc.  The existing framework has a lot of this; the information just needs to be structured differently.  Will there be huge variability?  Yes.  But the goal is not standardization of business processes — the goal would enumeration of the elements below.
  • IT operational systems.  Every enterprise is different.  But there is a portfolio of IT solutions that most ACOs will need in order to operate effectively.  Decisions will need to be made whether affiliated practices will be using their own systems (i.e., interfacing with a health information exchange) vs. working from a centralized solution provided by the ACO (and rationalize any non-ACO practice needs).  To me, it makes sense to provide a meta-catalog of high-probability systems: EMR, patient portal, referral, etc. so that organizations can start the process of gap analysis.

ACO Technical and Data Domains

  • Data domains.  One way of beginning to enumerate the IT operational systems is to focus on enumerating the data domains required to support the business process definitions.  Again, I suspect there are some reasonably clear data areas most ACOs will need to manage across institutional boundaries: patient medical records, list of physicians within the ACO, standard treatment protocols, etc.  With a data catalog spelling out the required assets, it is much easier to assess data provisioning and interchange.
  • Analytics.  No big surprise, but my biggest disappointment in the framework was the lack of attention to analytics.  Where analytics were mentioned, the statements were one liners like “apply predictive modeling algorithms to identify high risk patients” — a statement comparable “and then a miracle occurs” for many providers today.  Putting aside the obvious-but-largely-undiscussed requirements of analytically rationalizing outcomes, costs, and risks to manage the viability of the ACO business model, in my opinion ACOs should be the templates for learning health organizations.  But the existing framework does little to address the dynamic, iterative, evidence-based, and real-world health analytics required to realize that vision.  It is early days, I know, but now is a great time to be forward thinking.

Nevertheless, the framework is a great step in creating for the industry.  Kudos, CCHIT, on getting the conversation going so people like me can write blog posts like this one.  I look forward to the next iteration.


Health Analytics vs. Business Intelligence

One of the questions I get asked frequently is the difference between business intelligence and health analytics.  And I struggle with a good answer; there is so much inconsistency in the use of terminology in this space, and to answer the question requires that you be able to cleanly define terms like “business intelligence.”  But I do think it is an important question, as how you answer the question implies quite a lot in terms of what you need to be doing operationally.

Business intelligence (BI) was a term first coined in the 1950’s, but many people would argue that our modern conceptualization of BI is based around Howard Dresner‘s 1989 definition as “concepts and methods to improve business decision making by using fact-based support systems.”  As the adoption of information technology has grown over the past two decades, the conceptualization of BI has evolved in parallel such that today, BI can be taken to mean just about anything.  This situation has led to the advent of the term “business analytics” (an equally ambiguous term) to characterize a more modern, advanced approach to insight development.

Of course, health analytics has an equally ambiguous history rooted in other overly generalized terms like “informatics.”  A few years ago, this terminology issue led me to explicitly define health analytics as a domain separately from health informatics and business intelligence:

Health analytics is the domain of advanced analytics focused on providing strategic insights into the inter-dependencies in health outcomes, profitability, and customer preferences and behaviors.  Health analytics target insights that support transformational programs and business growth opportunities, enabling organizations to improve medical care, strengthen financial performance, deepen customer relationships, and pursue medical innovations.

I’ve reflected many times since then whether this was a good definition or not, but I’ve not come up with a better alternative yet.  But in my mind, three key attributes that fairly clearly characterize health analytics are:

  • multi-market: health analytics intentionally blur the lines between payer, provider, and pharma.  A fundamental assumption in health analytics is that the insights needed to transform health require collaboration across these historically siloed market segments (i.e., convergence).
  • multi-dimensional: health analytics are designed to explore the relationships within and between clinical, financial, administrative/operation, and personal aspects of health.  As such, they cross many domains of business inquiry and data.
  • multi-method: health analytics provide both retrospective and prospective views of health through multiple channels.  So in addition to the typical descriptive health metrics (e.g., counts, averages, percentages), health analytics incorporates more sophisticated and powerful techniques such as predictive modeling, data mining, and optimization to help define what is going to happen in the future (not just what happened in the past).  And the insights it produces get deployed operationally in a broader set of channels within an organization (e.g., reports, alerts, rules, etc.).

So with that as backdrop, here is my attempt at describing the differences between business intelligence and health analytics.

Scope Usually domain specific: clinical, financial, administrative Domain specific or cross domain: designed to link, for example, clinical and financial information together into one model
Timeframe Mostly retrospective Both retrospective and prospective
Mathematical Concepts Descriptive statistics: sums, averages, means, medians, percentages, counts Descriptive statistics + inferential statistics: correlation strength, forecasting, prediction, simulation, optimization, data mining
Data Structures Standardized, usually in data marts Both standardized and emergent (based on research needs)
Hypotheses Implicit — included in the assumptions behind measure / metric Explicit — part of a formal iterative discipline of research, discovery, and validation
Project Delivery Linear: project scope can be well characterized before the project starts Iterative: project scope is designed to constantly evolve based on findings
Project Risks Mainly associated with data: completeness, accuracy, cleanliness, representativeness Data risks + Time risks + Finding risks: projects include research which by definition carries uncertainty
Insight Delivery Standardized paper reports and web pages that often include “dashboards” Standardized paper reports and web pages/dashboards.  Also includes custom reports based on research, and direct integration of insights into operational systems and processes (e.g., alerts, rules engines, decision support)
Business Impacts Best suited for operational performance measures against clear standards; rarely competitively differentiated Operational + Transformative: best suited for strategic insights into changes, growth, investments, outcomes, etc.

In summary, the difference is really based on how broadly you define “business intelligence.”  In it’s broadest sense, health analytics could be considered a subcomponent of BI, taking many of the concepts of BI and applying them to an industry-specific set of questions and issues.  In it’s fairly popular technology-oriented characterization, BI is seen more as a reporting framework; in that sense, BI is a subcomponent of health analytics.  And if you prefer the term business analytics, health analytics could be an industry-specific implementation of BA.  But regardless of how we define it, I hope we can agree that it represents an under-served aspect of health information technology today.

The Health Analytics Book is Coming

Book Mock CoverAs many of you know, I’ve spent the past few months writing a book on health analytics and informatics.  I’m pleased to be able to report that, as of last week, the fully-complete draft is in the hands of my editors!  So I thought now might be a good time to give you a sneak peek into what’s in store.

The working title of the book is Health Analytics: Gaining the Insights to Transform Health Care.  It is all about EMRs.  Just kidding.  I’d probably sell a few more copies if it were about EMRs, but it is actually about what we might do with all of that information we are now collecting.

The target readers for the book are executives and leaders in health and life sciences organizations who are curious how to better incorporate analytics and informatics as part of a more effective and efficient business strategy.  I do not spend any time talking about the technical aspects of analytical methods, and there is no software code in the book — it is designed completely for the non-technical reader.  Here is a draft paragraph from the preface that summarizes the topic briefly:

This book is about painting a tangible picture of a different future for health care — one where the business of health care is more closely connected to the evolving science of medicine and the evolving role of individual health care consumers (i.e., patients).  It builds the case for a fairly singular idea; namely, that using health-related information in new and creative ways can dramatically lower costs, enhance profitability, improve patient outcomes, grow customer intimacy, and drive medical innovation.  We call this opportunity “health analytics.”

Some of the topics that the book covers includes:

  • what is health analytics, and why should every health enterprise now be focused on developing their health analytics capabilities?
  • how is health analytics different than the retrospective, reactive, and metric-oriented status quo informatics and business intelligence approaches operating across health care today?
  • what are some key health analytics capabilities and scenarios that will be foundational for 21st-century health enterprises?
  • why health analytics requires us to share data and insights across organizational and market segment boundaries?
  • how does an organization get started, and what does a roadmap look like for becoming an information-driven enterprise?

The book is being jointly published by Wiley and SAS, and can be pre-ordered on Amazon.  I don’t have a publishing date yet, but I’m guessing it will be out in the early fall of this year.  Over the coming weeks and months, I’ll be gradually providing more information, including a few deep dives into the book content.  So stay tuned!

My Health Analytics Talk

This past summer, I was fortunate enough to be asked to deliver one of the keynote addresses at the first Health Analytics Symposium conference.  Afterwards, a number of people asked for copies of my materials, which I’m fine to provide except no one ever knows what I said around each slide, and the slides themselves are far from self-explanatory.  So I managed to get a partial recording of my presentation, and have posted it here for those that might be interested.  Note that some of this content will be in my upcoming book on health analytics. More on that later.

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.

Does health care need “big data” or “big insights?”

Data tapeI’m thinking of starting my own medical condition:

Big Data Fatigue Syndrome (BDFS): a cognitive disorder characterized by feelings of frustration, disbelief, and growing apathy caused by repeated exposure to over-hyped technology concepts.  Occasionally accompanied by recurring fantasies of slapping publishers.

In the midst of our mad rush to amass yottabytes of “big data” as the cure-all for health care (see my Twitter feed for example articles), I wonder if it might be possible to pause briefly and ask one question:

What exactly are you going to do with the data?

Don’t get me wrong: I am a huge advocate of the opportunity in big data (I actually believe it could be revolutionary).  But it strikes me that health and life sciences has not really mastered “small data,” yet everyone seems excited to discuss big data.  I suppose it is no different in other industries — the hype is rolling along, with Gartner estimating 2013 spending of $34B.  That’s more than ice cream money.

Yet there are a few things we’ve learned in other industries and data experiences that might be applicable to health care:

1.  If you don’t know what you are going to do with data, there is no way you will collect it properly.  Hint: EMR implementers, you might want to look into this.

2.  “More” and “Better” are two different and often unrelated concepts.

3.  “More” increases costs regardless of how it is used (i.e., storage, cleaning, administration, integration architectures, software licenses, etc.).

4.  “Better”, when used properly, increases return on investment (i.e., increased efficacy, productivity, cost containment and avoidance, revenue maximization)

5.  If the “more” is not already inherently “better”, it can only become “better” by incurring additional costs.

“More” is a quantitative assessment – one petabyte is more than 500 terabytes.  “Better” is a qualitative assessment – it requires context in order to assess.  In the world of analytics, that context is directly related to the question you are trying to answer. Without that context, “more” can only ever be “more.”

In a conference I spoke at in July, I posed this question to the audience: do we really want “big data,” or should we be focused on “big insights?” Based on the reaction in the room, I think the question resonated with a lot of health executives.  If we raised the caliber of questions we are asking, we would undoubtedly find big data has a dramatic role to play.  For example, I’ve written before that big data presents a new opportunity in the science we practice.  What sorts of clinical questions could we answer using this analytics-oriented approach…investigations that could potentially offer immediate benefits to patients and physicians?  Could we, for example, model a 3-factor relationship between disease prevalence, socio-economic status, and geography in order to better optimize the design of clinical trials?  Could we mine behavioral propensities to look for non-genomic indicators of treatment efficacy?  Could we predict (not just detect) epidemiological progressions based on real-time consumer data feeds?

For each of these, the question itself opens up a more meaningful dialogue.  How exactly could we analyze that?  What data could we potentially use?  How much data would we likely need?  What would be the limitations of the data, and how might we address those limitations?  What other questions would we need to answer in order to feel confident in our findings?  These questions put us on the road to delivering real value from our data assets, regardless of their size or source.

The discussions we need to be having should be around the insights that could provide the biggest impacts across health and life sciences.  Let’s define “better” before we decide how much “bigger.”

Nine Truths in US Health Reform

Washington, D.C.

When it comes to health reform, it is time for the American people to “agree to agree.”

In my first post on this blog, I mentioned that I don’t pick political sides in the endless debates on US health policy…and I don’t.  But as the impending election approaches, more and more political maneuvering has become focused on re-evaluating our recent health reforms.  Maybe we should shut down improvement incentives?  Or maybe even reverse the legislation?  The increasingly polarized arguments are driven nearly exclusively from philosophical perspectives — big government vs. small government, fiscally liberal vs. conservative, etc..  But health care improvements need not be as politically charged as many politicians would have our people believe.

Most industry leaders could agree (if reluctantly) on four points:

1.  Health care is severely broken — the entire ecosystem: providers, payers, pharma, government…all of it.  Dan Munro has a great Quora post on this topic; I’ve borrowed some of the charts he pulled together below.

Per Capita Health Care Spending

2.  Without coordinated action, health care will stay broken and bring havoc to our economy.  The problem has been getting worse, and prior to recent health reforms, there was no way the market was going to resolve these issues in a reasonable period of time (if ever).

3.  Existing health reform efforts are accomplishing something that had not been done before; namely, facilitating a more immediate patient-oriented transformation of health care while spurring the long-lagging adoption of information technology.  Whether you agree with the financing of it or not, the transformation is now underway.

4.  Existing reforms are neither perfect nor adequate.  Insurance reform and health information technology adoption were required first steps (e.g., forcing different incentives, collecting information from which we could eventually make better decisions).  But hard work awaits.

If we can agree on those points, we should be able to agree on one other point:

5.  Improvement delays — especially those driven by political philosophy instead of informed industry strategies — should be unacceptable.  We cannot let ideology obscure reality.  If we hinder the progress now underway, more people will suffer: medical costs will bankrupt more families, citizens will receive sub-optimal care, and health care costs will increasingly compromise our national economy.  These things are known.

Milliman Medical Index chart, care of Dan Munro

For any political party, delays in health reform should be seen as a dereliction of elected duty.

When a patient enters the emergency room after a traumatic accident, the first step is stabilizing the patient: the heart needs to be pumping, the lungs need to be breathing, and any bleeding must be stopped.  That’s what health reform today is doing — trying to get a new baseline of vital signs for industry health.  If a doctor came into the ER and started cutting stitches and removing IVs without knowing how to treat the patient , we would most certainly question his or her competence.  As a nation, we need to agree on a long-term national health strategy that will get our patient healthy before we cut off the care being delivered today.  Let’s not put our citizens at any greater risk of medical or financial suffering — lets “first do no harm” while we develop longer-term approaches that reflect national consensus.

In order to do this, the American people should exercise our obligations as citizens to ensure the long-term viability of our country:

6.  We must hold ourselves and our elected officials accountable for producing results, not prosecuting ideologies.  If you hold an elected office, health care is not just a policy issue — it is your problem to fix.  If you can’t show a very specific and better plan, it would be irresponsible to interrupt the progress underway.

7.  We must demand that people debate specific solutions, not philosophies.  Philosophies and ideologies almost never represent ideal solutions.

8.  We should seek compromises for our collective good.  If the only way to win is to create losers among our fellow countrymen, we will be weaker as a nation (note: the demand for financial losers within the health market has been one of the forces that created this crisis).

9.  We must accept the uncomfortable reality that no health reform solutions can be either effective or sustainable unless we do our part as individuals to improve our individual health.  Governments can and should tackle the big problems, but citizens must do their part: if we want the quality of life enjoyed by a healthy people, we must live healthy lives.

As the Bipartisan Policy Center has shown, health reform doesn’t have to be political.  It can be what our other great achievements as a nation have been: unique, creative, powerful.  And united.

Starting Fresh

Welcome to my new blog!  My name is Jason Burke, and I’m a strategist, technologist, and writer focused on how data, technology, and analytics can be used to transform the health and life sciences ecosystem.  My LinkedIn profile is public if you are interested in the places I’ve worked and the experiences I’ve had.

For those that have followed my blogging since my start way back in 2008, thanks for continuing to read and contribute to the conversation (and if you wish to browse my prior blog posts, they are still available at, just click here for the feed).  For those that are new, I hope some of the things I share will be at least thought provoking, and I would welcome your participation in the dialogue.

Here is what you can expect from me on this blog:

  1. I don’t accept the status quo.  I believe health care — the entire ecosystem — is broken…but not beyond repair or hope.  I write about what interests me, which often focuses on the potential for evolution of the industry — the business, the science, the technology — towards a more effective health delivery system.
  2. My view of the problem space — and therefore my writing — tends to be multi-disciplinary.  Topics include the evolving disciplines of medicine, clinical informatics, advanced analytics, strategy development, innovation, software architectures, big data, performance  management…the list goes on, as the field of opportunities for health improvement is huge.
  3. I don’t pick sides.  I’m not interested in the politics of health care — I don’t write about them, and I don’t participate in the ideological debates of conservative vs. liberal policies.  I’m interested in researching, exploring, and discussing real-world issues based on real-world information, not financial and social philosophies.

So welcome aboard, it should be an interesting ride!