Fictional worked example · Healthcare software & integrations
How we would assess
a patient portal and clinical integration.
Follow a proposed engagement from the initial brief to its scope, planned evidence and follow-up. This scenario uses fictional data and does not describe completed client work.
The fictional brief
Start with the decision
the assessment must support.
A fictional healthcare organisation is preparing a patient portal release connected to a clinical system. It wants evidence about the application and integration before making its release decision.
- Decision to support
- Understand weaknesses in the agreed patient, clinician and administrator workflows and plan remediation before the release decision.
- System in scope
- One staging version of the portal, its API and the organisation-controlled side of the clinical integration.
- Representative roles
- Patient, clinician and administrator accounts, representing the agreed workflows and information boundaries.
- Information used
- Synthetic patient records and an approved integration simulator. Live care systems and real patient records are outside this proposed scope.
Patient and staff portal
Use agreed patient, clinician and administrator workflows with synthetic records.
API and integration
Assess information and actions through the portal’s API and organisation-controlled integration code.
Clinical-system simulator
Use representative responses from an approved simulator. The live clinical system is not a target of this proposed assessment.
Planned coverage
Connect each question
to evidence and a boundary.
The OWASP Web Security Testing Guide is the web-testing baseline, informed by OWASP API security guidance. Specialists build on that baseline around the architecture, technology and business rules in the agreed scope. They validate findings and interpret their impact.
| Area | Question for the assessment | Context and boundaries |
|---|---|---|
| Identity and roles | Do sign-in, sessions and authorisation controls enforce the intended patient, clinician and administrator boundaries? | Focus on access to patient information and permitted actions for the agreed roles. Other roles or workflows would need to be added to the scope. |
| Input and application behaviour | Does the application safely process forms, files and API input through the agreed workflows? | Consider how unexpected input could affect information or application behaviour. Testing stays within the permitted environment and operating constraints. |
| Information exposure | Is sensitive information appropriately protected in responses, exports, errors, logs and relevant caches? | Consider where patient information could be exposed. Available logs and components determine which paths can be assessed. |
| Workflow and integration rules | Do important actions and record changes follow the intended workflow, including integration failures and unexpected responses? | Assess the organisation-controlled code against the agreed simulator behaviour. This does not test the clinical system itself or establish clinical safety. |
| Deployment and connected components | Do the agreed transport, web server, CDN and cache settings support the application’s security? | Include the agreed configuration and components. Production verification or third-party systems may need a separate assessment. |
Before testing
Make the boundaries
and preparation explicit.
Included scope has limits.
- The live clinical system, production portal and wider organisational infrastructure are outside this proposed scope.
- A simulator allows examination of the integration code but cannot reproduce every behaviour of the real service.
- Availability-impacting work is excluded unless specifically agreed. Testing has named operating constraints and an escalation contact.
- This application assessment does not complete a HIPAA risk analysis, NHS assurance process or medical-device submission, or validate clinical safety.
What to prepare.
- A representative staging version, API/interface documentation and the agreed workflow definitions.
- Patient, clinician and administrator test accounts with synthetic records.
- An approved integration simulator and a list of behaviours it can and cannot represent.
- A technical contact, written authorisation, permitted test windows and an agreed escalation route.
Your assessment report
Clear findings.
Practical next steps.
Your report helps you understand the findings and gives your technical team the detail needed to act on them.
| Report section | What it contains | How it helps |
|---|---|---|
| Executive summary | A clear overview of the assessment’s key findings and their implications. | Give decision-makers a concise view of the risks that need attention. |
| Summary of findings | An overview of the individual findings in one place. | Review the issues together and plan the next steps with your team. |
| Finding details | Each finding includes a description, reproduction steps, remediation steps and references. | Help your technical team understand the issue, reproduce it and work through the recommended fix. |
Apply the example to your context
Add the requirements
relevant to your organisation.
Reviewed 25 September 2026. The referenced frameworks inform technical coverage; the actual engagement defines the system, scope and limitations.
Let’s plan
your assessment.
Use this example as a starting point. Tell us how your workflow differs, what you need to learn and any requirements the assessment must address.