Proposals
Summary Background Objective Scope Effort Team Timeline Assumptions Deliverables Next steps
Project Proposal

Replicating production infrastructure from London → Mumbai

A scoped, low-risk migration that mirrors your proven AWS environment into ap-south-1 — same architecture, one production footprint, one extended pipeline.

68
Estimated hours
7–8
Working days
2
Engineers
2
New environments
London
eu-west-2
Existing
Dev UAT Prod GitLab CI/CD
Mirrored
replication
Mumbai
ap-south-1
New
Prod UAT GitLab CI/CD (extended)
01

Executive summary

This proposal outlines the approach, scope, and commercial terms for replicating the client's existing AWS production infrastructure from the London Region into the AWS Mumbai Region (ap-south-1). The client currently operates a fully validated, production-grade environment in London spanning Development, UAT, and Production, supported by an established GitLab CI/CD pipeline.

The objective of this engagement is not to redesign the existing architecture, but to faithfully mirror the proven London production environment in Mumbai. In line with the client's requirements, Production and UAT environments will be deployed in the Mumbai region; the Development environment is excluded from this scope unless requested as a separate engagement.

The existing GitLab CI/CD pipeline will be extended to support deployments to both the London and Mumbai regions, preserving the current deployment workflow and minimizing operational disruption for the client's engineering team.

This engagement is estimated at approximately 68 hours of effort, delivered by a two-person team comprising a Lead DevOps Engineer and a Senior DevOps Engineer, over an estimated project duration of 1.5 weeks (7–8 working days).

02

Project background

The client currently maintains a fully operational AWS infrastructure in the London Region, comprising three distinct deployment environments: Development, UAT, and Production. This infrastructure is stable, production-proven, and already supported by GitLab CI/CD pipelines that automate deployments to the London region.

The client now wishes to establish equivalent application infrastructure in the AWS Mumbai Region (ap-south-1) to support regional expansion, data residency requirements, or improved latency for users in South Asia.

03

Objective

Replicate what already works — reduce risk and accelerate delivery by reusing a proven design rather than starting from scratch.

Production & UAT environments

Unlike London, only Production and UAT environments will be deployed in Mumbai. Development is excluded unless requested separately.

Pipeline extension

The existing GitLab CI/CD pipeline is extended to target both London and Mumbai, preserving the current workflow.

04

Scope of work

Twenty-six activities across five delivery areas, grouped the way the build actually happens.

Phase 0

Infrastructure assessment and migration planning precedes all build activity.

Foundation & networking

  • VPC
  • Public & private subnets
  • Security groups
  • Route tables
  • Internet gateway
  • NAT gateway (if required)

Compute, storage & data

  • EC2
  • EBS
  • Amazon RDS migration / setup
  • ElastiCache

Delivery & access

  • Application load balancer
  • Route 53
  • Certificate Manager (SSL)
  • CloudFront
  • API Gateway
  • Lambda

Security, messaging & ops

  • IAM roles & policies
  • AWS KMS
  • Amazon SES
  • CloudWatch monitoring & logs

Deployment & handover

  • GitLab CI/CD config for Mumbai
  • Application deployment
  • End-to-end testing & validation
  • Production readiness verification
  • Documentation & handover
05

Estimated effort

Approximately 68 hours, broken down by task area.

Total estimated effort 68 hrs
06

Team allocation

A focused, senior two-person team.

LD

Lead DevOps Engineer

Architecture & readiness

Oversees architecture validation, migration planning, security, and production readiness.

SD

Senior DevOps Engineer

Build & delivery

Handles infrastructure provisioning, deployment, CI/CD configuration, and testing.

07

Timeline

1.5 weeks (7–8 working days) end to end.

DAY 1–2
Infrastructure provisioning
DAY 3
Database migration
DAY 4
Application deployment
DAY 5
GitLab pipeline setup
DAY 6
End-to-end testing
DAY 7
Production validation
DAY 8
Documentation
08

Assumptions

  • Existing London infrastructure will remain unchanged.
  • The existing architecture will be reused without major modifications.
  • Production and UAT environments will be created in Mumbai; Development is not included.
  • Existing GitLab repositories and deployment pipelines are available.
  • Required AWS access, DNS access, SSL certificates, and application source code will be provided by the client.
  • Any new application development, feature enhancements, or infrastructure redesign is outside the scope of this proposal.
Note

If any technical challenges or AWS service limitations arise during the replication process, we will assess the issue, discuss available alternatives with the client, and proceed with the most appropriate solution upon approval.

09

Deliverables

  • Production-ready AWS infrastructure in Mumbai (ap-south-1)
  • Infrastructure configured to mirror the London production environment
  • Database migrated and validated
  • GitLab CI/CD pipeline extended to support Mumbai deployments
  • Application successfully deployed
  • Monitoring and logging configured
  • Infrastructure tested and validated
  • Documentation and deployment handover
10

Next steps

Ready to mirror London in Mumbai?

We welcome the opportunity to walk through scope, timeline, or approach in more detail. On approval, we'll schedule a kickoff to confirm access requirements and begin provisioning.

Prepared by Chintan Ramani & · 28 July 2026 · Confidential
Overview Objective Tech Stack Scope Integration Environment Security Success Criteria Effort Assumptions Deliverables Next Steps
Feasibility Demonstrator

Re-engineering the Diagnostic Module → integrated with TCC-CASEMIX

React.js + Python Flask, connected to the existing TCC-CASEMIX platform through a middleware integration layer — not a replacement of the platform, a re-engineering of the Diagnostic module within it.

78
Estimated hours
6
Workflow steps
Existing
Database (unchanged)
1
Module in scope
Current stack
TCC-CASEMIX — live
Existing
Angular .NET TCC-CASEMIX platform
Middleware /
Integration API
Target stack
Diagnostic module only
New
React.js Python Flask Middleware API
01

Project overview

This is a feasibility demonstrator for re-engineering the existing TCC-CASEMIX Breast Oncology / Diagnostic Module from Angular/.NET to React.js and Python Flask.

The objective is to prove that the module can be re-engineered while preserving existing functionality and integrating with the current TCC-CASEMIX platform and database.

The existing TCC-CASEMIX platform remains fully in place. The new Diagnostic implementation communicates with it through a middleware / integration layer — this is a re-engineering of the Diagnostic module within the platform, not a replacement of it.

02

Objective & approach

Prove feasibility of the new stack, integrated safely with what already exists.

Diagnostic module only

Only the Diagnostic / Breast Oncology module is re-engineered. The wider TCC-CASEMIX platform — configuration, user management, institution data — remains exactly as it is today.

Middleware bridges old and new

A middleware / integration API lets the existing .NET platform and the new React/Flask implementation communicate securely, so the Diagnostic module can be opened from inside TCC-CASEMIX without a full platform migration.

03

Technology stack

Frontend and backend are rebuilt on a modern stack; a new middleware layer bridges the two platforms; the database is untouched.

FE

Frontend

Rebuilt

React.js · React Router · REST API integration

BE

Backend

Rebuilt

Python Flask · RESTful APIs

IN

Integration

New

Middleware / integration API · secure API communication · existing auth/role context validated

DB

Database

Unchanged

Existing MySQL (Amazon Aurora) · no redesign, no unnecessary schema changes

The middleware layer exists because the TCC-CASEMIX platform stays operational: when a user opens the Diagnostic Module from the existing .NET platform, this layer is what lets it hand off to the new React/Flask implementation and back again.
04

Scope of work

Ten main areas, kept at module level — not a field-by-field specification.

1. Diagnostic module frontend

  • Rebuild the Diagnostic / Breast Oncology module in React.js
  • Maintain the current UI workflow & functionality
  • Completed & Draft Stage 1 records · Create / Edit / View

2. DDAP Stage 1 workflow

  • Consent · Subject · Risk 1 · Risk 3 · Summary Finding · Referral
  • Draft / save / navigation behaviour
  • Existing validation & calculation behaviour preserved

3. Python backend

  • Re-engineer the Diagnostic backend in Python Flask
  • Maintain business logic & functional parity
  • CRUD and required Diagnostic APIs

4. Middleware / platform integration

  • Middleware / integration API between .NET and Flask
  • Enable Diagnostic access from inside TCC-CASEMIX
  • Pass & validate user / session / role context

5. Existing database integration

  • Connect to existing MySQL / Amazon Aurora
  • Read required TCC-CASEMIX data
  • Write Diagnostic data, preserving existing structure

6. User / role integration

  • Use the existing User Management & role structure
  • Demonstrate creating a physician user & assigning access
  • User Management itself is not rebuilt

7. Institution / referral integration

  • Read Institution / Clinic data from TCC-CASEMIX
  • Support the existing referral workflow, incl. postcode / closest-institution logic
  • Institution Management itself is not rebuilt

8. Security & AI-assisted development

  • AI used only as a development accelerator; all code reviewed
  • Security review: auth, input validation, SQL injection, secrets, dependencies
  • Migrated functionality compared against the existing .NET implementation

9. Database integrity

  • Controlled development / CI environment, no direct production work
  • Restricted credentials, backups / snapshots, transaction-controlled writes
  • Diagnostic writes tested without affecting unrelated data

10. Testing & demonstration

  • Functional & integration testing, DB read/write validation
  • User/role & referral test scenarios
  • Existing workflow validation & demonstrator handover

DDAP Stage 1 workflow

Consent
→
Subject
→
Risk 1
→
Risk 3
→
Summary Finding
→
Referral to Secondary Care
05

Integration flow

