Feature

What it takes to build a mobile health care app: Time and teamwork

Ezine

This article can also be found in the Premium Editorial Download "Modern Infrastructure: Understanding infrastructure and platform as a service."

Download it now to read this article plus other related content.

Health insurance companies aren’t exactly known for streamlined information access and delivery. Independence Blue Cross thought a mobile health care app might change that, helping it take a competitive stance and better support customers.

“Providing access to [customers’] health information anywhere, anytime, is what we call the ‘retailization of health care,’” said Greg Barnowsky, chief enterprise architect of Independence Blue Cross (IBC). Earlier this year, the insurance company launched the IBX App, an iOS and Android mobile health care app that offers its 3.8 million subscribers access to their medical information at any time, such as during a doctor’s visit. It’s the first mobile venture for the Philadelphia-based company, which plans to expand the app over time.

Modern Infrastructure recently spoke with Barnowsky, who led the charge on IBX’s app, to discuss the business and technical decisions that went into its creation.

How did the idea for the IBX mobile health care app come about?

We launched the Digital Engagement Center of Excellence [CoE] to help us create consumer “stickiness” to our brand. We think of digital engagement as applying mobile applications that address three pillars: those applications that differentiate us as a health care payer, those applications that address mobile health, and those applications that promote gamification or fun. All three of these pillars can be applied standalone or in combination with any mobile application. The underlying theme across all of this is the customer experience. We run our prospective application look and feel through customer experience trials before we finalize the details of the application.

What were some of your upfront technical considerations?

We had a mobile technology strategy before launching our Digital Engagement CoE. A key principle of our strategy was to ensure applications we built were portable and adhered and aligned to industry standards such as HTML5. We did not want to lock ourselves into a proprietary tool set because the vendor didn’t adhere to industry standards. We looked at public-domain mobile tools as well. We decided against these tools for a number of reasons, but the main reason was supportability and risk, including potential issues with scalability, security, testing costs, cross platform support, etc., over time.

 

Did you develop the app in-house or outsource it?

It was a combined effort of multiple departments. We decided early on that we would partner with Kony, an application tools development vendor. We used our own people to develop our first Kony-based mobile application. We wanted to build and own our intellectual property. We teamed closely with our marketing department, which told us what they wanted from an overall digital engagement strategy. Our internal corporate communications department created all of the themes and graphical design. Finally, we partnered with our informatics data warehouse teams for providing the back-end data. Our information services department developed and assembled the application, tested it and deployed it to the Android and Apple stores. In upcoming releases, we will provide support for Windows Phone, as well as iPad, Android and Windows tablets.

What kind of integration challenges did you face?

When you talk about any mobile application, the challenge is getting access to data. The first thing we discovered is that we had data-access gaps in regards to retrieving data in a format that was easy to use.

Having a Web-oriented architecture or APIs [application programming interfaces] to access back-end information is a plus. So, when building a mobile application, one starts to think in terms of APIs. That is, “How [can we] create APIs across these individual platforms to improve my delivery speed?”

So identification of the data access gaps and creation of flexible API wrappers that can be leveraged in the next mobile application becomes a key focus in application development. The result is a faster time to market for the next release with better customer experience due to improved application response times.

In addition to development tools, we had to consider mobile device management [MDM] tools. The MDM tools are complementary to mobile development tools and allow us to deploy applications internally via the MDM tool set, as well as ensure that if needed, we can do remote wiping of devices that we choose to control using MDM.

What else did you learn?

Select top talent and expect a lot from your teams. To mitigate risk, we evaluated, interviewed and selected team members who knew the company’s investment in mobility would require a similar investment in their own personal time [outside of regular work hours].

Once we picked the team, we also picked a seasoned professional to run the mobile development team who had the right mix of management, technology and leadership skills.

Both business and technology departments were asked to contribute funding by way of resources and time to the Digital Engagement CoE effort. We also chose to develop and deliver applications iteratively using the Agile development methodology -- a real must-have when developing mobile applications.

How do you measure your application usage?

We have a plethora of measurements to report on what’s being accessed, including how often the application is being accessed and what functions are being accessed and when. The issue is: What do you want to turn into actionable items that are meaningful to our business?

For example, based on utilization, we can determine what is and isn’t working to improve features. Based on business needs, we can improve individual member medication utilization so that the next version of the app would include new features such as reminders to your medicine cabinet or to exclude other features that are not being used.

What other areas are you planning to address?

Mobile health and gamification are two other areas we will continue to pursue over the current health care payer core mobile capabilities. You see [other possibilities for] mobile health in the medicine cabinet, and personal health records for example, with health and wellness tracking. Every app we build has some pieces of core intellectual payer support, mobile health or some level of gamification. We see both mobile health and gamification as key areas to continue to pursue. Consumers expect their apps to provide some fun and be a positive experience, driving them back to our applications.

Have you seen a return on investment yet?

The uptake in the release of the application since we delivered it into app stores in January has tripled. We don’t charge for this app, but we’ve seen the investment we’re going after is a really great consumer experience. We are very early in our investment but continue to seek out areas to improve customer convenience and satisfaction.


This was first published in June 2013

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: