Skip to content

M-E1 research: what makes an occupational measure CORRECT, and who says so? #405

Description

@Taleef7

Not scheduled yet — this is the question to answer BEFORE writing any M-E1 CQL. Recorded now so it does not have to be re-derived.

Why this is a new problem

Every milestone so far had an external oracle, and M-E1 does not.

what made it correct who said so
M-A official eCQMs MADiE expected results, 410/410 the measure stewards
M-B QRDA I/III 0 findings vs the HL7 base ruler HL7 / Cypress
M-C engine cqframework/cql-tests, 1622/1835; cross-execution vs Java cqf-fhir-cr the CQL WG / an independent engine
M-E1 occupational ? ?

OSHA publishes requirements, not CQL. That absence is precisely why locked decision 6 calls this the differentiator — "the measures nobody publishes" — but it also removes the thing every prior milestone leaned on. There is no MADiE case file to check ourselves against, and an oracle that is our own authored test cases is the weakness ADR-055 exists to document.

Candidate answers, none yet chosen

1. Self-authored spec + test cases. We write the measure intent, the CQL, and the cases together.

  • For: fast; total control; matches how the existing occupational measures (audiogram, respirator, etc.) were built.
  • Against: the oracle is us. Agreement proves internal consistency, not correctness. ADR-055's whole lesson was that our numbers only became trustworthy when checked against a third party's expected results.

2. NCQA stewardship. ROADMAP_2026-07-24 records that MIE could steward occupational measures through NCQA.

  • For: a real external authority; the strongest possible answer; would make the content genuinely citable.
  • Against: slow, organisational, not something engineering can execute alone. HEDIS guardrail still applies — own spec text and cases only, never reproduced NCQA specs (DUA).

3. Connectathon / peer verification. Another engine runs our published content and agrees.

  • For: genuinely independent, and we already have the harness — B7 cross-executed our artifacts through Java cqf-fhir-cr, the one engine that does not wrap fqm-execution. Also fits the dqm-content-shaped publication M-E names, and the CQI WG meets Fridays.
  • Against: proves two engines agree on what the CQL says, not that the CQL says the right thing. Necessary, not sufficient.

4. Regulatory traceability as the artifact. Treat the citation itself as the deliverable: every define traced to a numbered paragraph of the CFR, and the measure is "correct" when a compliance officer can audit that mapping.

  • For: honest about what can be verified; matches what an occupational-health customer actually needs; nothing else in the market publishes it.
  • Against: it is a documentation standard, not a computational check. Needs one of the above beside it.

The likely shape of the answer

These are not exclusive. A defensible position is probably (4) + (3): regulatory traceability as the published artifact, peer/cross-engine execution as the computational check, with (2) as the long-horizon goal if MIE wants it. (1) alone is the one to avoid claiming as verification.

Also to decide with it

  • Which standard first. 29 CFR 1910.95 (occupational noise / audiometric testing) is the obvious candidate — the audiogram measure and hearing-conservation data already exist, so it tests the pipeline rather than the domain. Alternatives: respirator medical evaluation (1910.134), silica (1926.1153), lead (1910.1025).
  • What "denominator" means occupationally. Exposure-based cohorts, not diagnosis-based — this is the structural difference from every CMS measure we run, and it may not fit ROSTER_ELIGIBLE_MEASURES as-is.
  • What we may claim. docs/STANDARDS_CONFORMANCE.md rules apply: never upgrade a row without a passing test or validator run to point at, and always name who graded what.

Do not start M-E1 implementation before this is answered.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions