Gozinta and Gosouta

In an engineering career spanning three decades, I’ve been involved in a number of process improvement programs, incorporating ISO 9001, SEI CMM, some home grown work and a smattering of Six Sigma. In all of these, I’ve found that three things are necessary in any process improvement program.

1. A well-documented process
2. Meaningful measures applied to process outcomes
3. Deep commitment from organizational leadership on execution

The last is also the most critical. Process improvement cannot be a grass roots initiative. It takes a great deal of resources and commitment to execute well.

As a result of being involved in these activities I’ve learned quite a bit about software development as an engineering discipline. A key take-away from these initiatives is that measurement needs to be baked into any process. You can begin with a process that doesn’t incorporate measurements into it, but at the end you will have a process that includes them.

Over the last five years, we’ve seen increasing attention on quality initiatives in healthcare. There are many parallels between these quality improvement initiatives within healthcare, and similar ones I’ve experienced in the field software development. One of the most heartening parallels is the deep commitment to this quality improvement effort at the Federal level.

Unfortunately, the more deeply I look into current initiatives, the more I see some critical gaps in the first two requirements, which I’ll cover in the reverse order.

Lack of standards for communicating well defined Quality Measures
One of these gaps is in the area of meaningful measurement. In order for a quality measure to be meaningful, it needs to be correlated with outcomes. The better the correlation, the more useful the measure is as an indicator of quality. This may be obvious, but needs to be stated in any case.

Presently, we describe many healthcare measures in the US using billing data and codes. However, all discussions I’ve ever had with clinical experts indicate that billing data is insufficient to provide refined clinical judgment. In a recently well-publicized case reported on by John Halamka in the Limitations of Adminstrative Data, these may not even provide a good indicator of what is happening to a patient. That doesn’t mean the measures we are using don’t provide some indication of quality, just that there are better measures that could be developed.

The next part of this issue is to ensure that we have a good way to communicate the measure definition so that they can be applied to the process. There is groundbreaking work presently being developed by the HL7 eMeasure Project. This project is developing a standard to specify how the definitions of quality measures will be exchanged. The first draft is out for ballot starting August 10th. One challenge of this project is that it is exploring areas of the HL7 RIM that have been underutilized in prior standards. I personally don’t expect the first draft to pass ballot because of this challenge, but it is a good start.

Lack of standards for communicating Guidelines
There are also gaps in standards used to communicate process documentation. The issue here is in the relationship between clinical guidelines and quality. If you look at clinical guidelines as “process documentation”, and quality measures as the measurement to be baked in, you will see not only do we lack standards that allow measurement to be baked into our processes, but we also lack standards that allow the processes themselves to be described. This is another interesting challenge because it often falls into the realm of decision support that I’ll discuss later in this article.

If we are to implement clinical guidelines in electronic health records, they need to be codified in a way that they are executable and measurable. However, guidelines aren’t written to facilitate their implementation or measurement in EHR systems.
The current process goes something like this:

• Write the guideline using evidence-based medicine.
• Write the quality measure based on the guideline.
• Apply available codes to the quality measure.
• Apply the measure to an institution.

There are several reasons why the process works this way, but breaking it up into these individual steps is in some ways like playing a game of telephone. Each step introduces an opportunity to deviate from the original intent of the guideline. One of the difficulties today in developing executable clinical guidelines is that there is no standard language for computably describing these guidelines.

For the purpose of illustration, I’ll take a very simple guideline in use today, which I’ve slugged to avoid giving medical advice:

“Patients with a suspected PROBLEM should take DRUG unless DRUG is
contraindicated within one hour of onset of PROBLEM symptoms.”

This guideline assumes a great deal of medical knowledge. Consider the following terms in it:

• suspected PROBLEM
• DRUG is contraindicationed
• onset of PROBLEM symptoms
• PROBLEM symptoms

A key role of measure developers is to supply definitions of these phrases. There are a lot of subtleties involved in this measure, and while current EHR systems are able to support it, they must be implemented appropriately to do so.

There are two ways to alleviate this problem. The first is to hack the guideline to fit the available data. Here are just a few possible hacks (note that I DO NOT RECOMMEND hacking guidelines, this is just meant to illustrate the problem):

1. Use the discharge diagnosis to identify patients with PROBLEM.
2. Exclude patients allergic to DRUG.
3. Compute the time between admission and administration of DRUG.

Every single one of these hacks results in the measurement of a clinical guideline that is different from what was written. First of all the phrase “suspected PROBLEM patient” is not meant to be a confirmed diagnosis of PROBLEM. It just means that the patient has one or more symptoms of PROBLEM. It doesn’t even mean waiting for confirmation by some lab test or diagnostic procedure. Next, there are more contraindications for a DRUG than allergies. Finally, the starting time for the interval measured is after admission, which is almost assuredly later than onset of symptoms (unless the PROBLEM was suffered after admission).

The right way to resolve this is to ensure that the guideline clearly and crisply defines what it means. This takes effort, and introduces a natural tension between the need to publish the information for human use, and to codify it for measurement. With just a little bit of training non-clinical persons can easily implement a guideline similar to the one described above, and as a result many lives can be saved. However, encoding that same clinical guideline takes some effort, and is needed if you want to automate measures of its implementation. Here, the person in the loop that makes the guideline easily implemented becomes less effective. This is a repetitive process that people aren’t terribly good at, but where computers excel.

Automation of Clinical Decision Support
The last challenge is perhaps the most difficult of all to address. We’ve been struggling for years to develop standards that will allow us to automate clinical decision support. Much of the attention has been focused on languages (e.g., GELLO, Arden Syntax) for specifying the clinical decision support rules.
As a software engineer, I have a different perspective on this problem. Clinical decision support rules that are executed by a computer system are nothing more than software programs. Any software engineer who tries to tell you that there is one best language for developing computer software is simply ignoring the plethora of computer programming languages available. Programming languages are tools, and if you’ve read what I have to say about tools previously, you know what’s coming. You need to select the right tool for the job. Different decision support problems will require different techniques to solve them. We shouldn’t try to limit decision support by any one language.

The definition of a standard language used to define decision support rules is not necessary or even desirable. Rather, we should focus on the development of a standard way to integrate decision support services into healthcare IT. Decision support standards need to be focused upon what the inputs and outputs of a decision process are (the Gozintas and Gosoutas that one mentor of mine liked to call them) .

If we can define what those inputs and outputs are in a standard format, and provide for an arbitrary (perhaps even proprietary) definition of the logic used make the decision, we’ve developed the core component necessary for a standard guideline. These Gozintas and Gozoutas happened to be the same data points needed for quality measures, and the same ones that providers record during the provision of care.

Two profiles developed by Integrating the Healthcare Enterprise can help here. The Care Management (CM) Profile developed last year describes how Gozintas to a clinical decision support process can be codified in a Guideline using the HL7 Care Provision Draft Standard for Trial Use. This profile is desperately in need of a document format for clinical guidelines that better supports what it is attempting to accomplish.
The Request for Clinical Guidance (RCG) profile will be published for Trial Implementation here in the week of August 10th. The public comment version of it can be found here until then. This profile defines how a Clinical Decision Support Service can be integrated into a Healthcare IT environment using the same HL7 DSTU listed above. It presently needs to have the Gozinta’s and Gozouta’s defined for it by a separate content profile, but ideally, these would also appear in computable documents. I plan on testing this profile out later this month and will tell you the outcome in a subsequent post.

If we piece together definitions of a quality measures, the inputs and outputs for clinical decision making, and arbitrary languages and algorithms for decision making, we can build a process definition with measurement baked in. We omit the contentious step of defining a single standard language for decision support, but move healthcare quite some distance towards having a repeatable quality process.
Those Gozintas produce a a Gozouta that I want.