Healthcare Web Application Testing: Encounters and Delegated Access

Test the relationship, not only the login

Healthcare web application testing should verify which person can perform which action on which patient or encounter record, under the current delegation and care relationship. Successful authentication only establishes an identity. It does not establish that the identity may view every record, change every appointment or act on behalf of another person. Those decisions need separate evidence.

This guide develops an encounter and delegated-access test matrix for patient portals, clinician applications and related APIs. It is intended for application owners, security teams and buyers planning an authorised assessment. The examples use fictional identities and synthetic records. They are not clinical guidance, a statement of legal access rights or a description of an actual patient system.

Use the method as a focused workstream within healthcare penetration testing. Agree intended behaviour with the application and privacy owners before testing. Healthcare relationships vary by service, jurisdiction and patient circumstances. The assessor should test the organisation’s approved rules, identify inconsistencies and record uncertainty rather than inventing a universal access policy.

Describe the access relationships in plain language

Begin with the people and organisations represented in the application. Typical examples include a patient, caregiver, clinician, administrative worker, external referring organisation and support operator. For each, describe the relationship that grants access. A role alone may be insufficient: a clinician may need a current care relationship, a caregiver may have a limited delegation, and a support operator may need a specific approved task.

List the objects those relationships apply to. A patient profile, encounter, document, message, appointment and billing record may have different access rules. Do not assume permission to view a profile also permits downloading every attachment or changing every appointment. Ask the owner to identify intentional differences so the matrix can distinguish a valid exception from an unintended gap.

Record where the relationship is authoritative. It may be stored in the application, received from an identity service or synchronised from another system. This matters when testing changes and revocation. A portal that displays a revoked relationship while an API continues using cached authority may create a different outcome from the one the owner expects.

Build a small but expressive synthetic population

Create at least enough synthetic records to represent permitted and forbidden relationships. For example, use two patients, two encounters, an active caregiver delegation and an expired delegation. Add separate organisations or tenants when that boundary exists. The exact population depends on the scope, but a single patient and a single administrator cannot establish whether cross-patient controls work.

Give fixtures stable non-sensitive labels and document their relationships. A worksheet might say that Patient-A owns Encounter-A1, Caregiver-B may view appointments for Patient-A until a specified test expiry, and Clinician-C belongs to the authorised care team. Keep credentials in the approved secret channel, not in the worksheet or report.

Ensure the fixtures cannot trigger real clinical or operational actions. Synthetic appointments should not occupy real slots unexpectedly, test messages should reach controlled recipients, and documents should contain clearly fictional content. Ask the owner how to distinguish and remove the records safely. A test label in a name field does not prevent downstream systems from treating the record as real.

Define action-level expectations

Build rows around actions, not only screens. Read, search, list, export, create, amend, cancel and share can each have different consequences. A user may be allowed to view an appointment but not change it, or read a message but not download a related clinical attachment. The matrix should reflect those differences and identify the interface through which each action is available.

For every forbidden row, include a permitted control. Confirm that the authorised identity can perform the operation on the synthetic object before interpreting another identity’s denial. This helps distinguish an access-control result from a broken fixture, unavailable service or invalid request. Observe the resulting state where the action has side effects.

Write the expected result before execution. “Access denied” may need to mean no content, no metadata, no background export and no notification containing protected information. The intended boundary should be explicit. A generic error on the main page does not settle what a secondary endpoint or asynchronous job may reveal.

Inspect object-level authorisation across the interfaces

The OWASP API Security Top 10 discussion of object-level authorisation explains the importance of checking access to the requested object. In healthcare testing, that principle becomes a concrete relationship question: does the caller have permission for this encounter, document or message, not merely permission to use the endpoint?

Use only known synthetic object identifiers supplied or created for the assessment. The test does not require enumerating real patient records. Compare the permitted owner’s operation with an approved identity that lacks the relevant relationship. Record the identity class, object relationship, route and observed result. The report can then demonstrate the boundary without exposing unrelated data.

Include agreed secondary routes such as previews, downloads and mobile APIs. An application may enforce the relationship in its main page while a document service applies a weaker rule. Select variants based on the architecture and state the coverage. Do not imply that every possible route was tested because one representative endpoint behaved correctly.

Test delegation scope, expiry and withdrawal separately

Delegation is more than an on-off flag. Record the represented patient, permitted actions, excluded information, effective period and authority that created the relationship. Ask how changes are propagated to active sessions and downstream services. The assessment should test these dimensions separately rather than treating a caregiver account as a second patient account.

For scope, compare a permitted action with an excluded action using the same delegate. For expiry, use an agreed short-lived synthetic relationship and observe behaviour after its validity ends. For withdrawal, remove the relationship through the approved process and check the relevant active and newly established sessions. The owner should define the expected timing and any legitimate delay.

