How to Build Secure Healthcare Applications with PHP and AWS

The session covered protecting sensitive medical information (PHI), applying security and privacy by design, and strategies for isolating client and back-office systems. Real examples were provided for topics like domain discovery and threat modeling, secure coding practices, encryption, key management, and searching encrypted data. The talk also explored common vulnerabilities, securing file uploads, and achieving non-repudiation.

The project used as context for the talk was a platform that manages the full treatment workflow for dental aligners. It brings together patient records, clinical data, 3D scans, imaging and treatment plans from orthodontists, along with the full case history. Patients, dentists, orthodontists, internal systems and external providers all interact with it, which defines strict expectations for handling PHI and PII. This project illustrates many of the challenges developers face when building healthcare software.

Regulations and the Questions They Introduce

Healthcare systems must follow GDPR, HIPAA, HITECH, PIPEDA and sometimes local rules like HDS in France. These regulations guide and influence how sensitive information, PHI and PII are stored, accessed, processed and audited. The talk outlined fundamental questions that guide the design of such systems:

• What data do we have, including sensitive data, PHI and PII?
• How do we process and store the data?
• What are the risks associated with the data?
• How do we protect it and reduce risk?
• How do we guarantee integrity of processing?
• How do we prove compliance?
• What happens during an incident?

Questions like these drive everything from initial risk assessments and RoPA/DPIA to architecture, development and monitoring.

Mindset: Understanding What Is at Stake

The mindset shifts from “if something goes wrong” to “when something goes wrong”. This is not about expecting failure, but about recognizing the stakes in healthcare systems and designing with that reality in mind. By assuming that incidents are possible and can happen, the system is built with multiple layers of defenses, clear boundaries and predictable recovery paths. When an issue does occur, the impact is contained and limited and the platform can return to a safe state without consequences for patient data or operations.

Security and Privacy by Design

Building with the assumption that incidents can happen leads directly to security and privacy by design. These principles guide the system from the first architectural decisions and are treated as core business requirement. They define how much data the system collects, how that data moves through the platform, which components can access it and where boundaries are enforced. They also ensure that controls such as encryption, auditing, isolation and retention rules are planned early instead of added later.

The process translates these principles into concrete steps in the design phase, supported by OWASP Application Security Verification Standard (ASVS) as the reference framework. Healthcare systems naturally align to Level 3 because of the sensitivity of medical data.

Threat Modeling as Part of System Design

The talk showed how structured threat modeling provides clarity when building systems that handle PHI. Instead of relying on intuition, the process examines how the system can fail across authentication, data flows, storage, internal communication and file handling. The goal is to identify threats early, understand their impact and design security controls that reduce the chances for an incident or limit its impact.

Healthcare workflows increase the range and impact of these risks. They involve long-term patient histories, large imaging files and roles with different levels of access. Threat modeling helps identify where someone could impersonate a user, alter medical information, access data they should not see, overload system resources or cross role boundaries. These findings guide decisions such as isolating backoffice access, separating public and internal services, encrypting medical data and keeping immutable logs that preserve the full treatment history.

During the session, STRIDE was used as an example to categorize risks in areas such as:

• Spoofing, where weak credential handling could allow unauthorized access.
• Tampering, including direct modification of PHI or treatment plans.
• Repudiation, where actions must be recorded so they cannot be denied later.
• Information disclosure, such as leaking PHI through APIs, indexes or metadata.
• Denial of service, especially with large imaging files or abusive uploads.
• Elevation of privilege, where incorrect role boundaries expose sensitive functions.

Working through these produced a focused list of mitigations and helped shape the architectural decisions presented later in the session.

Non-Repudiation and Append-Only Medical Records

Healthcare applications must keep a full history of changes to treatment data. The talk outlined how append-only domain models (event sourcing or log based) support non-repudiation: new entries are added instead of overwriting existing information, and history is preserved as an immutable log. This design supports compliance requirements and helps reconstruct the exact sequence of actions. 

Encryption, Envelope Encryption and Searching Encrypted Data

Sensitive information must remain protected even if storage is compromised. The presentation covered encryption in transit, encryption at rest, separation of keys and data and the use of envelope encryption. A real threat model was presented where an attacker obtained a full SQL dump containing encrypted PHI, yet the data remained unusable and undecryptable.

Searching encrypted fields was discussed for cases where treating doctors need to look up patients by name or other encrypted fields. Blind indexes support exact-match searches without exposing the underlying PHI. The trade-offs between index size, false positives and potential information leakage were explained at a high level.

When more flexible search or sorting is required, the system uses small encrypted read models that hold only the fields needed for these operations. The application decrypts this data in memory, performs the search there and then loads the matching records from the main database. This keeps the encryption model intact while still allowing practical search for clinical workflows.

CQRS: Separating Write and Read Concerns

The slides showed a distinction between the write/command model, where consistency and encryption are strict, and the read/query model, which is optimized for listing, filtering and clinical workflows. Read models can aggregate data from multiple encrypted sources and be recreated when needed, which reduces complexity while preserving security.

Handling Files Securely

Healthcare platforms handle large clinical files such as scans, x-rays and 3D models. These can reach 50 GB and must be stored for years. Risks include execution of uploaded files, resource exhaustion, malware and enumeration.  Mitigations include disabling uploads on application servers, using read-only filesystems, securing S3 buckets with encryption and versioning, using Object Lock for long-term retention, generating non-sequential object keys and avoiding client-provided filenames that contain PII. EXIF metadata is treated as sensitive and encrypted.

Why PHP and AWS Fit This Use Case

PHP supports expressive domain modeling, isolated request handling and a mature security ecosystem suitable for handling medical workflows. AWS provides HIPAA-eligible services, reliable storage for large datasets, strong auditing, KMS, IaC and infrastructure that aligns with healthcare compliance.

The session combined regulations, secure architecture, threat modeling and implementation techniques. It showed how secure healthcare systems benefit from explicit modeling, structured analysis and consistent use of established standards.  

ThinkWeb works with organizations and startups that handle sensitive data and need dependable, compliant software. Book a consultation to discuss your healthcare or regulated-industry project.