I’m Hiring at UNC Health Care

For those that may be unaware, I’ve taken on a new role with the UNC Health Care System, and I am building a new team.  We are creating an innovative, industry-leading example of a system-wide health analytics organization – one that is truly focused on bringing advanced analytics, data sciences, agile engineering, and user enablement together to empower health care.  If you love data and want an opportunity to really see how it can improve patients’ lives in one of the nation’s leading academic medical systems, we just might have the perfect opportunity for you.

Go to UNC Health Care’s Career page and search on keywords “Enterprise Analytics” to see the current openings.  The site is constantly be updated with new roles, so check back often.

Advertisements

Live: health analytics on streaming radio

RadioI’ve been invited to appear on an AllAnalytics.com radio show tomorrow (Monday, 7-Oct-2013) called Making Medicine Smarter.  We are going to talk about health analytics, the book, and all things health care.  The show will air live at 2PM Eastern US, and you can hear it by going to http://www.allanalytics.com/radio.asp?doc_id=267367.  There will also be an after-show text chat on the AllAnalytics message board if you want to dive deeper on any topics.  Hope you can join us!

The 5 Most Annoying Data Excuses

data miningI recently had an interesting Twitter exchange with my friend Dan Munro over at Forbes regarding a KevinMD posting,  Quality is a Word that Lacks Universal Meaning.  The article touched on one of my book topics: the industry’s reporting-centric, manufacturing-oriented conceptualization of quality is ambiguous and unreflective of the problem space.  We need to look at quality differently.

Dan raised the concern of data — do we really have the data to support a different view of quality, especially in light of resistance to data collection?

Dan is absolutely right; from a quality perspective, we often are “flying blindfolded and handcuffed.”  But do we really lack data?

Consider that most health organizations have four available data sources:

  • Their own data (though it is often not readily consumable)
  • Partner data (though they may not be sharing it)
  • Purchasable data (though we often just pay for the answer, not the data)
  • Public data (though we often can’t determine how best to use them)

Between these four categories, we are drowning in data: EMRs, claims, referrals, device, billing, CMS, labs, imaging, clinical trials, public health, service utilization, reimbursement, health exchanges, costing, genomics, consumer sentiment, behavioral data, consumer health devices, e-prescribing… and it keeps coming.  It doesn’t look to me like we lack data; it looks like we lack insight.  So why do we lack insight?

Part of the challenge is focus.  Instead of getting smarter on how we use data, we continually shift our attention to the next set of data we need to collect, the next regulation we need to satisfy, the next benchmark we are handed, the next incentive to capture or penalty to avoid, the next dashboard report to build.

A second challenge is lack of process oversight, which I think validates Dan’s question.  We have plenty of processes across health care, and we do manage them.  But we fail to instrument or otherwise empirically characterize those processes in such a way as to offer process-related insights.  Note that meaningful use and HEDIS don’t do this either — they simply establish benchmarks.  Additional instrumentation does not imply we must collect more data — we could use derived or surrogate measures, for example.  But it just needs to be a focus (see above).

But a third challenge is the litany of status quo excuses that leaders hear daily about why we cannot be more data-driven in our decision making:

1. We don’t have enough data.

Of all the data excuses, this one gets the most play.  There are two assumptions behind this state.  First, it assumes that a complete inventory of data options exists, and that inventory does not offer enough to do what you need.  In my experience, most firms do not have a handle on all of their data options, and they do not understand (because they haven’t looked analytically) whether a given data asset is useful in understanding the problem at hand.  There is also an assumption you can determine how much data you need without analytics – which is untrue.  You actually need to do an analysis to determine if you have enough data.

2. The data we have isn’t good enough.

This excuse always interests me because, 99% of the time, it surfaces without any actual analytical work being done.  The data isn’t good enough…good enough for what exactly?  The perception is usually derived from either a) previously struggling with the data on an unrelated project, or b) physically looking at the data, which often appears messy, incomplete, and/or error prone.  Yet all data assets have limitations such as these; the utility of data can only be assessed in the context of the question being asked and the analytical method being used.  And the data never gets better until you use it and make it better.

3. The data exists, but we can’t have access to it.

Our obligations to patient privacy notwithstanding, we have to move beyond the rampant fears in using data.  Rules and contract terms should not prolong patient suffering and/or drive up health costs.  If an organization has data assets that cannot be used for agile innovation, then change the rules, re-write the contracts, change the consent forms, or provision new data sources to compensate.

4. We can’t use the data because of regulations.

This excuse is really a variation of #3, but it has the apparent added weight of the government behind it.  My same opinion applies.  There is no question that we need strong data protections and use provisions — we’ve been facing that for decades.  But no patient I know would rather suffer, die, or face bankruptcy than have their data used responsibly to improve medical decision making.  And if they do, that is fine, but have the patient or sponsor “opt out”, not “opt in.”

