Skip to content
HMS
Open menu

Security and access

The right people see the right work—and access ends when it should.

HMS keeps tenant-owned data inside its operating context, checks whether a person may perform the work at hand and refuses the request when required context or access is missing. Sensitive access can require a second reviewer, temporary grants can expire, and changes remain reviewable.

Access boundary map

A protected action crosses every required boundary—or it stops.

Refuse by default

01 / Person

Who is asking?

Identity and session controls establish who is asking and whether access remains active.

Tenant-owned work boundary

02 / Operating context

Resolve the tenant for tenant-owned data and any facility or resource context this work requires.

03 / Permitted work

Confirm that this person has access to perform this action.

04 / Bounded result

Proceed only with the work and context the decision allows.

Boundary holds

If identity, required context or access cannot be established, the work does not cross the boundary.

Separate evidence after the decision

Access governance

Grant, approval, revocation and expiry history.

Change evidence

What changed, from what, to what and by whom.

What hospital teams can do

Five access questions with a clear answer.

Security becomes useful when administrators can understand the boundary, act on it and later review what changed.
  1. Hospital question

    Could one tenant’s records appear in another tenant’s work?

    Keep tenant-owned data separated.

    Team action
    Keep access and operational review inside the intended tenant context.
    Plain-language safeguard
    Tenant-owned rows are filtered by tenant. A facility or resource boundary applies only where the owning area defines it.
  2. Hospital question

    Can access stay limited to the work at hand?

    Give people only the access their work requires.

    Team action
    Grant or revoke access for a named area of work instead of relying on an assumed default.
    Plain-language safeguard
    When the required context or permission cannot be established, the request is refused.
  3. Hospital question

    Can sensitive access require another person?

    Add a second review where escalation is required.

    Team action
    Send access marked for escalation to a different administrator for approval.
    Plain-language safeguard
    Self-approval is blocked for these requests, and incompatible access combinations are rejected.
  4. Hospital question

    Does temporary access really end?

    Let time-bound access expire.

    Team action
    Place an expiry on temporary access and revoke it sooner when circumstances change.
    Plain-language safeguard
    Once an expiry passes, that grant no longer opens the gate.
  5. Hospital question

    Can we investigate who changed access or a record?

    Keep access and change evidence reviewable.

    Team action
    Query or export governance and change evidence when a review requires it.
    Plain-language safeguard
    Governance and change evidence stay separate from the immediate access result; each serves a different review need.

Optional technical proof

Inspect the controls behind the boundary.

The customer story stays simple. Security and technology teams can open the implementation detail they need without mistaking it for broader assurance.
How an access decision is resolved

Authorisation

  • Required scope fails closed

    Tenant context is resolved for tenant-owned data. Facility context is required only where the owning model, query or policy defines it; a missing required scope is refused rather than defaulted.

  • Ordered permission evaluation

    Permission evaluation applies user deny, user allow, role deny and then role allow, followed by inherited-parent checks. A matching user allow can therefore override a role deny.

  • Time-bound access

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

  • Governance history is separate evidence

    Grant history retains the actor, reason and optional reference that explain how access was created; it is not the runtime decision result.

  • 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.

  • Narrowly explainable decisions

    Evaluation identifies the decision source and the matched literal or wildcard rule when a rule matched. Grant and audit history remain separate evidence.

Where data boundaries are enforced

Isolation

  • Service-owned persistence

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

  • Tenant filtering in shared persistence

    Shared EF infrastructure universally filters tenant-owned rows by tenant. Facility scope is enforced only by the owning model, query or policy; there is no universal facility persistence filter.

  • Boundaries by contract

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

Who establishes and ends access

Identity

  • Authorization-server ownership

    Auth owns the OAuth 2.0 and OpenID Connect authorization server and token issuance rather than relying on custom session code.

  • Account and assurance ownership

    Identity owns accounts, memberships, MFA and passkeys, invitations, sessions and sign-in risk.

  • Session control

    Identity-owned 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.

What remains available for review

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.

Review your boundary

Start with the access decisions your hospital cannot afford to blur.

Bring the roles, independently scoped operating contexts, sensitive approvals, temporary access and evidence questions that matter to your team. Deployment region and residency remain written-scope decisions.

A useful review asks

  1. 01Who is asking?
  2. 02Which context?
  3. 03What work?
  4. 04When should access end?