Data Modeling

1. Introduction

Good health is not a luxury. It is, arguably, the single condition that everything else in a person's life depends on — earning a living, raising a family, simply getting through an ordinary day — and it is for this reason that health has long been treated as central to how a country pulls itself out of poverty and moves toward genuine socioeconomic progress (Abd-Ali et al., 2018). That said, the human body itself resists easy description. It is a sprawling, interlocking system of processes, many of which are still not fully understood even after centuries of inquiry. What we do know, we have learned mostly through patient observation, experimentation, and no small amount of trial and error. Over time, this slow accumulation of medical knowledge hardened into something more formal: a distinct scientific discipline, supported by institutions whose entire purpose is to test, refine, and apply what researchers discover. Hospitals, laboratories, and university-affiliated research centers now make up the backbone of a health sector that, at least in principle, exists to give people better treatment and a fairer chance at recovery.

Underpinning almost all of this is one deceptively simple thing: the patient record. A well-kept record does more than store a name and a diagnosis — it preserves the shape of a person's medical history, accurately enough that a clinician meeting the patient for the first time can still make sense of what came before. And yet, despite how obviously important this sounds, a great many hospitals — including, somewhat surprisingly, hospitals attached to universities — are still keeping this information on paper. Not digitized paper, not scanned paper. Actual paper, filed away in cabinets, subject to loss, misfiling, and decay. Asabe and Oye (2013) made much the same point back in 2013, and it remains, more than a decade later, an uncomfortably accurate description of how many institutions still operate. A paper-based system is not merely inconvenient; it actively works against the kind of care hospitals are supposed to provide, and in that sense it has become something of an anachronism that the sector has been slow to retire.

Bangladesh's health care system is not exempt from this pressure — if anything, the opposite is true. Like many developing nations, it is contending with a rising demand for medical services that its existing infrastructure was never quite built to absorb. Every patient who walks through a hospital door generates a history that, in theory, should be captured precisely and kept safe for whenever it is needed again. In practice, whether that happens often comes down to whether the hospital in question has moved beyond paper at all.

University hospitals occupy a peculiar and, frankly, underappreciated place within this picture. They are woven tightly into the daily rhythm of campus life — students fall ill, get injured, need prescriptions renewed, and these hospitals are usually the first and most convenient point of contact. It was this closeness, this sense that a university hospital's efficiency has a direct bearing on the wellbeing of the people who depend on it day to day, that motivated the present research into an Integrated Digitalization Health Platform built specifically for the university hospital context. The manual alternative, whatever its historical merits, is slow and prone to error in ways that are entirely avoidable with modern tools.

Consider a small, almost mundane scenario, the kind that likely plays out on university campuses more often than anyone would like to admit. A hospital employs three doctors — two men and one woman, say — each keeping their own hours and their own office. A student comes in with an illness, is seen by Doctor A, receives a prescription, and Doctor A files a copy away in his own office, as one does. Some days later, the same student returns with the same complaint, only to find Doctor A unavailable and Doctor B on duty instead. Now the student has to start over: explain the symptoms again, describe what was already prescribed, hope the details are remembered correctly. And if, on top of that, the original prescription slip has been misplaced — which, given how these things go, happens more than it should — there is no institutional memory to fall back on. Doctor A's records stay with Doctor A. The student is left to reconstruct their own medical history from memory, which is neither fair to them nor particularly safe from a clinical standpoint. It is a small failure in isolation, but repeated across a student body of thousands, it becomes a structural weakness — one that a fragmented, paper-bound record-keeping approach makes almost inevitable.

This is, in essence, the gap the present work tries to close. Rather than accept the manual system's inefficiencies as simply the cost of doing business, this research proposes an online hospital management system built for the university context — one designed, deliberately, to be no more complicated than it needs to be. The underlying goal is not novelty for its own sake; it is to make routine hospital operations systematic, computerized, and, above all, easier for the people who rely on them, replacing a manual process that is costly and time-consuming with something considerably more dependable.

