For the engagement owner. The safest useful test data reproduces relationships and workflow states, not real patient histories. Design the expected decisions before sending requests.
Model relationships before endpoints
An API inventory lists routes, but a healthcare permission model also needs patients, practitioners, organisations, delegates and the relationships between them. Describe which actor may perform which operation on which object, and under what context. An integration identity may have different permissions from the clinician using the portal. Include that distinction in the scope rather than treating every bearer of a valid token as equivalent.
Where the implementation uses FHIR or another healthcare exchange format, agree the actual operations and profiles in use. A familiar standard name does not establish the application's authorisation policy or mean that every optional operation is enabled.
Read diagram text
- Relationships
- Patient, practice and clinical role
- Operations
- Read, search, change and export
- Outcomes
- Expected access and downstream state
Build a small, deliberate dataset
Prepare synthetic records with contrasting owners, organisations, relationship states and object lifecycles. A useful set might include two practices, one clinician assigned to each and a third account with an explicitly approved cross-practice role. Add cancelled, draft and final objects only when those states matter to the service. Keep identifiers recognisable as test data and agree how downstream systems will distinguish them from operational records.
Do not copy a production patient history simply because changing the name appears convenient. Generate only the fields needed for the test, and confirm that the synthetic records will not trigger clinical actions, billing or external notifications.
Compare one permission decision at a time
Establish the permitted baseline before testing a prohibited comparison. Change the actor, object owner or requested operation deliberately, while keeping other conditions stable. Record the expected decision and the evidence that would demonstrate it. Include list, search, export and attachment retrieval where they exist; an object read endpoint may be well protected while another interface exposes the same material.
This controlled comparison is also central to fintech API pentest scoping. The business objects differ, but the need to separate identity, ownership and operation is the same. Clinical relationships require their own owner-approved rules.
Read diagram text
- Assigned clinician
- Allow the approved clinical operation
- Unrelated practice
- Reject the prohibited comparison
- Export worker
- Preserve the requesting context
Follow asynchronous work to its destination
Some API calls create a job rather than returning a document immediately. Identify the queue, worker identity, result store and download mechanism relevant to the agreed test. Check that the result remains bound to the correct requesting context and that changing an access relationship is handled according to the product's documented policy. Avoid inferring success or failure from the initial HTTP response alone.
Hospital integrations can also involve acknowledgement and routing behaviour outside the portal. Our EHR and imaging interface guide explains how to include those boundaries without treating every connected device as an authorised target.
Read diagram text
- Fixture
- Synthetic relationship and object state
- Request
- Role, operation and bounded input
- Result
- Response plus downstream observation
Agree bounded execution and useful telemetry
Set request limits, permitted methods and a stop contact. Use small, deterministic comparisons rather than broad enumeration of patient identifiers. Arrange enough application logging to correlate the test account, object and outcome without recording unnecessary clinical payloads. If the system behaves unexpectedly, pause and resolve the uncertainty with the owner before expanding the test.
A useful finding contains the synthetic fixture, identity context, operation, redacted response and any downstream effect. Record negative results too, but qualify them by the cases checked. A handful of correct decisions cannot prove that every combination of roles and records is secure.
Turn the fixtures into a regression asset
After remediation, repeat the original comparison against the agreed release and verify the legitimate path. Ask the engineering team to preserve the relevant synthetic relationships as a regression fixture where practical. Separate the security test evidence from automated regression results, since their coverage and execution conditions may differ. Document which system owner is responsible for maintaining the expected decisions as the care workflow evolves.
The sample healthcare pentest report shows how evidence and limitations can be presented. It is a fictional reporting example; the scope and acceptance criteria for a real engagement must be agreed for the actual service.
Read diagram text
- Record the release
- Identify the tested application version
- Replay the comparison
- Verify denied and legitimate paths
- Maintain the fixture
- Update expected decisions with the workflow
Primary sources
General information, not a compliance opinion. Confirm legal applicability and testing requirements for your entity and jurisdiction.
This guide and the related sector publications linked above are published by Atlant Security. Technical examples are planning examples, not claims about completed client tests.
