Ed. Note: We’ve recently published a number of articles focusing on designing and deploying medical apps, starting with our Medical Apps 101 article that hits on some basics. Given that the core function of many medical apps is to deliver information, here we’ll look at one way to do that.

Many medical apps are primarily online or contact online content so that people can use them offline. Why do people do this? The mobile web is a cheaper way to dish out content because it avoids an app in favor of being a website, but usage graphs show that people prefer using apps. Why? My best guess is because apps are quicker and do not download as much data as a mobile website because of the HTML overhead.

To heap more upon more, the WiFi runs slower on mobile devices because of the limited physical space for an adapter. The advantages of offline use are obvious, especially with home visits and with sporadic WiFi in nooks and crannies of our hospitals and clinics.

There are a few ways to design medical apps for offline use. One way is to have all the information the app needs stored locally, using a local database. We’ve discussed that approach more. That, however, limits your ability to update or add information to the app. One way to get around that is to use a web server.

To distinguish terms: This article is describing a mobile app receiving data from a web server that is probably accessed or created by a web app.

  • Mobile app: A program on your mobile device that runs online or offline; it can download data from a web server and access it later. Often, this is done via an API (Application Programmer Interface) that facilitates the “conversation.”
  • Web app: A program that runs on a website; a mobile web app is basically just a web app accessed on a mobile device when it is online. In contrast to a mobile app, a mobile web app basically is like accessing the web app so it only works when online.

How do you download content from a website? Basically, by downloading the website. You pass input parameters via POST (hidden) or GET (public – no hidden passwords), and then the web server returns with some kind of content. It can be a website (HTML), plain text, a file, XML (kind of like HTML), or a JSON. “Whoa!,” you might ask, “What’s a JSON?” It stands for JavaScript Object Notation. It is a structured way of storing data that takes less space than an XML document. It looks like this:

{ “first” : { “name”:”Scott”, “hobby”:”medicine” } }

JSONs are a great, concise way of passing data to other entities. You might instead use XML to fill in a website or HTML to display a story with graphics. Your app can interpret these data structures only if it trusts that the website will deliver it in the same format every time. If you or your friend is writing the website, then you’re ok. If some other entity with whom you have no organizational relationship is, I’d worry a bit about using this approach.

Having a web server for medical apps allows you or someone else to customize your content each day, each week, or each month. This keeps people coming back, but it can also keep you or your developers busy. It also allows more control of content. Content is updated every time your app is accessed while it is online, instead of upon each app upgrade.

The other question that arises in app development is: What happens when the website goes down? It’s something to test for. Also, a similar question: What happens when the app goes offline? What happens when only half of the data is transmitted as low signal cuts it off? Can you detect when someone goes online? Can you discern between a WiFi signal and a cellular signal? I’ve had much more success with WiFi signals than cellular signals when sending large packets of data, especially in Africa. Do you want to send large files on cellular? All these design questions need to be answered by someone who knows the use cases.