Guide · checked October 2026
How to write a clinical audit proforma
Write a clinical audit proforma by listing only the fields needed to test each standard, giving collectors clear instructions on where to look and how to decide compliance, using coded answers and pick lists instead of free text, and piloting it before full data collection.
Start from the standards
HQIP's Best practice in clinical audit says the data set should be defined against the standards, and that data not needed to measure compliance should not be collected. So the proforma starts with the criteria: for each one, what fact in the record shows whether it was met, and what counts as an exception.
Add the minimum identifying fields needed to avoid double counting and to check a case later, and plan to anonymise at the earliest stage, as HQIP's reporting guide asks.
Design rules from HQIP's data quality guide
- Write instructions that name the data sources and the order to check them.
- Say how to decide and record compliance, including what to do when sources conflict or information is missing.
- Group questions by type of data and order them as they appear in the source record.
- Use number codes, for example 1 = yes, 2 = no, 9 = missing, 8 = not applicable.
- Use pick lists and keep free text to a minimum.
Pilot it
HQIP recommends using an existing validated tool where one exists, or designing and piloting your own before full data collection. With several data collectors, write a data collection protocol and pilot that too, so that two people reading the same record record the same answer.
For electronic records, HQIP says to test the extraction to confirm the right source and the right sample are being pulled. A query that quietly misses a ward or a date range undermines the whole audit.
Proforma pitfalls
- Yes/no questions with no rule for "not documented".
- Free-text boxes that cannot be counted at analysis.
- Fields that do not map to any standard.
- A form changed half-way through collection without recording the change.
Where Oriel fits
In Oriel, the proforma is replaced by an audit pack: versioned data that says what is read, from which system, and which rule decides each case. A pack can be drafted from a one-line description and is approved by governance before use. Where there is no interface, a CSV or XLSX export can be mapped column by column and previewed before import.
Unclear cases are not forced into yes or no. They wait for a person to decide, with a note. Oriel is a pilot on synthetic data only.
Questions
Should the proforma include patient names?
Collect the minimum needed to identify and check a case, and anonymise at the earliest possible stage, as HQIP advises, under your organisation's information governance rules.
How do I record missing information?
Give it its own code. HQIP's example uses 9 for missing and 8 for not applicable, so gaps are visible at analysis.
Sources
Official pages, checked October 2026. Guidance changes, so check the current version before you rely on it.
General information for healthcare managers and clinical teams, checked October 2026. It is not legal, regulatory or clinical advice; follow the current official guidance and your organisation's own policies. No patient data is used in these examples. Oriel is a working prototype shown on a fictional demo hospital with synthetic data only. It is not a medical device and is not for clinical use. It drafts and flags for people to decide; it does not diagnose or change clinical records. A clinical safety case and information-governance approval come before any use with real patient data. Oriel is a working name.