Bonnie: An Open Source Clinical Quality Measure Testing Tool

Bonnie is a new open source software tool that MITRE has developed and released in April 2014 that allows Meaningful Use (MU) Clinical Quality Measure (CQM) developers to test and verify the behavior of their CQM logic.  The goal of Bonnie is to reduce the number of defects in CQMs by providing a robust and automated testing framework. Bonnie allows measure developers to independently load measures that they have constructed using the Measure Authoring Tool (MAT). Loading the measures into Bonnie converts the measures from their Extensible Markup Language (XML) eSpecifications into executable artifacts and measure metadata.

Bonnie Dashboard Page

The measure eSpecification format that Bonnie loads is Health Quality Measure Format (HQMF) XML. The HQMF specification provides the metadata and logic that describe the specifics of calculating a CQM. Bonnie can load the HQMF describing a measure and programmatically convert the HQMF specification into an executable format that allows calculating the measure directly from the specification. 

The measure metadata loaded into Bonnie is then used to allow developers to rapidly build a synthetic patient test deck for the measure using the clinical elements defined during the measure construction process. By using measure metadata as a basis for building synthetic patients, developers can rapidly and efficiently create a test deck for a measure. 

Once a CQM has been loaded into Bonnie, a user can inspect the measure logic and then build synthetic test records and set expectations on how those test records will calculate against a measure. This capability to build synthetic test patient records, set expectations against those records, and calculate the measures using those patient records provides an automated and efficient testing framework for CQMs. 

Using the Bonnie-supported CQM testing framework allows measure developers to more clearly understand the behavior of the measure logic, validate that the measure logic encodes their intent, and allows for multiple iterations of measure updates to be validated against a test deck. 

Bonnie Measure Page

Additionally, the development of a test deck as part of measure development provides benefits after the measures are finalized. The test deck build as part of measure development can be used to demonstrate the intent of the measure though the use of patient examples included in the test deck. Furthermore, the test deck provides systems that implement the measures with a means to validate the development of their systems. This is provided in the form of a base set of synthetic patient records with known expectations for calculating against the implemented measures. Finally, the test deck could be used as a basis for the test deck used as part of the Meaningful Use certification program. 

Bonnie has been designed to integrate with the nationally recognized data standards used by the Meaningful Use program for expressing CQM logic for machine-to-machine interoperability. This provides enormous value to the CQM program and federal policy leaders and stakeholders: this software tool verifies that the new and evolving standards for the Meaningful Use CQM program are tractable and can be implemented in software.   

Additionally, Bonnie was designed to provide an intuitive and easy-to-use interface based on feedback from the broader measure developer community. A key goal of the Bonnie application is to deliver a user experience that provides an efficient and intuitive method for constructing synthetic patient records for testing and validating CQMs. 

The Bonnie software is freely available via an Apache 2.0 open source license. The Meaningful Use program makes all or parts of the Bonnie software available for inspection, verification, and even reuse by other government programs or federal contractors. 

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2014.

Thoughts on Clinical Quality Measure and Clinical Decision Support Convergence

I have been tracking several discussions for the past year to consider the convergence of Clinical
Quality Measures and Clinical Decision Support within Electronic Health Record systems.  As a quick refresher on the two types of healthcare reports:

Clinical Quality Measurement (CQM)

• Typically post-event reporting on treatment, usually via a quarterly or annual basis
• Longer term impact on healthcare quality of a population of patients

Clinical Decision Support (CDS)

• Guide clinical choices during treatment now
• More direct and immediate impact on the quality of care being provided to a patient

CQMs and CDS are clearly very closely related disciplines.  In fact, they are two sides of the same coin.  They both consider what actions providers take with the "hand they are dealt" with their patients.  For both types of reports, data in input via electronic clinical data, and both are implemented within EHR systems.  Additionally, the logic of a CDS rule and a CQM report are indeed very similar.

With CQMs, you are reviewing actions taken in the past to help educate and influence decisions in the future.

