| Table of Contents |
|---|
Points of Contact
Dimagi - Anton de Winter
Cell Life - Munaf Sheik
OxD - Mark Gerard
UNICEF - Kieran Schafer
ODK - Yaw Anokwa
MVP - Matt Berg
Open MRS -
Data Dyne -
D-Tree - Jonathan Payne
...
Notes from various discussions:
...
:
dynamic role-based handlng of page requests
easy to build pages out of a common library of useful components
good patterns that are easy to copy
UI redesign
Concepts - for interoperability & sharing. e.g. what is malaria & all included variations
MVP Concept Dictionary: 47k concepts, lots of languages
Centralized repository of concepts matched with IDs
Javarosa Project Updates:
Afrosys: 8 people developing mobile applications, Spring and all this Java type stuff
Nigerian Government: used RapidSMS and other open source mobile platforms, looking into OpenMRS.
Kieran (UNICEF) - RapidSMS to collect nutrition data in Malawi. Investigating touch screens in addition to SMS. Also using OpenMRS-Jr client for cell phones.
Sara (IRD, Pakistan) - OpenXdata. Had to hack around it for some privacy reasons, changing the workflow. DOTS.
Olivia (MVP) - point of care decision support for nurses. Looking into Android ODK. Retreiving data for long-term care.
Gerald (DataDyn) - Wants ability to tag photos.
Yaw (UW) - ODK Collect. Media as questions instead of text. Collect & export data.
Jon (Dimagi) - all OpenRosa except OpenXdata. Not doing surveys directly, mostly community health work
Android OpenMRS:
D3 - light clone of openmrs to android. Implemented, pilot project soon in zanzibar. Enables execution of specific protocol (registration, treatment for malnutrition) they don't check for conflicts in data.
ODK Clinic - Similar, but assumes connection to a server. Form-filling and dl replacemt, dl a cache, mostly still online. Data exporting in multiple forms (stream to google maps etc)
SANA - XML config files, push to SANA engine and get forms back.
EMOCHA - they encrypt all written data. focus more on education. video training + quiz at end. Working on deployment
DAY 3
OpenMRS Point of care: support improvements, reduce staffing, improve quality of care Need: high value data, ease of use, good uptime, good fall-back systems, limited goals (something better than lots of nothing)
JavaRosa/OpenMRS APIs: Deciding on an API so that openMRS compliant clients can easilty communicated with openMRS (2.0 requirements) Got caught up on Patient List API previously, trying to push forward today. Historical Data: use cases: applying different questions based on previously answered questions (preg/notpreg) displaying charts, patient summary display displaying latest updates from last encounter (prev values) retrieve personal summaries prior therapy date(s) review of data submitted at end of day means: download pre-filled xforms xform produces xml document. filling out the xform populates the nodes. if nodes are already filled out they act as default answers. You can use hidden nodes to fill in data thats invisible (e.g. HIV status = positive) pre-filled instance data long external IDs check digit validation invalid IDs (avoid revise) embedding data for non-mobile processing when submitted. limiting selections of large lists knowing relationships (children etc) default answers dynamic boundaries (age between 0-20) Future Topics: Metadata between OpenMRS and JavaRosa: Patient Summary:
Future Direction of OpenRosa: Past & where we are: ~15 ppl meet in Boston, discuss nondupe of effort & interop & share experience We've started duplicated effort -- 3 different yet similar J2ME clients. (fail). This happened bc everyone pooled on a client, but no end-to-end solution. then everyone had to go do their own thing server side. Why so much duplication? priorities use cases business decision platform preference What to do about it? Reference implementation of (esp of server end) publicity -- put all this on a website openXdata and android ODK are end-to-end systems, could both be reference implementations Merging EMIT and OpenXData. Do we want to be a service body to implementers or programmers? So far it's been programmers Anton will be champion of working groups Kieran & Brian will be implementers website champion Mark is reference implementation champion DAY 4: Capacity Development: training developers, putting openMRS in the curriculum, code it in country and the infrastructure gap people need to know wehre to get openMRS support and get certified Lightning talks: interoperability: use cases v important openMRS metadata: moving between openMRS servers using a web app SDMX to OpenMRS interoperability: Messaging modules (frontlineSMS): exposed APIs and variety of sending methods. Easily extensible. Pilot in Kenya, out for testing now. Sy's allergy and problems list Rita's growth charts: configurable data sources. gives doctors a reason to use the system bc they get something out of it. xforms module and ODK clinic: openMRS appliance = vm w openMRS install ODK collect OpenRosa: elections champions? committee? October 30: spec deadline, neal gets website done January 15: elections for champion sub-champions: Dimagi: Anton Cell-life: Munaf OXD: Mark UNICEF: Kieran ODK: Yaw-->Mitch MVP: Matt Berg OpenMRS: ??? DataDyne: ??? (ask Joel) D-Tree: Jonathan Payne
Thanks to Amelia for taking these notes!
...
FrontlineSMS -- runs on computer, SMS capabilities. -
- messaging module
...
- frontline forms (j2me)
RapidSMS
DTree is porting openMRS to Android
...
What do people actually need?-
- patient messaging (en mass based on need e.g. hypertension)
...
- sending message to CHW. Patients to message Doctors.
...
- sending message to CHW. Patients to message Doctors.
...
- Patient outreach/followup/case management
...
- point of care (decisin support)
...
- facility referrals
...
- logistics management
...
- feedback reports
...
- birth/pregnancy/patient registration
Generally if u can send an SMS GPRS will work too
...
Historical Data:
use cases:
- applying different questions based on previously answered questions (preg/notpreg)
- displaying charts, patient summary display
- displaying latest updates from last encounter (prev values)
- retrieve personal summaries
- prior therapy date(s)
- review of data submitted at end of day
means:
- download pre-filled xforms
- xform produces xml document. filling out the xform populates the nodes.
- if nodes are already filled out they act as default answers.
- You can use hidden nodes to fill in data thats invisible (e.g. HIV status = positive)
- pre-filled instance data
- long external IDs
- check digit validation
- invalid IDs (avoid revise)
- embedding data for non-mobile processing when submitted.
- limiting selections of large lists
- knowing relationships (children etc)
- default answers
- dynamic boundaries (age between 0-20)
Future Topics:
- Metadata between OpenMRS and JavaRosa:
- Patient Summary:
Future Direction of OpenRosa:
Past & where we are: ~15 ppl meet in Boston, discuss nondupe of effort & interop & share experience
- We've started duplicated effort -- 3 different yet similar J2ME clients. (fail).
- This happened bc everyone pooled on a client, but no end-to-end solution. then everyone had to go do their
...
- own thing server side.
Why so much duplication?
- priorities
- use cases
- business decision
- platform preference
What to do about it?
- Reference implementation of (esp of server end)
- publicity -- put all this on a website
- openXdata and android ODK are end-to-end systems, could both be reference implementations
- Merging EMIT and OpenXData.
- Do we want to be a service body to implementers or programmers? So far it's been programmers
- Anton will be champion of working groups
- Kieran & Brian will be implementers website champion
- Mark is reference implementation champion
DAY 4:
Capacity Development: training developers, putting openMRS in the curriculum, code it in country and the infrastructure gap
...