• 

RXsignal: medication-risk context before the clinician signs

Inspiration

RXsignal started from a simple problem: clinicians are asked to make high-stakes medication decisions while the relevant risk context is scattered across too many places.

A provider may be in the middle of prescribing a controlled medication, but the useful signals live elsewhere: chart history, current meds, prior notes, PDMP-style evidence, risk flags, documentation requirements, and patient-reported history. The risk is not just that a bad prescription gets signed. It is that the decision happens before the full context is visible.

We wanted RXsignal to feel like something that belongs inside the prescribing workflow, not another dashboard someone has to remember to open.

The core idea was:

Put medication-risk context directly in front of the clinician before final eRx signature.

RXsignal does not prescribe. It does not replace clinical judgment. It gives the provider a clear, explainable, documented safety layer at the moment it matters.

What it does

RXsignal is a clinical decision-support prototype for medication-risk review.

When a provider selects a medication, RXsignal:

1. Uses patient/chart context from the host workflow.
2. Looks up medication-risk context through a narrow MCP-style tool contract.
3. Applies deterministic safety rules.
4. Returns a risk score, recommendation, rationale, and chart-ready documentation.
5. Keeps the clinician in control of the final decision.

For the demo case, RXsignal can identify a high-risk controlled-substance scenario involving Xanax, PDMP mismatch, opioid/benzodiazepine overlap, multiple prescribers/pharmacies, and missing documentation.

It can also handle lower-risk cases. One important design choice was that age alone should not automatically create a high-risk result. For example, an older adult dental follow-up with a non-opioid medication plan should be reviewed carefully, but not over-penalized just because of age.

A simplified scoring model looks like this:

$$ R = \sum_i w_i f_i $$

Where:

• $R$ is the final medication-risk score.
• $f_i$ are risk features such as PDMP overlap, active sedatives, dose concerns, age modifiers, or missing documentation.
• $w_i$ are deterministic rule weights.

The key is that the score is explainable. RXsignal should be able to show which facts contributed to the result, not just output a black-box label.

How we built it

We built RXsignal as a synthetic-only demo application with a few connected pieces.

EHR-style prescribing flow

The UI is designed to look and feel like a provider is already inside a chart. The demo starts with patient lookup, encounter context, medication entry, and then RXsignal appears as part of the prescribing workflow.

The goal was to avoid a separate “run this tool” experience. The product should feel embedded.

MCP-compatible medication-risk tools

The backend exposes MCP-style tools for patient and medication lookup. One important piece was compatibility with Prompt Opinion’s expected tool behavior, including patient lookup paths like FindPatientId.

That let the demo support a natural flow:

Find patient -> select medication -> lookup medication-risk context -> return structured result

The tool interface matters because it keeps the integration narrow. RXsignal does not need broad access to everything. It needs the right patient, the proposed medication, and the context required to explain the safety recommendation.

Deterministic risk rules

We used deterministic rules instead of relying on an LLM to invent the risk result.

That means the system can return structured output like:

{
  "risk_score": 80,
  "risk_level": "high",
  "recommendation": "Not recommended — verify with patient before prescribing",
  "compliance_flag": "PDMP review not documented"
}

The rules are intentionally explainable. If RXsignal flags a medication, it should be clear whether the issue is PDMP mismatch, opioid/benzodiazepine overlap, multiple prescribers, missing documentation, dose risk, age modifier, or identity uncertainty.

Chart-ready documentation

A big part of the project was not just showing a risk score. RXsignal also generates documentation support.

The provider can choose an action such as proceed, proceed with caution, or do not prescribe. RXsignal then carries the rationale into the chart so the clinical reasoning is visible before final eRx review.

Safety and fail-safe behavior

One design rule we cared about: if identity matching is uncertain, RXsignal should refuse confidence.

That means:

No guessed patient.
No guessed PDMP.
No fake risk score.
Manual review required.

A system like this is only useful if it knows when not to answer.

Challenges we ran into

The hardest challenge was keeping the demo honest.

Because the project is synthetic-only, we had to be careful not to imply that RXsignal was connected to real PDMP data or real patient records. The demo needed to show a believable workflow while clearly staying inside synthetic data.