How a Diagnostic session works end to end — and how it stays inside the existing platform.

The existing TCC-CASEMIX platform remains the system of entry and continues to manage the wider platform functionality. The middleware layer provides the integration boundary between the existing .NET platform and the new React/Flask Diagnostic implementation.

Proposed flow

ExistingTCC-CASEMIX login
↓
ExistingExisting dashboard
↓
ExistingUser opens Diagnostic / Breast Oncology
↓
Bridge.NET platform / middleware integration API
↓
NewReact.js Diagnostic module
↓
NewPython Flask API
↓
ExistingExisting MySQL / Aurora
↓
ExistingRead existing TCC-CASEMIX data
↓
NewCreate / update Diagnostic data
↓
ExistingReferral reads Institution / postcode data
↓
NewSave Diagnostic / Referral data
↓
NewReturn result to React
↓
NewDisplay within Diagnostic module

Quick client flow

ExistingExisting TCC-CASEMIX
↓
ExistingExisting login / dashboard
↓
ExistingOpen Breast Oncology / Diagnostic
↓
BridgeMiddleware integration API
↓
NewReact.js
↓
NewPython Flask
↓
ExistingExisting MySQL / Aurora
READ

User / Role / Institution / required TCC-CASEMIX data

WRITE

Diagnostic / DDAP / Referral data

06

Development environment & requirements

What we need from the client to begin.

  • GitLab / repository access to the existing Angular and .NET Diagnostic implementation
  • Development / CI TCC-CASEMIX database access
  • Database schema and relevant table relationships
  • Existing authentication / session / authorization details
  • Test user accounts and roles
  • Access to relevant User/Role and Institution/Clinic data
  • Existing API / interface documentation where available
  • Development deployment environment / access
  • Existing test scenarios / data where available
The Diagnostic work will be developed independently from the infrastructure replication work currently underway. Infrastructure replication is not included in this 78-hour Diagnostic estimate.
07

Security & database integrity

"If you are planning to use AI for the transformation, how will you verify that you have not introduced any security vulnerabilities?"

AI will be used only as a development accelerator. All generated code is reviewed by the development team and validated against the existing .NET implementation before it is accepted.

Security verification

  • Authentication & authorization review
  • Role / permission validation
  • Input validation
  • SQL injection protection
  • Secure API handling
  • Sensitive data protection
  • Secret / credential review
  • Dependency vulnerability checks
  • API and integration testing

Database integrity

  • Separate development / CI database & environment
  • Restricted DB permissions, no direct production development
  • Backup / snapshot before major integration testing
  • Transaction-controlled, controlled SQL/database operations
  • Test data used; unrelated TCC-CASEMIX data validated unchanged
08

Key success criteria

What "done" looks like for this demonstrator.

  1. Breast Oncology / Diagnostic module successfully demonstrated using React.js and Python Flask.
  2. Diagnostic module accessible from the existing TCC-CASEMIX platform.
  3. Existing TCC-CASEMIX database can be read successfully.
  4. Diagnostic data can be written to the appropriate existing database tables.
  5. New physician can be created through existing User Management and granted appropriate Diagnostic access.
  6. Referral workflow can read Institution information from TCC-CASEMIX.
  7. Existing Diagnostic workflow and business behaviour are maintained.
  8. AI-assisted transformation passes developer, functional, security, and integration validation.
  9. Development database integrity is maintained throughout the demonstrator.
09

Estimated effort

78 Total estimated hours
€35 Per hour · €2,730 total at this rate
Note

This estimate is for the feasibility demonstrator described above. It assumes the current source code, database, and business logic are available, and no new features or major functional changes are required beyond the integration work described. Infrastructure replication work is independent and excluded from this estimate.

10

Assumptions & boundaries

  • Only the Diagnostic / Breast Oncology module is being re-engineered.
  • Existing TCC-CASEMIX platform modules are not being rebuilt.
  • User Management remains existing.
  • Institution / Clinic Management remains existing.
  • Configuration modules remain existing.
  • Existing database is reused; no major schema redesign is included.
  • Infrastructure replication work is independent and excluded from this estimate.
  • Existing source code and required access will be provided.
  • New features or major changes to existing business logic are outside this scope.
  • Hidden complexity found in the existing .NET code or integration architecture will be discussed before expanding scope.
11

Deliverables

  • React.js Diagnostic / Breast Oncology demonstrator
  • Python Flask Diagnostic backend
  • Middleware / integration API
  • Existing MySQL / Aurora integration
  • User / Role integration demonstration
  • Institution / Referral integration demonstration
  • Existing DDAP Stage 1 workflow
  • Security and database integrity validation
  • Functional / integration testing
  • Source code and handover
12

Next steps

Ready to demonstrate the integrated Diagnostic module?

On approval, we'll confirm repository and database access, agree the development/CI environment, and begin with technical discovery of the existing .NET Diagnostic implementation.

Prepared by DevOps & Cloud Infrastructure Team · Revised 04 August 2026 · Confidential
Setup Overview Understanding Clinical Journey Scope Effort Deliverables Assumptions Next Steps
New Clinical Module

HRIPT Dermatology Module → a 46-day patch test, end to end

A new primary-care screening module for the CaseMix platform that lets community clinics enrol a subject, record baseline health checks, follow patch-test reactions over 46 days, and refer to secondary care when needed.

50–60
Estimated hours
7–8
Working days
46
Day clinical protocol
5
Deliverables
01

Project setup & code review

We get the existing CaseMix code running locally and understand how it works.

Repository clone & local setup. We clone the CaseMix backend and frontend repositories from GitLab and set up the full platform locally — the .NET 6 / ABP 7 backend, the Angular 20 admin frontend (casemix-admin) and a local MySQL database built using the existing Liquibase migrations. Application settings, connection strings, JWT authentication and test user accounts are configured so the platform runs end to end on a developer machine.

Fixing build & run errors. We resolve any package or dependency version issues, compile and configuration errors, and database migration problems found during setup. The platform is then checked by logging in, selecting a clinic and opening the existing Breast Oncology (DDAP) and Pre-Operative (POAP) modules to confirm everything works as expected.

Code understanding & review. We carry out a read-only review of the existing codebase. This confirms that no HRIPT code exists today, and that key building blocks can be reused — module gating and clinic access (HospitalsAppService), sequential subject ID allocation (PatientRegistryAppService), the DDAP dual worklists and multi-table referral logic (DiagnosticAssessmentsAppService), and the POAP bloods and medication panels. Services, DTOs, permissions and routing are mapped so HRIPT follows the same architecture.

Outcome: a working local copy of CaseMix, a clear view of reusable code, and a confirmed build plan for HRIPT.
02

Module overview

HRIPT stands for Human Repeat Insult Patch Test. It is a standard 46-day clinical protocol used by community clinics to check how a person’s skin reacts to repeated contact with a substance — helping identify contact dermatitis, skin sensitisation and other adverse skin reactions.

Today the CaseMix platform has no HRIPT module. This proposal covers building it as a new module inside the existing platform, following the same look, feel and working patterns clinicians already know from the Breast Oncology (Diagnostic) and Pre-Operative modules.

The module is fully pseudonymous: no patient names, addresses, phone numbers or national ID numbers are collected. Each subject is identified only by a system-generated study ID.

03

Our understanding

A good part of what HRIPT needs already exists elsewhere in CaseMix — which is why the effort is kept low.

Already available — will be reused

  • Clinic-level access control and module tile on the dashboard
  • “In progress” and “Completed” worklist layout
  • Automatic subject ID numbering and consultant selection
  • Demographics form, postcode lookup and blood pressure calculator
  • Blood test and medication panels (from Pre-Operative module)
  • Secondary care referral process

New for HRIPT

  • Dermatology-specific consent statement
  • Vital signs checklist and urine panel
  • Skin type assessment (Fitzpatrick types I–VI) and 7-level skin irritation scale
  • Eight follow-up visit forms covering the full 46-day protocol
  • Referral routing to dermatology (currently fixed to Breast Oncology)
  • Locking the record as read-only once complete
04

Clinical journey

How a clinician will use the module, from login to referral.

Step 1Login & clinic selection — clinician signs in and selects their community clinic; only clinics set up for primary-care diagnostics see the HRIPT module.
↓
Step 2Worklists — two lists: “Tests in progress” (editable) and “46-day tests completed” (read-only). A new subject is started with “+ Create”.
↓
Step 3Enrolment & consent — a study ID is issued automatically, a consultant is assigned and consent is recorded. The next step unlocks only after consent.
↓
Step 4Demographics — year of birth, gender, postcode and ethnicity, plus the planned final assessment date.
↓
Step 5Vitals & lifestyle — blood pressure (with automatic category), temperature, pulse, breathing, oxygen, urine checks, smoking, alcohol and BMI.
↓
Step 6Clinical baseline — blood results, current medications (including immunosuppressants) and skin type / irritation assessment.
↓
Step 746-day patch follow-ups — eight visits across three phases (below), recording skin reactions at each reading.
↓
Step 8Summary finding — clinician reviews the baseline and all reactions; if an acute allergic reaction is found, a secondary care hospital is selected.
↓
Step 9Referral & record lock — the referral is created automatically, the record is locked as read-only and moves to the “completed” worklist.

The 46-day patch test in three phases

Induction · Days 1–21

  • Visits 2–5
  • Repeated patch application
  • Readings at 48 / 72 hours

Rest · Days 22–35

  • Visits 6–7
  • 10–14 days without patches
  • Watch for delayed reactions

