OpenCRVS
v1.4
v1.4
  • 👋Welcome!
  • CRVS Systems
    • Understanding CRVS
    • Effective digital CRVS systems
    • OpenCRVS within a government systems architecture
    • OpenCRVS Value Proposition
  • Product Specifications
    • Functional Architecture
    • Workflow management
    • Status Flow Diagram
    • Users
      • Examples
    • Core functions
      • 1. Notify event
      • 2. Declare event
      • 3. Validate event
      • 4. Register event
      • 5. Print certificate
      • 6. Issue certificate
      • 7. Search for a record
      • 8. View record
      • 9. Correct record
      • 10. Verify record
      • 11. Archive record
      • 12. Vital statistics export
    • Support functions
      • 13. Login
      • 14. Audit
      • 15. Deduplication
      • 16. Performance management
      • 17. Payment
      • 18. Learning
      • 19. User support
      • 20. User onboarding
    • Admin functions
      • 21. User management
      • 22. Comms management
      • 23. Content management
      • 24. Config management
    • Data functions
      • 25. Legacy data import
      • 26. Legacy paper import
  • Technology
    • Architecture
      • Performance tests
    • Standards
      • FHIR Documents
        • Event Composition
        • Person
        • Registration Task
        • Event Observations
        • Locations
    • Security
    • Interoperability
      • Create a client
      • Authenticate a client
      • Event Notification clients
      • Record Search clients
      • Webhook clients
      • National ID client
      • FHIR Location REST API
      • Other ways to interoperate
  • Default configuration
    • Intro to Farajaland
    • Civil registration in Farajaland
    • OpenCRVS configuration in Farajaland
      • Application settings
      • User / role mapping
      • Declaration forms
      • Certificate templates
    • Business process flows in Farajaland
  • Setup
    • 1. Planning an OpenCRVS Implementation
    • 2. Establish project and team
    • 3. Gather requirements
      • 3.1 Mapping business processes
      • 3.2 Mapping offices and user types
      • 3.3 Define your application settings
      • 3.4 Designing event declaration forms
      • 3.5 Designing a certificate template
    • 4. Installation
      • 4.1 Set-up a local development environment
        • 4.1.1 Install the required dependencies
        • 4.1.2 Install OpenCRVS locally
        • 4.1.3 Starting and stopping OpenCRVS
        • 4.1.4 Log in to OpenCRVS locally
        • 4.1.5 Tooling
          • 4.1.5.1 WSL support
      • 4.2 Set-up your own, local, country configuration
        • 4.2.1 Fork your own country configuration repository
        • 4.2.2 Set up administrative address divisions
          • 4.2.2.1 Prepare source file for administrative structure
          • 4.2.2.2 Prepare source file for statistics
        • 4.2.3 Set up CR offices and Health facilities
          • 4.2.3.1 Prepare source file for CRVS Office facilities
          • 4.2.3.2 Prepare source file for health facilities
        • 4.2.4 Set up employees & roles for testing or production
          • 4.2.3.1 Prepare source file for employees
          • 4.2.3.2 Configure role titles
        • 4.2.5 Set up application settings
          • 4.2.5.1 Managing language content
            • 4.2.5.1.1 Informant and staff notifications
          • 4.2.5.2 Configuring Metabase Dashboards
        • 4.2.6 Configure certificate templates
        • 4.2.7 Configure declaration forms
          • 4.2.7.1 Configuring an event form
        • 4.2.8 Seeding & clearing your local databases
        • 4.2.9 Countryconfig API endpoints explained
      • 4.3 Set-up a server-hosted environment
        • 4.3.1 Verify servers & create a "provision" user
        • 4.3.2 HTTPS & Networking
        • 4.3.3 Create a Github environment
          • 4.3.3.1 Environment secrets and variables explained
        • 4.3.4 Provision environments
          • 4.3.4.1 Building, pushing & releasing your countryconfig code
        • 4.3.5 Deploy
    • 5. Functional configuration
      • 5.1 Configure application settings
      • 5.2 Configure registration periods and fees
      • 5.3 Managing system users
    • 6. Quality assurance testing
    • 7. Go-live
      • 7.1 Pre-Deployment Checklist
    • 8. Operational Support
    • 9. Monitoring
      • 9.1 Application logs
      • 9.2 Infrastructure health
      • 9.3 Routine monitoring checklist
      • 9.4 Setting up alerts
      • 9.5 Managing a Docker Swarm
  • General
    • Community
    • Contributing
    • Releases
      • v1.4.1: Release notes
      • v1.4.0 to v1.4.1 Migration notes
      • v1.4.0 Release notes
      • v1.3.* to v1.4.* Migration notes
      • v1.3.5: Release notes
      • v1.3.4: Release notes
      • v1.3.3: Release notes
      • v1.3.1: Release notes
      • v1.3.* to v1.3.* Migration notes
      • v1.3.0: Release notes
      • v1.2.* to v1.3.* Migration notes
        • v1.2 to v1.3: Form migration
      • v1.2.1: Release notes
      • Patch: Elasticsearch 7.10.2
      • v1.2.0: Release notes
      • v1.1.* to v1.2.* Migration notes
      • v.1.1.2: Release notes
      • v.1.1.1: Release notes
      • v1.1.0: Release notes
    • Interoperability roadmap
    • Product roadmap
