Visual regression testing: an automated testing method that compares screenshots of a user interface between two versions to detect unintentional visual changes — defined by the ISTQB as a regression testing technique applied to the display layer of a software system.
Here is a question nobody asks in compliance meetings: when your visual testing tool takes a screenshot of your patient portal, where does that image go?
The screenshot shows a dashboard with the patient's name, date of birth, lab results, current prescriptions, perhaps an appointment history. It is a staging environment, sure. But the data is realistic — because testing with absurd data tests nothing at all. And that screenshot was just sent to a cloud server in the United States to be compared pixel by pixel with a reference image.
Congratulations: you just created a potential compliance incident.
This article is for quality managers, CIOs, and DPOs at healthcare software vendors, hospitals, clinics, and healthtech startups who want to test their interfaces without compromising their patients' data.
Healthcare interfaces are not ordinary interfaces
A healthcare interface has a characteristic that few other domains share: the information it displays can have direct consequences on patients' lives.
A medication dosage displayed with a misplaced decimal. A lab result with a truncated unit. A severity indicator whose color changed after a CSS update — the "critical" red became "moderate attention" orange. An appointment calendar where the date displays in the wrong format and the patient shows up on the wrong day for a preoperative procedure.
These scenarios are not hypothetical. The ANSM (French National Agency for the Safety of Medicines) and the FDA regularly document incidents related to display errors in healthcare software. The FDA's 2023 report on medical device software recalls identifies user interface errors as the third cause of recalls, behind calculation errors and data transmission issues.
The difference from other sectors is simple: in e-commerce, a visual bug costs money. In healthcare, a visual bug can cost a life. This reality fundamentally changes how you must think about testing your interfaces.
Healthcare professionals using your software — doctors, nurses, pharmacists, lab technicians — work under pressure, often fatigued, managing dozens of patients. They do not have time to verify whether the interface displays information correctly. They trust what they see. And that trust must be justified by rigorous testing processes.
HIPAA, HDS, GDPR: the regulatory triptych and its implications for visual testing
The healthcare sector is probably the most regulated domain when it comes to data protection. And these regulations have direct implications for how you can — and cannot — test your interfaces.
HIPAA (Health Insurance Portability and Accountability Act). In the United States, HIPAA protects PHI (Protected Health Information) — any information that identifies a patient and relates to their health condition, care received, or payment for that care. HIPAA's Security Rule requires technical safeguards to protect electronic PHI, including access control, audit trails, data integrity, and transmission security. A screenshot of a patient interface containing PHI is itself PHI. Sending it to a SaaS testing tool means that vendor becomes a Business Associate under HIPAA, requiring a BAA (Business Associate Agreement) — and even with a BAA, liability in case of breach remains shared. HIPAA fines range from $100 to $50,000 per violation, with a cap of $1.5 million per category per year. In 2024, the OCR (Office for Civil Rights) issued over $130 million in cumulative fines.
HDS (Health Data Hosting). In France, HDS certification is mandatory for any host of personal health data. Introduced by the decree of February 26, 2018, and reinforced by the 2024 update, this certification requires hosting within the European Union, with specific technical and organizational guarantees. If your visual testing tool sends screenshots containing health data to a non-HDS-certified cloud, you are in violation. HDS certification is not a formality: it involves an audit by a body accredited by COFRAC, an information security management system compliant with ISO 27001, and specific controls on data location and access.
GDPR and health data. The GDPR classifies health data as sensitive data (Article 9), subject to enhanced protection. Processing is prohibited by default, with limited exceptions — including explicit consent and vital interest. A screenshot of a patient interface containing health data, sent to a SaaS testing tool, constitutes processing of sensitive data. This processing must be justified by a legal basis, documented in your processing register, and subject to a DPIA (Data Protection Impact Assessment) if the transfer is outside the EU. The CNIL has been clear: transferring health data to the United States, even under the Data Privacy Framework, requires enhanced vigilance.
What these three regulations say together is that health data appearing in your screenshots is not just images. It is sensitive data protected by strict legal frameworks. And every time those images leave your infrastructure, you create a regulatory risk point.
Why staging data is a false sense of security
"We don't test with real data." This is the argument you hear in almost every healthcare development team. And it is an argument that does not hold up well under scrutiny.
First, there is the question of what "real data" means. Many healthcare staging environments use anonymized or pseudonymized copies of production data. Perfect anonymization is notoriously difficult in the medical domain — studies have shown that 87% of the US population can be uniquely identified with just three pieces of information: zip code, date of birth, and gender. A pseudonymized patient record that retains date of birth, zip code, and primary diagnosis is not anonymous — it is re-identifiable.
Then there is synthetic data. Yes, you can generate fictitious patients with random names, invented dates of birth, and algorithmically assigned conditions. But for your tests to be relevant, this data must be realistic. An HbA1c of 6.4% for a type 2 diabetic patient on metformin. An INR of 2.3 for a patient on warfarin. These values are medically coherent — and that is exactly what makes them potentially classifiable as health data by a cautious regulator, if associated with a sufficiently detailed patient profile.
Finally, there is ground reality. Developers sometimes copy production data to staging to reproduce a bug. A doctor reports a display issue on a specific patient's record, the development team needs to reproduce the exact context. These "temporary" copies have an unfortunate tendency to become permanent. And when your visual testing tool takes a screenshot of that environment, it potentially captures real patient data.
The only way to structurally neutralize this risk is for screenshots to never leave your perimeter. Regardless of what they contain — real, pseudonymized, synthetic, or mixed data — if they stay on your machine, the risk of unauthorized transfer is eliminated by design.
Visual testing as an accessibility guardian
There is one aspect of visual testing in healthcare that is discussed too little: accessibility.
Healthcare interface users are not just healthcare professionals. They are also patients themselves — via patient portals, monitoring apps, digital health records. And these patients include elderly people with degraded vision, colorblind individuals who cannot distinguish certain colors, people with motor disabilities who navigate by keyboard or with assistive technologies.
In France, the RGAA (General Accessibility Improvement Framework) requires digital public services to be accessible. Public healthcare facilities are directly concerned. The private sector does not escape either: the European Web Accessibility Directive (2016/2102) and the European Accessibility Act (2025) progressively extend these obligations.
Visual testing detects accessibility regressions that manifest visually. A text contrast falling below the 4.5:1 ratio required by WCAG 2.1 Level AA. A clickable area shrinking below 44x44 pixels. A visible focus disappearing after a CSS overhaul. Text that does not enlarge correctly when the user increases font size in their browser.
For elderly patients — who represent a growing share of patient portal users with population aging and digitization of the care pathway — these regressions are not mere inconveniences. A font too small on a lab result means a patient who cannot understand their results. A poorly contrasted button on an appointment booking page means a missed appointment. An overlapping prescription renewal form on mobile means a patient who cannot access their medication.
Visual testing does not replace a full accessibility audit. But it prevents regressions — and in a context where the initial audit has been done and the challenge is maintaining compliance across sprints and updates, visual regression testing is the most effective safety net. For a deeper look at what WCAG visual testing covers, including contrast ratios and focus indicators, our dedicated guide has you covered.
On-premise as the only structural answer
Let us recap the constraints. HIPAA requires PHI protection and BAAs with every vendor. HDS mandates certified hosting on European territory. GDPR classifies health data as sensitive and restricts its transfer. Staging data is not necessarily safer than production data. And accessibility imposes continuous visual requirements.
Faced with these constraints, there are two approaches. The first is to comply with each requirement individually: sign a BAA with your SaaS vendor, verify their HDS certification, document the transfer in your GDPR register, conduct a DPIA, implement anonymization controls on your staging. It is feasible, but it is a complex edifice where every link must hold — and a single weak link is enough to create a breach.
The second approach is to eliminate the problem at the root: if screenshots never leave your infrastructure, most of these requirements become moot. No transfer to document, no BAA to sign, no certification to verify at a third party, no DPIA to conduct for visual testing. This is exactly what on-premise visual testing offers — full control over your data, with no third-party exposure. You maintain total control, and your compliance posture simplifies radically.
This is the on-premise approach. And in the healthcare sector, it is not a conservative or technophobic choice. It is the most rational response to a regulatory environment that does not forgive approximations.
Delta-QA and the specifics of the healthcare sector
Delta-QA is a no-code visual testing tool that runs entirely locally. Here is what that means concretely for healthcare.
Zero data transfer. Screenshots of your patient interfaces stay on your tester's machine. No cloud, no external API, no third-party server. Whether your patient portal displays real, pseudonymized, or synthetic data, it never leaves your perimeter. For a DPO, this is a considerably simplified compliance file.
No developer expertise required. In healthcare, QA teams are often composed of functional profiles — people who know care pathways, business processes, regulatory requirements, but who do not code. Delta-QA works by navigation: you open your application, you browse screens as a user would, and the tool records and compares. It is a skill any functional tester already has.
Deterministic and auditable detection. Delta-QA's structural algorithm analyzes actual CSS rather than comparing pixels. When it detects a change, it produces an explicit report: "the font size changed from 16px to 14px on the .patient-name element," "the contrast of the .confirm button changed from 4.8:1 to 3.2:1." In a context where every testing decision must be justifiable — during an HDS audit, an ANSM inspection, or a HIPAA investigation — this traceability is a significant advantage over AI approaches whose results are a probability, not a certainty.
Accessibility regression detection. Because Delta-QA analyzes CSS structure, it detects changes that affect visual accessibility: contrast modifications, font size reductions, changes in interactive area dimensions. It is not an accessibility audit tool, but it is a tool that prevents accessibility regressions from going unnoticed between audits.
Free to start. The Desktop version of Delta-QA is free, with no capture limits and no trial period. For a hospital or clinic that wants to evaluate visual testing on its EHR (Electronic Health Record) or patient portal, there is no procurement process to initiate. You can test the tool in your real environment conditions before any budget decision.
Limitations to be aware of
Visual testing, even on-premise, is not a universal solution in healthcare.
It does not test business logic. Visual testing verifies that the display is correct, not that the displayed data is correct. If your dosage calculation algorithm returns an erroneous value, visual testing will only detect it if that error changes the interface appearance compared to the reference. An incorrect calculation that produces a visually plausible result will go unnoticed. Functional and unit tests remain indispensable.
Delta-QA does not integrate into a cloud CI/CD pipeline. If your organization has invested in a cloud-hosted continuous integration pipeline and you want every merge request to automatically trigger a visual test, Delta-QA is not designed for that workflow. It is a desktop tool, made for assisted manual testing and structured test campaigns. For healthcare organizations, this approach is often more realistic than full automation, but it is a limitation to evaluate based on your DevOps maturity.
It does not cover all accessibility aspects. Visual testing detects visual accessibility regressions, not structural problems. A screen reader that cannot navigate your form because ARIA roles are misconfigured will not be detected by visual testing. A complete accessibility audit with specialized tools (axe, WAVE, Lighthouse) remains necessary.
Coverage depends on your scenarios. Visual testing only tests the screens you have defined as test scenarios. If a critical patient pathway is not included in your scenarios, visual regressions on that pathway will not be detected. The quality of your visual test coverage depends on the quality of your scenario selection.
FAQ
Are screenshots of a patient portal PHI under HIPAA?
Yes, if they contain any of the 18 identifiers defined by HIPAA: name, date of birth, address, social security number, medical record number, or any other information that identifies the patient. A screenshot of a patient dashboard showing the name and lab results is an electronic PHI, subject to the same protection requirements as the patient record itself.
Must a SaaS visual testing tool be HDS-certified in France?
If the tool receives and stores screenshots containing personal health data, even temporarily, it acts as a host of that data. HDS certification is then required. In practice, very few SaaS visual testing tools are HDS-certified — it is not their core business. This is why the on-premise approach, which eliminates the need for third-party certification, is structurally simpler for compliance.
How does visual testing help healthcare interface accessibility?
Visual testing detects visual accessibility regressions: text contrast falling below WCAG 2.1 ratios (4.5:1 for normal text, 3:1 for large text), clickable area size reduction, visible focus disappearance, font size changes. For elderly or visually impaired patients, these regressions can make an interface unusable. Visual testing does not replace a complete RGAA/WCAG audit, but it prevents degradation between audits.
How long does it take to set up visual testing on an EHR?
With Delta-QA, initial setup takes between one and three days depending on your EHR's complexity. The first day consists of identifying critical pathways (patient record consultation, prescriptions, lab results, appointment booking). The second day involves creating test scenarios and reference captures. The third, if needed, allows fine-tuning sensitivity thresholds and training the QA team. No development skills are required.
Can visual testing detect medication dosage display errors?
Visual testing detects display changes relative to a reference. If a dosage was displayed correctly in the reference version (e.g., "500 mg") and a CSS update modified the display (e.g., truncating to "500" without the unit, or reformatting to "5.00 mg"), visual testing will detect that change. However, if the displayed dosage has been incorrect since the reference version (backend error), visual testing will not detect it — that is the role of functional tests.
What is the difference between anonymization and pseudonymization for healthcare staging data?
Anonymization makes it impossible to identify a person, even with additional information. It is an irreversible process. Pseudonymization replaces direct identifiers (name, social security number) with pseudonyms, but identification remains possible with the correspondence table. GDPR does not apply to truly anonymized data, but does apply to pseudonymized data. In practice, perfect anonymization of medical data is extremely difficult to guarantee, which reinforces the argument for on-premise: if you are not certain your staging data is perfectly anonymized, do not send it outside.
Conclusion
Visual testing in healthcare is not a question of aesthetic perfectionism. It is a question of patient safety, regulatory compliance, and trust.
Healthcare interfaces display the most sensitive data that exists: patients' health data. Every screenshot of these interfaces is a document potentially subject to HIPAA, HDS certification, and GDPR. Every transfer of those screenshots to a third-party cloud is a measurable regulatory risk.
The on-premise approach is not a compromise. It is the only approach that structurally eliminates the risk of unauthorized health data transfer. And with tools like Delta-QA, this approach requires neither a significant budget, nor development skills, nor dedicated infrastructure.
Your patients trust you with their most intimate data. Your test screenshots deserve the same level of protection.