Designing a software architecture for an Electronic Patient Records (EPR) management system using the

Attribute Driven Design (ADD) approach involves a systematic process that focuses on achieving specific
quality attributes. Below, I will outline how to design an EPR system for the Ugandan healthcare system,
focusing on **Security** and **Usability** as the two key attributes. The system will be designed to
work at Health Center II (HCII), Health Center III (HCIII), and Health Center IV (HCIV) levels, with modules
limited to **admission** and **dispensing of drugs**.

---

### **1. Understanding the Context**

- **Ugandan Healthcare System**: The system is resource-constrained, with limited infrastructure,

intermittent power supply, and varying levels of healthcare worker expertise. The EPR system must be
robust, easy to use, and secure to protect patient data.

- **Functional Requirements**:

- **Admission Module**: Register patients, capture demographic and clinical data, and assign unique
identifiers.

- **Dispensing Module**: Manage drug inventory, prescribe medications, and track drug dispensing.

- **Non-Functional Requirements**:

- **Security**: Protect patient data from unauthorized access, ensure data integrity, and comply with
privacy regulations.

- **Usability**: Ensure the system is easy to use for healthcare workers with varying levels of technical
expertise.

---

### **2. Attribute-Driven Design (ADD) Approach**

The ADD approach involves the following steps:

1. **Identify Design Concerns**: Prioritize security and usability as the key quality attributes.

2. **Define Architectural Drivers**: These include functional requirements, quality attributes, and
constraints.
3. **Create Design Iterations**: Decompose the system into modules and define interfaces.

4. **Validate the Design**: Ensure the design meets the specified attributes.

---

### **3. Architectural Design**

#### **Step 1: Identify Design Concerns**

- **Security**: Protect patient data from unauthorized access, ensure data encryption, and implement
role-based access control (RBAC).

- **Usability**: Design an intuitive user interface, provide offline functionality, and ensure the system is
accessible on low-end devices.

#### **Step 2: Define Architectural Drivers**

- **Functional Requirements**:

- Admission: Register patients, capture clinical data.

- Dispensing: Manage drug inventory, prescribe and dispense drugs.

- **Quality Attributes**:

- Security: Data encryption, RBAC, audit logs.

- Usability: Simple UI, offline mode, responsive design.

- **Constraints**:

- Limited internet connectivity.

- Low-end hardware devices.

- Varying levels of user expertise.

#### **Step 3: Create Design Iterations**

- **Module Decomposition**:

1. **Admission Module**:

- Interfaces:

- `registerPatient()`: Captures patient details.

- `assignUniqueID()`: Generates a unique patient identifier.

- `captureClinicalData()`: Records clinical information.

2. **Dispensing Module**:

- Interfaces:

- `manageInventory()`: Tracks drug stock levels.

- `prescribeDrugs()`: Records prescribed medications.

- `dispenseDrugs()`: Tracks drug dispensing.

3. **Security Module**:

- Interfaces:

- `authenticateUser()`: Verifies user credentials.

- `authorizeUser()`: Implements RBAC.

- `encryptData()`: Encrypts sensitive data.

4. **Usability Module**:

- Interfaces:

- `offlineMode()`: Allows functionality without internet.

- `syncData()`: Synchronizes data when online.

- `simpleUI()`: Provides an intuitive user interface.

- **Architectural Patterns**:

- **Layered Architecture**: Separates concerns into presentation, business logic, and data layers.

- **Client-Server Architecture**: Centralized server for data storage, with clients at health centers.
 - **Offline-First Design**: Ensures functionality in low-connectivity areas.

#### **Step 4: Validate the Design**

- **Security**:

- Data encryption ensures confidentiality.

- RBAC restricts access based on user roles.

- Audit logs track access and changes to patient data.

- **Usability**:

- Simple UI reduces training requirements.

- Offline mode ensures functionality in remote areas.

- Responsive design works on low-end devices.

---

### **4. Detailed Module Specifications**

#### **Admission Module**

- **Interfaces**:

- `registerPatient(name, dob, gender, contact)`: Registers a new patient.

- `assignUniqueID()`: Generates a unique identifier for the patient.

- `captureClinicalData(patientID, symptoms, diagnosis)`: Records clinical data.

- **Security**: Data encrypted at rest and in transit.

- **Usability**: Simple forms with dropdowns and checkboxes for ease of use.

#### **Dispensing Module**

- **Interfaces**:

- `manageInventory(drugID, quantity)`: Updates drug stock levels.

- `prescribeDrugs(patientID, drugID, dosage)`: Records prescribed medications.

- `dispenseDrugs(patientID, drugID, quantity)`: Tracks drug dispensing.

- **Security**: Role-based access to prevent unauthorized dispensing.

- **Usability**: Barcode scanning for drug identification.

#### **Security Module**

- **Interfaces**:

- `authenticateUser(username, password)`: Verifies user credentials.

- `authorizeUser(role, resource)`: Checks user permissions.

- `encryptData(data)`: Encrypts sensitive data.

- **Usability**: Minimal user interaction for authentication.

#### **Usability Module**

- **Interfaces**:

- `offlineMode()`: Stores data locally when offline.

- `syncData()`: Synchronizes local data with the server when online.

- `simpleUI()`: Provides an intuitive and responsive interface.

- **Security**: Local data encrypted to prevent unauthorized access.

---

### **5. Deployment Considerations**

- **HCII, HCIII, HCIV**: The system must be deployable on low-end devices with intermittent internet
connectivity.
- **Training**: Provide training materials and support for healthcare workers.

- **Maintenance**: Regular updates and bug fixes to ensure reliability.

---

### **6. Conclusion**

The proposed EPR system architecture, designed using the ADD approach, prioritizes **security** and
**usability** to meet the needs of the Ugandan healthcare system. The modular design ensures
scalability, while the focus on offline functionality and simplicity ensures usability in resource-
constrained settings. This architecture can be extended to include additional modules and quality
attributes as needed.