Nuts and Bolts

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:

Sana Workflow

Using the Sana app, health workers can run a procedure and collect patient data. Sana then uploads the information to OpenMRS for a doctor to review. After reviewing the case, doctors can notify the health worker of the diagnosis by sending results to the Sana app.

 

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.

Procedures

Procedures are at the very core of Sana. They can be thought of as "forms," but we call them Procedures because they can do far more than just take down information. Procedures are step-by-step workflows. In most scenarios, a procedure is a set of pages that each have questions or prompts. Sometimes a page will prompt a user to take a picture or record audio. Other pages in a procedure may ask the user to enter text, or check boxes. See the Demo to get a clearer idea of what a running Procedure looks like.

Procedures in Sana are defined in an extremely compact XML format. While it is easy to write a procedure in our procedure format, we plan on developing graphical tools to define procedures in the future. In the future, we also plan on integrating an X-Forms implementation standardized by OpenROSA. This will allow greater interoperability.

In addition to containing pages with question/response pairs, a Procedure has the ability to branch. Branching is defined in the Procedure XML, and allows for any arbitrary logic to be performed on other previously answered questions. This extremely powerful feature can be used to do everything from not asking certain questions if they are not relevant given prior responses, to allowing physicians to create complete decision tree diagnosis utilities. One such decision tree, the Integrated Management of Childhood Illness (IMCI) developed by the World Health Organization (WHO), is an example of something a Procedure using branching can accomplish.