CMS FHIR Quality Measure Development IG, published by Centers for Medicare & Medicaid Services (CMS). This guide is not an authorized publication; it is the continuous build for version 0.8.0-cibuild built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/cqframework/cms-qmd/ and changes regularly. See the Directory of published versions

Pattern Index

This page indexes the data elements and authoring patterns available to CMS dQM developers, across both this guide and the US CQL implementation guide. It is intended as the single starting point for locating guidance on a given data element.

Each pattern is listed once. Where this guide documents a pattern, the link goes here, and that page links on to the underlying US CQL guidance where it exists. Where a pattern is documented only in the US CQL guide, the link goes there directly.

NOTE: The patterns in this guide are authored against US Quality Core 0.5.0, while the US CQL patterns are authored against US Core directly. Retrieves therefore differ in the model qualifier — [USQualityCore.AllergyIntolerance] here, [USCore.AllergyIntolerance] there — but the element-level guidance applies to both. See Authoring against the US Quality Core model.

Each pattern page opens with a link to the modifier elements, search parameters, and cross-version considerations for its resource in the US CQL guide, where those apply.

Overall

Guidance that applies across all resources, from FHIR Patterns and Negation Patterns in this guide, and from the Using CQL With FHIR implementation guide.

Pattern	Description
Element cardinality	What cardinality does and does not tell an author about whether an element will be present.
Must support elements	Restricting logic to elements an implementation is required to provide when it has them.
Modifier elements	Elements whose value changes the meaning of the resource, including modifier extensions and implicitRules.
Authoring against the US Quality Core model	Derived ModelInfo, the required version on the using declaration, and why extensions are reached through fluent functions.
Accessing data	The retrieve expression, model-qualified type names, and the status functions to apply when accessing a resource.
References	Best-practice for dealing with references in FHIR resources.
Use of terminologies	When to use =, ~, and in, the prohibition on string-based membership testing, and direct-reference code requirements.
Primitives	Whether a .value accessor is required; under derived ModelInfo elements carry FHIR types, with FHIRHelpers supplying the conversions.
Choices	Elements that may take several types, such as Condition.onset, and the FHIRCommon interval helpers over them.
Slices	Accessing sliced elements, such as blood pressure components through systolic() and diastolic().
Extensions	Reading extension values where no fluent accessor is defined; see also the Extension Index in the Refactored Index.
Missing Information	Null propagation, the is true and is not true predicates, and the treatment of unknown status codes.
Date, Time, and DateTime Values	Being explicit about comparison precision, typically day of.
Timezone and Timezone Offset Handling	Day-boundary calculations such as “on hospital day 2”.
Time-Valued Quantities	Calendar durations (year, month) versus UCUM definite durations ('a', 'mo').
Overall Patterns	The US CQL treatment of the same element considerations, plus its naming best-practices for shared library declarations.
Choosing a negation pattern	Absence of evidence versus negation rationale, and when a negation profile is not the right choice.
Use cases for negation rationale	The three use cases and the ten US Quality Core negation profiles that realize them.
Extent of negation	Negating a specific activity versus an entire value set, through the notDoneValueSet extension.
Working with doNotPerform	Why is not true rather than an equality comparison, given the profiles that fix the element.
Positive requests and rejected proposals	Excluding requests that carry a rejecting Task when looking for a positive request.

Patient

Pattern	Description
Patient age	Age calculated as of a specific date, usually the start of the measurement period, and the precision pitfalls of the DateTime overloads.
Patient race and ethnicity	Reading the US Core race and ethnicity extensions through the race() and ethnicity() fluent functions, and the tuple each returns.
Patient name	Accessing a patient’s name.
Patient birth date	Accessing the birth date directly rather than through an age calculation.
Patient gender	The administrative gender element and its required binding.
Patient sex	birthSex(), the deprecated sex(), and the forward-compatible individualSex().
Patient deceased	The deceased choice element, as either a boolean or a date and time.

Allergies and intolerances

Pattern	Description
Current allergies	Retrieving allergies to a substance, and why isActive() is unsafe for the retrospective evaluation a measure performs.
No known allergies	The confirmed and not-asked forms of a no-known-allergy assertion, and which one a measure should use.
Clinical and verification status	The FHIRCommon verification-status functions, in place of re-declaring them locally.
Onset, abatement, and prevalence interval	Computing a prevalence interval from onset, abatement, and resolution age — the reliable way to establish that an allergy was active during a period.
Allergy examples	Worked examples for contrast dye, egg, and nut allergies.

Conditions

Pattern	Description
Active conditions	Retrieving active conditions, the category functions that distinguish problem list items from encounter diagnoses, and the retrospective caveat on isActive().
Verified conditions	Excluding refuted and entered-in-error conditions using the FHIRCommon verification-status functions.
History of a condition	Unioning the two condition profiles, since US Quality Core profiles problem list items and encounter diagnoses separately.
Onset, abatement, and prevalence period	prevalenceInterval() and abatementInterval(), and why they are preferred over clinicalStatus for a question about a period.
Diagnosis during an encounter	Establishing that a diagnosis was active during an encounter across reasonCode, reasonReference, and claim diagnoses.
Condition category	Distinguishing problem list items, health concerns, and encounter diagnoses.
Relevant condition	Taking the condition from workflow context rather than searching for it.

Encounters

