Most QA conversations in healthcare software start with test cases and bug reports. This one, with Sun* QA Lead, starts somewhere different.
We started with the gap between what a spec describes and what a regulated clinical system actually needs to be trusted.
In this article, let’s sit down with our QA Lead, Kim Thi, who worked on a cross-border EHR platform built for a neurology clinic network expanding across Europe and Asia. The system handled all of it: patient screening workflows, clinical records, medication management, and jurisdiction-specific healthcare compliance standards.
What she shared wasn’t a methodology walkthrough. It was a practitioner’s account of what happens when the standard QA process meets multi-country regulatory reality and why the spec is never the whole picture.
Q: ICD-10 varies by country. How did you validate the implementation matched each market’s requirements?
ICD-10 isn’t one standard because every country adapts it differently. I sourced each localized variant directly from the national authority, not from the spec or the developer’s interpretation.
Same with ATC medication codes. The client purchased the international standard and every medication mapping had to match it exactly.
In a clinical system, a wrong code isn’t a data issue. It affects the real clinical workflow. That’s where the spec ends, and the real validation starts.
This isn’t something a standard test case template covers. It’s domain research embedded in QA work.
Q: You built on an open-source EHR platform. How did that change your testing scope?
Custom builds scope themselves. Open source, on the other hand, doesn’t, because you inherit the entire function library and you’re responsible for all of it, not just what was added for this project.
We mapped coverage across the full platform first, then layered custom features on top. Regression after every cycle was non-negotiable.
The test timeline was longer than a comparable custom build. That was the right call — not a delay.
Understanding that the interaction surface before writing a single test case is what determines whether your QA coverage actually holds in production.
Q: E-signature standards across Europe differ by country and require national legal approval. How did you approach the validation when a vendor handled the implementation?
In Europe, e-signature requirements for clinical documentation vary by country and must meet specific national legal standards before they’re accepted for clinical use.
We tested the output ourselves.
As a delivery team, our responsibility and compliance validation aren’t the same thing. On this project, we owned both.
We prove what we claim.
What working on this project changed about how I think about QA
Healthcare QA forces a specific kind of discipline that’s harder to develop on standard software projects because the feedback loop is slower and the consequences are higher.
In a clinical system, a missed compliance check doesn’t produce a ticket. It produces a clinician who can’t trust the record they’re reading, a medication that doesn’t map to the standard their institution uses, or a signature that isn’t legally valid in the jurisdiction where it was signed.
That consequence changes how you read a test case. It changes what you look for when you’re sourcing a regulatory standard. It changes what “done” means.
The process at Sun* — plan, test, report, fix, verify — is the same process every QA team follows. What’s different is what we validate against.
Healthcare compliance doesn’t stop at the border. Neither does our validation scope.
Working with a US healthcare team on a clinical platform that crosses jurisdictions?
If your EHR, clinical workflow, or health data platform operates across states or countries, and you need a QA team that knows the difference between a functional test and a compliance validation, this is the conversation worth having early.
Sun* bring QA depth in FHIR, HL7, ICD-10 localization, ATC medication standards, and jurisdiction-specific compliance — across both US and international deployments.
