OpenCRVS
v1.5
v1.5
  • 👋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 TLS / SSL & DNS
          • 4.3.2.1 LetsEncrypt https challenge in development environments
          • 4.3.2.2 LetsEncrypt DNS challenge in production
          • 4.3.2.3 Static TLS certificates
        • 4.3.3 Configure inventory files
        • 4.3.4 Create a Github environment
          • 4.3.4.1 Environment secrets and variables explained
          • 4.3.4.2 VPN Recipes
        • 4.3.5 Provisioning servers
          • 4.3.5.1 SSH access
          • 4.3.5.2 Building, pushing & releasing your countryconfig code
          • 4.3.5.3 Ansible tasks when provisioning
        • 4.3.6 Deploy
          • 4.3.6.1 Running a deployment
          • 4.3.6.2 Seeding a server environment
          • 4.3.6.3 Login to an OpenCRVS server
          • 4.3.6.5 Resetting a server environment
        • 4.3.7 Backup & Restore
          • 4.3.7.1 Restoring a backup
          • 4.3.7.2 Off-boarding from OpenCRVS
    • 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.5.1: Release notes
      • v1.5.0: Release notes
      • 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.0: Release notes
      • v1.2.1: Release notes
      • Patch: Elasticsearch 7.10.2
      • v1.2.0: Release notes
      • v.1.1.2: Release notes
      • v.1.1.1: Release notes
      • v1.1.0: Release notes
    • Roadmap
Powered by GitBook
On this page
  • A model for high-performing CRVS
  • Business requirements of a digital CRVS system
  • Principles when digitising a civil registration system
  1. CRVS Systems

Effective digital CRVS systems

Setting realistic business expectations of CRVS digitisation

PreviousUnderstanding CRVSNextOpenCRVS within a government systems architecture

A model for high-performing CRVS

It is important to understand that digitisation alone will not be able to transform under-performing CRVS systems. A number of operational aspects need to be in place if the intended results are to be achieved and benefits fully realised. These are presented in the following operating model diagram, which is intended to be illustrative of a high-performing scenario.

High-performing CRVS operating model

Business requirements of a digital CRVS system

A set of clear business requirements outlines the real purpose and objectives of the digital system. The following list provides a number of expectations that a government may have of their digital CRVS system and serves as a reference for CRVS modernisation programmes.

  • Increase the registration completeness rates for all vital events in all areas

  • Digital first process with the removal of manual and error-prone processes

  • Digital (and searchable) archive of all paper-based records to free up office space

  • Improve the efficiency of the registration process (decrease certification turn-around time, decrease time taken to process each record by staff)

  • Improve interoperability / utilization of civil registration data as a component of Digital Public Infrastructure

  • Ensure that civil registration data is secure and compliant with data protection laws

  • Ensure integrity of data across the foundational identity ecosystem, including civil registration and digital ID

  • Improve accuracy of civil registration data

  • Provide high quality and timely statistical data from civil registration records

  • Standardisation and harmonisation of processes across the country

Although each country will have their own specific business objectives, any modern CRVS system would expect to be able to provide a number of these requirements. OpenCRVS has been designed with these business requirements in mind to maximize the utility of the platform once implemented.

Principles when digitising a civil registration system

When considering an OpenCRVS implementation it is important to understand some key best-practice concepts of digitisation.

There is often a tendency to try to digitise an existing manual process, especially if it is enshrined within the legal framework and formal regulations. This should be avoided as it will limit the long-term effectiveness of the system.

Moving from a manual system to a fully automated and effective digital system may take many years as a result of the legislative reforms required, but it is advisable to think about the long-term strategic direction from the outset and create a roadmap for how the change will be introduced and when.

Below are a sample list of principles to consider when setting a long-term vision and roadmap for CRVS digitisation, which will help you get the best out of OpenCRVS:

  • Try to conceptualise the Civil Registry in terms of digital records rather than a digital archive of paper-based records, which may be a symptom of outdated laws. One key question to ask would be "What do you consider is the actual registry?". If the answer to this question is "It's the data in the database", then you are probably good. If the answer is "It's the data in the paper-based register books", then you may not be maximizing the utility of OpenCRVS.

  • Capture data in a digital format at source. Try to avoid initiating the process using a manual paper-based process and then transcribing from paper records to digital format later in the process as this may introduce data quality issues.

  • As far as is possible, make data collection forms (e.g. for birth declarations) work using validation rules based on reference data . This will help with data validation at source, for example using a defined list of occupations, rather than allowing free text entry.

  • Create a master repository of all civil registration data which is then accessible by various actors with different privileges. Creating multiple systems for decentralised or autonomous organisations will make maintenance tasks challenging and increase the total cost of ownership.

Think about the way that the the CRVS system receives and shares data with other systems to maximize the value of civil registration data. See the next section on for more details.

OpenCRVS within a systems architecture