Inspiration
OneAquaHealth already uses HL7 FHIR to standardize environmental and population-health data, but structural validity does not guarantee trustworthy evidence.
A real example from the OAH sandbox made this clear: one structurally valid Observation reports a mean water temperature of about 198,000 °C while the median is 19.8 °C.
That led to the core idea behind OAH Agent Gateway:
FHIR gets data to an AI agent. The gateway decides whether that evidence is safe to reuse.
What it does
OAH Agent Gateway is an interoperability layer between OneAquaHealth FHIR data and AI agents.
It:
- queries official OAH environmental and population-health FHIR data
- assigns deterministic
OK,CAUTION, orDO_NOT_USEtrust states - preserves FHIR references and caveats in agent answers
- combines environmental and community-health evidence for One Health queries
- converts citizen observations into OAH-aligned FHIR
Observation+Provenance - requires explicit human approval before any write-back
- exposes the same capabilities through a Streamlit web app and MCP tools
The AI never decides whether a record is trustworthy. That decision is always made by deterministic code.
How we built it
The gateway is written in Python and uses the official OneAquaHealth FHIR Implementation Guide.
The main layers are:
- FHIR ingestion and normalization for water, air, and population-health records
- Deterministic trust engine for physical, statistical, origin, and unit checks
- Plain Python gateway tools as the single source of truth
- MCP server for external AI-agent access
- NVIDIA Nemotron 3 Super for the built-in agent
- Streamlit for the judge-facing web application
- FHIR Provenance for citizen-data authorship and AI-assisted assembly
- Snapshot + live modes for reproducible demos and real sandbox access
A typical agent flow is:
Question → Gateway tool → Trust checks → FHIR evidence → Agent answer
For example, a Benevento One Health query can combine air-quality and population-health indicators while retaining source Observation/... references and explicitly avoiding causal claims.
The reverse direction is also supported:
Citizen observation → FHIR draft → Provenance → Human approval → Bundle/write
Challenges
The hardest problem was separating FHIR validity from evidence quality.
FHIR can ensure that a resource is structurally interoperable, but it cannot guarantee that values are physically plausible or internally consistent. We therefore built trust checks outside the LLM, including range checks, statistical consistency checks, origin checks, unit checks, and cross-record checks such as PM2.5 exceeding PM10.
Another challenge was keeping AI useful without giving it authority over safety-critical decisions. The model can choose tools and summarize evidence, but it cannot change trust verdicts or silently correct suspicious source data.
We also had to keep the demo reproducible while working with a shared public FHIR sandbox. The app therefore supports both live data and a dated snapshot mode.
What we learned
The biggest lesson was that interoperability for AI agents needs more than standardized schemas.
Agents also need:
- evidence quality
- provenance
- source traceability
- trust-state preservation
- explicit human control over writes
We also learned that interoperability should work in both directions: existing standardized data should be safely consumable by agents, while new citizen observations should be able to enter the same standards ecosystem with provenance and human oversight.
What’s next
Next steps include:
- broader support for additional OAH-compatible FHIR servers
- more citizen-observation profiles
- automated conformance checks for external servers
- richer cross-city comparisons
- packaging the gateway as a reusable interoperability service beyond the Streamlit showcase
Log in or sign up for Devpost to join the conversation.