Zambia’s Electronic Medical Record – Initial Release

Post Sequence

1. Background
2. Initial Release
3. Patient Flow
4. Reporting Server
5. Version 2.0
6. Continuity of Care
7. (More on the way…)

These are a series of posts on the history of Zambia’s first national Electronic Medical Record or EMR. The EMR was known by a few names: PTS, PMRS, Continuity of Care and finally SmartCare. The EMR was originally targeted at supporting care and treatment of the estimated 17% of the adult Zambian population infected with HIV. The project was successful on a grand scale. It grew to serve the population of Zambia as a general EMR addressing other illnesses such as Tuberculosis, Malaria and general health. It is still in operation today has served millions of patients not just in Zambia but in other African nations as well.

The Original Fork

At the very beginning Zambia’s Electronic Medical record was a fork of another application that was being developed by a American developer based out of South Africa to provide Perinatal care to infants. The original application was built on top of a typed key-value table structure inside of a dynamically built Apache Struts framework. This provided a very flexible foundation for a form based application. The technical details are that it was Java servlet-based application and it was running in Apache Tomcat on top of the ubiquitous MySQL server.

The reason we needed to fork was that the database had no domain orientation. It was based off of dynamically rendered forms. As part of this form orientation there was a section of the application for creating the forms themselves. This made a quick fork of the application very easy. Quickly the developer of the Perinatal system was able to create the original few forms need to capture the required patient data.

However this was as far as the development of the other Perinatal system had gotten. The early focus had been on creating a flexible form creation system. The next step for the Perinatal system was to be able run reports and provide single and cross-patient data aggregation to obtain intelligence about the status of the patient as well as the clinic or hospital.

This is where I came into the picture.

Patient Tracking System (PTS 1.0)

What I was hired to do was to get data out of the system. In fact a month before I had started the system had been operationalized. But it was immediately obvious that while data seemed to be going into the system the two critical reports that needed to be produced could not be. The two governing organizations were:

• Zambian Ministry of Health (Zambian MoH)
• US Centers for Disease Control (US CDC) PEPFAR Reporting Form

The four initial clinics that the system was rolled out to were:

• Kalingalinga
• Kanyama
• Kamwala
• Matero Ref

To developers (or even program managers) out there this should start to sound a little bit like a train wreck. The application was deployed and collecting data, but the very purpose of the application and for the collecting of the data, namely the generation of reports, was not possible.

This was the initial problem I was brought in to solve.

Another Data Model

After analyzing the problem the solution I chose to pursue was the creation of a secondary data model based on domain modeling the data that was being collected. The data structures that emerged were based on the domain such as:

• Clinic
• Patient
• Visit
• Prescription
• Lab Results
• ….

Instead of the previous:

• Form 1 (Initial History & Physical)
• Form 2 (Follow Up Visit)
• Form 3 (ARV Evaluation)
• …

Maintaining double data structures in real time seemed prone to data corruption so the way the reports were run was via an aggregation program which extracted the data which populated the reporting or domain-driven database. The domain-driven database could then be queried to do the required aggregations. The first version of this was via console output and manual copy over into the required forms.

As the project gained traction and word of mouth in the HIV public health community we were asked to present on it from time to time. Below is the document we used at the time of PTS 1.0 which provides a good overview of the system.

Coming Up…

Later I will detail the evolution of this aggregation program and reporting database into a separate application and data source called the Patient Management & Reporting Server (PMRS).

However first I’d like to review the patient flow through the clinics as well as the accompanying forms we were using to capture and document the patient’s health information.