Pakenham Hospital Patient Management System

1. Introduction to the PH-PMS Project

The fundamental motive of the Pakenham Hospital Patient Management System (PH-PMS) development project is to apply modern software-engineering understanding and practice to a comprehensive, well-structured system for a healthcare platform. The PH-PMS reflects the essential operations of the healthcare industry: new patient enrolment, doctor and hospital-admin profiles with role-based access, appointment booking and management, personalised QR/bar-code generation with physical scanner support, biometric and RFID device integration, and a secured, efficient relational database. The system is built with Java (Swing and AWT) on a MySQL backend.

Digital infrastructure of this kind contributes directly to operational efficiency, minimised human error, and quality of care through structured resource organisation. The PH-PMS pairs a modern, efficient user interface with an extensive feature set: role-based access control (RBAC), appointment booking and management, personalised user dashboards, patient enrolment with custom QR/bar-code generation, physical device integration (scanners, biometrics, RFID, kiosks), a futuristic admin panel, a well-designed relational database, and an integrated system chatbot. The overall design outlines four qualities above all: modularity, reliability, security, and efficiency.

2. High-Level Requirements

The PH-PMS must incorporate numerous real-world requirements for business functions and operational logic. These high-level requirements are the foundational basis of the overall system architecture, and they divide into functional requirements (what the system must do for its stakeholders) and non-functional requirements (the qualities the system must exhibit while doing it).

2.1. Functional Requirements

Eight families of functional requirements were specified, each decomposed into sub-requirements with explicit constraints, data elements, database dependencies, an assigned Agile release phase, a time frame, and a complexity rating. Table 1 summarises all seventeen work packages.

Security anchors the specification. FR-1 demands authenticated login with session handling, hashed credentials (PBKDF2/Bcrypt/Argon2), account lockout after repeated failures with admin reset, and full audit records of every login attempt. RBAC routes admin credentials to the Admin_Panel() and all other successful sessions to the Reception_Panel(), with roles configurable by the administrator. FR-2 covers the patient enrolment form writing into the relational patients table, plus a personalised dashboard that greets each authenticated user by name and scopes functionality to their access level.

The appointment subsystem (FR-3) displays the active-doctor directory with availability, enforces booking rules (one doctor and one slot per appointment, completed forms before confirmation, support for recurring bookings such as weekly physiotherapy), and manages overflow with a linked-list waitlist using enqueue/dequeue logic to maintain FIFO or priority ordering — fully booked doctors are removed from the directory automatically. Around this core sit report and invoice generation with access-level restrictions (FR-4), a database-aware chatbot with ticketing and request forwarding to the concerned staff panel (FR-5), integration of wristband QR/bar-code scanners, biometric/RFID devices, and kiosk self-check-in displays (FR-6), hospital room and bed inventory management with CRUD operations and allocation locking (FR-7), and an admin panel with database backup, security monitoring, and email/SMS notification formats (FR-8).

2.2. Non-Functional Requirements

Non-functional requirements are the underlying qualities that ensure the system's safe and reliable existence — rarely raised by stakeholders directly, but the development team must assure them regardless. Eleven NFRs were specified and prioritised with MoSCoW. The most consequential are security-driven: all patient health information (PHI) and PII must be protected according to the Australian Privacy Principles and HIPAA-equivalent standards, every read/write must check the confidentiality flag and user role, role violations must return HTTP 403, and every CRUD operation on patient, appointment, or document data must produce an immutable, tamper-evident audit entry.

Performance targets are equally explicit: 95% of core transactions (login, booking, check-in, record retrieval) must respond within two seconds at 200 concurrent users; the system must sustain twice the baseline load with no more than a 10% increase in average response time; uptime must reach 99.9% during business hours; concurrent bookings must resolve to exactly one confirmation per slot; and failover must complete within 60 seconds with no data loss.

3. Development Methodology: Agile Scrum

Developing the PH-PMS requires a methodology that is flexible, adaptive, and iterative, while remaining responsive to stakeholder needs. Agile, implemented through the Scrum framework, was selected as the guiding approach — a decision grounded in the literature on healthcare information projects and the complexity profile of a large-scale hospital information system. Agile development, introduced by the Agile Manifesto (Beck et al. 2001), promotes iterative progress, close cooperation with stakeholders, and continuous delivery of working software; Scrum adds defined roles (Scrum Master, Product Owner, Development Team), time-boxed sprints, and structured ceremonies — sprint planning, reviews, and retrospectives — that impose discipline and maintain momentum (Schwaber & Sutherland 2020).

