Project case study

NHS IT Risk Tool

A Django-based risk documentation application designed to help structure hazards, causes, controls, control types, and hazard control records for NHS IT risk management.

DjangoPythonRisk ManagementNHS ITClinical SafetyGovernanceDocumentationProduct DesignHealthcare Technology

Overview

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

The project focuses on a practical problem: risk documentation can become inconsistent, fragmented, and difficult to maintain when it is managed across separate spreadsheets, documents, and local templates.

The aim of this project was to explore how a web application could provide a more structured way to manage:

The project was built using Django because the problem is highly suited to a database-backed, form-driven web application. The core task is not complex front-end interaction. The core task is structured data capture, relationship management, validation, and report generation.

This makes Django a sensible choice.

Project Context

This was a project designed to explore risk management software in a healthcare IT context.

The application was created to support the production of NHS IT risk documentation. The goal was not to create a clinical decision-making tool, but to make risk documentation more structured, reusable, and consistent.

In healthcare technology, risk documentation is not just administration. It provides evidence that hazards have been identified, causes have been considered, controls have been defined, and risk treatment has been documented.

The product idea was to move this process away from disconnected documents and towards a structured system of records.

The Problem

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

Common problems include:

The problem is not simply storing the information.

The harder problem is keeping the relationships between the information clear.

A hazard may have multiple 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 consistent way.

That structure is where software can help.

Product Goal

The goal of the application is to support structured risk documentation.

The system should 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 documentation?”

The product is designed to help users:

The aim is not to replace professional judgement.

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

Product Boundary

This distinction is important.

The application should support documentation. It should 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]

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

    A -. supports .-> F

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

Current Scope

The uploaded project represents an QDS rather than a polished commercial product.

The current scope appears focused on the core information model and basic web application structure. It is used by a limited number of users in a live situation

It was developed to get something working quickly rather than to develop a polished solution

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 tool comes from managing the relationships between the objects, not simply from storing text.

Why Django?

Django is a strong fit for this kind of application.

The project needs:

Django provides most of this out of the box.

A more complex front-end stack would add cost and complexity without necessarily improving the core product. For a documentation-heavy internal tool, server-rendered Django pages are often sufficient.

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 basic architecture is simple and appropriate.

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 should allow users to create and manage hazards.

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

Typical hazard fields may include:

The important product decision is that hazards should be 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:

Capturing causes separately makes the risk record more useful.

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

3. Control Management

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

Examples might include:

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.

For example:

Control TypeExample
PreventativeAccess restriction or validation rule
DetectiveAudit log or exception report
CorrectiveRecovery process or manual correction
ProceduralTraining, checklist, or operating procedure
TechnicalSystem rule, integration check, or automated control

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.

5. Hazard Control Records

The hazard control record is the key product object.

It brings together:

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.

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 identification to documented control.

The important design point is that each stage should improve the quality of the record.

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.

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:

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:

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

4. Make Traceability Visible

Traceability is one of the main benefits of the system.

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

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 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:

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:

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.

Report Generation

Reporting is central to the product. The system outputs a project based reporting pack in excel format, the excel format is exactly what is needed by the end user

Security and Governance Considerations

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

Important areas included:

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.

What This Project Demonstrates

This project demonstrates several useful product and technical capabilities:

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.

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, 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:

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.

The next stage would be to strengthen workflow, audit history, permissions, and reporting. Those additions would move the project from a prototype into something closer to a credible internal governance product.

Status

The project is in use by a user. The core concept is strong and is ideal for its current limited useage, but the project would need further work before being treated as production-ready.

Priority future improvements include:

The project remains useful as a portfolio example because it demonstrates how a regulatory documentation 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 healthcare IT governance.

Back to Projects