Medical AppBy Scott J. Pearson. Scott develops medical research software currently with Project REDCap. He has written four medical apps for healthcare institutions and lives in Nashville, Tennessee.

Clinicians often reach out to iMedicalApps asking for tips on developing a medical app, often to address needs they encounter in their day to day practice. In the first part of an ongoing series looking at the “where to start” when it comes to health & medical apps, we covered some of the basics of developing on Android and iOS.

Next comes the actual developing and that can be an overwhelming task to get started. One place to start is to think through what you actually want the app to do. Its often helpful to start by categorizing the app’s functionality in your head in order to understand it better. With better categorization, you can set yourself up to design the app more efficiently & intuitively.

Apps will often fit into more than one category. That is, they make use of more than one function. This list is not meant to be exhaustive. In fact, I’d love to hear about apps that are in different categories.

To start, we’ll try to categorize the ways in which your medical app could store & access information.

Apps that access web servers

These are apps that store or download their data in a central web database. For example, electronic medical record apps act like this. Mobile web (mWeb) apps usually function this way, too. The good data is not stored on a local device, often for security reasons. Instead, it is stored at a central location that can be accessed by users of the app (and usually, other users via a web interface).

Because these are stored at a central location, security is easier – protect the server and the transmission (at all costs), and the data will be protected. Users only download one record or one other subset of the data. They then upload a modified or new instance of the data. A security breach on a device would only compromise a limited subset of the data.

Application Programming Interfaces (APIs), which allow for speedy data access to a web service, and HTTPS (secure internet using Secure Socket Layer or SSL), which allow for secure data transmission, are key concepts for these apps.

What about the so-called cloud

Cloud devices are basically just servers with a fancy name, often offered as a service. Typically, you can sign up for space on a shared server (cheaper) or set up a dedicated server (more expensive).

All medical apps that use Protected Health Information (PHI, as in an electronic medical records service) should use a HIPAA-compliant cloud service. That basically means that the service uses HTTPS (using SSL) for its transmission security as well as secure authentication logins, good physical security of the server, encrypted hard drives, and so on.

HIPAA-compliant cloud services are available at-cost online. TrueVault is a cloud service that specifically caters to healthcare. Some other cloud services like Amazon Web Services offer HIPAA compliant data storage and will sign business associate agreements.

If you don’t need HIPAA-compliance (in other words, no PHI, as in a medical literature service), then a normal cloud service would suffice. Or again, you can find IT folks to build a simple web database for you.

The value of the cloud is in how you use it. You can download information to store temporarily on your device’s hard drive (e.g., downloading a few medical records to do rounds on) or you can access them real-time on-demand (e.g., accessing a description of diagnosis and treatment of a rare disease when they occur in a patient). Real-time/on-demand access requires an online signal. Downloading records allows you to voyage offline (in a nook of a building where the WiFi signal is bad for example) after you’ve downloaded them.

Apps using local databases for offline use

Another way people format their data is to download the entire database into a local database. This is a better approach when people need offline access and when database security is less important. This is used only with native mobile apps and not with mWeb apps. Basically, the local database (or part of the local database) would be downloaded from a web database and installed when online. Then one can voyage offline and use the downloaded data. This is helpful when Internet signal is weak, whether in a clinician’s office or in Africa.

Epocrates’ prescription drug database is an excellent example of this category. Users download the entire database and update it at will. They need it for offline access because the nooks and crannies of a hospital or clinic may not always afford a good Internet signal. Yet information about drugs is always needed in every patient room.

There are many database options available on the market today. The W3C (World Wide Web Consortium) has attempted to define a standard programmers’ interface to local databases so that they can be easily switched without much effort. That way, if you need to switch databases, you don’t have to rewrite all of your code. You’d just need to dump your database data. SQLite has also carved out a respectable niche in the marketplace for its products that undertake relatively bug-free transactions. Still, other options are available.

Coming Soon

In our next article, we’ll look at other ways to categorize the functionality of health & medical apps.