OpenRIMS-RPM - Workflow Variations

From OpenRIMS Wiki
Jump to navigation Jump to search

OpenRIMS software tracks the lifecycle of medicinal products as well as facilities related to the import, selling, storing, and manufacturing of them. This lifecycle is managed by in-country businesses and the state National Medicine Regulatory Authority (NMRA).

The main stages of the lifecycle are:

1.     Registration or approval

2.     Active

3.     De-registered

A modification workflow intends to maintain data actuality in the Active stage:

·       For an applicant possibility to report changes in the information initially provided.

·       For NMRA possibility to process changes properly under the legislative

This manual is for OpenRIMS supervisor that is motivated to create and maintain modification workflows.

The scenario

The scenario of any modification workflow:

1.     An applicant:

1.1.  selects subject and object of modification and, then:

1.2.  fills out the electronic forms of the modification application

1.3.  submit it to NMRA

2.     NMRA:

2.1.  Reviews the modification and  then:

2.1.1.Apply it to the existing object data or return the application

2.1.2.Makes all necessary legislate actions, i.e., issue new certificates, inform Internal Revenue Commission, etc

Subject and object of modification

              The subject of modification is a piece of information to be modified. Examples are:

·       Pharmacy owner

·       Capital

·       Address of the facility

·       Manufacturer of the medicinal product

·       etc.,

The object of modification is the application data to be modified. Examples are:

·       Pharmacy # 23

·       “Peter and Co” manufacturer

·       Panadol medicine

·       Etc

For a typical application, data is collected from more than one page. Any given subject of modification can be applied only to the whole or part of data on one page.

Thus it is important to cast the application data to pages considered necessary for future modifications.

Definition of the modification workflow

Figure 1 The full list of modification workflows can be found in "dictionary.guest.amendments"

Figure 2 The item in the “dictionary.guest.amendments” contains a definition of the “Owner modification” application

1.     The subject of modification – an electronic form

2.     The URL of the workflow definition in the “Processes” menu

3.     The modification application data configuration[1]

4.     The self-check checklist that should be filled out before a modification application will be submitted

Modification application. The configuration of data

Figure 3 Data configuration for owner modification

1.     The first page of any modification application should contain at least “register” and “prefLabel.

2.     The second page is the modification subject form.

3.     The rest of the pages may contain any required application data. To simplify, this data may be placed on the first page

Definition of modification subject

A modification may be applied to data placed on one electronic page of a modification object. The modification subject form should contain the same or fewer variables that are defined for the modified page.

Figure 4 This subject form allows for modified addresses defined by variables in the right table

Figure 5 It is a valid object of modification using the subject form



Figure 6 This object cannot be modified by the subject form

Modification of the whole page        

It is possible to use an object’s electronic form as a subject form. However, it is possible only when a subject should modify the whole page of an object. In the example below the same configuration of the data, is in use for input and modification

Figure 7 The "site.pharmacist" is in use for modification

Figure 8 The "site.pharmacist" is in use for the new pharmacy application

Workflow steps definition

Figure 9 Workflow steps definitions  for modifications can be found here

For a modification workflow minimum 3 steps are mandatory:

1.     Screening

2.     Verification or Review or something else

3.     Finalization

Figure 10 The last step should be marked as AMEND. The modification will be implemented on entering the previous step (in this case – Verification)

Troubleshooting

Impossible to apply subject to object

Figure 11 The address modification can't be applied to any application

              To fix this:

Figure 12 Open the dictionary of modification workflows

Figure 13 Determine URL of modification subject configuration

Figure 14 The "modification_instruction" header does not exist in any object configurations

Hint:

·       Suspend the extra variable “modification_instruction”

·       Place this variable on the first page of the address modification application.



[1] Not the same as 1