Home » Guest articles » Currently Reading:

Readers Write: Guiding Principles for Designing a Useful Healthcare Mobile App

July 27, 2017 Guest articles 1 Comment

Guiding Principles for Designing a Useful Healthcare Mobile App
By Calvin Chock

image

Healthcare mobile apps can provide many benefits to busy physicians. Roughly 80 percent of healthcare providers use smartphones and medical apps, and more than 25 percent rely on mobile apps to provide patient care. In discussing mobile app usage, physicians strongly voice the need for quicker and easier access to patient data. If a mobile app is well designed, enables efficient access to patient data, and is easy to use, it can serve as a powerful companion to an EHR. By following some basic guidelines during the concept and development process, a robust, user-friendly mobile app can be built that meets a physician’s need for quick and easy data access.

The methodology outlined here is specifically targeted towards large applications with hundreds of features, complex workflows, and a vast number of users interacting in different ways. For these complex applications, the challenge is to design a solution that is useful but that will also fit into a much smaller form factor. Often, the trade-off involves realizing the full application cannot be fully converted into a mobile app, and instead making a version that is less complex, sequestering a subset of valuable features that are not meant to replace the full application but instead complement it.

Guidelines for Developing Critical Elements Help Ensure Success

There are several basic elements that require much thought and consideration when building a mobile app from a complicated application such as an EHR. This includes the overall design and layout, the types of user interfaces, and user experience.

Follow Design Principles and Build a Strong Foundation

First and foremost, realize that it is unlikely that all the information in the application can be crammed into a tiny screen. Distil the information down by breaking it into smaller subsets using a few logical steps:

Build an inventory of workflows.

Physicians, nurses, pharmacists, and other key staff all have different screen sets. Take an inventory of the workflows for various users to find out what they do during the day. Watch, observe, study, and write down each user’s role and their distinct user pattern.

Determine which items on the list are a good fit for a mobile app.

Look at the subset list closely and decide which workflows make sense to put in a mobile app and which will be challenging or cumbersome due to the limited size. Also, review each one and ask yourself, “Was the user able to fully complete a useful task?” If the answer is yes, keep it on the list. If not, then consider whether that specific workflow is a good candidate for a mobile app.

For example, during office visits, physicians document a wide range of a patient’s medical details. This function is probably not the best candidate for an app due to the large number of data entry fields and content. Phones are not great data entry vehicles, so trying to type a lot of information in can be cumbersome and frustrating. In contrast, physicians spend a tremendous amount of time reviewing patient data and acknowledging this review was done.

An example of a typical day would include a review of hundreds of lab results, dozens of notes, and several new orders. Lists of data that require limited data entry lends itself well to a mobile app. This tedious and time consuming work can now be done outside of the office, which now gives physicians the flexibility to do this work on the go.

Rank each item’s value.

Of those workflows that you determine will work well on a phone, rank the value of each subset based on potential user utilization of the app or other factors.

Once the subsets have been ranked, establish one theme for the app’s purpose. Too many different themes are confusing. For example, if the main goal is to empower the user to perform tedious work on the go, then define that as the primary goal and rank the features based on achieving that goal.

Utilize the Minimum Loveable Product (MLP) concept. In many applications, there is a choice between speed of delivery versus quality. If the mobile app is meant to be a compliment to the main application versus a full replacement, then designing an MLP will allow you do deliver a solution quickly and with high quality. Start the design work of just the most valuable workflows first, building one highly usable feature at a time. As users rally around that one feature, they get eager for the next one. You won’t sacrifice quality, and will still deliver new features at a good pace.

Lastly, use smart phone features to your advantage. Incorporating Location Based Services can save the user time in filling out location-related data entry fields, notifications can provide important alerts to users while the app is not in focus, and the camera phone can be used to take photos of documents or patients for immediate upload.

Create a Great User Experience with a Simple Layout and User Interfaces

Once the main theme is selected and an initial set of features has been identified, the last step is to take the time to think about how the app will look and how the user will interact with it. Going from a wide screen to a tiny one is challenging, so screen element choices are critical to maintaining a high level of usability. Only essential information can be shown, and creative ways must be utilized to display information. For instance, instead of showing the full directory of a file system, a hierarchy can be represented by descending shades of a color, saving time and real estate.

Be consistent with elements used throughout the app. If a field is accepted by clicking a button or swiping left to right, the same method should be used on every single page. Having a consistent user interface is key to the learnability of an application.

Employ user-friendly interface elements, such as big toggle switches, buttons, swipes, or gestures. Entering a lot of data using a phone is frustrating, so limiting free text entry when possible is important.

Make the app look simple and easy to use so practice staff can absorb the view quickly. Avoid too many user interfaces, text, and other details, or the screen will look cluttered and confusing.

Finally, verify that the user interface design will work on the majority of phones users have. While phones today are standardizing, it is still important to check. Time and expense can be saved by building the app to support only the top two or three phones potential users have.

Calvin Chock is VP of product management and engineering at McKesson Specialty Health in The Woodlands, Texas.


Contacts

Jenn, Mr. H, Lorre

More news: HIStalk, HIStalk Connect.

Get HIStalk Practice updates.
Contact us online.
Become a sponsor.

JennHIStalk

Comments 1
  • To think that this process began with a simple idea many years ago and has evolved into a truly helpful and dynamic platform is very impressive. Congratulations on the transition from the age of Lynx Data Management into the true advancements that are being made to change medical technology for the better.

Comments are closed.

Platinum Sponsors


  

  

  


  

Gold Sponsors


 

Subscribe to Updates




Search All HIStalk Sites



Recent Comments

  1. The article about Pediatric Associates in CA has a nugget with a potentially outsized impact: the implication that VFC vaccines…

  2. Re: Walmart Health: Just had a great dental visit this morning, which was preceded by helpful reminders from Epic, and…

  3. NextGen announcement on Rusty makes me wonder why he was asked to leave abruptly. Knowing him, I can think of…

  4. "New Haven, CT-based medical billing and patient communications startup Inbox Health..." What you're literally saying here is that the firm…

  5. RE: Josephine County Public Health department in Oregon administer COVID-19 vaccines to fellow stranded motorists. "Hey, you guys over there…

RSS Industry Events

  • An error has occurred, which probably means the feed is down. Try again later.