Measures Metadata

Introduction

The purpose of the measures.json metadata is to make the Web Interface system as dynamic as possible allowing changes in measures from year to year to be made without requiring code changes in the API or the Web Interface UI. It is also informational and contains measure descriptions and measure questions that non-technical CMS personnel can modify to update the measure definitions at runtime.

You can download the measures.json specification can be viewed and/or fetched for your own purposes here

The schema.json used to validate the structure of the metadata can be found here

Measure Data Model

Confirmation

For every measure, e.g. CARE-2, a patient can be confirmed, or not confirmed for any of a number of different reasons, represented by different confirmation values. Certain confirmation values may require a help desk ticket number to be entered for that measure for the patient.

Attributes

A set of attributes can be defined for each measure. The value is stored as a string but data type and other kinds of validations can be applied before storing the value.

An attribute can have many values but by default is assumed to have one.

Scopes

Attributes can have values in different attribute scopes. The full set of scopes for a scope group is defined using an attribute that corresponds to the name of the group. The distinct values of a scope group attribute define all the possible scopes for the scope group with that name. As with any kind of attribute data, scopes are per patient. One patient will have a different set of scopes than another for the same scope group.

Interaction Model

The first step is to confirm the patient for a measure. Attribute data should not be allowed until the patient is confirmed for the measure.

Once confirmed, attribute data can be entered. Data entry for certain attributes may be prohibited until data for some other related attribute is entered and meets certain conditions, i.e. it equals a certain value, or is valid (or not), or meets its performance (or doesn’t).

Basic Validity Rules

Dependencies

Dependencies between attributes can be defined with the requiredAttribute property of an attribute definition. Data should not be allowed for the dependent attribute until the required attribute meets the specified condition. There are three types of conditions that can be defined:

• Value: The related attribute must equal some value. Ex:

  "requiredAttribute": { "name": "foo", "value": "bar" }
  

• Valid: The related attribute must be valid or not. Ex:

    "requiredAttribute": { "name": "foo", "valid": true }
  

• Performant: The related attribute must be performant or not. Ex:

    "requiredAttribute": { "name": "foo", "performant": false }
  

Inputs

We can define rules against the input control used to enter data for an attribute with the input property.

Types

The type of an attribute defines the type of input control presented to allow the user to enter data for the attribute.

• text (default)
• radio
• select

Choices

We can define choices for an input. Each choice has value and a label. Ex:

"choices": {
  "Y": { "label": "Yes" },
  "N": { "label": " No" }
}

The choices define the valid values for that attribute. The UI can constrain the interface to only present and allow the specified choices.

Data Types

The data type of the attribute can be defined with the dataType property of an input: “string” (default), “number”, integer, or “date”.

Measure Specifications

The CMS Web Interface Measure Specifications can be downloaded from the QPP Resource Library here.