With CDS, you are working in real-time... in the present.

To put this in another context, with CQMs you may be viewing data that may have led to the death of a patient.  The goodness or badness has been performed by the provider or healthcare team.  With CDS, you have the potential to actually kill a patient by taking the wrong action.

This is the part of the CDS space that I personally find troubling to work with, since there is a much more real risk to harming a patient with either a bug in CDS logic or with ambiguity in standards that could be used to express CDS

Consider a Warfarin CQM that measures “Did you perform appropriate warfarin dosing?”  You could apply this CQM to a population of cardiac patients and consider the results in aggregate to see if over the course of a year.  Now consider a CDS that determines "What is the lethal dose of warfarin dosing that I am providing this patient... right now?!?”

For me, addressing the second scenario become really serious very quickly.  For healthcare providers, I do not think that they are phased with either domain, since they deal with life and death scenarios all the time.

But again, for me, these are the scenarios and domains where I lose sleep after work.

Several considerations have been discussed to expand the Health Quality Measures Format (HQMF) XML standard that is used for expressing the CQM logic for the Meaningful Use program.  The HQMF is an HL7 standard for representing a Clinical Quality Measure (CQMs) in XML.  The HQMF standard is a declarative approach to defining procedural CQM reporting logic.  What the HQMF standard has going for it, is (regrettably) being named the authoritative source for expressing the logic for the Meaningful Use Stage 2 CQMs.

The HQMF implementation of CQMs defines the data elements referenced by the logic, and associates them to value sets using object identifiers (OIDs).  These OIDs can then be used with the National Library of Medicine's (NLM's) Value Set Authority Center (VSAC) to translate clinical concepts into various operational clinical codes.

For those really interested in using the HQMF, you can download the HQMF files for all the Meaningful Use Stage 2 Clinical Quality Measures from the CMS site here.

Having worked with the HQMF XML standard indirectly for the past 2 years on both the popHealth project, and for the past year the Cypress project, my team has repeatedly expressed concern over the standard due to ambiguity and difficulty in ensuring that the HQMF standard is properly implemented in an EHR.  For our team, our challenge was consuming HQMF XML and turning it into procedural logic for Cypress and popHealth.

Based on the challenges my team has faced, I am very cautious about any considerations to re-use the HQMF standard for CDS support, since I feel it does a poor job expressing even the CQM logic.  My primary concern with the plans on converging CQMs and CDSs logic is the current declarative approach used for CQMs which is the HQMF XML standard.

What I feel is needed is a procedural definition of both CQM and CDS logic.  The reason for this need for procedural expression of the logic is that it allows for more rigorous testing, and also reduces the ambiguity associated with EHR systems have to implement their own parser to convert the declarative HQMF definition of either a CQM or CDS into their own procedural set of software instructions.

Consider the following procedural JavaScript logic built into popHealth v1.4 for the Meaningful Use Stage 1 CQM, NQF 0421 Adult Weight Screening:

function() {
  var patient = this;
  var measure = patient.measures["0421"];
  if (measure == null)
    measure={};

  var day = 24 * 60 * 60;
  var year = 365 * day;
  var effective_date = <%= effective_date %>;

  var measurement_period_start =  effective_date - (1 * year);
  var latest_birthdate = latestBirthdayForThisAge(65, measurement_period_start);
  var earliest_encounter =        measurement_period_start - year;

  var population = function() {
    var correct_age = patient.birthdate <= latest_birthdate;
    return (correct_age);
  }

  var denominator = function() {
    return inRange(measure.encounter_outpatient_encounter,
                   earliest_encounter, effective_date);
  }

  var numerator = function() {
    return weight_numerator(measure, 22, 30);
  }

  var exclusion = function() {
    return weight_exclusion(measure, earliest_encounter, effective_date);
  }

  map(patient, population, denominator, numerator, exclusion);
};

