1 / 43

Android/OpenMRS

Android/OpenMRS. Tom Routen D-Tree International Things Prim GmbH. NGO founded by Harvard School of Public Health lecturer, Marc Mitchell Develops health protocols for delivery within decision support software on mobile devices Paradigm case: IMCI -> «e-IMCI». D-Tree International.

arnav
Download Presentation

Android/OpenMRS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Android/OpenMRS Tom Routen D-Tree International Things Prim GmbH

  2. NGO founded by Harvard School of Public Health lecturer, Marc Mitchell • Develops health protocols for delivery within decision support software on mobile devices • Paradigm case: IMCI -> «e-IMCI» D-Tree International

  3. Sudden ubiquity of mobile phones • Phones qua phones • SMS • Voice • Phones qua computers • Data collection • Health protocols • D-Tree focus is NOT data collection, but rather improving patient care mHealth

  4. IMCI

  5. e-IMCI

  6. IMCI

  7. e-IMCI

  8. IMCI

  9. e-IMCI

  10. IMCI

  11. e-IMCI

  12. IMCI

  13. e-IMCI

  14. Future • Huwawei IDEOS available in Kenya for 100 USD • Capacities • CPU, RAM, database • Facility rather than community • Dont need to wait until Android phones are the norm Android

  15. Single visit • Patient comes in with complaint, gets advised and goes • IMCI (often) • Multiple visit • Patient comes in with complaint, gets registered, gets advised, returns regularly • HIV • Malnutrition Single Visit/Multiple Visit

  16. Single Provider • Patient comes in, is seen by one health provider and goes • Multiple Provider • Patient comes in, is seen by the nurse, goes to the doctor, goes to the lab, returns to the doctor, etc. Single Provider/Multiple Provider

  17. Three Core Functionalities

  18. Android/OpenMRS is an application framework being developed to provide integrated system with three core functionalities: • 1. Protocol Interpreter • 2. On-Device Patient Records • 3. Data Synchronization Android/OpenMRS

  19. Started 2010 • Still under development • In use in four pilot projects/research studies in Tanzania in a handful of clinics • Open source but not ready • Currently requires 1GhZ phone (NexusOne, HTC Desire) Android/OpenMRS status

  20. Operating System: variant of linux • Programming Language: variant of Java • Database: SQLite • Disk space: 32 GB cards Android Capabilities

  21. Android makes it easy for one application to call another (seamlessly) • Android/OpenMRS simply calls existing «logic engines» such as ODK Collect or Mangologic. • Logic engines return data to Android/OpenMRS, which transforms and stores in OpenMRS data model 1. Protocol Engine

  22. Name indicates connection with OpenMRS project which is technological - • Android/OpenMRS synchronizes records with OpenMRS Server (with custom module installed) • Uses same data model • Uses some of the OpenMRS API (written in Java) 2. On-Device Patient Records

  23. Patient, has • Encounters with • Providers, comprised on • Observations, which each pair • Concept with • Value OpenMRS data model

  24. Android/OpenMRS... • Handles «forms» marked up with «real» OpenMRS Concepts (from a Concept Dictionary) • Also handles «forms» with no concepts – internal «concepts» are automatically generated OpenMRS Concepts: Defined and Internal

  25. Vast majority of work is in devising synchronization scheme • Flexible • Efficient – mobile devices limited, network connectivity severely limited • Easy - usable 3. Data Synchronization

  26. Algorithm called PeerSync • Attempts to treat all possible sync partners as peers, devices and server • Successful synchronization of A and B results in both having same database • No prioritised copy – database is distributed (copied) among synchronizing partners • This is not upload/download from a server PeerSync

  27. PeerSync runs on device, but is also delivered in a custom OpenMRS module (PeerSync Module) • D-Tree has a server hosted at University Computing Centre Dar es Salaam • Running instances of OpenMRS server with PeerSync Module installed • Phones synchronize with server via GPRS Phone to Server synchronization

  28. PeerSync intercepts and records database transactions • Synchronization is the communication of transactions • Conflicts resulting from concurrent working are NOT currently handled. OpenMRS data model makes conflicts unlikely. Transaction Interception

  29. Devices and Server are both equal «units» with respect to serialization (i.e. This is not upload) • Post-synchronization, two units share the same database • Devices may synchronize with other devices via Http (WiFi) and Bluetooth • Devices may synchronize with server though server has MySQL, Device has SQLite PeerSync Flexibility

  30. Useful for remote clinic where connection with server is difficult • Router installed • Static IP addresses used • Clinic can function with medical records but with no server • Database is distributed (copied) among devices • Bluetooth is also possible but not popular Phone to Phone synchronization

  31. Incremental sync: A and B remember when they last synced, so sync can be incremental, but what if B re-inits? (checksums) • Creation date of transaction different from receipt date of transaction • Transactions accumulate monotonically • Database constraints can be broken by distributed actions Interesting computational problems

  32. Database is distributed (copied) among syncing units • So how to allocate «units» to databases? • 1 database per clinic? • 1 database per district? • Database merging and splitting? Scaling

  33. Consequence of sharing databases among units is: • Analyses could run on any unit, not just on server • Real-time distributed reporting On-Device Reporting

  34. Zanzibar Malnutrition • Ministry of Health • Supported by UNICEF and WHO • Detection and treatment of Severe Acute Malnutrition • Also as outpatients, using RUTF Example application

  35. Three Core Functionalities Required

  36. Longtitudinal Views

  37. How did you feel when you were providing care to the patients by using the phone? • `.. «simplifies communication between me and the client» • ... «simplifies the work compared with using paper forms» • ... «at first she thought she would never to understand the phone, but then after several practice it is very simple and understandable» Feedback

  38. Computational (sync) • Scale-up organization • Current device cost Challenges

  39. Questions? Thank you for listening

More Related