Challenge · Days 36–46

  • Visits 8–9
  • Patch applied to a fresh skin site
  • Readings at 48 / 72 / 96 hours
05

Scope of work

What we will build, test and hand over.

  1. HRIPT module tile, access control and navigation within CaseMix.
  2. “Tests in progress” and “46-day tests completed” worklists.
  3. Enrolment, consent, demographics and vitals / lifestyle screens.
  4. Clinical baseline screens: bloods, medications and skin assessment.
  5. Eight follow-up visit screens covering the full 46-day protocol.
  6. Summary finding, automatic secondary care referral and record locking.
  7. Built-in checks — e.g. no progress without consent, valid birth years, sensible blood pressure values, every vital sign answered.
  8. Full end-to-end testing, plus a check that existing Breast Oncology and Pre-Operative modules are unaffected.
06

Estimated effort

50–60 hours over 7–8 working days, broken down by work area.

Total estimated effort 50–60 hrs
07

Deliverables

  • D-1 · Database setup — new HRIPT data storage and access permissions added to the existing CaseMix database.
  • D-2 · HRIPT backend service — secure services that save and retrieve HRIPT records, limited to each clinic’s own data.
  • D-3 · HRIPT screens — the complete module in CaseMix: two worklists and the step-by-step assessment covering all 13 stages.
  • D-4 · Technical reference — updated API documentation for the HRIPT services.
  • D-5 · Clinician user guide — step-by-step guide covering navigation, screening entry and secondary care referral, plus UAT support.
08

Assumptions

  • No personal identifiers (names, phone numbers, addresses, Aadhaar / NHS numbers) are stored; year of birth is the only date of birth information collected.
  • The module follows the existing CaseMix technology and design standards — no platform changes.
  • Clinical photo uploads and surgical tray set-up belong to other modules and are not included.
  • Required code, environment and test access will be provided by the client.
09

Next steps

Ready to add HRIPT to CaseMix?

On approval and confirmation of the points above, we’ll confirm access, finalise requirements and begin delivery — with the module ready for your UAT in around 7–8 working days.

Prepared by Kretoss Technology · September 2026 · Confidential
Summary Scope Deliverables Timeline & Effort Approach Assumptions Out of Scope Acceptance Summary
Module Implementation

Breast Oncology Module → DDAP & DDAP2 within TCC CaseMix

Implementing the primary-care (DDAP) and secondary-care (DDAP2) Breast Oncology workflows inside the existing CaseMix platform — reusing its architecture, UI patterns, APIs and referral model rather than building a new application.

80–90
Estimated hours
3–4
Weeks delivery
2
Workflows (DDAP / DDAP2)
1
Full-stack developer
DDAP
Primary care · screening
Gen 1
Consent Risk 1 & 3 Summary Referral
Referral &
data transfer
DDAP2
Secondary care · imaging
Gen 2
Imaging Procedure type Surgical pathway
01

Executive summary

The objective of this engagement is to implement the Breast Oncology DDAP and DDAP2 workflows within the existing TCC CaseMix platform. This is an enhancement to CaseMix — not a new, standalone application.

The CaseMix application has already been reviewed and set up locally. The implementation will build on the existing codebase, reusing its authentication, hospital context, UI patterns, backend services, database structure and referral architecture wherever appropriate. The existing codebase and API brief are treated as the source of truth for scope.

The Breast Oncology scope covers two generations of the workflow: DDAP for primary care screening and referral, and DDAP2 for secondary care imaging and onward referral to the surgical pathway.

The work is estimated at 80–90 hours, delivered by one experienced full-stack developer using AI-assisted development tools, over approximately 3–4 weeks.

02

Scope of work

Eight functional areas, each built on existing CaseMix components where they already exist.

A. Authentication & session

  • Existing CaseMix authentication & session flow
  • User context and hospital context
  • Module access / gating
  • Breast Oncology runs within the existing auth architecture

B. Consent & subject ID

  • Consent workflow
  • Subject ID allocation
  • Patient / subject context
  • Required hospital & clinical context

C. DDAP — primary care workflow

  • Subject · Risk 1 · Risk 3
  • Summary Finding · Referral to Secondary Care
  • Reuses the existing DDAP tab-based workflow and question / answer rendering patterns

D. DDAP2 — secondary care workflow

  • Subject · Risk 1 · Risk 3 · imaging questionnaires
  • Summary Finding · Procedure Type Selection · Refer to Surgical Pathway
  • Risk 3 is the largest component — the main questionnaire renderer plus multiple imaging-related panels / stages

E. Worklists / list pages

  • DDAP list page · DDAP2 list page
  • Search, sorting and pagination
  • Delete / action handling where supported by the existing implementation

F. Referral & data transfer

  • DDAP referral to secondary care & creation of the receiving hospital record
  • Transfer of relevant patient / diagnostic information and subject ID handling
  • Originating record marked as transferred and made read-only
  • DDAP2 referral to the surgical pathway / POAP workflow, per existing architecture

G. Backend / API & database

  • Implement or extend required application services, DTOs and API endpoints
  • Database operations reusing existing CaseMix entities & services
  • Hospital-level data isolation
  • Server-side authorization for new / modified services

H. Testing & integration

  • Functional testing of DDAP & DDAP2 workflows
  • API integration and referral / data-transfer testing
  • Authentication & authorization testing
  • Regression against existing CaseMix, bug fixing and UAT support

DDAP — primary care workflow

Consent & Subject ID
→
Subject
→
Risk 1
→
Risk 3
→
Summary Finding
→
Referral to Secondary Care

DDAP2 — secondary care workflow

Subject
→
Risk 1
→
Risk 3 · Imaging
→
Summary Finding
→
Procedure Type
→
Refer to Surgical Pathway
03

Deliverables

  • Completed Breast Oncology DDAP module
  • Completed Breast Oncology DDAP2 module
  • Required frontend screens and components
  • Required backend APIs and services
  • Database integration
  • Referral and data-transfer functionality
  • Authentication and authorization integration
  • Testing and bug fixes
  • Deployment / UAT-ready build
  • Basic technical handover and documentation
04

Timeline & effort

Approximately 80–90 hours, delivered over 3–4 weeks depending on review and UAT turnaround.

Total estimated effort 80–90 hrs
About this estimate

The estimate is based on the reviewed CaseMix codebase and the documented DDAP / DDAP2 scope. It includes development, integration, testing, bug fixing and deployment / UAT support. Changes or additions outside the defined scope may require a revised estimate.

05

Technical approach

Build on what CaseMix already does well; extend only where the workflow requires it.

  1. Reuse the existing architecture — CaseMix components, entities and services are reused wherever practical.
  2. Follow existing frontend patterns — the same tab-driven workflow and question / answer rendering used across CaseMix.
  3. Extend APIs only where required — existing backend services are reused; new endpoints are added only where the workflow needs them.
  4. Maintain hospital-level security — server-side authorization and hospital-level data isolation on all new and modified services.
  5. AI-assisted, human-verified — AI tools accelerate repetitive implementation. All clinical workflow, business logic, security, integration and final code is manually reviewed and tested.
06

Assumptions

  • Existing CaseMix source code and required dependencies remain available.
  • The existing development environment can be used.
  • No major architectural redesign is required.
  • Clinical requirements and questionnaire definitions are available in the provided codebase / specification.
  • Existing third-party integrations required by the module remain available.
  • Client feedback and UAT are provided within a reasonable timeframe.
  • Any new functionality outside the documented DDAP / DDAP2 scope will be estimated separately.
07

Out of scope

Not included unless specifically requested.

  • Major redesign of the CaseMix platform
  • New infrastructure architecture
  • New third-party integrations not already required by the existing module
  • Clinical image processing or AI analysis
  • Major changes to unrelated CaseMix modules
  • New business workflows outside DDAP / DDAP2
  • Large-scale data migration
08

Acceptance criteria

What “done” looks like for this module.

  1. The DDAP workflow functions end to end, from consent through to referral to secondary care.
  2. The DDAP2 workflow functions end to end, through to referral to the surgical pathway.
  3. All required forms and questions save and load correctly.
  4. Authentication and hospital-level authorization work correctly.
  5. Referral and data transfer work correctly between primary and secondary care.
  6. Originating records become read-only after transfer where required.
  7. DDAP and DDAP2 list pages work correctly, including search, sorting and pagination.
  8. No critical regression issues in the existing CaseMix platform.
  9. A UAT-ready deployment is delivered.
09

Final summary

Breast Oncology, built into CaseMix.

The Breast Oncology module can be implemented within the existing CaseMix platform by leveraging the existing DDAP / DDAP2 architecture, reusable components, APIs and database patterns. We estimate 80–90 hours of effort with delivery in approximately 3–4 weeks, based on the reviewed codebase and documented scope.

Prepared by Kretoss Technology · September 2026 · Confidential
Document Executive Scope Technology Architecture Authentication, Authorisation, DDAP Referral Data Security Infrastructure, Testing Risk Assumptions, Change
Statement of Work · Technical Proposal Version Control 1 · V.1

Breast Oncology System → standalone, on CaseMix identity

DDAP and DDAP2 delivered as a separate, secured application. Users sign in with their existing CaseMix credentials; clinical records, referrals and the POAP hand-off stay consistent with the CaseMix platform.

