There is a popular adage for information technology professionals: “Don’t pave the cow paths.”

I recently worked with a client from Texas, and they were fond of this adage. They said it with the most excellent drawl, giving it extra credibility, as if they may have actually learned it the hard way on their own ranches.

In the IT context, I interpret the adage to mean:

When designing an information technology solution for a business area, don’t just learn how they did the process manually and then create a software application to transfer that same process to computers. Rather, try to understand the underlying problem that the business process is trying to solve and the value that the business process is intended to create, and then take the opportunity to design a different process, one that is rendered feasible with enabling information technology and that delivers greater value.

When designing a new process to replace an old one, the starting point is re-conceptualization. The process designer must shed some of the terminology used to describe the old process when that terminology is too strongly tied to the details of the old process. Rather, the designer must dig down to the more essential concepts, and choose labels that are simpler and purer, seeking fresh metaphors to provide cleaner terminology. Then, the new process and the associated data structures can be re-constructed on top of a conceptual foundation that is easier to talk about, simpler to manage, and more stable.

Once we have a strong conceptual foundation, we can then flesh out the details of how the process can be made leaner and more effective, enabled by information technologies. Obviously, the proposed new process design influences the selection and configuration of enabling technologies. But, awareness of the capabilities of various technologies can also help generate ideas about candidate process designs that will be rendered feasible by the technologies. Therefore, this process is inherently iterative. The old-school philosophy of getting sign-off on detailed system requirements before considering the technology solution was a response to a valid concern that people will fall in love with a technology and then inappropriately constrain their process design accordingly. But, applying that philosophy too rigorously causes the opposite problem. If process designers don’t know what’s possible, they naturally stick with their old conceptualization, which also serves to inappropriately constrain their process design. As with most hard things, effectiveness requires finding the right balance between two undesirable extremes.

An example: the case of “registries.”  

A “registry” is a list of patients. The list includes the evidence-based services they need and whether or not they have received them. It is like a tickler file to help members of the clinical team remember what preventive services and chronic condition management services need to be done, so the team can improve their performance on quality of care metrics and provide better care to their patients.

But, if you dig down, the more fundamental purpose of the registry can be conceptualized as enabling care relationship management and care planning processes. Conceptually, health care providers need to know which patients they are taking care of. That’s care relationship management. It involves integrating different sources of information about care relationships, including derived care relationshpis based on claims data (also called “attribution”) and declared care relationships from health plans, patients and physicians. Part of the function of a registry is to clarify and make explicit those care relationships. This simple function can be considered  radical to clinicians who have become accustomed to an environment where such care relationships have been ambiguous and implicit.

If a physician has a care relationship with a patient, then, conceptually, he or she has a professional responsibility to make and execute a plan of care for that patient. Care planning is the process of determining which problems the patient has and what services are needed to address those problems. Conceptually, a good care planning process also includes provisions for multi-disciplinary input by members of the clinical team.  And, a good care planning process also includes decision support, including alerts for necessary things missing from the care plan, and critique of things that have been put on the care plan.  Such critique can be based on clinical grounds, such as drug-drug interactions, drug allergies and drug dosing appropriateness. Or, they can be based on evidence-based medicine or health economic grounds, such as in utilization management processes.

The name “registry” is tied historically to the word “register” which is a type of paper book used for keeping lists of things. In the health care context, “registries” were used by public health officials to track births, outbreaks of infectious diseases and cancer tumors. So, when people think about chronic disease registries, their mental model of keeping a paper list is a barrier to their willingness to re-conceptualize the underlying function differently.  But, more fundamentally, a “registry” is just one type of tool to facilitate care relationship management and care planning — a tool designed to be used for a narrowly defined list of problems and services, rather than being designed for more general use.

Today, there is no single care plan for most patients.  The function of keeping track of the problems that need to be addressed is either not done or it is done in a haphazard way, peppered across various structured and unstructured encounter notes, scribbled on problem lists, auto-generated in clinical summaries based on diagnosis codes on billing records, checked off on health risk appraisals, etc.   The function of figuring out which services are necessary to address each problem is peppered across numerous clinical notes, requisition forms, e-prescribing systems, order entry systems, care management “action lists” and in the fields of registry systems.  The function of facilitating interdisciplinary input to a patient’s care occurs informally in hallway conversations, morning rounds, tumor board meetings, or, most commonly, not at all.  These are all care planning functions, but most clinicians have no familiarity with the concept of linking these diverse bits of data and process in a cleaner, simpler notion of managing a single care plan to be used and updated over time by the entire care team.  As far as they are concerned, such a notion is probably infeasible and unrealistic.  They’ve never seen a technology that can enable it to become reality.

Choosing the right leap distance.

Of course, when re-conceptualizing processes, it is possible to go too far.  Old habits, mental models, terminology, and processes die hard.  If your re-conceptualization is a great leap to a distant future state of elegantly conceptualized processes, it might end up being too difficult to convince people to take the leap with you.  Other adages come to mind:  “Don’t get in front of your headlights.” Then there is President Obama’s version: Don’t get “out over your skis.”  And my favorite, often quoted by Tom Durel, my old boss at Oceania, “Never confuse a clear vision for a short distance.”

The optimal “leap distance” is a function of motivation to change.  If people start to experience great pain in their current state and begin to fear the consequences of sticking to their old ways, change happens.  As we move forward to a world where providers are taking more economic risk and facing more severe consequences for failing to improve quality of care, we will be able to pursue bolder innovation and leap greater distances in our process and technology improvements.