Connecting successfully to Epic in US institutions does not mean ChatGPT for Healthcare could simply be switched on across NHS primary and secondary care, and treating the two as equivalent misunderstands both the technical and the governance distance between a US enterprise deployment and an NHS-appropriate one. This checklist sets out the questions any NHS organisation would need answered before responsibly considering adoption.
The adoption questions
Which NHS EHRs are supported: Epic itself has UK deployments, and the majority of NHS primary care runs on EMIS and SystmOne specifically, neither confirmed as supported by the current integration. Can it integrate with EMIS and SystmOne as well as hospital Epic instances: a genuinely open question with no current answer, and a critical one given how much NHS primary care activity sits outside Epic entirely. Where is data processed and stored: a foundational question for any UK deployment, since the current architecture's data-processing location was built around US institutional requirements. Is UK data residency available: distinct from processing location specifically, and a requirement many NHS information-governance frameworks would treat as non-negotiable. What information is retained, and for how long: a specific, answerable question no NHS organisation should proceed without having confirmed directly.
What agreements govern the connected public sources: the Healthcare Public Data plugin's nine sources are all US-specific, and even setting aside their limited direct UK relevance, the governance agreements underlying them were not built with NHS information-governance requirements in mind. How is role-based access mapped to NHS permissions: NHS access control structures have their own specific logic, distinct from the US institutional permission model the current Epic integration was built around. Can every answer be traced to the source chart entry: the auditability standard this cluster's broader evidence-literacy coverage treats as essential for any clinical AI output, worth confirming explicitly for any UK deployment rather than assumed from the general read-only design. How are source dates shown: a recency-transparency question with direct clinical-safety implications. What clinical-safety documentation is available: the DCB 0129 clinical safety case UK-deployed clinical software is generally expected to maintain, a requirement this cluster's broader coverage notes OpenAI's products have not currently undergone.
Which use cases fall within medical-device regulation: a genuinely important classification question, since different specific uses of the same underlying tool may fall on different sides of the UK's medical-device threshold. What happens after model updates: the revalidation obligation this cluster's broader diagnostic-AI coverage treats as a standing requirement for any deployed AI system, with no confirmed process specific to this integration. How are wrong-patient incidents reported: an incident-management question every deploying organisation needs a clear, pre-agreed answer to before go-live, not worked out after the first incident occurs. What does the organisation monitor after deployment: the post-market surveillance discipline UK medical device regulation generally expects, worth confirming explicitly rather than assumed present. How are local formularies and pathways added: since none of the announced connectors reach local operational context, any NHS deployment would need its own answer to this question entirely separate from what OpenAI has built. And how is patient information and transparency handled: what patients are told about this technology's use in their care, a governance and consent question distinct from the clinical and technical ones above it.
The suggested framing
The right response to this checklist is not that the NHS is too regulated for genuine innovation, a framing that mistakes governance rigour for obstruction. It is that the value of this or any comparable product depends on connecting it to the real systems and evidence that actually govern UK care, not merely on achieving technical access to a medical record, the same distinction this cluster's broader coverage draws throughout between infrastructure capability and demonstrated, jurisdiction-appropriate clinical value.
Frequently asked questions
Has any NHS Trust announced plans to deploy ChatGPT for Healthcare's Epic integration?
No: nothing of this kind has been publicly announced, and the sixteen questions above represent the governance work that would need to happen before any such deployment could responsibly proceed, not a description of work already underway.
Could a smaller-scale pilot address some of these questions faster than a full deployment?
Plausibly, and a genuinely well-designed pilot would still need to address the clinical-safety documentation, data-residency and incident-reporting questions above at a meaningful scale to generate answers an NHS organisation could actually rely on, rather than a token trial that leaves the harder governance questions unresolved.
Does UK Epic deployment specifically change any of these answers?
Some: an NHS organisation already running Epic starts from a stronger technical position on EHR compatibility specifically, while every governance, data-residency and clinical-safety question in this checklist remains open regardless of which specific EHR the organisation runs.