Programming Question

Using your PD UC, its SSD, the Domain Model, the System Operation Contract (SOC), and the Interaction Diagram from the previous assignment, draw the Design Class Diagram (DCD).

Provide a rationale for any domain classes and domain associations that are eliminated from the domain model, any Pure Fabrications and Indirections introduced, any polymorphism used, and any generalization and specialization.

Domain Modeling
1
Overview
This domain model project for the healthcare sector is crafted to enhance the visualization and
comprehension of the healthcare system’s complexities by methodically identifying and
categorizing conceptual classes, serving as a fundamental framework for the development of
robust healthcare information systems. Structured around key categories such as physical
objects, specifications, places, transactions, roles, policies, and software applications, it captures
the essence of healthcare operations from tangible equipment like hospital beds to abstract
concepts like treatment plans. A rigorous pruning process was applied to focus on classes
directly impacting healthcare delivery and system functionality, retaining those essential for
processes, patient management, and financial operations while excluding the peripheral. The
backbone of this model includes physical objects critical to service delivery, specifications
ensuring treatment standardization, roles highlighting the patient-provider interaction, processes
for efficient service, and policies for patient data protection. At its core, the UML domain model
visually encapsulates these relationships, providing a clear and structured representation of the
healthcare system’s architecture, facilitating stakeholders in aligning technological solutions with
healthcare needs.
Domain Modeling
2
How to Derived the Domain Model
Deriving a domain model in the healthcare sector begins with a clear definition of its scope, such
as focusing on specific areas like patient care management or electronic health records. This
clarity assists in identifying relevant entities and their interconnections within the vast healthcare
sector. The next step involves gathering detailed information through consultations with
stakeholders, reviewing regulatory guidelines, and analyzing existing systems, which is crucial
for understanding the domain’s needs and challenges. The process continues with the
identification of conceptual classes—such as physical objects, roles, processes, and policies—
using the gathered information as a foundation. A pruning process evaluates the relevance of
each class to the healthcare delivery system, retaining those essential for understanding and
modeling the domain while pruning peripheral ones to maintain focus. Attributes and
relationships for each retained class are then defined; for example, a “Patient” class might
include attributes like ID and medical history and relationships indicating the healthcare
providers involved. This information is translated into a UML diagram to visually represent the
interconnected entities of the domain, adhering to UML standards for clarity. Sharing the initial
model version with stakeholders for feedback ensures the model accurately represents the
domain and meets identified needs. Documentation of the model includes descriptions of each
class and its attributes, the rationale behind the inclusion of each entity, and explanations of the
depicted relationships, providing a comprehensive overview accessible to diverse stakeholders.
This iterative process of engagement, learning, and adaptation to changes in the healthcare
domain ensures the model remains a valuable and accurate tool for enhancing healthcare service
delivery.
Domain Modeling
3
Conceptual Class Category and Examples:
Conceptual Class Category
Examples
Physical or Tangible Objects
Hospital Bed, MRI Machine, Medical Record, Prescription
Specifications, Designs, or Descriptions of
Things
Treatment Plan, Drug Formulary, Surgical Procedure
Places
Operating Room, Pharmacy, Clinic, Emergency Room
Transactions
Medical Appointment, Surgery Booking, Prescription Order
Roles of People
Patient, Doctor, Nurse, Administrator
Containers of Other Things
Medicine Cabinet, Patient File, Hospital Ward
Things in a Container
Medications in Cabinet, Files in Patient Record
Other Computers/Systems (external)
Electronic Health Record (EHR) System, Insurance Database
Abstract Noun Concepts
Health Insurance Policy, Patient Consent
Organizations
Healthcare Provider, Insurance Company
Events
Health Screening, Vaccination, Hospital Admission
Processes
Patient Onboarding, Medical Billing, Drug Dispensing
Rules and Policies
Data Privacy Policy, Treatment Guidelines, Billing Codes
Catalogs
Medication Catalog, Service Catalog
Records of Finance, Work, Contracts, Legal
Matters, etc.
Billing Statement, Employment Contract, Consent Form
Financial Instruments and Services
Health Savings Account (HSA), Payment Plan
Manuals, Books, Documents, Reference
Papers
Medical Textbook, Treatment Protocol, Research Paper
Communication Channels
Patient Hotline, Online Patient Portal, Email Notifications
Healthcare Equipment and Supplies
Syringes, Bandages, Diagnostic Kits, PPE
Software and Applications
Appointment Scheduling App, Telehealth Services Platform,
Patient Monitoring Software
Domain Modeling
List of Pruning:
Physical or Tangible Objects
Prune: Keep all, as each represents core components of healthcare service delivery.
Specifications, Designs, or Descriptions of Things
Prune: Retain Treatment Plan and Drug Formulary; these are central to healthcare delivery.
Places
Prune: Keep all, each place is essential for different healthcare activities.
Transactions
Prune: Keep Medical Appointment and Prescription Order, which are core transactions in
healthcare.
Roles of People
Prune: Focus on Patient, Doctor, Nurse, removing Administrator due to its indirect role in care.
Containers of Other Things & Things in a Container
Prune: Merge into one category focusing on essential containers like Patient File.
Other Computers/Systems (external)
Prune: Electronic Health Record (EHR) System remains crucial for integrating healthcare
services.
Abstract Noun Concepts
Prune: Health Insurance Policy is essential for understanding patient coverage and billing.
4
Domain Modeling
Organizations
Prune: Keep Healthcare Provider and Insurance Company, directly involved in healthcare
delivery and financing.
Events
Prune: Retain Health Screening and Vaccination, core health maintenance events.
Processes
Prune: Patient Onboarding and Medical Billing are essential for patient management and
financial operations.
Rules and Policies
Prune: Data Privacy Policy remains critical due to the sensitivity of health data.
Catalogs
Prune: Medication Catalog is crucial for prescribing and inventory management.
Records of Finance, Work, Contracts, Legal Matters, etc.
Prune: Keep Billing Statement for its direct relevance to financial transactions.
Financial Instruments and Services
Prune: Exclude this category as it’s more about financial management than healthcare delivery.
Manuals, Books, Documents, Reference Papers
Prune: Exclude for being too general and not directly affecting system functionality.
5
Domain Modeling
6
Communication Channels
Prune: Keep Online Patient Portal for its direct interaction with healthcare services.
Healthcare Equipment and Supplies
Prune: Exclude as it details are more operational than conceptual for the domain model.
Software and Applications
Prune: Retain Appointment Scheduling App, directly impacting patient interaction with the
system.
List Of Classes That Are Pruned & The Classes That Are Retained For The Domain
Model:
Good Classes (Retained)
Bad Classes (Pruned)
Hospital Bed
Prescription
MRI Machine
Medical Record
Treatment Plan
Drug Formulary
Operating Room
Surgical Procedure
Clinic
Pharmacy
Medical Appointment
Surgery Booking
Patient
Administrator
Domain Modeling
7
Good Classes (Retained)
Bad Classes (Pruned)
Doctor
Insurance Database
Nurse
Patient Consent
Patient File
Medicine Cabinet
Electronic Health Record (EHR) System
Insurance Company
Health Insurance Policy
Vaccination
Healthcare Provider
Hospital Admission
Health Screening
Medical Billing
Patient Onboarding
Drug Dispensing
Data Privacy Policy
Treatment Guidelines
Medication Catalog
Billing Codes
Online Patient Portal
Health Savings Account (HSA)
Appointment Scheduling App
Payment Plan
Medical Textbook
Domain Modeling
UML Domain Model:
8
Interaction Diagram
1
Three System Operation Contracts and Interaction Diagrams
Three System Operation Contracts
System Operation Contract 1: Register Patient
Name:
Register Patient
Responsibilities:
Registering the patient.
Type:
System
Cross Reference:
Use Case: Register Patient.
Notes:
The patient registers using a registration
form. They enter and submit their details via
the registration form. The system verifies
the registration details and if successful the
system activates the user account.
Exceptions:
If the registration details are incomplete or
inaccurate the system prompts the user for
more information and if verification fails the
system informs the user and involves an
administrator.
Output:
Pre-conditions:
The patient must have access to the user
interface of the healthcare system.
The provided details must be valid and
complete.
Post-conditions:
If the patient’s details are verified
successfully their user account is activated
in the system.
System Operation Contract 2: Schedule Appointment
Name:
Schedule Appointment.
Responsibilities:
Scheduling appointments.
Type:
System
Cross Reference:
Use Case: Schedule Appointment.
Interaction Diagram
2
Notes:
A Patient navigates to the appointment
scheduling section and selects preferred date
and time. The system checks for availability
and if available, appointment is scheduled
and confirmed to the patient.
Exceptions:
If the selected time is not available, the
system recommends other available options.
Output:
A confirmation message is sent to the
patient.
Pre-conditions:
The patient must be logged in the system
and the selected time slot must be available.
Post-conditions:
An appointment is successfully scheduled
and recorded in the system.
System Operation Contract 3: Access Patient File.
Name:
Access Patient File.
Responsibilities:
Accessing Patient Files.
Type:
System
Cross Reference:
Use Case: Access Patient File.
Notes:
The healthcare personnel initiates the
process by requesting a patient’s medical
file. The system authenticates the personnel
and if authorized the personnel is presented
the file after the system fetches it. The
healthcare reviews the file as needed.
Exceptions:
If the healthcare personnel has issues with
authentication or authorization, they are
notified and the operation terminates. In
addition, if the Patient’s records are missing
the personnel is notified and the operation
terminates.
Output:
Pre-conditions:
The healthcare personnel must be
authenticated and authorized to access the
Interaction Diagram
3
files. The patient’s medical record files must
be available in the system.
Post-conditions:
The healthcare personnel successfully
accesses the patient’s medical file.
Interaction Diagrams
System Operation Contract 1: Register Patient Interaction Diagram
Interaction Diagram
System Operation Contract 2: Schedule Appointment Interaction Diagram
System Operation Contract 3: Access Patient File Interaction Diagram
4
Interaction Diagram
5
Use Case Analysis
1
1. Fill in the below table to list at least 3 primary, 2 supporting, and 3 offstage actors with their goal
descriptions respectively for a healthcare domain software system. (Refer to Health Care Domain
Example). Each actor must be correctly classified in the appropriate category, i.e., Primary,
Supporting, or Offstage.
Type
Actor
Primary
Goal Description
Patient
Healthcare Provider
Supporting
Manage patient treatments, update medical records
Administrator
Manage system configuration, user roles
Insurance Company
Approve insurance claims, handle billing
Laboratory
Offstage
Schedule appointments, view medical records
Process lab tests, send results to healthcare provider
Software Developer
Develop and maintain the software system
Regulatory Agency
Ensure compliance with healthcare regulations
Data Analyst
Analyze health data for system improvements
2. List at least five use case names for the system based on the above actor list. At least two use
cases must involve both primary and supporting actors.
A) Register Patient (Primary Actor: Patient; Supporting Actor: System Administrator)
This use case involves a patient registering to use the healthcare system, with the system
administrator playing a supporting role in verifying the registration details and activating the patient
account.
B) Schedule Appointment (Primary Actor: Patient)
In this scenario, a patient schedules a healthcare appointment through the system. The primary
focus is on the patient’s interaction with the system to find and book an available time slot with a
healthcare provider.
C) Prescribe Medication (Primary Actor: Healthcare Provider; Supporting Actor: Pharmacist)
Use Case Analysis
2
This use case involves a healthcare provider prescribing medication for a patient, with a pharmacist
(as a supporting actor) verifying the prescription and preparing the medication for the patient.
D) Access Patient Records (Primary Actor: Healthcare Provider; Supporting Actor: System
Administrator)
A healthcare provider accesses a patient’s medical records to review their medical history before or
during an appointment. The system administrator ensures that the healthcare provider has the
necessary permissions to access these records.
E) Submit Insurance Claim (Primary Actor: Patient)
A patient submits an insurance claim through the system for medical services received. This use
case focuses on the patient’s interaction with the system to complete and submit the claim form.
F) Analyze Patient Health Trends (Primary Actor: Data Analyst; Supporting Actor: Healthcare
Provider)
Data Analyst performs an analysis of patient health trends using the system’s aggregated health
data. The goal is to identify patterns or trends that could lead to improvements in patient care or
health outcomes. The Healthcare Provider supports this use case by providing expert insights into
the health data and assisting in the interpretation of the analysis results.
G) Develop Patient Feedback System (Primary Actor: Software Developer; Supporting Actor: System
Administrator)
This use case involves a Software Developer designing and implementing a patient feedback
system within the healthcare software. The System Administrator supports this process by
providing requirements for system integration, ensuring security protocols are followed, and
assisting in the deployment and testing phases to ensure the new system functions smoothly within
the existing healthcare infrastructure.
3. Document the five use cases as Partially-Dressed/Fully-Dressed use cases.
Partially-Dressed Use Cases
Use Case: Register Patient
Use Case Section
Description
Use Case Name
Register Patient
Scope
Healthcare system registration process.
Level
Primary goal for patients, supporting for system administrators.
Primary Actor
Patient
Preconditions
The patient must have access to the registration interface of the
healthcare system.
Success Guarantee
The patient’s registration details are successfully verified, and their
account is activated in the system.
Use Case Analysis
Main Success
Scenario
1.
2.
3.
4.
5.
Patient accesses the registration form.
Patient fills in required details (e.g., name, contact information).
Patient submits the registration form.
System/System administrator verifies the registration details.
Patient account is activated in the system.
Use Case: Schedule Appointment
Use Case Section
Description
Use Case Name
Schedule Appointment
Scope
Healthcare system appointment scheduling functionality.
Level
Primary goal for patients.
Primary Actor
Patient
Preconditions
The patient must be logged into the healthcare system.
Success Guarantee
An appointment is successfully scheduled and recorded in the
system.
Main Success
Scenario
1.
2.
3.
4.
5.
Patient accesses the appointment scheduling interface.
Selects preferred date and time.
System checks for availability.
Appointment confirmation.
Confirmation sent to patient.
Fully-Dressed Use Cases
Use Case: Prescribe Medication
Use Case Section
Description
Use Case Name
Prescribe Medication
Scope
Healthcare system medication prescribing functionality.
Level
Primary goal for healthcare providers, supporting for pharmacists.
Primary Actor
Healthcare Provider
Stakeholders and
The healthcare provider aims to prescribe medication for the patient’s
Interests
treatment. The pharmacist’s interest lies in ensuring the prescription
and preparing the medication prescribed.
Preconditions
The healthcare provider must have access to the patient’s medical
records and prescription capabilities within the system.
Success
A valid prescription is issued and accessible by the pharmacist for
Guarantee
dispensing.
Main Success
Scenario
3
Use Case Analysis
1.
2.
3.
4.
Healthcare provider accesses patient’s medical records.
Healthcare provider selects appropriate medication and dosage.
Prescription is generated and recorded in the system.
Pharmacist reviews and validates the prescription.
Use Case: Access Patient Records
Use Case Section
Description
Use Case Name
Access Patient Records
Scope
Healthcare system patient record access functionality.
Level
Primary goal for healthcare providers, supporting for system
administrators.
Primary Actor
Healthcare Provider
Stakeholders and
The healthcare provider aims to access patient records for informed
Interests
decision-making during treatment. The system administrator ensures
proper access control and data security.
Preconditions
The healthcare provider must be authenticated and authorized to
access patient records.
Success
The healthcare provider successfully accesses the required patient
Guarantee
records.
Main Success
Scenario
1.
2.
3.
4.
Healthcare provider logs into the system.
Healthcare provider navigates to patient records section.
Relevant patient records are displayed.
Healthcare provider reviews the records as needed.
Use Case: Submit Insurance Claim
Use Case Section
Description
Use Case Name
Submit Insurance Claim
Scope
Healthcare system insurance claim submission functionality.
Level
Primary goal for patients.
Primary Actor
Patient
Stakeholders and
The patient aims to claim insurance for medical services rendered.
Interests
The insurance company’s interest lies in processing valid claims
efficiently.
Preconditions
The patient must have received medical services covered by
insurance and have access to the claim submission interface.
Success Guarantee
The insurance claim is successfully submitted and processed.
Main Success
Scenario
1. Patient accesses the insurance claim submission form.
2. Patient fills in necessary details (e.g., treatment information, provider details).
3. Patient submits the claim.
4
Use Case Analysis
5
4. Insurance company reviews and processes the claim.
4. Please use the format below for your description of the UC
Use Case Section
Comment
Use Case Name
Clear and concise, directly reflects the action and the subject.
Scope
Specifies the system within which this use case operates.
Level
Indicates that this use case is aimed at achieving a specific user
goal.
Primary Actor
Identifies the main user or stakeholder who initiates and benefits
from the use case.
Stakeholders and
Interests
Highlights the interests of both the primary actor and the
supporting actor, emphasizing their goals and stakes in the use
case.
Preconditions
Sets the stage for the use case, ensuring that it starts with a clear
initial state.
Success Guarantee
Provides a clear definition of what success looks like for this use
case.
Main Success Scenario
Outlines the step-by-step process to achieve the goal, from start
to finish.
Extensions
Addresses potential deviations from the main scenario, providing
alternative paths or solutions.
Special Requirements
Specifies additional requirements that are crucial for the
successful execution of the use case, focusing on security and
user verification.
Use Case 1: Register Patient
Use Case Section
Comment
Use Case Analysis
6
Use Case Name
Register Patient
Scope
Healthcare system registration process.
Level
Primary goal for patients, supporting for system administrators.
Primary Actor
Patient
Stakeholders
and Interests
The patient’s interest lies in successfully registering in the healthcare
system to access medical services. The system administrator’s interest
is in ensuring the accuracy and legitimacy of the patient’s registration
details.
Preconditions
The patient must have access to the registration interface of the
healthcare system.
Success
Guarantee
The patient’s registration details are successfully verified, and their
account is activated in the system.
Main Success
Scenario
1. Patient accesses the registration form. 2. Patient fills in required
details (e.g., name, contact information). 3. Patient submits the
registration form. 4. System administrator verifies the registration
details. 5. Patient account is activated in the system.
Extensions
If the registration details are incomplete or inaccurate, the system
administrator requests additional information from the patient.
Special
Requirements
The system must ensure the security and privacy of patient
registration data.
Use Case 2: Schedule Appointment
Use Case Section
Comment
Use Case Name
Schedule Appointment
Scope
Healthcare system appointment scheduling functionality.
Level
Primary goal for patients.
Primary Actor
Patient
Stakeholders and
Interests
The patient aims to schedule a healthcare appointment at a
convenient time. The healthcare provider’s interest lies in managing
their schedule effectively.
Preconditions
The patient must be logged into the healthcare system.
Use Case Analysis
7
Success
Guarantee
An appointment is successfully scheduled and recorded in the
system.
Main Success
Scenario
1. Patient navigates to the appointment scheduling section. 2. Patient
selects preferred date and time. 3. System checks for availability. 4.
If available, appointment is scheduled. 5. Confirmation is sent to
patient.
Extensions
If the preferred time slot is unavailable, the system suggests
alternative options.
Special
Requirements
The system must integrate with the healthcare provider’s schedule
and ensure appointment data accuracy.
Use Case 3: Prescribe Medication
Use Case Section
Comment
Use Case Name
Prescribe Medication
Scope
Healthcare system medication prescribing functionality.
Level
Primary goal for healthcare providers, supporting for pharmacists.
Primary Actor
Healthcare Provider
Stakeholders
and Interests
The healthcare provider aims to prescribe medication for the patient’s
treatment. The pharmacist’s interest lies in ensuring the accuracy and
safety of the prescribed medication.
Preconditions
The healthcare provider must have access to the patient’s medical
records and prescription capabilities within the system.
Success
Guarantee
A valid prescription is issued and accessible by the pharmacist for
dispensing.
Main Success
Scenario
1. Healthcare provider accesses patient’s medical records. 2.
Healthcare provider selects appropriate medication and dosage. 3.
Prescription is generated and recorded in the system. 4. Pharmacist
reviews and validates the prescription.
Extensions
If the prescribed medication conflicts with the patient’s medical
history or is unavailable, the pharmacist consults with the healthcare
provider for clarification.
Special
Requirements
The system must support secure transmission of prescriptions and
adhere to regulatory guidelines.
Use Case Analysis
8
Use Case 4: Access Patient Records
Use Case Section
Comment
Use Case Name
Access Patient Records
Scope
Healthcare system patient record access functionality.
Level
Primary goal for healthcare providers, supporting for system
administrators.
Primary Actor
Healthcare Provider
Stakeholders and
Interests
The healthcare provider aims to access patient records for informed
decision-making during treatment. The system administrator ensures
proper access control and data security.
Preconditions
The healthcare provider must be authenticated and authorized to
access patient records.
Success
Guarantee
The healthcare provider successfully accesses the required patient
records.
Main Success
Scenario
1. Healthcare provider logs into the system. 2. Healthcare provider
navigates to patient records section. 3. Relevant patient records are
displayed. 4. Healthcare provider reviews the records as needed.
Extensions
If access is denied, the system administrator is notified to review and
adjust permissions accordingly.
Special
Requirements
Access to patient records must be role-based and adhere to privacy
regulations.
Use Case 5: Submit Insurance Claim
Use Case Section
Comment
Use Case Name
Submit Insurance Claim
Scope
Healthcare system insurance claim submission functionality.
Level
Primary goal for patients.
Primary Actor
Patient
Use Case Analysis
9
Stakeholders and
Interests
The patient aims to claim insurance for medical services rendered.
The insurance company’s interest lies in processing valid claims
efficiently.
Preconditions
The patient must have received medical services covered by
insurance and have access to the claim submission interface.
Success
Guarantee
The insurance claim is successfully submitted and processed.
Main Success
Scenario
1. Patient accesses the insurance claim submission form. 2. Patient
fills in necessary details (e.g., treatment information, provider
details). 3. Patient submits the claim. 4. Insurance company reviews
and processes the claim.
Extensions
If the submitted claim is incomplete or invalid, the system prompts
the patient for additional information.
Special
Requirements
The system must support secure transmission of sensitive insurance
data and integrate with insurance company systems for claim
processing.
Use Case Analysis
Draw a Use Case Diagram based on questions (1) , (2), and (3)
10
Use Case Analysis
5. Draw the System Sequence Diagrams (SSDs) for the above UCs.
a. SSD for Registering a Patient.
–
The Patient initiates the registration process.
The Patient enters registration details in the healthcare system.
The Patient submits the registration form.
11
Use Case Analysis
12
The healthcare System verifies the registration.
If successful, system activates the patient’s account.
If unsuccessful the system informs the patient of the unsuccessful verification and system
administrator becomes involved.
b. SSD for scheduling Appointments.
–
– Patient requests an appointment.
– Patient selects appointment details.
– System checks appointment availability.
– If available, system confirms the appointment.
– System notifies the patient about the confirmed appointment or appointment unavailability.
c. SSD for Medication Prescription.
Use Case Analysis
–
Healthcare provider initiates the prescription process.
Healthcare provider selects the medication.
System generates the prescription.
System validates the prescription.
13
Use Case Analysis
– Healthcare provider provides the patient with their prescription.
d. SSD for Accessing Patient Records.
– The health provider requests patient records.
– The healthcare system retrieves the requested records.
– The healthcare system patient records.
– The Healthcare provider reviews the records.
e. SSD for Submitting Insurance Claim.
14
Use Case Analysis
–
The patient initiates the insurance claim process.
The patient enters the claim details.
The patient submits the claim.
The healthcare system processes the claim and forwards it to the insurance company.
The insurance company approves the insurance claims and handles billing.
The healthcare system provides the claim processing result to the patient.
15