The evidence for this fit is substantial. Dybå and Dingsøyr (2008) found that Agile practice improves software quality, customer satisfaction, and delivery frequency in patient-facing systems; Hossain, Babar and Paik (2009) observed that Agile enables better handling of requirement volatility and interdepartmental communication in complex, high-risk institutions such as healthcare. Features like patient registration, chatbot integration, and biometric attendance tracking demand phased development and validation, which suits Agile's incremental nature. The feedback-driven loop also keeps end users — doctors, administrative staff, and patients — involved throughout the life cycle, which drives usability and reduces rework when user stories come from real clinical scenarios.

From a risk-management perspective, delivering a potentially shippable increment each sprint reduces the possibility of large-scale failure and surfaces integration, performance, and security issues early — vital for compliance with the Australian Privacy Principles and ISO/IEC 27001, where continuous verification of data handling and access control is mandatory (OAIC 2022; ISO 2022). Finally, Agile aligns with the system's modular technical structure: each major feature — attendance, appointment booking, scheduling — can be developed, tested, and deployed independently, mirroring Agile's modular delivery style (Newman 2015) and supporting the hospital's long-term digital strategy.

4. Requirements Prioritisation (MoSCoW)

MoSCoW prioritisation (Karlsson, Wohlin & Regnell 1998) separates the release-critical core from deferrable enhancements, keeping early sprints focused on the capabilities the hospital cannot operate without.

5. System Design & Modelling

5.1. UML Use-Case View

The use-case diagram is a graphical representation of the interactions between the primary actors and the system as a whole. Patients use the system to sign up, reserve or cancel appointments, learn about doctors, check in at kiosks, and consult the chatbot; receptionists enrol new patients and book on their behalf; doctors schedule visits, update medical records, review patient histories, and weigh in on treatments; and the administrator creates users, departments, and hospital rooms while overseeing system performance. Charting these interactions gives a readily comprehensible picture of what the system does, what each user must do, and how the system facilitates hospital business and patient-care processes.

5.2. Appointment-Booking Sequence

The sequence diagram documents the exchanges between system elements during a typical process — here, booking an appointment. Operations move from the user through Login(), the RBAC-selected panel, and the Database_Handler() into MySQL, following a strict chronological order of function invocations and query results. Displaying the exchanges this way reveals the process coordination and fault-management points, and confirms that the operational requirements are satisfied through reliable communication between components.

5.3. Entity-Relationship Model

The entity-relationship diagram establishes the logical framework of the MySQL database: patients, doctors, departments, appointments, rooms, invoices, and admin/login records, together with their properties and connections. Patients connect to appointments, appointments relate to doctors, doctors are assigned to departments, and rooms are allocated to patients through relational links, while administrators oversee these entities centrally. The design guarantees normalisation, minimises data duplication, and maintains relational consistency — the groundwork for effective data management, access, and expansion.

6. Project Timeline

The Gantt chart organises the seventeen work packages across the Agile release plan, from requirement gathering and database architecture through module development, integration, quality assurance, and launch. Each task maps to a release — Phase 1 delivers the login and access core, subsequent phases layer on enrolment, profiles, appointments, reporting, device integration, the chatbot, and finally the admin panel and production notifications. The chart specifies time frames, task relationships, and checkpoints, providing progress transparency for project participants, facilitating resource management, and exposing possible delays before they cascade.

7. Budget Breakdown & Financial Analysis

Financial planning for the PH-PMS takes a scalable approach that supports the technical facilities, operational stability, and long-term sustainability of the system, reflecting both direct development costs and post-deployment operational expenses. The estimates align with current industry benchmarks for mid-tier hospital IT deployments — especially those incorporating real-time tracking, AI services, and cloud-hosted infrastructure — and with the Agile strategy and twelve-week core delivery window. Sprint-based delivery generates its own cost efficiencies: incremental validation identifies resource drain early and lets priorities be restructured before overruns compound (Beck et al. 2001).

