How to Join

Click here to expand...

By Browser

https://www.uberconference.com/openmrs

By telephone

US telephone number: +1 201.479.2627

Agenda

Quickly review previous meeting minutes (5 min)
Review next meeting agenda

Minutes

Attendees

Jamie Thomas

Darius Jazayeri

Ryan Yates

Rafal Korytkowski

Archana Eadara

Tomasz Mueller

Sri Maurya

Natalia

Sharon Varghese

Tharunya

Carolyn

Maimoona Kausar

Ali Habib

Ndisha

Mark

Agenda & Notes

OpenSRP w/ Ali Habib & Maimoona Kausar

OpenSRP started off as a project in India called Drishti,

Currently being developed by Thrive Consortium: Ona, John Hopkins, Harvard School for Public Health, mPower, ThoughtWorks, ...

Intended to be like OpenMRS but for frontline health workers

UI intends to mirror "what a typical health worker enters into paper registers", but optimized electronically

current work is around maternal-child health, and it's part of an ongoing study

ongoing effort to turn what was originally an app into a platform.

Chose OpenMRS as a back-end data store because many of the partners had experience with it.

And OpenMRS includes a powerful reporting component.

The idea for OpenSRP is that you could use other back ends as well (not just OpenMRS), but starting with OpenMRS.

(Maimoona having connectivity difficulties, so Ali will try presenting the rest...)

OpenSRP is a client-server system, with 3 basic components:

OpenSRP Client

OpenSRP Server

OpenMRS

(See presentation for libraries/tools used in these)

Client application shows a list of "register books" (this was designed based on how ANMs like to see their registers)

Each register shows a list of entries, with relevant columns. (E.g. "household register" has profile, last visit date, due date, etc). These need to be implemented by a register developer.

Forms are authored using xlsform standard (http://xlsform.org/)

also used by ODK; defines skip logic, calculations, constraints, labels, etc

benefit is that the "science team" or "form designer" can define the forms (using xlsforms) and test them out, before the developer integrate them into a register

There are examples in the presentation of an xlsform, and the various files that get generated from it, and the files it is integrated with

(see hand-drawn diagram of client, web, registers, and OpenMRS)

Client communicates with Web component of OpenSRP. Many functions are provided by OpenMRS back-end

e.g. client calls OpenSRP web to authenticate; forwards request to OpenMRS via REST, through a connector module

Team Management module (an OpenMRS module)

maps which users (health workers and providers) work at which locations

and who is on teams together

Forms are submitted from OpenSRP client to OpenSRP server. Saved in form repository. Submitted forms are also sync'd back to client

Error logging (for OpenSRP-OpenMRS communications?)

Robust scheduling component (implemented via MoTeCH)

schedules defined via a JSON format

produces alerts

Mapped the OpenSRP API to OpenMRS (e.g. patient, addresses, etc)

OpenSRP uses couchdb, so it's trivial to add new fields

Added (to OpenSRP) the idea of "Events and Obs", backed by Concepts (equivalent to Encounters, Obs, and Concepts)

Added 3 columns to xlsform definition that indicate mapping to OpenMRS concepts

Register sends form submissions to the OpenMRS Connector.

The submission is parsed into OpenSRP entitied like client, user, etc.

These are then pushed to OpenMRS via REST services, which saves successfully or throws an error

Errors are written to Error Logger along with a way that the transactions could be replayed.

OpenMRS Connector

OpenMRS for:

Authorization, Authentication, Privileges, User Management, Team Management

no user tables in OpenSRP: you just create users, priviliges, etc, in OpenMRP

OpenSRP queries OpenMRS to authenticate a user, and sends back the list of privileges, etc

DHIS Location Importer

since DHIS is used in collaborating countries

syncs locations down from DHIS into the OpenMRS location hierarchy

Team Management module

Reporting

implemented something to bring OpenMRS reports into OpenSRP (though these don't make it to the client yet)

Cohort Module

OpenSRP can record some data per-household (which OpenMRS doesn't natively support)

Sharon Varghese is working on GSoC project to allow storing household data in OpenMRS

Idea is that each household would be a cohort, and household members would be cohort members

Planned to use Metadata Sharing, but this isn't currently being used, since teams have standardized on using CIEL dictionary

IDgen (being used in Indonesia implementation)

Team Management module

see https://github.com/OpenSRP/openmrs-module-team

Challenges/Plans

Biggest challenge was mapping OpenSRP addresses to OpenMRS addresses.

Needed even more fields for Indonesia and Bangladesh. => combine multiple fields together as a key-value mapping in address5 in OpenMRS

OpenMRS REST errors are often non-descriptive, and require careful analysis by a developer whenever anything goes wrong.

CIEL dictionary updates aren't as fast as they'd like. E.g. auto-synching might help

Need to be able to support data about a group of people (e.g. household) but OpenMRS doesn't allow this now.

Q&A

A: For addresses, haven't yet asked/reported this to OpenMRS, but for things like cohorts, CIEL, idgen, and reporting, have been following OpenMRS work.

Q: If someone is using OpenMRS already, should they try to use OpenSRP, and how?

A: If you want to use existing OpenSRP registers, and you use the CIEL dictionary, it would be straightforward.

Q: What OpenMRS version?

A: Using OpenMRS 1.9.7 right now. And latest CIEL dictionary.

Learn more at the OpenSRP wiki:

http://smartregister.org/

https://smartregister.atlassian.net/

TODOs

Transcripts

Video recording: https://connect.iu.edu/p7mpr357rqg/

Browser not supported