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
  1. Technology
  2. Interoperability

Event Notification clients

Submitting full or partial event applications into OpenCRVS from an external service such as a health institution or public portal.

PreviousAuthenticate a clientNextRecord Search clients

Last updated 1 month ago

An Event Notification client can submit full or partial birth or death applications into an OpenCRVS' office "In Progress" or "Ready For Review" workqueue. Usually these clients are Hospitals, but technically these clients could be any system and the "Health system" label on the workqueue tab could be content managed accordingly.

When Event Notifications are received in OpenCRVS, they are audited accordingly as being received from one of your automated clients.

Submitting an Event Notification

Event Notification Requests

Parameter
Description

Event Notification Response

If the request fails, you will receive a 500 Error and you must check the payload you are sending for errors. No error codes or explanations currently exist. We welcome pull requests to improve the developer experience here.

You can use our to test Event Notification API functionality. is a tool you can download to test API access before building your integrations.

To submit an Event Notification, your client must first request an using your client_id and client_secret.

With the token as an authorization header, the following request will submit a minimal birth declaration in . To learn more about our FHIR standard, read the section.

Parameters in handlebars must be substituted with specific data that requires further explanation below. Other data is given as an example, but you can refer to our to set the values correctly depending on the birth or death.

Refer to our to see a payload for a full birth declaration, minimal and full death declaration. Pay attention to the parameters that are dynamically provided from the Postman "Environments" to understand where to configure your URLs and other variables listed below. You should use the in tandem with the Event Notification API in order to find the required FHIR IDs for locations used in addresses, places of birth, office of registration etc.

An

This is an important parameter. It is a FHIR Location uuid for a Civil Registration Office that you wish this notification to arrive in the jurisdiction / workqueue of. You can retrieve these ids using our open . Your offices are customised for your country needs in

If you are submitting addresses, then this is an optional FHIR Location uuid for the locationLevel2, technically expressed as a "district". You can retrieve these ids using our open . Your location levels are customised for your country needs in

If you are submitting addresses, then this is an optional FHIR Location uuid for the locationLevel1, technically expressed as a "state". You can retrieve these ids using our open . Your location levels are customised for your country needs in

A FHIR Location id for a facility that is already in the OpenCRVS database to track places of births or deaths in health institutions. You can retrieve these ids using our open . Your health facilities are customised for your country needs in

The for the address. E.G. UGD for Uganda, FAR for our fictional country Farajaland.

If the notification has been successfully processed by OpenCRVS, you will receive a 200 OK response and a full payload back.

token
officeId
districtId
stateId
facilityId
countryCode
Postman collections
Postman
authorization token
FHIR
standards
standards
Postman collections
FHIR Location API
FHIR Composition
authorization token
Location API
this step.
Location API
this step.
Location API
this step.
Location API
this step.
Alpha-3 country code
An Event Notification in the OpenCRVS In Progress view
Record Audit view for an Event Notification