Electronic Health Management System

Background

NUS’s medical overseas community involvement projects (OCIPs) bring student-led healthcare initiatives beyond familiar clinical infrastructure. One example is Project i2Eye, an OCIP led by students from the NUS Yong Loo Lin School of Medicine and based in Madhya Pradesh, India. Such projects may operate temporary clinics across large sites, with patients moving through several screening and consultation stations in sequence.

This environment presents a deceptively difficult systems problem. Clinical work cannot stop when the internet connection does. Different missions may also require different stations, questions, measurements, and routing rules. Meanwhile, multiple field sites may operate independently before eventually combining their records, and medical workflows must remain safe and accountable throughout.

Our Electronic Health Management System (EHMS) was built on CVWO’s Cornerstone platform to address these needs. Its central principle is simple: care must continue even when connectivity does not.

Project i2Eye

Project Objectives

Our team set out to:

• Build configurable patient journeys that can support different medical missions without needing to rebuild the application for each project.
• Keep the system usable across connected, weakly connected, and fully offline environments.
• Support multiple distributed deployments while preventing identifier collisions and silent data loss.
• Provide a complete pharmacy workflow from prescription calculation to batch allocation, packing, and dispensing.
• Preserve central governance, auditability, and data integrity across every deployment.

Key Contributions

1. Configurable Clinical Workflows

EHMS represents each patient encounter as a visit made up of an ordered sequence of stations. Administrators can create reusable visit templates, arrange the stations patients may attend, enable or disable individual stations, and attach custom forms for programme-specific questions and measurements. This allows each medical mission to configure its own screening workflow without requiring changes to the application’s code.

A configurable patient journey

Throughout a visit, EHMS maintains the patient’s profile, medical information, visit history, attachments, and progress through each station. It also supports specialised clinical workflows, including a purpose-built visual-acuity station that calibrates the test for different viewing distances and screen sizes, allowing screenings to adapt to the physical constraints of each site.

Visual Acuity Station

Beyond that, our EHMS can also automatically calculate complex derived values and aggregate metrics from information collected throughout a visit. For example, it can calculate a patient’s body mass index (BMI) from their height and weight, or combine screening results into summary metrics for staff dashboards.

These calculations are configured using a visual expression builder inspired by Scratch. Instead of writing code, administrators combine typed blocks representing form responses, numbers, arithmetic, comparisons, and logical operations. The editor guides users towards valid combinations and identifies incompatible expressions early, making complex calculations and rules easier and safer to configure.

The same expression system also supports conditional routing. Information collected or calculated earlier in a visit can determine which stations a patient should attend next. For example, an abnormal screening result can automatically direct a patient to an additional review station, while someone who does not require follow-up can continue through the standard workflow. This shared system provides an easy, user-configurable foundation for clinical calculations, reporting, and patient routing.

Configuring a visit indication

2. A Local-First Field Architecture

Many rural screening sites have limited or no internet access, making a cloud-hosted system impractical during screenings. We therefore deploy EHMS locally at each site on a Raspberry Pi, which hosts both the application and its database. Staff connect their iPads to the Pi over the site’s local network, allowing the full screening workflow to operate independently of the internet. Once connectivity becomes available again, the local deployment can synchronise its records with the central EHMS server.

Network architecture

However, screening sites can be extremely large, and a normal Wi-Fi router may not be sufficient to cover every station. Hence, we also successfully integrated Wi-Fi HaLow to extend the local deployment’s wireless coverage. HaLow provides a long-range wireless link across the site, allowing stations located farther away to remain connected to the Raspberry Pi and use the same local EHMS system.

Wi-Fi HaLow

Even with this extended coverage, a staff member’s device may still temporarily lose its connection to the local network. EHMS therefore includes an offline Progressive Web App (PWA) as a final fallback. The application automatically caches the pages and station forms required for screening, while records created without a connection are stored locally on the device using IndexedDB. Staff can therefore continue working without interruption. When the device reconnects to the Raspberry Pi or the internet, these records can be synchronised back with the EHMS, and any conflicting changes are presented to the user for resolution. This ensures that the system remains robust and resilient to disruptions.

Offline PWA

3. Safe Distributed Record Creation

Running several independent databases introduces a subtle problem: Cornerstone traditionally used auto-incrementing integer keys, so two disconnected deployments could create records with the same identifier.

EHMS solves this using block-allocated IDs. During secure device registration, the central server assigns each deployment a large, non-overlapping range of identifiers. Each Pi then allocates from its own range locally, without contacting the central server for every new record. A device cannot invent its own range, and registration can be retried safely.

Each block contains one trillion identifiers. Even at 100,000 new identifiers per day, a deployment would take approximately 27,397 years to exhaust its range, while the signed 64-bit identifier space can accommodate more than nine million such blocks.

Registering a distributed client

4. Versioned Synchronisation and Conflict Resolution

Offline operation means that the same patient or visit may be edited at a distributed site while its central record is also being changed. EHMS avoids a silent “last write wins” policy by synchronising versioned aggregates: a patient or visit is transferred together with the records it owns, so the snapshot remains internally coherent. Using this, we have essentially implemented our own distributed version control system.

