Inspiration
The US has the worst maternal mortality rate among high-income countries. What makes that worse is that a huge portion of postpartum deaths are not clinical failures -- they are paperwork failures.
Medicaid covers 42% of US births. It expires 60 days after delivery. The American Rescue Plan created a state option to extend that to 12 months, but patients still lose coverage because a renewal mailer got lost, a state portal timed out, or nobody flagged the deadline in time. A 2023 Commonwealth Fund report puts the number at 6.8 million people churning off Medicaid every year for purely procedural reasons.
Every "AI for maternal health" tool we looked at does the same thing: it reads the chart and tells a doctor something is wrong. Then the doctor has to go fix it. We wanted to build the thing that actually fixes it.
What it does
Trajectory.OS is an MCP server with three tools, callable by any agent on the Prompt Opinion platform.
AnalyzePostpartumCoverage reads a patient's FHIR record, extracts the delivery date, and computes exactly how many days are left before Medicaid expires:
$$\text{cliff date} = \text{delivery date} + 60 \text{ days}$$
If the patient is within 15 days, it generates a full intervention package -- a pre-written SMS, a pre-filled state Medicaid extension form with every field populated from the chart, and a flagged OB/GYN appointment with the required screenings. The agent extracts delivery dates from structured FHIR resources and, when those are missing, falls back to clinical NLP over discharge summaries — scoring date candidates by proximity to delivery-related keywords across multiple document types.
DispatchPostpartumAlert takes a single confirmation and actually executes: dispatches the SMS via Twilio, then writes a CommunicationRequest back to the patient's FHIR chart as a permanent audit trail. The EHR documents what was sent, when, and by whom -- automatically.
FindClinicalTrialsForPatient handles the case where coverage fails entirely. It queries ClinicalTrials.gov for actively recruiting trials matching the patient's condition and state, and drafts a ready-to-print referral letter. When the standard path closes, Trajectory.OS routes around it.
How we built it
Python 3.10 on FastAPI with FastMCP, exposing a streamable-HTTP MCP endpoint. The FHIR client is async httpx talking to a live FHIR R4 sandbox. Prompt Opinion forwards the patient session as three request headers per call -- server URL, SMART bearer token, and patient ID -- using their SHARP extension protocol.
The core analysis logic lives in one shared function used by both the analyze and dispatch tools. That was a deliberate call: it means the SMS body that actually gets sent matches exactly what the clinician previewed. No drift between the preview and the action.
The state policy table covers all 50 states and DC -- ARPA adoption status, agency phone numbers, and extension form names -- hand-curated from CMS and Commonwealth Fund sources. Clinical trial data is queried live from the public ClinicalTrials.gov v2 API. All patient data used in development is fully synthetic.
The AI reasoning layer handles what rules cannot: interpreting unstructured discharge summaries to extract delivery dates when structured FHIR Conditions are missing, contextualizing a patient's specific clinical and geographic situation against 50 state policy variations, and orchestrating a multi-step intervention chain (analyze → draft → dispatch → audit) from a single natural language clinical query. The LLM decides when the situation is critical, what to include in the patient communication, and how to adapt the workflow based on the patient's specific state policy and coverage status.
The server is deployed on Render and listed on the Prompt Opinion marketplace, where it is live and callable today.
Challenges we ran into
Delivery date extraction from unstructured clinical text was harder than expected. When the structured FHIR Condition resource is missing, you are left parsing free-text discharge summaries that might say "vaginal delivery on 3/20/26" or "delivered at 38 weeks on March 20" with no standard format. We built a regex-and-scoring approach that ranks date candidates by proximity to delivery-related keywords. It works, but it needed a lot of manual testing.
Twilio trial accounts prepend 39 characters of boilerplate to every SMS and reject messages longer than one GSM-7 segment (160 characters total). That left us about 120 characters to say something urgent and useful. We also had to strip every non-ASCII character -- one smart quote drops the segment ceiling from 160 to 70 and silently breaks delivery.
FastMCP does not natively support extension capabilities. To advertise the SHARP FHIR scopes, we had to monkey-patch _mcp_server.get_capabilities at startup. It works, but it is a fragile seam.
The hardest challenge was deciding what to cut. Panel mode, PDF generation, voice dispatch, two-way SMS handling -- all designed, all dropped. A single patient with a real SMS hitting a real phone is a better demo than five half-built features.
Accomplishments that we're proud of
It actually works end to end. The SMS arrives. The CommunicationRequest appears in the live FHIR sandbox. The state policy table covers all 50 states. The whole demo runs in under 90 seconds.
We are also proud of the infrastructure framing. Trajectory.OS is not an app -- it is a set of tools any SHARP-compatible agent can call. The value is in the capability, not the interface.
What we learned
The hardest part of healthcare AI is the plumbing. FHIR records are inconsistently populated. SMART scopes interact in non-obvious ways. Twilio trial limits are nowhere near obvious until you hit error 30044 at midnight. The gap between "works in a demo" and "survives a real clinical environment" is almost entirely in how you handle the cases where the expected data is missing.
We also learned that the posture of an AI tool matters as much as its capability. Most healthcare agents today are diagnostic -- they read and report. Shifting to prognostic and action-taking (predict the failure before it happens, then execute the fix) is a different design problem.
We learned to use the right tool for each layer: deterministic logic where patient safety demands precision, LLM reasoning where clinical context requires interpretation, and autonomous execution where speed saves coverage. The architecture is a hybrid by design — not because we avoided AI, but because we placed it where it creates the most value.
What's next for Trajectory.OS
The immediate next step is PDF generation of the pre-filled state forms. The JSON payload already has every field -- a PDF renderer is one layer away from making form submission truly one-click.
After that, the real production target is panel mode: a morning workflow that scans every postpartum patient within 15 days of their cliff and queues interventions for clinician review. It needs a system-scoped FHIR token and a lightweight approval UI, neither of which is architecturally complex.
Longer term, the reserved Observation and MedicationStatement scopes open the door to risk stratification -- surfacing patients with elevated blood pressure trends or PHQ-9 scores alongside the coverage alert, so the intervention includes clinical context, not just administrative context. And if the OBBBA Medicaid work-requirement changes go through, the same architecture applies directly to a new category of coverage cliff -- different policy table, same tools.
Log in or sign up for Devpost to join the conversation.