Skip to main content

Accurx's Approach to Building AI Products

B
Written by Ben Davies

How we keep AI safe, secure, transparent and compliant across our products.

At Accurx, we build AI features to help clinicians and patients - for example, helping to triage patient requests so the right care reaches the right person, faster. Because our products are used in healthcare, we hold our AI to a higher bar than most.

This page explains how we make sure the AI we build is as safe, secure, transparent and compliant as possible. In short, every feature is checked by clinicians, tested rigorously before it goes live, monitored while it's running, and built to fail as safely as possible if something goes wrong.


Clinical safety

Patient safety comes first. Every AI feature is owned and signed off by clinicians, tested against relevant standards, and monitored closely once it's live.

Clinical ownership and sign-off. The safety criteria for every AI feature are written by our in-house Clinical Team. We assess potential hazards and harms using recognised clinical risk standards (such as ISO 14971 and the NHS DCB0129 clinical risk management standard for health IT), grading each risk by how serious it could be and how likely it is, and we put controls in place wherever they're needed.

A living hazard log. A cross-functional team - including people from privacy, security, legal, product, engineering, clinical, design and service management - maintains a Hazard Log. This is a systematic record of every clinical risk we've identified, how serious it is, and the steps we've taken to reduce it to an acceptable level. We keep this up to date once a feature is live, adjusting it based on what we actually see happening in real use.

Clinical testing. Clinicians evaluate the AI's outputs against our safety criteria, and we explicitly ask them to flag anything that concerns them - including things we might not have thought of ourselves.

Statistical confidence. We test our AI products on data that is intended to represent the patients who use our products, and we use samples that are large enough that we can state our confidence with a defined margin - for example, 95% confidence that the failure rate stays below an agreed clinical threshold. Where possible, we test on real-world data (such as anonymised patient triage requests), so the results reflect as closely as possible how the feature will genuinely perform once live.

Guardrails. We build safety guardrails into our products, such as prompts for LLMs not to produce certain types of harmful outputs. When appropriate, we also build in live guardrails that double-check the LLM’s output and prevent highly harmful content from reaching a patient or user.

Graceful fallback. Even though our services are highly reliable, we design features to fail as safely as possible. For example, if AI outputs take too long to load or hit an error, they're simply skipped so the patient can still use our platform without disruption.

Post-market surveillance. Our responsibility doesn't end after we launch a new AI feature. We have a rigorous post-market surveillance process in place to monitor how our products perform in the real world once they're live, so we can detect issues early, feed learnings back into our hazard log and safety controls, and keep improving the products over time.


Security

We protect patient data using robust infrastructure and continuous testing by independent security experts.

Trusted infrastructure. Our infrastructure goes through a rigorous procurement process to ensure that it meets our strict security and data privacy requirements. Patient data is never used to train the underlying models.

Controlled access to data. The model runs inside a controlled software layer that ensures it can only ever access the data it's supposed to, and nothing more.

Adversarial testing (red teaming). Our security team deliberately tries to make the system misbehave so that we find and close gaps before any real-world use.

Penetration testing. We bring in independent security specialists to try to break into the system the way a real attacker would, so any weakness is found and fixed before someone with bad intent could exploit it - keeping patient data secure.

Secure software development lifecycle. All of our code has to pass strict static and dynamic security checks to ensure our products stay safe.


AI transparency

We build transparency throughout our products, so patients and users always know when AI is involved and what it's helping with. They should never be left guessing whether something was generated by a healthcare professional, a patient or AI. By making this clear at the point of use, we help people use our AI features safely and confidently.

We are also open about the fact that AI can make mistakes. That’s why our AI features are designed with a human-in-the-loop review built in. A healthcare professional stays in control, reviewing and confirming AI-generated outputs before they inform patient care.


Governance

Beyond our own internal checks, we meet the formal NHS and data-protection standards expected of digital health products.

DCB0129. We comply with DCB0129, the NHS clinical risk management standard for health IT manufacturers. This underpins our clinical safety work - from the hazard log to clinician sign-off described above.

DTAC. We meet the requirements of the Digital Technology Assessment Criteria (DTAC), an NHS assessment covering clinical safety, data protection, technical security, interoperability and usability for digital health technologies.

DPIA. We provide healthcare organisations with a Data Protection Impact Assessment (DPIA) template, which they can review to identify and address privacy risks before going live with a feature.


Medical Device Regulations

Some AI software counts as a medical device under the UK Medical Device Regulations 2002. If an AI product meets the criteria for a medical device, we build and maintain that product in line with those regulations. This includes our approach to product design, development, hazard identification, risk controls, clinical evaluation and post-market surveillance.


If you have any questions, please contact our support team using the message bubble in the bottom right-hand corner of this page. 👉


Did this answer your question?