Showing posts with label kamira. Show all posts
Showing posts with label kamira. Show all posts

October 31, 2013

Meaningful Use Stage 2 Clinical Quality Measure Analysis Against Live Patient Data

The Meaningful Use Stage 2 Clinical Quality Measures (CQMs) reference a wide variety of clinical data elements.  As part of the Kamira research project that I am wrapping up, we jointly developed a paper that describes the results of a study with the Massachusetts eHealth Collaborative (MAeHC).  The purpose of the paper was to determine data elements which are present in a large operational patient population and to describe the impact of missing data elements as components to the CQMs.

The full paper is publicly available on the Kamira site here.

To highlight, some of the results of the study determine the presence or absence of each of the clinical codes used in MU2 CQM data elements using a large set of patient data (500k patient records covering 5M care events) collected by MAeHC.  The results were used to determine the impact on the MU2 CQMs at two levels:
  • Clinical data elements were ranked according to the intersection of their component clinical codes and the codes present in the patient data 
  • CQM populations were classified according to the ranks of their component clinical data elements. 
The results of this analysis were then used to determine which CQMs are likely to work well with the patient data and which require data that is not present.

Some key findings of the paper include:
  • The majority of the clinical codes used in value sets referred to by the MU2 CQMs are not found in patient data. Very few of the SNOMED (0.03%) and LOINC (2%) codes used in MU2 CQMs are found in the patient data.
  • Many value sets do not contain any codes that are present in the patient data: across all measures over half of the MU2 CQM value sets contain no codes. Such value sets are referred to as non-intersecting.
  • There are many measure populations containing only non-intersecting value sets. Across all measures, nearly 60% of distinct denominators and 27% of numerators reference only data that is not present in the patient records. Such measures will, by definition, report 0/0 or 0/n results.
Below is an illustration taken from the paper that details code occurrence of what is available in Meaningful Use Stage 2 for ICD-9, LOINC, SNOMED, CPT, CVX and RxNorm. Each bar represents all of the codes from the respective code system defined in Meaningful Use Stage 2 for the Eligible Professional CQMs.  The blue segments of each bar show the percentage of codes that are present in the system.


Another compelling illustration is the value set intersection results.  A value set contains one or more codes from one or more clinical vocabularies for a clinical concept, like "Diabetes". Given the code occurrence results above it is possible to compute the intersection of each Meaningful Use Stage 2 CQM value set with the patient data as follows: I=P/T where I is the intersection, P represents the number of codes in the value set that are present in the data and T represents the total number of codes in the value set.

Below, each bar represents the total number of value sets for either both Eligible Hospital and Eligible Professional CQMs (All), just the Eligible Hospital (EH) CQMs, or Eligible Professional (EP) CQMs.  Each bar is subdivided to show the proportion of value sets with different levels of intersection.


A key takeaway from this paper is that the majority of the codes used in the value sets referred to by the Meaningful Use Stage 2 Eligible Professional CQMs are not found in the operational patient data.

Only finding a minority of the codes would not necessarily be a problem... value sets may contain many codes and provided one of those codes is present in the patient data, the corresponding data element will be also be satisfied.  Unfortunately, the value set intersection results show that many value sets contain no codes actually present in the patient data. Across all measures over half of the MU2 CQM value sets contain no codes.  The primary reason for non-intersecting value sets is choice of code sets: 73% of the non-intersecting value sets include only some combination of SNOMED-CT, LOINC and ICD-10 codes.  All of these are scarce in the live/operational patient data.

Additionally, the non-intersecting value sets are not distributed evenly across all measure populations where their impact would be lessened.  Instead, there are many CQM populations containing only non-intersecting value sets.  Across all measures, nearly 60% of distinct denominators and 27% of numerators reference only data that is not present.  Such CQMs will, by definition, report 0/0 or 0/n results… every time.  Yikes!!!

Admittedly, this is only one sample point of data using a single practice.  However, it is data from coded clinical source used by a national leader in healthcare information technology.  If this issue is present in other operational EHR systems (as I strongly suspect) the only way to address this problem moving forward in MU Stage 3 will be to re-consider the required clinical codes that need to be capture in the EHR systems used operationally... or refine the translations from clinical concepts to clinical codes.

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

July 10, 2013

Applying Cost To Clinical Quality Measures

With the Kamira research project that I am leading, our team was able to instrument the Meaningful Use (MU) Stage 2 Clinical Quality Measure (CQM) logic with the procedural logic for calculating the results of the CQMs via the popHealth project.  What this popHealth CQM calculation software provided the Kamira team was the clinical building blocks of the CQM logic, which we were able to marry with publicly available claims data hosted by CMS based on de-identified real-life claims records.

With the CQM calculation land this collection of claims records, we were able to asses ranges of the cost associated with addressing the MU Stage 2 CQMs.  With this, we were able to provide a guess for how much cost would be introduced into the healthcare system if a provider were to attempt to address the numerator logic of an MU Stage 2 CQM.

Consider the MU Stage 2 CQM "NQF 0062: Diabetes Urine Protein Screening".  This CQM measures the percentage of patients 18-75 years of age diagnosed with diabetes who had a some form of urine screening during the measurement period.  However, if you look at the conditional logic of this CQM, you can see that having the dialysis procedure would 

Numerator logic for NQF 0062 "Diabetes Urine Protein Screening"
Procedural numerator logic for "NQF 0062: Diabetes Urine Protein Screening"

When we applied the CMS claims data, you can see the wide range of costs associated with this particular CQM's numerator logic, spanning microalbumin testing, ACE inhibitor, and access to dialysis:

