John Moore of Chilmark Research had recently recalled the book to me in his post on developing a maturity model of Healthcare Information Exchange. HIMSS Analytics has a similar model for EHR Adoption. I happen to have a copy of Watts' book on my shelf, so I cracked it open again.
The problem with both of these models is that they work from assumptions about where we are with technology products today, and where we would like to be. They'll need to be changed when the entry level criteria for being an HIE or having an EMR improve. I like to think about levels more in terms of organizational capabilities, rather than fixed feature sets.
Page 6 of Watts Humphrey's book talks about 5 levels of organizational maturity. The first level is "Initial" and you get it for free. There is no "maturity" at level 1. Where I worked, we added a "Level 0", which is when you don't even know about the CMM. This was stolen from the fourth order of ignorance (see Five level of ignorance). John's critiera for level 1 for HIE is that you get something, but that something is ill-defined and provides basic capabilities (e.g., a portal).
At level 2, you get into a repeatable process, which implies basic management control. John talks about providing basic referal capabilities in his model for HIE's, but I'd rather look more closely. An HIE at level 2 of the CMM should be able to repeatedly roll out new features to its customers. This is somewhat different than providing a fixed set of features.
Level 3 in the CMM is the "Defined Process". Here, an organization has a documented process and follows it. It is an important, but as Dr. Humphrey's points out, only an interim step. There are no guarantees that the process is effective. I see this as being applied to HIE Governance. An HIE at this level would have written procedures in place that would describe how they go about developing new exchange capabilities. John has HIE's start gathering basic metrics and improving the HIE experience.
Level 4 is where real change begins to happen, because at that point, both projects and processes begin to be measured and evaluated. This is what quality measurement is about. An HIE at this level will be able to tell you how effective its offerings are in improving patient care. John has HIE's driving compliance across the organization. This is one of his best measures, because he's looking at what the effects of the HIE processes are (driving compliance), instead of a specific set of features.
Finally, Level 5 optimizes processes. When products and processes aren't measuring up, they are changed in ways that introduce efficiencies and improvements. An HIE at this level will be constantly improving not just its product offerings, but also the way it rolls them out. This is what is needed to establish the appropriate scaling in HIE efforts. One of John's goals here is really good: Improve operational efficiency and effectiveness of care, but the others are still too feature driven.
As critical as this post is, I realize that these fixed models of maturity or adoption are useful. John has a good list describe what HIE's should strive for today, and the HIMSS Analytics model for EHR Adoption helps organizations figure out a plan for EHR deployment.
As I look back through Watts' framework, I can see a number of other places where it can be applied in our nation's Healthcare IT programs, and ways in which different aspects of it have been applied. Current initiatives are trying to improve healthcare all over at once. We are after level 4 and 5 improvements (automation of the geneartion quality metrics an process redesign in standards development) at the same time as we trying to create a repeatable process for enabling information exchange. We should look at these programs through the lens of quality improvement as well, and see what the right order of steps is.
Take a look at Watts' book, and figure out where your organization might be. The company I worked for wound up at level 3 after about 18 months of working towards it, (and also became ISO 9001 Certified. Getting to that level was a huge improvement from where we were.
Hi Keith,
ReplyDeleteWhile it is perfectly understandable to have a maturity model based on process, after all that is the intent of CMMI from CMU's SEI - that does not mean it is the only maturity model going nor is it ideal.
As you reference in your post, the problem with models such as the one Chilmark developed for the HIE market, their reference to tech can result in them becoming outdated. No argument here.
But what is not referenced here is that the HIE maturity model that we developed was part of our HIE Market Report, a report that focuses on reviewing and rating the HIE technology solutions of 21 vendors. It is within this context, a context highly focused on technology, that was the foundation for this particular maturity model. Within that limited context, it is applicable and initial feedback from the community has been very positive.