It would be misleading, however, to suggest this research starts from a blank slate. A fair amount of groundwork already exists. Abd-Ali et al. (2018) argued for the necessity of well-designed, web-based healthcare management systems suited to private hospitals, public hospitals, and university clinics alike, while Abdulla et al. (2017) took a step back and mapped out the broader landscape of hospital management information systems, identifying the internal and external stakeholders such systems must ultimately serve. Akpojaro and Orau (2019) went further still, sketching a conceptual model for integrated health-monitoring information, though not without acknowledging that such ambition tends to come at a cost — implementation can be expensive, and slower than anyone would prefer. Bansler et al. (2016) offered a more sobering observation: patient records, once they accumulate across years or decades and sprawl across multiple locations, become genuinely difficult to navigate, however carefully they were originally kept, simply because of their sheer volume and disorganization.

Other researchers have approached the problem from more technical angles. Brown (2009) demonstrated that electronic clinical information systems improve both the accuracy and the reliability of health-related data, provided that data-entry practices and staff training keep pace with the technology. Ghazvini and Shukur (2013) turned their attention to security, examining how well modern e-health systems actually protect the records they hold. Harrington and Saloner (2008) built a fully compatible hospital administration system as part of an Ashesi University capstone project — a system not without its flaws, since a power failure could disable its sensors entirely, and its reliance on Wi-Fi introduced its own delays. Ilo et al. (2015) developed something comparable for a university clinic in Nigeria, though their spiral-development approach reportedly took longer, and cost more, than initially hoped. Adetola et al. (2021) pursued a similar aim for a different institution's health center, while Kaur and Grover (2013) built an online system capable of handling records and billing but stopped short of supporting mobile access or online appointments — a gap that, notably, still needs addressing.

Elsewhere, Laubbel (2008) offered a useful reminder that a "medical record" is not just a folder of paper but the entire body of data that constitutes a patient's health history, and that shifting this to computer-based systems tends to standardize care and reduce costs. Mali et al. (2020) built on this logic with a paperless, patient-centered platform, while Miller (2004) traced how growing government attention to health care has, over decades, shaped national policy around cost, quality, and access. Ripan and Mostakim (2017) constructed a system using standard web technologies but found it, too, fell short on mobile compatibility, and Salomi and Fabio (2017) documented measurable efficiency gains at a hospital that reduced its paper usage by 60 percent after digitizing its clinical processes. Sani et al. (2017), Sawaneh et al. (2018), Sikiru and Oyekunle (2021), and Sobowale et al. (2011) round out this body of work, each contributing evidence that computerized patient-data management, however it is implemented, tends to outperform its paper-based predecessor.

Taken together, these studies point toward a fairly consistent conclusion: digitization helps, but no single system so far has managed to bring every relevant piece — appointments, billing, records, prescriptions, and communication — together under one roof, particularly within the specific constraints of a university hospital setting. That is the space this research occupies. What follows is an attempt to design a platform that is comprehensive enough to matter and simple enough to actually be used.

2. Methods

2.1 Overview and Development Approach

Building a hospital platform is, in some ways, less about writing code and more about making a long series of small decisions correctly — who gets access to what, where a record lives once it's created, what happens when someone forgets a password. With that in mind, the system described here was developed following a fairly conventional, if deliberately unglamorous, three-tier design: a browser-based front end, a server-side logic layer, and a relational database sitting underneath both. This is not a novel architecture — it echoes what Abdulla et al. (2017) described when mapping the general shape of hospital management information systems, and it is close to what Kaur and Grover (2013) used in their own online hospital information system, though, as will become clear, this project tries to close a few of the gaps that earlier attempts left open, particularly around mobile compatibility and integrated appointment booking (Kaur & Grover, 2013).

The platform was implemented using PHP for server-side scripting, JavaScript for interactive front-end behavior, and MySQL for data persistence. This combination was chosen less for novelty and more for reliability: MySQL, in particular, offers a mature, well-documented way of storing structured hospital data — patient details, appointment slots, prescriptions — without requiring exotic infrastructure that a university hospital's IT department would struggle to maintain. Ripan and Mostakim (2017) built a comparable system using PHP, JavaScript, jQuery, HTML, and CSS, and while their design was ultimately found to be incompatible with mobile applications, the present system was designed from the outset with that limitation in mind, aiming for a lighter, more portable interface.

