Meaningful Use Stage 2 XML Standards for Clinical Quality Measure Reporting

When implementing an EHR system, or EHR module, that supports the Meaningful Use Stage 2 program for Clinical Quality Measure (CQM) support, there are three HL7 XML standards that you need to be aware of:

• HQMF
• QRDA Category 1
• QRDA Category 3 

The HQMF XML standard defines the data elements referenced by the logic, and associates them to value sets using object identifiers (OIDs).  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.

The QRDA Category 1 XML standard is what is used for expressing patient-level data as inputs to a Clinical Quality Measure calculator, such as popHealth, as part of the Meaningful Use Stage 2 program.  This XML standard allows for EHRs to express the clinical results of individual patients based on the CQM that an EHR system was queried about.  The reports that determine the data to include in the QRDA Category 1 XML are tightly coupled to the HQMF definition of the measure.  I have shared high-level information about the QRDA Category 1 specification, as well as an example of what the QRDA Category 1 XML should look like.

Lastly, the QRDA Category 3 XML standard is what is used to express the summary results of a CQM.  It is unfortunate that the QRDA Category 1 and Category 3 are worded so similarly, yet have significantly different roles in this landscape.  The QRDA Category 3 is the artifact that needs to be generated for expressing summary/aggregate report numbers.  For instance, if the CQM report where created to assess the mammography screening results of women between the ages of 45 and 65 years old, and the result were 73% of that population met that criteria, the QRDA Category 3 XML could express the 73% performance rate, as well as counts associated with the initial patient population, the denominator, the numerator , the exception, and exclusion populations.  You can view an illustration of these different CQM logical families for the proportion-based CQMs here.

Below is an illustration that details the use of these various HL7 XML standards when reporting on Meaningful Use Stage 2 Clinical Quality Measures.

Landscape of Meaningful Use Stage 2 Clinical Quality Measure XML Standards

Hopefully this is helpful.  If not, let me know!

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

Designing Logos for a Portfolio of Healthcare Projects

Over the past three years, I have been involved with numerous open source healthcare projects, ranging from large reference implementations of Clinical Quality Measures, certification and testing tools adopted by the federal government, a small research project assessing CQM complexity/cost/tractability, this blog, and other ideas that failed to launch.

What I have been endorsing throughout the course of the past three years has been to establish a common "brand" that could be applied to various open source healthcare projects, but still provide a unique look and feel for each individual project.  

The design approach that organically evolved was to develop logos followed the following rules:

• Use only circles
• The circles may come in different sizes and arrangements
• Limiting the logos to a pallet of only two colors
• Color opacity could be changed

You can see the portfolio of these project logos below:

Portfolio of logos for open source healthcare projects I have worked on

Since I am a "left brain" engineer at heart, the various arrangements of the circles has been an easier task than color selection.  I have often struggled with finding the magic combination of colors for anything from these logos to our interior design of our hours.

The best resource that I have found been able to identify is ColorLovers.com.  For those not familiar with the site, it is an evolving resource for palettes and colors that users can share, rank and comment on.

When I had to select to colors, I went to the filter for "most loved" colors of all time, and tried to identify pallets where instead of 5 colors, there were 2 colors used in the pallet.  Hopefully this is a helpful trick.

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

Remaining "Agile" with a Medium-Sized Team

I am hoping to start leading a new (really old... but soon-to-be revived) open source health IT project very soon.  The good news is that it's appearing that the project will be well-supported, and that we will be able to staff the project team up to a very good size.  I'm also planning on continuing to embrace an agile project management process using scrum.

One of the key benefits to having a successful agile process has been the shared situational awareness of the members of the project which allows the team to self-organize.   If I am needed less on the small but blocking minute-to-minute decision making, there's a higher probability of exceeding the expected outcomes of our sponsor while simultaneously growing new leaders for the future.  Additionally, I am happy to perform less tactical work and focus more on strategy.  

With the right project team (talented... responsible... multi-domain... passionate) it is remarkably easy to be successful on any project; from a project that is technology-heavy software development activity, to one that is primary focused on steering or influencing federal policy.

After originally being a software engineer, have been leading software projects for about 7 years, and my largest projects have been right around 5-8 Full Time Equivalent (FTE).  I am now facing the prospect of leading a 14 FTE project... this is a first for me.  

One concern of leading a project of this size is the increasing number of individual communication links that would be needed for everyone on the team to know what everyone else on the team is working on to maintain shared situational awareness on the project.  

To illustrate this, you can see how the communication links will continue to increase non-linearly with more and more staff.  L = number of communication links, T = number of members of the team.

Additionally about half of the 14 Full Time Equivalent (FTE) project team are co-located in an agile bullpen room, while the other half are geographically distributed across the East Coast... from Massachusetts, New Jersey, Virginia, all the way down to Florida.  The good news with this distributed team is that the entire roster will be based in Eastern Standard Time.  At least we will not be depriving individuals of sleep with meetings that span numerous time zones!

My thoughts of dealing with this if/when this new project starts, and try the Scum Alliance model of hosting a "Scrum of Scrums".  My current plan is to have co-located team maintain their agile "bullpen" and have one scrum, and have the geographically-distributed team scrum either after or before them.  The two team would have a size of approximately 7 FTE each.  They should both be able to maintain a cross-domain roster of engineers, healthcare informaticists, clinicians, policy leaders, and Clinical Quality Measure SMEs.  

To follow the "Scrum of Scrums" process, I plan to identify a scrum master from each team, and after the daily scrums, the scrum masters, product owner and stakeholders will host a second scrum.  Again following the Scrum Alliance variant on the "Scrum of Scrums" meeting, the agenda for that meeting will deviate a little by addressing the following questions:

Because the "Scrum of Scrums" meetings may not be daily and because one person is there representing his or her entire team, these three questions need to be rephrased a bit to be "team-focused" and they suggest it's beneficial to add a fourth question, identifying if the two teams might be unintentionally stepping on each others' toes:

1. What has each team done since yesterday?
2. What will each team do today?
3. Are there any impediments to the team's plan today?
4. Are you about to put something in the other team’s way?

It looks good and makes sense.  I hope to report out on how this "Scrum of Scrums" works.  

Fingers crossed...

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.