Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

See also Administering Programs Workflows and States

Introduction

A program is typically used when a patient is identified as belonging to a group for which a particular set of coordinated interventions is to be followed. For example, programs might be used for diseases such as HIV or tuberculosis or conditions such as pregnancy or interventions such as childhood immunization.

A program may be composed of one or more workflows. If there are no workflows, only the patient_program data (entry date, exit date, outcome) is maintained. Many programs have only one workflow, but some have more than one. For example, in the pregnancy program, there might be an "all patients" workflow, a "high risk" workflow, and a "delivery" workflow; a woman with a high risk pregnancy would get both the "all patients" protocol and the "high risk" protocol.

A workflow is composed of states, at most one of which will be assigned to a particular patient at a particular time; for example, an HIV program might have "registered", "ready for ARV", "on initial ARV regimen", "on other 1st line regimen", "on 2nd line regimen", "defaulted", "lost to follow-up", "died", etc. Some states are "initial" states, to which patient may be assigned upon entry into the program; other states are "terminal" states – when a patient is assigned to this state, the patient's participation in the program comes to an end.

When the patient's participation in a program comes to an end, an outcome may recorded; typically, this indicates the success or failure of the intervention in achieving its purposes. This is a new feature introducted in OpenMRS version 1.9. In earlier versions, these outcomes would have had to be terminal states of a workflow.

Thus there are two main ways of using Programs: (1) without workflows, in which program entry and exit dates plus program outcome would be used; (2) with workflows, in which the traversal of internal workflow states is recorded and terminal states record outcome.

The primary reason for using a program is where entry and exit dates for the program and its component workflow states are significant for reporting. The reporting module allows the selection of patients both on program and workflow state. Statistics which can be computed include median time spent in a workflow state, number of program participants in a particular workflow state on a particular date, outcome by initial state, etc.

Data Model

User Interface

Program Administration (on the Administration page)

Note that program, workflow and state all keep their names in concepts, so these concepts must be defined before adding a program. Also, the possible outcome values must be in a concept set, which should be defined in advance as well.

In Manage Programs, choose Add a new program

Enter the name and description, select the concept (which should match the name), add the workflows and select the outcomes.

The program has been successfully defined. Note that the workflows both have 0 states. Select the one on which to work (STI Testing).

Add the states associated with this workflow. Note that the 3 initial states are based on patient characteristics; this is so we can count them from the program data alone. Also note that the only terminal state is STI Negative; the consequences of this choice will be discussed below.

Add the states associated with the STI Treatment workflow. Note that STI Positive is the initial state of this workflow; the treatment workflow starts with a positive diagnosis. For STI positive patients, the testing workflow will remain in the "STI Testing" state when the patient is following the treatment workflow. This is not necessarily the best practice, it is only illustrative.

The programs, workflows and states are now set up.

Patient Program Status (on the Patient dashboard)

The following example shows progressive changes in a patient's participation in the STI Program. Please excuse any unusual dates, they are due to a bug in the version being used to generate these screenshots.

On the patient dashboard, choose Add a new program.

Select the program, enrollment date and location. The initial states of each workflow are available in the dropdowns.

The addition of the program and the initial state for the testing workflow are now shown on the dashboard. To change the state of the testing workflow, choose the Edit link adjacent to it.

Select the new state, the date for the change, and click Change.

The change is shown on the patient dashboard. Since the example patient tested positive for STI, we will now initiate the treatment workflow by choosing the Edit link adjacent to it.

Select the new state, the date for the change, and click Change.

The change is shown on the patient dashboard. To change the state of the treatment workflow, choose the Edit link adjacent to it.

Select the new state, the date for the change, and click Change.

The change is shown on the patient dashboard. The patient is sent away to take their medications and return when the course of treatment is done. On return, the patient's STI is found to be cured. To change the state of the treatment workflow, choose the Edit link adjacent to it.

Select the new state, the date for the change, and click Change.

The change is shown on the patient dashboard. Since STI Cured is a terminal state, the program is marked completed. Choose the STI Program link to change the outcome.

Select the appropriate outcome and click Save. Note that in this example, all the terminal states are also outcomes and vice versa; this is not necessarily the best practice, it is only illustrative.

The change is shown on the patient dashboard.

  • No labels