301 Medical Applications: Content Delivery via Web Server

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

Many medical apps are primarily online or contact online content so people can use them offline. Why do people do this? The mobile web is a cheaper way to deliver content because it eschews an app in favor of a website, but usage charts show that people prefer using apps. Why? My best guess is that the apps are faster and don’t download as much data as a mobile website due to the HTML overhead.

To do more, WiFi runs slower on mobile devices due to limited physical space for an adapter. The advantages of offline use are obvious, especially with house calls and with sporadic Wi-Fi in the nooks and crannies of our hospitals and clinics.

There are several ways to design medical apps for offline use. One way is to store all the information the application needs locally, using a local database. We have discussed this approach more. However, this limits your ability to update or add information to the app. One way around this problem is to use a web server.

To distinguish the terms: this article describes a mobile application receiving data from a web server which is probably accessed or created by a web application.

  • Mobile Application: 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) which facilitates the “conversation”.
  • Web application: a program that runs on a website; a mobile web application is basically a web application that can be accessed on a mobile device when online. Unlike a mobile app, a mobile web app is basically accessing the web app, so it only works when it’s online.

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

{ “firstname”: { “lastname”:”Scott”, “hobby”:”medicine” } }

JSONs are a great, concise way to pass data to other entities. Instead, you can use XML to populate a website or HTML to display a story with graphics. Your application can only interpret these data structures if it is confident that the website will provide them in the same format every time. If you or your friend is writing the website, then it’s fine. If another entity that you have no organizational relationship with is, I would be a little concerned about using this approach.

Having a web server for medical applications allows you or someone else to customize your content daily, weekly or monthly. It keeps people coming back, but it can also keep you or your developers busy. This also allows for better content control. Content is updated each time your app is accessed while online, not each time the app is upgraded.

The other question that arises in app development is: what happens when the website goes down? It’s something to try. Also, a similar question: what happens when the application disconnects? What happens when only half of the data is transmitted while the weak signal cuts it off? Can you detect when someone logs in? Can you tell the difference between a Wi-Fi signal and a cellular signal? I’ve had much more success with WiFi signals than cellular signals when sending large data packets, especially in Africa. Do you want to send large files over cell? All of these design questions need to be answered by someone who knows the use cases.