Protected health information, protected by design
This architecture overview is under factual and legal review. Code-level controls are not proof of production configuration, completed operational procedures or signed vendor coverage. A healthcare deployment requires verified safeguards and appropriate executed agreements.
Data protection
Application controls and infrastructure safeguards must work together.
Encryption at rest (AES-256-GCM)
Designated sensitive fields use application-layer AES-256-GCM encryption with tenant-derived keys. Not every clinical value is field-encrypted; database, object-store and backup encryption also require deployment verification.
Encryption in transit
The application includes transport and browser-security headers. TLS, certificate validation and effective edge configuration must be checked for the deployed service and each provider path.
Redaction is not a de-identification determination
Export redaction can reduce direct identifiers, but does not by itself establish HIPAA Safe Harbor or expert-determined de-identification. Any secondary use needs appropriate permission and a documented assessment.
Clinical Data Processing
Structured extraction and optional AI assistance have separate data scopes and require verified provider coverage.
Separated extraction and AI-assistance paths
Extend supplies structured extraction. Optional Azure functions support upload classification, summaries and source-backed input reconciliation. Exact account, service, retention and BAA scope must be approved; a model result still needs source verification.
Deterministic clinical logic
A versioned contract maps Extend fields. Azure may select source-backed canonical inputs; all score formulas, flags, trends, and missing-data decisions run deterministically in code.
Access & accountability
Tenant-scoped access, audit records and explicit treatment of shared credentials.
Tenant isolation (defense in depth)
Clinical access uses tenant-scoped application and database controls. Public share access derives its scope from the share credential. Deployment roles and negative cross-tenant tests must verify those boundaries.
Role-based access control
Protected clinical endpoints use role-based access. Public dashboard shares are a separate bearer-credential path: accepting a notice does not authenticate the viewer or create disclosure authority.
Append-only audit log
The clinical audit design includes append-only protections and pseudonymous network identifiers. Other authentication and request records may include IP addresses. Coverage, retention, access and human review require operational evidence.
Session timeouts
Authentication configuration includes session expiration, recent-authentication checks and revocation. These are distinct from an idle timeout; effective behavior must be tested for the deployed configuration.
Clinical data and web-host boundaries
Public marketing pages do not request clinical records. Clinical dashboards render sensitive data in the recipient's browser. Even where the browser calls the backend directly, share credentials, URLs and request metadata may pass through a web host or proxy. Those paths require a separate privacy and vendor coverage review; a static application shell alone does not establish that no BAA is needed.
Reviewing OrganAlert for your program?
We can share our full security package and BAA, and answer your security and privacy teams’ questions.