Target releaseRelease name or number
Epic Link to related JIRA epic or feature
Document status
Document owner

Unknown User (mafrica)

DesignerLead designer
DevelopersLead developer
QALead tester

Goals

Background and strategic fit

Every health facility is in a constant conflict between service quality and available resources.  

OpenMRS should provide the information and tools to help resolve the conflict by ensuring efficient and effective use of resources while objectively measuring key aspects of service quality.

Assumptions

Requirements

#TitleUser StoryImportanceNotes
1Workflow within OpenMRS

The long term goal would be to be able to (ideally graphically) describe the workflow associated with each patient encounter type. The workflow would have to support conditional branches and iterations.

Initially this may be implemented in a more basic form by the extension of the concept of location.

At the start an encounter a patient would enter a workflow path by being assigned to a service (currently this is location). A user would be responsible for the management of one or more services and have visibility of all patients currently assigned to the service with time of assignment and other encounter attributes like urgency.

The intersection of patient encounter with service would have an associated status eg waiting initial consultation, in process, waiting secondary service, reassigned, complete, discharged. A status change would be time-stamped.

While "in process" a number of secondary assignments could be made eg lab request, radiology with similar facilities to manage the the patient encounter queue and status.

Historical data should be available to report maximum and average number (and/or service time) of patient encounters and for a given service and status over a given time period e.g. what is the maximum waiting time for a lab test between the hours of 18.00 and 06.00.

I would imagine that a number of workflow management tools contain these facilities and may form a model for more detailed technical design.

Must Have
  • Additional considerations or noteworthy references (links, issues)
     

User interaction and design

Include any mockups, diagrams or visual designs relating to these requirements.

Questions

Below is a list of questions to be addressed as a result of this requirements document:

QuestionOutcome
(e.g. How we make users more aware of this feature?)Communicate the decision reached

Not Doing