eSaude Pharmacy Technical Specification

⚠️  This document has now be deprecated in favour of +eSaude Pharmacy Technical Specification v2.0.0.


This document should define the general technical strategy and system architecture, as well as the details technical requirements of the eSaude pharmacy system.

Technical Strategy

  • ℹ️ This is currently @Pascal B’s personal opinion and needs to be discussed with the team.
  • Agreed upon in eSaude Scrum on 10/20/2016

The pharmacy application should consist of two components, (1) an open module that a RESTful pharmacy API and (2) and app within the existing POC system. The table below describes some of the pros and cons of this approach.

PROS
CONS
Patient registration and management (FR3) is already implemented
Dependency on eSaude EMR Platform
User management already implemented (FR2)
Dependency on eSaude EMR POC
Access control already implemented (FR1)

Drug management (FR6) already implemented

Drug orders (prescriptions?) already implemented (FR4)


The developed OpenMRS module (openmrs-module-pharmacyapi) could be a fairly general component (if not at first, then eventually) that could be shared with the community. The POC app component could be the part that is specific to the eSaude community.

If we use the approach, many of the functional requirements are already implemented. This should allow us to get the system up and running relatively quickly by making use of a lot infrastructure that the eSaude EMR Platform already provices.

The bulk of the initial work will be into implementing stock management (FR7 & FR8) and reporting (FR9). 

Pharmacy Frontend

One critical difference between a pharmacy system and an EMR is that and EMR is focused around patients, while a pharmacy system is focused around drugs and prescriptions. When the pharmacist logs in, they should be presented options to create or dispense prescriptions, or maa

The frontend can be an angularJS + Bootstrap. Basically the same idea we had to build the POC.

Pharmacy Backend

The pharmacy backend should be implemented as an OpenMRS module. The module will create the additional required database tables, Java servers to interact with those tables, as well as a RESTful API that the frontend can make use of. See lower down for a more detailed API design.

Depending on our strategy, the following could be taken care of the by the eSaude platform: user management, access control, drugs (concepts) including ingredients and units, and prescriptions (orders).

The components that will definitely need to be developed are as follows.

Dispensing

Dispensing is when the pharmacist gives drug to a patient, usually based on the content of a prescription (drug order or order set).

All of the following should happen during a dispensation event:

  • The exact drugs and quantities should be recorded. Note: this can be different from the prescription, but the prescription should not be modified, since we need this original information as well.
  • The stock quantities should be adjusted.
  • If the patient had and left over drugs from a previous dispense event, the system should record this also.

Stock Management

Stock corresponds to physical packages of drugs that exist at the facility. The following stock operations need to be supported:

  • Register new stock in the system
  • Adjust stock counts during dispensation
  • Adjust stock counts during stock taking