Do not assume that signing out of one browser proves access has ceased everywhere. A mobile client, API session or cached download link may have separate behaviour. Name the channels included in the retest and record the ones not examined. If the architecture intentionally permits temporary cached access, the owner must understand and accept that behaviour rather than discovering it through an incident.

Test encounter changes and care-team transitions

Encounter-related access can change when a referral is accepted, a patient moves between teams or an episode closes. Ask which events should alter authority and which should preserve historical access. These are policy and workflow decisions that require owner input. The tester’s role is to check whether the implemented behaviour matches the agreed rule across relevant interfaces.

Use controlled state changes on synthetic encounters. For example, move a fixture from one test team to another and compare access before and after the change. Record the event time, the relationship source and the observed propagation. If access remains because of a separate role or explicit exception, identify that reason instead of treating every continued view as a failure.

Include historical records and reopened encounters where relevant. A system may handle current and archived records differently. Reopening can also revive cached permissions or reuse an old sharing arrangement. The matrix should identify the intended behaviour at those transitions and avoid assuming that a closed encounter is either universally accessible or universally forbidden.

Follow referrals and organisational boundaries

A referral may move information between organisations with different identity systems and access models. Define what is shared, with whom, for what purpose and for how long. Test the actual handoff implemented by the application: a portal invitation, document link, API exchange or another mechanism. A secure originating system does not automatically make the receiving route appropriately restricted.

Use two approved synthetic organisations or tenants where the architecture supports them. Confirm the intended recipient can access the agreed referral material, then test an unrelated identity under the same controlled conditions. Examine whether a link or reference grants broader access than intended, including adjacent documents or metadata. Do not test a supplier’s infrastructure without the necessary permission.

Inspect revocation and completion behaviour. If a referral is withdrawn or sent to the wrong synthetic recipient, how is access removed and how is that decision recorded? A notification that a referral was cancelled may not itself disable an already issued access route. The evidence should establish the technical effect of the approved workflow.

Check search, previews and metadata as separate disclosure paths

An application can suppress a full record while still revealing its existence, title, date or category. Whether that matters depends on the information and policy, but the review should not ignore it. Search suggestions, result counts, preview cards and error messages may expose information through paths that do not look like a conventional document read.

Use synthetic content with recognisable but non-sensitive markers. Search from identities with different relationships and compare what appears. Confirm whether the intended rule permits existence disclosure or only content access. The finding should describe the exact information returned and its context rather than automatically labelling every difference as a major breach.

Inspect client-side caches and downloaded content within the agreed scope. A browser may retain information that was legitimately accessed before revocation. The owner should distinguish server-side access removal from local copies already obtained. Testing can establish the behaviour, but it cannot make a universal promise to erase information from every device or recipient.

Verify exports and background jobs after permissions change

Exports can capture a permission decision at one point and deliver data later. Ask when the application checks authority: at request creation, processing, delivery or each stage. Define the intended rule for a delegation that expires while a synthetic export is queued. There is no useful test without a clear expectation and a safe way to observe the result.

Use a controlled export containing only synthetic records and a destination owned by the assessment team or organisation. Record the request identity, scope, job identifier and final output. Check that the export does not include records outside the permitted population. If a permission change occurs during the test, record its timing and the system’s documented behaviour.

Review download links separately from job creation. A correctly scoped job can still produce a broadly accessible artifact. Ask about expiry, recipient binding and access checks at retrieval. Test only the issued synthetic artifact and agreed identities. If a link remains valid after authority changes, document the exact condition and the owner’s intended policy.

Treat FHIR as an exchange model, not proof of access control

HL7’s FHIR security guidance states that FHIR is not itself a security protocol and discusses the surrounding authentication, authorisation and audit capabilities. For an assessment, identify the actual FHIR version, implementation guide and security architecture in use. Do not assume that a standards-based data exchange automatically applies the organisation’s patient and encounter rules.

Map the application’s relationships to the implementation’s access decisions. Ask where scopes, roles, resource labels and organisational policy are evaluated. The test should examine the resulting permitted resource population, not merely the presence of a token or a familiar protocol name. Different implementations can make different architectural choices, so the evidence must be target specific.

Keep format validation separate from security verification. A resource can conform structurally while being disclosed to the wrong caller. Conversely, a rejected malformed resource does not establish the correctness of ordinary authorised access. Use well-formed synthetic records to test the permission boundary and report interoperability or validation issues separately where they are in scope.

Evaluate emergency access without simulating an emergency casually