140–180
Estimated hours
23
DDAP2 Risk 3 panels
15
CB §2 units quoted
Python
Backend · Flask
Existing CaseMix.NET 6 · Users · Hospitals · MySQLExisting
Identity · JWT
Security layerSession · MFA · Authorisation · AuditNew
Scoped API
Breast OncologyReact.js · Python · DDAP · DDAP2New
Existing CaseMixProposed ArchitectureRecommendationAssumptionValidation Required
Prepared for TCC-CASEMIX — Engineering & Clinical Product
Prepared by Kretoss Technology — Engineering
Document SOW & Technical Proposal — KT-TCC-BO-SOW
Version / date v1.3 — 26 September 2026 — structured against Codebase Brief v3 §2
Technology React.js · Python (Flask) · MySQL (existing CaseMix)
Client documents referenced CB = CaseMix — working with the codebase, v3 (19 Sep 2026) · API = CaseMix API — v1 and tpv1, v1.2 (17 Sep 2026)
00

Document conventions

Client references. Every point carries a reference chip back to the client's own documents so it can be checked side by side:

Chip Points to
↗ CB §2 · U10 Codebase Brief v3, section 2 table, Unit of work #10
↗ CB §7.1 Codebase Brief v3, section 7.1
↗ API §3 API Brief v1.2, section 3
New Not in the client documents — added by the standalone-system requirement

Statement labels.

Label Meaning
Existing CaseMix Confirmed in CB or API
Proposed Architecture New design introduced by the standalone requirement
Recommendation Preferred option, subject to TCC-CASEMIX agreement
Assumption Taken as true for this estimate
Validation Required Confirmed against the tagged code in Phase 1
01

Executive summary

↗ CB §1 ↗ CB §2 ↗ CB §10 ↗ API §3

  • A separate Breast Oncology application delivering DDAP (primary care) and DDAP2 (secondary care), quoted for both generations as CB §2 requires. ↗ CB §2
  • Users sign in with their existing CaseMix username and password; no credentials stored. ↗ API §3
  • Every CB §2 unit of work (U1–U15) is addressed individually in §2 of this document. ↗ CB §2 · U1–U15
  • Server-side authorisation and hospital scoping — new work the client has specified — is built into every endpoint. ↗ CB §2 · U14 ↗ CB §10

Authentication / identity
(existing CaseMix credentials)

Existing CaseMix platform
users · roles · hospitals · clinical platform data

Standalone Breast Oncology System

DDAP workflow
primary care

DDAP2 workflow
secondary care

Referral workflows
DDAP → DDAP2 → POAP

Breast Oncology data

Figure 1 — Architectural objective.

Ref
Frontend React.js (TypeScript) SPA ↗ API §6.4
Backend Python (Flask) — module logic ported from the CaseMix .NET 6 / ABP 7 code ↗ CB §5 ↗ API §2
Database Existing CaseMix MySQL — no schema changes ↗ CB §8 ↗ CB §12
Estimated effort Lower: 140 hours · Upper: 180 hours
02

Scope against Codebase Brief §2

↗ CB §2 ↗ CB §2.1

2.1 Units of work — CB §2 table

CB §2 Unit Client description (CB §2) Existing source (CB §2 / §5) Our approach SOW §
U1 Authentication and session bootstrap Login, JWT handling, mandatory AbpUserConfiguration/GetAll Platform — API §3 Delegated CaseMix login via Python (Flask) BFF; JWT held server-side; GetAll for permissions + localised labels §5
U2 Hospital context and module gating Hospital selection; careSettingId + hasDiagnosticSpecialty decide DDAP 1 / DDAP 2 / neither 3.2 KB + platform call Hospitals/GetByUser; gating enforced server-side; name-match logic reproduced ↗ CB §8.4 §6
U3 Consent and subject-ID allocation Consent panel; 500-per-hospital pseudonymous registry; shared with POAP 3.2 KB + 4.4 KB Consent gate; transactional allocation with row locking ↗ CB §7.1 §7
U4 DDAP — Subject tab Six fields + postcode typeahead within 68.6 KB form React tab; postcode validation against postcodes table ↗ CB §11.2 §7
U5 DDAP — Risk 1 tab 9 keys, option bands, BP banding, air-quality lookup 68.6 KB form + 4.6 KB helper Option bands ported; AQI (OpenWeather + WAQI) replicated as built ↗ CB §9 §7
U6 DDAP — Risk 3 questionnaire 27 questions, 5 groups, conditional enable/disable, declarative 5.1 KB defs + 11.3 KB renderers Question model ported as data; one generic renderer ↗ CB §8.3 §7
U7 DDAP — Summary Finding tab Risk cohort and scanner result within 68.6 KB form Reproduced; no backend stamp ↗ CB §7.1 §7
U8 DDAP — Referral to Secondary Care Referral target list + the five database writes within 24.3 KB service Region/Trust candidates; five writes in one transaction ↗ CB §7.1 ↗ CB §11.2 §8
U9 DDAP2 — Subject and Risk 1 Same shape as U4/U5 on secondary-care tables; largely reuse within 89.7 KB form Reuse U4/U5 components against secondarydiagnostic* ↗ CB §7.2 §7
U10 DDAP2 — Risk 3 imaging questionnaires Largest unit. 23 panels: 5 stage-1 groups + mammography, biopsy, ultrasound × 3 stages × 2 sides 15.3 KB defs + 19.8 KB renderers + majority of 89.7 KB form One questionnaire engine; stage rules server-side; CIP upload-status read-only ↗ CB §4.2 ↗ CB §9 §7
U11 DDAP2 — Summary and Procedure Type Selection Screening results summary; surgical approach and sub-specialty 9.6 KB + within form Options filtered by BreastOncoSurgGroupId ↗ CB §8.4 §7
U12 DDAP2 — Refer to Surgical Pathway Write into POAP — boundary of the port within 21.4 KB service POAP Draft insert + transfer flag, one transaction ↗ CB §7.2 §8
U13 List pages (×2) Search, sort, paging, delete per generation 22.4 KB Both lists; DDAP2 delete follows existing (commented out) ↗ CB §5 ↗ CB §6 §7
U14 Authentication and authorisation in the new services New work. Authenticate caller, enforce Pages.Ddap / Pages.SecondaryDdap, scope every read/write to entitled hospitals new Deny-by-default middleware; hospital predicate in every query; end user's identity carried to CaseMix ↗ CB §10 §6
U15 Development environment and test data Local stack and the supplied copy of the UAT database see CB §12 Python/React/MySQL 8 local stack; Liquibase schema; UAT dump ↗ CB §12 §3

2.2 CB §2.1 — "The three items that will move your number most"

CB §2.1 item How this is handled Ref
1. Unit 10 — DDAP2 Risk 3 is ~60% of front-end work Scoped as its own unit — the largest in the module; one questionnaire engine for all 18 imaging panels ↗ CB §2.1 ↗ CB §2 · U10
2. Unit 8, and the postcode — candidates come from Region/Trust, no proximity Referral candidates from GetReferralHospitals(trustId, hospitalId); no proximity selection priced ↗ CB §2.1 ↗ CB §11.2
3. The platform writes — Patient, HospitalPatient, subject registry, POAP are real work Delivered in U3, U8 and U12 as real transactional writes; nothing stubbed ↗ CB §2.1 ↗ CB §7

2.3 Work beyond CB §2 — required by the standalone system

CB §2 describes the module. Running it as a separate system with a Python (Flask) backend and MFA adds the following, listed separately so it can be compared with the client's scope.

Item Why it is needed Ref
Architecture & Phase 1 validation Confirm integration points against the tag before build ↗ CB §13 New
2FA / MFA Security requirement of the standalone system New ↗ API §3
React frontend foundation Angular client is a reference only, not a starting point ↗ API §6.4 New
.NET 6 → Python port Backend stack decision (§3) ↗ CB §5 New
Backend / API core (Python) Shared service layer for U1–U14 ↗ CB §6
Database / data integration Mapping to module + platform tables ↗ CB §8 ↗ CB §9
Audit logging Standalone system needs its own audit trail New
AWS infrastructure CB scope runs locally only; a standalone system needs hosting ↗ CB §3 ↗ CB §12 New
CI/CD As above ↗ CB §3 New
Testing & QA Both acceptance scenarios + regression ↗ CB §11
Security testing Verifies U14 ↗ CB §10
UAT & deployment Release and handover New
03

Technology stack & Python backend

↗ CB §5 ↗ API §2 ↗ CB §2 · U15 ↗ CB §12

NEW — Breast Oncology

React.js SPA

Python API · Flask

Existing CaseMix MySQL
schema unchanged

PORT TO PYTHON

Translate C# / ABP logic
to Python services

SQLAlchemy +
MySQL driver

Server-side authorisation
+ hospital scoping

Parity tests vs
.NET 6 behaviour

EXISTING — CaseMix module · .NET 6 · ABP 7

DiagnosticAssessmentsAppService
DDAP

SecondaryDiagnosticAppService
DDAP2

PatientRegistryAppService
subject IDs

DTOs · entities
AppConsts

Figure 2 — Backend porting path.

  • Existing CaseMix Module backend is ABP 7.0 on .NET 6: DiagnosticAssessmentsAppService (24.3 KB), SecondaryDiagnosticAppService (21.4 KB), PatientRegistryAppService (4.4 KB). ↗ CB §5 ↗ API §2
  • Proposed Architecture Breast Oncology API in Python (Flask), re-implementing this logic; CaseMix platform stays on .NET 6 Assumption. New
  • Development environment (U15): Python 3 runtime, MySQL 8 with Liquibase from database/ddml/main.ddml.xml, UAT database dump; nothing hard-codes hostnames. ↗ CB §12 ↗ CB §3
Porting risk Mitigation Ref
C# / ABP 7 logic must be re-written, not upgraded Recommendation Port service-by-service; reproduce ABP tenant filter, soft delete and audit columns explicitly ↗ API §2 ↗ CB §9
SQLAlchemy / MySQL driver behaviour against the existing schema Validation Required Phase 1 spike ↗ CB §12
Data-format parity with .NET 6 reads (GUIDs, dates, timezone) Parity tests both directions ↗ CB §8.1 ↗ CB §9
Behaviour drift between C# and Python (rounding, dates, validation) Unit tests against current .NET 6 behaviour ↗ CB §5
Python package selection & security Dependency review and SCA scanning New
Two runtimes in operation Separate deployables; contract-level integration New
04

Architecture & system boundary

↗ CB §9 ↗ API §1 ↗ CB §3

HTTPS · session cookie

TokenAuth/Authenticate
AbpUserConfiguration/GetAll
Hospitals/GetByUser

least-privilege DB role

least-privilege DB role

least-privilege DB role

server-side keys

User — browser

React.js web application
CloudFront + S3

WAF → Application Load Balancer

Breast Oncology API
Python · Flask

Authentication
CaseMix identity integration

Authorisation service
permission + hospital scope

DDAP services

DDAP2 services

Referral services

Audit service

Existing CaseMix v1 API
.NET 6 · ABP 7

Existing CaseMix MySQL

BO security & audit store

OpenWeather / WAQI

Figure 3 — Proposed architecture.

Component Status Ref
CaseMix Angular UI, ABP v1 API (.NET 6), users / roles / hospitals Existing — integrated, unchanged ↗ API §1 ↗ CB §10
Patient, HospitalPatient, PatientSubjectIDRegistry, POAP Existing — written at consent / referral ↗ CB §9 ↗ CB §2.1
diagnostic*, secondarydiagnostic* tables Existing — read / write, schema unchanged ↗ CB §8.1
Configuration reads (SpecialtyInfo, SubSpecialtyInfo, BodyStructureGroup) Existing — reads in scope, screens not ↗ CB §9
Clinical Image Processing Existing — out of scope; DDAP2 reads its upload-status rows ↗ CB §9
React frontend, Python (Flask) API, security layer, audit, BO store New New
AWS environments, CI/CD New ↗ CB §3 New
05

Authentication, SSO & MFA

↗ CB §2 · U1 ↗ API §3 ↗ API §6.2

  • Existing CaseMix POST /api/TokenAuth/Authenticate → HS256 JWT, 24 h, no refresh, no revocation. ↗ API §3
  • Existing CaseMix GET /AbpUserConfiguration/GetAll is mandatory — permissions, settings and all localised labels. ↗ API §6.2 ↗ CB §8.3
  • Recommendation Delegated login via the Python (Flask) backend (BFF); JWT held server-side, KMS-encrypted; browser gets an HttpOnly cookie. Shared HS256 key rejected. ↗ CB §10
  • Proposed Architecture MFA (TOTP + recovery codes) after CaseMix validates the password. New
BO security storeCaseMix v1 APIBO backendBO frontendBO security storeCaseMix v1 APIBO backendBO frontendalt[Invalid credentials / locked / disabled][Success]UserCaseMix username / email +password1POST /api/v1/auth/login (TLS)2Rate-limit check (perIP + per username)3POST /api/TokenAuth/Authenticate4ABP error envelope5Audit LOGIN_FAILED6401 generic "sign-in failed"7accessToken, userId,expireInSeconds8GET/AbpUserConfiguration/GetAll(Bearer user token)9granted permissions, settings,localisation10Require Pages.Ddap orPages.SecondaryDdap11GET Hospitals/GetByUser12hospitals, careSettingId,hasDiagnosticSpecialty13Create pre-MFA session (token encrypted, KMS)14200 + mfaRequired /mfaEnrolmentRequired15User

Figure 4 — Login with existing CaseMix credentials (U1).

fail

ok

No — first login

Yes

Yes

No

< 5 attempts

≥ 5 attempts

Username + password

CaseMix validates credentials
(TokenAuth/Authenticate)

Sign-in failed · audited · throttled

MFA enrolled?

Enrolment: show TOTP QR
verify one code
issue 10 recovery codes

Request TOTP code

Full session issued

Code valid?
(±1 step window, not reused)

Attempt counter +1

Temporary lock (15 min) · audited · alert

Use recovery code

Figure 5 — Second factor (TOTP).

  • Sessions: 30 min idle / 12 h absolute; permissions re-validated every 15 min. ↗ API §3 New
  • Validation Required whether a disabled user's existing JWT is rejected by CaseMix. ↗ API §3
06

Authorisation, hospital context & gating

↗ CB §2 · U2 ↗ CB §2 · U14 ↗ CB §10 ↗ API §6.3

  • Existing CaseMix Clinical services have no server-side permission checks — authenticated = allowed. ↗ API §6.3
  • Client requirement (U14): authenticate the caller, enforce Pages.Ddap / Pages.SecondaryDdap, scope every read and write to entitled hospitals; carry the end user's identity into CaseMix calls. ↗ CB §2 · U14 ↗ CB §10
  • Gating (U2): DDAP needs Pages.Ddap + careSettingId = 1 + hasDiagnosticSpecialty; DDAP2 needs Pages.SecondaryDdap + careSettingId = 2 + the same flag. ↗ CB §10 ↗ CB §8.4

No

Yes

No

Yes

No

Yes

No

Yes

No

Yes

Incoming API request

Valid BO session
and MFA complete?

401 Unauthorized

Permission for endpoint?
Pages.Ddap / Pages.SecondaryDdap

403 Forbidden · audited

Selected hospital in user's
UserHospital entitlements?

Module gate for hospital?
DDAP: careSettingId=1 + diagnostic
DDAP2: careSettingId=2 + diagnostic

Record's owning hospital =
selected hospital?
(checked in the query)

404 Not Found · audited
(no existence disclosure)

Execute · audit if sensitive

Figure 6 — Server-side authorisation flow (U2 + U14).

Example: a Hospital A user editing an ID or hospital field to reach Hospital B data gets 403/404, audited. ↗ CB §10

07

DDAP & DDAP2 workflows

↗ CB §2 · U3–U7 ↗ CB §2 · U9–U11 ↗ CB §2 · U13 ↗ CB §4 ↗ CB §7

  • Existing CaseMix One tab-driven form per generation; each tab saves independently with a tab index; Consent gates all tabs. ↗ CB §4 ↗ CB §7

1 · Sign-in
CaseMix credentials + MFA

2 · Hospital & module access
careSettingId=1 · diagnostic · Pages.Ddap

DDAP list
(not yet transferred)

3 · Consent
gates all other tabs

4 · Subject ID allocated
{HospitalId}-NNNN

5 · Subject

6 · Risk 1

7 · Risk 3
Diagnostic Screening

8 · Summary Finding

9 · Referral to Secondary Care
Generate DDAP Stage 2 Draft

Record frozen
'DDAP data now frozen'

Figure 7 — DDAP (primary care): U3 → U4 → U5 → U6 → U7 → U8.

1 · Sign-in + MFA

2 · Hospital & module access
careSettingId=2 · diagnostic · Pages.SecondaryDdap

DDAP2 list
(not yet transferred to Pre-Op)

3 · Consent
(POAP consent endpoint)

4 · Subject

5 · Risk 1

6 · Risk 3

Diagnostic Screening
stage-1 answers · read-only

Screening (Mammogram)
Stage 1·2·3 × R·L

Biopsy
Stage 1·2·3 × R·L

Ultrasound
Stage 1·2·3 × R·L

7 · Summary Finding
screening results summary

8 · Procedure Type Selection
surgical approach · sub-specialty

9 · Refer to Surgical Pathway
→ POAP Draft

Record frozen

Figure 8 — DDAP2 (secondary care): U9 → U10 → U11 → U12.

Tab / feature Key behaviour reproduced CB unit Ref
Consent & subject ID Next of 500 IDs per clinic, {HospitalId}-0001; DDAP2 uses POAP consent U3 ↗ CB §7.1 ↗ CB §7.2
Subject 7 fields; Area Post Code typeahead U4 / U9 ↗ CB §4.1 ↗ CB §11.2
Risk 1 9 keys; BP banding; AQI stored U5 / U9 ↗ CB §8.3 ↗ CB §9
DDAP Risk 3 27 questions, 5 groups, declarative rules U6 ↗ CB §8.3
DDAP2 Risk 3 23 panels; stages unlock in order, never go backwards U10 ↗ CB §4.2 ↗ CB §7.2
Summary / Procedure Type Cohort & scanner result; surgical approach + sub-specialty U7 / U11 ↗ CB §7.1 ↗ CB §7.2
List pages Search, sort, paging, delete (DDAP) U13 ↗ CB §6
08

Referral & data transfer

↗ CB §2 · U8 ↗ CB §2 · U12 ↗ CB §2.1 ↗ CB §7 ↗ CB §11.2

  • A referral is a set of database writes, not a message; both run in one transaction. ↗ CB §7
  • Candidates come from the referring clinic's Region/Trust — no proximity selection. ↗ CB §11.2
