NHS IT Risk Tool

Overview

The NHS IT Risk Documentation Tool is a Django-based application designed to support the creation, maintenance, and reporting of structured risk documentation for healthcare IT systems.

The project addresses a practical and important problem in NHS software governance - risk information is often difficult to manage when it is held across separate spreadsheets, Word documents, shared folders, email trails, and local templates. In that environment, risk documentation can quickly become inconsistent, hard to audit, and difficult to reuse.

In healthcare technology, this matters. Software used in or around NHS services can affect clinical workflows, operational continuity, patient communication, access to information, data quality, and decision-making. Even when software is not directly making clinical decisions, it may still introduce risks through poor configuration, unavailable interfaces, incorrect data, weak controls, unclear processes, or incomplete documentation.

The purpose of this application is to provide a more structured way to manage NHS IT risk documentation by capturing hazards, causes, controls, control types, and hazard-control relationships in a database-backed system.

The application does not attempt to replace clinical judgement or formal safety approval. Its value is in improving the structure, consistency, traceability, and maintainability of the information used by people who are responsible for risk review and governance.

Project Context

This project was developed to explore how software can improve the quality and reliability of healthcare IT risk documentation.

The application supports the production of structured NHS IT risk documentation. It is not a clinical decision-making tool and it does not assess risk automatically. Instead, it provides a structured system of record for the information needed during risk review.

That distinction is important.

Risk documentation in healthcare is not simply administration. It is part of the evidence trail that shows hazards have been identified, possible causes have been considered, controls have been defined, and residual risk has been reviewed. When this information is poorly structured, it becomes harder for safety officers, project teams, reviewers, and governance groups to understand what risk exists and what has been done to manage it.

The product idea was to move risk documentation away from disconnected documents and towards a structured, reusable, auditable model.

Why Managing Software Risk Matters in the NHS

Software risk in the NHS has to be managed carefully because healthcare systems operate in complex, high-consequence environments.

A system failure, incomplete integration, incorrect configuration, missing validation rule, unavailable report, or unclear operational process may not look dangerous in isolation. However, in a healthcare setting, these issues can affect patient pathways, clinical administration, service continuity, safeguarding processes, staff workload, and confidence in digital systems.

The risk is not always that the software directly harms a patient. The risk may be that the software contributes to unsafe conditions.

For example:

• important information may not be visible at the right time;
• incorrect or incomplete data may be used in an operational process;
• an integration failure may delay communication between systems;
• a user may misunderstand what the system is showing;
• a manual workaround may become normalised;
• audit evidence may be incomplete when an incident is reviewed;
• an approved control may be inconsistently applied across projects.

This is why structured risk documentation is valuable. It helps teams move beyond informal discussion and creates a clearer evidence base for risk review.

Good risk documentation should make it possible to answer basic but important questions:

What could go wrong, why could it happen, what control is in place, who owns that control, and what risk remains?

The tool was designed around that principle.

The Problem

Risk documentation can become difficult to manage when it is spread across documents, spreadsheets, shared folders, and local templates.

Common problems include:

• duplicated hazards;
• inconsistent control wording;
• unclear ownership;
• poor traceability between hazards, causes, and controls;
• difficulty finding previous risk records;
• difficulty maintaining version control;
• limited reuse of known controls;
• reports becoming detached from the underlying data;
• manual effort when producing documentation packs;
• uncertainty over which records are draft, reviewed, approved, or retired.

The issue is not simply storing the information.

The harder problem is maintaining the relationships between the information.

A hazard may have several causes. A cause may require several controls. A control may apply to more than one hazard. A hazard-control record needs to bring these elements together in a way that can be reviewed, reused, reported, and audited.

That structure is where software adds value.

Product Goal

The goal of the application is to support structured risk documentation for healthcare IT systems.

The system is designed to help answer questions such as:

What hazards have been identified, what causes have been linked to them, what controls are in place, and how can this be turned into consistent risk documentation?

The product supports users by helping them:

• create and manage hazard records;
• define possible causes;
• define controls;
• categorise controls by type;
• link hazards, causes, and controls together;
• create hazard-control records;
• produce consistent documentation packs;
• reuse approved control wording;
• improve traceability between risk items;
• maintain a clearer evidence base for review.

