OpenRIMS-RPM - Workflow Configuration Part 1: Difference between revisions
Khoppenworth (talk | contribs) m (Khoppenworth moved page Workflows Part 1 to OpenRIMS - Workflow Configuration Part 1 without leaving a redirect) |
Khoppenworth (talk | contribs) m (Khoppenworth moved page OpenRIMS - Workflow Configuration Part 1 to OpenRIMS-RPM - Workflow Configuration Part 1) |
(No difference)
| |
Latest revision as of 20:21, 14 August 2023
Introduction
This guide intends to Pharmadex 2 Supervisors and contains reference data necessary to the creation of on-screen forms.
The Pharmadex 2 application and workflow data forms are configurable by the Supervisor. Any given data form consists of components. Each component provides an atomic functionality, i.e., data input/display field, choices from the pre-defined set of choices, file upload, file download, etc.
To place any data component to an on-screen form the Supervisor should:
· Define a place on the form
· Provide component-specific parameters
Form layout
The basic configuration layout of an electronic form is in two columns. Depending on the room on the screen a form may be represented in two or one columns. In the case of the one-column representation, the second column will be placed under the first one.
The numbering of rows and columns starts from zero.
Figure 1. The two columns layout
The heigh of components may be very different. Thus, placing one component to a cell (row, col) is almost unusable
Figure 2. The only cell is not enough
To avoid this, the Pharmadex 2 provides the third coordinate – an order inside the cell. The order starts from zero and allows place many components in a cell.
Figure 3. Cell and order inside a cell are acceptable
Electronic form
Where to find it?
The definitions of all electronic forms are in the feature Administrate-Configuration-Data Configurator.
Figure 4. Electronic form configuration feature
1. Search for electronic form definition in the list below
2. List of all electronic form definitions
3. The definition of a selected electronic form (see above Figure 3)
Configuration data form
The data form configuration consists of general data and layout configuration. In own turn, the layout configuration consists of variables.
1. Select to access the layout configuration
2. Click to edit general data
3. Add new form
The general data consists of URL and description. URL is a unique identifier of the form; the description is a description of the whole form.
Figure 5. General form data
1. Click to edit URL
2. The description of data
3. Press to save the general data
4. Press to remove the general data
5. Press to do nothing
6. Press to copy the general data and the layout configuration
Component configuration form
Figure 6. Layout form data
1. Click to edit a component definition (variable)
2. Add New component definition
3. Preview the electronic form
Component definition
1. Click to edit the name of the component
2. The experimental feature will be described later
3. The help texts
4. Select a type of component, e.g., text field, file uploader.
5. Validation parameters. The particular meaning for a particular component
6. Screen position – row, col, order inside a cell (see Figure 3)
7. Additional configuration data for particular components
The components configuration reference
headings
Headers or links to external resources
| Parameter | Usage | Example |
| Minimal Offset | ||
| Maximal Offset | ||
| required | ||
| mult | ||
| Auxiliary Data | ||
| url | Link to external resource | https://google.com |
| dictUrl | ||
| auxURL | ||
| readOnly | ||
| unique | ||
| The pattern for the field or file names | ||
strings
Text input field
| Parameter | Usage | Example |
| Minimal Offset | min length in characters | 3 |
| Maximal Offset | max length in characters | 1024 |
| required | value is required | |
| mult | ||
| Auxiliary Data | ||
| url | ||
| dictUrl | ||
| auxURL | ||
| readOnly | value is read-only | |
| unique | the value should be unique | |
| The pattern for the field or file names | Java Regular expression pattern[1] | [a-zA-Z]{3} |
literals
See “strings” above
dates
Date input control
| Parameter | Usage | Example |
| Minimal Offset | months from the current date | -3 |
| Maximal Offset | months after the current date | 3 |
| required | value is required | |
| mult | ||
| Auxiliary Data | ||
| url | ||
| dictUrl | ||
| auxURL | ||
| readOnly | value is read-only | |
| unique | ||
| The pattern for the field or file names | ||
numbers
Number input field
| Parameter | Usage | Example |
| Minimal Offset | min value | 0 |
| Maximal Offset | max value | 1000000 |
| required | value is required | |
| mult | ||
| Auxiliary Data | ||
| url | ||
| dictUrl | ||
| auxURL | ||
| readOnly | value is read-only | |
| unique | ||
| The pattern for the field or file names | ||
logical
Yes/No/NA logical field
| Parameter | Usage | Example |
| Minimal Offset | ||
| Maximal Offset | ||
| required | ||
| mult | ||
| Auxiliary Data | ||
| url | ||
| dictUrl | ||
| auxURL | ||
| readOnly | value is read-only | |
| unique | ||
| The pattern for the field or file names | ||
dictionaries
Allows selection from the pre-defined choices. For example
Figure 7. The dictionary
| Parameter | Usage | Example |
| Minimal Offset | ||
| Maximal Offset | ||
| required | at least one choice is required | |
| mult | ||
| Auxiliary Data | ||
| url | url of the dictionary | dictionary.guest.deregistration |
| dictUrl | ||
| auxURL | ||
| readOnly | value is read-only | |
| unique | ||
| The pattern for the field or file names | ||
addresses
Address dictionary with the possibility to select geographical coordinates
Figure 8. The address control
| Parameter | Usage | Example |
| Minimal Offset | ||
| Maximal Offset | ||
| required | selection and coordinates are required | |
| mult | ||
| Auxiliary Data | ||
| url | where to store and find | nepal.address |
| dictUrl | ||
| auxURL | ||
| readOnly | value is read-only | |
| unique | ||
| The pattern for the field or file names | ||
documents
Upload documents
Figure 9. The file uploader component
| Parameter | Usage | Example |
| Minimal Offset | wide of the image[2] in pixels | 300 |
| Maximal Offset | height of the image in pixels | 300 |
| required | at least one file should be uploaded | |
| mult | ||
| Auxiliary Data | ||
| url | where to store and find | pharmacy.documents |
| dictUrl | dictionary with the list of file to uplaod descriptions | dictionary.pharmacy.site.photos |
| auxURL | ||
| readOnly | value is read-only | |
| unique | ||
| The pattern for the field or file names | file types allowed[3] | .jpg,.png,.tiff |
resources
Download documents, pictures, and templates.
Figure 10. The file resource component
| Parameter | Usage | Example |
| Minimal Offset | ||
| Maximal Offset | ||
| required | ||
| mult | ||
| Auxiliary Data | ||
| url | Where are the files stored? | pharmacy.new.invoices |
| dictUrl | ||
| auxURL | ||
| readOnly | value is read-only | |
| unique | ||
| The pattern for the field or file names | ||
things
Sub-forms or forms that placed at the right of the main form
Figure 11. The main form and sub-forms
1. The main form. This form must contain a literal with the name prefLabel.
2. Additional forms that should be included using the “thing” class
| Parameter | Usage | Example |
| Minimal Offset | ||
| Maximal Offset | ||
| required | ||
| mult | ||
| Auxiliary Data | ||
| url | URL of an electronic form configuration. This form should not contain “things”, however may contain any other component | retail.pharmacy.classifiers |
| dictUrl | ||
| auxURL | ||
| readOnly | ||
| unique | ||
| The pattern for the field or file names | ||
persons
Allows adding detailed records to the main data. Examples are pharmacy owners to a pharmacy or warehouses to the wholesaler.
Figure 12. The "persons" component - detail records
| Parameter | Usage | Example |
| Minimal Offset | ||
| Maximal Offset | ||
| required | at least one detail record is required | |
| mult | ||
| Auxiliary Data | ||
| url | Where to store detail records | site.owners.persons |
| dictUrl | ||
| auxURL | The configuration of the detail record electronic form. This configuration can contain subforms, i.e. “things” | site.owner.person |
| readOnly | ||
| unique | ||
| The pattern for the field or file names | ||
schedulers
Allows to run another follow-up application after the application will be approved. Examples are “scheduled renewal payment”, “scheduled inspection”, etc.
Figure 13. The scheduler component
| Parameter | Usage | Example |
| Minimal Offset | Offset in months from the current date to minimal possible date to run the follow-up application | |
| Maximal Offset | Offset in months from the current date to maximal possible date to run the follow-up application | |
| required | the scheduled date should fit the Minimal offset – Maximal offset criteria | |
| mult | ||
| Auxiliary Data | ||
| url | Where to store the scheduler? | pharmacy.site.renew |
| dictUrl | ||
| auxURL | Which application should be scheduled? | application.pharmacy.renew |
| readOnly | Display date only | |
| unique | ||
| The pattern for the field or file names | ||
registers
Provides assigning numbers, registration date, and expiration date like a typical filing system register does.
Figure 14. The register component
| Parameter | Usage | Example |
| Minimal Offset | Offset in months from the current date to the minimal possible registration date | -1 |
| Maximal Offset | Offset in months from the current date to the maximal possible expiration date | |
| required | the dates should fit the Minimal offset – Maximal offset criteria | |
| mult | If true, the dates will be available. Otherwise the registration only. | |
| Auxiliary Data | ||
| url | Where to store the register? | pharmacy.site.renew |
| dictUrl | ||
| auxURL | Which application should be scheduled? | application.pharmacy.renew |
| readOnly | Display date only | |
| unique | ||
| The pattern for the field or file names | The registration number prefix. For most filing systems – code of cases | MR/ |
atc
ATC codes for medicines
Figure 15. The ATC codes component
| Parameter | Usage | Example |
| Minimal Offset | ||
| Maximal Offset | ||
| required | Require at least one code selected | |
| mult | ||
| Auxiliary Data | ||
| url | Where to store the selected codes? | medicinalproduct.productclassification |
| dictUrl | ||
| auxURL | ||
| readOnly | Display date only | |
| unique | ||
| The pattern for the field or file names | ||
legacy
Allows select objects uploaded from the legacy data. Applicable for manual legacy data export, usage the legacy data for new applications, etc.
Figure 16. The legacy data component
| Parameter | Usage | Example |
| Minimal Offset | ||
| Maximal Offset | ||
| required | Require the selection | |
| mult | ||
| Auxiliary Data | ||
| url | Where to store the selected codes? | pharmacies.registered.legacy |
| dictUrl | The kind of legacy data, e.g., pharmacies, medicines, etc. | legacy.pharmacies |
| auxURL | ||
| readOnly | Display date only | |
| unique | ||
| The pattern for the field or file names | ||
intervals
The interval between two dates.
Figure 17. The interval component
| Parameter | Usage | Example |
| Minimal Offset | The length of the interval in months | |
| Maximal Offset | The max in the interval, zero means no restrictions | |
| required | Minimal Offset and Maximal offset constraints should be applied | |
| mult | ||
| Auxiliary Data | ||
| url | ||
| dictUrl | ||
| auxURL | ||
| readOnly | ||
| unique | ||
| The pattern for the field or file names | ||
[1]
[2] In case if jpg, jpeg or png file will be uploaded. For other types of uploaded files will be ignored
[3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file - see attribute “accept”