Re-mappings and signing

In our presentation we call these re-mappings. A rule is the versioned, signed form of a re-mapping: what changed, why, and who reviewed it.

Trusting a number you had to adapt the data to compute

Real exports have to be adapted before the measures can read them. The obvious objection follows: if you change the data, why trust the number? dQMGrid’s answer is that every adaptation is a rule — versioned, reviewable, attributable — and that rules are classed by how much they change the meaning of the data. Only some classes count in a reported result unless a named reviewer has signed them.

Rules are FHIR artifacts

Each rule is a standard FHIR artifact, so it travels and can be audited with ordinary tools:

• a CodeSystem fragment for a platform’s local vocabulary;
• a ConceptMap from local codes and text strings to standard codes;
• profile-declaration and derivation rules;
• a Provenance resource naming the rule, its version and its reviewer — attached to every element the rule adds.

Because every added element carries the Provenance of the rule that added it, a run can be read backward: from a population count, to the patients in it, to the data and the rules that put them there.

Three classes

Class	What it does to the meaning	Example	Counts in reporting mode
Repair	Re-expresses a fact the source asserted, in the form the measure reads	A HCPCS code relabeled from CPT; a profile declared from a Condition’s category	Yes
Derivation	Fills a missing element from one present in the same resource	An onset date from a recorded date	Only when signed
Inference	Adds meaning the source did not assert	A site’s local radiology text mapped to LOINC; clinical sex from administrative gender	Only when signed

An example of why the class matters

To compile CMS125 under our model information — a translator defect we carry as a documented workaround — we rewrote Patient.sex = '248152002' (a SNOMED-coded clinical sex) as Patient.gender = 'female' (an administrative code), in the denominator of a breast cancer screening measure.

The two do not classify the same patients: administrative other and unknown have no clinical equivalent. So dQMGrid classes the change as an inference, not a repair. It counts in a reported result only when a named signer accepts it; in our harness it is unsigned.

The published test deck cannot surface the difference, because its patients have consistent sex and gender — the cohort is 60 of 60 either way. That is a coverage gap in the test deck rather than a fault in it, and it is exactly the kind of thing that only shows up on real data. In US Core 6.1.0 the sex extension is optional while gender is mandatory, which is why a certified export can be fully conformant and still fail the published measure.

Three tiers

Rules are organized by data source, not by measure:

Tier	Scope	Who it reaches
Standards	Rules that follow from the specifications themselves	Everyone
Vendor	Rules for one EHR product	Every organization on that product
Site	Rules for one organization’s build of a product	That organization

An open vendor-tier rule corrects a non-conformant export today. The vendor, seeing exactly what had to be adapted, can fix it at the source tomorrow — and the rule then retires for every customer at once.

The gate a rule must pass

A rule counts as a repair only if it passes both checks:

1. It leaves the expected MeasureReports on the published test decks unchanged; and
2. its output passes the HL7 FHIR Validator against the measures’ own profiles.

A profile-declaration rule never fires on the published decks, because their patients already declare the profiles, so it passes the first check by doing nothing. Declaring a profile on a resource that does not actually meet it is caught only by the validator — which is why both checks are required.

Signing

Signing is how a derivation or inference becomes part of a reported result. A signer is a named, qualified reviewer who accepts professional responsibility for the judgment a rule encodes. The signature is recorded in the rule’s Provenance and travels with every result that used it.

• Any qualified signer may sign rules. MDinteractive is the default signer for the rule sets it maintains, but signing is not exclusive to it. Qualification criteria, signer scope and liability are defined in the governance charter, an first release deliverable. See Governance.
• No rule has yet been clinically signed. Signed rule sets for two ambulatory EHR platforms are an first release deliverable.

Two modes, one bias report

The same run is read two ways, from the same tags:

• Reporting mode counts only what the source already coded, plus repairs and signed rules. This is the number you would submit.
• Quality-improvement mode also counts unsigned derivations and inferences, each one marked. This is the number that helps a site find closable gaps.

The bias report is the difference between the two, per measure and per data source: every patient whose population membership depended on an unsigned derivation or inference. It makes visible exactly how much of a rate rests on judgment that nobody has yet accepted.

The data adaptations are open for anyone to read, fork and run. A signature — a named reviewer accepting responsibility for a clinical judgment — is what makes an adaptation count in a reported result.

See it working in the live run report, which lets you switch between the two modes and filter the account by rule class, tier and signature.