1
Sensitivity: Internal
Individual Report Template
4CM506
<100785312>
Important Note on Report Submission:
• Students must follow the provided report template when completing CW2.
• Students must not use their own format or template for CW2.
• If you do not wish to answer a section or question in the template, simply leave it blank.
Do not remove the corresponding section or question.
Guidance for Completing the Template:
• Pay attention to notes provided in each section. These notes are meant to guide your
responses and should be considered carefully.
• Replace sample figures and captions with your own. Any figure provided in the
template is only an example. You must insert a figure relevant to the specific question
or section and update the caption accordingly.
• Table of Figures: Ensure that all figures included in your report are listed in a Table of
Figures with accurate captions.
Academic Integrity Declaration:
I hereby certify that this work is entirely written and/or drawn by myself and that no sections of this
work are taken verbatim from an AI model or other source that would be classed as academic
plagiarism. I agree that if my tutor has concerns about this, the work will be viva’d to verify that this
piece is my own original work.
2
Sensitivity: Internal
Table of Contents
Table of Figures ....................................................................................................................................... 4
Requirements and data........................................................................................................................... 5
Executive Summary ............................................................................................................................. 5
Explicit user requirements .................................................................................................................. 5
Implicit user requirements .................................................................................................................. 5
Domain requirements ......................................................................................................................... 7
Requirement justification ................................................................................................................... 7
Application architecture ..................................................................................................................... 8
Data model design .............................................................................................................................. 9
Data model justification and validation .............................................................................................. 9
Sample data set ................................................................................................................................. 11
Data and Workflows ............................................................................................................................. 12
Workflows ......................................................................................................................................... 12
Patient application workflow ........................................................................................................ 12
Medical professional application workflow .................................................................................. 13
Server-side application workflow ................................................................................................. 14
Dataflows .......................................................................................................................................... 15
Patient application data flow ........................................................................................................ 15
Medical professional application .................................................................................................. 16
Server-side application workflow ................................................................................................. 17
Server-side database structure ..................................................................................................... 18
• Visualisations: ............................................................................................................................... 19
Interface visualisations ..................................................................................................................... 19
Medical professional application interface................................................................................... 19
Patient application interface ......................................................................................................... 20
Dataset visualisations ....................................................................................................................... 21
Medical professional dataset view 1 ............................................................................................ 21
Medical professional dataset view 2 ............................................................................................ 22
Patient dataset view 1 .................................................................................................................. 23
Patient dataset view 2 .................................................................................................................. 24
Identification of issues .......................................................................................................................... 25
Legal issue 1 ...................................................................................................................................... 25
Legal issue 2 ...................................................................................................................................... 25
Usability issue 1 ................................................................................................................................ 25
3
Sensitivity: Internal
Usability issue 2 ................................................................................................................................ 25
Risk Register ...................................................................................................................................... 25
4
Sensitivity: Internal
Table of Figures
Figure 1: Application architecture .......................................................................................................... 8
Figure 2: Data model design ................................................................................................................... 9
Figure 3: Sample data set ...................................................................................................................... 11
Figure 4: Patient application workflow ................................................................................................. 12
Figure 5: Medical professional application workflow ........................................................................... 13
Figure 6: Server-side application workflow .......................................................................................... 14
Figure 7: Patient application data flow ................................................................................................. 15
Figure 8: Medical professional application data flow ........................................................................... 16
Figure 9: Server-side application data flow .......................................................................................... 17
Figure 10: Server-side database structure ............................................................................................ 18
Figure 11: Medical professional application interface.......................................................................... 19
Figure 12: Patient application interface................................................................................................ 20
Figure 13: Medical professional dataset view 1 ................................................................................... 21
Figure 14: Medical professional dataset view 2 ................................................................................... 22
Figure 15: Patient dataset view 1 ......................................................................................................... 23
Figure 16: Patient dataset view 2 ......................................................................................................... 24
5
Sensitivity: Internal
Requirements and data
Executive Summary
The NHS patient logbook application is a digital tool that will make records of patient’s medical
records, manage appointments and actively engage with prescribed treatment plans. The application
will empower patients and NHS care by enabling secure tracking of health data between visits. The
application will also keep a track of symptoms, medications and appointments.
The core benefits of the application are:
• Primary health record access (view medical records).
• Appointment management (book, view and cancel).
• Prescription ordering (order repeat prescriptions with direct delivery to a chosen pharmacy).
• Notifications (receive messages and notifications for upcoming appointments).
Explicit user requirements
1. User Authentication – Secure login using NHS number, password, and two-factor
authentication (2FA).
2. User Management – User can view medical records, test results, upcoming appointments
and be able to manage them (book, view or cancel).
3. Notifications – The system sends alert messages for test results and upcoming
appointments.
4. Data Storage – The application should store users’ details in a database. Ensures persistence
of data, preventing loss when the app is closed or the device restarts.
5. Cross-Platform Support – The app must run on both mobile (iOS/Android) and desktop
(Windows/MacOS).
6. Encryption – Data should be encrypted for protection of personal information.
Implicit user requirements
1. User Expectations:
• Easy to navigate interface with clear instructions.
• Secure login using NHS number, password and two-factor authentication (2FA).
Users expect a simple and fast experience, meaning the interface should be easy to navigate,
and actions like adding an appointment or checking a medical record result should be
seamless.
2. Cultural and Social Expectations:
• The app should support multiple languages.
• Consideration of accessibility (e.g., screen readers for visually impaired users).
Support for multiple languages and accessibility features ensures inclusion for diverse users.
3. Context:
• The app should be available 24/7.
• Connected with NHS 111 in case of emergency.
The app must be accessible 24/7, requiring integration with external NHS 111 services.
6
Sensitivity: Internal
4. Industry Standards and Regulations:
• Compliance with data protection laws (e.g., GDPR).
Compliance with privacy laws (e.g., GDPR) ensures that users’ personal data is handled
securely.
5. Technical Constrains:
• Support for various devices and web browsers.
The app must run efficiently on devices with various processing power and screen sizes.
6. User Experience Standards:
• Quick response time.
Fast response time and an intuitive design increase user satisfaction.
7. Performance:
• The app should handle quick access without delay.
The app should handle users’ medical records and appointments without delays.
8. Scalability:
• Ability to store an increasing amount of data such efficiently.
Future updates should support additional features without affecting performance.
9. Security:
• Encrypt stored contact data to protect privacy.
• Implement two-factor authentication (2FA) for login.
Storing encrypted data prevents unauthorized access and safeguards users’ private
information.
10. Reliability:
• Ensure data consistency, even during app crashes.
Users must trust that their data will not be lost, even in case of crashes or data corruption.
11. Portability:
• Seamless transition between mobile and desktop version.
Seamless transition between desktop and mobile versions improve accessibility.
12. Maintainability:
• Easy updates and bug fixes.
Frequent updates should be easy to implement without disturbing user experience.
13. Flexibility:
• Allow integration with third-party apps (e.g., email, calendar)
7
Sensitivity: Internal
The app should allow API integrations with calendar app and email clients.
14. Reusability:
• Use of reusable components for similar medical applications.
Modular design allows for reusing NHS medical data in other private medical facilities.
Domain requirements
The NHS application operates within a highly regulated healthcare domain where security,
trust and legal compliance is critical. As a public-facing digital health service, its domain
requirements must ensure safe access to sensitive patient data while maintaining high availability
and interoperability with existing NHS systems.
• Explicit Requirements: NHS domain, HTTPS encryption, NHS login integration, UK
GDPR compliance.
• Implicit Requirements: User trust, data confidentiality, system reliability, protection
from phishing and cyber threats.
Requirement justification
Explicit Requirements – these are the features and functions directly requested by stakeholders:
• User Authentication: Users must be able to securely proof their identity (e.g., two-factor
authentication (2FA) login) to access personal records.
• User Management: The ability to book, view or cancel appointments, and view medical
records.
• Accessibility: To ensure the app is usable by people with disabilities.
• Data Portability: Integration with personal health records to allow data to flow between
different healthcare providers.
Implicit Requirements – users assume these will exist without having to ask for them. If these are
missing, the app will fail to gain trust:
• Data Privacy: Users implicitly expect that their medical data will never be sold to third
parties and will be handled according to GDPR.
• High Availability: The app is expected to have 99.9% uptime. The app should not be “down
for maintenance” during peak morning hours when the medical appointment slots are open.
• Performance: The app should load quickly even on older smartphones or slower mobile data
(3G/4G).
• User Interface: The app should “feel” like an official NHS service, using the standard NHS
design system to provide a sense of authority.
Domain Requirements – these are requirements derived from the healthcare industry itself. They
are dedicated by law, medical ethics, and clinical safety standards:
8
Sensitivity: Internal
• Clinical Safety: The app must comply with UK standards for managing clinical risk in health IT
systems to ensure the software doesn’t cause patient harm.
• Information Governance: Alignment with the national data opt-out policy, allowing patients
to choose how their data is used for research and planning purposes.
• Terminology Standards: Medical data must be coded so that information is interoperable
across different hospital systems.
• Security Standards: Compliance with the data security and protection toolkit.
Application architecture
Layered Architecture Pattern (N-Tier Architecture):
1. Presentation Layer:
• This is the user interface where the user interacts with the system
• Components: Mobile app (iOS/Android) and Web portal (Windows/MacOS)
• Security: Handles session management and login integration.
2. Application Layer:
• This layer acts like a bridge that passes information between Presentation layer and
Data layer.
• Coordinating tasks, handling API requests from the Presentation layer, and
managing the flow of data between the UI and the core logic.
3. Business Layer:
• It processes the rules and logic to decide what should happen based on the user’s
input.
• Involves the actual operations and rules that define how the system should process
data, make decisions, and achieve goals specific to business.
• This layer processes the data received from the Presentation layer, applies the
business rules, and makes decisions based on the application’s functionality. It then
communicates with the Application layer or Data layer for further actions.
4. Data Layer:
• This is where the data is stored and managed.
• This layer interacts with the database to retrieve, store, and manage data.
Presentation Layer
Application Layer
Business Layer
Data Layer
9
Sensitivity: Internal
Data model design
Relationship
Type
Logic
Patient – Appointment
1: N (One-to-Many)
One patient can have many appointments.
Patient – Prescription
1: N (One-to-Many)
One patient can be prescribed multiple medications.
Patient – Medical Record
1: N (One-to-Many)
One patient has many records over time.
Data model justification and validation
Data model justification:
1. Normalization & Integrity: By separating the data into four distinct tables, we follow Third
Normal Form (3NF):
• Reduced Redundancy: Patient details (like phone number) are stored once. If a patient
changes their phone number, you update it in one place rather that in every single
appointment or prescription record.
Patients
• NHS number
• Name
• Date of birth
• Phone number
Appointments
• NHS Number
• Date
• Time
• Status
10
Sensitivity: Internal
• Referential Integrity: By using NHS number as a foreign key in all tables, we ensure that
no prescriptions or records can exist without being attached to a valid patient.
2. Clinical safety & accuracy:
• The NHS number: Using this as a unique identifier is a critical safety feature. It allows for
interoperability with other UK healthcare systems and prevents “patient mismatching”.
• Prescription/Medical record: Linking prescriptions to a medical record ensures there is
clinical justification for every drug issued – an essential requirement for medical
auditing.
3. Scalability:
• This model allows for growth. Because relationships are one-to-many (1: N), a patient
can have 10 years’ worth of medical history and thousands of prescriptions without the
database structure needing to change.
Validation:
1. Technical validation – Validation against third normal form (3NF) ensures the database is
efficient and prevents data anomalies.
• 1
st
normal form: Each attribute (name, date, dosage) cotains a single value.
• 2
nd
normal form: All non-key attributes (like notes or status) depend entirely on the
primary key (NHS number).
• 3
rd
normal form: There are no “hidden” relationship. For example, Medication depends
on the Prescription, not on the Patient name.
2. Functional validation:
• The system looks up the Patients table to find the Id number. It then creates a new entry
in the Appointments table linked by that Id.
• The system looks at the prescriptions table. Using the date, it can cross-reference the
medical records table for that same date and patient.
• The pharmacist takes the Patient Id from Prescriptions table and joins it to the Patients
table to retrieve the phone number.
3. Constraints & business logic validation:
• NHS number: Validate that no two patients can have the same NHS number.
• Date validation:
- Patients date of birth must be in past
- Appointments date should generally be in the future.
• Status enumeration: The status field in Appointments should be restricted to a specific
list to ensure clean reporting.
11
Sensitivity: Internal
Sample data set
Patient Name (text, 512)
John Smith
Age (integer, 32 bit)
45
Address (text, 512)
10 Main Street, Leicester
NHS Number (integer, 32 bit)
712-555-1211
Phone Number (integer, 32 bit)
07759555111
12
Sensitivity: Internal
Data and Workflows
Workflows
Patient application workflow
Open NHS App
NHS
Login
Home Screen / Select
Service
New User
Returning User
Book Appointment
Order Prescription
Confirm / Manage
Select & Send to
Pharmacy
View Medical Record
Access & Read
End-to-End
13
Sensitivity: Internal
Medical professional application workflow
GP / Clinician Admin / Other Stuff
Professional Login
Verify
Role
GP, Nurse
Admin
Review / Action Tasks
Update Medical
Records & Refer
Initiate Consultation
Manage Appointments
Access Patient Record
Handle patient Queries
Manage Appointments
Generate Reports
End-to-End
14
Sensitivity: Internal
Server-side application workflow
Invalid Valid
Client sends request
Server receive request
Parse request data
Business Logic Processing
Input
Validation
Prepare Database Query
Database Interaction
Format Server Response
Return Error Response
Input Sanitisation
15
Sensitivity: Internal
Dataflows
Patient application data flow
Design Justification:
• Mobile: Focus on user models
• Offline Access: Health data caching
• Security: Explict sync process, encrypted user data
• Scalability: Modular design
• Clarity: Clear data flow, colour-coated components
User Authentication
Order Repeat
Prescription
View & Book
Appointments
Data Stores
User Data (Encrypted)
Order Repeat
Prescription
Cached Health Data
Medical Records &
Results
Authentication
Server
Backend
Server
Secure Data
Synchronization
16
Sensitivity: Internal
Medical professional application
Design Justification:
• Security: Robust authentication, encrypted data
• Offline Access: Cached data for continuity
• Modular: Clear duller design
• Clarity: Colour coated components, simple arrows
User Authentication &
Profile Management
Access Patient Records
Access Patient Records
(Summary/Full)
Data Stores
User Data (Encrypted)
Manage Appointments
(Book/Reschedule)
Generate Data (Offline
Access)
Handle Patient Queries
& Messages
Authentication
Server
NHS
Backend
Server
Secure Data
Synchronization
17
Sensitivity: Internal
Server-side application workflow
Server Application
Design Justification:
• Security: First before processing
• Reliability: Handles errors
• Database: Separate for data Database
Process Data & Interact
Database
Business Logic
Business Logic Data
Storage
Send Success Response
Database
Client
App
Receive Data
(Encrypted)
Authenticate &
Validate Input
Client
App
Send Error Response
18
Sensitivity: Internal
Server-side database structure
Design Justification:
• Relational: Clear relationships (Foreign Key)
• Data Integrity: Constrains (Unique, Foreign Key)
• Security: Encrypted history, logs
• Simple Structure: Easy to read
Patients
NHS Number (Foreign Key)
Name
Date Of Birth
Contact Info
Clinicians/Stuff
Stuff ID
Name
Department ID
Contact Info
Medical Records
Record ID
Patient NHS Number (Foreign Key)
Diagnosis Code
Treatment Notes (Encrypted)
Appointments
Appointment ID
Patient NHS Number (Foreign Key)
Date & Time
Location
19
Sensitivity: Internal
• Visualisations:
Interface visualisations
Medical professional application interface
Design Justification:
• Simple Navigation
• Key Tasks First
• Mobile-Optimized
Search
Navigation Bar
Patients
Calendar
Tasks
Messages
Task List
• Review urgent lab results (3)
• Approve repeat Prescriptions (2)
Today’s Appointments
12:30 – John Smith
13:00 – Nick Jones
13:30 – Amber Rose
14:00 – Ivan Dinev
Patient Flow
Patient Info
Nathan Smith
Age: 42
Medical
History
Medication
New Entry
20
Sensitivity: Internal
Patient application interface
Design Justification:
• Responsive Design: Adapted for larger screens.
• Patient-Centric: Focused to core patient needs (Booking, refills).
• Simple & Accessible: Large buttons, text.
• Action-Oriented: Guides users data access.
• Mobile-Optimized: Designed for easy use on smartphones.
Search
Home
Appointments
Messages
Profile
Welcome, John!
Home
Your Health
Book Appointment
Order Repeat Prescription
Medication Reminders
Latest Test Results
21
Sensitivity: Internal
Dataset visualisations
Medical professional dataset view 1
Design Justification:
• Key Info First.
• Simple Status (Colour Dots).
• Actionable (Tab to View).
• Mobile-Friendly.
Patients
Patient: Today
Search
Tasks
John Smith 45
45 45
Sarah Connor 30
30
Urgent Lab Results Late
Messages
Patients
22
Sensitivity: Internal
Medical professional dataset view 2
D
Design Justification:
• Focus: Single Patient.
• Action-Oriented (Button).
• Visual Alerts (Red).
• Mobile-Friendly.
John Smith
Alerts:
High Blood Pressure
Add Note
Summary
Labs
Next Appointment: 10:30 AM
Reason: Follow-up
Recent Vitals:
BP: 140/90 HR: 88
23
Sensitivity: Internal
Patient dataset view 1
Design Justification:
• Core Info First.
• Simple Actions (2 Buttons).
• Critical Alerts (Red).
• Mobile-Friendly
John Smith
DOB: 21/05/1990
Key Info
GP: Dr. Williams
Last Visit: 22/12/2025
Allergies: Peanuts
Book Appointment
Order Refill
Home
Messages
Profile
History
Edit
24
Sensitivity: Internal
Patient dataset view 2
Design Justification:
• Focus Status (Colour Dots).
• Easy Trends (Simple Chart).
• Actionable (View Buttons).
• Mobile-Friendly.
John Smith
DOB: 21/05/1990
Edit
Blood Test 22-12
X-Ray Test 22-12
Labs
Imaging
View Details
View Image
Heart Rate Trend
Home
Messages
Profile
25
Sensitivity: Internal
Identification of issues
Legal issue 1
The NHS application handle sensitive biometric data and often function as medical devices. If
the app isn’t built to strict legal standards, it creates a massive liability. Using personal phones to
access data or adding features that “analyse” health without medical license/certification. The risk is
heavy government fines and lawsuits if the data is leaked, and the potential of the app to be legally
shut down by health regulators. The Mitigation is to use encryption, to ensure no data is saved on
the phone itself and strictly define the app as an information tool.
Legal issue 2
The second legal issue is Professional Negligence and Clinical Liability. This issue focuses on
patient harm caused by reliance on the application. The issue arises when a mobile app provides a
data visualization or a summary that leads a clinician to miss a diagnosis or prescribe the wrong
treatment. If the app is found to be the source of the error, the developer and the healthcare
provider face a complex legal battle over who is responsible for the faulty decision. The Mitigation is
to always use time-stamped data, always show exactly when apiece of data was last updated so the
clinician knows if they are looking at real-time or stale info.
Usability issue 1
Clinicians often need to make split decisions based on complex datasets. When the data is
squeezed onto a small mobile screen, it becomes hard to read. If a clinician can’t find critical data
because it’s buried in a submenu, it leads to patient harm. The Mitigation is to use a summary
dashboard that highlights only the most critical values in red, hiding other values in the main menu.
Usability issue 2
The second usability issue is the lack of seamless context. In a fast-paced hospital, a clinician
is constantly interrupted. If it is difficult for the app to switch between tasks quickly, it causes
context loss. The clinician loses their train of thought, leading to errors or frustration. If a doctor has
to navigate back through five screens to find where they left off, it adds 30-60 seconds to every
patient interaction. The Mitigation is to provide a persistent patient tab at the top of the screen that
allows the clinician to jump between views without losing the current patient context.
Risk Register
1. Data Security: Risk of unauthorised access. Sensitive patient health information is accessed
by unauthorized users due to weak credentials. The Mitigation strategy is to implement
Multi-Factor Authentication (MFA), end-to-end encryption for data in transit and automatic
session timeouts.
2. Scheduling: Underestimating the time required for medical device certification pushes the
launch date back. The Mitigation strategy is to build a 3-month buffer into the timeline
specifically for a regulatory audit and hiring a clinical safety officer.
3. Communication: Developers and clinicians have different views on essential features,
leading to a product that doesn’t fit the clinical workflow. The Mitigation is to establish
weekly clinical review boards where active doctors test prototypes and provide immediate
feedback on usability.
4. Data Security: Insecure mobile hardware. Clinicians use personal, unmanaged phones that
may be lost, stolen or infected by malware, exposing the portal. The mitigation is to use a
26
Sensitivity: Internal
zero-footprint architecture, where no data is stored locally on the phone and implement
remote wipe capabilities via mobile device management.
5. Technical: Incompatible data standards, where the hospital and the portal are using
different data standards which is causing data translation errors. The mitigation is to use a
middleware integration engine to translate legacy data into modern formats before it
reaches the portal.
6. Operational: The app sends too many non-critical notifications, causing clinicians to ignore a
real emergency alert. The mitigation is to implement notification tiering, where only life-
critical alerts get sound/vibration while the routing alerts are silent in the inbox.
7. Legal/Safety: The portal summarizes labs incorrectly, leading a doctor to miss a critical
result. The Mitigation is to be appointed a clinical safety officer to perform a hazard
workshop, using red-flagging for all values outside clinical norms.