AquaPass

Inspiration

Urban water health decisions are rarely limited by a complete absence of data. In many cases, the real problem is that evidence is fragmented across citizen observations, environmental monitoring systems, field teams, researchers, and public institutions.

When an incident occurs, decision-makers may already have a large amount of information but still face a much harder question:

What do we need to know next, which decision will it change, and why now?

This inspired us to build AquaPass - Decision-Aware Evidence Orchestration for One Health.

Instead of building another monitoring dashboard or an AI system that simply predicts risk, AquaPass focuses on the gap between having data and making an evidence-based decision.

Our goal is to help One Health stakeholders identify the most valuable missing evidence, coordinate its collection through interoperable standards, and bring the result back into the same incident before a human makes the final decision.

What it does

AquaPass is a decision-aware evidence orchestration layer for urban aquatic One Health incidents.

The workflow starts with a pending decision, not simply with a collection of data.

For each incident, AquaPass:

Organizes existing evidence into an Evidence Graph.
Identifies evidence that is missing, conflicting, stale, or low-confidence.
Generates candidate evidence that could help resolve the pending decision.
Ranks those candidates based on their practical decision value.
Explains WHY a particular piece of evidence should be collected.
Allows a human operator to confirm the recommendation.
Converts the recommendation into an Evidence Request.
Sends the request to the appropriate actor or system through FHIR and REST APIs.
Tracks the request through its lifecycle.
Receives the new evidence and attaches it back to the same incident.
Re-evaluates the decision context.
Keeps the final action under human approval.

The core AquaPass workflow is:

Pending Decision -> Evidence Gap -> Next Best Evidence -> Evidence Request -> Collection -> Same Incident -> Decision Update -> Human Approval -> Action

AquaPass therefore does not ask:

"How much more data can we collect?"

It asks:

"Which evidence is worth collecting now for this specific decision?"

How we built it

We designed AquaPass as a modular platform with several components working together around one decision-centered workflow.

Decision-First User Interface

The AquaPass interface is designed around decision-making rather than data dumping.

The main workflow prioritizes:

Pending Decision
Current Evidence
Evidence Gap
Next Best Evidence
WHY explanation
Evidence Request
Request Status
Decision Update
Human Approval

Instead of forcing users to search through large dashboards, AquaPass shows what information matters for the current decision.

Incident and Evidence Management

Each case is represented as an incident containing the evidence that is currently available.

Evidence can come from different sources such as:

Environmental sensors
Citizen observations
Field teams
Researchers
Monitoring systems
Weather information
External APIs

All evidence remains connected to the same incident so that users can understand how the situation changes over time.

Evidence Graph

AquaPass uses an Evidence Graph to represent relationships between:

Incidents
Evidence
Evidence sources
Pending decisions
Evidence gaps
Evidence requests
Returned observations
Decision updates

This allows the system to reason about what information already exists and what information is still missing.

Conflicting evidence is not silently removed or averaged away. Instead, the conflict can remain visible so that AquaPass can recommend additional evidence when necessary.

Decision-Aware Evidence Engine

The main intelligence of AquaPass is the Decision-Aware Evidence Engine.

Candidate evidence is evaluated based on factors such as:

Decision impact
Expected uncertainty reduction
Reliability
Availability
Urgency
Decision-window fit
Collection time
Collection cost
Resource constraints

Conceptually, evidence priority can be represented as:

DecisionValue(e) = w1*I + w2*U + w3*R + w4*A + w5*T - w6*C

where:

I = potential impact on the pending decision
U = expected uncertainty reduction
R = evidence reliability
A = evidence availability
T = suitability for the current decision window
C = collection cost and resource requirements

The weights can be configured depending on the operational context.

This means AquaPass does not automatically prefer the evidence with the greatest theoretical information gain.

For example, one measurement may be scientifically useful but take several days to obtain, while another slightly less informative measurement may be available within two hours and directly affect an urgent decision.

In that situation, AquaPass can prioritize the evidence with greater practical decision value.

AI Assistance

AI can support tasks such as:

Summarizing existing evidence
Identifying possible evidence gaps
Generating evidence candidates
Producing human-readable WHY explanations
Helping users understand the current incident

However, AI does not make the final decision.

Our architecture follows a simple principle:

AI proposes and explains.

Deterministic logic ranks.

Humans approve.

This keeps AquaPass human-in-the-loop and reduces the risk of treating AI as an autonomous environmental or health authority.

Evidence Request Orchestration

A recommendation becomes useful only when it can result in action.

After AquaPass identifies the Next Best Evidence, the user can create an Evidence Request.

A request can move through a lifecycle such as:

Created -> Assigned -> Accepted -> Collecting -> Returned -> Completed

This connects the recommendation engine with actual evidence acquisition.

FHIR and API Interoperability

AquaPass was designed to align with Track 7 - Digital Health Standards.

Evidence requests and returned observations can be represented or mapped using interoperable concepts such as:

FHIR ServiceRequest
FHIR Task
FHIR Observation
REST API exchanges

FHIR is not the main innovation of AquaPass.

Instead, interoperability is the mechanism that allows a decision-aware evidence workflow to move between different actors, organizations, and systems.

The goal is not only:

System A can exchange data with System B.

The goal is:

A decision requires evidence -> AquaPass requests it -> another actor collects it -> the result returns to the original incident -> the decision context changes.

Closed-Loop Workflow

One of the most important parts of AquaPass is that the workflow does not stop after recommending evidence.

The complete loop is:

Incident -> Pending Decision -> Evidence Gap -> Next Best Evidence -> WHY -> Evidence Request -> Actor -> FHIR/API -> New Evidence -> Same Incident -> Decision Update -> Human Approval -> Action

When new evidence returns, it is attached to the same incident.

AquaPass then updates the decision context so users can immediately see whether the new information reduced uncertainty or changed the recommended action.

Challenges we ran into

One of our biggest challenges was avoiding evidence overload.

A system could easily recommend collecting every possible measurement. However, real field teams have limited:

Time
Staff
Sensors
Laboratory capacity
Budget
Access to locations

We therefore designed AquaPass around decision value instead of data volume.

Another challenge was handling conflicting evidence.

Environmental observations do not always agree. A citizen observation, sensor reading, satellite signal, and laboratory result may provide different indications.

Instead of hiding these differences, AquaPass represents conflicting evidence explicitly and can recommend additional corroborating evidence.

Interoperability was another major challenge.

Citizen applications, environmental platforms, laboratories, researchers, and public institutions can all use different data structures.

We therefore separated AquaPass's internal models from its interoperability layer so that external systems can be integrated through adapters and APIs.

We also had to carefully define the role of AI.

We did not want AquaPass to become a black-box system that automatically makes environmental or health decisions.

This led us to adopt a human-in-the-loop architecture where AI supports the workflow but humans retain final authority.

Finally, scope management was difficult during the hackathon.

AquaPass could easily expand into:

Environmental monitoring
Risk prediction
Citizen science
Mapping
Alert systems
Automated reporting
Resource management

To control scope, we continuously returned to one question:

Does this feature strengthen the core decision-to-evidence loop?

If not, it was not considered a core feature of the prototype.

Accomplishments that we're proud of

We are proud that AquaPass goes beyond simply displaying environmental information.

We designed a complete closed-loop workflow connecting:

Evidence -> Decision -> Missing Information -> Evidence Collection -> Updated Decision

Instead of stopping after recommending information, AquaPass can turn a recommendation into an actionable Evidence Request.

The request can be tracked, completed, and returned to the original incident.

We are also proud of the separation between:

AI assistance
Deterministic ranking
Interoperability
Human authority

This makes the system more transparent and easier to understand.

Another important accomplishment is traceability.

For an evidence request, AquaPass aims to answer:

Why was this evidence requested?
Which decision required it?
Who was asked to collect it?
When was it requested?
What evidence was returned?
What source produced the evidence?
How did the decision change afterward?

This creates an evidence trail instead of an unexplained AI recommendation.

We also designed AquaPass around real operational constraints rather than assuming unlimited resources.

The best evidence is not always the most scientifically informative evidence.

Sometimes the best evidence is the one that provides enough reliable information to affect a decision within the available time and resource constraints.

Our key differentiation can be summarized as:

OneAquaHealth connects environmental evidence. AquaPass connects evidence to decisions.

What we learned

The most important lesson we learned is that more data does not automatically create better decisions.

A useful One Health system must understand not only what information exists, but also what information is missing for a specific decision.

We also learned that interoperability becomes much more valuable when it is connected to a real workflow.

FHIR is not useful to us simply because two systems can exchange information.

Its real value appears when interoperability allows:

Decision -> Request -> Collection -> Observation -> Updated Decision

We also learned that evidence acquisition should account for real-world constraints.

A theoretically ideal measurement may not be the most useful measurement if:

It is unavailable
It costs too much
It takes too long
It requires unavailable equipment
It arrives after the decision deadline

This motivated our use of decision-aware ranking rather than simply maximizing information gain.

Another important lesson was the importance of explainability.

A recommendation such as:

"Collect dissolved oxygen."

is much less useful than an explanation such as:

"Collect dissolved oxygen because the current evidence is insufficient to determine whether the incident requires escalation, and this measurement has high expected decision value within the available decision window."

Finally, we learned that AI works best in this context as a copilot rather than an authority.

Our principle became:

We don't ask AI to make the decision. We ask it what we need to know before humans make it.

What's next for AquaPass

The current AquaPass prototype demonstrates the core concept of decision-aware evidence orchestration.

Our next step is to connect AquaPass with more real-world One Health and environmental data sources instead of relying on prototype or simulated evidence for parts of the demonstration.

We also want to extend the interoperability layer with additional FHIR-compatible and REST-based adapters so that AquaPass can communicate with:

Environmental monitoring platforms
Citizen-science applications
Laboratories
Field teams
Research institutions
Government information systems
Sensor networks
One Health platforms

Future development will focus on:

Real OneAquaHealth ecosystem integration
More evidence-source adapters
Improved evidence reliability models
More advanced Evidence Graph reasoning
Configurable decision-value scoring
Multi-organization workflows
Stronger provenance and auditability
Field-team mobile workflows
Real-world evaluation with domain experts
Evaluation of decision relevance
Measurement of uncertainty reduction
Resource-efficiency analysis
More advanced request orchestration
Better accessibility
Additional FHIR mappings

We also want to evaluate AquaPass using metrics such as:

Decision relevance
Top-1 evidence ranking agreement
Time-to-useful-evidence
Decision uncertainty reduction
Resource efficiency
Evidence-request completion
Evidence provenance completeness

In the long term, AquaPass could act as an orchestration layer between existing One Health systems.

We do not want to replace existing environmental monitoring platforms.

We want to help those platforms answer the next question: