Software evolution log · 2019 → 2026

Vera software platform · s1.0 → s4.0

One digital backbone, adapted four times. Each version added, modified, or removed specific features in response to a measurable operational requirement that the previous build could not meet. Every software version shipped paired with a mobile-unit hardware version. This page is the change log of the digital layer.

s1.0 · base digital layer

Smart Health Profile · door-to-door digital intake

2019–2020 · India · AP + Telangana + Tamil Nadu · 9 community deployments
Paired with v1.0 Coach →
First buildNo prior version
Operational requirement that triggered s1.0
Deliver a portable, government-shareable digital health record for door-to-door deployment in communities with no permanent EMR infrastructure. Paper intake forms were too slow, too error-prone, and could not feed government referral chains in real time.
+ Added in s1.0
  • Door-to-door digital intake form — tablet-based, offline-capable
  • Digital Health Card — per-citizen unique ID with government seal
  • IoT vitals integration — BP, glucometer, ECG devices → cloud sync
  • 38-condition checklist — RBSK-compatible screening schema
  • Government dashboard — district-level aggregate view
  • Referral chain integration — routing to DH / PHC / CHC / DEIC / AFHC
± Modified in s1.0
  • — first build, nothing to modify —
− Removed in s1.0
  • — first build, nothing to remove —
4,824Students profiled (Aarogya TG)
56Govt schools (Medchal)
6Urban communities (Hyderabad)
38Condition checklist
s1.0 reference rendering · pending
Smart Health Profile UI illustration coming soon — tablet intake form, Digital Health Card mock, IoT vitals device, government dashboard view.
s1.0 reference deployment → v1.0 hardware pair →
s1.0 limitations carried into next requirement set → No real-time state-scale pipeline · no traveller tracking · no COVID schema
s2.0 · +state-scale pipeline

TTS + iMASQ Analytics · state-scale data pipeline

2020 · India · AP + Telangana · CMO live feed · district-level analytics
Paired with v2.0 iMASQ →
Built ons1.0 record schema
Operational requirement that triggered s2.0
COVID-19 emergency required state-scale traveller tracking with GPS check-in and symptom intake, a real-time sample-pipeline analytics layer across a 170-bus fleet, and a live data feed into the Chief Minister's Office for daily containment decisions. s1.0's per-deployment Profile model had no real-time or fleet-wide layer.
+ Added in s2.0
  • TTS app — India's first state-level traveller tracking system
  • GPS check-in — transit-hub and interstate-border lanes
  • Symptom intake form — standardized COVID schema
  • Live CMO feed — data stream into Chief Minister's Office
  • iMASQ sample-pipeline tracking — VTM packaging → lab handoff
  • District-level analytics dashboard — Govt of AP cumulative chart
± Modified in s2.0
  • Coverage view — point-deployment dashboards → district heat-map
  • Data velocity — daily batch reports → live state feed
  • Fleet scope — 4 units → 170+ units in pipeline view
− Removed in s2.0
  • General Profile schema — suspended for COVID single-use
  • School-screening flow — not used during emergency mode
11 / 13AP districts covered
1MSamples in pipeline · 150 days
9,700Staff onboarded
Top 10Analytics India AI Collab · 2020
s2.0 reference rendering · pending
TTS + iMASQ Analytics UI illustration coming soon — phone with Govt of Telangana seal + GPS check-in, district heat-map dashboard, CMO live-feed view, cumulative milestone chart.
s2.0a reference (TTS) → s2.0b reference (iMASQ) → v2.0 hardware pair →
s2.0 limitations carried into next requirement set → Aggregate counts only · no patient-level vitals stream · no bedside layer
s3.0 · +telemetry

Critical-care telemetry · per-bed vitals stream

2021 · India · Telangana · COVID second wave · 24×7 operations
Paired with v3.0 Mobile ICU →
Built ons2.0 pipeline + iMASQ telemetry base
Operational requirement that triggered s3.0
Mobile ICU deployment required real-time bedside monitoring and a centralized 24×7 operations console for multi-bus coordination. s2.0's aggregate-counter view had no patient-level telemetry, and no per-bed vitals stream existed in the prior software stack.
+ Added in s3.0
  • Per-bed ECG telemetry — live waveform stream per patient
  • O&sub2; saturation feeds — pulse-oximetry per bed
  • Live vitals dashboard — 6-bed view per bus
  • 24×7 critical-care operations console — central ops layer
  • Fleet coordination view — multi-bus visibility, bed availability
± Modified in s3.0
  • Data granularity — aggregate counts → patient-level vitals
  • Operating profile — daytime → 24×7 critical-care
  • User role model — field operators → clinical-grade nursing
− Removed in s3.0
  • Sample-pipeline tracking — no longer the active mission
  • Traveller tracking flows — deprecated for ICU role
6Beds · ECG streams per bus
24×7Operating profile
Live O&sub2;Per-bed saturation feed
Central opsMulti-bus coordination
s3.0 reference rendering · pending
Critical-care telemetry UI illustration coming soon — 6-bed live vitals dashboard with ECG waveforms and O&sub2; saturation gauges, central ops console showing fleet-wide bed availability.
s3.0 reference deployment → v3.0 hardware pair →
s3.0 limitations carried into next requirement set → No HIPAA compliance · no US insurance billing · no pre-deployment screen layer
s4.0 · +US compliance + billing

Face-sheet portal + US billing · US-market compliance layer

2023–2026 · United States · Florida · HIPAA-compliant · 4-channel billing
Paired with v4.0 FL Dental →
Built ons1.0 record schema · US-spec re-platform
Operational requirement that triggered s4.0
US deployment required HIPAA-compliant patient intake, pre-deployment face-sheet upload by senior community administrators, and a US insurance-billing layer spanning Medicare Advantage, Medicaid, commercial dental, and self-pay. The prior India-spec stack had no US compliance, no payer integration, and no operator-mediated intake model.
+ Added in s4.0
  • Face-sheet pre-screen software — senior community uploads patient face sheets pre-deployment
  • Vera ALF upload portal — portal.verahealthcareusa.com
  • HIPAA-compliant intake + storage — Supabase HIPAA BAA
  • Insurance-billing layer — Medicare Advantage + Medicaid + commercial dental + self-pay
  • Dentition pre-screen logic — e.g. dentures → no radiographs
  • 2-day camp scheduler — Day 1 dentist + Day 2 hygienist
± Modified in s4.0
  • Data-sharing chain — government-only → private US insurance + operator
  • Identity model — per-citizen Health Card → ALF-mediated patient intake
  • Compliance regime — Indian Govt seal → US licensed entity (Vera Healthcare Florida LLC)
− Removed in s4.0
  • Government dashboard layer — no equivalent US client
  • Population-screening Profile — replaced with individual-procedure pathway
  • State-CMO live feed — not applicable in US context
12FL communities · 2024
207Residents seen · 2024
4Billing channels integrated
HIPAACompliance regime (Supabase BAA)
s4.0 reference rendering · pending
Face-sheet portal UI illustration coming soon — ALF upload portal screen with face-sheet drag-and-drop, HIPAA badge, scheduler view for Day 1 + Day 2 camp model, US insurance-billing channel selector.
s4.0 reference deployment → s4.0 active service → v4.0 hardware pair →