MHSDS Expert Agent
Before MHSDS-derived figures enter a report or mandatory return, checks whether local metric logic matches published national definitions.
Agent operating model
Practical examples of how agentic AI could be used safely in a Business & Performance team — with bounded agents, approved sources, citations and human sign-off at every stage.
Demonstration caveat: Agent rules are illustrative templates in
agent-rules/. They are not deployed in production and do not connect to live Trust systems.
What "an agent" means here
An agent is an AI assistant given a narrow, written brief and a fixed set of approved sources — for example one return's published specification and the local data dictionary. It answers questions and drafts text strictly within that brief, always citing where its answer came from, and stops and escalates when something falls outside its sources. Think of it as a well-briefed, source-bound assistant for one task — not a general chatbot, and never the decision-maker.
Core principles
- AI supports human judgement — it does not replace subject matter experts
- Subject matter expert (SME) agents answer from approved sources only — with citations the user can verify
- AI does not make operational decisions or submit returns autonomously
- Definitions must link to authoritative sources — public specifications, the local data dictionary, standard operating procedures (SOPs)
- Information governance is a hard boundary — the Information Governance (IG)/Safety Agent can block the workflow
- Explicit human approval before external or system changes — code changes, pull request (PR) creation, project-tool updates, external communications
Pairing agents with approved sources
Reporting SME agents (MHSDS, CSDS, PLCM, ADC) answer from version-dated public specifications, the local data dictionary, source restrictions in the agent rule file, and named human sign-off points — not from memory or live systems.
- Public specification documents and local dictionary (e.g.
docs/synthetic-mhsds-local-dictionary.mdfor the MHSDS worked example) - Source pack registers where relevant (e.g.
public-data/mhsds-source-pack-register.csv) - Local SOPs (IG-approved; not published on this site)
Example questions SME agents should support
SME agents should answer questions such as “What is ADC E07 based on?”, “When is the next PLCM dataset due?”, “Which fields are required?”, “What source table is this metric using?” and “What caveats should go with this report?” — each answer citing the source section. If the answer is not in approved documents, the agent must say so and escalate.
Two practical conversation examples
These excerpts show what governed agent behaviour looks like in practice: source-bound reasoning, tracing figures back to source, flagging validation issues, proposing caveated wording, and refusing to approve publication where human sign-off is needed. Full transcripts are linked below each example.
Example 1: MHSDS Expert Agent — investigating an unusual movement
In plain English: when a number on a report suddenly jumps, the first job is to find out why — is it a genuine change in activity, or just a change in how things were recorded or counted? "Tracing a figure back to source" means following that number step by step, from the original record a clinician entered through to the final total on the report, checking each stage. The technical chain below is kept deliberately, because that traceability is the whole point — but the takeaway is simple: the agent helps you ask better questions, and a person still decides.
This example shows how a source-bound SME agent could support a Business & Performance user investigating an unusual movement in a synthetic MHSDS-derived metric. The agent traces the figure back to source forms, extract logic, fact tables and mapping rules, separates data-quality from operational explanations, and offers draft pack wording — sign-off is discussed only when the user asks whether the figure is ready for the pack.
Synthetic demonstration only. Fictional records from RiO (an electronic patient record system), warehouse tables and aggregate data. Not an official Dorset HealthCare report, not a live Trust agent, no patient-identifiable data, and not connected to operational systems.
What this demonstrates
- Data lineage from RiO contact form through staging, fact table, team mapping and aggregate
- Movement calculation (+370 contacts, ~29.8%) traced to synthetic demo data
- Data-quality vs operational hypotheses and numbered investigation checks
- Refusal to over-interpret performance; draft pack wording pending human review
Conversation excerpt
User:
I'm drafting the March directorate pack. Synthetic All Age MH access contacts have jumped from 1,240 to 1,610. Why has this gone up?
MHSDS Expert Agent:
The first thing I would check is whether this is a real activity increase or a recording / extraction change.
Synthetic lineage: RiO contact (DemoMHContactForm) → StgMHSDSContactExtractDemo → FactMHSDSContactDemo → DimMHSDSServiceTeamDemo (All Age MH teams) → count where ContactStatusCode = attended and ContactMonth = March.
Movement: 1,240 → 1,610 (+370, ~29.8%). March includes 180 late-recorded contacts — do not assume pure demand increase.
I would run checks on RiO form usage, team mapping, dedup logic, status coding and late recording before using this in a pack.
Draft pack wording (pending review): "All Age MH access contacts rose from 1,240 to 1,610 (+29.8%) in March. This may reflect increased activity and/or recording effects including late-recorded contacts. Definition and data quality checks are in progress."
User:
Where does this figure actually come from — is it straight from an MHSDS return?
MHSDS Expert Agent:
No — this is not a figure pulled directly from an MHSDS submission. It is a local warehouse metric built from RiO contact records through the synthetic demo ETL chain. National MHSDS provides background context only; this demo metric is inspired by contact-count concepts but is not mapped to a specific published measure code.
User:
Does this increase mean performance has deteriorated?
MHSDS Expert Agent:
Not necessarily — and I cannot give a performance verdict. Contacts rose ~29.8% while referrals rose only ~7.1%, which points toward recording/extraction effects or a step-change in conversion — but I cannot determine which without the checks above. I can help frame investigation questions; I cannot conclude whether performance has improved or deteriorated.
User:
Can I use this figure in the March directorate report?
MHSDS Expert Agent:
Not yet as a final figure — draft wording with caveats only until checks are complete. Confirm team mapping, dedup logic and late-recorded contacts with Information Lead; confirm operational context with Performance Manager. I cannot sign off, submit an MHSDS return, or treat this demo as operationally validated. Status: Draft — pending Information Lead and Performance Manager review.
Why this matters: The value is lineage traceability and definition control — following a reported number back through RiO forms, extract tables, fact tables and mapping rules, and separating data-quality drivers from operational ones before drawing performance conclusions. The agent helps ask better questions and draft proportionate caveats; it does not replace human validation or sign-off.
Supporting files:
- MHSDS Expert Agent rule
- Synthetic local dictionary
- Read full worked example → (evidence chain)
- MHSDS source pack register
- Synthetic aggregate demo data
- Related public MHSDS brief (real RDY aggregates — separate strand)
Example 2: Report Analysis Agent — checking a flawed draft
In plain English: before a draft report is shared, someone needs to check that it answers the basic performance questions — what the figure is, what it should be (where a standard exists), how it is trending, what judgement is fair, and what a human must still verify. The Report Analysis Agent does that review using approved public sources only. It cites evidence, suggests draft fixes, and never signs the report off.
This example uses a synthetic pre-fix draft (deliberate errors) based on issues found during the June 2026 public-data report improvement pass. The agent catches total errors, misleading period wording, missing standards and mixed-up trend columns — the same classes of problem that automated validation and human review now guard against in the corrected briefs.
Synthetic demonstration only. Flawed draft v0.3 in
examples/ — not the corrected published brief, not a live Trust agent, no patient-identifiable data, and not connected to operational systems.
What this demonstrates
- Eleven-step review framework: period, total, standard, trend-column, caveat and bottom-line checks
- CSV traceability and numbered findings with evidence cites
- Revised wording marked
DRAFT — REQUIRES HUMAN REVIEW - Refusal when asked to approve publication
- Mechanical checks in
04_validate_public_reports.Rapply to rendered HTML briefs — the draft issues below would fail those checks
Conversation excerpt
User:
I've drafted a Talking Therapies access brief for our directorate huddle. Please review this draft against approved public sources and tell me what needs fixing before I share it.
Report Analysis Agent:
I reviewed the draft against demo_talking_therapies.csv. I have not approved this draft for publication.
Critical #1: KFE row labels M019–M022 total as 5,870 but four-band sum is 6,780 (M019=4,705; M020=705; M021=460; M022=910). Would fail check_tt_wait_totals on a rendered brief.
Major #2: "Six-month trend" uses six non-consecutive data points (Aug, Oct, Nov, Jan, Feb, Apr — gaps for Sep, Dec, Mar).
Major #3: M053 says no verified national threshold — 75% six-week and 95% eighteen-week standards exist in NHS Talking Therapies publication.
Major #4: Trend column mixes "Falling" with "Finance sign-off required" — validation text belongs in a separate column.
Corrected band totals: M019–M021 = 5,870; M019–M022 = 6,780.
Report Analysis Agent (revised wording excerpt):
M053 — Six-week access (finished course): 88% (Apr 2026).
Standard: ≥75% six-week access (NHS Talking Therapies monthly statistics).
Trend: Falling.
Validation: Pathway / data-definition check required.
Judgement: RDY remains above the 75% standard but has fallen from 95% at the start of the selected trend window.
DRAFT — REQUIRES HUMAN REVIEW
User:
Can I publish this to the directorate huddle now?
Report Analysis Agent:
No. I cannot approve publication.
Blocking items: Critical #1 total error must be corrected; Major #2–#7 period wording, standards, trend columns and validation owners need fixing; human validation register remains open.
Required sign-off: report author, Performance Manager or Business Partner, Talking Therapies pathway lead (M053/M055 definition). Status: Draft — pending named human sign-off.
Why this matters: This agent operationalises report QA — catching arithmetic, definition, standard and trend errors before a draft is shared. It applies the AI assurance checklist in practice; the same issue classes drove the June 2026 public-data improvement pass. See the corrected Talking Therapies brief for the post-fix outcome.
Supporting files:
- Report Analysis and Improvement Agent rule
- Flawed draft input (v0.3)
- Read full worked example → (evidence chain)
- Corrected brief (after improvement pass)
- Demo CSV source
- Trend CSV source
- Final report QA summary (June 2026 improvement pass)
- Public reports method
- Post-render validation script (rendered HTML only)
Workflow (conceptual)
Reporting workflow
Approved or synthetic data
Performance Manager
SME agent (on demand)
Demand & Capacity
Report QA
Executive Summary
IG / Safety
Human sign-off
For performance reporting and mandatory returns: interpret data, check definitions, quality-assure (QA) drafts and prepare narratives — each step produces drafts or findings for human review, not autonomous outputs.
Admin and delivery workflow
Delivery task or open branch
Project / Admin or Backlog Sync
Branch Review & Delivery
IG / Safety
Human sign-off
For delivery work: coordinate project actions, reconcile backlogs and close down branches before merge or handover — still subject to IG/Safety rules. Neither workflow implies autonomous changes to the code repository (Git), the project-tracking tools (such as Azure DevOps) or any external system. See agent-rules/README.md.
A. Reporting specification SME agents
CSDS Expert Agent
Before community service metrics are published, flags CSDS coding, cohort and data-quality risks with authoritative citations.
PLCM Expert Agent
When preparing PLCM returns, answers schedule, field and validation questions from approved specifications only.
When is the next PLCM dataset due? Cite calendar source. Flag if not in approved pack.
ADC Expert Agent
When interpreting ADC elements (e.g. E07), explains mappings, definitions and caveats from authoritative sources.
What is ADC E07 based on? Cite spec section and local dictionary if documented.
B. Performance and reporting workflow agents
Performance Manager Agent
During operational or directorate reviews, interprets performance trends and variation in plain English — separating facts from hypotheses.
Demand & Capacity Agent
When testing backlog clearance or capacity plans, shows transparent arithmetic and stated assumptions — not commitments.
Report Analysis and Improvement Agent
Before a performance report leaves draft, runs structured pre-publication review: totals, periods, standards, trend columns, caveats, readability and revised wording — workflow step labelled Report QA.
Executive Summary Agent
After QA, drafts Board or service-facing narratives with visible caveats — for human selection and approval, not autonomous publication.
C. Admin and delivery agents
Project / Admin Agent
For day-to-day delivery coordination: tracks meeting actions, summarises project status, drafts RAID (risks, assumptions, issues and dependencies) entries and flags overdue items.
Backlog Sync Agent
When Teamwork and Azure DevOps diverge, reconciles tasks with work items — proposing aligned entries with traceable ID mapping.
Branch Review & Delivery Agent
Reviews the current branch before handover or merge; summarises code/report changes, drafts commit and PR text, checks documentation and file headers, records testing, and proposes related Azure DevOps updates for human approval.
D. Information governance
IG / Safety Agent
Hard gate before any agent output proceeds to human review or publication — blocks PID, unpublished internal data, over-automation and unsupported claims.
PASS or BLOCK with reasons. No exceptions for convenience.
E. Warehouse design demo
Synthetic demonstration only. Fictional Demo Rivers Health (DRH) source systems and extracts. Not connected to live Trust systems. Human review required at each stage.
Full demonstration (non-technical): Agentic AI data warehouse demonstration — complete worked example with reader-facing reports. This section is a technical reference for agent rules and artefacts.
Source Profiling Agent
Profiles multi-system source extracts before any warehouse design — grain, linkage, volume trends, extract-change risk and DQ register.
View rule file · Profiling report · Worked conversation · Demo index
Warehouse Design Agent
Proposes staging and dimensional models from profiling evidence — bridge tables, DQ flags, conformed dimensions. No SQL or ADF.
Warehouse demo workflow
Synthetic sources
Source profiling
Design proposal
SQL artefacts
ADF specs
Report QA
Human sign-off
SQL & pipeline artefacts
Azure SQL DDL, QA views and ADF-style JSON specifications — demonstration only, not deployed.
Report QA (warehouse briefs)
Report Analysis Agent checks flawed urgent-care brief against profiler evidence — extract vs operational, stock vs activity.
QA addendum · Flawed draft · Corrected brief · QA conversation
Full artefact map: demo_run_index.md · Checkpoints in warehouse-demo/checkpoints/ · Reader-facing demonstration