2.2 System Architecture: Three Interlocking Modules

Rather than build one monolithic application, the platform was structured around three distinct modules — Admin, Doctor, and Patient — each with its own login pathway and its own scope of permitted actions ( Figure 1). This separation is not merely organizational; it reflects a design principle borrowed, in spirit, from earlier hospital information system work emphasizing that different stakeholder groups — administrative staff, clinicians, and patients themselves — require fundamentally different views into the same underlying data (Abdulla et al., 2017). Each module authenticates independently, and no user can act outside the permissions attached to their assigned role.

2.3 Admin Module

The Admin module functions as the system's control center. Administrators can add or remove users, adjust access levels, and configure the platform's underlying settings. Perhaps more importantly, only an administrator can create a doctor profile — populating fields for specialty, consultation fee, assigned room, and contact details — since doctors, in this design, are treated as employees managed centrally rather than self-registering users. This mirrors, at least loosely, the administrative-control emphasis found in Harrington and Saloner's (2008) Ashesi University system, though the present implementation was built to avoid one of that system's more consequential shortcomings: a dependence on physical sensors (for vitals and bed occupancy) that failed outright during power outages. Here, all administrative actions run through the web application layer itself, with no hardware dependency that could be knocked out by a single point of failure.

2.4 Doctor Module

Once logged in, doctors can view and update the records of patients assigned to them, confirm new registrations, schedule appointments, and generate prescriptions. They can also edit their own profile information — consultation fees, room assignment, contact details — without needing to route every small change through an administrator. The intent here, consistent with what Brown (2009) found regarding electronic clinical information systems, was to keep data entry simple enough that accuracy doesn't depend on extraordinary effort from clinical staff; a system that is difficult to update correctly tends, eventually, to be updated incorrectly, or not at all.

2.5 Patient Module

New patients register through a self-service account creation process, after which a confirmation prompt directs them to log in with their newly created credentials — a lightweight verification step intended to reduce the chance of duplicate or fraudulent accounts. Once authenticated, patients can browse doctor profiles, check appointment availability, book a consultation slot, and view prescriptions issued to them. This design choice — giving patients direct, unmediated access to their own records — reflects the broader shift Laubbel (2008) described from paper-bound recordkeeping toward computer-based records, a shift generally associated with better care standardization and lower long-term costs (Laubbel, 2008).

2.6 Login and Authentication Procedure

Each of the three user categories — admin, doctor, patient — is presented with a visually consistent but functionally separate login form, requiring the user to first select their module before entering credentials. On successful authentication, the database retrieves the relevant records and renders them to the user. Passwords can be changed at will, and a recovery mechanism exists for forgotten credentials, verified against information already stored in the system. It is a modest feature set, admittedly, but a deliberately modest one: login security here is meant to be robust without becoming a barrier to routine use, a balance Ghazvini and Shukur (2013) identified as a persistent tension in e-health system design — protecting sensitive medical data while keeping the system usable for people who are, often, not particularly technical.

2.7 Generating Unique Patient Identifiers

Every patient and doctor in the system is assigned a unique identifier upon registration (see Figure 2). This was, in many respects, a non-negotiable design

Fig. 1. System architecture of the Integrated Digitalization Health Platform, showing the three interconnected user modules — Admin, Doctor, and Patient — and the flow of information between them. Each module represents a distinct login pathway with role-specific permissions: the Admin module oversees user management and system configuration, the Doctor module supports patient record access and prescription management, and the Patient module enables appointment booking, record viewing, and provider communication.

Fig. 2. Workflow for generating a unique patient and doctor identifier at the point of registration. The identifier links each user's records across all system modules, preventing confusion between individuals with identical or similar names and supporting accurate, traceable medical record-keeping throughout the platform.

