The Sana Technology Overview

Sana is a standard-focused open-source system that supports audio, images, location-based data, text, and in the future, video. Sana's front-end for data and media capture is accessible through a fully programmable workflow interface. The back-end provides an intuitive user interface for management of medical media. Sana was built to be integrated with OpenMRS and other commonly used medical record systems for portability. The system infrastructure and design allows for modularity and interoperation.

Some of the other key features provided include:

 

Create Procedures with Sana

Doctors also have the ability to build unique procedures for nurses and organizations to use. These procedures allow for a high-degree of customization. They also allow branching (to show different questions and/or results based on previous selections). This allows physicians to make their own decision tree diagnosis utilities that run on the phone and do not need remote doctor review.

Sana Infrastructure

The complete Sana system consists of at least one (in most instances several) phones and a web-connected server. The server runs the medical records system of choice, such as OpenMRS, and the Sana Dispatch Server program.

The Sana Dispatch Server is a program running on the server that is responsible for communication to and from phones registered in the system. It takes care of receiving data via the lower-level synchronization and packetization that the Sana-enabled phones perform. In addition to this, the Sana Dispatch Server has plug-ins that allow it to interface with medical records systems. Sana is currently fully-compatible with OpenMRS, using our OpenMRS plug-in for the Sana Dispatch Server.

In addition to the Sana Dispatch Server program, the medical records system also runs on the server (although this can reside on a separate machine if the installer would like). Sana uses a custom-patched version of OpenMRS. This patch extends OpenMRS to have a queue of pending diagnoses in addition to allowing data such as images to be tagged to a patient record.

Sana is a turnkey solution that can be added to existing records systems deployments. If an organization is currently using OpenMRS, all that needs to be done is to 1) Install the Sana Dispatch Program onto a server, 2) Point the Sana Dispatch Program to OpenMRS, and 3) Install the Sana Module in OpenMRS.

Reliable Operation On Unreliable Networks

A key challenge facing remote diagnostic platforms that utilize cellular networks in developing nations is the issue of connectivity. In order for a system to be useful, it must be robust. Sana uses several strategies to ensure reliable, low-cost data transfers.

  1. Synchronization. When a Procedure tagged for upload is completed for a particular patient, the question/response pairs as well as other media (pictures, sounds, etc.) are stored in a local (on-phone) database. At this point the Procedure (or another one) can be rerun for the next patient. A background service is constantly listening for cellular service. As soon as service is available, all of the filled out forms (Procedures) are uploaded to the server.
  2. Packetization. Some acquired data is extremely large. Video and high-resolution images, for example, take time to upload over GPRS. Oftentimes a half-completed transfer will be interrupted due to poor service. Even though a significant amount of data was transferred successfully, the mid-upload failure results in a complete drop of the data. Using packetization, Sana uploads large files in chunks so that very little bandwidth is wasted in the case of a lost connection.
  3. Multimodal transfers. Sana has the ability to transfer data using a number of interfaces, including GPRS, WiFi, SMS, and USB tether. Different interfaces are used for different things. For example, images and sounds must be transferred on either GPRS, WiFi, or USB tether, but the text of a filled out Procedure can be sent back via SMS. The diagnosis/response from a physician that is sent back to the phone is sent via SMS. This is done for several reasons, such as the fact that if the phone is outside of the coverage area, the cellular network operator will take it upon itself to deliver the SMS notification as soon as the phone reenters service area.