Mobile Transport Layer

Owned by Former user (Deleted)
Last updated: Aug 04, 2024 by Olara Moses
5 min read

This page is outdated and no longer receives updates!

<html><head><title></title></head><body>h1. Background

HIV medical outreach frequently occurs in resource constrained settings, often far away from primary clinical locations. Handheld computers are often more practical for data management in remote settings. In addition, cell phones are used extensively in developing countries. As such, there's a need for tools to both collect and process information related to a person's care using mobile devices. We are developing software to run on mobile devices to carry out this work. An OpenMRS server will export X-Forms, patient sets, and information about which X-Forms should be collected on which patients to a handheld computer. Software on the handheld will allow the user to look up patients, create new ones, and fill out X-forms. The completed X-Forms will be uploaded to the server and included in the main database. Possible summer projects include (1) working on a "transport layer" so that completed forms can be sent over the web, the phone line, or by manually carrying electronic media, (2) extending our systems ability to present data on the handheld.

Goal

the basic idea is that we want to have a variety of components that all connect to each other in different and varying ways; and the transport layer should make it easy for this communication to happen; requiring the components to say where they want to send data, but not how they want to send it.

For example, suppose we have one OpenMRS server that is always connected to the internet and a variety of PDAs and phones running our software for collecting data. Some of the PDAs are plugged into a desktop computer that is connected to the Internet each night, some of the phones send their data via SMS, others by GPRS. There are also PDAs that convey their data by “sneaker netâ€ÂÂ; they are plugged into a laptop, the data is downloaded to the laptop, and then the laptop is later connected to the internet and sends the data to the server.

Our objective in the above scenario is that the data collection code running on the PDAs and smart phones is the same in all casesâ€â€Âit just tells the transport layer to get the data to the main server, and doesn’t know or care if it gets there by SMS, GPRS, sneaker net etc.

The goal for this summer is to set up the API to make this all work, and to build as many different parts of the transport layer as we can, though we certainly won’t get them all.

Note that the transport layer is no one piece of software or code. It is a set of code running on a variety of computer and devices.

Use Cases

Initial thoughts:

  1. mobile device is able to communicate directly with the server

    1. use TL (Transport layer) to send data directly to server via HTTP

    2. on success update status of records on device and possibly delete sent records

  2. Using an intermediate device (PC / laptop) to communicate with the server

    1. use TL to send data to laptop

    2. : which transport method? Bluetooth / IR / Serial / devices own sync method

    3. use the desktop version of the TL to queue messages (including very simple GUI that shows allows user to view queued messages)

    4. desktop TL sends queued message to server via HTTP when it is connected (manually started by users)

    5. having successfully sent messages to server send success message to device on next sync

Requirements

We want to design and build very generic code that can send a variety of data and can work with "backend" servers other than OpenMRS. However, we can focus initially on meeting the needs of our OpenMRS. That is, our design will be very general, but our initial implementation will support the functionality we need most.

In particular, we want to be able to use existing OpenMRS functionality to specify a cohort (e.g., all children under 5 who attend a particular clinic) and then export information about that set of patients along with a set of x-forms to a handheld device. The handheld device will send back information on new patients, as well as completed x-forms.

Design

Unique address: We need to be able to sepcify a unique address for each component of the system-- each PDA, each server, etc. We want something like a URL. A URI (a Unique Resource Identifier-- see http://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Examples_of_absolute_URIs) might be the right concept.

Transmit request: When one component needs to send data to another, it will generate a transmit request until we come up with a better name). The transmit request will indicate:

  • the address where the data should go

  • the data itself (or a pointer to it)

  • what to do with the data, e.g., dump it in a directory, post it to a url, etc. (Simon, I think you mentioned some system that has such options already)

  • whether a return receipt is requested. the transport layer should offer the ability to get notification when the data has been transmitted successfully. this is especially important for sneaker net situations, in which the data should not be deleted from the source device until the data is confirmed to have been conveyed.

Question: Should we allow broadcast messages (eveybody gets the message), or other ways of sending messages without specifying who gets it. E.g., the server could send a message to all PDAs, or a PDA could send a message with lab results to any component that has expressed interest in getting lab results. (I'm not sure how all this work, though.)

Encryption: the messages need to be sent in a secure, encrypted fashion. Should the transport layer provide ways to encrypt or should the client devices just generate already encrypted data?

SMS server: (Neal is writing this, making best guess, but others probably know more). There should be a SMS server software that receives SMS messages and then sends them off, via the internet, to wherever their destination is. In this case, the transport layer code running on the phone would have to know the phone number of the general server. Or, conversely, the SMS server should be able to send information that it receives over the internet to phone applications. E.g., the OpenMRS server could want to send new x-forms to some of the smart phones: it would send a transmit message saying to send this data (the new x-forms) to the URI of a smart phones. The SMS server would have to know the phone number that was assocaited with the URI of the smart phone. http://www.kannel.org and http://www.gammu.org are popular options for SMS services.

Collaborating with Daniel Kayiwa: Daniel (kayiwadaniel@gmail.com) has developed an EpiHandy (http://www.epihandy.com/) application that connects to OpenMRS. It's great work and we must collaborate with him. In particular, we want to share and perhaps generalize the module he wrote for OpenMRS which imports and exports the data to EpiHandy. (This code perhaps is not transport layer code, but still is part of this project.) For example, I would guess this code requires that the PDA is plugged into the computer running OpenMRS. We would like to generalize this so that the OpenMRS code exports information to the transport layer, which could send it ot the PDA va direct connection, SMS, sneaker net, etc.

Transport layer code on PDA: as an example, there should be transport layer code written in Java that runs on the Palm OS. Let's call it Trans-PALM. We should design it such that the data-collection code we are writing can send transmit messages to Trans-PALM. There also needs to be a way for Trans-PALM to send data to the data-collection code. Once the Trans-PALM component running on the PDA gets data, it should periodically check poll to see if it is connected to the internet. If so, it should send the data to the URI indicated in the Transmit message. If the PDA gets connected to the laptop which is running Trans-SNEAKER_NET code then the Trans-PALM code should send a transmit message with the data to the Trans-SNEAKER_NET code running on the laptop.

Schedule

<span style="color:red">TODO</span>

</body></html>