Before adopting AI in a UK clinic, check the tool’s intended purpose, whether medical-device requirements apply, how patient data will be processed, the assurance requirements for your setting and who will oversee its use. Ask for evidence that covers the actual product and workflow you plan to use.
HolistiCare is a clinical decision-support platform for longevity, concierge and functional medicine clinics. It helps clinicians bring patient information together and develop care plans, with the treating team responsible for clinical decisions.
That is why the scope of an AI tool matters to us. This guide sets out the checks clinic owners and operations leads can use to evaluate a proposed workflow, including when considering HolistiCare.
Check which rules apply to your clinic
A product described as suitable for “UK healthcare” still needs a closer look. The MHRA’s medical-device guidance distinguishes Great Britain—England, Scotland and Wales—from Northern Ireland, where a different device-market framework applies.
NHS England assurance processes need a separate scope check. Do not assume they apply in the same way to every private clinic or across every UK nation.
Before asking for documents, establish which questions you need them to answer:
| Area | What to establish |
|---|---|
| Medical devices | Whether the product falls within device rules and which territorial market requirements apply |
| Data protection | Why and how personal data will be processed, and who is responsible |
| NHS assurance in England | Which assessment, procurement and clinical-safety requirements apply to the proposed deployment |
| Care-provider oversight | Which service regulator and professional obligations apply to the organisation using the tool |
In England, the Care Quality Commission assesses the quality of care. It says it does not assess or approve specific technologies. If a supplier refers to CQC, ask what that reference means for the product and your service.
Ask what the tool is intended to do
“AI for healthcare” tells you little about a product’s boundaries. Ask for the intended purpose and the instructions staff will receive.
The MHRA’s intended-purpose guidance for software medical devices explains that intended purpose is determined from information supplied by the manufacturer, including instructions, labelling and promotional materials.
For example, consider a clinic comparing a tool that arranges appointment times with one that interprets symptoms to recommend urgency. Both use AI, but they perform different functions. Ask for a documented assessment of each rather than treating the AI label as a regulatory category.
The supplier should be able to explain which users, patients and settings the intended purpose covers. Ask what action each output is intended to support, which uses are excluded and how staff will know those limits.
The MHRA’s software and AI overview explains that many software and AI products are regulated as medical devices. That does not mean every AI tool used in a clinic is a device.
Where device requirements apply, request the relevant conformity documentation and registration evidence for the intended market. Check that both cover the product and use being offered. If the supplier considers the tool outside device regulation, ask for its rationale. Unresolved classification questions need someone with appropriate expertise to assess them.
Follow the patient data through the system
Before a pilot uses patient information, find out what will leave your clinic’s systems, where it will go and what the supplier may do with it.
The ICO explains that processing special-category data requires both an Article 6 lawful basis and an Article 9 condition, together with associated Data Protection Act conditions where required. The supplier’s privacy policy does not make that assessment for your clinic.
Ask for a data-flow description that follows information from collection through storage, access and deletion. It should cover generated outputs as well as inputs. Establish whether recordings, transcripts or other patient information may be used for model training, and identify subcontractors, processing locations and any international-transfer arrangements that need assessment.
Document the parties’ controller and processor roles for the actual processing activities. Resolve these questions during procurement, while you can still change the proposed arrangement.
Also assess whether a data protection impact assessment, or DPIA, is required. The ICO’s AI accountability guidance links this to the risks of the processing and calls for case-by-case assessment. It also explains the need to consult the ICO before processing where residual high risk cannot be sufficiently reduced.
NHS England’s patient-data guidance explains that confidentiality obligations must also be addressed. Work with your information-governance or legal adviser on the appropriate arrangements and patient information.
The ICO flags that its relevant guidance is under review following the Data (Use and Access) Act. Recheck the current position when making a deployment decision.
Separate NHS assurance from your local safety assessment
For relevant deployments in England, the Digital Technology Assessment Criteria, or DTAC, covers five areas: clinical safety, data protection, technical security, interoperability, and usability and accessibility.
DTAC works alongside other required approvals; it does not replace medical-device requirements. Ask for the completed assessment and supporting evidence relevant to your procurement, including the form version. NHS England revised DTAC in 2026 and states that the previous form should not be used from 6 April 2026 onwards.
Clinical-safety responsibilities also differ between the supplier and the organisation using the system. DCB0129 concerns manufacturers of health IT systems; DCB0160 concerns deployment and use by health organisations. Establish their applicability to your setting with the responsible clinical-safety lead. NHS England is reviewing DCB0129 and DCB0160, so confirm the current requirements before relying on an old procurement pack.
Supplier documents cannot account for every detail of your clinic’s workflow. Your local assessment should consider how staff will spot an incorrect output, who can stop its use and what happens when the tool or its connection fails.
Give staff a workable review process
For an AI documentation tool, a practical starting point is to name who checks an output before it enters the patient record or is used elsewhere. Decide how corrections are made and how repeated errors reach the supplier and your clinic’s safety lead.
Then check whether that person has the time and information to do the review. Naming a reviewer achieves little if the workflow encourages automatic acceptance.
Agree how updates will be handled, too. Ask how the supplier communicates product changes, changes to intended use and newly identified limitations. Decide which changes require a fresh local assessment before wider use. These are practical governance recommendations, not a universal statutory checklist.
For a separate look at the workload involved in checking and correcting outputs, read how to assess whether a clinical AI pilot removed work or moved it. That article addresses pilot evaluation; the checks here address the evidence to examine before adoption.
Use a supplier evidence checklist
The following table is a starting point for an evidence register. For each item, record who will assess it and what remains unresolved.
| Request | What your clinic should check |
|---|---|
| Intended purpose and instructions | The proposed workflow falls within the stated users, settings and boundaries |
| Device-status rationale and applicable documents | The evidence covers the relevant product, intended use and territory |
| Data-flow and contractual information | Processing roles, access, retention, training use and subcontractors are understood |
| Relevant NHS assurance evidence | The assessment and version fit the procurement context |
| Clinical-safety documentation | Supplier risks are considered alongside local deployment risks |
| Support and change procedures | Staff know how to report problems, obtain help and assess updates |
Receiving a document is not the same as resolving a question. Record its scope, who reviewed it and any gaps that still affect your decision.
How HolistiCare approaches regulatory alignment
At HolistiCare, working within a defined product scope and preserving clinical oversight are central to our approach. We are committed to keeping the platform aligned with the regulatory requirements that apply within that scope, and to updating it as those requirements and the product evolve.
That commitment should be part of the supplier conversation. When evaluating HolistiCare, discuss the specific workflow, the information it will process and the documents relevant to your clinic’s deployment. Our clinical data analysis overview explains how the platform brings information together for clinician review.
Bring one defined workflow to the next conversation
Before your next supplier meeting, write down one proposed use and its boundaries. Take the intended-purpose statement, data flow and relevant assurance evidence to the people responsible for procurement, information governance and clinical safety.
The decision should be specific: does the evidence support this tool, for these users, in this setting? What still needs to be resolved before patient use?
Want to see how HolistiCare fits your clinic’s workflow? Book a HolistiCare demo and bring the workflow you want to discuss.
Regulatory guidance checked on 28 October 2026.