Human capital is the largest cost centre at 83% of the budget. The Agile team comprises software engineers, a database designer, UI/UX design, a Scrum Master/project manager, a QA engineer, and a part-time healthcare-specialist consultant, at Australian IT market rates of roughly A$80–150 per hour. The remaining categories cover development licensing and cloud resources (6%), dedicated hardware for biometric/RFID testing and secure staging (6%), staff training and documentation (3%), and a contingency reserve (2%).

8. Conclusion

The use of Agile methodology for the Pakenham Hospital Patient Management System is strategically sound: it meets the bespoke needs and challenges of developing software in a healthcare context. The phased release pattern exhibits a fine-grained understanding of system architecture, risk, and stakeholder value delivery, while retaining the nimble, responsive characteristics that exemplify Agile at scale. The plan ensures the PMS is not just responsive to current hospital operational requirements but positions Pakenham Hospital for future digital transformation and innovation in healthcare delivery.

The combination of iterative development, continuous stakeholder engagement, and a disciplined QA process establishes a groundwork for lasting healthcare-technology leadership. Success will be measured not only by traditional technical delivery metrics but by the impact on the quality of patient care, the efficiency of clinical workflows, and the agility with which the organisation integrates clinical-practice changes into new and updated applications — proving that effective selection and implementation of software-engineering methodology is itself a strategic investment in healthcare quality improvement and organisational resilience.

Appendix A. Agile Scrum Release Phases

Appendix B. Compliance & Standards

Healthcare compliance: HIPAA-equivalent patient-data protection and privacy; HL7 standards for healthcare data-exchange compatibility; medical-record documentation and retention standards; complete activity logging for audit requirements. Technical standards: Oracle Java coding conventions; ANSI SQL compliance; OWASP security guidelines; IEEE software-documentation standards.

Glossary — API: Application Programming Interface · CRUD: Create, Read, Update, Delete · DAO: Data Access Object pattern · HIPAA: Health Insurance Portability and Accountability Act · JVM: Java Virtual Machine · MVC: Model-View-Controller · RBAC: Role-Based Access Control · SQL: Structured Query Language · UAT: User Acceptance Testing · UML: Unified Modeling Language.

References

1. Beck, K et al. 2001, Manifesto for Agile Software Development, Agile Alliance, https://agilemanifesto.org/.
2. Dybå, T & Dingsøyr, T 2008, 'Empirical studies of agile software development: A systematic review', Information and Software Technology, vol. 50, no. 9–10, pp. 833–859.
3. Hossain, E, Babar, MA & Paik, H 2009, 'Using Scrum in global software development: A systematic literature review', Proceedings of the 4th IEEE International Conference on Global Software Engineering, Limerick, Ireland, pp. 175–184.
4. International Organization for Standardization (ISO) 2022, ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements, ISO, Geneva.
5. ISO 2019, ISO 9241-210:2019 Ergonomics of human-system interaction — Human-centred design for interactive systems, ISO, Geneva.
6. Kamel Boulos, MN & Berry, G 2012, 'Real-time locating systems (RTLS) in healthcare: a condensed primer', International Journal of Health Geographics, vol. 11, no. 25, pp. 1–8.
7. Karlsson, J, Wohlin, C & Regnell, B 1998, 'An evaluation of methods for prioritizing software requirements', Information and Software Technology, vol. 39, no. 14–15, pp. 939–947.
8. Kruse, CS, Stein, A, Thomas, H & Kaur, H 2018, 'The use of Electronic Health Records to support population health: A systematic review of the literature', JMIR Medical Informatics, vol. 6, no. 2, e19.
9. Newman, S 2015, Building Microservices: Designing Fine-Grained Systems, O'Reilly Media, Sebastopol, CA.
10. Office of the Australian Information Commissioner (OAIC) 2022, Australian Privacy Principles (APP) Guidelines, OAIC, Canberra.
11. Pressman, RS & Maxim, BR 2020, Software Engineering: A Practitioner's Approach, 9th edn, McGraw-Hill, New York.
12. Schwaber, K & Sutherland, J 2020, The Scrum Guide: The Definitive Guide to Scrum — the Rules of the Game, Scrum.org.
13. Vaidyam, AN, Wisniewski, H, Halamka, JD, Kashavan, MS & Torous, J 2019, 'Chatbots and conversational agents in mental health: A review of the psychiatric literature', Current Psychiatry Reports, vol. 21, no. 88, pp. 1–7.