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

Interoperability

An introduction describing how OpenCRVS interoperates

PreviousSecurityNextCreate a client

OpenCRVS has been technically architected from conception to interoperate with other e-Gov systems in a standardised, safe and secure way.

We have demonstrated how easy it is to interoperate with OpenCRVS in the past by:

a) being a core collaborator of the initiative.

b) installing a permanent installation of an OpenCRVS and National ID integration with at the MOSIP Experience Center in Bangalore, India.

c) integrating with to standardise birth and death notifications from a hospital setting for civil registration using .

As of OpenCRVS v1.2.* we now provide a simple GUI to set up, enable and disable integrating clients that generates and refreshes API keys.

There are 4 common interoperability use cases you can easily take advantage of using our new GUI and specific API Gateway endpoints in JSON and GraphQL.

  1. Event Notification: Allow any other service to POST full or partial civil registration event applications to OpenCRVS - referred to in civil registration nomenclature as a "notification". Most commonly these are submitted by hospitals, but you could also use this functionality to enable application submission from a social protection system or a public portal.

  2. National ID: Ensure a National ID system is notified by a webhook whenever an event (birth or death) is registered in OpenCRVS. Use this to create or deactivate National ID numbers, or use it to authenticate citizens before allowing them to register an event.

  3. Record Search: Allow any other service to perform an advanced search of civil registration records. Use this to help support social protection systems, check the existence of civil registration records or check citizen demographics.

  4. Webhook: Allow any other system to subscribe to event in OpenCRVS and retrieve a customisable payload of registration data. Allow any system to react immediately when a birth or death is registered.

The following sections will describe step-by-step instructions regarding how to configure these integrations as well as show you how you can expose OpenHIM to have full interoperability control over OpenCRVS.

Other ways to interoperate

OpenCRVS' database layer for all registration data is expressed in JSON as in MongoDB and exposed via a FHIR database server called . This means that our schema is automatically thoroughly documented in the HL7 FHIR specification. We have made some customisations to support the civil registration context hat are documented in the section. We knew how important it would be for health institutions to be able to send us birth and death notifications from the beginning, hence our early adoption of FHIR as our interoperability standard. This also makes it easy for interoperating systems to understand our data.

We expose some FHIR APIs directly via our API Gateway, specifically for performing CRUD actions on which we use for administrative structure, civil registration and health office buildings where registrations occur. When OpenCRVS is running you can view documentation in this Gateway.

OpenCRVS stack includes . The Open Health Information Mediator is a middleware component designed to ease interoperability between disparate information systems. Both OpenHIM and Hearth are OpenSource projects developed by . It is possible to expose direct access to OpenHIM in OpenCRVS Core, should you wish to interoperate with it.

FHIR
Hearth
standards
FHIR Locations
Swagger
OpenHIM
Jembi Health Systems
G2PConnect
MOSIP
DHIS2
FHIR
Using the OpenCRVS v1.2.* Integrations GUI to configure a webhook client