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
  • Implementation Phases
  • Proof of Concept
  • An OpenCRVS Pilot
  • Pilot Work Plan
  1. Setup

1. Planning an OpenCRVS Implementation

PreviousBusiness process flows in FarajalandNext2. Establish project and team

Last updated 1 year ago

Failing to prepare is preparing to fail. Implementation planning is critical, considering the different phases of an effective digital transformation programme.

Implementation Phases

There are 3 key phases of a digital transformation programme, and an additional pre-transformation phase that can secure buy-in and super-charge the business analysis process.

  1. Proof of Concept: configure the core product with basic country inputs to prove OpenCRVS’ applicability and identify additional requirements.

  2. Pilot: test out OpenCRVS in a range of settings to prove that it works, improve the product and refine a scalable, integrated rollout plan.

  3. Scale-up: scale-up digital services across the country, using the integrated components tested in the pilot.

  4. Operational Support: Manage and maintain the solution for the long-term, including regular product upgrades and hot fixes, as required.

Proof of Concept

OpenCRVS can be quickly configured to meet the basic civil registration needs of a country, which provides a unique opportunity to test the product and learn more about specific business needs and system requirements before procuring a full system.

The Proof of Concept (PoC) may confirm OpenCRVS as the right product for implementation or help identify the requirements that can be used within a competitive tender process.

What a PoC IS

  • Quick way to see how OpenCRVS can enable digital CRVS in your country

  • Use existing functionality in the core product, applied to your country

  • An opportunity to learn what works and what doesn’t work and identify additional system requirements

  • Small-scale field-testing to get user feedback and better understand requirements

  • An opportunity to inform the development of a long-term digitisation and investment strategy

What a PoC IS NOT

  • A full requirements gathering process (this will happen once the country has confirmed it wants to use OpenCRVS)

  • Customisation of OpenCRVS with additional requirements (no new requirements will be built)

  • Live registration of vital events (only mock data will be used), so concerns about data sovereignty and ownership defined in law i.e. must host in-country, don't affect the exercise

Outputs of a PoC

  1. OpenCRVS Configured: configured version of OpenCRVS for the country, hosted in the cloud.

  2. Analysis document: including as-is and to-be process maps.

  3. Requirements backlog: detailing all requirements identified during analysis that can be used for subsequent work. NB. this is not a complete product backlog, it is the beginning, based on findings from the PoC.

  4. Pilot plan: enabling you to plan for a pilot of the solution to inform a national-scale CRVS digitisation effort.

An OpenCRVS Pilot

Definition of a Pilot: A pilot project is a small-scale, preliminary initiative or experiment designed to test the feasibility, viability, and effectiveness of a particular idea, concept, or solution before full-scale implementation. Pilot projects are often conducted in real-world settings to assess how a proposed intervention or innovation performs under controlled conditions and to identify any potential challenges or opportunities for improvement. These projects typically have defined objectives, timelines, and success criteria, allowing stakeholders to evaluate outcomes and make informed decisions about whether to proceed with broader implementation. Pilot projects are commonly used in various fields, including technology, healthcare, education, and social services, to validate concepts, gather feedback, and mitigate risks before investing resources in larger-scale initiatives.

NB. the purpose of a pilot is to learn and inform scale-up plans.

Pilot Work Plan

Detailed below is an example of a work plan for a pilot of OpenCRVS in a country. You will notice that this is an integrated programme of work because technology alone cannot bring about a true transformation of civil registration in a country. Programme workstreams include:

Business Analysis: understanding business and system requirements to help a country achieve their strategic objectives.

Product Development & Testing: designing, building and testing the country instance of OpenCRVS that fulfils all requirements defined through business analysis.

Change Management: designing and implementing a comprehensive change management programme that will ensure effective buy-in and take-up of the new system and services.

Training: designing and implementing a robust training programme that equips users with the skills to effectively use the system, and that is scalable (cost-effective).

Monitoring & Evaluation: defining key performance indicators (KPIs) and a continuous improvement plan that monitors these indicators on an ongoing basis in order to inform product, service and deployment improvements as the pilot ends and scale-up begins.

Operational support: establishing tier 0-4 user support functions to ensure that users are continuously supported over time and services remain operational.

Planning an OpenCRVS Implementation
What is a PoC and why is it valuable?
Example PoC Work Plan
Example Pilot Work Plan