The programming languages used in the Jimma Hospital Patient Record Management System
project document are:
1. Frontend Languages:
o HTML
o CSS
o JavaScript
These are used for creating the user interface — forms, dashboards, and navigation
features.
2. Backend Languages:
o PHP (primarily mentioned)
o Alternatives mentioned: Python with Django or Java — though PHP is the main
language planned.
3. Database Language:
o SQL (Structured Query Language), used within:
MySQL or PostgreSQL as the database management system.
These languages and tools are selected to build a web-based patient record management system
that is cost-effective, scalable, and compatible with Jimma Hospital's existing infrastructure
Backend Development
Languages:
Java (Spring Boot) or Python (Django) for robust server-side logic, API development,
and EHR management.
SQL (MySQL/PostgreSQL) for structured patient data storage (e.g., demographics,
appointments).
NoSQL (MongoDB) for flexible storage of documents (e.g., scanned lab reports, X-
rays).
APIs:
RESTful services for seamless integration with external systems (e.g., insurance
providers, lab equipment).
HL7/FHIR standards for healthcare-specific data exchange.
Frontend Development
Web Interface:
React.js for dynamic admin dashboards (real-time analytics, user management).
HTML5/CSS3 with responsive design for accessibility across devices.
Mobile App:
Flutter for cross-platform compatibility (iOS/Android) to enable patient portal features
(e.g., appointment booking, record access).
DevOps & Infrastructure
Cloud Hosting: AWS (EC2, S3, RDS) or Azure for scalability, security, and offsite
backups.
CI/CD Pipelines: GitHub Actions/Jenkins for automated testing and deployment.
Containerization: Docker for consistent environments (development → production).
Security & Compliance Tools
Encryption: AES-256 for data at rest, TLS 1.3 for data in transit.
Access Control: Role-Based Access Control (RBAC) with Two-Factor Authentication
(2FA).
Audit Logs: ELK Stack (Elasticsearch, Logstash, Kibana) for tracking user activities.
Third-Party Integrations
SMS/Email APIs: Twilio, SendGrid for appointment reminders.
Payment Gateways: CBE Birr, PayPal for billing.
BI Tools: Power BI, Tableau for analytics dashboards.
Why This Stack?
Scalability: Modular architecture supports future expansions (e.g., pharmacy module).
Regulatory Compliance: Meets Ethiopia’s Health Data Protection Guidelines and global
standards (HIPAA/GDPR).
User Experience: Multilingual support (Amharic/English) and intuitive interfaces reduce
training overhead.
Test Plan for Patient Record Management System (PRMS)
1. Test Plan Overview
This test plan outlines the strategy, objectives, scope, schedule, and approach for verifying and
validating the PRMS to ensure that it meets functional, performance, security, and compliance
requirements before deployment at Jimma Hospital.
2. Objectives
Validate all functional requirements (patient registration, appointments, EHR, billing, etc.)
Verify non-functional requirements such as security, usability, scalability, and performance
Ensure integration with third-party systems (SMS, payments, analytics)
Confirm that the system meets healthcare compliance (HIPAA, GDPR, Ethiopia’s Health Data
Protection)
3. Scope of Testing
In-Scope
Web Application (Admin Dashboard)
Mobile Application (Patient Portal)
Backend APIs
Database and data integrity
Third-party API integrations
Cloud deployment and DevOps pipeline
Role-based access control (RBAC)
Out-of-Scope
Physical infrastructure and network testing
Performance of external systems (e.g., payment gateways, SMS providers)
Module Test Areas
Patient Registration Form validation, duplicate detection, ID generation
Medical Records Create, update, view, delete records
Appointments Schedule, reschedule, cancel, calendar integration
Billing Invoice generation, payment status, payment gateway connection
User Management Role creation, permissions enforcement, login/logout
2 Integration Testing
Test RESTful APIs between frontend and backend
HL7/FHIR API exchange with labs/insurance systems
Payment gateway callbacks and transaction logs
SMS/email reminders via Twilio/SendGrid
4.3 Security Testing
Penetration testing and vulnerability scans
Role-Based Access Control (RBAC) enforcement
Two-Factor Authentication (2FA)
Data encryption at rest (AES-256) and in transit (TLS 1.3)
Session management (timeouts, invalid sessions)
4.4 Usability Testing
Multilingual interface (Amharic, English)
Accessibility (WCAG 2.1 compliance)
User flow for patients, doctors, and admins
Mobile responsiveness across devices
4.5 Performance Testing
Load testing: 500 concurrent users accessing records
Stress testing: 10,000 records accessed under peak load
Response time: <3 seconds for patient search & dashboard
4.6 Regression Testing
Performed after each update or bug fix
Ensure no impact on previously validated functionality
4.7 User Acceptance Testing (UAT)
Involve real users from Jimma Hospital
Test live scenarios: patient check-in, lab results review, etc.
Final approval required for deployment
5. Test Environment
Component Tools/Technologies
Frontend React.js, Flutter (simulators for mobile)
Backend Django/Spring Boot APIs
DB MySQL/PostgreSQL, MongoDB
DevOps Docker, GitHub Actions, AWS (EC2, RDS)
Component Tools/Technologies
Monitoring ELK Stack (Logs), Postman/Newman (API testing), JMeter (load testing)
6. Test Data
Create dummy patients, doctors, and staff records
Generate synthetic lab reports, invoices, appointments
Simulate real-world conditions (e.g., emergency cases)
7. Roles & Responsibilities
Role Responsibility
QA Lead Overall test strategy and coordination
QA Engineer Writing test cases, executing tests
Developers Bug fixing and unit testing
System Admin Setting up and maintaining test environments
Hospital Staff Performing UAT and providing feedback
8. Schedule
Phase Duration
Test Plan & Case Design Week 1
Unit & Integration Testing Week 2
Functional, Security, Performance Testing Week 3
UAT & Final Review Week 4
9. Deliverables
Test Plan Document
Test Case Document
Bug Report Log
Test Summary Report
UAT Sign-Off
10. Entry & Exit Criteria
Entry Criteria:
All features completed and unit tested
Test environment configured
Test data prepared
Exit Criteria:
100% critical and high severity test cases passed
No open critical defects
UAT approved
