Security
A practical, layered security approach
This is a high-level overview of the engineering principles ASAP HMS is built on. It describes how the software is designed and makes no certification or compliance claims.
How the platform is designed
Each principle below is a design decision in the software rather than an aspiration. Where a principle stops short of what a reader might assume, the limit is stated with it.
Tenant and facility isolation
Records belong to a client account and to a facility within it. Queries, worklists and dashboards are scoped to that boundary, so one organisation’s data does not surface inside another’s — and neither does one facility’s inside a sibling facility it should not see.
Role-based access control
Permissions are granted to roles that match real hospital job functions — front desk, doctor, nurse, pharmacist, laboratory technician, cashier, administrator — and are scoped to the facilities a user belongs to. People reach the workflows their role needs and not the rest.
Auditability
Administrative and clinical mutations are recorded to an append-only audit log, so who changed what, and when, can be reconstructed after the fact rather than reasoned about from memory.
Encrypted transport
The platform is built to be served strictly over HTTPS. The hospital application ships browser-hardening response headers — strict transport security, a content security policy, framing denial and strict content-type handling — as part of its own delivery.
This public marketing website is a static export and cannot set its own response headers; those are configured on the web server at deployment time.
Backup and restore preparation
Durable state lives in the database, and the application tier is stateless. Backup posture is an explicit operator attestation with fail-closed defaults: until an operator enables point-in-time recovery and records a passing restore drill, the platform reports the posture as unverified and raises a critical alert rather than staying quiet.
This is preparation and enforcement of an attestation, not evidence of recovery. Whether backups exist and a restore drill has passed is a deployment-time operator fact and is not asserted here.
Secure attachment handling
File attachments are handled through a scanning path with a fail-closed default: if a scanner is unavailable or a file cannot be cleared, the upload is refused rather than accepted on trust.
Least-privilege provider roles
The ASAP HMS provider team operates a console that is separate from any hospital’s own administration, with its own roles. Operating the platform and using it as a hospital are distinct capabilities held by distinct roles.
This website
The public site holds nothing worth stealing
This marketing website is a deliberately boring target. It is published as static pages with no backend, no database, no accounts and no sign-in, so there is no visitor data store to compromise.
- No backend application or database
- No visitor accounts and no sign-in
- No analytics, advertising or tracking scripts
- Enquiries open your own email client — nothing is submitted here
What this page does not claim
We would rather be precise than impressive. The following are not claimed anywhere on this site, and their absence is deliberate.
- No regulatory certification, accreditation or compliance attestation of any kind is claimed.
- No independent third-party security audit or penetration test is claimed.
- No production deployment, availability level or recovery outcome is claimed.
- No external clinical, payment, insurance or messaging gateway is claimed to be running live.
Security is an ongoing programme rather than a finished state. Specifics — architecture, controls, and the deployment posture for a particular rollout — are discussed directly with an organisation as part of an evaluation. For security questions, contact piyush.pandey@asaphms.com.
See ASAP HMS with your workflows in mind
Request a walkthrough and we'll tailor it to how your hospital or clinic runs.