Sector
AI consultancy for healthcare & nhs
Patient data cannot be posted to an offshore API, and information governance will not approve a system that cannot show where the data went. We build inside the boundary and produce the evidence that gets a project through IG.
The constraint
Why healthcare AI projects stall
The clinical case for AI in healthcare is frequently the strongest of any sector, and the deployment constraint is the tightest. Identifiable patient data is special category data. Information governance functions are, correctly, unwilling to approve processing they cannot fully characterise.
What stops projects is rarely clinical scepticism. It is that the pilot ran on a synthetic or de-identified extract and nobody established what would happen at the point real records were involved, at which time the architecture turns out to be wrong at the foundation rather than adjustable.
There is a second, quieter blocker: whether the thing being built is a medical device. A tool that informs a clinical decision may fall within MHRA scope, and that determination changes the entire compliance picture. It needs answering at the start, not at the point of rollout.
Where it works
What actually earns its place here
Ordered roughly by how quickly they get approved. The first item on this list is usually the right first project, precisely because it is the least contentious.
Administrative and correspondence load
Drafting referral letters, discharge summaries and routine correspondence from structured inputs, for clinician review. Large time saving, and the clinician remains the author.
Coding and documentation support
Suggesting clinical codes from documentation, as a prompt for the coder rather than a replacement. Measurable accuracy and a clear human decision point.
Policy and guideline retrieval
Staff querying local policy, standard operating procedures and national guidance with citations. Non-clinical, non-identifiable, and often the correct first project.
Waiting list and referral triage support
Surfacing and prioritising for human review against defined criteria, never deciding. The framing is not a technicality: it determines whether the tool is a device.
The gate
What your assurance function will ask for
We build so that this evidence is a by-product of delivery rather than a document assembled under pressure afterwards. It is markedly cheaper that way, and considerably more likely to be accurate.
- DPIA completed before processing, covering special category data and lawful basis
- Data flow documentation showing every point identifiable data is processed or stored
- DSPT alignment and DTAC evidence where the system is a digital technology being procured
- A written position on whether the system is a medical device, and the reasoning
- Clinical safety involvement, including hazard log and clinical safety officer sign-off
- Logging and retention agreed against the organisation’s retention schedule
Illustrative scenario: a composite example of how an engagement typically runs, not a specific client.
Illustrative: an NHS trust corporate function
A trust wants to reduce time spent by staff locating the current version of local policies and standard operating procedures, a problem that generates real clinical risk when the wrong version is followed.
The classification work establishes that the corpus contains no patient data at all, which changes the project entirely: this is a document management and retrieval problem, not a clinical AI problem, and it can be delivered inside the trust’s existing infrastructure with a substantially lighter approval path.
The build enforces per-user permissions from the source system, cites every answer to a specific document and version, and treats "this is not covered by current policy" as a first-class response. The DPIA is short because the processing is genuinely low risk, and it is short because the classification work was done first, not because corners were cut.
The trust’s more ambitious clinical use cases are then scoped separately, with the medical device question answered before any build begins.
Questions from this sector
Can we use AI with identifiable patient data at all?
Yes, with the right architecture and the right evidence. That generally means processing inside your own boundary (self-hosted or a private deployment you control), a DPIA completed before processing begins, a clear lawful basis, and information governance involved from design rather than presented with a finished system. What does not work is piloting on de-identified data and hoping the production question resolves itself.
Is our tool a medical device?
It depends on its intended purpose, and it is a question for your regulatory and clinical safety colleagues rather than for us. What we can do is characterise precisely what the system does and does not do (whether it informs a clinical decision, and whether a clinician remains the decision-maker) so that determination can be made properly and early. It is the answer that most changes the shape of a project, so it should never be deferred.
How does this fit with DSPT and DTAC?
We build to produce that evidence as a by-product rather than assembling it afterwards. Data flows, retention, access control and supplier position are documented as part of delivery, in the form your IG team and DTAC assessment need.
Start with a straight answer
A 30-minute call, no pitch deck. Tell us what you are trying to do and we will tell you whether AI is the right tool, what it would take, and what it would cost, or that you should not bother.