Knowing the patient is not permission to act.

There are several different identities in the same request.

Separate the person asking, the patient affected, the software acting, and the backend identity that executes the action. A service credential can establish what the software may technically access without establishing what this requester may cause it to do.

Hardy’s confused-deputy example describes a program using its own authority in response to another party’s request. Applied to patient access, it suggests examining whether a connected service preserves the requester’s limits when it reaches a privileged operation. This is our healthcare application of a general security mechanism.

Turn the rule into cases the team can evaluate.

Agree the patient, action, relationship, scope and relevant time. Include who defines the policy and which system enforces it. Do not invent one universal rule for every proxy, family member or pharmacy interaction; the institution must establish the applicable authority.

Pair each prohibited request with an allowed counterpart. A system that blocks everyone is not a successful patient-access control.

Ask when authority is checked.

A workflow can span authentication, conversation, queued work and a later action. If authority changes during that interval, an earlier check may no longer describe the current request. Agree the expected treatment of revocation, expiry and narrower scope at each relevant boundary.

Our revoked-proxy specification describes a proposed timing test. It is explicitly unexecuted. The separate executed cancellation-authority lab demonstrates different, narrower cases in an isolated fixture.

Evidence to request from the implementation owner.

1. A mapping from requester and patient to the requested operation.
2. The current policy and the enforcement point for that operation.
3. Denied-request tests with final record evidence showing no prohibited effect.
4. Tests involving a different protected record, changed authority and delayed execution where applicable.
5. Allowed patient and proxy requests that still complete correctly.
6. The service-permission boundary and the behavior when policy information is unavailable.

OWASP recommends enforcing authorization in downstream systems rather than relying on the model to decide what is permitted. Verify where that enforcement exists in the configured deployment. Read the guidance.

A focused assessment can settle a focused question.

Start with a consequential action such as cancellation or rescheduling. Name the included channels, sites, dependencies and roles. Ask what the current testing establishes, what remains unverified, and which decision requires that evidence.

A successful authorization test is specific to its policy, configuration and coverage. It does not establish compliance, clinical appropriateness, or the safety of every other workflow.