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.

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.

• 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.