Notifications
Clear all
Topic starter
18/08/2026 2:44 pm
TL;DR: Healthcare software security breaks down when EHRs, patient portals, connected devices, APIs, and open-source dependencies are managed in silos, because the attack surface spans code, runtime, and data flows, according to Probely. The practical issue is not just finding vulnerabilities, but tracing how each exposure can leak PHI, trigger HIPAA or GDPR risk, and erode trust.
NHIMG editorial — based on content published by Probely: From Patient Portals to EHRs: Securing the Healthcare Ecosystem
Questions worth separating out
Q: How should healthcare organisations secure PHI sharing through APIs?
A: They should require strong identity assurance, narrow scopes, and continuous monitoring for every API client that can touch PHI.
Q: Why do healthcare applications need integrated security testing?
A: Healthcare applications fail in context, not in isolation.
Q: What do security teams get wrong about shift-left for secrets?
A: They often assume early detection equals governance.
Practitioner guidance
- Map PHI exposure paths across applications and APIs Create a single inventory that ties patient data flows to EHRs, portals, telemedicine services, mobile apps, and backend APIs so teams can prioritise the highest-risk exposure paths first.
- Test authorisation at the API layer Verify that endpoints return only the data a caller is entitled to see, and include negative tests for broken object-level access and overbroad responses.
- Link findings to remediation in the SDLC Route DAST, SAST, and API test results into the development workflow with service ownership, data classification, and release blocking rules for critical PHI exposures.
What's in the full article
Probely's full article covers the operational detail this post intentionally leaves for the source:
- How its scanning approach maps to healthcare web applications and APIs in practice
- The specific ways DAST and API testing are positioned for continuous healthcare release cycles
- The product framing around developer-first remediation support for code, dependencies, containers, and infrastructure
- The article's broader sector positioning for teams building healthcare security programmes
👉 Read Probely's analysis of healthcare application security for patient portals, EHRs, and APIs →
Healthcare app security, APIs, and PHI risk: what teams must change?
Explore further
18/08/2026 3:27 pm
Healthcare application security is a data-governance problem before it is a scanner problem. The article correctly centres PHI, because healthcare risk is determined by how software moves, stores, and exposes sensitive records across many interfaces. Security teams that look only at code defects miss the operational reality that EHRs, portals, devices, and APIs all participate in the same trust chain. Practitioners should treat PHI exposure paths as governance objects, not just findings to remediate.
A question worth separating out:
Q: Who is accountable when PHI is exposed through weak access governance?
A: The covered entity or business associate remains accountable, even when a vendor, contractor, or internal team member caused the exposure. HIPAA does not shift responsibility away from the organisation handling PHI. Accountability must therefore be backed by ownership, evidence, and enforceable offboarding.
👉 Read our full editorial: Healthcare application security depends on API and web context
