Features
From MoCa Development Wiki
Moca is made up of 3 main software components: Android client, Moca Dispatch Server, and OpenMRS medical record system.
Contents |
Android Client
http://code.google.com/p/moca/source/browse/#svn/clients/android/trunk
Our Android client can do the following:
- Download forms from the MDS (described below)
- Render form as a UI in the phone for user to fill out
- Sync with the MDS/OpenMRS to sync patient information, procedures (for offline usage when outside of GPRS coverage)
- Create a new patient if the patient doesn't have an OpenMRS record yet
- Scan linear or QR barcode from patient ID card, or manually type in patient info
- Upload completed cases (filled out forms) to the MDS via REST API. (The MDS passes it on to OpenMRS, where it shows up in our queue, more info below)
- Upload cases via background service and when data connection is available. User can inspect upload queue / see status of pending uploads
- Collect GPS, Picture, and Audio data, in addition to all common forms of text entry
- View previously completed cases for a patient
- Upload binary data in small chunks to work around high packet-loss in rural areas. Packet size changes automatically to find the 'sweet spot' for a given network link
- Receive diagnosis / treatment recommendation for patient via SMS and display notification to user
We do not have XForms support and it's currently our main priority now that we have released our version 1.0. Our current form format is a custom XML format that looks like this:
Middleware Server "Moca Dispatch Server" (MDS)
http://code.google.com/p/moca/source/browse/#svn/servers/mds/trunk
The MDS is a Django-based middleware server written in Python that sits between the phones and an EMR backend (e.g. OpenMRS).
Motivation: If you are developing for n phone platforms and m EMR backends then you have to maintain n*m EMR-specific implementations (m per client).
It has two purposes:
- Provide a standard REST API that all the different Moca clients can implement in order to remotely interact with an EMR backend.
- Remove the need to support mobile-specific features in each EMR
- Allow us to support any EMR by writing a backend for it into the MDS
Having the MDS simplifies our interaction with OpenMRS. The phones upload data piece by piece and the MDS collects all the data for a given case and submits it to OpenMRS.
The MDS is also in charge of all of our SMS interactions. We use Clickatell but you can change the SMS backend it uses. We wrote a tiny library so that we can send structured data over SMS (with some overhead of course). We use this to send arbitrary-length (i.e. not limited to 160 characters) notification/diagnosis data from OpenMRS to the phones over SMS, but not currently for data from the phones to the MDS.
OpenMRS Modules
We rely on:
- REST Module (We'd like to start contributing to this module -- we have our own customizations for it that we'd like to contribute back).
Media Viewer Module
http://code.google.com/p/moca/source/browse/#svn/servers/openmrs-modules/viewer/trunk
We created an enhanced (Moca-independent) encounter viewer module for OpenMRS. OpenMRS's encounter viewer lacks the ability to view media like images, audio, and video in a rich manner. Our Media Viewer module is capable of the following:
- Images can be panned/zoomed, and parameters (e.g. brightness, contrast, sharpness) can be changed on the fly.
- Audio recordings (mp3) can be played in browser
- Video (flv) can be played in browser.
- Applet can go fullscreen
- All files can be downloaded for viewing on the PC
These features are accomplished in-browser via Flash. We would be happy for other groups to join us in maintaining this module, as it seems to be something we would all need.
Moca Module
http://code.google.com/p/moca/source/browse/#svn/servers/openmrs-modules/moca/trunk
Our module for OpenMRS presents a simple queue-based workflow to allow providers to address incoming cases/forms from the phones. From the queue you can view an encounter using a Moca specific encounter viewer that:
- Embeds the Media Viewer module's viewer for rendering ComplexObs's
- Shows all the responses to questions in a given form that were uploaded from a phone
- Allows the provider to select diagnosis codes from an ontology such as SNOMED
- Make commentary and diagnosis recommendations (or request more information). These are transmitted back to the phones via SMS and summaries are emailed to all providers involved.
- All recommendations are stored in the same encounter as further observations from the provider.
The Moca module also exposes an API that the MDS uses to publish encounters to OpenMRS. To send SMS and email, our Moca Module uses the MDS's REST API to request that the message be sent. When new cases come in they show up in the queue and doctors who are members of various roles are notified via email or SMS.
What We're Working On
We are actively working on the following tasks:
- OpenROSA / XForms support -- Switch to using the XForms module for OpenMRS to design forms. Swap out the serialization/deserialization format on the phone with XForms. This is our top priority since we released our version 1.0 and it should be done within the month.
- Filter the Moca Queue by various different criteria (for larger Moca deployments which might be multi-site or have multiple clinical scenarios)
- Filter by OpenMRS Location
- Filter by Provider Role (e.g. designate a case for TB Specialist role)
- Filter by Patient/Provider OpenMRS relationship
- Bluetooth connectivity with hardware devices (MIT Media Lab bluetooth sensors as well as off-the-shelf/OEM sensors)
- SMS upload of cases : For regions with no data connection -- for text-only cases we are working towards supporting SMS-ing the text to the MDS via many messages (structured as described in the MDS section)
- Localization
