Skip to content

MEASURES.md

Latest commit

 

History

History
679 lines (586 loc) · 53.7 KB

MEASURES.md

File metadata and controls

679 lines (586 loc) · 53.7 KB
Raw

WorkWell Measure Catalog

WorkWell is one product with several instances. The TWH instance (employees) runs the OSHA, wellness and immunization measures, plus CMS122 and CMS125 on CMS's FHIR drafts. The Maui sandbox (patients) runs six CMS measures on those drafts. The catalog below is seeded on startup, and each instance runs its own subset of it.

Catalog summary

Category Count Status CQL
OSHA occupational safety — fully evaluated 4 Active Full CQL, runnable
OSHA occupational safety — catalog only 2 Draft / Deprecated Partial or no CQL
HEDIS wellness — fully evaluated 5 Active Full CQL, runnable
Permanent immunization panel — fully evaluated 3 Active Full CQL, runnable (series-completion; MMR, Varicella, Hep B)
CMS eCQM — authored CQL kept beside the official artifact 2 Active WorkWell's own CQL for CMS125 and CMS122; TWH and Maui both run CMS's FHIR drafts for these
CMS eCQM — official-only (no authored CQL) 4 Active CMS2, CMS130, CMS165, CMS137 — the vendored artifact IS the logic (ADR-072)
CMS eCQM catalog (2026 performance period) 43 Draft Catalog entry only — CQL authoring pending
Total 63

Runnable (full CQL): 14 — 4 OSHA + 5 HEDIS + 3 immunization panel + 2 CMS eCQM. Hepatitis B was promoted from an Approved catalog entry to Active (E10.6).

Active is not runnable, and runnable is per deployment (ADR-072). The four official-only measures (cms2, cms130, cms165, and since 2026-09-06 cms137 — the Draft cms137v14 placeholder was retired into it by the ADR-071 seed, the way cms2v15 was) have no authored CQL and no synthetic binding: they are runnable only where the deployment names them in WORKWELL_OFFICIAL_MEASURES, and classifyRunnable reports them as official-pending everywhere else. Since 2026-09-08 the Maui sandbox routes all six (ADR-078, owner decision): cms122, cms125, cms2, cms130, cms165 and cms137, so CMS2, CMS130, CMS165 and CMS137 are Active, gated AND executing there; TWH still routes cms122 and cms125 only. All four pass their full MADiE deck against the runtime (36/36, 64/64, 68/68 and 45/45, zero errors); cms2's whole-roster gate reads 17,795 of 20,000 in the initial population and 5,413 actionable (docs/evidence/FLIP_GATE_2026-09-08_CMS2.md); cms130's, run through the credentialed .github/workflows/flip-gate.yml, reads 64/64 and 9,257 in the initial population with 4,997 actionable (FLIP_GATE_2026-09-08_CMS130.md), and cms165's 68/68 and 6,837 with 2,431 actionable (FLIP_GATE_2026-09-08_CMS165.md) — on the sandbox corpus, which is all it claims. CMS137 is multi-rate (Initiation and Engagement, ADR-074): one catalog row, one outcome per patient reduced to the worst rate, and every rate persisted and exported — and the roster cell, the case detail, the case's next action and the CDS card name the rate the patient actually missed ("without treatment initiation within 14 days" or "initiated but not engaged within 34 days"), read from the persisted rates (ADR-074 d13). All four sit in the roster's quality panel, so each becomes a column the day its flip routes it. CMS137's MM-1c verification is done on the sample the unit ran (2026-09-06): the flip gate over the first 2,000 of the corpus roster reads evidence FOR the flip (45/45 MADiE, 60 in the initial population, both rates alive), and the second-engine sweep agrees on 44/45 cases on both rates, the one disagreement characterised as a period-boundary difference (docs/evidence/CROSS_ENGINE_2026-09-06_CMS137.md). The whole-roster run the flip PR needs is now banked (2026-09-07): flip-gate --measure cms137 --subjects all over all 20,000 corpus patients reads 45/45 MADiE, 599 in the initial population and denominator, 518 actionable, 0 evaluation errors, with both rates alive (numerators 231 and 81) and the effectivePeriod covering the measured year — evidence FOR the flip on the full roster, not a 2,000-subject sample (docs/evidence/FLIP_GATE_2026-09-07_CMS137.md). Its flip landed with the others on 2026-09-08 (ADR-078); it is un-routed, if the final rule removes Quality ID 305, by removing it from both WORKWELL_OFFICIAL_MEASURES and WORKWELL_DERIVED_MEASURES (DEPLOY.md, "Turning a translation on or off"). For 2027, Maui scores it with WorkWell's translation of CMS137v15 (ww-2027.1, #767), never under a CMS eCQM id.