requirement rather than a nice-to-have. Sobowale et al. (2011) found that an earlier electronic health information system failed, in practice, because no distinct key was ever assigned to patient information — an oversight that made it functionally impossible to track individual patient data with confidence once records began to accumulate. The unique-ID approach adopted here was built specifically to avoid repeating that mistake. Beyond simply preventing confusion between two patients who happen to share a name, the identifier improves the completeness and accuracy of medical records, supports clearer communication between providers, reduces the likelihood of medication errors, and offers a modest layer of privacy protection by allowing records to be de-identified where appropriate.

2.8 Core Functional Modules

2.8.1 Digital Medicine and Prescription Records

Migrating prescription and medication history from paper to a digital record was treated as one of the platform's central functions rather than an add-on. Digitized medicine records reduce the duplicate filing and manual retrieval that paper systems require, and — perhaps more usefully — they can be shared between providers instantly rather than physically transported. Mali et al. (2020) pursued a broadly similar goal in their paperless, patient-centered system, built specifically so patients would no longer need to carry physical history documents with them; the present platform extends that logic by allowing patients to download a formatted PDF of any prescription directly from their account.

2.8.2 Telehealth: Audio and Video Consultations

An integrated audio/video calling feature was included to support remote consultations — useful for patients who cannot easily travel to campus, or who need a follow-up that doesn't warrant an in-person visit. This functions both as a full telehealth appointment channel and as a lighter-weight option for specialist consultations that would otherwise require physical travel. The expected benefits — convenience, reduced travel cost, improved rapport between patient and provider, and shorter effective wait times — align with findings from Salomi and Fabio (2017), who documented measurable efficiency gains, including a sizable reduction in paper usage, following the digitization of clinical workflows at a European university hospital.

2.8.3 Emergency Call Handling

The emergency-call component captures a caller's identifying information and the nature of the emergency, then determines whether ambulance dispatch is warranted. Where feasible, the interface is designed to surface a location indicator so responders can be directed with minimal delay — a detail that matters considerably in situations where minutes make a clinical difference. This general approach — rapid identification and routing rather than manual triage over the phone — is consistent with the emphasis on data accuracy and reliability that Brown (2009) associated with well-designed clinical information systems.

2.8.4 Hospital–Ambulance Communication

To support continuity of care during transport, the system allows bidirectional information exchange between hospital staff and ambulance personnel: the hospital can relay a patient's known history and condition to responders in transit, while the ambulance can transmit real-time updates back to the hospital so that staff can prepare appropriately before arrival. The intended outcomes here — better-coordinated assessment, reduced transport delay, fewer communication errors, and more efficient allocation of hospital resources such as bed availability — follow the same logic that underpinned Sani et al.'s (2017) evaluation of hospital information standards, where fragmented recordkeeping was repeatedly identified as a source of delay and, occasionally, avoidable harm (Sawaneh et al., 2018).

2.9 Doctor Management

Administrators can add new doctor profiles by entering credentials, contact information, and scheduling details, after which doctors can be assigned to specific patient cases with progress tracked over time. This module also supports lightweight reporting — surfacing workload and performance data that administrators can use to redistribute cases or identify bottlenecks, a function broadly consistent with the stakeholder-oriented system design Abdulla et al. (2017) recommended for hospital information systems more generally.

2.10 Enquiry and Communication Module

Finally, an enquiry module allows patients and their families to search for a specific doctor by name, specialty, or location, request particular services such as laboratory testing, and submit general questions or feedback, all of which are routed to the appropriate staff member for a response. Patients can subsequently track the status of their enquiry rather than being left to wonder whether it was received at all — a small feature, perhaps, but one that Abd-Ali et al. (2018) suggested is often what separates a merely functional web-based hospital system from one that patients actually trust.

2. 11 Reproducibility Considerations

For transparency and to support replication by other research groups, the technical environment is summarized as follows: server-side logic implemented in PHP; client-side interactivity handled via JavaScript; data storage and retrieval managed through a MySQL relational database; and the interface rendered through standard HTML/CSS templates accessible via any modern web browser, without dependence on proprietary hardware or specialized sensors. No patient-identifiable data were used in system testing; all records referenced during development were synthetic, constructed solely to validate module functionality, login behavior, and database read/write operations across the Admin, Doctor, and Patient modules described above.