The aim is not to replace professional judgement.

The aim is to make the documentation process more structured, auditable, reusable, and easier to maintain.

Product Benefits

The main benefit of the software is that it turns risk documentation from a document-centred activity into a data-centred activity.

A document is useful as an output, but it is a weak system of record. Once risk information is locked inside separate documents, it becomes harder to search, reuse, validate, compare, and maintain.

A structured application provides several practical benefits.

Improved Consistency

The tool allows hazards, causes, controls, and control types to be recorded in a consistent format. This reduces variation between documents and helps improve the quality of risk records over time.

Standardised control wording is particularly valuable. If the same control is used across multiple hazards or projects, it should not need to be rewritten differently each time.

Better Traceability

The tool makes relationships visible.

A reviewer can see which cause relates to which hazard, which control mitigates that cause, and what residual risk remains. This supports clearer review and makes the evidence trail easier to follow.

Traceability is one of the strongest product benefits because it helps users understand not only what has been documented, but why it has been documented.

Reuse of Known Controls

A reusable control library helps reduce duplication.

Once a control has been written, reviewed, and improved, it can be linked to other relevant hazards. This makes risk documentation faster to produce and helps ensure that common controls are expressed consistently.

Easier Reporting

Because the data is structured, reports can be generated from the same source records.

This reduces the need to manually assemble documentation packs and lowers the risk of reports becoming detached from the latest version of the underlying data.

Stronger Governance

A structured tool can support clearer governance by separating draft records from reviewed or approved records. It can also provide the foundation for audit trails, role-based access, review dates, ownership, and approval states.

This is important in an NHS context because risk documentation needs to be reliable, reviewable, and capable of supporting assurance activity.

Reduced Administrative Burden

The tool reduces the amount of manual effort involved in creating and maintaining risk documentation.

Instead of copying and pasting hazards, controls, and tables between documents, users can maintain structured records and generate outputs when needed.

Better Review Conversations

Good software should improve the quality of human review.

By presenting risk information in a clearer structure, the tool helps reviewers focus on the substance of the risk: whether the hazard is well understood, whether the cause is credible, whether the control is appropriate, and whether the residual risk is acceptable.

Product Boundary

This boundary is critical.

The application supports documentation. It does not make clinical safety decisions.

flowchart TD
    A[Risk Documentation Tool] --> B[Structures risk information]
    A --> C[Links hazards, causes and controls]
    A --> D[Supports reporting]
    A --> E[Improves consistency]
    A --> F[Improves traceability]

    G[Human Reviewer] --> H[Assesses risk]
    G --> I[Approves documentation]
    G --> J[Accepts or rejects residual risk]
    G --> K[Owns clinical judgement]

    A -. supports .-> G

The software can improve structure, consistency, and auditability, but risk ownership remains with the appropriate human reviewer, safety officer, project owner, or governance process.

This is an important design principle. In healthcare software, a tool that supports risk management should not imply that risk ownership has been automated away.

Current Scope

The current project should be understood as a working internal tool rather than a polished commercial product.

It focuses on the core information model and basic web application structure. It is used in a limited live context and was developed to solve a practical documentation problem quickly.

The current version demonstrates the value of structured data capture, reusable records, and report generation, but it would need further development before being positioned as a production-ready governance platform.

The most important point is that the concept is strong. The project identifies a real problem, models it sensibly, and provides a practical software response.

Conceptual Domain Model

erDiagram
    HAZARD ||--o{ CAUSE : has
    HAZARD ||--o{ HAZARD_CONTROL_RECORD : includes
    CAUSE ||--o{ HAZARD_CONTROL_RECORD : contributes_to
    CONTROL ||--o{ HAZARD_CONTROL_RECORD : mitigates
    CONTROL_TYPE ||--o{ CONTROL : categorises

    HAZARD {
        int id
        string title
        string description
        string reference
        string status
    }

    CAUSE {
        int id
        string title
        string description
    }

    CONTROL {
        int id
        string title
        string description
        string owner
    }

    CONTROL_TYPE {
        int id
        string name
        string description
    }

    HAZARD_CONTROL_RECORD {
        int id
        string reference
        string riskSummary
        string residualRisk
        string approvalStatus
    }

This model is deliberately relational.

The value of the application comes from managing the relationships between risk objects, not simply from storing text.

Why Django?

Django is a strong fit for this type of application.

The project needs:

• user authentication;
• database-backed records;
• forms;
• validation;
• admin-style maintenance;
• templates;
• reports;
• clear model relationships;
• fast development;
• low infrastructure complexity.

Django provides most of this out of the box.

A more complex front-end stack would add cost and technical overhead without necessarily improving the core product. For a documentation-heavy internal tool, server-rendered Django pages are an appropriate and pragmatic choice.

The key requirement is not a highly dynamic interface. The key requirement is reliable structured data capture and controlled report generation.

Architectural Shape

flowchart TD
    A[User] --> B[Django Views]
    B --> C[Forms and Validation]
    C --> D[Domain Models]
    D --> E[(Database)]

    D --> F[Hazards]
    D --> G[Causes]
    D --> H[Controls]
    D --> I[Control Types]
    D --> J[Hazard Control Records]

    B --> K[Report Views]
    K --> L[Risk Documentation Output]

The architecture is intentionally simple.

The user interacts with Django views and forms. The application stores structured risk information in the database. Reports can then be generated from the same source data.

This is a better model than manually maintaining separate documents because the report output can be regenerated from controlled records.

Core Capabilities

1. Hazard Management

The system allows users to create and manage hazards.

A hazard record describes something that could cause harm, service failure, data loss, clinical disruption, operational risk, or governance concern.

Typical hazard fields may include:

• hazard title;
• description;
• reference number;
• status;
• category;
• owner;
• initial risk;
• residual risk;
• review date.

The important product decision is that hazards are treated as durable records, not one-off paragraphs in a document.

2. Cause Management

Hazards often have multiple causes.

For example, a single hazard may be caused by:

• incorrect configuration;
• poor user training;
• failed integration;
• missing validation;
• unavailable system interfaces;
• unclear operational process;
• poor data quality;
• incomplete data migration;
• weak access control;
• insufficient monitoring.

Capturing causes separately makes the risk record more useful.

It also helps avoid weak controls. A good control should address a cause, not simply restate the hazard.

3. Control Management

Controls are the actions, safeguards, checks, or processes intended to reduce risk.

Examples might include:

• user access controls;
• audit logging;
• validation checks;
• backup procedures;
• training material;
• operational work instructions;
• monitoring;
• exception reporting;
• manual fallback processes;
• approval workflows;
• reconciliation reports;
• integration failure alerts.

A reusable control library can reduce duplication and improve consistency.

Instead of rewriting similar controls in multiple risk documents, the system can hold a standard control record and link it to relevant hazards.

4. Control Types

Control types allow controls to be categorised.

This classification helps reviewers understand what kind of mitigation is being applied.

It also helps identify gaps. For example, a risk record may have several procedural controls but no technical or detective controls. That may be acceptable, but it should be visible to the reviewer.

5. Hazard-Control Records

The hazard-control record is the key product object.

It brings together:

• the hazard;
• the cause;
• the control;
• the type of control;
• the mitigation explanation;
• the residual risk;
• the review status.

flowchart LR
    A[Hazard] --> D[Hazard-Control Record]
    B[Cause] --> D
    C[Control] --> D
    E[Control Type] --> C
    D --> F[Risk Documentation]

This object turns separate data items into a useful risk management record.

It also creates the structure needed for reporting, review, and audit.

Suggested Workflow

flowchart TD
    A[Create Hazard] --> B[Add Causes]
    B --> C[Add or Select Controls]
    C --> D[Classify Control Types]
    D --> E[Create Hazard-Control Record]
    E --> F[Review Risk Record]
    F --> G{Approved?}
    G -->|Yes| H[Include in Risk Documentation]
    G -->|No| I[Revise Hazard, Cause or Control]
    I --> F

This workflow creates a clear route from initial hazard identification to documented control.

The important design point is that each stage should improve the quality of the record. The software should encourage better thinking, not simply faster form completion.

Product Design Principles

1. Structure Before Reporting

The system should not start with the report.

It should start with the data model.

If hazards, causes, controls, and control relationships are captured correctly, reporting becomes much easier. If the data is weak, the report will simply reproduce weak information in a different format.

This is especially important for NHS risk documentation because reports need to be credible, traceable, and capable of supporting review.

2. Reuse Rather Than Rewriting

A major advantage of software over document templates is reuse.

Controls should not need to be rewritten every time they are used.

A reusable control library makes it easier to:

• standardise wording;
• improve quality over time;
• avoid duplicate records;
• apply known controls to new hazards;
• update common controls centrally;
• reduce manual effort;
• improve consistency between projects.

This is one of the strongest product arguments for the application.

3. Support Human Review

The system should not try to approve risk automatically.

It should support human review by making the record clearer.

Good software should make it easier for a reviewer to see:

• what the hazard is;
• why it exists;
• what control is proposed;
• what type of control it is;
• what risk remains;
• whether the mitigation is credible;
• whether the record is ready for approval.

The system should improve the review process, not bypass it.

4. Make Traceability Visible

Traceability is one of the main benefits of the system.

The tool should make it clear:

• which hazard a control relates to;
• which cause the control addresses;
• who owns the control;
• whether the control is preventative, detective, corrective, procedural, technical, or governance-based;
• what residual risk remains;
• whether the record has been reviewed or approved.

This helps users understand why a control exists and what risk it is intended to mitigate.

5. Keep the System Pragmatic

A risk documentation tool does not need to be over-engineered to be valuable.

The most useful version is one that supports the real workflow: capturing hazards, linking causes and controls, maintaining a reusable library, and producing the required reporting output.

The technical architecture should stay proportionate to the problem.

Data Flow

sequenceDiagram
    participant User
    participant App as Django Application
    participant DB as Database
    participant Report as Report View

    User->>App: Create hazard
    App->>DB: Store hazard record

    User->>App: Add causes and controls
    App->>DB: Store linked records

    User->>App: Create hazard-control record
    App->>DB: Store relationship

    User->>Report: Request documentation output
    Report->>DB: Retrieve structured risk data
    Report->>User: Return risk documentation

The data flow is intentionally simple.

A simple architecture is an advantage here because the complexity is in the risk information, not in the technology.

Key Trade-Offs

Trade-Off 1: Django Monolith Rather Than Microservices

A monolithic Django application is the right design for this stage.

A microservice architecture would add unnecessary complexity. The application needs fast iteration, clear data relationships, and simple deployment. Django provides that without requiring separate services for each part of the domain.

The trade-off is that the application may become harder to scale if many independent modules are added later.

However, for an early-stage risk documentation tool, the monolith is the correct starting point.

Trade-Off 2: Server-Rendered UI Rather Than SPA

A single-page application would not add much value at this stage.

The application is form-heavy and document-heavy. Server-rendered Django templates are sufficient for:

• creating records;
• editing records;
• viewing lists;
• linking objects;
• generating reports.

This keeps development faster and reduces front-end complexity.

Trade-Off 3: Structured Records Rather Than Free Text

Free text is flexible, but it is hard to analyse, reuse, and validate.

Structured records are more restrictive, but they allow better:

• reporting;
• reuse;
• traceability;
• validation;
• consistency;
• governance.

For risk documentation, this is a worthwhile trade-off.

The system should still allow narrative explanation, but the key entities should be structured.

Trade-Off 4: Documentation Support, Not Risk Automation

It would be tempting to add automated risk scoring or AI-generated risk conclusions.

That should be treated carefully.

Risk scoring can support analysis, but it should not replace review. The product should make risk information clearer, not pretend that risk ownership can be automated away.

This is particularly important in healthcare technology, where risk acceptance must remain part of a controlled governance process.

Report Generation

Reporting is central to the product.

The system outputs a project-based reporting pack in Excel format. This is valuable because Excel remains a common and practical format for review, circulation, and governance activity.

The benefit is that the Excel output is generated from structured records rather than manually assembled from disconnected notes.

This means the reporting pack can be:

• more consistent;
• easier to regenerate;
• less prone to manual copying errors;
• aligned to the underlying risk records;
• suitable for review by users who do not need direct access to the application.

The report is not the system of record.

The database is the system of record.

The report is the controlled output.

That is an important product distinction.

Security and Governance Considerations

Because the project relates to healthcare IT risk documentation, security and governance need to be considered carefully.

Important areas include:

• user authentication;
• role-based permissions;
• audit history;
• secure deployment settings;
• protection of sensitive project information;
• controlled access to risk records;
• clear separation between draft and approved records;
• change history for hazards and controls;
• review and approval workflow;
• secure handling of exported reports.

These areas become more important if the tool moves beyond limited use and becomes a broader internal governance product.

Risk documentation may contain sensitive information about systems, controls, vulnerabilities, operational weaknesses, or project decisions. Access should therefore be controlled and proportionate.

Recommended Improvements

1. Add Workflow State

Records should not all be treated the same.

A basic workflow would make the tool more useful:

stateDiagram-v2
    [*] --> Draft
    Draft --> UnderReview
    UnderReview --> Approved
    UnderReview --> Rejected
    Rejected --> Draft
    Approved --> Retired

This would allow the product to distinguish between working records and approved documentation.

2. Add Audit History

Audit history would strengthen the governance value of the tool.

The system should record:

• who created a record;
• who changed it;
• what was changed;
• when the change was made;
• when the record was reviewed;
• when it was approved;
• when it was retired.

This would make the tool more credible as a risk documentation system.

3. Strengthen Permissions

The application would benefit from role-based permissions.

For example:

This would help separate data entry from governance approval.

4. Improve Reporting Controls

Reporting could be strengthened by adding:

• report version numbers;
• generation dates;
• approval status;
• export history;
• filters by project or system;
• separation of draft and approved records;
• clear indication of residual risk.

This would make exported packs easier to manage and more reliable as review evidence.

5. Add Search and Reuse Features

Search is important because the value of the tool increases as the risk library grows.

Useful search features might include:

• search by hazard;
• search by control;
• search by system;
• search by owner;
• search by approval status;
• search by risk category;
• ability to clone or reuse existing hazards and controls.

This would reduce duplication and make the tool more valuable over time.

What This Project Demonstrates

This project demonstrates several useful product and technical capabilities:

• identifying a structured workflow problem;
• modelling risk documentation as relational data;
• using Django for a form-heavy business application;
• creating reusable domain objects;
• thinking about governance and traceability;
• separating documentation support from human decision-making;
• recognising the importance of reporting;
• designing for future audit and approval workflows;
• understanding why software risk management matters in healthcare settings.

It also shows a practical product management pattern:

Do not start by automating judgement. Start by improving the structure, consistency, and traceability of the information people use to make judgement.

That is the central product insight.

Product Management Reflection

The strongest product idea in this project is the move from document-centric risk management to data-centric risk management.

A document is useful as an output, but it is a weak system of record. A database-backed application can make the underlying risk information easier to maintain, search, reuse, review, and report on.

The product value is not simply that users can type hazards into a web form. The value is that risk information becomes structured.

• Hazards are linked to causes.
• Causes are linked to controls.
• Controls are categorised.
• Hazard-control records become reusable evidence.
• Reports are generated from controlled data.

That is the shift from administration to product design.

The project also shows why the right level of technical ambition matters. A simple Django application is more appropriate than an over-engineered architecture because the core problem is structured documentation, not distributed computing.

In an NHS context, this kind of tool has additional importance because healthcare software needs clear risk ownership, credible evidence, and a reliable audit trail. The software does not remove the need for human judgement, but it can make that judgement better supported, better documented, and easier to review.

The next stage would be to strengthen workflow, audit history, permissions, test coverage, and reporting controls. Those additions would move the project from a useful internal tool towards a more credible governance product.

Status

The project is currently in limited live use.

The core concept is strong and appropriate for its current usage, but the project would need further work before being treated as production-ready.

Priority future improvements include:

• cleaner project structure;
• dependency clean-up;
• clearer documentation;
• workflow states;
• audit trail;
• role-based permissions;
• stronger reporting;
• test coverage;
• secure deployment configuration;
• sample data and screenshots.

The project remains useful as a portfolio example because it demonstrates how a healthcare IT governance problem can be translated into a structured software product.

Rather than presenting it as a finished commercial system, it is better positioned as a design and development exercise in risk documentation, Django application design, and NHS software risk governance.

Back to Projects