Electronic Prescription Service Assist Me
EPS Assist Me helps suppliers onboarding by answering their questions.
1. Summary
1 - Name
EPS Assist Me
2 - Description
EPS Assist Me is a chatbot that answers questions about the Electronic Prescription Service (EPS). The tool is designed to support suppliers when they are onboarding onto EPS. It looks through a collection of documents and uses AI to give clear, easy‑to‑understand answers.
3 - Website URL
N/A
4 - Contact email
Tier 2 - Owner and Responsibility
1.1 - Organisation or department
NHS England
1.2 - Team
Electronic Prescription Service
1.3 - Senior responsible owner
Chief Pharmacy and Medicines Information Officer
1.4 - Third party involvement
No
1.4.1 - Third party
N/A
1.4.2 - Companies House Number
N/A
1.4.3 - Third party role
N/A
1.4.4 - Procurement procedure type
N/A
1.4.5 - Third party data access terms
N/A
Tier 2 - Description and Rationale
2.1 - Detailed description
EPS Assist Me is an AI‑powered Slack‑based support tool that helps suppliers onboarding to EPS obtain fast, accurate answers during onboarding and technical integration. It uses Retrieval‑Augmented Generation (RAG) to ground responses in authoritative EPS documentation, ensuring accuracy and reducing hallucinations. When a supplier submits a question in Slack, an AWS Lambda function receives the request via API Gateway and triggers a multi‑step RAG workflow using Amazon Bedrock. The system:
- Reformulates the query using a Bedrock‑hosted Meta Llama model to add technical terminology backed with RAG for better retrieval.
- Searches the Bedrock Knowledge Base, which contains embedded EPS documents automatically chunked and indexed in OpenSearch Serverless using Titan Embeddings V2.
- Sends the retrieved context and query to Meta Llama to produce a grounded, safe answer, with Guardrails to prevent hallucinations or unsafe responses.
- Posts the response back into the Slack thread.
The architecture uses: AWS Lambda for Slack event processing Amazon Bedrock (retrieval, embedding, generation, guardrails) Amazon S3 (document storage) OpenSearch Serverless (vector index) API Gateway, IAM, CloudWatch Logs, Secrets Manager The system also includes a feedback workflow stored in DynamoDB, featuring: duplicate‑vote prevention clean‑up of Q&A pairs without feedback latest‑message restrictions Not designed for: clinical decision support, prescribing decisions, patient advice, or any activity affecting patient care. Types of queries the tool is designed to support EPS Assist Me is intended to support supplier onboarding and technical integration queries, for example: - “What are the steps required to onboard to EPS?” - “How do I configure my system to connect to the EPS API?” - “What testing environments are available and how do we access them?” - “How do I set up to receive a subsequent cancellation message?” - “What are the validation rules for claim submissions?” These queries are answered using authoritative EPS documentation to provide consistent, traceable guidance.
What the tool is not designed to cover EPS Assist Me is not intended for: - Clinical decision support or interpretation of patient data - Prescribing decisions or medication advice - Patient‑specific guidance or healthcare queries - Operational support outside EPS onboarding/integration scope (e.g. general IT support not related to EPS) - Any activity that could directly impact patient care External users are EPS suppliers, not members of the general public.
2.2 - Benefits
- Improved onboarding efficiency — suppliers receive immediate, consistent answers grounded in EPS documentation.
- Reduced reliance on human support — frees EPS staff for higher‑complexity cases.
- Higher accuracy — RAG architecture reduces hallucination risk by grounding responses in the latest EPS materials.
- Continuous improvement — feedback mechanisms provide insights into common issues and information gaps.
- Secure by design — uses NHS‑approved cloud patterns (S3, Lambda, Bedrock, IAM) with guardrails to mitigate unsafe content.
2.3 - Previous process
Previously, suppliers relied on Slack channels, documentation repositories, emails, or direct support requests. Answers often required manual intervention from the EPS team, resulting in delays and inconsistent guidance.
2.4 - Alternatives considered
- Static knowledge base / FAQ: Rejected due to difficulty keeping guidance up‑to‑date and lack of interactivity.
- Non‑AI search tools: Rejected because suppliers frequently use informal language or incomplete technical phrases; retrieval quality was low without query enhancement.
- Non‑RAG LLM chatbot: Rejected due to high hallucination risk and inability to guarantee grounding in EPS documentation.
Tier 2 - Deployment Context
3.1 - Integration into broader operational process
EPS Assist Me is used by external suppliers during onboarding and integration. Suppliers ask technical questions within Slack; the chatbot provides instant responses grounded in official EPS documentation.
These answers help suppliers understand API behaviour, message flows, FHIR schema requirements, authentication, non‑repudiation, repeat dispensing logic, and other onboarding steps.
The tool does not make decisions. It provides informational support only. EPS staff remain responsible for technical assurance, approvals, and onboarding decisions.
3.2 - Human review
EPS staff may review:
cases escalated due to ambiguity incorrectly returned responses issues flagged via feedback buttons
All final decisions about supplier readiness remain with EPS onboarding specialists. The chatbot provides auxiliary guidance, not decision‑making.
3.3 - Frequency and scale of usage
Usage frequency depends on onboarding volumes. Suppliers may submit multiple queries per day as they work through EPS testing scenarios. The system is designed for scalable use and supports concurrent interactions.
3.4 - Required training
Users require no training other than knowing how ask the bot a question.
3.5 - Appeals and review
The tool does not make or influence decisions that affect public rights or eligibility. It provides technical support only; appeals processes do not apply.
Tier 2 - Tool Specification
4.1.1 - System architecture
The architecture consists of:
Slack → API Gateway → Lambda event flow Async Lambda for query reformulation + RAG invocation Amazon Bedrock (Titan Embeddings, Knowledge Base, Meta Llama, Guardrails) OpenSearch Serverless vector index S3 document ingestion pipeline triggered by Lambda DynamoDB for session tracking and feedback lifecycle
4.1.2 - System-level input
Slack message text (free text questions) Slack user metadata (name, email, Slack ID) Ingestion of EPS documents uploaded by admins into S3
4.1.3 - System-level output
AI‑generated responses returned into Slack threads Citation‑linked answers where relevant Optional log entries and feedback prompts
4.1.4 - Maintenance
EPS documentation updated through S3 ingestion Knowledge Base auto‑re‑ingests and re‑indexes via Bedrock ingestion jobs Prompts managed as infrastructure in Bedrock Prompt Management with version control and environment switching Guardrails can be updated without code changes Logs and usage monitored via CloudWatch
4.1.5 - Models
Amazon Titan Embeddings V2 (for vector embedding) Meta Llama (query reformulation and answer generation) Bedrock Guardrails (safety filtering)
Tier 2 - Model Specification
4.2.1. - Model name
n/a
4.2.2 - Model version
n/a
4.2.3 - Model task
n/a
4.2.4 - Model input
n/a
4.2.5 - Model output
n/a
4.2.6 - Model architecture
n/a
4.2.7 - Model performance
n/a
4.2.8 - Datasets and their purposes
n/a
2.4.3. Development Data
4.3.1 - Development data description
N/A
4.3.2 - Data modality
4.3.3 - Data quantities
4.3.4 - Sensitive attributes
4.3.5 - Data completeness and representativeness
4.3.6 - Data cleaning
4.3.7 - Data collection
4.3.8 - Data access and storage
4.3.9 - Data sharing agreements
Tier 2 - Operational Data Specification
4.4.1 - Data sources
Operational data includes:
User input text from Slack questions Retrieved chunks from Bedrock Knowledge Base (EPS documents) System‑generated metadata (timestamps, event IDs, message IDs) Feedback data stored in DynamoDB (e.g., positive/negative ratings)
4.4.2 - Sensitive attributes
The tool is designed not to collect patient data. However, Slack messages may occasionally include:
names or identifiers of supplier staff potentially prescription IDs if shared incorrectly
Controls are in place to instruct users not to post PII, and guardrails block exposure of identifiers such as NHS numbers
4.4.3 - Data processing methods
Processing includes:
Query reformulation Vector search Embedding and retrieval RAG answer generation Feedback lifecycle management (cleanup, deduplication, latest‑message restrictions)
4.4.4 - Data access and storage
No long‑term storage of user questions beyond operational logging. Feedback items retained for up to 3 years with strict access controls via a data custodian. Logs stored in CloudWatch with role‑based access. DynamoDB stores only minimal metadata for session tracking
4.4.5 - Data sharing agreements
Slack processes user messages as the platform hosting the workspace
Tier 2 - Risks, Mitigations and Impact Assessments
5.1 - Impact assessments
A Data Protection Impact Assessment (DPIA) addendum was completed specifically for the Slack integration. It identifies:
potential presence of supplier personal data (names, emails, Slack IDs) risk of users entering patient identifiers legal basis under GDPR Art 6(1)(e) mitigations including onboarding messages, guardrails, staff training, and minimisation
5.2 - Risks and mitigations
Risk 1 — Users entering patient data
Mitigation:
Onboarding warnings instruct users not to submit PII
Guardrails prevent exposure of identifiers (e.g., NHS numbers)
Staff trained to manage accidental disclosures
Risk 2 — Incorrect or misleading AI output
Mitigation:
RAG architecture grounds answers in official documentation
Human review available for escalations
Guardrails reduce hallucinations by enforcing grounded, in‑scope responses and preventing speculative outputs
Additional detail on effectiveness of guardrails: Effectiveness is measured using DeepEval’s Faithfulness metric, assessing whether responses are grounded in retrieved EPS documentation. Baseline testing across 20 sample queries shows high faithfulness, with only a small number of failures involving unsupported technical values noted. To fix this issue, retrieval and document chunking have been improved to better surface relevant detail, reducing these cases.
Prompt design has also been refined to discourage generation of values not present in source material.
Risk 3 — Supplier confusion if responses are truncated or unclear
Mitigation:
Prompt management refines queries for better relevance
Retrieval quality improvements (chunking, embeddings, re‑ranking)
Risk 4 — Data retention beyond necessity
Mitigation:
Automatic deletion of un‑feedbacked Q&A pairs
Conditional DynamoDB writes and cleanup
3‑year max retention for feedback
Risk 5 — Slack platform reliance and data handling
Mitigation:
Minimal data ingestion
Clear purpose communication to users