Authorization plus forced database policy
Tenant and location scope are revalidated server-side, with PostgreSQL row-level security providing a second boundary.
Trust architecture
Safety is expressed through boundaries, evidence, and honest failure.
The platform is designed so tenant scope, patient capabilities, provider authority, communication consent, and operational evidence remain separate—and uncertainty is visible.
01RLSforced tenant isolation
02Opaquepublic references
03Fail closedprovider boundaries
Core safeguards
Protection that follows the transaction.
Security is not one settings page. It appears in database isolation, server authorization, URL design, managed content, provider callbacks, audit, support access, and recovery behavior.
Purpose-built projections
Patient, support, management, platform, and public experiences receive different data contracts instead of broad shared payloads.
Secrets are not view state
Shareable UI state uses validated public references; patient capabilities, contact data, clinical detail, and payment information stay out of URLs.
Actors, reasons, attempts and outcomes
Sensitive actions and lifecycle transitions produce scoped evidence suitable for operational review.
Untrusted files are reconstructed
Assets and documents follow bounded upload, inspection, scanning, clean derivation, delivery, archive, hold, and deletion lifecycles.
No fabricated completion
Ambiguous callbacks, writes, messages, payments, or connector results enter reconciliation instead of being silently repeated.
Production truth
A strong local foundation is not a production certificate.
The repository has extensive local migrations, tests, browser matrices, security boundaries, and fail-closed adapters. Live Canadian infrastructure, provider credentials, customer configuration, counsel decisions, monitoring, load/failover, and independent assurance remain deployment evidence—not marketing adjectives.
Available foundation
- Working local application portfolio
- Locally verified migrations and tenant isolation
- Automated tests and browser matrices
- Bilingual staff and patient surfaces
- Fail-closed adapters and exception operations
- Architecture, PRD, operations, and verification documentation
Activation evidence required
- Managed Canadian infrastructure and DNS/TLS
- Live provider credentials and contracts
- Customer, clinical-owner, and counsel approvals
- Hosted monitoring, on-call, and incident response
- Target-environment load, restore, backup, and failover evidence
- Independent security, accessibility, and compliance assurance
Governance workspaces
Privacy and reliability are operational modules.
Named owners receive queues and evidence for consent, DSAR, PIA, transfers, incidents, errors, integration exceptions, message delivery, access, and controlled recovery.
Consent, rights and transfer control
Purpose-separated evidence, correction/access workflows, privacy impact work, transfer gates, and incident history.
Identity, sessions and privileged access
MFA-oriented controls, role scope, step-up boundaries, session revocation, time-boxed view-as, and tamper-evident activity.
Health and exception ownership
Readiness, worker health, outbox/queue state, integration freshness, safe error references, retry rules, and escalation.
Evidence before activation
External acceptance gates remain explicit so a local success cannot silently become a production claim.
Evidence-led product tour
See the system in action.
Captured from the working product with synthetic demonstration data. Use the thumbnails like an ecommerce product gallery; every view explains what to notice and the documentation that governs it.
1 / 4Select a thumbnail to explore
Full topic drill-down
What this part of the product covers.
Each topic connects the public promise to a real screen and the relevant product evidence. Detailed technical records remain available during an appropriate private review.
Tenant isolation
Server authorization and forced database policy revalidate tenant and resource scope.
Product evidence: Product specification §19 · Security recordMinimum necessary
Platform, staff, support, patient and public surfaces receive different data contracts.
Product evidence: Security record · Role-action matrixSafe links
Shareable view state is distinct from patient capabilities, credentials and protected content.
Product evidence: Security record · Screen experience contractImmutable evidence
Sensitive actions preserve actor, reason, attempt, transition and outcome evidence.
Product evidence: Product specification §19 · Verification recordProduction truth
Infrastructure, providers, counsel, customer acceptance and independent assurance remain explicit external gates.
Product evidence: Production acceptance pack · Verification recordA serious operating review
See the product as a system—not a collection of screens.
Bring your organization structure, cancellation economics, integration landscape, branding requirements, and diligence questions. We will map the operating boundary and the evidence available today.