Built secure,not secured afterwards.

Traffic between a browser, a ward tablet or a connected system and the platform runs over TLS, and the credentials the platform holds on your behalf are sealed with authenticated encryption.

• Encrypted connections between your people and the platform
• Passwords hashed with a memory-hard algorithm, never recoverable
• Integration and portal credentials sealed, and tamper-checked on read

In transit

TLS at the edge, over an encrypted tunnel to the application

Passwords

scrypt (N=16384, r=8, p=1), 16-byte random salt, constant-time compare

Stored credentials

AES-256-GCM, with the authentication tag checked on every decrypt

Sessions

Signed tokens (JWT, HS256)

Integrity

SHA-256 across audit records and the custody chain

The credentials that let us talk to your other systems live apart from clinical data, so a problem in one is not a problem in the other.

• Integration credentials stored apart from workflow data
• Held as ciphertext, worthless to anyone without the key
• Replaceable without a code change, and versioned so the scheme can move on

What it covers

ABDM and ABHA configuration, and government portal logins

Cipher

AES-256-GCM: encrypted and authenticated in one step

Stored as

A versioned envelope: fresh nonce, ciphertext, authentication tag

Key

Supplied by the deployment environment, never held in the database

On read

The tag is checked first anything altered is refused, not used

Nobody gets a blanket key. Every route names the permission it needs, and every query is cut down to the caller's branch before it reaches the clinical record.

• A named permission on every route, not a general login
• Queries scoped to your branch and role before the domain sees them
• Approvals and privilege grants cannot be signed off by the person asking

Per route

Each route names the permission it requires

Scoping

Queries cut to the caller's branch and role at the boundary

Separation

Approvals, verifications and grants cannot be self-authorised

Federation

OIDC single sign-on with your identity provider, where you want it

Record

Append-only audit trail, hash-chained on sensitive cases

Application, data and messaging run on separate hosts. Only the web tier answers the outside world, so the database and the event bus are never sitting on the public network.

• Three isolated tiers, each container reachable only from the one above it
• Deployment model chosen with you, including fully on your own infrastructure
• Tracing and metrics per service, so a fault points at the module that caused it

Web tier

Reverse proxy and the application, TLS only, the single public surface

App tier

Core API, event bus and cache, reachable only from the web tier

Data tier

PostgreSQL, reachable only from the application tier

Services

Core API, AI copilot, device server and event worker, each isolated

Watching it

Tracing, metrics and dashboards attributable to a single module