Numerator costs on NQF 0062 - Diabetes Urine Protein Screening
Numerator costs on NQF 0062 - Diabetes Urine Protein Screening
As a non-clinician, the first two tests in the numerator logic make sense to me (microalbumin lab tests).  They appear to be in the "spirit" of this CQM, measuring if the provider has performed the microalbumin lab test for kidney damage.  However, the Kamira automated cost assessment highlighted that the vascular access for dialysis is clearly a much more expensive procedure to address this numerator logic than the lab test.  We didn't have any claims data on the kidney transplant from our sample set, but I can only speculate that the cost for that claim would be in the six figure range.

Looking purely at the CQM logic, and not applying any clinical perspective on this CQM, the vascular access for dialysis procedure is viewed as equivalent to the microalbumin lab test, at least within the scope of in this CQM logic.  Both are equal when assessing if the provider is performing the best quality of care for their population of diabetic patients.  Again... a kidney transplant is also in that same category as being semantically equivalent to the microalbumin lab test!!!

On the flip side, it appears to me that vascular access for dialysis is meant to address a known clinical problem, whereas the microalbumin lab test is designed to only collect and present information to a provider.  This difference in the clinical purpose of the clinical activities is not considered in the CQM logic.  Again, the CQM logic views both as equivalent when measuring the quality of care that a provider is applying to their population of patients.

Based on the Kamira automated CQM cost analysis, my recommendation is to groom the logic of "NQF 0062: Diabetes Urine Protein Screening", and re-position the dialysis procedure probably belongs in the exception or exclusion logic, vs. the current numerator logic.  There are some additional opportunities to apply this cost consideration on all Meaningful Use Stage 3 CQMs.  By applying these cost metrics to the MU Stage 3 CQMs, at minimum, the policy makers could discuss the impact of cost with the numerator logic clinical data.  Additionally, these conversations could potentially lead to streamlining and pruning the MU Stage 3 CQM logic to avoid noisy and high variance healthcare costs within the logic of one CQM.

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

May 17, 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
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.
Creative Commons License

February 5, 2013

Complexity Analysis of MU Stage 2 Eligible Professional Clinical Quality Measures

I recently wrote about the initial release of the MITRE open source Kamira project to assess the quality of Clinical Quality Measures (CQMs).  The initial focus of the Kamira project has been the Cyclomatic Complexity analysis of the CQM logic.

The Kamira project has listened to my evangelizing the use of Kiviat charts as the visualization technique used with CQMs.  In addition to being fairly useful for understanding the CQM complexity results, I have found that the Kiviat visualizations also have a "sexiness" factor that I have been leveraging to continue the research.  See the Kamira Cyclomatic Complexity dashboard design below:

Kamira complexity dashboard design
Kamira complexity dashboard design
What we did with the Kiviat visualization for the complexity results is leverage the five attributes that could always be used for parts of the CQM algorithmic logic:
  • Initial Patient Population (IPP)
  • Denominator 
  • Numerator 
  • Exclusion 
  • Exception
We then associated ranges for the complexity metrics based on the Carnegie Mellon University paper that I identified a few months ago.  These ranges are:
  • 1-10: Very Simple, Low Risk (green)
  • 11-20: Nominal, Moderate Risk (yellow)
  • 21-50: Complex, High Risk (orange)
  • >50: Untestable, Extreme Risk (red)
Since we wanted to highlight the worst/highest component of the CQM, we opted to color in the area of the five metrics with the worst/highest section of the algorithmic logic.

Because some of the MU Stage 2 CQM logical sections far exceeded CMU's threshold of 50 for "Untestable, Extreme Risk" we found that there were some CQMs that had logical sections that were "off the scale" when it came to Cyclomatic Complexity.  The worst violator is "NQF 0038: Childhood Immunizations" which is actually part of the core set of MU Stage 2 for Eligible Professional CQMs.

Since we couldn't use a linear scale for those CQMs, so we capped the scale at 60, and switched the presentation of the results around by providing a red background around the Cyclomatic Complexity value.  Normally, there isn't a background and the results are just black text.  The idea here was to try and call out that there was something fundamentally wrong with complexity values that are so high.

See the 6 most complex CQMs for MU Stage 2 Eligible Professionals (EP) below:

6 Most Complex CQMs for MU Stage 2 Eligible Professionals
6 Most Complex CQMs for MU Stage 2 Eligible Professionals
From a software engineer's perspective, if you have to manually implement these CQMs in software code, you are going to be very hard pressed to test and validate that any system implementing this logic accurately.  Ie. you have a challenging job ahead of you to test that any implementation of these 6 CQMs are in fact accurate.  This also means that there's a higher probability of having a lurking software bug in your implementation.

Also, for healthcare providers who need to understand these CQMs in order to improve the quality of care that they are providing to their patients, they will also have a challenge.  Providers needing to maintain a mental model of the CQMs and understand what actions should be taken for their patients will likely face challenges.

Ideally, the complexity of the CQMs should never even get this high.  What I would want to see is some consideration by measure stewards on Cyclomatic Complexity during the development process.  Another consideration for the policy leaders would be refusal to accept any CQM submitted that had a Cyclomatic Complexity value that exceeded a threshold.

The Kamira project's work has initially focused on the Meaningful Use Stage 2 Eligible Professional CQMs.  The reason that these were initially selected is because we were easily able to instrument the JavaScript code that is implemented in the popHealth and Cypress project's quality measure engine.  However, the work can be expanded to include the MU Stage 2 Eligible Hospital (EH) CQMs when those are implemented in popHealth and Cypress, currently planned for late April 2013.  Unfortunately, I expect that the EH CQMs will actually be more complex than the EP CQMs.

Additionally, I have plans to expand the work into financial analysis and feasibility of implementing CQMs, but for now the lowest hanging fruit was the complexity analysis.

The full visualization of the Meaningful Use Stage 2 CQM Complexity Data is available here, and the detailed results in a JSON file is available here.

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