Every cross-engine disagreement is run to a cause (2026-10-19, #846). On a Java image pinned by digest (cqf-fhir-cr 4.13.0), the second engine agrees on 397 of 455 MADiE cases across all nine measures with the measurement period sent. The 57 that differ are Java's second-precision period, which makes an event at the period's last second "uncertain" to it: CMS165 54, CMS125 2, CMS137 1. With the measure's default period none remain. One CMS165 case makes the Java engine throw. CMS2's seven, and the other medication disagreements first seen in August, were an older Java image's bug in convert … to days and agree on the pinned image (docs/evidence/CROSS_ENGINE_2026-10-19.md). That closes #572, the cross-engine condition §4A.5 put on CMS165's PHI phase; its other condition, profile-stamped blood pressures at ingest (#591), stands.

For 2027, Maui scores CMS130 with WorkWell's translation of CMS130v15 (ww-2027.1, #779), never under a CMS eCQM id. v15 changes one line of logic, in the shared frailty library: an advanced-illness diagnosis now counts when it overlaps the year before or the measurement year, where v14 required it to start in that window. So a frail patient 66 or older with a long-standing, still-active diagnosis, or an active one with no onset date, is now excluded. Ten value sets change too. The edit is proven by hand-built test patients that tell the two rules apart; neither CMS's test decks nor the 2027 Cypress deck exercises it (backend-ts/measures/derived/cms130/README.md).

For 2027, Maui scores CMS125 with WorkWell's translation of CMS125v15 (ww-2027.1, #782). It carries the same frailty edit, and v15's mastectomy changes: which side a unilateral mastectomy was on now comes from the procedure's body site ("entire left/right breast", a new value set), and the old path through an unspecified-laterality diagnosis with a left/right qualifier is gone; the end-of-period comparisons become day-precise. Because a value set moved, the translation's computed data requirements were edited to match its logic. On CMS's own test deck three patients move (two lose the exclusion, one gains it through the frailty edit), each listed and explained; 22 hand-built patients test every edit (backend-ts/measures/derived/cms125/README.md).

For 2027, Maui scores CMS165 with WorkWell's translation of CMS165v15 (ww-2027.1, #816). Its blood-pressure logic is CMS's, unchanged. Its exclusions follow v15: the same frailty edit; pregnancy and renal diagnoses become two exclusions, and a renal diagnosis (ESRD, CKD stage 5, kidney transplant status) now counts when it started on or before the year's end, even if it ended earlier; kidney transplant status is the code Z94.0; the ESRD monthly-visit exclusion is gone; and the hypertension window and the dialysis date comparisons become day-precise. On the 2027 Cypress deck it matches 42 of 44 patients: the other two are blood pressures taken during an emergency stay, which CMS's own logic misses the same way, because a QRDA file does not tie a reading to its visit. On CMS's own test deck two patients move, each explained; 14 hand-built patients test every edit (backend-ts/measures/derived/cms165/README.md).

For 2027, Maui scores CMS122 with WorkWell's translation of CMS122v15 (ww-2027.1, #818). It carries the same frailty edit, and v15's change to which HbA1c or GMI the numerator reads: the most recent day counts only a result above 0 %, and the reading is the lowest number that day, else the most recent number in the year, else the most recent result-less one. So a result-less test beside a numerical one on the same day, or on a later day, no longer makes the patient "poor control". The 2027 Cypress deck agrees on 64 of 64; on CMS's own test deck no patient moves; 12 hand-built patients test every edit (backend-ts/measures/derived/cms122/README.md).

For 2027, Maui scores CMS2 with WorkWell's translation of CMS2v16 (ww-2027.1, #822). A positive depression screen counts in three ways: a follow-up from the screening to two days after the visit (v15: during the visit, or ordered up to two days after it), active depression management (new in v16), or an antidepressant active over and after the visit, whenever it was ordered. CMS's FHIR draft had no separate active-medication path. The 2027 Cypress deck agrees on 379 of 379; on CMS's own test deck one patient moves into the numerator (an active antidepressant ordered a year before the visit, with no stated end); 19 hand-built patients, 10 of which tell the logics apart (backend-ts/measures/derived/cms2/README.md).

CMS165 reads a blood pressure by its profile, and nothing else by profile (#591, 2026-10-10). CMS165 is the only pilot measure whose decisive retrieve identifies a blood pressure by PROFILE alone with no code filter. Read by resource type, it matched any final Observation, so a patient with any other lab read as non-compliant and a same-day non-BP Observation threw (verified by execution 2026-09-05).

So the executor reads cms165 by type, except that retrieve, which keeps only resources stamped us-core-blood-pressure (OFFICIAL_MEASURE_SEMANTICS.cms165.trustedProfiles). prepareForQiCore derives that stamp from the codes a resource already carries, which no other layer can do. It is the only profile whose code-less retrieve picks out part of its type; the other four code-less retrieves name their type's one QI-Core profile, and a test pins the list (official-cms165-retrieves.test.ts).

From 2026-09-07 to 2026-10-10 cms165 trusted EVERY profile. That needed qicore-patient, qicore-encounter, both Condition profiles and more, which only the corpus stamps, so every QRDA-imported or WebChart patient threw. On the same data the narrowed trust is identical to it: CMS's 68 MADiE cases, and all 20,000 corpus patients. QRDA states a blood pressure as two readings, a systolic and a diastolic at one time; the importer makes them one panel only under LOCKED §4A.8's conditions. A document may instead state one Physical Exam coded 85354-9 with its two readings as QDM Components: that is imported as the panel it states, under §4A.8's value rule (#794). With both changes the Cypress deck scores 42 of 44, from 0 (both years). The two left are readings taken during an ED visit or an inpatient stay: CMS's draft leaves those out only through Observation.encounter, which QRDA does not carry and the importer does not infer.

cms165 is routed on the SANDBOX (ADR-078) and must not be routed over WebChart data until #591's remaining half is closed: WebChart exports its BP panel with status: "unknown", while the measure admits only final | amended | corrected, and without Observation.encounter a reading taken in an ED or inpatient stay is counted. CMS165's cross-engine sweep is also unexplained (#572). Both sit in the PHI readiness gate. The batch-level retrieve refusal fires only for a roster of more than one subject.

An officially routed measure is scored over the calendar year containing the evaluation date, not a rolling 365-day window (ADR-072). The vendored artifacts are a 2026 vintage and the pilot year is 2027. Where a WorkWell translation covers the year (CMS137, CMS130, CMS125, CMS165 and CMS122 on Maui, #767, #779, #782, #816, #818), it scores the run with no warning. Otherwise the run logs an effectivePeriod warning naming both periods, and the measure page says "Scored with the 2026 FHIR logic; 2027 logic not yet available" beside the rate, or "…; applies from the next run" for a run scored before the translation was routed (the programs summary's logicVintage, set only for a run that carried official evidence).

What runs, and what the rates are. The vendored artifacts are CMS's FHIR versions of the measures (CMS125FHIR v1.0.000 and so on), drafts CMS posted for public comment in January–February 2026 and derived from the 2026 QDM measures (CMS125v14). The measure read models carry them as identity.executed; the measures grid and the measure page name that artifact and its version, and show the QDM measure only as what it was derived from (locked decision §4.3). WebChart calculates and submits the pilot group's reported rates, so on the patient profile every rate screen calls WorkWell's rate an estimate.

MM-1d is not a re-vendor, and the content it needs does not exist yet (verified 2026-09-14). Two different PY2027 publications get conflated, and only one has happened. The QDM/HQMF specifications were published by CMS on 2026-05-14 — that is what a customer means when they say the 2027 specifications are available. The FHIR content this engine executes has not landed: cqframework/dqm-content-qicore-2026 holds only draft examples, on QI-Core 7.0.2, with no release tag, no bundles/ directory, and none of the six pilot measures in input/cql or input/resources/measure. Since our shipping content is authored on QI-Core 6, the arrival of PY2027 FHIR content is a profile migration plus a full MADiE re-gate per measure, not a refresh — re-sized in ROADMAP_2026-08-30.md MM-1d and §7.9. Until then, a measure without a WorkWell translation fires the effectivePeriod warning through 2027, which is the warning doing its job rather than a defect to silence; CMS137, CMS130, CMS125, CMS165 and CMS122 have one (#767, #779, #782, #816, #818). Check the repository for a release tag before assuming this is still true.

Outcome buckets (all measures): COMPLIANT, DUE_SOON, OVERDUE, MISSING_DATA, EXCLUDED.

Category 1 — OSHA Occupational Safety (Full CQL)

These four measures have complete CQL libraries, are seeded as Active, and run against the synthetic employee dataset.

1.1 Annual Audiogram Completed

Define logic

  • Program eligibility: In Hearing Conservation Program
  • Exemption: Has Active Waiver
  • Recency: Most Recent Audiogram Date
  • Aging metric: Days Since Last Audiogram

Outcome mapping

  • EXCLUDED when Has Active Waiver = true
  • MISSING_DATA when enrolled, not waived, no exam date
  • OVERDUE when enrolled, not waived, days since exam > 365
  • DUE_SOON when enrolled, not waived, days in (336..365)
  • COMPLIANT when enrolled, not waived, days <= 335

1.2 HAZWOPER Annual Medical Surveillance

Define logic

  • Program eligibility: In HAZWOPER Program
  • Exemption: Has Medical Exemption
  • Recency: Most Recent Surveillance Exam Date
  • Aging metric: Days Since Last Exam

Outcome mapping

  • EXCLUDED when Has Medical Exemption = true
  • MISSING_DATA when in program, not exempt, no exam date
  • OVERDUE when in program, not exempt, days since exam > 365
  • DUE_SOON when in program, not exempt, days in (335..365]
  • COMPLIANT when in program, not exempt, days <= 335

1.3 Annual TB Screening

Define logic

  • Program eligibility: In TB Screening Program
  • Exemption: Has Medical Exemption
  • Recency: Most Recent TB Screen Date
  • Aging metric: Days Since Last TB Screen

Outcome mapping

  • EXCLUDED when Has Medical Exemption = true
  • MISSING_DATA when eligible, not exempt, no TB screen date
  • OVERDUE when eligible, not exempt, days since last screen > 365
  • DUE_SOON when eligible, not exempt, days in (330..365]
  • COMPLIANT when eligible, not exempt, days <= 330

1.4 Flu Vaccine This Season

Define logic

  • Program eligibility: Clinical Facing Employee
  • Exemption: Has Valid Exemption
  • Season completion: Flu Vaccine This Season

Outcome mapping

  • EXCLUDED when Has Valid Exemption = true
  • COMPLIANT when eligible, not exempt, vaccinated this season
  • DUE_SOON when eligible, not exempt, not vaccinated this season, last vaccine ≤ 365 days ago
  • OVERDUE when eligible, not exempt, not vaccinated this season, last vaccine > 365 days ago
  • MISSING_DATA when eligible, not exempt, no flu vaccine record on file

Category 2 — OSHA Occupational Safety (Catalog Only)

These two measures are seeded for catalog richness and demonstrate the full measure lifecycle (Draft → Approved → Deprecated). They have no runnable CQL evaluation. (Hepatitis B Vaccination Series was promoted to a runnable Active measure in E10.6 and is now a multi-alternative series — see Category 3c.)

Name Policy Ref Status Tags
Respirator Fit Test OSHA 29 CFR 1910.134 Draft v0.9 surveillance, respiratory, osha
Lead Medical Surveillance OSHA 29 CFR 1910.1025 Deprecated v1.1 surveillance, lead, osha

Category 3 — HEDIS Wellness (Full CQL)

Five employer wellness / HEDIS-style measures with complete CQL and active evaluation. These represent the wellness side of TWH — chronic disease management, preventive health screening, and adult immunization programs run by occupational health departments.

3.1 Hypertension BP Screening

  • Policy reference: Placeholder: CMS165 Controlling High Blood Pressure pending (relabelled 2026-09-03; it also runs on the Maui pilot profile as the blood-pressure placeholder until CMS165 is onboarded, so its defines read "In Eligible Population" / "Has Documented Exclusion")
  • CQL file: backend-ts/measures/hypertension.cql
  • Tags: clinical, hypertension, cardiovascular
  • Compliance window: 365 days (DueSoon 336–365)

3.2 Diabetes HbA1c Monitoring

  • Policy reference: HEDIS HBD / JPMC Wellness Rewards
  • CQL file: backend-ts/measures/diabetes_hba1c.cql
  • Tags: wellness, diabetes, hba1c
  • Compliance window: 180 days biannual (DueSoon 161–180)

3.3 BMI Screening & Counseling

  • Policy reference: HEDIS WCC / Cigna Healthcare Wellness
  • CQL file: backend-ts/measures/obesity_bmi.cql
  • Tags: wellness, bmi, obesity
  • Compliance window: 365 days annual

3.4 Cholesterol LDL Screening

  • Policy reference: HEDIS CBP / JPMC Wellness Rewards
  • CQL file: backend-ts/measures/cholesterol_ldl.cql
  • Tags: wellness, cholesterol, cardiovascular
  • Compliance window: 365 days annual

The four chronic-disease/screening measures above use the same outcome pattern:

  • EXCLUDED when Has Medical Exemption = true
  • MISSING_DATA when enrolled, not exempt, no qualifying lab/screening date
  • OVERDUE when enrolled, not exempt, days since last event > compliance window
  • DUE_SOON when enrolled, not exempt, days approaching window end
  • COMPLIANT when enrolled, not exempt, days within window

3.5 Adult Immunization Status — Td/Tdap (AIS-E)

Define logic

  • Program eligibility: In Immunization Program
  • Exemption: Has Td/Tdap Contraindication (clinical contraindication Condition)
  • Refusal: Refused Td/Tdap (documented tdap-refusal Condition — does NOT exclude; case stays open)
  • Recency: Most Recent Td/Tdap Date
  • Aging metric: Days Since Last Td/Tdap

Outcome mapping

  • EXCLUDED when Has Td/Tdap Contraindication = true
  • MISSING_DATA when enrolled, not contraindicated, no Td/Tdap record on file
  • OVERDUE when enrolled, not contraindicated, days since last dose > 3650 (>10 years)
  • DUE_SOON when enrolled, not contraindicated, days in (3590..3650]
  • COMPLIANT when enrolled, not contraindicated, days <= 3590

Refusal: a Refused define in evidence_json flags the refusal; the case stays OPEN and is routed to a case manager for intervention. Refusal does not trigger an EXCLUDED outcome.

Advisory immunization forecast: for adult_immunization cases, GET /api/cases/:id attaches an advisory immunizationForecast for the 3 ACIP series (Td/Tdap, Influenza annual, Hepatitis B). It is computed by the ImmunizationForecast port and is advisory only — it never affects the CQL Outcome Status (ADR-012).

WorkWell has no vaccination-history source yet, so today the forecast is empty (series: [], historyAvailable: false) and the case page says there is no history (#628). Until #628 a default forecaster invented each subject's doses from a hash of their id. The real adapter (ADR-029) targets a self-hosted ICE sidecar (HLN's ACIP-maintained Immunization Calculation Engine), selected by WORKWELL_IMMZ_ICE_BASE_URL alone; it forecasts from an injected dose history, answers "no history" without dialing ICE when there is none, and answers an empty forecast on any failure. WebChart immunizations are the history source it waits for (E12). With a history, the forecast carries ICE's own recommendation and reason codes (e.g. ICE RECOMMENDED (DUE_NOW, ADMINISTER_TDAP_OR_TD)).

ICE and a WorkWell measure can legitimately disagree, and that is not a defect. ICE scores the full ACIP schedule for a vaccine group; a WorkWell measure scores its own authored rule. A subject with 2 Hep B doses reads COMPLIANT under hepatitis_b_vaccination_series if those doses complete the Heplisav-B alternative, while ICE — told the doses are a traditional adult formulation — will correctly propose dose 3. The CQL Outcome Status remains the sole compliance authority (ADR-008/ADR-012); the ICE forecast is clinical advice sitting beside it, not a second verdict.

Category 3c — Permanent Immunization Panel (series-completion CQL)

These three measures introduce the PERMANENT compliance class (E10.1 / E10.6): compliance is proven by a completed dose series, not recency — once the series is on file the employee stays COMPLIANT indefinitely ("once compliant, always compliant"). This contrasts with every other measure, which is RECURRING (windowed days-since-last with DUE_SOON/OVERDUE). The class is declared as complianceClass in each measure's YAML binding (default RECURRING); it is descriptive/routing metadata only — the CQL Outcome Status remains the sole compliance authority (ADR-008). These are the repo's first series-completion CQL measures (Count("Valid Doses") >= N, no recency filter).

Measure id Series COMPLIANT when Excludes
MMR Immunity mmr 2 doses (CVX 03/94) ≥ 2 valid MMR doses on file contraindication
Varicella Immunity varicella 2 doses (CVX 21) ≥ 2 valid varicella doses on file contraindication
Hepatitis B Vaccination Series hepatitis_b_vaccination_series multi-alternative (E11.2c): Heplisav-B 2 doses (CVX 189, ≥28d apart) OR traditional 3 doses (CVX 08/43/44/45, ACIP min intervals 28/56d) either alternative series complete contraindication

Outcome mapping (MMR / Varicella):

  • EXCLUDED when a documented contraindication Condition is present
  • COMPLIANT when enrolled, not contraindicated, and Dose Count >= 2 (regardless of dose age)
  • MISSING_DATA otherwise — including a partial series (0 < Dose Count < 2), surfaced by the roster read model as IN_PROGRESS (E10.5)
  • DUE_SOON / OVERDUE are not applicable to PERMANENT measures

Hepatitis B (multi-alternative, E11.2c / #183): COMPLIANT requires a complete alternative series — "Heplisav-B Complete" (2 doses CVX 189 ≥28 days apart) OR "Traditional Complete" (3 doses CVX 08/43/44/45 with consecutive gaps ≥28 and ≥56 days). A union "Dose Count" define (any Hep B CVX) is kept for the roster's method string only — so a mid-traditional-3 series shows the approximate "1 of 2 doses on file" (the IN_PROGRESS denominator uses the top-level series.requiredDoses 2; the canonical bucket is CQL-authoritative). EXCLUDED/MISSING_DATA/refusal behave as the other two. The codegen capability is E11.2c (ADR-015); this repoint is additive seed/app data with no schema change.

A documented refusal (declination) Condition does not change the canonical bucket; it is surfaced as DECLINED by the roster read model (E10.5) and keeps the case open (same pattern as adult_immunization). Titer-proves-immunity ("Allow positive titer") for Hep B remains deferred.

Category 3b — CMS eCQM (Full CQL)

Two CMS eCQM measures promoted from Draft catalog to Active with full CQL evaluation:

MIPS↔CMS crosswalk in the UI (2026-09-01, MM-0 Task 4). Every CMS catalog row carries a structured identity — {cmsId, mipsQualityId} in backend-ts/src/measure/measure-identity.ts, served as identity on GET /api/measures — and the product renders it on the surfaces a quality user works from: the catalog's Identity column, case detail, the cases work list, the roster column headers and mobile cards, the patient profile, and the programs pages read "MIPS 112 · CMS125 · Breast Cancer Screening". A drift test ties each entry to the MIPS text in the catalog row so the two cannot disagree. Occupational measures have no identity and render as before.

3b.1 Breast Cancer Screening (CMS125v14 / MIPS 112)

  • Policy reference: CMS125v14 (2026 eCQI; v15/2027 annual roll-forward — stay on v14 for 2026)
  • CQL file: backend-ts/measures/cms125.cql (v2.0.0 production faithful-subset)
  • Tags: ecqm, cms, cancer-screening, preventive
  • Measurement period: 12 months (periodMonths: 12)
  • Fidelity: structural report at GET /api/measures/cms125/fidelity

Official criteria (CMS125-v14.0.000-QDM): women 42-74 + visit during MP; mammogram on/between Oct 1 two years prior to MP and end of MP (VSAC Mammography); DENEX hospice / mastectomy / palliative (66+ LTC + frailty/AI = Phase 2 residual).

Outcome mapping (higher is better):

  • EXCLUDED — DENEX (mastectomy / hospice / palliative)
  • COMPLIANT — in IPP with qualifying mammogram
  • OVERDUE — in IPP without qualifying mammogram
  • MISSING_DATA — not in IPP
  • DUE_SOON — not used (cleaner eCQI proportion story)

3b.2 Diabetes: Glycemic Status Assessment Greater Than 9% (CMS122v14 / MIPS 1)

  • Policy reference: CMS122v14 (2026 eCQI; stay on v14)
  • CQL file: backend-ts/measures/cms122.cql (v2.0.0 production faithful-subset)
  • Tags: ecqm, cms, diabetes
  • Measurement period: 12 months
  • Catalog/display name matches eCQI title; library DiabetesHbA1cPoorControlCQL-2.0.0
  • Fidelity: structural + estimate + subset + literal fqm (GET /api/measures/cms122/fidelity + /diff)

Official criteria (CMS122-v14.0.000-QDM): age 18-75 + diabetes + visit; NUMER most recent HbA1c or GMI (LOINC 97506-0) in MP > 9% or missing/not performed; DENEX hospice + palliative (66+ LTC + frailty/AI = Phase 2).

Outcome mapping (lower-is-better eCQM rate; NUMER maps to OVERDUE):

  • EXCLUDED — DENEX
  • OVERDUE — in IPP and numerator (poor control or missing assessment)
  • COMPLIANT — in IPP with glycemic assessment <= 9%
  • MISSING_DATA — not in IPP

eCQM accuracy posture (vs eCQI — read this before claiming parity)

Short answer (2026-07 production-faithful promotion): the two runnable CMS measures are eCQI-aligned faithful subsets for 2026 (v14). They are still not full multi-library QICore MAT packages for MIPS submission.

What we ship Count Relationship to eCQI How we prove it
Runnable Active CMS CQL 2 — CMS122v14, CMS125v14 Faithful official-subset production CQL: 12-month MP, age/sex/visit, VSAC OIDs, GMI, Oct-1 mammogram window, hospice/palliative/mastectomy. Residual Phase 2: 66+ LTC + frailty/AI. Dual-coded synthetic data. Structural fidelity both; CMS122 also estimate + subset + literal fqm
Draft CMS catalog entries 47 Metadata only — correct CMS ID, v14 = 2026, MIPS ID, title Terminology audit 2026-07-08
OSHA / HEDIS / permanent vax 12 Not CMS eCQMs Separate authorities

Demo claim that is honest:

We evaluate CMS122v14 and CMS125v14 — the 2026 eCQI Eligible Clinician measures (MIPS 001 / 112) — with production CQL aligned to official population criteria — and, for CMS122 and CMS125 on the demo/production stack since 2026-07-30, replaced outright by CMS's FHIR (QI-Core) artifacts, CMS122FHIR and CMS125FHIR v1.0.000: drafts CMS posted for public comment in January–February 2026 (PR-9c / ADR-045, ADR-046). We can show structural fidelity (and for CMS122, a literal official package comparison). We do not claim full MAT multi-library submission packages or 2027 v15 until we cut over.

Remaining accuracy work: Phase 2 DENEX (LTC/frailty); optional CMS125 literal ELM; annual roll-forward to v15/2027 when product targets that year.

Category 4 — CMS eCQM Catalog (2026 Performance Period)

Id convention (ADR-071, 2026-09-01): an official-vendored measure's catalog id is the vendored manifest's bare catalogId (cms2, cms130, cms165, like cms122/cms125); the CMS version lives in policyRef. Legacy versioned rows on an existing database are deprecated once by the seed.

49 official CMS electronic Clinical Quality Measures are seeded as v1.0 catalog entries, of which 43 remain Draft: CMS125 and CMS122 are Active with full authored CQL (Category 3b), and CMS2, CMS130, CMS165 and CMS137 are Active official-only, where the vendored artifact IS the logic (ADR-072, ADR-078). The counts in the Category table at the top of this file are the same six and forty-three; 49 is also the number §"Terminology & standards currency" and the seeding note below both cite, so all four agree. The policy_ref field stores the CMS eCQM ID (e.g., CMS128v14). The spec_json stores cmsEcqmId and mipsQualityId for downstream tooling. CQL authoring for the remaining catalog entries is future work.

The measures page renders CMS IDs as blue mono badges to distinguish them from OSHA CFR citations and HEDIS references. Since #769 every surface that shows a result names the logic that scored it, read from that result's own evidence, never from today's routing: in full MIPS 112 · CMS125FHIR v1.0.000 (from CMS125v14) (its title adds that it is a CMS draft), as the chip MIPS 112 · CMS125FHIR (from CMS125v14), and for a translated year MIPS 305 · WorkWell translation of CMS137v15 (ww-2027.1) (chip MIPS 305 · WW translation of CMS137v15), which never carries a CMS id. A result no named logic scored (authored CQL, an errored row) keeps the unversioned crosswalk (MIPS 112 · CMS125). Selection surfaces (pickers, filters, the grid's identity column) stay unversioned because a measure spans years; the grid's Version column for a routed measure is the artifact's (1.0.000), not the catalog's v1.0, which stays in the version ids.

Two new measures added in 2026 vs 2025: CMS146v14 (Appropriate Testing for Pharyngitis) and CMS154v14 (Appropriate Treatment for URI) in the new Respiratory / Antimicrobial Stewardship domain; CMS1173v1 (Diagnostic Delay of VTE) added to Cardiovascular; CMS1154v1 (Screening for Abnormal Glucose Metabolism) added to Diabetes. CMS249v7 (DXA Scans) retired from 2026 eligible clinician list.

Domain breakdown

Domain Measures
Mental Health / Behavioral CMS2v15, CMS128v14, CMS136v15, CMS137v14, CMS149v14, CMS159v14, CMS177v14
Cardiovascular CMS22v14, CMS90v15, CMS135v14, CMS144v14, CMS145v14, CMS165v14, CMS347v9, CMS1173v1
Diabetes CMS122v14, CMS131v14, CMS142v14, CMS951v4, CMS1154v1
Cancer Screening / Preventive CMS69v14, CMS124v14, CMS125v14, CMS130v14, CMS138v14, CMS139v14, CMS153v14, CMS155v14
Respiratory / Antimicrobial Stewardship CMS146v14, CMS154v14
Pediatric / Immunization CMS74v15, CMS75v14, CMS117v14
HIV / Infectious Disease CMS314v3, CMS349v8, CMS1157v2, CMS1188v3
Oncology CMS129v15, CMS157v14, CMS645v9, CMS646v6
Ophthalmology CMS133v14, CMS143v14
Functional Status / Orthopedic CMS56v14
Medication Safety CMS68v15, CMS156v14
Care Coordination CMS50v14
Urology CMS771v7
Radiology / Patient Safety CMS1056v3

Full list with MIPS Quality IDs is embedded in MeasureService.CMS_ECQM_CATALOG and visible in the measures catalog at /measures.

Canonical Status Source

For all runnable measures, the canonical stored status is the value of CQL define Outcome Status.

Persistence path:

  1. CQL engine evaluates all defines.
  2. Outcome Status string is read from expression results.
  3. Status is persisted in outcomes.status.
  4. Full define-level results are persisted in outcomes.evidence_json.expressionResults.

Evidence Traceability

Each outcome evidence payload includes:

  • Key eligibility/exemption/recency defines for the measure.
  • Computed day-difference define where applicable.
  • Outcome Status define result.
  • why_flagged derived fields for the UI (last exam date, compliance window, days overdue, waiver status).

Implementation Notes

  • Incremental/delta evaluation (#263 / ADR-035, 2026-07-24 — descriptive only, ADR-008). A recurring population run may reuse a subject's prior Outcome Status (copy-forward) instead of re-running the CQL, when the subject's data + measure logic are unchanged and the status cannot have moved. This never changes any measure's semantics or authored CQL — it decides only whether to re-ask the engine, and a reused subject's outcome is byte-identical to a fresh run (proven by the parity suite). Only windowed-recency + PERMANENT measures get across-day reuse; flu_vaccine (seasonal) and cms122/cms125 (measurement-period) are same-day-only, since their status is not a monotone function of days-since-event. Inert unless WORKWELL_INCREMENTAL_EVAL=true. See DATA_MODEL §3.27, ARCHITECTURE.

  • CQL→SQL (WCDB) demo translations (#292 / ADR-034, 2026-07-20 — descriptive only, ADR-008). Four observation-backed windowed-recency measures (hypertension, cholesterol_ldl, obesity_bmi, diabetes_hba1c) also have generated MariaDB SQL against the WebChart dev-DB schema: pnpm generate:sql (engine/cql/codegen/generate-sql-cli.ts) templates the same rule params that compile to CQL (plus the crosswalk's LOINC sets, loincCodesForMeasure) into parameterized per-patient / single-patient / cohort statements, committed under wcdb-fhir-shim/sql/ (freshness-tested) and executed only by the standalone shim's compliance API. CQL remains the sole Outcome Status authority — the SQL is parity-gated per ADR-025 (the CQL engine over the shim's FHIR output is the oracle; cohort counts verified equal 2026-07-20) and serves nothing in the product. Series-completion SQL is deliberately absent (WCDB has no immunization table to prove parity against).

  • Live WebChart enrollment and groups (ADR-033). When the live tenant seam is configured, WORKWELL_WEBCHART_ENROLLMENT_JSON may map raw Patient ids to explicitly enrolled measure ids. Otherwise the safe demo default enrolls every live subject in every ROSTER_ELIGIBLE_MEASURES member. No CMS eCQM is on that list, so nothing is ever stamped for one (until 2026-10-02 the roster stamped a CPT 99213 visit for cms125). Enrollment only supplies occupational-health context: each measure's CQL age, sex, diagnosis, visit, exclusion, and clinical-data gates remain authoritative, and CQL alone sets Outcome Status. The demo-segment baseline (All Employees) now covers the fixed live site WebChart out of the box (WEBCHART_LIVE_SITE, folded into the seed's site list), so on any fresh DB (a local demo, a new instance) WebChart subjects are applicable and the /compliance roster shows their real per-measure chips immediately — no manual admin step. (An already-seeded DB predating this change keeps its old baseline row, since seeding is name-idempotent and never auto-mutates an operator's segment; the owner-gated repair — edit All Employees at /admin → Groups, add site WebChart, save, recording an audited SEGMENT_UPDATED — still applies there, and the live Neon stack leaves the seam off regardless.) Cases are still not created for wc| subjects by default and rerun-to-verify on any resulting wc| case returns a non-mutating 409 until fetch-one-patient lands.

  • Synthetic-corpus fidelity to the OFFICIAL artifacts (2026-07-27, ADR-038). Every eCQM code the synthetic corpus stamps is now a verified member of the official artifact's own expansion of the value set it is registered under (CANONICAL_CODE_VALUE_SETS in engine/cql/bundled-ecqm-expansions.ts, enforced by wiring/corpus-membership.test.ts). An audit against the vendored CMS122/CMS125 terminology found 12 of 24 codes belonged to a different set than the one they were registered under — e.g. SNOMED 103735009 is in "Palliative Care Intervention" but not "Palliative Care Diagnosis". No measure test could catch it: that file supplies both the stamped code AND the offline expansion the authored CQL resolves, so a wrong code is wrong in both places and every authored outcome stays exactly as seeded. Also fixed: CMS125's official IPP reads the us-core-sex extension (not Patient.gender) and its numerator retrieves [Observation: "Mammography"] (all 92 members LOINC) where the corpus emitted only a CPT Procedure — so the corpus now emits both, and Conditions carry an onsetDateTime. Authored outcomes are byte-identical (an Observation is not a Procedure; no authored CQL reads onset or the sex extension), and the official artifacts now score all five synthetic targets per measure as the corpus intends — up from cms122 4/5 and cms125 0/5. Scope: the static synthetic corpus. Real WebChart data gets neither CMS125 fix (normalizeWebChartBundle synthesizes no us-core-sex; the crosswalk maps mammography to a CPT Procedure with no LOINC), so official CMS125 over live data would still read out-of-population — tracked as a PR-9 blocker.

  • CMS125 over real WebChart data, updated 2026-07-30 (ADR-042). The us-core-sex half is now closed for the shim / dev-DB export path: both mapping sites emit the extension from patients.sex, and official CMS125 agrees with the authored measure on all 56 dev-DB subjects (52 MISSING_DATA, 4 OVERDUE) once a qualifying visit is supplied as test data; the sample itself carries no encounters. It is not closed for a live third-party WebChart FHIR server (teatea), which supplies no us-core-sex and whose roster therefore reads out-of-population — deliberate, fail-closed, and a limit to state before a tenant is onboarded. The mammography half is still open and fails in the dangerous direction: the crosswalk emits CPT 77067 / HCPCS G0202 on a Procedure, the official numerator retrieves [Observation: "Mammography"] from a value set of 92 LOINC codes only, and isDiagnosticStudyPerformed additionally requires category ~ imaging. Measured: with one crosswalk-shaped mammogram, authored says COMPLIANT and official says OVERDUE — a false non-compliance on a screened patient. A LOINC Observation alone does not fix it (no category), and with category it flips the error to authored. The remedy is dual-stamping both representations, as the synthetic corpus does. All four states are pinned in devdb-official-eval.test.ts.

  • Terminology & standards currency (2026 audit, 2026-07-08 — docs/archive/TERMINOLOGY_AUDIT_2026-07-08.md). A three-way verification (our implementation vs MIE's WebChart dev DB vs the current 2026 authorities — CMS eCQI, CDC CVX, LOINC, VSAC, AMA CPT, eCFR) confirmed everything load-bearing is correct and current: all 49 CMS catalog versions/MIPS IDs (v14 = 2026 confirmed), all OSHA CFR citations, and all runnable LOINC/CPT codes. The one defect class — vaccine CVX currency on the WebChart crosswalk — was fixed: influenza matching expanded from 141/140-only to the full active seasonal CVX set (VSAC "Influenza Vaccine" OID 2.16.840.1.113883.3.526.3.1254); the inactive Td code 139 supplemented with active 09/113/196; MMRV 94 now counts toward varicella; deleted HCPCS G0202 marked read-only. All fixes are additive to the WebChart read path (engine/ingress/webchart/terminology.ts) — synthetic outcomes are unchanged (the synthetic CQL matches urn:workwell:* codes, not CVX numbers). Inactive codes are matched on read for legacy records, never emitted. Durable follow-up: resolve flu membership from the VSAC value set via the ADR-023 resolver rather than the hardcoded active list.

  • All active CQL measures now use inline code-filter expressions on both the qualifying event (Procedure or Immunization) and the enrollment/exemption Conditions, matching the system/code stamped by SyntheticFhirBundleBuilder. This replaces the earlier exists([Condition]) / Count([Condition]) > 1 pattern that was semantically correct but not code-scoped. HAZWOPER (hazwoper.cql) and TB Screening (tb_surveillance.cql) were the last two still on the un-scoped pattern; the Fable H3 hardening fix (2026-07-03) brought them into line — a patient with unrelated Conditions no longer false-positives as enrolled/exempt on the arbitrary-bundle path (evaluateBundle/pnpm evaluate), where the synthetic per-measure bundles had masked it. A foreign-condition-scoping.test.ts golden regression guards it; the ELM was recompiled (pnpm compile-measures); synthetic outcomes are unchanged. True ValueSet token expansion (resolving urn:workwell:vs:* OIDs via the VSAC or a local expansion service) is a known evaluator limitation of the in-memory CQF path; the inline-code pattern is the stable workaround until a resolver is wired. (E3.2 / #90 update) A ValueSetResolver seam now supports real value-set expansion: the engine can run in an expansion mode (an optional resolver → a populated cql.CodeService) where a CQL value-set retrieve ([Procedure: "Audiogram Procedures"]) filters by real membership. Audiogram ships a value-set-retrieve ELM variant proven byte-equal to the inline path (cross-mode golden parity); the inline path remains the default. (ADR-023 update, 2026-07-05) The live VSAC (NLM UMLS) adapter is now real behind the port, superseding the "future drop-in" language above: a CompositeValueSetResolver routes dotted-numeric VSAC OIDs → a live VsacValueSetResolver (GET {base}/ValueSet/{oid}/$expand) and urn:workwell:* references → the local store, selected only when WORKWELL_VSAC_API_KEY is set (inert-unless-configured; engineForEnv is key-gated so the unkeyed path is byte-identical to today). The owner-run pnpm resolve-valuesets CLI imports official VSAC expansions into value_sets (source="VSAC", no DDL; DEPLOY.md). Descriptive only (ADR-008) — expansion feeds the CodeService, never Outcome Status (guarded by the audiogram cross-mode VSAC parity test). (E14 PR-3, 2026-07-05 — SHIPPED) GET /api/measures/cms122/fidelity/diff now runs a real, subject-by-subject execution outcome diff for CMS122: for each subject in the latest cms122 population run it builds the synthetic bundle, additively enriches it with real VSAC-member codes, evaluates both WorkWell's authored cms122 and an official-subset CMS122 measure fresh, and diffs — attributing each divergence to the first differing official gate (age 18–75 / qualifying visit / diabetes diagnosis / hospice / palliative / HbA1c-missing / WorkWell-side exclusion). It resolves the imported VSAC value_sets (source="VSAC") rows from the store, so no runtime VSAC key is needed (the key was only for the one-time pnpm resolve-valuesets import); when those rows are absent (e.g. local/dev), the route degrades to the unchanged PR-2 criteria-impact estimate. Since #664 (2026-09-22), only for a run of at most 20 subjects (IN_REQUEST_EXECUTION_MAX_SUBJECTS): the execution tiers are synchronous CPU per subject (~130–150 ms measured locally) and run inside the request, and on the pilot's 20,000-subject runs one diff held the worker, /health included, for over half an hour. Above the cap the estimate answers with executionSkipped: { reason, subjects, limit }, decided after the ladder so it never claims a tier the stack lacks, and the Standards tab says it is showing an estimate. That includes the 100-employee default roster. Moving the diff to the nightly run is #673. The official measure is a faithful official-SUBSET — measures/cms122_official.cql, using FHIR '4.0.1' in the proven value-set-retrieve style, driven by the VSAC OID value sets and compiled to committed ELM (DiabetesHbA1cPoorControlOfficialCQL-1.0.0) — not the literal multi-library QICore artifact. A compile-feasibility spike (2026-07-05) judged the literal QICore CQL uncompilable under the pinned @cqframework/cql 4.0.0-beta.1. That was wrong (2026-10-03): given cqframework's QICore 6.0.0 model info, the same translator compiles all six pilot measures, and pnpm test:compiled-cases runs CMS's decks on that ELM with results identical to CMS's own (334 cases, 0 of 14,880 define values differ). The literal tier below still runs CMS's vendored ELM. The diff is descriptive only (ADR-008) — it writes nothing and never sets an Outcome Status; WorkWell's cms122 outcomes stay byte-identical (the enrichment is harness-local — it appends codings to a copy for the diff harness, it is not a change to the live fhir-bundle-builder). The GMI numerator alternative is now modeled in the official-subset CQL (2026-07-05): the numerator takes the most recent of an HbA1c (VSAC HbA1c Laboratory Test set) OR a Glucose Management Indicator (GMI, LOINC 97506-0) within the period, so a newer GMI supersedes an older HbA1c. GMI uses a direct LOINC-97506-0 code filter (the synthetic corpus ships no GMI value set, so no VSAC OID is invented) — the remaining simplification for that criterion is terminology-only (this code filter vs the official combined "Glycemic Status Assessment" VSAC set), and WorkWell's own authored cms122 still models neither GMI nor a recency window (see Fable L15 above). The SUBSET diff is CMS122-only (it executes a hand-authored cms122_official.cql), and the route enforces that: any other measure degrades literal → estimate, never literal → subset. (#258, 2026-07-09 — LITERAL tier SHIPPED; supersedes ADR-024's "revisit on a stable translator" clause — ADR-026. Generalized 2026-07-27, ADR-039.) The fidelity diff has a three-tier ladder — literal → subset → estimate — surfaced by an additive mode field in the response. The literal tier executes the actual official multi-library QICore artifact of any vendored measure (MADiE FHIR export, using QICore '6.0.0') via MITRE's fqm-execution over the pre-compiled ELM shipped inside the bundle's Library.content (application/elm+json) — no translation happens. Bundles are vendored with provenance under backend-ts/measures/official/<catalogId>/ (cms122 + cms125 today); value sets come from the artifact's own terminology sidecar (ADR-036) with no fallback to the resolve-valuesets VSAC import. fqm-execution is a diagnostic-only dependency, declared by packages/official-executor alone and reached through a lazy await import — never the run pipeline / ingress / worker (arch-tested by fqm-isolation.test.ts).

    Per-subject population membership (IPP/DENEX/DENEXCEP/NUMER) maps to the outcome vocabulary with population-level gate attribution, through the fail-closed officialMeasureSemantics table — a measure with no recorded reading of its numerator is unavailable for the tier rather than scored under another measure's. Since ADR-039 the tier is a genuine SHADOW of the runtime: the same measurement period (officialMeasurementPeriod), the same preparedForQiCore copy with the authored engine still seeing the original bundle, the same outcomeFromPopulations mapping, and no harness enrichment — that stays in the SUBSET tier, where manufactured divergence is the point. Memoized per measure + run-id. WorkWell's own outcomes stay byte-identical (ADR-008 guard). The subset tier is the fallback when cms122's vendored bundle is absent or its literal execution fails at runtime; the estimate remains the floor.

  • All five HEDIS wellness measures (including adult_immunization) are seeded via ensureInstanceSeeds() when WORKWELL_INSTANCE=ecqm or twh.

  • The synthetic FHIR bundles declare QI-Core conformance: each resource carries a QI-Core meta.profile canonical + the required structural elements (#92 / E3.4). Structural alignment (JVM-free), not IG/validator-validated — meta.profile is metadata, so evaluation outcomes are unchanged. See docs/STANDARDS_CONFORMANCE.md.

  • All 49 CMS eCQM catalog entries (2026 performance period) are seeded via ensureCmsEcqmCatalogSeed() for the same instance values. They are Draft-only and do not participate in CQL evaluation runs until CQL is authored and compiled. On re-seed, existing measures are looked up by CMS ID prefix (LIKE 'CMSNNNv%') and updated in-place so version bumps (e.g., v13→v14) do not create duplicate DB rows.

  • A headless CLI (pnpm evaluate --patient <bundle.json> --measure <id>, backend-ts/src/engine/cli/) evaluates one FHIR R4 patient bundle against a measure with no server or DB — the same CqlExecutionEngine the run pipeline uses. Golden regression over backend-ts/spike/synthetic asserts outcomes for all 11 measures × 4 scenarios (#72 / E2, updated for E6).

    • E12 PR-1 (#184): the same DB-less evaluation is also a library entry — evaluateBundle(bundle, measureId) (single JSON/FHIR object) + evaluateBatch(bundles, measureId) (a "bucket", per-item error isolation), from backend-ts/src/engine/ingress. A PatientDataSource port + resolveDataSource(env) make the ingress pluggable (JSON default; WebChart adapter is an inert stub until E12 PR-2). FHIR-native-first — adapters feed the unchanged engine (ADR-017).

  • Immunization forecasting (E6 / #76): GET /api/immunization/forecast?subjectId=&asOf= returns an advisory ImmunizationForecast (Td/Tdap, Influenza, Hepatitis B next-dose-due) computed by the ImmunizationForecast port (backend-ts/src/engine/immunization/immunization-forecast.ts). With no vaccination-history source it is empty with historyAvailable: false (#628); the ICE adapter is selected by WORKWELL_IMMZ_ICE_BASE_URL alone (the API key is optional). The forecast is advisory only — the CQL Outcome Status remains the sole compliance authority (ADR-012).

  • A completed single-measure run can be exported as a FHIR R4 MeasureReport (summary + per-subject individual + a collection Bundle) via GET /api/runs/{runId}/measure-report — built from persisted outcomes with a proportion population model whose individual membership labels reconcile 1:1 with the summary (#89 / E3.1; ADR-031). Reported DENOM includes DENEX membership; the score is NUMER / (DENOM - DENEX). For cms122/cms125 only, binding metadata maps MISSING_DATA to out-of-population because their authored CQL uses that status for not Initial Population; OSHA and HEDIS-style measures keep it in IPP/DENOM. Value-set expansion + QRDA are separate E3 items (#90/#91).

  • A completed single-measure run can be exported as an HL7 QRDA Category III aggregate stub via GET /api/runs/{runId}/qrda?format=xml — well-formed CDA carrying the aggregate population counts + performance rate (reuses the MeasureReport countPopulations); a stub, not IG-validated (#91 / E3.3). See docs/STANDARDS_CONFORMANCE.md.

  • E7 action-evaluator order map (#77): backend-ts/src/order/order-catalog.ts maps a measure to the order it proposes. Codes reuse the terminology_mappings seed standards where present: audiogram → CPT 92557; tb_surveillance → CPT 86580; flu_vaccine → CVX 141; hazwoper → hazwoper-exam in urn:workwell:vs:hazwoper-exams. Others use a representative standard code (cms122 → CPT 83036, cms125 → CPT 77067) or a LOCAL urn:workwell:orders code (BMI). A measure absent from the catalog proposes nothing; on Maui that is cms2, cms130, cms165 and cms137, and the route names them in measuresWithoutOrder (#621). GET /api/orders/proposals returns ProposedOrder records (or FHIR R4 ServiceRequest bundles) for at-risk subjects; proposals are advisory only.