Houbad — Smart Ambulance MVP & Technical Acceptance

Context

Sep 2025 — Present · Ongoing role; ambulance MVP field-tested and later stopped because of hardware constraints · Maturity: Controlled Field Test.

Problem

The smart-ambulance initiative entered with an incomplete product design and multiple software, IoT, medical-device, infrastructure, and stakeholder dependencies; separate confidential projects also needed contract-based technical acceptance.

Users

EMS operators, ambulance teams, command-center/authorized medical stakeholders, and enterprise stakeholders involved in contracted system delivery.

My Role

Official title: Researcher. Functional scope: Product Manager, cross-functional coordination, and technical acceptance.

Responsibilities

• Translated an incomplete concept into user scenarios, flows, MVP priorities, requirements, and executable tasks without a dedicated designer.
• Coordinated a small delivery group spanning two frontend developers and one-to-two backend developers plus software/IoT/medical-device/infrastructure dependencies.
• Turned contract appendices for four confidential vendor-delivered systems into acceptance criteria, UAT/integration scenarios, remediation checks, and evidence-based delivery recommendations.

Constraints

• No dedicated designer during the smart-ambulance work.
• Hardware limitations stopped broader ambulance validation in Esfand 1404.
• No live-patient mission validation and no final production deployment.
• Confidential client identities, system architectures, capabilities, and operational details cannot be published.

Product Decisions

• Prioritize the end-to-end emergency workflow rather than represent the much larger target architecture as delivered scope.
• Keep patient-refusal confirmation traceable with an OTP-backed mission record.
• Use executable acceptance scenarios and evidence for approve / conditional-approve / reject recommendations.

Delivery & Technical Approach

• Worked across call intake, location/dispatch, in-vehicle tablet missions, Neshan routing, medical-sensor visibility, patient records, remote visibility, mission closure, and OTP-based refusal flow.
• Performed hands-on functional/integration acceptance, documented defects/non-conformities, followed remediation, and retested revised deliveries.

Product flow

1. Call intake & location
2. Ambulance selection / dispatch
3. Tablet mission
4. Neshan route
5. Medical-sensor visibility
6. Patient record
7. Mission closure / OTP refusal

Evidence / Outcome

• Reached an initial smart-ambulance MVP in approximately seven months.
• Conducted a controlled EMS field test on two real ambulances.
• Supported technical acceptance across four confidential vendor-delivered security systems.

What I Learned

• A large target architecture is not the same as implemented product scope.
• Technical acceptance becomes much stronger when contractual requirements are converted into observable test scenarios.
• In enterprise delivery, evidence boundaries and confidentiality are part of product communication.

Evidence Boundary

Next Iteration

For any future ambulance restart, validate hardware readiness first, then expand from controlled flow testing toward broader operational evidence without skipping safety and acceptance gates.