Another challenge was making the Prompt Opinion integration reliable. Early versions ran into patient lookup issues, argument-shape mismatches, and provider behavior that made the demo harder to test. The fix was to make the MCP contract more forgiving while keeping the clinical output strict.

A third challenge was balancing risk logic. A system that flags everything as high risk is not useful. A system that under-flags dangerous cases is unsafe. RXsignal needed to show both sides:

$$ \text{High risk} \neq \text{any risk factor exists} $$

$$ \text{Low risk} \neq \text{no review needed} $$

The useful middle ground is explainable context. Age, medication type, dose, active meds, PDMP evidence, and documentation gaps all matter, but they should be weighted and shown clearly.

Accomplishments that we're proud of

We are proud that RXsignal feels like part of the clinical workflow instead of a detached demo screen.

The provider starts in the chart, enters a medication, sees RXsignal run at the right moment, and ends with documentation that can support the final decision. That flow matters because a safety tool only helps if it appears before the prescription is signed.

We are also proud of the explainability. RXsignal does not just say “high risk” or “low risk.” It shows the evidence behind the recommendation and keeps the clinician responsible for the decision.

The Prompt Opinion/MCP compatibility work was another major win. Supporting patient lookup and alias-friendly medication context calls made the prototype more realistic as an agent/tool integration instead of a hardcoded UI mockup.

What we learned

The biggest lesson was that clinical AI demos can look impressive while still being wrong in subtle ways.

It is easy to show a polished risk modal. It is harder to prove where the data came from, what was synthetic, what was chart context, what was a PDMP-style overlay, and why the recommendation was generated.

We learned to separate those layers clearly:

• Prompt Opinion or host workflow context supplies the patient/chart side.
• RXsignal supplies the medication-risk and synthetic PDMP overlay.
• The rules engine produces the recommendation.
• The clinician makes the final decision.

We also learned that compatibility details matter. A small mismatch in tool names or argument aliases can break the whole flow, even if the core logic is correct. Supporting lookup paths and aliases like FindPatientId, patientId, synthetic_patient_key, and proposedMedication made the system much more usable inside the Prompt Opinion workflow.

Finally, we learned that the best demo is not the one with the most screens. It is the one where the story is obvious: the provider is about to prescribe, RXsignal surfaces the risk before signature, and the chart ends up with better documentation.

What's next for RXsignal

The next step is making the prototype feel even closer to a real clinical integration while keeping the synthetic-only safety boundary clear.

That means improving the chart-context handoff, tightening the MCP tool contract, expanding the medication scenarios, and making the audit trail easier for a reviewer to follow. It also means adding more fail-safe paths, especially around patient identity, incomplete chart context, missing medication details, and uncertain PDMP matches.

Longer term, RXsignal should become a focused medication-safety sidecar:

Chart context in -> medication-risk evidence out -> clinician reviews -> chart documentation updated

The product direction is simple:

RXsignal makes medication-risk context visible before the clinician signs.

Not autonomous prescribing. Not a replacement for judgment. Better context, at the right moment, with a traceable reason why.

Built With

• a2a/byo-agent-compatible-workflow
• and
• and-pdmp-style-data.-no-real-phi-or-live-pdmp-data.-testing-/-qa:-node-test-scripts
• browser-frame-verification
• chart
• checks
• control:
• css
• deterministic-rules-engine
• ffmpeg-for-video-rendering-and-qa-framework-/-architecture:-mcp-style-tool-interface
• ffprobe/ffmpeg
• fhir-style-patient/chart-context
• findpatientid
• git
• github
• html
• javascript
• languages:-typescript
• markdown-runtime-/-tooling:-node.js
• mcp-endpoint-smoke-tests
• media
• medication
• medication-context-lookup
• npm
• playwright-for-browser/demo-validation
• prompt-opinion-compatible-patient-lookup
• pull
• request
• static-asset-tests
• static-ehr-style-demo-ui-platforms:-prompt-opinion-byo-agent-/-prompt-opinion-workflow
• synthetic-pdmp-style-overlay-data:-synthetic-only-patient
• vercel-cloud-services:-vercel-for-deployment-and-production-smoke-testing-apis-/-protocols:-model-context-protocol-style-tools
• version
• vite-style-static-demo-workflow