You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Data Entry Clerk will be able to use an easy to navigate event form to input the legacy data. These forms will include standardised inputs and data validation for demographics.
Standardised inputs will exist on a one-page form to enter all the information required for the legacy event.
Input fields will exist to select the original Registrar who registered the record. First, a search select field allows the user to choose from existing Registrars who are already configured in OpenCRVS. A CSV of legacy (deactivated) registrars will be supplied. A data migration script must be written to load these legacy users into OpenCRVS 1.6 as deactivated registrars.
A search select allows the user to choose from existing administrative location levels as the place of registration or place of event. A CSV of legacy (deactivated) administrative locations, offices and health facilities will be supplied. A data migration script must be written to load these legacy locations into OpenCRVS 1.6 as deactivated locations.
A date input field allows the user to enter the date of registration.
Tech tasks
Develop data migration scripts that load the legacy locations and staff into an already seeded OpenCRVS installation. Legacy locations must be deactivated "inactive" and not visible within the main OpenCRVS application. Legacy registrars must be deactivated in the main OpenCRVS application. Legacy registrars should only be visible in the Team pages of the main OpenCRVS application if they used to work in an office which already exists
From the landing page, a user can click a button to start a registration.
The form field requirements are TBC. But to begin with we will need these minimal inputs:
Type of event - a select (Birth, Death, Marriage, Divorce, Adoption)
Place of event - a (searchable location select) ... ADMIN_STRUCTURE & HEALTH_FACILITY locations will be retrieved from the FHIR Location API. Ensure that both active and inactive locations are visible.
Date of event - a date picker
Place of registration - a (searchable location select) ... CRVS_OFFICE locations will be retrieved from the FHIR Location API. Ensure that both active and inactive offices are visible.
Date of registration - a date picker
Registrar - a (searchable location select) ... Registrars will be retrieved from the Gateway searchUsers resolver using an office ID which is passed into the app as an environment variable. Ensure that both active and deactivated registrars are visible.
Other form fields and validations required will be supplied soon
The text was updated successfully, but these errors were encountered:
Requirements
Tech tasks
Develop data migration scripts that load the legacy locations and staff into an already seeded OpenCRVS installation. Legacy locations must be deactivated "inactive" and not visible within the main OpenCRVS application. Legacy registrars must be deactivated in the main OpenCRVS application. Legacy registrars should only be visible in the Team pages of the main OpenCRVS application if they used to work in an office which already exists
From the landing page, a user can click a button to start a registration.
The form field requirements are TBC. But to begin with we will need these minimal inputs:
Type of event - a select (Birth, Death, Marriage, Divorce, Adoption)
Place of event - a (searchable location select) ... ADMIN_STRUCTURE & HEALTH_FACILITY locations will be retrieved from the FHIR Location API. Ensure that both active and inactive locations are visible.
Date of event - a date picker
Place of registration - a (searchable location select) ... CRVS_OFFICE locations will be retrieved from the FHIR Location API. Ensure that both active and inactive offices are visible.
Date of registration - a date picker
Registrar - a (searchable location select) ... Registrars will be retrieved from the Gateway searchUsers resolver using an office ID which is passed into the app as an environment variable. Ensure that both active and deactivated registrars are visible.
The text was updated successfully, but these errors were encountered: