Built for regulated healthcare from day one

The platform is designed with the expectation that it will handle PHI and other sensitive clinical data, with a clear separation between demo content and production-grade deployments.

• Encryption in transit and at rest (design assumption for production)
• Role- and scope-based access control around PHI
• Audit logging of user access and key data operations
• Architecture that can support Business Associate Agreements (BAAs)

The Home Health Hub and Intelligence Layer are positioned as decision support, not autonomous diagnosis. Clinicians remain the final decision-makers.

• All real-world results designed to be reviewed by licensed clinicians
• Configurable escalation pathways for urgent or ambiguous findings
• Separation of raw readings vs. clinician-verified interpretations
• Traceable audit trail of clinical decisions linked to Hub sessions

The ultimate FDA pathway will depend on the final test menu and positioning, but the architecture is being developed in a way that can be reasoned about by regulatory teams.

• Separation between hardware, firmware, and software-as-a-medical-device (SaMD) concepts
• Foundational documentation patterns to support future submissions
• Alignment to quality and risk-management thinking (ISO 13485-esque posture)
• Room for acquirers to determine and own final regulatory strategy

The Home Health Hub ecosystem assumes that PHI will be present in signals, logs, and payloads. That assumption drives the way components are separated and how data is expected to flow in production.

• Logical separation of Hub, cloud services, and portals
• Data minimization principles for what leaves the device
• Clear boundaries between PHI-bearing stores and configuration/meta-data
• Support for per-tenant or per-partner data isolation models

AegisOne is not being represented here as a fully audited HIPAA-compliant service today. Instead, the system is being designed so an acquirer or partner can apply their own controls, audits, and BAAs.

• Architecture compatible with typical covered-entity and BAA expectations
• Support for adopting acquirer identity, access, and logging standards
• Recognition that formal HIPAA audits would occur post-acquisition or partnership
• Separation of demo/non-PHI environments from production PHI environments

Nothing on this page is legal advice or a compliance certification; it is a description of design intent and posture for diligence purposes.

The device and Intelligence Layer surface patterns and suggested interpretations, but do not replace clinicians. This aligns with how acquirers and regulators typically want home diagnostics positioned.

• Clinician review before final interpretations or prescriptions
• Ability to override, annotate, or reject device or model suggestions
• Support for institutional clinical guidelines and routing rules
• Logs that show what the Hub suggested vs. what the clinician decided

The ecosystem is designed to support configurable escalation and safety scenarios: “If this result + these vitals + these symptoms, then escalate to…”

• Configurable triage rules for high-risk findings
• Hooks for telehealth escalation, nurse lines, or in-person referrals
• Ability to align rules with partner/health-system playbooks
• Event-level audit trail of how escalations were triggered and handled

The current concept emphasizes standardized at-home testing and clinician-supported interpretation. This keeps AegisOne closer to a home diagnostics + decision support posture, rather than an unbounded AI that “decides” care on its own.

• Clear split between hardware, cartridges, and cloud logic
• Intelligence Layer framed as supporting clinician judgment
• Ability to adjust positioning per acquirer’s regulatory strategy
• Room for test-specific submissions where needed (e.g., particular panels)

While AegisOne is not presented as FDA-cleared, the product is being shaped in a way that can later support structured documentation, traceability, and change control.

• Separation of safety-critical logic from ancillary UX/UI elements
• Conceptual support for versioning, change logs, and traceability
• Architecture that can map onto formal quality systems
• Expectations that an acquirer’s regulatory team will own final filings

AegisOne is designed to output structured data that matches how providers already document and bill care.

• FHIR/HL7-aligned concepts for observations and diagnostic reports
• Support for attaching Hub events to existing patient records
• Integration thinking that respects system-of-record boundaries
• Room to adopt acquirer-specific EHR integration patterns and vendors

The architecture anticipates that different acquirers or partners may require specific hosting regions or residency constraints.

• Ability to align deployments with regional hosting requirements
• Logical sharding and isolation models for partners or programs
• Support for separation of demo/sandbox vs. production data planes
• Compatibility with enterprise backup, DR, and retention policies

AegisOne expects to live inside a larger organization’s governance and risk processes, not define them.

• Support for partner-driven policies, roles, and review workflows
• Audit trails aligned to internal committee and review structures
• Clear definition of what AegisOne is responsible for vs. host systems
• Separation of product concerns from enterprise policy decisions

The Intelligence Layer is being designed so that Hub events can be mapped to billing and coding frameworks, making it easier for acquirers to plug into existing revenue and value-based models.

• Events tied to test types, encounters, and clinician actions
• Support for mapping to CPT/ICD and payer-specific requirements
• Separation between test event logs and claims-facing summaries
• Space for acquirers to incorporate their own coding guidelines

Beyond single claims, AegisOne can support program-level reporting for chronic condition programs, remote care initiatives, and employer or plan-sponsored benefits.

• Longitudinal tracking of Hub use by condition, household, or program
• Signals to support value-based and risk-sharing arrangements
• Ability to segment reports by payer, employer, or program design
• Alignment with the broader analytics stack of an acquirer