Architecture
The technical architecture of OpenCRVS was designed to conform to the Open Health Information Exchange (OpenHIE) architectural standard and interoperate using HL7 (Fast Healthcare Interoperability Resources) or FHIR. FHIR is a global standard application programming interface or (API) for exchanging electronic health records.
By following the OpenHIE framework, OpenCRVS seamlessly connects civil registration to health services and other systems. Firstly, by utilising the OpenHIE interoperability reference middleware OpenHIM, a FHIR standard enterprise service bus; and secondly, by using a scalable, modular, NoSQL FHIR datastore, called Hearth.
We use OpenHIM to receive birth and death notifications from a hospital setting, and expose registration events to any other technical system via an API gateway e.g. MOSIP foundational national ID, or DHIS2 health Information Management.
OpenCRVS business functions are designed using modular, event-driven microservices. Each micro service and every OpenCRVS component is independently scalable in private or public cloud, in large or small data centres, and easy to manage, load balance and network using included Docker Swarm configurations.
OpenCRVS builds on these sound principles by additionally providing:
Easy country configuration via simple csv files and a configuration UI.
Standards-based multi-language content management.
A market-leading, powerful search and de-duplication engine powered by ElasticSearch.
Real-time performance analytics powered by the time-series database Influx.
An Amazon S3 compatible object store for storing supporting documentation attachments powered by Minio.
Increased performance by the use of GraphQL, reducing HTTP requests between client and server.
An automated continuous integration, delivery and testing suite.
A single JS, TypeScript codebase for backend, desktop and mobile using Progressive Web Application technology for offline and low-connectivity access.
External server and application health monitoring using Kibana
Automatic LetsEncrypt SSL configuration
SMS 2-Factor Authentication with well defined user role authorization privileges
OpenCRVS is a full-stack that is designed to give you the lowest possible "total cost of ownership".
Our international development teams work in an Agile way, in tandem with local development resources and human-centred designers, following the Scrum methodology, to rapidly design, build, deploy, test and maintain OpenCRVS releases.
Open source dependencies
The following dependencies are automatically provisioned alongside the OpenCRVS Core in docker containers in a Docker Swarm on Ubuntu.
Docker Swarm
Docker Swarm was chosen by our architects in 2018 for it's lack of requirement of other essential dependencies, it's close alignment with Docker and it's simplicity in terms of installation and monitoring on a Tier 2 private data centre, on bare metal servers with headless Ubuntu OS. Why not use AWS, public cloud SaaS or serverless you might be thinking?
Many countries may be located far from a high-quality data-centre above Tier 2.
Many countries may not legally support international data storage of citizen data on a public cloud. Getting the legal approval for external storage of citizen data requires regulatory change which can take a considerable amount of time.
Because some countries may not be able to maintain complex software independently, we are considering a SaaS solution, provided enough countries get regulatory approval. Over time, this situation appears to be slowly evolving and we are monitoring it closely.
Previously unskilled system administrators can quickly up-skill in the techniques of private cloud infrastructure management using Docker Swarm. We wanted to democratise containerisation benefits for all countries.
Is there a plan for Kubernetes?
We are working on a Kubernetes migration now that Kubernetes has become a more mature, easier to use and configure solution, thanks to dependencies like Helm and other plugins increasing popularity since 2018. In the meantime, Docker Swarm makes it easy to commence containerised microservice package distribution privately, automatically configures a "round robin" load balanced cluster, and provides Service Discovery out-the-box.
Hearth MongoDB Database layer
In order to support configuration for limitless country scale, OpenCRVS was designed for NoSQL, built on MongoDB, and aligned to a globally recognised healthcare standard.
Massively scalable and extensible, Hearth is an OpenSource NoSQL database server originally built by the OpenCRVS founding member Jembi Health Systems, using interoperable Health Level 7 FHIR v4 (ANSI Accredited, Fast Healthcare Interoperability Resources) as standard.
We extended FHIR to support the civil registration context. Our civil registration FHIR standard is described here.
ElasticSearch
OpenCRVS uses ElasticSearch, an industry standard, NoSQL document orientated, real-time de-duplication & search engine. Lightning fast, intelligent civil registration record returns are possible, even with imprecise “fuzzy” search parameters.
De-duplication management to ensure data integrity is essential to any civil registration system. A fast search engine lowers operational costs and improves the user experience for frontline staff.
ElasticSearch is also used with Kibana for application and server health monitoring. \
InfluxData
The hyper-efficient Influx "time series database" is used in our stack for "big data" performance insights. Millisecond level query times facilitate civil registration statistical queries over years of data, disaggregated by gender, location and configurable operational and statistical parameters. \
OpenHIM enterprise service bus, interoperability Layer
The OpenHIM (Health Information Mediator) is a NodeJS enterprise service bus designed to ease interoperability between OpenCRVS and external systems such as Health & National ID. It provides external access to the system via secure APIs. OpenHIM channels and governs internal transactions, routing, orchestrating and translating requests into FHIR between services and the database layer.
OpenCRVS packages
The core of OpenCRVS is a monorepo organised using Lerna. Each package reports unit test coverage in Jest. Following the microservice, 1 service per container model, every package is independently scalable in a single docker container.
Microservice business layer packages
The OpenCRVS microservice architecture enables continuous evolution of its business requirements.
The microservices are written in TypeScript (a strictly typed superset of JavaScript that compiles to JavaScript) and NodeJS using the HapiJS framework.
Each microservice in OpenCRVS has no knowledge of other services or business requirements in the application, and each exposes it’s capabilities via JWT secured APIs.
auth - the authentication microservice for OpenCRVS, JWT token generation and management in Redis. Our client applications are protected by SMS 2-Factor Authentication. Our apps and microservices utilise OAuth best practices for JWT tokens.
commons - a shared library package that all microservices use in order to validate JWTs
config - an application configuration microservice to power a configuration GUI for forms, application settings and certificates
gateway - the GraphQL and Apollo API gateway for the OpenCRVS client. GraphQL allows OpenCRVS to perform much faster and more responsively in remote areas by drastically reducing the number of HTTP requests that are required in order to render a view in the presentation layer. The OpenCRVS GraphQL Gateway is a JWT protected Apollo server that requests and resolves FHIR resources from Hearth via OpenHIM into GraphQL, for easy consumption in the client applications.
notification - the microservice that manages SMS communications from OpenCRVS, communicating with a choice of 2 3rd party SMS Gateways.
search - the search microservice for OpenCRVS using ElasticSearch
workflow - the OpenCRVS business process orchestration microservice, mediating civil registration vital event status and audit updates.
Client application packages
Using an Android progressive web application for our client applications means that we can take advantage of offline functionality and native mobile features using Workbox, without the overhead of maintaining multiple web and mobile codebases and respective App/Play Store releases.
In remote areas, registrars can save a configurable number of registrations offline on their mobile phone, using IndexedDB.
Client npm dependencies and enablers include:
Easy build configuration with create-react-app, craco, typrescript-eslint
Multi-lingual content management support using Format JS
ES6 JS component styling using styled-components
Fully configurable, high performance form management using formik
Pure JavaScript, client side, offline PDF certificate generation using pdfmake
Read-only application state management using redux
Support packages
integration - performance tests for OpenCRVS using the K6 framework.
components - a UI component library package for the clients using React Storybook
Automated testing support
OpenCRVS Core displays Codecov enforced 80% unit testing coverage on git. We supply example e2e UI test scripts using Cypress and cover the main registration business functionality in those tests.
Because the OpenCRVS Form UI is configurable to your country, the end-to-end testing scripts are located in our example country configuration server for Farajaland so you can copy this approach and customise them depending on the structure of your published form.
Last updated
