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.

Advertisements

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.