Skip to main content

Measure Testing


Ideally, the measure developer should perform feasibility testing very early in the development process, preferably, right after establishment of the measure’s description, numerator, and denominator; after identification of the required data for measure calculation; and before finalization of specifications.

Feasibility testing is especially important for electronic clinical quality measures (eCQMs). Given disparate electronic health records (EHRs) and other electronic clinical systems, collection and storage of required data elements may be different. Therefore, the presence or absence of a data element in the EHR and other electronic clinical systems will inform whether the required data elements will be in the measure specifications or whether the measure developer will need to explore other similar data elements. eCQMs have a separate feasibility scorecard assessing data availability, data accuracy, data standards, and workflow. However, measure developers can adapt the scorecard for non-eCQMs. The current requirement for eCQM testing is more than one vendor product. 

The measure developer should use testing to assess measure feasibility. One aspect of feasibility is the extent to which required data are available and retrievable without undue burden, and the extent to which measure developers can collect and process data for performance measurement. The measure developer may obtain some feasibility information when assessing validity of the measure score or data elements (e.g., quantifying the frequency of absent diagnosis codes when a target condition is present). The measure developer should obtain other feasibility information using systematic surveys (e.g., survey of physician practices tasked with extracting the information). They may choose to gather more in-depth information by conducting focus groups composed of professionals who may be responsible for a measure’s implementation.

Feasibility Assessments

Feasibility assessments should address

  • Availability of data (e.g., evidence of routine generation and use in care delivery of required data, including any denominator or numerator exclusion criteria)
  • Extent of missing data, measure susceptibility to inaccuracies, and the ability to audit data to detect problems
  • Estimates of the costs or burden of data collection, data entry, and analysis including the impact on clinician workflow, diagnostic thought processes, and patient-physician interaction
  • Barriers encountered in implementing quality measure specifications, data abstraction, measure calculation, or performance reporting
  • Ability to collect information without violation of patient confidentiality, including circumstances where measures based on patient surveys or the small number of patients may compromise confidentiality
  • Identification of unintended consequences
Last Updated: