A patient-centred EHR system for connecting fragmented healthcare records
Many reputable healthcare facilities in Nigeria have already digitized their clinical records. The larger problem is that these systems often operate in isolation. A patient's history may be complete within one hospital's EHR, but that information does not necessarily follow them when they receive care elsewhere.
MedSync was built around the idea that a patient's medical history should follow the patient, not the hospital. It is a SaaS-based Electronic Health Records platform designed to give healthcare providers a unified view of a patient's care across participating facilities, while keeping access tightly controlled around clinical roles and responsibilities.
The project also served as the practical implementation component of my research into what a centralized, interoperable EHR could look like in a developing healthcare system. That meant looking beyond the software itself and considering interoperability, privacy, clinical workflows, adoption, and the operational realities of Nigerian healthcare.
The problem
Healthcare providers can have sophisticated EHR or EMR systems while still operating as isolated data silos. When a patient moves between facilities, their previous records may not be available to the new provider, even when both facilities already have digital systems.
This creates problems throughout the patient journey:
Doctors may not have access to previous diagnoses, medications, or investigations from another facility.
Patients may have to repeatedly provide the same medical history.
Laboratory results can remain disconnected from records maintained by other providers.
Emergency treatment can be more difficult when the treating facility has no access to the patient's previous history.
Providers have limited visibility into a patient's care when that care is distributed across multiple facilities.
How MedSync works
The system is structured around three groups: healthcare facilities, healthcare professionals, and patients.
Hospitals can onboard onto the platform and configure their organization, departments, and users. Administrative users have oversight of the facility and can manage access without having to manually configure an entirely separate system for every new deployment. This was very important to the product model as a connected EHR only becomes useful when bringing another healthcare provider into the network is practical.
Doctors get a clinical workspace centered around their patients rather than around isolated encounters. A patient's record can bring together their medical history, diagnoses, consultations, laboratory results, appointments, and other relevant information into a longitudinal view. Access is deliberately scoped. A doctor does not simply gain unrestricted access to every patient's information because they are part of the same organization. Patient assignment and permissions determine what they can access.
Laboratory workflows have their own role-specific interface. Staff can work with investigations and attach results to the appropriate patient record, allowing laboratory information to become part of the patient's broader clinical history instead of remaining as a separate workflow.
Patients have their own view of their records and interactions with healthcare providers. They can maintain continuity across facilities rather than treating every hospital visit as an entirely new medical history. Messaging is also built into the platform because healthcare coordination does not stop at documentation. Some interactions require communication between patients and providers outside the formal clinical record.
Access control and privacy
Centralising health records introduces an important tradeoff. Making information easier to access is useful, but making it universally accessible is dangerous. MedSync therefore treats permissions as a core part of the system rather than an afterthought. Different roles have different capabilities, with access determined by the user's relationship to the patient and their responsibilities within the healthcare facility. Administrative, clinical, laboratory, and patient experiences are separated accordingly.
The system also incorporates auditing so that activity around patient records can be tracked. This provides an important foundation for accountability in a system handling sensitive medical information.
The design was informed by healthcare data protection and interoperability requirements, including considerations around GDPR, FHIR, HL7, and SNOMED CT.
AI, but deliberately constrained
One of the more experimental parts of MedSync is its AI assistant. The goal was not to build a chatbot that gives patients generic medical advice. Instead, the assistant is scoped to support doctors using information already available within a patient's record.
Clinical documentation is a significant source of administrative overhead, so the assistant was designed as a support layer around existing patient data. Its context is grounded in the patient's records and the current clinical workflow rather than an open-ended conversation detached from the patient's history. The prototype therefore treats AI as an assistive capability, not as a replacement for clinical judgement.
Engineering the prototype
MedSync uses a Django backend with PostgreSQL and a React TypeScript client, previously deployed on AWS. The application is structured around the different workflows and permissions within the healthcare system rather than treating the application as one generic dashboard. This allows the same underlying patient record to support very different experiences for doctors, laboratory staff, administrators, and patients.
Where it could go next
MedSync is currently a working prototype rather than a production healthcare system. Its purpose was to turn the research and architectural ideas into something tangible that could be tested, challenged, and extended. The next stage would be making interoperability a first-class capability through deeper adoption of standards such as FHIR, alongside stronger consent management, more granular clinical permissions, production-grade security and external auditing.
The AI layer would also require substantially more validation before being used in real clinical environments. Any system that influences clinical workflows needs strong safeguards, transparent boundaries, and meaningful human oversight.