Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »

This overview of mobile tools that interact with OpenMRS is intended as a resource for implementers who may be interested in using such tools. If you are developing or innovating with mobile devices and want to share ideas, check out the Mobile Work Group.

Note: The mobile tools on this page use various methods for exchanging data with OpenMRS. A majority of these tools use the ?XForms Module. Attendees of a mobile break out session at the 2009 OpenMRS implementers meeting agreed that using the XForms module to integrate various mobile tools to with OpenMRS would be a good way to collaborate.

mOpenMRS (mobile OpenMRS)

General need/use case:  mOpenMRS was developed using the existing OpenXData mobile client listed below on this page. The original system was modified to suit the needs of IRD for supporting the MDR-TB DOTS program in Karachi IRD. This system was developed using the OpenXData mobile client which enables forms-based data collection on Java enabled phones such as Nokia 2700. The system incorporates new features such as personalized data for each treatment supporter that visits a patient and handles data at a more granular level by linking the users with cohorts assigned to them. mopenMRS has simplified settings and hides the connectivity details from the end user contained by the previous application. Limits the treatment supporter to only the patients he is assigned to for privacy reasons. It also removes searching on Server for patients not assigned to the treatment supporter.

How it works:

Enter URL in the Settings screen in the following format: http://www.ServerAddressHere/openmrs

eg http://122.234.244.132:8088/openmrs. 

  • Treatment supporter logs in the system
  • Cohorts are downloaded 
  • Patients are downloaded
  • Patients Forms are downloaded 
  • Patients are searched
  • Form(s) related to the patient are filled
  • Forms are uploaded
  • Encounters are uploaded and can be viewed by providers using 
  • Note: Currently cohorts are mapped  with users based on the cohort name. Therefore the cohort name has to be the same as the user name. Eg, user 'peter' would have only see cohort also called 'peter'
  • The  data is exchanged with the server using Xforms module built by Daniel Kaiwa (who developed the initial OpenXData-OpenMRS application)  

Implementation Details: For the treatment of TB patients we follow the internationally recognised and followed method of Directly Observed Therapy. In DOT a trained treatment supporter administers the dose to a TB patient and watches the patient take it. This is then recorded everyday along with other very important information such as side effects, any noticeable changes in patient's contacts (immediate family such as parents, spouse, etc). In the mobile application's pilot implementation we provided 3 treatment supporters Nokia 2710NE cell phones with the OpenMRS mobile application pre-installed. The mobile implementation or mOpenMRS allows quick reporting and enables the providers to view the patient status on the browser window when they log into OpenMRS. The mobile application allows treatment supporters to download cohorts (group of patients assigned to each treatment supporter), download forms and upload filled forms to the server. More can be found on this Google Group ict4chw

Pre-requisites:

  • OpenMRS Version 1.5
  • XForms module (used and tested with 3.7.9)
  • J2ME enabled phones

Cost: Open source

Download: projects:JAR File, projects:JAD file

Future Work/ Enhancements

  • Remove dependency on cohort name and user name by introducing link table in the database for making the cohort-user mapping.
  • Incorporate GPS

Known Issues

1) Some* *incorrect URLs can make the application download for a long time without giving proper error

2) System allows users to download forms when they click on a Patients details field and also from the main menu by clicking 'Download Forms'. Kindly use the later method since the first one doesn't work correctly.

Where to find additional information:

omar.ahmed@irdresearch.org

www.irdresearch.org

FrontlineSMS:Medic

General need/use case: We focus on long tail use cases. In other words, we work to make everything dirt cheap and dead simple. Our system enables forms-based data collection on cheap java enabled phones when only SMS (not GPRS) is available. Also used for coordinating house visits - for example OMRS generates a list of patients who missed their appointments, and blasts an SMS to the health worker nearest to each patient, asking them to follow up with a house visit.

How it works: Data collected on forms on the phone, sent to health facility via SMS where it is received by the FrontlineSMS software. This software translates the forms to XForms which are submitted to OpenMRS via the Xforms module. Also coordinating health workers with plain text (not form based) SMS.

Costs: $25 and up for phones. $80-200 for modem to connect computer to mobile signal, can also send bulk SMS via Internet gateway. Server software can be installed on server that runs OpenMRS or most computers. Utilizes SMS for broadest reach, but can transmit data via GRPS to reduce costs. Internet is not required. Software is free and open source.

