Skip to content

Security and trust

Trust is a query, not a promise

HMS treats access as a governed decision with context, provenance and evidence. The useful question is not whether a checkbox exists, but whether the system can explain what happened.

Explainable access trace

Four questions before one answer.

Access evaluation is designed as a traceable chain. Scope cannot be guessed, a sensitive grant cannot approve itself and the final result must be reconstructable.

  1. 01

    Resolve context

    Tenant, facility, user and resource scope are established before policy evaluation.

  2. 02

    Evaluate policy

    Explicit deny, grant source, expiry and conflict rules contribute to one decision.

  3. 03

    Explain the result

    The decision retains the policy path and source needed to answer why access was allowed or refused.

  4. 04

    Record evidence

    Security and governance history is retained apart from ordinary application logging.

Control plane 01

Authorisation

  • Facility-scoped by default

    A request resolves tenant and facility context before it reaches scoped data. If required scope cannot be established, access is refused rather than defaulted.

  • Granular permissions, not role blobs

    Capabilities can be granted to roles, users or resources. Explicit deny is evaluated before allow.

  • Time-bound access

    A grant can carry an expiry, after which it is excluded from evaluation and removed by maintenance processing.

  • Every grant has provenance

    Grant history retains the actor, reason and optional reference needed to explain why access was created.

  • Four-eyes on sensitive permissions

    Escalation-capable permissions create an approval request for a different administrator. Self-approval is blocked.

  • Separation of duty

    Conflict rules reject incompatible permission combinations when access is granted and defend the same boundary during evaluation.

  • Explainable decisions

    Permission evaluation can identify the rule and grant source that produced a result instead of forcing an investigator to infer it from logs.

Control plane 02

Isolation

  • Service-owned persistence

    Implemented services own their data boundary instead of sharing a writable application schema.

  • Scope enforced below the application

    Tenant and facility filtering is applied in the data-access path rather than left to every screen or query author.

  • Boundaries by contract

    Services exchange defined events and validated calls. One service does not reach into another service’s tables.

Control plane 03

Identity

  • Standards-based authentication

    OAuth 2.0 and OpenID Connect are handled by a dedicated authorization server rather than custom session code.

  • Multi-factor authentication

    Authentication includes MFA and trusted-device handling.

  • Session control

    Active sessions are visible and revocable, including account-lifecycle revocation paths.

  • Login-risk signals

    Signals such as a new device, location or IP can contribute to a recorded sign-in risk decision.

  • Explicit account lifecycle

    Pending, active, suspended, terminated and archived states make authentication eligibility a deliberate decision.

Control plane 04

Audit

  • Dedicated audit ingestion

    Audit events are ingested separately from ordinary application logging and retained outside the emitting service.

  • Entity change history

    Change evidence can retain what changed, from what, to what and by whom.

  • Access-governance history

    Grant, revocation, expiry, approval and rejection history records actor, reason and timestamp.

  • Queryable and exportable

    Evidence retrieval is designed as a direct query and export path rather than a manual log investigation.

Residency and claims

Say exactly what the evidence supports.

  • Statement 01

    India-resident deployment

    The product is configured for India, including regional, locale, currency and deployment assumptions. Facility-specific deployment details are confirmed during technical scoping.

  • Statement 02

    Compliance-supporting, not compliance-certified

    HMS is designed to produce access, change and retention evidence. It does not currently hold HIPAA, NABH, ISO 27001 or SOC 2 certification, and this site does not imply otherwise.

A clearer next step

Inspect the boundary with us

A technical conversation about identity, isolation, policy evaluation, audit evidence and deployment assumptions.