Published: 7th September 2026
Reviewed by: David Small BSc (Hons), MSc, MTOPRA (Founder and CEO)
What Is NHS DTAC and Why Does It Matter for Digital Health Manufacturers?
For digital health companies looking to enter the NHS, developing an innovative product is only part of the challenge.
Before an NHS organisation can confidently procure and deploy a digital technology, it needs assurance that the product is safe, secure, technically robust, capable of protecting patient information, interoperable with relevant systems, and accessible to the people who will use it.
This is where the NHS Digital Technology Assessment Criteria (DTAC) becomes important.
DTAC provides a baseline assurance framework for digital health technologies used within NHS and social care settings. For digital health manufacturers, software developers and technology companies, understanding DTAC early can make the difference between approaching NHS opportunities with a structured evidence package and discovering major compliance gaps during procurement.
This guide explains what DTAC is, who it applies to, the five areas of assessment, the evidence manufacturers should prepare, how clinical safety standards such as DCB0129 fit into the process, and how to prepare your organisation for NHS procurement.
What is NHS DTAC?
DTAC stands for Digital Technology Assessment Criteria.
It was introduced to provide a consistent baseline against which digital health technologies can be assessed before they are adopted within health and social care.
Rather than focusing on only one aspect of a digital product, DTAC brings together several important areas of assurance.
The five principal areas are:
- Clinical safety
- Data protection
- Technical security
- Interoperability
- Usability and accessibility
For manufacturers, this means DTAC should not be treated simply as a questionnaire that can be completed shortly before an NHS tender.
The questions are supported by underlying evidence.
A strong DTAC position therefore depends on having appropriate governance, policies, technical documentation, risk management activities and supporting records already in place.
This distinction is important.
Answering a question and being able to substantiate that answer are two different things.
A digital health company might believe that its software is secure, for example, but an NHS organisation may need objective evidence demonstrating the controls, testing and governance supporting that conclusion.
The same principle applies throughout DTAC.
Why does DTAC matter for digital health manufacturers?
NHS organisations need confidence in the technologies they procure and deploy.
Digital health products may process sensitive patient information, integrate with clinical systems, influence healthcare workflows or directly support decisions affecting patient care.
Consequently, assurance cannot begin and end with whether the software functions as intended.
NHS buyers may also need to understand questions such as:
- Has clinical risk been appropriately managed?
- Does the organisation comply with applicable data protection requirements?
- Is sensitive information appropriately protected?
- Has the technology undergone suitable security testing?
- Can information be exchanged with other systems safely and accurately?
- Has accessibility been considered?
- Has the product been tested with its intended users?
- Is the product a medical device?
- If so, have the relevant medical device regulatory requirements been addressed?
DTAC provides a framework for examining these areas.
For suppliers, the commercial significance is clear: DTAC readiness can become an important component of NHS market access.
Waiting until an NHS customer requests DTAC evidence can therefore create unnecessary commercial risk.
If significant gaps are discovered at that stage, the organisation may suddenly need to develop policies, complete risk assessments, conduct technical testing or create clinical safety documentation while simultaneously responding to procurement deadlines.
A better approach is to understand the requirements before the commercial opportunity becomes time-critical.
Who needs to consider DTAC?
DTAC is relevant to a broad range of digital technologies intended for use within NHS and social care environments.
Examples can include:
- Software as a Medical Device (SaMD)
- AI-enabled healthcare software
- clinical decision-support systems
- patient-facing mobile applications
- remote patient monitoring platforms
- telehealth technologies
- digital therapeutics
- electronic patient record-related technologies
- workflow and care coordination software
- diagnostic software
- digital triage solutions
- cloud-based healthcare platforms
- technologies that process NHS or patient information
Importantly, DTAC is not synonymous with medical device regulation.
A digital technology does not necessarily need to be a medical device for DTAC to be relevant.
Conversely, where software does qualify as a medical device, medical device regulatory compliance does not automatically satisfy DTAC.
The two frameworks have different purposes, although there can be overlap between the evidence used to demonstrate compliance.
This is one reason digital health manufacturers benefit from considering their regulatory and NHS assurance strategies together rather than treating them as completely separate projects.
Is DTAC the same as UKCA or CE marking?
No.
This is an important distinction for digital health manufacturers.
UK medical device regulation determines whether software falls within the definition of a medical device and, where applicable, establishes requirements relating to areas such as classification, conformity assessment and placing the device on the market.
DTAC is an NHS assurance framework used when assessing digital technologies for use within health and social care.
A product could therefore have relevant medical device regulatory approval and still need to demonstrate that it meets NHS DTAC expectations.
Similarly, some products subject to DTAC may not qualify as medical devices at all.
For manufacturers of Software as a Medical Device, however, there can be valuable overlap.
Existing documentation relating to software development, risk management, cybersecurity, usability, clinical evaluation and quality management may contribute towards the wider evidence base needed for NHS assurance.
The key is understanding what evidence can be reused and where additional DTAC-specific evidence is required.
What are the five areas of DTAC?
The easiest way to understand DTAC is to examine its five principal assurance areas individually.
1. Clinical safety
Clinical safety considers whether appropriate measures are in place to identify, evaluate and control clinical risks associated with a digital health technology.
For many manufacturers, this brings DCB0129 into the discussion.
DCB0129 is the NHS clinical risk management standard applying to manufacturers of health IT systems. It establishes requirements for applying clinical risk management during the manufacture of health IT.
Depending on the product and its intended use, clinical safety activities may involve:
- appointing an appropriately qualified Clinical Safety Officer
- establishing a Clinical Risk Management Plan
- identifying potential clinical hazards
- evaluating associated risks
- implementing and documenting risk controls
- maintaining a Hazard Log
- preparing a Clinical Safety Case
- producing a Clinical Safety Case Report
- maintaining clinical safety activities as the technology changes
A common mistake is assuming that clinical safety applies only to software formally regulated as a medical device.
That is not necessarily the case.
Clinical safety under NHS health IT requirements and medical device regulatory status need to be considered separately.
For manufacturers planning NHS adoption, determining whether DCB0129 applies should therefore happen early.
There is also an important distinction between DCB0129 and DCB0160.
DCB0129 relates to the manufacturer of health IT systems, whereas DCB0160 concerns the deployment and use of health IT systems by health and care organisations.
Although the NHS organisation has responsibilities associated with deployment, manufacturers need to provide appropriate information and safety evidence to support that process.
2. Data protection
Digital health technologies frequently process some of the most sensitive categories of personal information.
Data protection is therefore a fundamental component of DTAC.
Manufacturers need to understand:
- what personal data their technology processes
- why the data is processed
- where it is stored
- who has access to it
- how long information is retained
- whether third parties or subprocessors are involved
- whether international transfers occur
- how data subjects can exercise their rights
- what happens in the event of a data breach
Privacy should be considered during the design of the technology rather than added immediately before procurement.
Depending on the organisation and product, relevant evidence may include privacy notices, data flow information, processing records, retention policies, information governance procedures and supporting information for Data Protection Impact Assessments.
Manufacturers should also be prepared to explain their role in the processing relationship.
Depending on the circumstances, organisations may act as controllers, processors or potentially occupy different roles for different processing activities.
The correct position needs to be determined from the actual processing arrangements rather than assumed.
3. Technical security
A digital health technology may process sensitive health information, connect to healthcare infrastructure and form part of clinical workflows.
Security weaknesses can consequently create risks extending beyond conventional IT disruption.
Technical security under DTAC examines whether appropriate measures are in place to protect the product, its infrastructure and the information it handles.
Evidence may cover areas such as:
- security governance
- access controls
- authentication
- vulnerability management
- penetration testing
- encryption
- secure development practices
- incident management
- backup and recovery
- infrastructure security
- patching and updates
- monitoring
- business continuity
- third-party dependencies
One common difficulty for growing digital health companies is that security controls may exist operationally without being adequately documented.
Developers might follow secure practices, permissions may be carefully managed and vulnerabilities may be addressed quickly, yet there may be limited formal evidence demonstrating how these activities are controlled.
From an assurance perspective, undocumented processes are difficult to demonstrate.
DTAC readiness therefore often involves converting existing good practice into controlled, reviewable evidence.
4. Interoperability
Healthcare technology rarely operates completely independently.
A digital health product may need to exchange information with electronic patient records, NHS services, APIs, laboratory systems, patient administration systems, connected devices or other healthcare platforms.
Interoperability considers whether information can be exchanged accurately, appropriately and securely.
Manufacturers should understand their product’s:
- data inputs
- data outputs
- interfaces
- APIs
- integration architecture
- data standards
- terminology standards
- identity requirements
- dependencies on external systems
Interoperability should also be considered during product architecture.
A platform that works well as a standalone application may encounter significant barriers if NHS deployment requires integration that was never anticipated during development.
For companies targeting the NHS, future integration requirements should therefore be considered well before a specific procurement exercise.
5. Usability and accessibility
A technically capable digital product can still fail if people cannot use it effectively.
This is particularly important in healthcare, where users can include patients with different levels of digital literacy, people with disabilities, clinicians operating under significant time pressure and individuals accessing services through different devices or assistive technologies.
DTAC therefore considers usability and accessibility.
Manufacturers may need evidence relating to:
- user research
- usability testing
- accessibility testing
- inclusive design
- user feedback
- identified accessibility issues
- corrective actions
- compatibility with assistive technologies
- relevant accessibility standards
Accessibility should not be treated as a final design check.
It is more effective when incorporated into product development from the beginning.
Digital health companies should also retain evidence showing what was tested, who participated, what problems were identified and how those findings influenced the final product.
What evidence is needed for DTAC?
There is no single document that makes an organisation “DTAC compliant”.
DTAC readiness is usually demonstrated through a collection of evidence covering the relevant areas of the assessment.
Depending on the technology, this may include:
- clinical risk management documentation
- Clinical Safety Case documentation
- Hazard Logs
- privacy policies
- information governance procedures
- data flow diagrams
- security policies
- penetration testing reports
- vulnerability management procedures
- business continuity documentation
- incident response procedures
- technical architecture
- API and interoperability documentation
- accessibility assessments
- usability testing
- medical device regulatory documentation, where applicable
- organisational policies and governance records
The precise evidence required depends on the technology, how it operates, the information it processes and its intended deployment.
This is why copying another organisation’s DTAC evidence pack is rarely a good strategy.
A clinical decision-support platform integrated into hospital systems presents very different risks and evidence requirements from a relatively simple patient information application.
The evidence needs to reflect the actual product.
What is a DTAC gap analysis?
For organisations approaching DTAC for the first time, a gap analysis or readiness assessment is often the logical starting point.
Rather than immediately creating new policies and documentation, the organisation first determines:
- Which requirements apply?
- What evidence already exists?
- Is that evidence adequate?
- Where are the gaps?
- Which gaps create the greatest procurement or compliance risk?
- What needs to be completed before approaching NHS customers?
This prevents teams from spending time developing documentation they may not need while overlooking higher-priority deficiencies.
For example, a company may already have significant evidence because it operates an ISO 13485 or ISO/IEC 27001 management system.
Another organisation may have excellent technical security practices but little formal clinical safety documentation.
A third might have completed most regulatory activities but have inadequate accessibility evidence.
Each requires a different roadmap.
Patient Guard’s DTAC Readiness Assessment is designed around this approach, reviewing existing evidence, identifying gaps and producing a prioritised implementation roadmap before NHS procurement.
What are common DTAC compliance gaps?
The exact gaps vary between organisations, but several patterns occur frequently in digital health compliance.
Treating DTAC as a questionnaire
The questionnaire is only the visible part of the process.
The real work is establishing the evidence behind the answers.
Starting too late
Beginning DTAC preparation after receiving a procurement request can place considerable pressure on technical, regulatory, clinical and management teams.
Some gaps cannot be solved simply by writing a document.
Testing, risk management, governance implementation and technical remediation can take time.
Weak clinical safety documentation
Companies sometimes have mature medical device risk management processes but have not considered whether DCB0129 applies.
Others may have clinical safety activities but lack a structured Hazard Log or Clinical Safety Case.
Fragmented evidence
Different teams may hold different pieces of the DTAC evidence.
Security information sits with developers, data protection documentation with legal advisers, usability evidence with product teams and regulatory documentation with quality staff.
Nobody owns the complete assurance package.
Policies that do not reflect actual practice
Generic policies are not enough.
The documented process should correspond with what the organisation actually does.
Inadequate accessibility evidence
Accessibility is sometimes considered only near product launch, which can make remediation significantly more difficult.
Assuming medical device compliance covers everything
A strong medical device QMS can provide an excellent foundation, but DTAC includes requirements extending beyond conventional medical device regulatory compliance.
When should manufacturers start preparing for DTAC?
Ideally, before an NHS procurement opportunity is imminent.
Some DTAC requirements are much easier to address when considered during product development.
Clinical risk management can influence system architecture.
Privacy requirements can influence data flows.
Security requirements can affect infrastructure.
Interoperability can influence APIs and system design.
Accessibility can affect the user interface.
Trying to retrofit all of these after the product has been developed can increase both cost and complexity.
An early readiness assessment can therefore be valuable even if an organisation is not yet actively bidding for NHS contracts.
It provides visibility of future requirements and allows compliance work to be incorporated into normal development activities.
How long does DTAC compliance take?
There is no universal timeframe.
A mature organisation with established information security, quality, clinical safety and data protection systems may already hold much of the required evidence.
An early-stage company with limited formal governance may have considerably more work to complete.
The timeline can be affected by:
- product complexity
- clinical risk
- medical device status
- existing documentation
- cybersecurity maturity
- availability of penetration testing
- data processing arrangements
- integrations
- accessibility testing
- availability of a Clinical Safety Officer
- internal resources
This is another reason to conduct a readiness assessment first.
Until the existing evidence has been reviewed, estimating the implementation workload accurately can be difficult.
Who should own DTAC compliance internally?
DTAC is inherently cross-functional.
Responsibility should not simply be handed to a single developer, regulatory professional or information governance consultant.
A typical DTAC project may require contributions from:
- senior management
- regulatory affairs
- quality assurance
- software development
- information security
- data protection
- clinical safety
- product management
- user experience teams
- commercial or NHS procurement teams
One person may coordinate the project, but evidence usually needs to come from several functions.
Establishing ownership early prevents DTAC from becoming a last-minute document collection exercise.
What happens after a DTAC readiness assessment?
A readiness assessment should leave the organisation with a clear understanding of its current position.
Gaps can then be prioritised according to their significance.
Some may require relatively straightforward documentation updates.
Others may involve substantial activities such as:
- developing a clinical risk management system
- appointing or accessing a Clinical Safety Officer
- preparing DCB0129 documentation
- undertaking penetration testing
- implementing new information security controls
- formalising data protection procedures
- conducting accessibility assessments
- completing usability testing
- documenting system architecture and integrations
This is where implementation support can become valuable.
Patient Guard’s DTAC Accelerator service is designed as the next stage after gap analysis, providing hands-on support to develop the policies, documentation and evidence required across the DTAC domains.
The objective is not merely to identify what is missing, but to close those gaps.
How does DTAC fit into NHS procurement?
DTAC is an important part of the wider NHS procurement picture, but organisations should avoid thinking that completing DTAC automatically makes a company ready to win NHS business.
NHS procurement can involve a broader range of requirements.
Depending on the product and procurement route, buyers may consider areas such as:
- DTAC
- clinical safety
- data protection
- cybersecurity
- medical device regulatory status
- quality management
- technical capability
- commercial requirements
- contractual requirements
- evidence supporting the technology
- implementation and support
- organisational capability
Manufacturers therefore benefit from looking beyond the DTAC questionnaire and considering the complete NHS procurement evidence package.
Patient Guard’s NHS Procurement Ready service is intended to bring these different areas together so organisations can approach NHS opportunities with a coordinated regulatory, quality and digital health compliance strategy.
Is DTAC compliance a one-time exercise?
It should not be viewed that way.
Digital products evolve.
New functionality is released. Software architecture changes. Vulnerabilities emerge. Subprocessors change. New integrations are introduced. Clinical workflows develop. Regulations and standards evolve.
The evidence supporting your assurance position therefore needs to remain current.
A significant product change may require clinical hazards to be reconsidered.
A new data processing activity may affect privacy documentation.
Infrastructure changes may affect security evidence.
New functionality may need usability or accessibility testing.
Organisations should consequently incorporate DTAC-related assurance into their ongoing product governance rather than creating an evidence pack and forgetting about it.
For organisations without sufficient internal regulatory and quality resources, ongoing compliance support can help maintain this position as products and requirements change.
A practical DTAC readiness roadmap
For digital health manufacturers beginning their NHS journey, a practical approach is:
Step 1 – Define the product and intended NHS use
Understand exactly what the technology does, who uses it, where it will be deployed and what information it processes.
Step 2 – Determine regulatory status
Establish whether the software may qualify as a medical device and identify applicable regulatory requirements.
Step 3 – Map the DTAC requirements
Review the five DTAC areas against the actual product and organisation.
Step 4 – Inventory existing evidence
Identify policies, procedures, reports, certifications, testing and technical documentation that may already support the assessment.
Step 5 – Conduct a readiness assessment
Assess the quality and completeness of existing evidence and identify gaps.
Step 6 – Prioritise remediation
Separate critical gaps from lower-priority improvements and assign responsibility.
Step 7 – Build missing evidence
Develop the required governance, documentation, testing and technical evidence.
Step 8 – Review the complete evidence package
Check that answers are accurate, evidence is consistent and documents reflect current practice.
Step 9 – Prepare for procurement
Organise the evidence so that relevant information can be provided efficiently during NHS procurement and customer due diligence.
Step 10 – Maintain compliance
Review the evidence when products, systems, suppliers or regulatory requirements change.
DTAC readiness checklist for digital health manufacturers
Before approaching NHS procurement, ask whether your organisation can confidently demonstrate the following:
- We understand which DTAC requirements apply to our technology.
- We have established whether the product is a medical device.
- We understand whether DCB0129 applies.
- Clinical hazards have been appropriately identified and managed.
- Required clinical safety documentation is available.
- Our data processing activities are clearly mapped.
- Data protection documentation reflects actual practice.
- Appropriate cybersecurity controls are implemented and documented.
- Relevant technical security testing has been completed.
- Our system architecture and integrations are documented.
- Interoperability requirements have been considered.
- Usability has been evaluated with appropriate users.
- Accessibility has been assessed.
- Evidence supporting our DTAC answers is current and controlled.
- Responsibilities for maintaining the evidence are defined.
- We understand the wider requirements likely to arise during NHS procurement.
If several of these questions cannot be answered confidently, a structured DTAC readiness assessment may be a sensible next step.
Frequently asked questions about NHS DTAC
DTAC stands for Digital Technology Assessment Criteria. It provides baseline assurance criteria for digital health technologies used within NHS and social care environments.
The five principal areas are clinical safety, data protection, technical security, interoperability, and usability and accessibility.
The practical requirement for DTAC depends on the circumstances in which a technology is being assessed, procured or deployed. NHS England describes DTAC as national baseline criteria for digital health technologies entering NHS and social care, and NHS procurement guidance expects relevant digital platforms to meet the criteria. Manufacturers targeting NHS adoption should therefore expect DTAC to form an important part of assurance and procurement discussions.
No. DTAC can apply to digital health technologies regardless of whether they qualify as medical devices. Medical device regulatory status must be considered separately.
No. Medical device regulatory compliance and DTAC are separate, although evidence developed for medical device compliance may support some aspects of DTAC.
DCB0129 is the clinical risk management standard applying to manufacturers of health IT systems. It establishes requirements for managing clinical risks associated with the manufacture of health IT.
DCB0129 concerns manufacturers of health IT systems. DCB0160 applies to organisations responsible for deploying and using health IT systems within health and care environments.
Where the applicable clinical risk management requirements require clinical safety oversight, an appropriately qualified Clinical Safety Officer plays a central role. Organisations should establish the requirements applicable to their particular technology rather than assuming clinical safety activities are unnecessary.
It depends on the maturity and complexity of the organisation and technology. Companies with established quality, information security and clinical risk management systems may already hold substantial evidence, while others may need to develop several areas from the ground up.
Preparing early is generally preferable. Identifying gaps before a live procurement opportunity gives the organisation more time to address clinical safety, security, data protection, interoperability or accessibility issues without procurement deadlines driving the process.
Preparing your digital health technology for NHS DTAC
For digital health manufacturers, DTAC should be considered part of the product’s wider NHS market-access strategy.
The strongest approach is not to wait for a procurement team to send a questionnaire.
Instead, determine the requirements early, understand the evidence you already have, identify what is missing and build a structured compliance roadmap.
This is particularly important for growing digital health companies where resources are limited and clinical safety, information governance, cybersecurity, medical device regulation and quality management may otherwise be addressed as separate projects.
Bringing these activities together can create a much clearer route towards NHS readiness.
Find out where you stand with a DTAC Readiness Assessment
If you are preparing a digital health technology for NHS procurement, the first question is not necessarily “How do we complete DTAC?”
It is:
“How close are we already?”
Patient Guard’s DTAC Readiness Assessment reviews your existing documentation and evidence against the applicable DTAC requirements, identifies compliance gaps and provides a prioritised roadmap towards NHS procurement readiness.
For organisations that subsequently need help closing those gaps, our DTAC Accelerator provides hands-on implementation support across the relevant DTAC areas.
Patient Guard can also provide dedicated Clinical Safety Compliance support for DCB0129 and DCB0160, wider NHS Procurement Ready support, and ongoing regulatory and quality assistance through Compliance Essentials.
Speak to Patient Guard about your digital health technology and find out what you need to do before your next NHS procurement opportunity.
References
This guide is based on official NHS England guidance, standards and digital service guidance relating to the Digital Technology Assessment Criteria (DTAC), clinical safety, data protection, technical security, interoperability, usability and accessibility for digital health technologies used within NHS and social care settings.
| Organisation | Reference | Why it's relevant |
|---|---|---|
| NHS England | Digital Technology Assessment Criteria (DTAC): Guidance for Buyers and Suppliers | Provides the principal NHS guidance on the Digital Technology Assessment Criteria. DTAC provides a national baseline for assessing digital health technologies and supports NHS and social care organisations when considering the assurance of digital technology products. |
| NHS England | Medical Devices and Digital Tools | Provides NHS England guidance relating to medical devices and digital health tools, including considerations relevant to the implementation and use of digital technologies within NHS healthcare environments. |
| NHS England | Principles for Using Digital Technologies in Mental Health Inpatient Treatment and Care | Defines DTAC as a set of criteria used when introducing new digital health technology and identifies the national minimum standards covering clinical safety, data protection, technical security, interoperability, usability and accessibility. |
| NHS England Digital | Clinical Risk Management Standards | Provides the NHS framework for clinical risk management of health IT systems and explains the roles of DCB0129 and DCB0160. DCB0129 applies to manufacturers of health IT systems, while DCB0160 applies to health organisations deploying and using those systems. |
| NHS England Digital | DCB0129: Clinical Risk Management – its Application in the Manufacture of Health IT Systems | Defines clinical risk management requirements for organisations responsible for developing and maintaining health IT systems. It is particularly relevant to digital health manufacturers preparing clinical safety evidence for DTAC. |
| NHS England Digital | DCB0160: Clinical Risk Management – its Application in the Deployment and Use of Health IT Systems | Defines clinical risk management requirements for health and care organisations responsible for the deployment, use, maintenance or decommissioning of health IT systems. |
| NHS England | National Review of Clinical Risk Management Standards DCB0129 and DCB0160: Supporting Information | Provides current information on NHS England's review of DCB0129 and DCB0160 and explains their respective responsibilities. DCB0129 establishes clinical risk management requirements for manufacturers of health IT systems, while DCB0160 establishes requirements for care organisations deploying and using health IT systems. |
| NHS England Digital Service Manual | What All NHS Services Need to Do About Accessibility | Sets out NHS accessibility requirements for digital services, including WCAG 2.2 Level AA, compatibility with commonly used assistive technologies, inclusion of people with access needs in user research and publication of an accessibility statement. |
| NHS England Digital Service Manual | Accessibility | Provides NHS guidance on designing, developing and testing accessible digital services. The NHS Digital Service Manual reflects WCAG 2.2 and provides guidance covering accessibility across product development, user research, content, design, development and testing. |
DTAC readiness should not be treated as a one-time exercise. Digital health manufacturers should maintain their supporting evidence as their technology, clinical use, data processing activities, security environment, integrations and applicable NHS requirements evolve.
David Small BSc (Hons), MSc, MTOPRA
Reviewed by
David Small, BSc (Hons), MSc, MTOPRA
Founder & CEO |
20+ years in medical device regulatory affairs, MDR/IVDR compliance and quality systems.
Patient Guards Recent Posts