Expertise Required: FrontlineSMS is quite simple compared to OpenMRS, installation on windows, linux, or Mac is simple and takes less than 5 minutes for someone who is computer literate but not a software developer. Sharing forms between FrontlineSMS and an existing installation of OpenMRS should be feasible for non-developers in late 2009 or early 2010.

Current Implementations: The FrontlineSMS platform is used at dozens of implementations across six continent, concentrated in Africa. Integration with OpenMRS is a relatively new project, first implementation (currently underway) involves 130 phone wielding community health workers at St Gabriel's Hospital, which serves about 250,000 people in rural Malawi.

Where to find additional Information: The FrontlineSMS:Medic website, or contact Field Director Isaac Holeman.

ChildCount+/RapidSMS

General need/use case: This is a community health worker information system built upon the RapidSMS framework, but being co-developed by Columbia University and UNICEF. The Millennium Villages Project needed a way to monitor children in particular, but entire villages more generally, for nutrition, malaria and other illnesses. The need was to have this data be incorporated into OpenMRS so that there is continuity and interoperability and that referrals between the home and clinic can be managed.

How it works: Structured text messages (SMS) on the phone is used to send information to the ChildCount+ server. Information from there is passed via Xforms to the Xform module within OpenMRS. Unique IDs are generated from OpenMRS using the IDGEN module and these are used to identify the patients between the systems.

Costs: $25 and up for phones. $80-200 for modem to connect computer to mobile signal. Server software can be installed on server that runs OpenMRS or most computers. Internet is not required. Software is free and open source.

Expertise Required: ChildCount+ is relatively simple to configure. Written in Python and object-oriented, installation on windows, linux, or Mac is relatively easy.

Current Implementations: The RapidSMS platform is used in many places, but the integration with OpenMRS is via the Millennium Global Village-Network and the Millennium Villages Project. Currently operational in Uganda and Kenya, the system is being rolled out to most of the 14 MVP sites in sub-Saharan Africa.

Where to find additional Information: The ChildCount website, or contact Matt Berg at mlberg@gmail.com.

PicoRosa

General need/use case: PicoRosa can be used for many of the use cases above, and can also send pictures. It is particularly useful when integrated with Google maps, as pioneered by IRD in Karachi, Pakistan.

How it works:

Costs:

Expertise Required:

Current Implementations: The MDR-TB treatment program at Indus hospital in Karachi Pakistan uses the OpenMRS MDR-TB module, PicoRosa, and Google Maps to track patients.

Where to find additional Information: Julia from Indus Hospital created a video overview of their MDR-TB program. Here's another video http://www.youtube.com/watch?v=5hEYn7cXZPY.

CommCare

General need/use case: Field based data collection, as well as coordination between mobile health workers and central management. In addition, CommCare assists CHWs to manage household visits and plan their day - structure that can be useful for CHWs who often receive relatively little medical training, have high turnover, and have limited opportunities to reinforce their knowledge once they begin working in the field.

How it works: ComCare is built on top of the open source JavaROSA platform.

Costs: Phones $180 and up. Requires GRPS. Software is free and open source.

Expertise Required:

Current Implementations: First implementation is currently underway in Tanzania.

Where to find additional Information: This project was initiated by Dimagi and D-tree
. See the ComCare page on Dimagi's website, read about D-tree, or read about ComCare in Tanzania here.

Openxdata-OpenMRS mobile application

General need/use case:
This application provides an interface for accessing OpenMRS via a J2ME phone. Useful for community/mobile health workers who need access to the OMRS system, for example, a health worker at small health center supported by a large hospital which runs OpenMRS.

How it works:

  • Health worker logs in with user name and password
  • Downloads available cohorts (if all patients then all patients must be available as a cohort?)
  • Selects a cohort and downloads the list of patients in this cohort. To save on data costs it is probably worth creating sensible sub-sets of patients
  • xForms in the openMRS system that represent a range of customizable encounters can then be downloaded onto the mobile phone.
  • Healthworker can then user the mobile interface to edit and submit forms for each patient and uploaded to openMRS.
  • If health worker wants to find a patient that is not on their phone, they can query the OpenMRS server and download that patient's file.

