OpenCRVS
v1.7
v1.7
  • 👋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
    • User roles & scopes
      • 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 roles
      • Declaration forms
      • Certified Copies 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 certified copy
    • 4. Installation
      • 4.1 Quick start: 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 Configure: 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 employee users, and scopes, for testing or production
          • 4.2.3.1 Prepare source file for employees
          • 4.2.3.2 Configure roles and scopes
        • 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 Deploy: 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. Quality assurance testing
    • 6. Go-live
      • 6.1 Pre-Deployment Checklist
    • 7. Operational Support
    • 8. Monitoring
      • 8.1 Application logs
      • 8.2 Infrastructure health
      • 8.3 Routine monitoring checklist
      • 8.4 Setting up alerts
      • 8.5 Managing a Docker Swarm
  • General
    • Community
    • Contributing
    • Migration notes
    • Releases and upgrades
    • Release notes
    • Product roadmap
Powered by GitBook
On this page
  • Pre-condition
  • Triggers
  • Standard flow
  • Post conditions
  • Variations/Exceptions
  1. Product Specifications
  2. Core functions

3. Validate event

In order to register the vital event, the declaration form must be validated by checking all the details recorded and any supporting documents attached.

In OpenCRVS, the declaration form can be reviewed side by side with the supporting documents to ensure that it is accurate before the vital event is registered. If the information is correct, a user with scope:record.register can go on to register the vital event; if it is not correct, it can be sent for updates if they have the scope scope:record.declaration-send-for-updates.

In the case where a Registrar has an assistant to conduct initial checks, eg. a Registration Agent with scope:record.declaration-send-for-approval. They can review a declaration and subsequently send it for approval to a user with scope:record.register .

Pre-condition

A record is in the Ready for Review workqueue with the status ‘In Review’

Triggers

A user with scope:record.declaration-send-for-approval or scope:record.register assigns and downloads the declaration

Standard flow

  1. User navigates to Ready for Review workqueue

  2. User assigns themselves to the record

  3. Declaration is downloaded and is now available to be validated offline

  4. User clicks “Review”

  5. User validates declaration against supporting documents

  6. Available actions depending on the user's assigned scopes:

    1. scope:record.register > Register

    2. scope:record.declaration-send-for-approval> Send for approval

  7. User is prompted to confirm their action

  8. On confirming, declaration is sent to the Outbox for processing

  9. Once processed the declaration status is updated

    1. scope:record.register > Status = Registered

    2. scope:record.declaration-send-for-approval> Status = Validated

Post conditions

  • Declaration is shown to the users workqueue depending on their assigned scopes

    1. Ready to review. Ifscope:record.register

    2. Sent for approval. If scope:record.declaration-send-for-approval

    3. Ready to Print. If scope:record.registration-print&issue-certified-copies

  • Record audit is updated to show the last action

Variations/Exceptions

  • If updates are required and the user has scope:record.declaration-send-for-updates. They can choose to send the declaration to the Requires Updates workqueue. Informant receives sms notification that their declaration was rejected and recommend them to visit the office.

  • The validator can choose to change a part of the declaration. If so they will receive a warning prompt about making changes. Before navigating them to the required section of the form. A audit log of this change is recorded in Record Audit.

  • When the system flags a declaration as a potential duplicate. A user with scope:record.review-duplicates can review the potential declaration against any flagged records. They can then mark the record as not a duplicate or mark it as a duplicate and archive the declaration.

Previous2. Declare eventNext4. Register event

Last updated 3 months ago