Health Insight 365

Public Architecture

A high-level view of the Health Insight 365 system and its information boundaries

This page describes how Health Insight 365 is organized without publishing credentials, internal addresses, database structures, cloud resource identifiers, security rules, or operational procedures that could increase risk.

Logical system flow

Architecture layers

Client experience

The native iPhone application presents account, profile, upload, insight, report, action-tracking, permission, purchase, export, and Help experiences. Sensitive session credentials are stored using iOS-provided secure storage. An optional account-specific App Lock uses Apple’s Local Authentication framework to protect the authenticated interface when the App returns from the background.

Identity and authorization

Email, Apple, and Google account paths establish identity. Authenticated requests are checked against the owner of each protected profile, upload, report, action, and preference.

Application services

Server-side services validate requests, coordinate file processing, calculate deterministic health measures, prepare report data, manage account activity, and enforce environment and account boundaries.

Protected persistence

Account records and private uploaded objects use encrypted managed storage with access restricted by application role and environment. Retention and deletion follow the published Privacy Policy.

Analysis Engine

Approved, malware-cleared report content may be sent for structured extraction and educational analysis. Temporary processing material is subject to cleanup controls. The engine is constrained against diagnosis and treatment instructions.

Platform integrations

Apple and Google support authentication; Apple supports in-app purchase verification, user-controlled Health access, and on-device Face ID or device-passcode evaluation for optional App Lock. Biometric templates and device passcodes remain under iOS control. Email infrastructure supports requested messages and operational communication.

Principal information flows

Environment and account boundaries

Development, staging, and production follow separate configurations and data boundaries. A build selects its environment before authentication. An account and its data in one environment do not automatically exist in another. Within each environment, profiles, preferences, avatars, reports, purchases, actions, and activity records are scoped to the authenticated account.

Defense-in-depth principles

Important: This public architecture is a transparency summary, not a security certification, penetration-test report, or guarantee that vulnerabilities do not exist. Detailed controls and response procedures remain restricted.