Powered by GitBook
On this page
  1. Setup
  2. 4. Installation
  3. 4.2 Set-up your own, local, country configuration

4.2.2 Set up administrative address divisions

Previous4.2.1 Fork your own country configuration repositoryNext4.2.2.1 Prepare source file for administrative structure

Last updated 1 year ago

Now that you have a repository ready for your country configuration code, you can begin the configuration process. structure must be standardised and configured in the application in order to accurately geo-locate registrations and provide accurate registration performance analytics and vital statistics exports.

OpenCRVS fully appreciates that within many countries, addresses are not standardised in some urban and rural areas. We believe passionately that this should not be a hindrance to registration, so we have gone out of our way to enable optional and un-standardised urban and rural address levels. However, we must ensure at least some administrative structure standardisation in order to calculate key metrics.

You can configure how many standardised levels you need between 1 and 5 administrative subdivisions. These must map into the FHIR Location standard. Therefore, internally we use the terms "state" for Location Level 1 and "district" ( "district" being a sub-level and therefore part of a "state") as Location Level 2. As of OpenCRVS v1.3, subsequent Location Levels 3-4 will populate the Address lines Array in the FHIR Location object at hard-coded indices.

You can present these location levels to the user labelled in any way that you want, such as "Province" for "state", and "County" for "district", as we have done in our demo country Farajaland.

  • Total: ((crude birth or death rate * total population) / 1000) * (target estimated days / 365))

  • Male: ((crude birth or death rate * population of males) / 1000) * (target estimated days / 365))

  • Female: ((crude birth or death rate * population of females) / 1000) * (target estimated days / 365))

Therefore in order to calculate completeness rate, you are required to have available from your country's statistical department, the value for the crude birth rate and total population divided by gender for all the administrative areas.

In our experience it is unrealistic to expect that countries have accurate data for each level, so these are automatically calculated by the system where they have not been explicitly supplied.

The rest of the address fields that can be completed by a user are all optional and should be left blank if not required. The form question labels can be renamed to suit your needs in content management. The address fields support all urban standardisations such as "zipcode", international addresses and additionally custom address lines for rural areas that can be used for un-standardised data such as "village elder".

This labelling process is simply achieved in by , such as , and . Replace all occurrences of the fictional country name "Farajaland", with your country name in the content of this file.

Regarding the analytical dependency, one of the key performance metrics for a good civil registration system is to be able to present what is referred to as the "Completeness rate" for a state or district. Completeness rates are the primary measure of performance of a CRVS system. They are used as a form of international comparison and the indicator selected to measure . In order to calculate the completeness rate, we use the following formula:

We begin by creating source files for importing your standardised administrative subdivisions into the OpenCRVS database. Each one of these locations will be converted into a object. All subdivisions can be retrieved and edited in the future by using the .

content management
editing the JSON directly
here
here
SDG target 16.9
FHIR Location
FHIR Location API
Administrative division