All apps

Clinical Decision Support · Physicians

CuRE Cue

Clinical decision support embedded in the EHR via SMART on FHIR.

Part of Research Engagement

What it does

Clinical decision support embedded in the EHR via SMART on FHIR. Lives inside the physician's existing EHR — no separate app to log into.

Key capabilities

  • Point-of-care alerts
  • Guideline-driven recommendations
  • EHR-embedded UI (SMART on FHIR)
  • EHR context-sync (FHIRcast)
  • OMOP-native cohort logic
  • Patient-chart-grounded genAI Q&A
  • Alert-fatigue self-tuning
  • DDI / dose-range / duplicate-therapy checking
CuRE Cue — clinical decision support showing mSMART guideline risk stratification and inferred transplant eligibility across a 121-patient cohort
Sandbox preview — synthetic demo data

What sets it apart

  • Lives inside the physician's existing EHR — no separate app to log into.
  • Answers the physician's question grounded in THIS patient's chart via SMART-on-FHIR context — the 2025-26 point-of-care AI bar — not a textbook lookup.
  • Trial matching and referral are the buyer-facing wedge: the same CDS surface surfaces eligibility at the point of care and warm-hand-offs the referral into Control's study operations — the point-of-care-to-enrollment path.
  • EHR context-sync via FHIRcast keeps Cue in step with the clinician's active patient context as they move through the chart.
  • Recommendations are study-aware when a patient is enrolled, not just generic guidelines.
  • The alert a physician sees runs the same OMOP cohort definition your analysts validated in Calculate — one vocabulary, no translation drift.
  • Generalizes beyond the myeloma beachhead to additional guideline families and disease models.
CuRE Cue · point-of-care CDS alert-rule evaluation
Live demo — synthetic data, runs in your browser

Edit the chart, and watch the point-of-care alerts recompute

Cue lives inside the physician's EHR. Opening a patient fires a CDS Hooks patient-view hook, and Cue evaluates every published clinical guideline's structured criteria against the patient's derived characteristics — risk group, treatment context, transplant eligibility, MRD. Toggle a high-risk cytogenetic marker or change the context and watch the matching evidence cards fire, then watch the evidence-framing firewall reject a card that dares to prescribe.

A synthetic multiple-myeloma chart. Opening it in the EHR fires a patient-view CDS Hook — Cue evaluates every published guideline against the derived characteristics.

Count drives risk group: 0 → standard, 1 → high, ≥2 → double-hit.

Maria Garcia · 77y, high risk (t(4;14)), 2 prior lines · relapsed, transplant-ineligible, MRD positive
Risk group
high
1 HR factor
Context
relapsed
2 prior lines
Transplant
ineligible
age ≥ 75
Cards emitted
3
1 blocked

CDS cards surfaced in the EHR

High-Risk Cytogenetics — Consider Quadruplet
warning

Presence of high-risk cytogenetic abnormalities (e.g. del(17p), t(4;14), t(14;16)) is associated with reference to dara-based quadruplet induction.

Cytogenetic factor(s): t(4;14)
Source: Mayo Clinic mSMART — Multiple Myeloma Risk-Stratified Management ↗
Relapsed MM — MRD-Informed Response Assessment
info

In relapsed/refractory myeloma, IMWG references describe MRD assessment (NGS/MFC) as a response-depth endpoint alongside conventional criteria.

Context: relapsedMRD status: positive
Source: IMWG Consensus Criteria for Response and MRD Assessment (Kumar et al., Lancet Oncol 2016) ↗
Multiple Myeloma — Supportive Care Reference
info

Guidelines describe bone-directed therapy, VTE prophylaxis, and infection prevention as supportive-care considerations across the myeloma course.

Source: NCCN Clinical Practice Guidelines in Oncology — Multiple Myeloma (Supportive Care) ↗

Evidence-framing firewall (SaMD guard)

Blocked before render · High-Risk MM — Prescriptive Directive (blocked by the firewall)
🚫

“We recommend you start treatment with a daratumumab-based quadruplet immediately for this high-risk patient.”

prescriptive-directive — app-voice recommendation: matched "We recommend"
prescriptive-directive — start/stop treatment: matched "start treatment"
prescriptive-directive — app-voice recommendation: matched "Cue recommends"
prescriptive-directive — imperative directive: matched "initiate quadruplet"

Cue is decision-support-with-evidence, not a device that prescribes. Every card is scanned against the same prescriptive-directive regex bank the product enforces — an app-voice imperative like “we recommend you start treatment with…” is rejected before it can reach the physician. That structural firewall is what keeps Cue on the right side of the SaMD line. Every match, derivation, and framing check here runs in your browser on synthetic data — no backend, no real patient.

Why this is more than a toy

The rule engine is a faithful port of the real product methodology across three sources in apps/cue: the pure AND-semantics guideline matcher (matchGuidelines, cds-hooks/evidence-engine.ts) evaluated constraint-for-constraint in the same order; the mSMART risk-group derivation (classifyRiskGroup, disease/profile.ts, ≥2 high-risk factors ⇒ double-hit); and — the part that separates real CDS from a toy — the evidence-framing guard (evidence-framing.ts), whose prescriptive-directive regex bank and citation check are ported verbatim and run over every fired card. The guidelines, their real NCCN / Mayo-mSMART criteria and citation URLs, and the FISH marker ids are the product's own seed (prisma/seed.ts). In the product the same matcher runs on the patient's governed OMOP slice under row-level security and returns HL7 CDS Hooks 2.0 cards to the EHR; this is that same match-then-firewall loop, running client-side on a synthetic chart. No backend, no real data.

Request a demo

See CuRE Cue in action

Every research ecosystem is unique. Let's discuss how CuRE can be configured for your needs.

Get in Touch