AuditCaseMix AuroraMySQLAuthorisationBO backendBO frontendAuditCaseMix AuroraMySQLAuthorisationBO backendBO frontendPrimary careclinicianChoose Institution, Specialty,Sub-Specialty1POST /api/v1/ddap/{id}/referral2Pages.Ddap · hospital scope ·record owned · not frozen3allowed4Verify target ∈ GetReferralHospitals(trust, hospital)5BEGIN TRANSACTION61 · Allocate + mark subject ID at receiving institution(PatientSubjectIDRegistry)72 · If no Patient for that ID → INSERT Patient (gender, year ofbirth)83 · INSERT HospitalPatient link94 · INSERT secondarydiagnostic (demographics copied,surgery/anaesthesia risk rows copied, stages = 1,specialty = Breast Oncology)105 · UPDATE diagnosticassessments SETisDataTransferredToDdap2 = true11COMMIT12REFERRAL_CREATED (source id, target hospital, new ids)13200 · record now read-only14Primary careclinician

Figure 9 — DDAP → Secondary Care (U8).

AuditCaseMix AuroraMySQLAuthorisationBO backendBO frontendAuditCaseMix AuroraMySQLAuthorisationBO backendBO frontendPOAP record is thenworked in theexisting CaseMixplatformSecondary careclinicianRefer to Surgical Pathway —choose Institution1POST/api/v1/ddap2/{id}/surgical-referra-l2Pages.SecondaryDdap · hospital scope · owned · not frozenProcedure Type completed3allowed4BEGIN TRANSACTION5INSERT PreOperativeAssessment (status Draft):demographics, procedure, all risk rows copied,patient identifier suffixed /x6UPDATE secondarydiagnostic: transfer flag + timestamp7COMMIT8SURGICAL_REFERRAL_CREATED9200 · record now read-only10Secondary careclinician

Figure 10 — DDAP2 → Surgical Pathway / POAP (U12).

Created Copied Referenced Ref
Subject ID at receiving hospital, Patient (if absent), HospitalPatient, DDAP2 record, POAP Draft Demographics, risk rows, procedure DDAP Risk 3 (read by DDAP2), source link, transfer flags ↗ CB §7.1 ↗ CB §7.2
09

Data & API

↗ CB §6 ↗ CB §8 ↗ CB §9 ↗ API §4

Breast Oncology System

Existing CaseMix

Aurora MySQL

credentials (login only)

JWT (held server-side)

user JWT

user JWT

permissions · settings · labels

hospitals · gating flags

read / write

write on consent / referral

read

upload-status rows

TokenAuth/Authenticate

AbpUserConfiguration/GetAll

Hospitals/GetByUser

Module tables
diagnostic* · secondarydiagnostic*

Platform tables
Patient · HospitalPatient
SubjectIDRegistry · POAP

Reference & config
Hospital · Specialty · BodyStructure
SurgicalApproach · Ethnicity · Postcodes

Clinical Image Processing

BO API

BO store
MFA · sessions · audit

Figure 11 — Data flow between CaseMix and Breast Oncology.

  • [Recommendation] Hybrid: clinical data stays in existing CaseMix MySQL (least-privilege user, no DDL); small BO store for MFA, sessions, audit. ↗ CB §8 ↗ CB §9
  • Every answer remains a Group/Key/Value row; Breast Oncology constants reproduced exactly. ↗ CB §8.2 ↗ CB §8.4