Pattern	Description
Office visit encounters	Characterizing encounters by type with a value set.
Encounters by direct-reference code	Why a direct-reference code cannot filter the multi-cardinality type element in a retrieve, and the two workarounds.
Encounters by class	Filtering by class, which is required in US Core and single-cardinality, and why it is the preferred first filter.
Completed encounters in a period	Filtering on status and period together.
Encounters of a certain length	lengthInDays() and direct duration calculations, and what an absent period end implies.
Hospitalization	The thirteen CQMCommon functions spanning an inpatient stay and any immediately prior emergency department or observation encounter.
Present on admission	The clinical representation, using the presentOnAdmission extension on Encounter.diagnosis.
Principal diagnosis	The clinical representation, using Encounter.diagnosis with a use of billing and a rank of 1.
Primary procedure	The clinical representation, where Encounter.diagnosis.condition references a Procedure rather than a Condition.
Discharge disposition	The clinical representation, using Encounter.hospitalization.dischargeDisposition.
Admission source	The clinical representation, using Encounter.hospitalization.admitSource.

Observations

Pattern	Description
Vital signs	Retrieving each US Core vital sign profile, and reading blood pressure components through systolic() and diastolic().
Laboratory results	The laboratory result profile, characterized by code with category fixed to laboratory.
Clinical results	Non-laboratory clinical test results, including measurements obtained from imaging.
Screening and assessment	Survey observations, including panels and multi-select answers.
Simple observations	Observations not covered by a more specific profile, and why the status test matters more here.
Pregnancy status	Establishing pregnancy across an observation, a laboratory result, an encounter diagnosis, and a problem list item.
Pregnancy intent	Intent to become pregnant within the next year.
Smoking status	The US Core smoking status profile.
Non-patient observations	Observations about resource use and availability rather than a patient.
Observations not done	Representing an observation that was not performed, as a rejected proposal.
Observation status	isResulted() and the individual status predicates, in place of inline status lists.
Observation category	The category functions, including isLaboratory(), isVitalSign(), and isSurvey().
Interpretation	The positive() and negative() filters, and why the element cannot be relied on.
Timings	Filtering and ordering observations by effective time, including specimen collection time.
Observation elements	The elements common across the observation profiles.
Other observations	Observations outside the profiled categories.

Services and procedures

Pattern	Description
Procedure performed	Retrieving a completed procedure, and accounting for the unconstrained status.
Procedure ordered	Retrieving a service request, excluding rejected proposals, and choosing ServiceRequest over DeviceRequest.
Procedure not done	Documenting the reason a procedure was not performed.
Procedure not ordered	Distinguishing a prohibition from the rejection of a proposal.
Imaging procedures	How far to look for evidence of an imaging procedure across order, procedure, report, and study.
Mammography	A worked example spanning the resources that may record a mammogram.

Medications

Pattern	Description
Medication status and intent	The status and intent functions drafted in MedicationCommon, in place of inline code lists.
Medication ordered	Retrieving a medication order, including the guard against a rejected proposal.
Medication administered	Retrieving a completed administration.
Medication dispensed	Retrieving any positive dispensing event.
Medication in use	Medications a patient is taking outside the hospital setting.
Self-administered OTCs	Over-the-counter medications, distinguished by category rather than code.
Medication not ordered	A documented prohibition, and how it differs from a rejected proposal.
Medication not administered	Documenting the reason an administration did not occur.
Medication not dispensed	Documenting the reason a dispense did not occur.
Electronically transmitted prescriptions	Identifying the transmission method of a prescription through the PDMP extension.

Devices

Pattern	Description
Device ordered	Ordering a patient-use device, and when ServiceRequest is the right profile instead.
Device in use	Establishing that a device is actually in use rather than ordered.
Device not ordered	A documented prohibition, and the rejected-proposal alternative.

Immunizations

Pattern	Description
Immunization performed	Retrieving an administered immunization by vaccineCode.
Immunization not performed	Documenting the reason an immunization was not administered.

Communication

Pattern	Description
Communication	Information transmitted about or with the patient, and when Procedure is the better choice.
Communication not done	Documenting the reason a communication did not occur.

Claims and coverage

Pattern	Description
Claim elements used by measures	The ClaimElements definitions that unfold a claim into flat elements keyed to the encounter, and the ClaimCommon predicates that go with them.
Present on admission	The claim representation, using Claim.diagnosis.onAdmission with the CMS indicator codes.
Principal diagnosis	The claim representation, identified by Claim.diagnosis.type.
Primary procedure	The claim representation, identified by Claim.procedure.type.
Discharge disposition	The claim representation, reached with dischargeStatus() over Claim.supportingInfo.
Admission source	The claim representation, reached with pointOfOrigin() over Claim.supportingInfo.
Claim status, use, and type	The ClaimCommon predicates that select active professional or institutional claims and explanations of benefit.
Claim items	Selecting the items of a claim; superseded by the ClaimElements definitions above.
Explanation of Benefit items	Selecting the items of an adjudicated response; superseded by the ClaimElements definitions above.
Mammography claim	A worked example over claim and EoB items, built on the superseded item definitions.
Coverage status	Restricting to active coverage, the only modifier element on the resource.
Member or subscriber ID	memberID() and policyNumber(), and the invariant requiring one of them.
Payer	SDE Payer for supplemental data reporting, and the status filter it omits.

Billing-related elements

Pattern	Description
Billing-related elements	Why these elements have several representations, and how to choose between the clinical record, the claim, and the adjudicated response.
Preferring claim information	The shape for using claim information when it is present and falling back on the clinical record when it is not.
Present on admission	Whether a diagnosis was present at admission, on the claim and in the clinical record; both use the same CMS indicator codes.
Principal diagnosis	The diagnosis chiefly responsible for the admission, identified by claim diagnosis type or by encounter diagnosis rank.
Primary procedure	The procedure identified as primary, on the claim and in the clinical record.
Discharge disposition	Where the patient went after the encounter; the two representations use different code systems, so the fallback needs a value set for each.
Admission source	Where the patient came from; carried as point of origin on the claim and as admitSource in the clinical record.