3. Results

3.1 From Manual Process to Automated Workflow

Once the platform was fully assembled, the first thing worth reporting — almost the most basic test of whether any of this was worth building — is that it actually did what it was meant to do: pull the university hospital away from a paper-dependent workflow and into something automated, searchable, and considerably less prone to human slip-ups. Data moves in both directions between the interface and the underlying database — retrieved when needed, written back once updated — and this two-way exchange forms the backbone of nearly everything the system does. It is, admittedly, not a flashy result. But it is the foundational one, and without it the rest of the platform's features would have very little to stand on.

3.2 Appointment Booking in Practice

The appointment process turned out to be one of the more instructive parts of testing. A patient selects "book an appointment," which routes them to a form collecting basic contact and address details before advancing to the actual slot-booking screen. From there, the patient sees a list of available doctors and can choose a time based on personal preference rather than being assigned one arbitrarily. This step relies on an interactive grid table, built with JavaScript, that pulls live availability data from the PHP-and-MySQL backend — meaning what the patient sees on screen reflects, in near real time, what is actually stored in the database, rather than a static or cached snapshot that might drift out of sync. Booking itself takes a single click once a slot has been selected. Compared with the manual alternative — phone calls, waiting lists, handwritten scheduling books — this is, frankly, not a subtle improvement. It is worth noting that this addresses a gap identified in earlier work: Ripan and Mostakim (2017) developed a comparable HMS but found their design incompatible with mobile applications, and Kaur and Grover (2013) similarly could not integrate online appointment scheduling into their system at all. The present platform was tested specifically to confirm that both limitations had been resolved, at least within the scope of the current implementation.

3.3 Access Differentiated by Role

Once an appointment is booked, the three user roles interact with that same underlying data quite differently, which was by design rather than accident. Administrators can view records both from a local host environment and from within the deployed system itself — a dual-access arrangement intended to support oversight without requiring a separate reporting tool. Doctors, by contrast, see appointment information only within the system's patient-facing appointment page, scoped to their own assigned cases rather than the hospital's full patient list. This distinction matters more than it might first appear; it reflects the same stakeholder-specific access logic that Abdulla et al. (2017) argued hospital management information systems generally require, where internal and external users need meaningfully different views of the same dataset rather than a single undifferentiated interface.

3.4 Unique Identifiers and Record Integrity

Every doctor and every patient registered in the system is issued a unique identifier at the point of account creation (Figure 2). This was tested deliberately with records containing duplicate or near-duplicate names, since that scenario is, in practice, exactly the kind of situation earlier systems struggled to handle. Sobowale et al. (2011), for instance, reported that their electronic health information model could not reliably track patient data because no distinct key had been assigned to each record — an issue the present system was built specifically to avoid. In testing, records with identical patient names remained cleanly distinguishable by identifier alone, which suggests — though this would benefit from larger-scale validation — that the underlying indexing approach holds up reasonably well even under conditions likely to produce confusion in less carefully structured systems.

3.5 Prescription Access and the Feedback Loop

Patients are able to download their prescriptions directly in PDF format, removing the need to physically carry, or worse, misplace, a paper slip between visits — a small feature, perhaps, but one that speaks directly to the recurring "lost prescription" scenario that partly motivated this research in the first place. Alongside this, a feedback mechanism was built into the system, most visibly through a "contact us" form, allowing patients to flag concerns or suggest improvements directly to hospital administration. This closes what might otherwise be a one-directional relationship between patient and system, giving administrators a continuous channel for identifying where the platform, or the hospital's broader service delivery, might still be falling short.

3.6 Positioning Against Prior Systems

