OpenSRP realizes the fact that Relational and No-SQL DBMSs are both mastered in different types of domains, and the features provided by each can not be ignored, therefore, you find different DBMSs used in OpenSRP for different types of functionality.

The data storage used by OpenSRP are as follows and the documentation further explains only first two in details

• CouchDB
• MySQL (App portable to Postgres)
• SQLite (Used by mobile client only)

CouchDB

This is the main repository where all Individual and identifiable data with each and every detail is stored. There are different databases in CouchDB repository named as

drishti:

• This is the main database where all entities are registered as unique, identifiable record showing the role of entity in system. All entities can link to any other entity by entityId/baseEntityId. Some example entities are Mother, EligibleCouple, Child etc.
• The repository also contains all Actions (maintained and triggered via motech schedule tracking) to be taken on certain schedule. These actions are used by mobile client to show alerts for ANMs for any specific schedule.
• The repository unnecessarily contains few configuration variables like InfantBalanceOnHandReportToken and FormExportToken and would be removed in next versions to motech scheduler handler.

drishti-form

• Every form filled by client application is directly submitted as it is into form  repository  without any normalization or concern with the role of entity into system.
• The submitted forms are then periodically processed by ziggy to be broken down into respective entities forming the registers. At this point the form data is processed and normalized according the view or data that actual register needs to show. The processed entities are then stored into drishti database.

motech-scheduletracking-api

• This is the repository internally used by motech for managing health schedules for generating alerts (OpenSRP maintains alerts in the form of Action)
• It also contains JSON schedules and Entities enrolled into any schedule.

drishti-mcts

The database contains all reports generated by MCTS report generator component. The MCTS report generator generates MCTS reports and sms these reports to a configured number for audit and reporting purposes for maternal and child health.

Postgres/MySQL

openmrs

• OpenMRS works on relational database and recommends MySQL and has pretty stable and scalable datamodel. For details about OpenMRS datamodel and working see https://wiki.openmrs.org/display/docs/Data+Model . OpenSRP internally doesnot make any call to OpenMRS database directly.
• All the communication with OpenMRs is done via REST calls. To dig into REST services provided by OpenMRS see https://wiki.openmrs.org/display/docs/REST+Web+Services+API+For+Clients and https://wiki.openmrs.org/display/docs/REST+Web+Service+Resources+in+OpenMRS+1.9.
• Moreover all authentication, teams and locations data is maintained in OpenMRS and accessed via REST services into OpenSRP.

motechquartz

• This database is used internally by motech scheduler for managing schedules for triggers and jobs.
• All details about the status of a scheduled job and its timings/trigger is maintained in this database.
• Note that this database does not maintain any individual records for entities`s schedules and neither does it keeps track of old jobs/triggers completed.

opensrp (drishti in older versions):

• If DBMS is postgres you would find a container/umbrella database for schemas below. MySQL doesnot treat database and schema differently hence schemas below would be independant databases in MySQL.
• This is where data for ANM reports is maintained.

report

• This is where old drishti app maintained its ANMs and their location mappings. This is no more being used for this purpose.
• The schema also keeps track of ANMs as service providers and services provided by each ANM for aggregated reports.
• Annual targets for ANM and indicators are also managed in this database.
• The final output from this database is generated in the form of a DB View that lists the ANMs and the services provided by each with location and date.
• This data is used by aggregator provider bamboo to get summary reports.
• This data is also used by drishti-site for allowing users to download aggregated reports.
• Although part of latest OpenSRP code but this module is abandoned by OpenSRP and replaced by OpenMRS reporting module.

anm_report

• Whole purpose of the schema is to generate and keep data for ANM summary for mobile client. The table anm_report_data holds all data for this summary by indicator, date and ANM.
• It also has a column external_id that holds the entity_id for beneficiary so that record could be tracked down to CouchDB anytime. This also helps in tracking actual person in summary reports on client.