Zambia’s Electronic Medical Record – Reporting Server

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.


First a little background (it would be best to read these posts in sequence). When I first started the project the immediate need was to run aggregated reports taken from a “bucket” or key-value style of database (see v1.0). Writing the queries directly against the original database was difficult and error prone.

The values which needed to be accessed were all stored in a single table in MySQL with a foreign key to an another table which contained the metadata for the particular field (name, data type, etc. etc.). The row in the key/value table itself needed to be referenced in a separate forms table to associate the selected fields with the specific form where they were to be displayed. While this allowed for the application to be highly flexible in terms of form creation, it created several problems. Namely:

  • Electronic Medical Record data model was highly obfuscated
  • Querying Single Patients required multiple joins
  • Querying Patient Aggregates required multiple joins
  • As data records increased queries would become slower and slower

The immediate problem at the time was to get data out of the database to create the aggregated reports required by the US and Zambian governments. The initial solution was to create a domain-driven database model and pull the data from the key/value table and place it into the domain-driven tables (see v1.0).

The Evolved Reporting Solution

The next step was to automate the above process so that the reports could be generated at anytime. This is what we called the Patient Management & Reporting Server (PMRS). This was a central database in it’s own server with a web application front end that allowed for the querying of the latest aggregate data from any clinic at any time.

The PMRS system was the Enterprise complement to the in-clinic Patient Tracking System (PTS). The features of the system were:

  • Central consolidation of data
  • Instant access to data from multiple sites
  • Data Tracked:
    • Patient Enrollment
    • Drug Prescriptions
    • Laboratory Results
    • Adherence Levels
  • Primary Goal is to improve effectiveness of a multi-site program

The PEPFAR reporting form was created by the central PEPFAR office in Washington and used at every site world wide.

The above form alongside the Zambian Ministry of Health reporting form (which I don’t seem to have copy of) were the two main outputs of the PMRS system. However as the project progressed the aggregated data had additional uses which the PMRS server supported. Chief among these was export to SAS for analysis and epidemiological research.

The PRMS system made the work of the PEPFAR administrator for the CIDRZ sites (see Background) far easier. We were lucky to have some very smart and capable people working on the logistics and the administration of these sites and the ease of creation of these reports made their work easier.

SAS Exports

We were privileged to have dedicated physicians, administrators as well as epidemiologists working on the project. The epidemiologists tool of choice was SAS and one of the additional functions we built into the PRMS system was a push button CSV export to SAS using a format defined by the epidemiologists.

Previous to this, we had to create the data sets manually which was both time consuming and disruptive to the work of the development team (3 at this point).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.