The Complete Guide to NHS DTAC Compliance for Digital Health Manufacturers
A complete guide to NHS DTAC compliance for digital health manufacturers, covering the five DTAC assessment areas, required evidence, clinical safety, data protection, technical security, interoperability and usability, and how to prepare your digital health technology for NHS procurement.

Cosmetic Product Safety Report (CPSR): A Complete Guide to UK Cosmetic Compliance
Before a cosmetic product can legally be placed on the UK market, manufacturers and Responsible Persons must demonstrate that it is safe for human use under normal or reasonably foreseeable conditions. The Cosmetic Product Safety Report (CPSR) is one of the most important regulatory documents required under the UK Cosmetics Regulation. This guide explains what a CPSR is, who can prepare one, what information it must contain, how it relates to the Product Information File (PIF) and how it supports legal cosmetic compliance.

IVDR PMPF Explained: A Complete Guide to Post-Market Performance Follow-up
Post-Market Performance Follow-up (PMPF) is a fundamental requirement under the EU In Vitro Diagnostic Regulation (IVDR), ensuring that manufacturers continually monitor the scientific validity, analytical performance and clinical performance of their in vitro diagnostic medical devices after CE marking. This guide explains IVDR PMPF requirements, PMPF Plans, PMPF Reports, Annex XIII expectations and how ongoing performance monitoring supports continued regulatory compliance throughout the device lifecycle.
Patient Guards Related Services
Need Training?
Do you need training on Quality Management Systems or EU MDR/ EU IVDR? then check out our training courses.
Posted on Google![]()
Jay Verma1 days agoTrustindex verifies that the original source of the review is Google.
I found Patient Guard Ltd to be an exceptional partner. Their assessment was thorough, their guidance clear, and their support instrumental in helping us achieve our objectives. Steve and Ellie, in particular, were outstanding in steering us through the MHRA Class I medical device registration process.Posted on Google![]()
Munna P54 days agoTrustindex verifies that the original source of the review is Google.
Working with the Patient Guard team has been a great experience throughout our MHRA and ISO 13485 documentation journey. Their expertise, structured approach, and practical guidance helped our team build a robust quality management system while keeping us aligned with regulatory expectations. The collaboration was professional, responsive, and focused on finding solutions rather than simply identifying issues. A special thank you to Alex and Steve for their outstanding coordination, responsiveness, and continuous support throughout the project. They were always approachable, provided valuable feedback, and worked closely with our team to resolve challenges efficiently. Their commitment made a significant difference in keeping our documentation effort on track. I highly recommend Patient Guard to any healthcare or MedTech organization looking for experienced regulatory and quality system partners for MHRA, ISO 13485, and broader medical device compliance initiatives. Thank you again to the entire Patient Guard team for being such reliable partners.Posted on Google![]()
Peter Reeve81 days agoTrustindex verifies that the original source of the review is Google.
STEPPER design, manufacture & distribute eyewear across the globe. With the increasingly complex landscape concerning the placing of Mecial Devices onto the market, we realised we needed professional guidance. We found Patient Guard via a simple internet search and are delighted we did! They provide a pragmatic solution to our needs, are totally reliable & always available to answer our (often simplistic) questions. They are highly efficient & responsive to what is a changing picture in our world and nothing is too much trouble. We have a much better understanding of regulatory affairs and our responsibilities as manufacturers & distributors and they support us in navigating the requirements in different territories. Updating our Declaration of Conformity, ensuring our labelling is compliant and acting as our PRRC are the key areas of their service for us.Posted on Google![]()
Derek Timm81 days agoTrustindex verifies that the original source of the review is Google.
For those companıes lookıng to comply to ISO standards and ın partıcular ISO13485 whıch to be honest ıs a nıghtmare I would strongly suggest goıng to the professıonals as ındeed we dıd by joınıng forces wıth Patıent Guard Ltd The staff are fantastıc nothıng ıs too much trouble and as a medıcal supply company we sımply cannot lıve wıthout them Thanks ın partıcular to Alex and Steve for all the hard work and our best regards from Dan Medıca South LımıtedPosted on Google![]()
BMSCriticalCare118 days agoTrustindex verifies that the original source of the review is Google.
Great service, very helpful and always willing to answer any questions we have,Posted on Google![]()
Thomson Software789 days agoTrustindex verifies that the original source of the review is Google.
Alex Lewis of PatientGuard guided us through the ISO13485 process in a thorough, systematic and efficient manner. He was friendly, patient and willing to go the extra mile. Excellent service.Verified by TrustindexTrustindex verified badge is the Universal Symbol of Trust. Only the greatest companies can get the verified badge who has a review score above 4.5, based on customer reviews over the past 12 months. Read more