Security that's layered, not centralized
No single layer is trusted to do everything. Identity, tenancy, clinical authorization, and data access are independently enforced, so Lumen scales from a solo physician's practice to a multi-facility enterprise health system without widening what any one part of the system can see.
Five sentences that describe the whole model
Identity and authorization are separate systems.
Proving who you are never automatically grants clinical access — that's a second, independent decision.
Organization is the hard tenant boundary; Facility is a scope inside it.
A health system can run many sites on one platform without any site seeing another's data.
Authentication never equals access.
Every request still requires active membership, tenant scope, role, and workflow-state checks — a valid login proves nothing on its own.
The client is never trusted to declare its own authority.
Reads are scoped before they run and writes are authorized before they execute — not checked after the fact.
Automation can observe and recommend. Humans approve anything consequential.
Nothing changes a signed report, a patient's image assignment, or a production system without an explicit human decision.
Five gates, in order — not one decision
A request doesn't go straight from login to data. It narrows through identity, membership, facility, and role/state, in that order, before anything is read or written.
Gait
Authenticates the user and issues a session. Proves who you are — nothing more.
Organization membership
Lumen resolves that identity against its own membership records, independent of Gait. No active membership, no access.
Facility scope
If the organization runs multiple sites, membership is checked against the specific facility too.
Role and workflow state
The member's role must permit the action, and the resource's current state must allow it.
Data
Only after all four checks pass does a read or write actually reach clinical data.
No single layer is trusted to do everything
Identity, authorization, media, and hospital integrations are four separate boundaries. Each one answers a different question, and none of them trust the others to have already checked.
Identity — Gait
Gait is a separate identity and security platform, built specifically to protect Lumen. It authenticates every user, issues and revokes sessions, and owns its own security monitoring. A valid identity proves who you are — nothing more.
Visit Gait →Authorization
Lumen independently resolves that identity into organization membership, facility scope, role, and workflow permissions before any clinical data moves.
Media storage
Imaging and media storage is owned separately. Every retrieval is tenant- and facility-authorized before a download URL is ever issued.
Hospital integrations
Epic, Oracle Health, MEDITECH, PACS, and interface engines are separate trust domains, each isolated behind its own boundary and message contract.
Invariants we treat as non-negotiable
These hold regardless of role, workload, or which part of the system is asking.
One organization, always
Every clinical record — exams, reports, media, audit events — belongs to exactly one organization.
The client doesn't get a vote
A client-provided organization, facility, or role is never sufficient authorization on its own.
Cross-tenant access returns nothing
A request for another organization's data returns no data — not an error that confirms it exists.
Facility is checked independently
Facility restrictions are enforced on their own, separately from role — one doesn't substitute for the other.
Inactive membership authorizes nothing
A suspended or removed member is denied even with an otherwise valid, authenticated session.
Workflow state still applies
A finalized report is locked regardless of role — signing, editing, and addending each have their own rules.
Automation is scoped too
Background jobs and integration workers are tenant-scoped the same as any request — no shortcuts for automation.
Media checked before it's issued
Image and media access is tenant- and facility-authorized before a retrieval URL is ever generated.
Safeguards built into how patient data is handled
Engineered with healthcare data in mind: access, isolation, auditability, and storage are each enforced in code, independent of one another.
Individual accounts, role-based permissions
Every user signs in with their own credentials — never a shared login. What someone can do is scoped to their role and their organization: for example, a technologist can sign a report, but only a physician can finalize it — and that boundary is enforced per facility, not just per account.
Data isolation enforced twice
Each customer organization's data is walled off both in the application and, independently, at the database itself. That second, database-level boundary means a bug in application logic still can't expose one organization's data to another.
Tamper-evident audit trail
Every action on a report — signing, finalizing, an addendum, a change in who has access — is permanently recorded. Once written, an entry can't be edited or deleted.
Finalized reports are locked
Once a report is finalized, it's locked. Any change after that point requires an explicit, logged addendum rather than silently overwriting clinical history.
Encrypted in transit
All traffic is encrypted end to end — between the browser and Lumen, and between Lumen's own services and its database — using TLS/HTTPS throughout.
De-identified file storage
Uploaded ultrasound images are stored under randomly generated identifiers, never their original filenames — so patient-identifying details don't end up sitting in a storage path or a log file.
Straight answers to the questions security teams actually ask
How do you handle authentication?
Gait — a dedicated identity and security platform built specifically to protect Lumen — authenticates users and manages session security. Lumen validates that trusted identity, then performs its own independent tenant and clinical authorization — a login never grants access by itself.
How do you prevent one customer from seeing another customer's data?
Organization is a mandatory, server-side tenant boundary. Reads are scoped to the caller's organization before they run, writes are authorized before they execute, and the browser cannot declare its own organization to gain access.
What about multiple hospitals or sites in one health system?
One organization can contain multiple facilities. Facility scope is enforced independently, underneath the organization boundary — so a health system can run on one platform while keeping each site's staff and workflow configuration separate.
Can AI change production or clinical data on its own?
No. Lumen's AI layer explains and retrieves approved protocols and criteria — it never invents them, and it says so when it doesn't know. It cannot change a signed interpretation, reassign a patient's images, or finalize a report on a clinician's behalf.
Do you use automated security monitoring?
Yes — Gait includes automated investigation agents that watch for anomalies, reproduce suspected issues, and propose fixes. Intelligence doesn't grant itself authority, though: every proposed fix is independently validated and still requires explicit human approval before anything is deployed.
Where does patient data actually live?
Lumen runs in AWS behind a load balancer, with application and database services deployed inside a private network — neither has a public IP. Public traffic terminates at the load balancer over HTTPS; production access to the private network itself goes through a VPN, never directly at the database or internal services.
A note on HIPAA
Lumen's architecture is built with HIPAA safeguards in mind. This site does not claim HIPAA certification, a signed Business Associate Agreement, or a completed third-party audit, and it does not process, store, or transmit protected health information (PHI). Any screenshots or examples shown across this site use synthetic data only.
Review Lumen's security architecture in detail
Request a walkthrough of tenancy, facility scoping, and authorization policy with your security team.