API group (/api/v1) Replaces CaseMix endpoint(s) Permission Ref
auth/*, me TokenAuth/Authenticate, AbpUserConfiguration/GetAll, Hospitals/GetByUser (called, not replaced) Session ↗ API §3 ↗ CB §6
ddap/* DiagnosticAssessments/* Pages.Ddap ↗ CB §6
ddap2/* SecondaryDiagnostic/* Pages.SecondaryDdap ↗ CB §6
reference/* Ethnicities/GetAll, PostCodes/GetAll, Aqi/* Session ↗ CB §6
admin/*, audit/* — Admin Assumption New
10

Security & audit

↗ CB §10 ↗ API §6.3

Area Control Ref
Credentials & tokens No CaseMix passwords stored; JWT server-side, KMS-encrypted ↗ API §3
Authorisation Deny-by-default; hospital predicate in every query ↗ CB §10 ↗ CB §2 · U14
Web TLS 1.2+, HSTS, CSP, CSRF, SameSite=Strict, CORS allow-list ↗ API §1 New
Secrets Secrets Manager + KMS (DB, JWT, OpenWeather/WAQI keys) ↗ CB §9
Pseudonymity No names, national IDs or DOB; year of birth only ↗ CB §7.1
Audit Login, MFA, access denied, allocation, saves, referrals, admin — append-only New
Reference OWASP Top 10 — no certification claimed New
11

Infrastructure, CI/CD & NFRs

↗ CB §3 ↗ CB §12 ↗ API §1

  • Note: CB §3 scope gives no infrastructure, CI/CD or AWS access and runs locally. A standalone system needs hosting — Assumption TCC-CASEMIX provides an AWS account, network path and DB user. ↗ CB §3 ↗ CB §12

BO VPC — per environment

VPC peering / Transit Gateway
port 3306 · SG-restricted

Users

Route 53

CloudFront + ACM
WAF attached

S3 — SPA assets
(OAC, private)

Application Load Balancer
public subnets · ACM

ECS Fargate — BO API
private subnets · multi-AZ

BO store
RDS MySQL/PostgreSQL · KMS

NAT Gateway → HTTPS egress
CaseMix API · OpenWeather · WAQI

CaseMix Aurora MySQL
existing VPC

Secrets Manager

KMS

CloudWatch logs · metrics · alarms

Figure 12 — AWS deployment (Dev, UAT, Prod).

fail

Feature branch

Merge request
code review required

CI: Python + React build
tests · SAST · SCA · secrets

main

Auto-deploy → Dev
integration + API tests

Release tag

Deploy → UAT
smoke + security tests

Manual production
approval

Deploy → Prod
blue/green ECS

Smoke tests

Automatic rollback
previous task definition

Figure 13 — CI/CD (Python API + React SPA).

NFR Target Ref
Performance p95 < 500 ms tab load/save New
Availability 99.5% monthly, multi-AZ New
Hostnames Configuration-driven (Mumbai migration) ↗ CB §3
Backup / DR BO store daily + PITR; RPO 24 h / RTO 8 h Assumption New

Validation

Not authenticated / expired

Forbidden / out of scope

Conflict: frozen, stage regression,
consent missing, duplicate referral

CaseMix API unavailable / timeout

Air-quality API failure

DB error in referral

Unhandled

Exception raised

Type

400 problem+json
field errors

401 → frontend returns to login
unsaved tab data retained locally

403 or 404 · audited

409 with reason code

Retry ×2 with back-off (reads only)
→ 503 'CaseMix unavailable'

Save Risk 1 without AQI
flag for retry · warn user

ROLLBACK · 500 · REFERRAL_FAILED audited
source stays editable

500 generic message
full detail in logs with correlation ID · alarm

Figure 14 — Error & exception handling.

12

Testing

↗ CB §11 ↗ CB §12 ↗ CB §2 · U14

  • Acceptance scenario 1 — add a physician user, assign within Breast Oncology (Users/Create, UserHospitals/SaveAll, Roles/Update; role named Primary Care Practitioner). ↗ CB §11.1
  • Acceptance scenario 2 — referral to another institution in the same Region/Trust. ↗ CB §11.2
  • Unit · integration (tagged schema + UAT dump) · API · React E2E · MFA · authorisation matrix · .NET 6 ↔ Python parity · CaseMix regression · ZAP · UAT. ↗ CB §12
# Security test Expected Ref
S1 Hospital A user requests Hospital B record 404, audited ↗ CB §10
S2 Hospital ID changed in request Session scope applies ↗ CB §10
S3 Expired session 401 ↗ API §3
S4 Invalid / replayed TOTP Denied New
S5 Save to transferred record 409 ↗ CB §4
S6 Referral outside Trust candidates 403 ↗ CB §11.2
13

Risk register

# Risk P I Severity Mitigation Ref
1 .NET 6 → Python port — C# / ABP 7 logic re-written in Python H H High Port service-by-service with tests; Phase 1 spike ↗ CB §5 ↗ API §2
2 Data-format parity with CaseMix .NET 6 M H High Parity test suite ↗ CB §8
3 Unit 10 under-read — DDAP2 Risk 3 M H High Scoped as its own unit; one questionnaire engine ↗ CB §2.1 ↗ CB §2 · U10
4 Platform writes incomplete or stubbed M H High Transactional U3/U8/U12; UAT check ↗ CB §2.1 ↗ CB §7
5 Referral scope drift to proximity L M Low Region/Trust only ↗ CB §2.1 ↗ CB §11.2
6 CaseMix auth integration M H High Week-1 spike ↗ CB §2 · U1 ↗ API §3
7 JWT not revocable for 24 h M M Medium Server-side token; re-validation ↗ API §3
8 Authorisation gap copied into new services M H High Deny-by-default; coverage check ↗ CB §2 · U14 ↗ API §6.3
9 Schema still changing H M High Pin to tag; drift check ↗ CB §3
10 Configuration reads missed L H Medium Reads in scope from day one ↗ CB §9
11 SQLAlchemy / MySQL driver compatibility M M Medium Phase 1 validation ↗ CB §12
12 Hosting / infra access not in CB scope H H High Agree AWS + DB access in week 1 ↗ CB §3
13 CaseMix regression L H Medium No schema change; regression tests ↗ CB §8
14 Scope expansion M H High Change control (§15) ↗ CB §13
14

Assumptions, out of scope & acceptance

Assumptions

  • CaseMix login, GetAll and Hospitals/GetByUser reachable. ↗ API §3 ↗ CB §6
  • Code at the tag, UAT dump and swagger available; the tag is authoritative over UAT. ↗ CB §3 ↗ CB §12
  • CaseMix platform stays on .NET 6; AWS account, network path and MySQL user provided. ↗ CB §3 New
  • No open items remain on client scope. ↗ CB §13

Out of scope

  • DiagnosticReport stub. ↗ CB §5
  • Proximity referral selection. ↗ CB §2.1 ↗ CB §11.2
  • Clinical Image Processing / image upload. ↗ CB §9
  • Malta postcode fallback and air-quality averaging. ↗ CB §9
  • Configuration screens (reads only in scope). ↗ CB §9
  • tpv1 third-party API. ↗ API §6.1
  • CaseMix rewrite or platform-wide .NET upgrade; identity replacement; clinical AI; native apps; formal certification; external pen test; multi-region DR; 24/7 support. New

Acceptance criteria

# Criterion Ref
AC1 Sign-in with existing CaseMix credentials; no password stored ↗ CB §2 · U1
AC2 DDAP / DDAP2 tile shown only when gating conditions are met ↗ CB §2 · U2 ↗ CB §10
AC3 Server enforces Pages.Ddap / Pages.SecondaryDdap and hospital scope ↗ CB §2 · U14
AC4 Scenario 1: new physician in a Breast-Oncology role sees the DDAP tile and clinician list ↗ CB §11.1
AC5 Scenario 2: referral to a same-Trust institution creates the downstream records ↗ CB §11.2 ↗ CB §2 · U8
AC6 DDAP (U3–U7) and DDAP2 (U9–U11, all 23 panels) complete end-to-end ↗ CB §2
AC7 Surgical-pathway referral creates a POAP Draft ↗ CB §2 · U12
AC8 Both list pages work ↗ CB §2 · U13
AC9 Records written by the Python API load correctly in CaseMix, and vice versa New
AC10 MFA works; no open critical/high defects at UAT sign-off New
15

Change control & summary

↗ CB §13

Changes to clinical workflow, questions, authentication design, MFA scope, database architecture, a platform-wide .NET upgrade, new integrations, reports, roles or modules are assessed and estimated before work starts. Anything that looks different from CB once we have the code is raised before it is estimated, as CB §13 asks. ↗ CB §13
Project Standalone Breast Oncology System integrated with CaseMix authentication
Stack React.js · Python (Flask) · existing MySQL
Scope CB §2 units U1–U15 + standalone additions (§2.3)
Estimated effort Lower: 140 hours · Upper: 180 hours

Prepared by Kretoss Technology for TCC-CASEMIX under the mutual NDA. Client references (CB, API) point to CaseMix — working with the codebase v3 and CaseMix API v1.2. Confidential.

A standalone Breast Oncology system, built on CaseMix identity.

DDAP and DDAP2 delivered as a separate, secured application — users keep their CaseMix credentials, every request is authorised server-side and scoped to the user's hospital, and referrals continue to create the records CaseMix depends on.

Prepared by Kretoss Technology · v1.3 · 26 September 2026 · Confidential
Overview Milestones Notes
Milestone Plan Version Control 2 · V.2

Breast Oncology System → 6 milestones, 110 hours

DDAP and DDAP2 delivered as a standalone application on CaseMix identity — planned milestone by milestone, with hours for each.

110
Total hours
6
Milestones
01

Overview

FrontendReact.js
BackendPython (Flask)
DatabaseMySQL (existing)
LoginCaseMix credentials + MFA
M1 Setup
→
M2 Auth & Security
→
M3 DDAP
→
M4 DDAP2
→
M5 Referral
→
M6 Testing & UAT
02

Milestones & hours

M112 h

Setup & architecture

  • Local environment & UAT data
  • Python (Flask) API + React app skeleton
  • Integration design confirmed
M220 h

Authentication & security

  • Login with CaseMix credentials
  • MFA (authenticator app)
  • Role & hospital-level access
M322 h

DDAP — primary care

  • Consent & subject ID
  • Subject, Risk 1, Risk 3, Summary
  • DDAP list page
M430 h

DDAP2 — secondary care

  • Subject & Risk 1
  • Risk 3 — screening, biopsy, ultrasound (3 stages × R/L)
  • Summary, Procedure Type, list page
M514 h

Referral & integration

  • DDAP → secondary care
  • DDAP2 → surgical pathway (POAP)
  • Records read-only after transfer
M612 h

Testing, UAT & deployment

  • Functional & security testing
  • UAT support & fixes
  • Deployment & handover
MilestoneScopeHours
M1 Setup & architectureEnvironment, skeleton, integration design12 h
M2 Authentication & securityCaseMix login, MFA, access control20 h
M3 DDAPPrimary care workflow + list22 h
M4 DDAP2Secondary care workflow + list30 h
M5 Referral & integrationBoth referrals, data transfer14 h
M6 Testing, UAT & deploymentTesting, UAT, go-live12 h
Total110 h
03

Notes

  • AI-assisted development; all code reviewed and tested.
  • CaseMix code, UAT database copy, test users and environment access provided at start.
  • Existing MySQL database reused with no schema changes.
  • Delivery depends on timely review and UAT feedback; scope changes are estimated separately.

110 hours · 6 milestones.

Each milestone ends with a working, reviewable result, so progress can be checked milestone by milestone.

Prepared by Kretoss Technology · September 2026 · Confidential
Summary Scope Configurator PDF Effort Commercial
Work Package · Proposal / SOW

HRIPT Reporting Module → reports, analytics & multi-page PDF

Implementation of the HRIPT reporting screens described on pages 17–19 of the HRIPT Module Functional Brief (v0.55): the subject-level HRIPT Report, the Analytics Report / Report Configurator and the multi-page printable PDF — built on top of the existing CaseMix reporting and PDF code.

~40
Total hours
5–7
Working days
3
Scope areas
11
WBS items
01

Executive summary

A focused, standalone work package that adds HRIPT reporting to the existing CaseMix platform.

This proposal covers the reporting requirements defined in the HRIPT Module Functional Brief (v0.55), pages 17–19. Users will be able to open Reports, generate an HRIPT Report for a selected subject, build an Analytics Report using the Report Configurator (Region, Sub-Region, Institution and criteria), produce the HRIPT Enrolment Progress Report by month or week, and print / download the result as a multi-page PDF.

The estimate of ~40 hours assumes the existing CaseMix reporting screens, query patterns, authorization and PDF engine are reused and extended — no new analytics engine, reporting framework or PDF technology is introduced.

Functional BriefRequirement taken from the Functional Brief ProposedOur implementation approach Reuse existingExisting CaseMix functionality reused Client confirmationAssumption / rule to be confirmed
02

Scope of work

Three delivery areas, each traceable to a page of the Functional Brief.

A · FB p.17

HRIPT Report

  • Reports menu → HRIPT Report
  • Subject selection
  • “Generate HRIPT Report” action
  • Subject-level report view
  • Print / PDF output
B · FB p.18

Analytics Report – Report Configurator

  • Region → Sub-Region → Institution
  • Analytics criteria selection
  • HRIPT Enrolment Progress Report
  • Reporting Period (Month / Week)
  • Results display & export
C · FB p.19

Multi-page PDF report

  • Institution, test, device, batch
  • Subject, phenotype, ethnicity, skin type
  • Visits, dermal response, analytics
  • Header / footer, page breaks
  • Print-friendly layout
03

HRIPT Report workflow

Functional Brief p.17 The Reports area offers HRIPT Report and Analytics Report. The HRIPT Report is generated for one selected subject.

Reports
→
HRIPT Report
→
Select subject
→
Generate HRIPT Report
#StepWhat happensBasis
1Open ReportsUser opens the Reports menu in CaseMix.FB
2Choose HRIPT ReportOption shown alongside Analytics Report.FB
3Load subject listOnly subjects the user is authorised to see (role / institution scope).Reuse
4Select subjectSearch / pick a single HRIPT subject.FB
5Generate HRIPT ReportUser clicks the “Generate HRIPT Report” button.FB
6Server-side checksBackend re-validates access to the subject before reading any data.Proposed
7Gather report dataSubject, visits, dermal response and related HRIPT data read from existing tables.Reuse
8Display reportReport shown on screen in the agreed layout.Proposed
9Print / download PDFMulti-page PDF produced through the existing PDF engine (see §08).Reuse
04

Analytics Report – Report Configurator

Functional Brief p.18 A configurator screen that narrows the data set by geography and criteria, plus the HRIPT Enrolment Progress Report.

Configurator fields

  • Region — top-level filter
  • Sub-Region — dependent on Region
  • Institution — dependent on Sub-Region
  • Analytics Report — criteria selection
  • HRIPT Enrolment Progress Report — Reporting Period (Month), Reporting Period (Week), “Generate Progress Report”

Analytics criteria

  1. Subjects with Dermal Response > 0, shown with the associated Fitzpatrick skin type
  2. Subjects with any identified Adverse Events (AEs)
  3. AEs correlated to Concomitant Medications
  4. Subjects with negative well-being assessments
Approach

Each criterion is implemented as a filter over data already captured by the HRIPT module. The exact definition of “correlated” AEs and “negative” well-being follows the existing data model Client confirmation required.

05

Report Configurator workflow

End-to-end report-generation flow. Every selection made in the browser is re-validated and authorised on the server.

01User
02Reports
03Analytics Report
04Region
05Sub-Region
06Institution
07Criteria
08Period
09Validate & authorise
10Query data
11Results
12Display
13PDF / Print
Browser (UI)Server (backend)Output
UICascading dropdowns: Sub-Region list depends on Region, Institution list depends on Sub-Region — lists only contain what the user may access.
ServerRequest validated: mandatory fields, valid combinations, period format, and that the user is authorised for the selected Region / Sub-Region / Institution.
QueryParameterised query against existing HRIPT data, restricted to the authorised scope; results returned to UI and to the PDF generator.
06

Analytics data filtering

Analytics are filters over existing data — not a new analytics engine.

PrincipleHow it is applied
Query existing dataResults come from data already captured in HRIPT visits, dermal response, AEs, concomitant medications and well-being assessments.
No hard-codingRegions, sub-regions, institutions and lookup values (e.g. Fitzpatrick type) are read from the database, never hard-coded in the UI.
No new analyticsNo statistical models, scoring or dashboards beyond the four criteria in the Functional Brief.
Combined filtersGeography + criteria + period are applied together on the server, inside the user’s authorised scope.
Consistent resultsThe same query output feeds the on-screen results and the PDF, so both always match.
07

HRIPT Enrolment Progress Report

Functional Brief p.18 Enrolment progress for the selected scope, by month or by week.

Region / Sub-Region / Institution
→
Reporting Period (Month) or (Week)
→
Generate Progress Report
ItemApproachStatus
Reporting Period (Month)Calendar month selectionFB
Reporting Period (Week)Week selection; week start day follows the existing systemConfirm
What counts as “enrolled”Existing-system ruleClient confirmation required
Progress measures shownExisting-system rule (e.g. enrolled / completed / withdrawn, if defined)Client confirmation required
Targets / expected enrolmentShown only if already stored in the systemClient confirmation required
08

Multi-page PDF report

Functional Brief p.19 A printable, multi-page report produced with the existing CaseMix PDF engine Reuse existing.

HEADER · Report title · Institution · Date
StudyInstitution · Test · Medical Device · Batch
SubjectSubject info · Phenotype · Ethnicity · Skin type
Health & responseHealth / response information
— page break —
VisitsVisit information · Dermal response table
AnalyticsAnalytics data for the subject / scope
FOOTER · Page X of Y · Generated by / on

Layout features

  • Repeating header and footer with page numbers
  • Report title and generation details
  • Structured tables; table headers repeat across pages
  • Controlled page breaks — no split rows or orphan headings
  • Print-friendly (A4, readable fonts, black & white safe)
  • Same data as on screen — generated server-side

Illustrative page structure based on Functional Brief p.19 — final layout follows the Brief’s example.

09

Existing reporting code reuse

Reuse is the key assumption behind the 40-hour estimate.

  1. Reuse the existing Reports menu and report page layout / navigation.
  2. Reuse existing report screen components (dropdowns, grids, buttons, loaders).
  3. Reuse existing data-access and query patterns already used by other CaseMix reports.
  4. Reuse the existing PDF generation engine and its templates / styles.
  5. Reuse the existing authentication, roles and permission checks.
  6. Reuse existing lookup / reference data (Region, Sub-Region, Institution, skin type).
  7. Reuse existing logging and error-handling conventions.
Important

The first 3 hours (WBS item 1) confirm these reuse points in the code. If a required component does not exist or cannot be reused, the impact on effort will be raised with the client before work continues.

10

Report API / backend

Proposed · illustrative only Indicative endpoints — these are not claimed to exist today. Final names follow the existing CaseMix API conventions.

MethodEndpoint (illustrative)Purpose
GET/reports/hript/{subjectId}HRIPT Report data for one authorised subject
POST/reports/hript/analyticsAnalytics Report: Region, Sub-Region, Institution, criteria
POST/reports/hript/progressEnrolment Progress Report for a month or week
POST/reports/hript/pdfGenerate the multi-page PDF for a report request

Each endpoint: validates input → checks authorization → runs a parameterised query → returns data (or a PDF file). No business rules live only in the browser.

11

Security & authorization

Hiding options in the UI is not security — every request is checked on the server.

RuleA user must not be able to change a Subject, Institution or Region ID in the request to see data outside their permitted scope.
BackendServer checks the user’s role and institution scope for every report, analytics query and PDF request — out-of-scope requests are rejected.
ReuseExisting CaseMix authentication and permission model is reused; no new identity or role system.
DataParameterised queries only; PDFs are generated on request and not stored publicly.
12

Audit logging

Where the existing platform supports it, report activity is logged with the current audit mechanism Reuse existing.

EventLogged details (where supported)
HRIPT Report generatedUser, date/time, subject
Analytics / Progress Report runUser, date/time, selected filters and period
PDF downloaded / printedUser, date/time, report type
Access deniedUser, date/time, requested scope

No new audit framework is built as part of this package.

13

UI components

Reports menu entriesHRIPT Report pageSubject search / selectorGenerate HRIPT Report button Analytics Report pageRegion dropdownSub-Region dropdownInstitution dropdown Criteria selectorReporting Period (Month)Reporting Period (Week)Generate Progress Report button Results tableLoading indicatorEmpty-state messageValidation messagesPrint / Download PDF
14

Effort estimate — WBS

Approximately 40 hours in total. Report Configurator and Multi-page PDF work items are highlighted separately.

#Work itemArea
1Existing reporting code review & technical analysisFoundation
2HRIPT Report UI and subject selectionA · HRIPT Report
3HRIPT Report data/API integrationA · HRIPT Report
4Analytics Report / Report Configurator UIB · Configurator
5Analytics filtering & backend integrationB · Configurator
6HRIPT Enrolment Progress ReportB · Progress
7Multi-page PDF report implementationC · PDF
8Existing report/PDF code adaptationC · PDF
9Security/authorization integrationCross-cutting
10Testing, bug fixing & report validationQuality
11UAT support / final adjustmentsQuality
TOTAL ESTIMATE~40 hours
15

Deliverables

  1. HRIPT Report option in the Reports menu
  2. HRIPT Report page with subject selection
  3. “Generate HRIPT Report” function
  4. Analytics Report / Report Configurator screen
  5. Region, Sub-Region and Institution cascading filters
  6. Four analytics criteria filters
  7. HRIPT Enrolment Progress Report (Month / Week)
  8. Multi-page printable PDF report
  9. Backend report endpoints with server-side validation
  10. Server-side authorization on all report requests
  11. Audit logging of report activity (where supported)
  12. Error handling and user messages
  13. Tested build deployed to UAT
  14. Short handover notes and test summary
16

Out of scope

  • Patient Diary functionality shown on pages 20–21 is outside the scope of this Reporting Module.
  • New analytics, statistics, dashboards or charts beyond the Functional Brief criteria.
  • Changes to HRIPT data capture screens or the database model.
  • A new PDF engine, reporting framework or audit framework.
  • New roles, permission model or authentication changes.
  • Excel / CSV export, scheduled or emailed reports (unless already available).
  • Production deployment, data migration and data correction.
17

Assumptions

  • The HRIPT data needed for the reports already exists and is captured by the HRIPT module.
  • Existing reporting screens, query patterns and PDF engine can be reused (see §09).
  • Region, Sub-Region and Institution hierarchy is already maintained in the system.
  • Enrolment-progress rules not defined in the Brief follow existing-system rules or are confirmed by the client.
  • PDF layout follows the Functional Brief p.19 example; major layout redesign is not included.
  • Source code, UAT environment, realistic test data and test users are available at start.
  • Client feedback and UAT sign-off are provided within the 5–7 day window.
18

Risks

RiskImpactMitigation
Existing reporting / PDF code cannot be reused as expectedHigher effortConfirmed in WBS item 1; impact raised before continuing
Enrolment-progress rules not definedRework of Progress ReportUse existing-system rule; confirm with client on Day 1–2
Analytics criteria definitions unclear (correlated AEs, negative well-being)Incorrect resultsConfirm definitions against the data model early
Insufficient UAT test dataReports cannot be fully validatedClient provides representative test data at start
Complex PDF layout / page-break behaviourExtra PDF effortFollow Brief p.19 layout; agree sample early
Slow queries on large data setsPoor report response timeScoped, parameterised queries; use existing indexes
19

Acceptance criteria

  1. An authorised user can generate the HRIPT Report for a selected subject.
  2. The Report Configurator filters correctly by Region, Sub-Region and Institution.
  3. Each of the four analytics criteria returns results that match the source data.
  4. The Enrolment Progress Report runs by month and by week using the agreed rules.
  5. The multi-page PDF contains the p.19 content with correct header/footer, tables and page breaks.
  6. On-screen results and PDF output match.
  7. Users cannot access data outside their authorised scope, including by changing IDs in requests.
  8. Validation, no-data and error cases show clear messages.
  9. The module is verified on UAT and signed off by the client.
20

Commercial summary

ProjectHRIPT Reporting Module
Estimated effort~40 hours
Estimated duration~5–7 working days
Primary deliverablesHRIPT Report, Analytics Report / Report Configurator, HRIPT Enrolment Progress Report, multi-page PDF report
Reuse approachExisting CaseMix reporting screens, query patterns, authorization and PDF engine are reused and extended
Important noteThe estimate depends on reuse of existing reporting / PDF code and on confirmation of rules not defined in the Functional Brief. Patient Diary (pp. 20–21) is excluded.

~40 hours · 5–7 working days · 3 reporting areas.

Built on the existing CaseMix reporting and PDF code, with server-side security on every report.

Prepared by Kretoss Technology · October 2026 · Confidential