2015-07-23 Developers Forum
Owned by Former user (Deleted)
How to Join
Click here to expand...
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
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:
TODOs
Transcripts
- Video recording: https://connect.iu.edu/p7mpr357rqg/