Archive | Technical RSS for this section

Creating An App-Panic

Screen Shot 2013-06-05 at 3.24.09 PM

iMedicalApps.com published an article detailing Apple’s ‘new’ development policy which will reject any app that includes dosing information for a medicine. Normally I wouldn’t comment on an article from another site in this much depth, but given the way headlines suddenly become ‘insights’ in this business, I thought it would be helpful to clarify a few things.

The article starts with an ominous headline “Apple is now rejecting new medical apps that include drug dosages.” Apple is not doing this across the board. One or two devs got rejected. Which by the way, happens all the time, for all kinds of reasons.  The article goes on from there, “It appears that a number of developers have struggled recently to get medical applications into the App Store.” It doesn’t say how many developers or how wide spread the problem is. And, without any kind of context as to what the app was, or any insight into it’s functionality, it’s impossible to draw any conclusion as to why it was rejected. Given the amount of apps currently in the app store that reference dosing information (mostly by manufacturers) I seriously doubt this is a widespread issue.

A simple reading of the actual rejection sent by Apple illustrates where the developer(s?) went wrong.

“We found that the Seller and/or Artist names associated with your app do not reflect the name of the manufacturer of the medicine referenced in your app or its metadata, as required by the iOS Developer Program License Agreement.

Section 1.2: 

“You” and “Your” means and refers to the person(s) or legal entity (whether the company, organization, educational institution, or governmental agency, instrumentality, or department) using the Apple Software or otherwise exercising rights under this Agreement. For the sake of clarity, You may authorize contractors to develop Applications on Your behalf, but any such Applications must be submitted under Your developer account.

We can only accept medical dosage information submitted by the medicine’s manufacturer.

If you have published these apps on behalf of a client, it would be appropriate for your client to enroll in the iOS Developer Program, then add you to their development team so you can develop an app for them to submit under their developer account.”

I actually see this as a good thing for users. First, the developer in the article clearly didn’t follow the metadata practices of Apple’s guidelines, which is a no-no. Apple has been very consistent on making sure apps are what they say they are and aren’t playing games with metadata to boost rankings. Already I’m suspicious of the developer(s?), since they seem to be unwilling to follow or correct this issue now that Apple has pointed out it’s a problem. Second, if you are publishing dosing information and aren’t doing it on behalf of the manufacturer, you may be publishing the wrong information. Since pharma has so many checks and balances on it’s content, Apple can be assured that anything with a manufacturer’s name on it would have the content verified for accuracy.

As part of gathering the info for the Mobile App Wiki, I spent quite a bit of time in the Android store. Let me tell you, it’s hard to know who’s published what. The requirements are very flimsy for publishing an Android app, and I couldn’t tell if an app was legit or not (see the Bob in IT example).  To be clear, Apple is not asking for the content to be verified, but does have some controls to ensure the veracity of content. Given the importance Apple has placed on medical content and audiences, this seems like a logical restriction to ensure quality for it’s users. So if you are developing an app for a pharma client, or doing it in house, you should be fine.

Comments Deactivated Temporarily

IT Unicorn Says Our System Is Hosed

We seem to still be having database issues. I’ve turned off the comment plug in to see if that fixes the issue. Stay tuned.

What To Watch For In 2013

“The future is already here, it’s just not evenly distributed.” – William Gibson

2013 is already shaping up to be a groundbreaking year for health technology. In just the past few weeks we’ve seen stunning technology announced, including LCD contact lenses, iPhone enabled EKG monitors, and brain controlled artificial limbs. I’m pretty sure we’re just at the beginning of a tidal wave of advances that push the human experience forward dramatically.

What follows are a few things I think will reshape our expectations and experiences in healthcare, some for better, some for worse.

The Zettabyte

For a sense of scale, the size of the data we’re talking about is as follows:

1,000 Megabytes = 1 Gigabyte. 1,000 Gigabytes = 1 Terabyte. 1,000 Terabytes = 1 Petabyte. 1,000 Petabytes = 1 Exabyte. 1,000 Exabytes = 1 Zettabyte. By 2015, global IP traffic is expected to pass 1.3 Zettabytes per year, with 39-45% of all that traffic happening wirelessly. 51% of that traffic will be video based, with HD video compromising 79% of that. For all of the talk about big data and how healthcare marketers can use it, the fact remains the industry is woefully under-resourced to create or leverage the kind of sophisticated algorithms needed to analyze and predict trends in order to stay relevant with customers. And, given the scale of the data involved, the problem is only going to get worse. Read More…

Is Passbook the Future of Pharma CRM?

No offense to Android or Windows 8, but when it comes to healthcare, it’s still an iOS world. As the FDA announced today that it has approved the AliveCor iPhone based EKG monitor (http://ht.ly/fM1n2), I’m left to wonder about another recently announced technology, Apple’s Passbook. Is this the future of Consumer CRM for pharma?

For those of you that are unfamiliar, Passbook is Apple’s built in coupon and payment card organizer. Passbook enabled apps, like Starbucks and Fandango, allow purchases to be added to Passbook for later use. No printing tickets or getting cards in the mail any more. Have a $25.00 Starbucks card? Scan it into the app and it appears in Passbook. Just bought tickets online to Skyfall? Open Passbook and there they are. In practical terms, this solves an enormous problem for users, namely organization and integration into your mobile life. And that integration isn’t just about keeping everything in one place. As a system level app, Passbook interoperates with most of the other functions on the device. Let’s stick with the Fandango app for a second. Let’s say you bought tickets to a Friday night show. Not only are the tickets waiting in Passbook for scanning at the theater, but you can automatically add a reminder to your calendar and text friends the show times. With location based services activated, users can receive proximity based notifications about traffic conditions on the way to the show or be notified of offers as you walk into the theater. Given it’s relative infancy, it’s safe expect the Passbook’s feature set to get more sophisticated and more valuable for users and brands alike.

 

The holy grail for any digital marketing program is the often-touted, rarely-validated ROI calculation. I’ve seen ROI for programs touted all over the industry, but the dirty little secret is this: if you can’t tie any program back to a validated sale, you can’t truly calculate ROI. Brands correlate ROI all the time, but correlation isn’t a true indicator of actual sales. This is why redemption and coupon cards are so important, as they give marketers direct numbers that validate the performance of a program. Brands can talk engagement until they are blue in the face, but if digital is ever to be taken seriously as a business driver, ROI calculations must be accurate and proven.

 

It’s estimated that almost 50% Rx brands will have some form of coupon or discount card program by 2021. And why not? Even by modest calculations coupon programs typically generate a 4:1 return. So, why don’t all brands have discount card programs? The answer to that is a simple one. Discount card programs are insanely expensive.