MaternaVoice

A voice-first Alexa+ experience that flags high-risk pregnancies from real FHIR data and speaks the warning aloud — verified end-to-end against a live MCP server, not a mock.

Comment

Inspiration

In Nigeria, a large share of women who attend antenatal care (ANC) visits still don't deliver in a health facility — the gap between ANC attendance and facility delivery is well documented in NDHS data. This is the ANC Paradox: a mother can do everything "right" during pregnancy and still be at serious risk during delivery, because the system has no way to catch the gap between attending care and actually planning a safe delivery.

I've spent 15+ years working with healthcare data at University of Calabar Teaching Hospital, and this pattern shows up again and again. MaternaVoice grew out of an earlier project, MaternaGuard, which proved the detection pipeline could work. This hackathon was the chance to give that pipeline a voice — literally — through Alexa+.

What it does

MaternaVoice is a voice-first experience that:

  1. Scouts a patient's FHIR record for the ANC Paradox pattern — adequate antenatal visits, but no clear facility-delivery plan
  2. Scores risk against real clinical red flags pulled from the record (blood sugar, gestational age, delivery intent)
  3. Explains the risk in short, plain language a community health worker can read or speak aloud to a family with no medical background
  4. Acts by writing a real, auditable observation back into the patient's FHIR record

Every step runs against a real, deployed FHIR MCP server — not mock data — and every run produces a timestamped, verifiable log entry.

How I built it

Track: Alexa+

The architecture:

CliniqBridge (live FHIR R4 MCP server, JSON-RPC 2.0, Streamable HTTP) | v Scout Agent (Nemotron 3 Nano) -- flags the ANC-Paradox pattern | v Risk Agent (Nemotron 3 Nano) -- scores against clinical red flags | v Explain Agent (Nemotron 3 Ultra) -- plain-language, voice-ready explanation | v Action Agent (Nemotron 3 Nano) -- writes a real FHIR Observation back | v job_history.jsonl (timestamped, real, verifiable audit log) | v Simulated Alexa+ voice host -- speaks the explanation aloud

CliniqBridge is a FHIR R4 MCP server I built and maintain, reused as infrastructure across several of my maternal-health projects. For this hackathon I brought it up to spec 2025-11-25 compliance (Streamable HTTP, correct protocolVersion, real JSON output instead of Python's str() repr, and proper Origin validation instead of a CORS wildcard).

The four-agent pipeline adapts a pattern from my earlier project MaternaGuard, now pointed at CliniqBridge's real tool names (get_patient_summary, get_conditions, get_encounters, get_observations, create_observation). Each agent has a single job, sized to the reasoning it actually needs.

The web front end simulates the Alexa+ experience: type a patient ID, and the browser calls the real pipeline and speaks the result aloud via the SpeechSynthesis API.

Why simulated, not a certified Alexa+ add-on: Amazon's Alexa+ Category SDK / MCP Toolkit is currently limited to select partners. The hackathon's own Alexa+ track description explicitly names this path — simulating the experience via a web app using open MCP standards (Agent Skills, Streamable HTTP) — so that's the route this project takes.

Reproducibility: because the public HAPI FHIR test server periodically resets its data, I built seed_demo_patient.py, which creates a fresh patient with a real, self-contained clinical profile immediately before any run. Anyone reviewing this project gets the same guarantee I did: a real patient, real data, real agent reasoning, every time.

Challenges I ran into

  • The public FHIR test server silently lost my demo data between sessions, which looked like a bug in my detection logic before I traced it to the server resetting. Fixed by making the pipeline self-seeding rather than dependent on data surviving externally.
  • A real bug in my own encounter-matching logic: this FHIR dataset labels all visits generically as "Clinical Visit" rather than tagging them antenatal-specific, so my first version of Scout saw zero ANC visits when there were actually six. Fixed by using encounter count as the visit-adequacy proxy and reading delivery-intent signals directly from observations instead.
  • AWS Bedrock access hit two separate account-level blocks — a new-account verification hold, then a ValidationException: Operation not allowed on Nova model invocation that AWS's own community forums show as an unresolved backend issue for some accounts, unrelated to IAM permissions or code. I built the Bedrock integration as an isolated, toggleable path (EXPLAIN_PROVIDER=bedrock vs. nebius) specifically so this wouldn't put the core submission at risk — the verified Nebius path stayed the default throughout.
  • Real Alexa+ Private Preview access turned out to be select-partners-only as of this hackathon — confirmed directly from Amazon's own developer docs, not assumed. This is why the submission uses the sanctioned simulated-experience path instead.

Tool feedback

  • CliniqBridge (my own MCP server): building a real JSON-RPC 2.0 dispatcher from scratch surfaced how easy it is to accidentally ship a server that "looks like" MCP (a manifest + REST endpoints) without actually being spec-compliant. Would benefit from a lightweight local conformance checker.
  • MCP Apps / Streamable HTTP (open standard): straightforward once understood, but the gap between "Alexa+ Builder Docs" (partner-gated) and "the actual open-standard resources the hackathon links to" was not obvious at first and cost real time to untangle.
  • Amazon Bedrock: the free-tier account verification hold and the ValidationException: Operation not allowed error on Nova (also reported by other users on AWS's forums) were the two biggest friction points of this entire build — neither was diagnosable from documentation alone.
  • Nebius Token Factory: reliable and fast once the correct model ID strings were confirmed directly against the /v1/models endpoint — third-party aggregator sites listing "the" Nemotron 3 model ID were inconsistent and cost time before I checked the source directly.

What's next

  • Resolve the AWS Bedrock backend issue with AWS Support and complete the AWS Builder mini-challenge integration
  • Add retry/dedup logic to the Action agent
  • Confirm the correct LOINC code for the ANC-Paradox risk observation against a real terminology server
  • Pursue real Alexa+ Private Preview access if/when it opens beyond select partners

Built With

  • alexa+
  • aws-bedrock
  • boto3
  • fastapi
  • fhir
  • github
  • hl7
  • httpx
  • javascript
  • json-rpc
  • mcp
  • nebius-token-factory
  • nemotron-3
  • python
  • render
  • speechsynthesis-api
  • streamable-http
  • uvicorn
Share this project:

Updates

Submission history