Every synchronised aggregate tracks its current version and the central version last seen by the device. When a Pi submits a local change, the central server locks the aggregate and compares its current version with the submitted base version:

• If the versions match (or the snapshots are already equal), the central server applies the snapshot, advances the authoritative version, records the change, and acknowledges the device.
• If the versions differ, neither side is silently overwritten. EHMS stores the central snapshot alongside the current local state as a conflict, and asks staff to keep either the central or local version.
• Choosing the central version applies that snapshot locally. Choosing the local version re-versions the local state so it can be retried through the ordinary synchronisation process.

Synchronisation requests are retryable and carry protocol-version and schema-fingerprint checks. A cursor also allows each Pi to request only central changes it has not yet applied. Transactions, repeatable reads, and row locks protect the comparisons and multi-table snapshots from concurrent edits.

Synchronisation also allows each Raspberry Pi to receive the latest centrally managed configuration. This includes changes to user accounts, visit templates, and other system-wide settings. By distributing these updates from the authoritative central server, EHMS keeps every local deployment consistent while preserving its ability to operate independently when offline.

EHMS Sync

5. Prescription and Pharmacy Safety

The pharmacy is deceptively complex because it must convert clinical instructions into discrete movements of physical stock. Doctors prescribe medication in clinical terms — for example, “500 mg twice daily for seven days” — while pharmacy staff manage physical stock as tablets, bottles, vials, and other dispensing units. EHMS must translate accurately between these two representations.

The calculation also varies between medications. A solid medication may contain 500 mg per tablet, while a liquid medication may contain 250 mg in every 5 mL and be stocked by the bottle. The final quantity depends on the prescribed dose, medication strength, frequency, treatment duration, as-needed instructions, and the smallest dose that can be administered.

To perform this translation safely and consistently, EHMS processes every prescription through a structured calculation and validation pipeline:

1. Normalise the entered dose into the drug’s base unit.
2. Confirm that it is compatible with the drug and is a multiple of its smallest usable dose.
3. Convert the base amount into dispense units.
4. Calculate the number of administrations from frequency and duration.
5. Round up safely to a whole stock unit.

The frontend provides immediate feedback, while the backend independently repeats and validates the calculation. A clinician can explicitly override the calculated quantity when necessary, but that choice is explicitly represented in the record rather than occurring silently.

EHMS manages the entire physical workflow after a prescription is created, from allocating stock batches to packing and final dispensing. During allocation, the system verifies that every selected batch contains the prescribed medication and prevents staff from allocating more than the required quantity. It then records who packed each item and when, and dispensing cannot proceed until every item has been packed.

The final dispensing step is completed as a single database transaction. EHMS locks the relevant prescription and stock records, verifies that sufficient stock remains, deducts the dispensed quantities, and records who completed the transaction and when. These locks prevent two concurrent requests from dispensing the same stock based on an outdated quantity. Once dispensing is complete, the prescription becomes read-only, preserving an accurate and auditable record of what was issued.

Prescription management

Project Team

• Saripalli Bhagat Sai Reddy (Project Lead, Year 2)
• Arjo Das (Developer, Year 1)
• Wang Ruiduan (Developer, Year 1)
• Lim Chuan Hao (Developer, Year 1)
• Le Xuan Son (Developer, Year 1)
• Vu Dang Khoa (Developer, Year 1)

Afterthoughts

Leading EHMS taught me that meaningful engineering begins with understanding the environment in which a system will be used. Designing for clinics with unreliable connectivity challenged us to think beyond individual features and build a complete, resilient system that healthcare teams can depend on in the field. I am deeply grateful to my teammates for their dedication, creativity, and willingness to tackle every difficult problem together.

– Sai

Working on EHMS showed me how quickly an apparently simple workflow can become a complex engineering problem when it involves real patients, multiple devices, and unreliable networks. It was rewarding to turn those constraints into practical solutions and to know that our work could make medical screenings more organised and dependable.

– Arjo

This project taught me that robust software is not only about making the normal path work, but also about preparing for everything that can go wrong. Building features around offline operation, synchronisation, and conflict resolution helped me appreciate the care required to protect important data in real-world systems.

– Ruiduan

EHMS gave me the opportunity to work on problems where technical correctness has a direct operational impact. Whether we were validating clinical workflows or ensuring that pharmacy stock was updated safely, every design decision required us to consider how the system would behave when people relied on it during an actual screening.

– Chuan Hao

I joined CVWO hoping to improve my technical skills, but I also learnt how important communication and teamwork are when building a large system. Working closely with the team to understand unfamiliar healthcare processes and translate them into usable features made this project both challenging and meaningful.

– Son

Working on EHMS changed the way I think about software engineering. I am grateful to have contributed to a project with such a clear real-world purpose.

– Khoa

Acknowledgements

We would like to express our heartfelt gratitude to the individuals and organisations whose guidance and field experience shaped this project:

• GIC for their generous support
• Prof. Ben Leong (NUS) for his guidance and mentorship
• The NUS medical OCIP teams and community partners who helped us understand the realities of field healthcare