Prerequisites:

  • Requires ?XForms Module to be running on openMRS server
  • Requires J2ME enabled phone. In Pakistan, IRD have tried it running on sub $100 phones e.g. Nokia 2700 with success. It has also opened on Nokia 2600 but not tried serious usage.
  • openMRS 1.5 (not openMRS 1.6). The mobile client has not been updated to encompass more recent features of openMRS 1.6 and therefore although xforms module is compatible with 1.6 the mobile client currently available (also v1.6) is not.
  • GPRS connectivity

Download:

Costs:

  • Free and open source.

Expertise Required:

Current Implementations: ?

Where to find additional Information: ?

MoTeCH (Mobile Technology for Community Health)

General need/use case: Building a general, extensible platform to collect and disseminate information to community health care workers as well as health care seekers (patients) in the community. The system will allow community health workers to input data using mobile form (on a java-enabled handset) or structured SMS (on a simple phone) and transmit to an OpenMRS back-end using either GPRS or SMS. The system can then send regular information and reminders to health care workers and patients.

How it works: Currently being developed. The first implementation, in Ghana, focuses on building the platform to support improving the quantity and quality of antenatal and neonatal care in Ghana. Weekly text or voice messages in local languages can be sent to pregnant parents who register with the system providing them information tailored to their stage of pregnancy. Simultaneously, community health workers can enter all antenatal and neonatal care they provide, and both patients and nurses will be reminded with they are due or overdue for their next ANC, PNC or immunization. After this platform has been built and deployed in June 2010, MoTeCH will focus on extending and refactoring the system to become a general mHealth platform

Costs:

Expertise Required:

Current Implementations: Pilot program beginning in Upper East Region of Ghana in June 2010. Software and content development and implementation planning underway currently

Where to find additional Information: Contact Aliya Walji (awalji atat grameenfoundation.org) or Bruce MacCleod (macleod atat usm.maine.edu)

Open Data Kit (ODK)

Overview. Tools to help organizations collect, aggregate and visualize their data. Focused on data standards (i.e. Xforms), and using robust tools (Android software platform and compatible phones) to ensure organizations can collect rich data.

  1. Form Filling (demo). Has functionality in ODK Collect so you can download an OpenMRS XForm and fill it out (both text and binary data) and submit it back to OpenMRS as an encounter.
  2. Patient Summaries (demo). Users can view a list of patients and view and edit encounters on the phone. Concepts like weight and CD4 are graphed. All changes to the patient gets synchronized to the server.

How it works: Developed on Android, will initially communicate data via GPRS or WiFi. UI very robust.

Costs: Devices $200-$250 and up, hard to get/replace in Africa. Software is free and open source.

Current Implementations: USAID-AMPATH, the largest HIV treatment program in sub-Saharan Africa and Kenya's most comprehensive initiative to combat the disease. AMPATH is also one of the first and largest OpenMRS sites. Millennium Villages Project (MVP) is using ODK Clinic to record Verbal Autopsies and will be soon deploying in clinic situations. Working to modify the ODK Clinic code to allow for searching from the server if the patient is not on the phone. Can be used to easily register patients in the field and create them in OpenMRS.

Where to find additional Information: ODK's developers are members of the opendatakit.org.

Data Collection with PDAs

Can anyone elaborate on what PIH/Socios in Salud are doing with this in Lima?

General need/use case:

How it works:

Costs:

Expertise Required:

Current Implementations: Socios in Salud/Partners in Health, Lima.

Where to find additional Information:

MocaMobile

General need/use case: Focused on remote diagnosis. E.g. health worker takes pictures, video, registers symptoms, sends them to clinician, clinician makes diagnosis and informs remote health worker of appropriate treatment.

How it works: Developed on Android, passes Java Objects rather than Xforms or another standard.

Costs: Devices $200 and up, hard to get/replace in Africa. Software is free and open source.

Expertise Required:

Current Implementations: ?

OpenMRS-JR (JavaRosa)

General need/use case: Enable users to download cohorts, fill out forms for patients, and create new patients from a mobile device.

How it works: Developed in J2ME, downloads cohorts and forms from OpenMRS and submits the XML data back to the XForms Module.

Costs: Software is free and open source.

Pre-Requisits: OpenMRS, XForms Module, J2ME enabled phones