Taken as a whole, the results suggest the platform performs its intended functions — registration, scheduling, record-keeping, and communication — within a single integrated environment, addressing several shortcomings documented in earlier hospital management research. Where Sikiru and Oyekunle (2021) noted that their otherwise functional web-based HMS could not support appointment rescheduling, and where Harrington and Saloner's (2008) system risked losing functionality entirely during a power failure due to its dependence on physical sensors, the present system's reliance on a purely web-based architecture (Figure 1) appears, at least in initial testing, to avoid both of these specific failure modes. Whether this holds under the kind of sustained, high-volume use a real university hospital would generate is a separate question — one the Discussion section returns to — but within the scope of the testing conducted here, the results are, on balance, encouraging.

4. Discussion

4.1 What This Platform Is, at Its Core

It's probably worth stepping back, before going further, to say plainly what this paper actually offers: a working concept for an automated university hospital management system — the Integrated Digitalization Health Platform — built around three modules that, together, are meant to replace the fragmented, paper-heavy way many university clinics still operate. The schematic relationships between these components (Figure 1) are not merely illustrative; they represent, in a fairly literal sense, the map that guided implementation, showing how the Admin, Doctor, and Patient modules pass information between one another and where the boundaries of each role's access begin and end. Senior administrative staff retain the broadest set of privileges, since the system's overall integrity ultimately rests with them. Doctors work within a narrower, clinically focused space — diagnosing, prescribing, updating histories — and that data, notably, is held under the same confidentiality expectations one would assume for any patient record, digital or otherwise. New patients, meanwhile, enter the system through registration and are immediately assigned the unique tracking number discussed earlier, which is what allows their information to be followed consistently from that point forward.

4.2 Everyday Functions, Reconsidered

There is a temptation, when describing a system like this, to focus only on its more dramatic capabilities — telehealth, emergency routing — and skip past the mundane ones. But the mundane ones are arguably where the manual system failed most often, and so they deserve at least equal attention here. Adding a doctor to the platform, for instance, is a short administrative task: a name, credentials, contact details, entered once by an authorized staff member. Booking an appointment is similarly straightforward — available at any hour, through the website or app, rather than confined to a receptionist's working hours. Making an enquiry, likewise, no longer requires tracking down the right department by phone; a patient can ask through the call center, the website, or the app and expect a reasonably prompt answer. None of this is conceptually new. What is different, compared with the manual process this research set out to replace, is that these small interactions used to depend on paper records, manual re-entry of the same information, and communication gaps between departments that, more often than one would like, led to avoidable mistakes.

Two features seem worth dwelling on a little longer. Generating a unique identifier for each patient, discussed already in the Results, does more than prevent name confusion — it is, in a fairly direct sense, the mechanism that lets the rest of the system function reliably at all, since nearly every module ultimately keys its data off that identifier. And maintaining digital medicine records — tracking allergies, current medications, dosages — exists specifically to reduce the kind of medication error that a busy, understaffed clinic relying on handwritten notes is, unfortunately, prone to. Audio and video consultation, meanwhile, extends the system's reach beyond the physical hospital building entirely, supporting telehealth appointments for patients who, for whatever reason, cannot make it to campus in person.

4.3 Measuring Up Against What Came Before

It would be a little dishonest to present this platform as arriving in a vacuum, so it's worth situating it against what similar efforts have already tried and, in some cases, struggled with. Salomi and Fabio (2017) documented genuinely striking gains at Universitätsklinikum Hamburg-Eppendorf, where a near-complete transition to computerized clinical processes brought about a 60% drop in paper usage — a figure that, frankly, sets a fairly high bar for what "successful digitization" can look like in a hospital setting. Whether the present platform could approach anything comparable at true operational scale is genuinely unclear, and this paper does not claim otherwise; what it does claim, more modestly, is that the underlying architecture was built with that kind of outcome in mind.

Other comparisons are less flattering to earlier systems, if that's not too blunt a way to put it. Sobowale et al. (2011) found that a lack of unique patient keys made their electronic health model unreliable for tracking data — the exact failure mode this platform's identifier system was designed to avoid. Sikiru and Oyekunle (2021) built a functional web-based HMS that nonetheless could not support appointment rescheduling, and Harrington and Saloner's (2008) Ashesi University system, however well-intentioned, could lose core functionality entirely during a power outage because of its dependence on physical sensors. Kaur and Grover (2013) got quite far — automated billing, patient records, staff administration — but ultimately could not fold mobile access or online appointments into their design. Taken together, these gaps form something like a checklist of problems the present platform was, at minimum, designed to address, even if confirming that it does so under real hospital conditions remains, for now, a task for future implementation rather than this paper.