Some healthcare applications provide an exceptional access process for urgent situations. Its policy, authority and oversight need explicit owner definition. Do not activate a real emergency process merely to see what happens. Agree a test environment or controlled procedure with the responsible clinical and security stakeholders, and make sure the test cannot confuse operational teams.

The assessment can examine who may invoke the process, what justification is recorded, what access it grants, how long it lasts and who reviews its use. Include a permitted test identity and an identity that should not have the capability. Record the resulting audit evidence and any notifications using clearly labelled test events.

A finding should distinguish access policy from enforcement failure. Broad emergency access may be an intentional design decision, while missing attribution or an unauthorised invocation path may violate the agreed requirements. The report should explain the observed behaviour and the owner-confirmed expectation rather than imposing a clinical workflow decision through a technical recommendation.

Verify attribution and reviewability of sensitive actions

Access-control testing should also ask whether important actions leave usable records. For a delegated action, the application may need to distinguish the actual actor from the patient or person represented. For an export, the record may need the requested scope and resulting artifact reference. Ask the owner which events are expected and how investigators would retrieve them.

Create a small set of labelled test actions and locate the corresponding records through authorised access. Compare timestamps, actor identifiers, object references and outcomes. If an action is denied, determine whether the relevant record distinguishes denial from success. Do not claim that the entire logging system is complete based on a few examples; name the events examined.

Avoid placing sensitive clinical content in logs unnecessarily. Useful attribution does not require copying whole records into every event. The assessment should consider whether the evidence supports investigation while respecting the organisation’s data-handling rules. Missing context and excessive logging can both create problems, so recommendations should be specific.

Worked example: an expired caregiver relationship

Consider a fictional portal where Caregiver-B may view appointments for Patient-A until a defined test expiry. The caregiver may not read clinical attachments. The assessor confirms the permitted appointment view and the forbidden attachment request while the relationship is active, using synthetic records and controlled accounts. These observations establish the baseline before testing expiry.

After the relationship expires, the assessor repeats the appointment request in an existing session and in a new session through the agreed web and API paths. If the web interface denies access but the API returns the appointment, the finding identifies that channel difference. If both deny access, the result is recorded for those paths and the tested propagation interval.

The assessor also checks a previously issued synthetic export link if that route is in scope. Continued access may require a separate finding or policy discussion depending on the agreed rule. The report does not claim that all patient information was exposed or that every client was tested. It explains the relationship, timing, path and actual data returned.

Retest with fresh fixtures and explicit acceptance conditions

When a relationship check is corrected, create fresh synthetic objects and repeat the original permitted and forbidden cases. Record the corrected release and the authoritative relationship state. Include the related route that previously behaved differently. A successful retest should show that the intended boundary is enforced while legitimate access remains functional.

Check a proportionate set of nearby variants. If the fix changes a shared relationship service, representative actions using that service may be appropriate. If it changes one endpoint only, ask whether parallel routes need separate correction. Document the rationale and avoid a blanket claim that every healthcare workflow is now secure.

Report unresolved evidence gaps clearly. A test environment without the production export service cannot establish production export behaviour. A missing caregiver account prevents delegated-access verification. These limitations should appear next to the conclusion so the release owner can decide what additional evidence is needed.

Keep a relationship decision register during the assessment

When an intended rule is unclear, record the question, the affected action and the owner who must resolve it. For example, the team may disagree about whether a caregiver should retain access to an appointment summary created before delegation expired. The assessor should not silently choose the stricter or more permissive interpretation. A short decision register keeps policy questions separate from confirmed technical failures and prevents contradictory findings across different workflows.

After the owner decides, update the expected result and retain the rationale with the test record. If the decision changes the application requirement, identify whether a development change or user communication is needed. This process also improves future regression testing: engineers receive a stable, owner-approved expectation rather than a one-time opinion from the assessment team. Unresolved decisions should remain visible in the final limitations and next-action list.

Scope the assessment around patient and encounter relationships

Prepare a role list, relationship model, important actions, supported interfaces and synthetic-data plan. Identify who can explain intended behaviour and who can authorise testing of integrations. Include known exceptions, delegated access and expiry rules. These inputs make the assessment more useful than a simple list of URLs or a generic request for an OWASP scan.

Our healthcare scoping brief helps organise the initial context. The vendor evaluation guide explains how to compare safety, coverage and report quality. Share sensitive architecture and test credentials only through an agreed secure channel after the scope and access arrangements are clear.

Contact Atlant Security to discuss an encounter and delegated-access assessment. The deliverable should identify the relationships and actions tested, the observed boundaries, the remaining uncertainty and the corrections that engineers can verify. That gives the organisation evidence for a specific decision rather than a vague claim that the portal passed.