5. The data is not structured in a way that is useful; it would take too much time.

So it is too much work to innovate?  If you do not have easily consumable data assets, then maybe it is time to start treating data and analytics more seriously.  It is possible to create meaningful, agile analytical assets and insights, but it doesn’t happen accidentally, and it doesn’t happen without work.

The hard part of these five excuses is they all hold an element of truth to them.  But when we accept those challenges as barriers, we don’t progress.  And to Dan’s point, there is justifiable, growing resistance to performance metric pile-on.  Most practitioners I know do not believe there is a strong association between existing quality measures (MU, HEDIS, etc.) and real-world, patient-centered outcomes and costs.  And though that conclusion is overly broad, I think there will be growing evidence to support that view.  For example, two recent studies —  one in the Journal of General Internal Medicine, another in Health Affairs — call into question the association between readmission rates and quality.

The fact that we are using data inadequately does not mean we should not be using data.  And it doesn’t mean we need to re-double our efforts around meaningful use and physician education.  It means we need to become smarter about the questions we ask,  more focused in the priorities we set for our organizations, and predictive through the tools we give practitioners and patients to make more informed decisions.

In my opinion, we should be building and deploying comprehensive, predictive quality models that we know improve outcomes and costs; not justifying retrospective metrics that we hope might help.

7 Reasons ACOs and Health Analytics Need Enterprise Architecture

Railroad tracksLast time, I proposed that organizations looking to build or participate in risk-delegated delivery models (like ACOs) would be well served to look at the discipline of enterprise architecture (EA).

For those not familiar with enterprise architecture, you can think of it as a management framework for an effective, efficient, agile, and durable technology portfolio aligned to business process needs.  Various definitions of enterprise architecture abound, but my favorite comes from the MIT Center for Information Systems Research:

Enterprise Architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company’s operating model.

Looking at that definition, anyone familiar with emerging care models should immediately see three important terms in this definition:

  • processes — ACOs design and implement management processes (clinical, financial, and administrative), including associated health analytics
  • standardization — ACO management processes are created as standards of practice with critical metrics and measures
  • integration — ACOs require process and data integration across organizational boundaries in order to operate, monitor, and manage the processes, metrics, measures, and analytics

In short, ACOs need health analytics, and health analytics need an enterprise architecture.

Enterprise architecture is one of the concepts that underpin the health analytics strategies I’ve written about over the years.  Why is enterprise architecture important for health analytics and ACOs?  Here are my top 7 reasons that enterprise architecture deserves attention:

  1. Organizational planning.  EA establishes a common framework for defining the to-be state of business processes, what technology is needed, when, and how.  Whether you are building a parallel ACO infrastructure from scratch or transitioning existing practices onto one way of handling patients, EA gives a mechanism for capturing, formalizing, and planning that trip.
  2. Security.  American security guru Bruce Schneier (among others) has been quoted as stating  “complexity is the enemy of security.” With lots of moving people, facilities, and contracts involved in ACO formation and operation, security concerns can mount fairly quickly.  EA reduces security exposure through infrastructure and service standardization and simplification.
  3. Data interchange.  ACOs need to share a lot of information: medical records, claims, referrals, care protocols, etc.  EA defines the standard, universal method(s) for sharing data within and across the enterprise.  That data is the fuel by which health analytics provide insights; the better the octane, the higher the performance of your ACO.
  4. Communication.  Sharing the data is not enough; people actually need to communicate and collaborate around patients.  Though sharing EMRs or HL7 documents may be important, many practitioners gain real benefits from more simple things like having a simple way to contact other care team members.  EA provides the common enterprise services associated with care coordination, communication and collaboration across corporate boundaries.
  5. Onboarding.  Would you rather teach the new guy one way of doing something, or five ways of doing part of it.  Through standardization, common service offerings, and simplification, EA facilitates speed and quality in bringing on new practitioners, facilities, and technologists.
  6. Standardized measurement.  If you are going to be contractually bound and compensated on a set of performance measures, doesn’t it make sense to have a single definition and calculation of those measures that everyone — regardless of where they sit organizationally — can depend on?  EA creates a lingua franca for consistent and reliable performance measurement and management.
  7. Cost efficiency.  If you want to avoid “system creep” (the unmanaged purchasing of new hardware and software) and get more value from the investments you have already made, EA increases returns on assets while lowering operating costs.

There are probably more than 7 good arguements for EA (safety, for example, is enhanced through the standardization that EA enables), but hopefully this list is enough to get you started down the path of building a more capable infrastructure to support your ACO.

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.

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.