WebChart ingest never fetches medication orders, referrals or device orders, which all six routed measures read
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 68/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- api, backend, testing-qa
Research direction
Start at backend-ts/src/engine/ingress/webchart/webchart-client.ts:72 and check WebChart's FHIR CapabilityStatement for patient searches of MedicationRequest, ServiceRequest, and DeviceRequest. Read docs/WEBCHART_FHIR_MAPPING.md:156 and corpus-bundle.ts, then compare WebChart-shaped fixtures with the corpus paths. Done means served types are profile-stamped, composed, and tests show the affected measure outcomes change accordingly.
Written by the indexing model from the issue text.
Description
What is wrong
The WebChart ingest composes each patient from five resource types only:
backend-ts/src/engine/ingress/webchart/webchart-client.ts:72
export const COMPOSED_RESOURCE_TYPES = ["Observation", "Condition", "Procedure", "Immunization", "Encounter"] as const;
The six routed measures also read MedicationRequest, ServiceRequest and DeviceRequest. The vendored CQL in .official-content/bundles/measure/* retrieves them here:
| Library (included by) | Type | Value sets | Role |
|---|---|---|---|
Hospice (CMS122, 125, 130, 165, 137) |
ServiceRequest | Hospice Care Ambulatory | denominator exclusion |
AdvancedIllnessandFrailty (CMS122, 125, 130, 165) |
MedicationRequest | Dementia Medications | exclusion (advanced illness, 66+) |
AdvancedIllnessandFrailty (CMS122, 125, 130, 165) |
DeviceRequest | Frailty Device | exclusion (frailty, 66+) |
CMS2FHIRPCSDepScreenAndFollowUp |
ServiceRequest | Referral for Adult / Adolescent Depression | numerator (follow-up plan) |
CMS2FHIRPCSDepScreenAndFollowUp |
MedicationRequest | Adult / Adolescent Depression Medications | numerator (follow-up plan) |
CMS137FHIRSUDTxInitEngagement |
MedicationRequest | SUD Long / Short Acting Medication | initiation and engagement |
Coverage is also retrieved but feeds only the supplemental payer data, not the score.
What it does to the numbers on real data
For these facts, a WebChart-sourced evaluation sees nothing, so:
- CMS122, 125, 130 and 165. A patient with a hospice order, or (at 66+) a dementia medication or a frailty device order, is not excluded. They stay in the denominator and can show as an open gap they should never have had.
- CMS2. A positive screen followed up by a referral or an antidepressant counts as no follow-up. The patient shows as a gap although the practice did the work.
- CMS137. Treatment by medication is invisible to initiation and engagement.
Nothing warns of this. The measures run and report numbers, and those numbers are wrong in one direction.
Why the sandbox does not show it
The synthetic corpus emits these facts: corpus-bundle.ts writes a dementia MedicationRequest (the frailty exclusion) and a PHQ-9 follow-up ServiceRequest (CMS2). So the sandbox exercises paths that live ingest can never feed. The sandbox's exclusion and CMS2 follow-up counts are therefore higher than a WebChart-fed run would produce from the same chart.
What is needed
- Check what WebChart serves. Read WebChart's FHIR CapabilityStatement for MedicationRequest, ServiceRequest and DeviceRequest search by patient. If a type is missing there, the fact has to come from the database side instead. The mapping doc already names
encounter_orders→ ServiceRequest for pending orders (docs/WEBCHART_FHIR_MAPPING.md:156), but it is unimplemented. - Add the types that are served to the composed set, profile-stamped at ingest like the rest.
cqf-fhir-crretrieval ismeta.profile-sensitive, so an unstamped resource is silently never retrieved (the #591 trap). - Test it. A WebChart-shaped fixture per path (a hospice order, a dementia medication, a frailty device, a CMS2 referral, a CMS137 medication) proves each moves the outcome the way the corpus version does.
Gating
This does not affect the sandbox. It gates the real-data (PHI) phase, under locked decision §4A.5: no known-unverified measure runs over the pilot's real data. It sits alongside #591 (cms165's blood pressures are not profile-stamped at ingest).
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- Avg merge
- 4h 20m
- Merged PRs (30d)
- 104
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Taleef7/workwell
-
frontend maui-pilot pilot-ask question
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
documentation owner-ops waiting
Difficulty 1/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
owner-ops waiting
Difficulty 1/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
backend enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
backend
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
All issues in Taleef7/workwell
Similar issues
-
module-request
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
appandflow/stim#1604 · 1 comment ·
Maintainers usually reply within 1 day
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 92/100
lingdojo/kana-dojo#31060 · 1 comment · 5 reactions ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
paperclipai/paperclip#14173 ·
Maintainers usually reply within 1 day
-
needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day