OpenRosa 2010 Discussions

Owned by Former user (Deleted)
Last updated: Sept 23, 2010 by Former user (Deleted)Version comment
5 min read

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

Models

Champion

  • Multiple Heads
  • Single "Platform"
  • Funding
    . Comittee

Deadlines:

  • October 30 - Spec Deadline and Website UP
  • Jan 1 - Send announcement about voting information
  • Jan 15 - Nomiations Due
  • Jan 31 - Elections Done

Who Votes:

  • Self Certified involvmenet
  • One per Person
  • Publish who voted
  • Private (mostly)

OpenRosa API List

See the OpenRosa Standards Wiki for more information.

  • [ORC] - Authentication
  • [ORC | Old] - Form List/Form Update/Profiled Forms
  • [ORC] - Patient List/Entity Download
  • [ORC | Draft] - Form Submission (overwrite capabilities)
  • [ORC | Draft] - Metadata
  • [Draft] - Client Usage / stats
  • Decision Support Download
  • Memory Card or Bluetooth submission
  • [Draft] - SMS Transmission
  • [Draft] - User Registration
  • [Draft] - Case Management / Program management
  • HTTP Headers
  • De-registration
  • Historical Form Download
  • Draft - Xform References External Data

authentication api

  • digest auth on client and server]
  • basically ready to ship.

form list api

send up to get list

  • user credentials (for auth)
  • display language (show me listing in swahili)
  • form namespace (get me only cell-life forms)
  • verbosity (form names vs form names + descriptions)

include in the listing

  • localized form names (human readable)
  • versioning of forms (human readable)
  • multimedia/resources location and packaging.
  • url, date, versioning, description, tags, uid=xlmns
  • browsing through a list of forms? (not common)
  • form type? adult form, child form (not common)

entity download api

  • no easy way to do generic entity download
  • specify xformsy patient, household, etc api for openmrs
  • likely include downloading entire cohors

form submission api

  • http posts we do are documented
  • in draft stage

metadata api

  • add as markup in form
  • in draft stage

history form download api

  • include instance data as download and reference

clinical summary document api

  • implement ccd/cda as standard

concept integration api

  • punt for now

case management api

  • punt for now

Notes from various discussions:

Thanks to Amelia for taking these notes!

OpenMRS Day 1: 9/9/2010

OpenMRS 2.0 -- concept of distributions, UI framework refresh decoupled from "core".  Apache-like community

OpenMRS new website -- lots of cool new features, especially for developers.  JIRA for issue tracking.  

Fisheye + Crucible for code review.

MODULE DEVELOPMENT

If theyre released publicly you can count on it

open MRS modules API, modules allow you to replace parts of UI

module development is fairly easy, know Java and XML.  One config file.

MOBILE APPLICATIONS

Platforms that use OpenMRS:

FrontlineSMS -- runs on computer, SMS capabilities.  

  • messaging module
  • frontline forms (j2me)

RapidSMS

DTree is porting openMRS to Android

summary:

SMS: messaging module

J2ME: openMRS-jr, picorosa/OpenXdata

Android: SANA telemedicine, android OpenMRS, ODK Clinic

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

If you give openMRS a list of API calls u want, they will implement them for 1.9

DAY 2 9/10/10

OpenMRS 2.0:

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:

Afrisis: 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