Who is behind this testing, and how is the work organised?
A QA and validation practice for medical software, organised around three risks a regulated product carries: the regulator saying no, patient data leaving where it belongs, and a clinician acting on a wrong screen. Every page here is written from a primary source and dated.
What are we actually removing?
Regulatory
What happens when a reviewer asks for the evidence?
A reviewer picks a requirement and follows it to the test that covers it. Where the trail stops, the submission turns into a deficiency letter, and the launch date moves by however long the response cycle takes.
The trail is built while the work happens. Reconstructing it after the questions arrive costs more and convinces less.
Legal and reputational
What happens when patient data leaves where it belongs?
Notification clocks start before anyone knows the scope. The people who have to be told include patients, regulators and the customers who trusted you with their own obligations.
Test environments that never hold real patient data remove most of the exposure before a test is ever written.
Product
What happens when a clinician acts on a wrong screen?
A dose, an allergy flag or a result lands in the wrong field, and the person reading it has no reason to doubt it. The defect is found by the patient rather than by the release.
Clinical workflows get tested as workflows, with the data conditions that make them fail, rather than as screens.
What do we claim, and what do we leave to you?
We test against the requirements in these standards and prepare the artefacts an auditor asks for. Compliance itself is held by the organisation that ships the product.
We do not need production PHI to test. Environments run on synthetic and de-identified data.
We sign a Business Associate Agreement before any engagement that touches PHI.
How are the regulatory statements here checked?
Every clause number, edition and date on this site was read against the primary source before publication, and each standard page carries the source link with the date it was last read. Nothing is written from memory. Where a fact could not be verified, the page says what is missing instead of filling the gap.
What can we tell you about a project before it starts?
- Do you sign a Business Associate Agreement?
- Yes. The contracting entity is settled during the engagement, not here.
- Where are the engineers who would work on this?
- Wherever your own rules require them to be. Where a buyer sits decides which working locations are acceptable to them, so the location of the team is part of the engagement terms and is agreed before the contract rather than after it. Ask for it in writing at the point you ask for the BAA.
- Where does project data physically live?
- In your systems. Project data stays with you, and the work is done against environments you control rather than against a copy held here.
- Do you ever work with production patient data?
- No. Testing runs on de-identified data, not on production patient records. Where a test genuinely needs a real-world shape, the route to it is agreed in writing before an environment exists, and de-identification is verified rather than assumed.
- What happens to our data when the engagement ends?
- It never left you, so there is nothing here to return or destroy. What ends is access, and the access list is yours to close.
What does this website do?
- Does the site track you?
- No. There is no analytics, no tag manager, no chat widget and no third party script of any kind. The build fails if one is added, which is a check in the repository rather than a promise on a page.
- What does it need JavaScript for?
- Two calculators and the mobile menu. Every page renders and reads with JavaScript switched off, including both calculators, which show their full data set until you narrow it.
- Where do the pages come from?
- The site is a static export. Each page is a file generated at build time, so there is no application server here reading requests and nothing that varies by who is asking.
What does validating your product actually involve?
Answer four questions about your markets, your product type and its integrations. You get the standards that reach you, the artefacts each one asks you to produce, and which of them a test supplier delivers.