4.5 Where the Manual System Still Falls Short

It's tempting to think of "paper versus digital" as a somewhat abstract debate, but the manual process's shortcomings are concrete enough to name directly: paper-based medical records that can be lost, duplicated, or simply misfiled; manual data entry that introduces transcription errors nobody notices until it matters; poor communication between departments that share the same patient but not, apparently, the same information; and, as a consequence of all this, a measurably higher risk of medical error. Bansler et al. (2016) made a related point about paper records more generally — that once they accumulate across years and multiple locations, they become genuinely difficult to browse or make sense of, regardless of how carefully they were originally filed. That difficulty compounds over time in a way that a searchable digital record, whatever its own imperfections, simply does not.

4.6 Evaluating the System's Standing

So, does the platform hold up against these standards? On the evidence gathered so far — the module structure (Figure 1), the identifier scheme (Figure 2), and the functional testing described in the Results section — the answer leans toward yes, at least provisionally. The system appears usable across the range of university clinic and hospital settings it was designed for, capturing genuine patient information and storing it in a form that both the hospital and the patient can draw on later. Set against a paper-based predecessor that is, by comparison, slow, error-prone, and incapable of producing an updated patient list within any reasonable timeframe, the intended benefit here is fairly direct: less time spent on paperwork, and more patients seen accurately and efficiently. Whether that benefit materializes at the scale and pace suggested by comparable efforts — Salomi and Fabio's (2017) hospital-wide efficiency gains, or the broader push toward standardization Laubbel (2008) associated with computer-based patient records — is a question this paper can gesture toward but not fully answer on its own. That, more than anything else, is the honest limitation to carry into the recommendations that follow.

4.7 Recommendation

Given all of this, the recommendation offered here is fairly measured rather than sweeping: university hospital administrations should be encouraged, and perhaps gently pushed, to move away from manual recordkeeping toward web-based platforms of this kind. This is, admittedly, not a new argument — versions of it have circulated in the health informatics literature for well over a decade (Miller, 2004) — but the twenty-first-century case for making the switch has, if anything, only strengthened. The Integrated Digitalization Health Platform proposed here is offered as one reasonable starting point for institutions ready to make that transition, rather than as a finished, universally optimal solution.

5.  Conclusion

This work set out, fairly modestly, to answer a specific question: can a university hospital's day-to-day operations be meaningfully improved by moving away from paper and into an integrated digital platform? The evidence gathered here suggests, cautiously, that the answer is yes. Across its three modules, the system appears to reduce the kind of human error and record fragmentation that manual processes tend to invite, while shortening the practical distance between a patient needing care and a doctor able to provide it. Unique identifiers, digital prescriptions, and appointment automation all point toward the same broader outcome — a hospital that runs on searchable, dependable data rather than scattered paper files. What remains is implementation at real scale, supported by adequate ICT infrastructure, and that step has deliberately been left for future work.

Acknowledgment

I would like to extend my heartfelt gratitude to my supervisor, Dr. Prof. Khondaker Abdullah Al Mamun, for his guidance, support, and encouragement throughout my research. I am also grateful to my colleagues who provided me with valuable insights and feedback. I would like to thank my family and friends for their unwavering support and encouragement; their love and encouragement kept me going during difficult times. Lastly, I would like to acknowledge the Department of Computer Science and Engineering, United International University, for the opportunity to pursue my knowledge and conduct my research during my master's program.

Author Contributions

U.A.S. conceived and designed the study, developed the system architecture and the Admin, Doctor, and Patient modules, conducted testing and validation, analyzed the results, and drafted the manuscript. K.A.M. supervised the study, provided critical guidance on system design and methodology, and critically reviewed and revised the manuscript. Both authors read and approved the final manuscript.

Competing Financial Interest

The authors U.A.S. declare no competing financial interests.

References