Work Group Module

Objetives

Create a way to manage work groups within a health center

Specific Objetives

  1. Create a method to create work groups for each health center and roles within each work group

  2. Create a way for patients to be assigned to a single work group within one health center

  3. Create an administration method for OpenMRS users to be assigned to one or more work groups and/or one or more roles

  4. A history should be kept of the work groups and roles that each OpenMRS user has been assigned to

  5. A history should be kept of each work group that patients have been assigned to

    1. Is this already done for patient attributes in OpenMRS? sent email may 12

Requirements

Specific Objetive 1

  1. All work groups should be named the same???  This will change the UI.

  2. Should a person be able to have different roles within each sector?

Specific Objective 2

  1. The module should have a setting (formerly Global Property from platform 1.8 downwards)defining the identifier of the patient attribute

  2. The patient attribute should be a dropdown list of possibilities, hence it should be a pointer to a value in a table. The tribe module is an example of this (it might not be a good example).

Specific Objective 3

  1. Should be able to view which users are assigned to which work groups

  2. Should be able to reassign them in the same page

  3. If users are changed in a work group, this does not affect the users assigned to that work group

  4. In the Add/Edit User page (image attached) there should be an option for which sectors and roles the user should take. These should be a multiple select list for both sector and for roles in each sector.  This way the user must have the same role in all of the sectors that they are assigned to. If there is an easy way to select different roles for different sectors, we should include it.

Specific Objective 4

  1. All work groups should be named the same???

Specific Objective 5

  1. All work groups should be named the same???

General

  1. The solution should be documented in the OpenMRS Wiki, http://wiki.openmrs.org

  2. When approprite bugs and new requirements should be entered using the eHS bug tracking software http://tickets.openmrs.org

    1. A link to those bugs or requirements should be entered in the Wiki

  3. JUnit tests (https://wiki.openmrs.org/display/docs/Unit+Tests) will be created for the module according to the OpenMRS specifications (https://wiki.openmrs.org/display/docs/Module+Unit+Testing)

  4. El diseño debe ser mostrado en una de las reuniones de diseno de OpenMRS https://wiki.openmrs.org/display/RES/Design+Forum

Functionality tests for each requirement

The test number should coincide with the requirement number

  1. The wiki documentation will be reviewed

  2. The tickets entered will be reviewed

  3. The creation of JUnit tests will be verified

Arquitecture

Use Cases

Global Property Options

User Interface

UI for page

Description or Mockup

UI for page

Description or Mockup

Data Model

Table Structure

Another way is to create a team management module and create a team table for management of users in the module and assign patients to teams via the patient attribute.
To have patient attribute be a drop down list, tribe module is an example of this (it might not be a good example). Since it's a patient attribute you want the person attribute values to be controlled, to be a pointer in a value in a table.
If you need it ASAP, you could set the type for the patient attribute to be coded and then set concepts as answers.

The table will have the following structure:

Field Name

Tipe

Description

Field Name

Tipe

Description

INDICE_PLANTILLAS_SEC

INTEGER NOT NULL

PRIMARY KEY

 

 

Â