Expertise Required: Installing and configuring OpenMRS

Current Implementations: Hospital Albert Schweitzer Haiti (Initial pilot in progress)

Where to find additional Information: OpenMRS-jr

OpenMRS Messaging Module

General need/use case: The messaging module allows for communication into and out of an OpenMRS installation. It currently supports connection via a directly attached SMS capable modem, email account, Twitter (r) account, or connection to a Nuntium server (a more robust messaging system with SMPP capability, archival, and more). The messaging module is currently independent of the Xforms module to allow for use cases such as community education, patient-initiated system queries, and more.

How it works: The Messaging Module takes advantage of the OpenMRS database schema to store messaging delivery options for all users (including "patients" as users) in the OpenMRS installation. Once stored, when messaging requests are received by the messaging module it then looks up that user's preferred messaging modality and delivers the message. The messaging module utilizes java libraries such as SMSLib, JavaMail, and java-twitter to perform the delivery of these messages.

As an alternative, the messaging module also supports connection to a Nuntium server. This allows for a direct SMPP connection (greatly increased throughput for SMS messages but this will require a direct connection to your telephony provider). Nuntium will also handle the above messaging modalities, so our users have the option of either direct connection or via Nuntium or both in rare use cases.

Costs: The module is open source and freely available on the OpenMRS module repository. SMS capable mobile devices cost anywhere from $10 on up. An SMS capable modem for the OpenMRS installation is anywhere from $50 on up. Email and Twitter accounts are free. Nuntium is also freely available and open source. An SMPP connection is costly, but these costs are also highly negotiable and up to your telephony provider.

Expertise Required: When completed, the messaging module will be available as an .omod file on the OpenMRS module repository and will require the technological expertise to download and install the module using the interface in the OpenMRS Admin UI. For direct connections (via a locally attached modem, email account, or Twitter(r)), the end user will need to make a few small tweaks to the messaging module via a user interface on the OpenMRS Admin UI. For connection via Nuntium, the nuntium server will need to be specified on the messaging module's interface and then Nuntium will need to be configured.

Current Implementations: Still in development. If you're interested in implementation, please contact zeshan (at) openmrs (dot) org so that we can support you and improve the module with your experiences.

Where to find additional Information: ?MM FAQs, ?Messaging Module, MMSyntax

OpenMRS Planet-Updates App

General need/use case: "OpenMRS Planet-Updates" is a Mobile Application which has developed to get informed about All the news and updates from OpenMRS world easily at your fingertips.

How it works: By using the official OpenMRS RSS feeds.

Costs: Free and Open Source

Expertise Required: For Development : PhoneGap/HTML5/JavaScript, Android/Java

Where to find additional Information: OpenMRS Planet-Updates App for Android

Muzima

General need/use case: Muzima is an ongoing effort to consolidate the mobile based system around AMPATH.

How it works: Muzima API

Costs: Free and Open Source

Expertise Required: For Development : PhoneGap, HTML5, AngularJS, Android, Java

Where to find additional Information: https://github.com/muzima/documentation/wiki/_pages, https://github.com/muzima/documentation

Github repos: https://github.com/organizations/muzima | Mailing list: https://groups.google.com/forum/?hl=en&fromgroups#!forum/muzima

SMS, USSD services for Patients

General need/use case: Medical data must be accessible to a patient through many channels. This DEMO Application will allow a patient to access and edit their OpenMRS system information through SMS, USSD. Patients will be able to edit their details, view structured medical data, see current prescriptions, and etc.

How it works: through SMS, USSD

Costs: Free and Open Source

Expertise Required: For Development : J2EE

Where to find additional Information: SMS, USSD Services for Patients

OpenMRS-iOS

General need/use case: Designed as a jumping-off point for others to add features. OpenMRS-iOS was created in about 23 hours by Parker Erway during Google Code-in 2014. Available on GitHub: https://github.com/Undo1/OpenMRS-iOS.

How it works: On the login screen, enter the URL of the server running OpenMRS, in the format http://host.org/openmrs. Enter your username and password, then tap "sign in'. Upon success, the login page closes and a main menu is shown. It currently only contains "find patients", but more features can (should!) be added. 

Costs: Open-source

Expertise Required: Currently the app is very simple, and can be operated by anyone with basic training.

  • No labels