By having a single procedural definition for both CQMs and CDS, we should be able to have a higher level of confidence in the performance of the EHR systems that have to implement either a CQM or CDS.  What could then be done, is test and certify EHR systems ability to process the procedural definition of the standard, and then have a higher level of confidence that the any new CQM expressed in procedural logic... as long as it were syntactically well formed... would work with an EHR system.

The benefit to this type of approach is accelerated velocity in development, testing, and deployment of new CQMs and new CDS reports/rules.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2013.

The Four Different Types of Clinical Quality Measures

Clinical Quality Measures (CQMs) have been a significant part of my work for the past 3 years.  My first foray into the CQM space was with the popHealth project, which is a reference implementation of the CQM logic that a provider or EHR vendor could use or incorporate into a software project.  popHealth was entirely focused on a family of CQMs called "proportion-based".

While the "proportion-based" CQMs get the majority of the attention with the healthcare community, it was not until a year working on popHealth that I discovered that there are a total of four different types of CQMs that affect how the CQM logic is implemented and reported.

The four different classifications of CQM logic are:

Proportion

• This is the type of CQM that most individuals are familiar with when referring to the Meaningful Use program.  
• These types of CQMs are routinely referred to as the "Numerator/Denominator" CQMs.  I recently wrote about the exception and exclusion logic, but it is worth noting that those CQM reporting characteristics are only applied to proportion-based CQMs.
• Usually, the proportion-based CQMs are a positive measurement of quality, meaning that usually, the higher the value of the Numerator/Denominator proportion, the better you are doing as a healthcare provider
• Example: "What percentage of women over the age of 45 and under the age of 65, who have had an outpatient encounter in the past 2 years, have had a mammography screening?"

Continuous Variable

• These CQMs are usually applied in the hospital CQM domain.  
• These types of CQMs measure the average time 
• Example: "What is the average time for Emergency Department (ED) admission until either Discharge or Admission to Inpatient Hospitalization?"

Episode of Care 

• These CQMs assess each distinct ‘encounter’ between a patient and a provider, during a a measurement period.
• A single patient can contribute to numerous considerations of the CQM result if they had numerous encounters
• Examples: "Did the provider measure the patient’s blood pressure during a particular episode?" or "Were heart attack patients discharged with an Rx for Aspirin during a particular episode?"

Longitudinal

• These CQMs take into account complete patient record with focus on a ‘measurement period’
• Examples: "Have patients who turned 2 years old during the measurement period received all required vaccinations on schedule?" or "Have diabetic patients received 2 foot exams during the measurement period?"

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2013.

Meaningful Use Stage 2 Exception vs. Exclusion Logic Explained

Introduced in Meaningful Use Stage 2 was the notion of both exception logic and exclusion logic with the Proportion-Based CQMs.  Based on numerous conversations over the past several months, there appears to be ongoing confusion in logical implementation of exception and exclusion logic for these CQMs as part of the Meaningful Use program.

The authoritative resource for this explanation is the Clinical Quality eMeasure Logic and Implementation Guidance Document that is publicly available on the CMS site.  The details for proportion-based CQM that I have paraphrased follows below:

• Initial Patient Population: The set of patients (or episodes of care) to be evaluated by the measure.
• Denominator Population: A subset of the Initial Patient Population.
• Exclusion Population: The members of the Denominator that should not be considered for inclusion in the Numerator.
• Numerator Population: A subset of the Denominator.  The numerator criteria are the processes or outcomes expected for each patient, procedure, or other unit of measurement defined in the denominator.
• Exception Population: These are the members of the Denominator that were considered for membership in the Numerator, but were rejected, and meet the logic required for the exception criteria.

I have included an illustration that attempts to capture this updated logic for Meaningful Use Stage 2.

Meaningful Use Stage 2 Proportion-Based CQM Logic

These final population counts are then used to calculate the performance rate of any CQM against a population of patients via the following formula:

Performance Rate = Numerator Count / (Denominator Count – Exclusion Count – Exception Count)


This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2013.