Form2Program Module


This Module provides the ability to automatically enroll patients in a program after a form is submitted. It also provides a mechanism to enroll all current patients in the database into one or more programs based on previous encounter types.


  1. Use at least OpenMRS 1.2 
  2. Have some forms and encounter types in OpenMRS (see Administering_Formentry).
  3. Create at least one program if none exist. It is not necessary to have any workflow or states in the program. (see Administering Programs, workflows and states).


  1. In the Administration page, look for Programs and click on Manage Encounter Types to Programs.
  2. Select a program and encounter type and click the Add Encounter Type to Program button.
  3. A program with one or more encounter types will be listed.
  4. Whenever a form of this encounter type is submitted, the patient will be enrolled in this program.
  5. An asterisk * next to an encounter type means that the database needs to be updated to enroll current patients into this program that have previously used this encounter type. Click the Update button to do so.
  6. To delete an Encounter Type to Program, click on the red x next to the item. It will be removed from

[Form2Program Module|]

h1. Release Notes

h5. Version 1.4

Fixed problem mentioned in [archive:ticket #627|] so that PatientProgram creator is the person who enters the encounter form.

Version 1.3.1

Workaround for [archive:ticket #627|] to set PatientProgram creator to be the person who enters the encounter form.

Version 1.3

This version sets the enrollment date as the encounter datetime instead of today's date. When using the Update button to enroll current patients, the enrollment date is the encounter datetime of a patient's first encounter of any encounter type mapped to the program being updated.

If you would like to change all current patient programs in your database to reflect the above behavior, here is an SQL query that will change all patient programs, including those that have been changed manually from the patient dashboard. May I say, use this SQL query at your own risk. In the future I may add the functionality of this script to the module. Please let me know of any comments or suggestions regarding this.

 * Warning: this will affect all patient programs.
 * Add a "where" clause to limit the scope.
   date_enrolled =
       select min(encounter_datetime)
       from encounter
       where encounter.patient_id=patient_program.patient_id
       and encounter.encounter_type in
           select encounter_type
           from form2program_map
           where form2program_map.program = patient_program.program_id
Versions 1.1 - 1.2

Have the features listed in the [Usage|] section on this page.


The following may or may not be built into this module:

  1. Automatically transition a patient workflow state based on an observation or an order.
  2. Use a scheduled task to handle transition of patient workflow states based on the absence of activity (e.g.: Loss of Follow-up).


Brian McKown



The module adds the following table to the database. Primary key is a superkey of (program, encounter_type). No history of deleted tuples is retained.

CREATE TABLE `form2program_map` (
`program` int(11) NOT NULL,
`encounter_type` int(11) NOT NULL,
`creator` int(11) NOT NULL,
`date_created` datetime NOT NULL,
`changed_by` int(11) NOT NULL,
`date_changed` datetime NOT NULL,
`applied` tinyint(1) NOT NULL DEFAULT '0',
PRIMARY KEY (`program`,`encounter_type`),
KEY `encounter_type` (`encounter_type`),
KEY `user_who_created_form2program` (`creator`),
KEY `user_who_changed_form2program` (`changed_by`),
CONSTRAINT `form2program_map_ibfk_1` FOREIGN KEY (`program`) REFERENCES `program` (`program_id`),
CONSTRAINT `form2program_map_ibfk_2` FOREIGN KEY (`encounter_type`) REFERENCES `encounter_type` (`encounter_type_id`),
CONSTRAINT `user_who_changed_form2program` FOREIGN KEY (`changed_by`) REFERENCES `users` (`user_id`),
CONSTRAINT `user_who_created_form2program` FOREIGN KEY (`creator`) REFERENCES `users` (`user_id`)