WebChart ingest never fetches medication orders, referrals or device orders, which all six routed measures read
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 68/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
- Ambito
- api, backend, testing-qa
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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).
- Lingua principale
- TypeScript
- Stelle
- 0
- Fork
- 0
- Merge medio
- 4h 54m
- PR unite (30g)
- 104
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Taleef7/workwell
-
frontend maui-pilot pilot-ask question
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
documentation owner-ops waiting
Difficoltà 1/5 1-3 ore Idoneità per principianti 86/100
I maintainer di solito rispondono entro 1 giorno
-
owner-ops waiting
Difficoltà 1/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
MCP: move to Streamable HTTP (spec 2026-07-28) with OAuth, so clients refresh their own tokensApertabackend enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
backend
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Taleef7/workwell
Issue simili
-
refactor
Difficoltà 2/5 Mezza giornata Idoneità per principianti 84/100
I maintainer di solito rispondono entro 5 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
OHDSI/Data2Evidence#3450 ·
I maintainer di solito rispondono entro 2 giorni
-
e2e-failure ready-to-code
Difficoltà 2/5 1-3 ore Idoneità per principianti 90/100
redhat-developer/rhdh-plugin-export-overlays#4011 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
automation missing-model model-sync provider:ofox
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
anomalyco/models.dev#8421 ·
I maintainer di solito rispondono entro 1 giorno
-
SlackAdapter and TelegramAdapter are not assignable to Adapter under exactOptionalPropertyTypesAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno