With the recent hurricane affecting the lives of numerous people on the East Coast, we are reminded of the plethora of apps that position themselves as being useful during these disaster type scenarios. You might remember the Pocket First Aid app we reviewed last year — the one that helped save a mans life in Haiti.

While different situations are going to call for different actions,  the App Store and Android Market are full of apps that can be used in an emergency situation.

The question then becomes how to sift through all the various apps and decide which ones are worth using and which ones should be tossed away.  TechNewsDaily provided a solid list of some apps that might be useful.  

In an emergency situation, first-aid treatment is vital for those who need it and numerous apps are avaible to for this:

“Popular first aid apps for Android users include First Aid (free), Pocket First Aid and CPR ($2.99) and Emergency First Aid Guide ($0.99). For iPhone and iPad users, try American Medical Aid ($2.99), Pocket First Aid and CPR ($3.99) and First Aid Guide ($1.99).”

Additionally, a good plan is just as critical to keeping yourself safe and healthy as being able to treat wounds.

“For Android users, check out Disaster Readiness ($0.99), Disaster Survival Guide ($1.36), Survival Preparedness ($0.99), Emergency Kit Organizer (free) and Are You Ready? (free), an app from the Federal Emergency Management Agency. iPhone and iPad users should try Emergency Supply List ($0.99), Disaster Survival ($0.99) and Disaster Alert (free).”

Disasters are unforseen events that have a dramatic impact on people’s lives. While nobody wants to experience them, there is some, albeit small, comfort in knowing that there are apps availabe to assist during these events. There is even an app to convert text into morse code which may come in handy–you never know. We will do our own review of useful apps in disaster scenarios in the future.

Source:  TechNews Daily

[Ed. This is the third of a three part series examining the past & present of FDA regulation of mHealth]

The debate over the adoption of electronic health records and health IT systems by physicians has largely focused on the concept of “Meaningful Use”. It was this term chosen by the Dept of Health and Human Services Office of the National Coordinator (ONC), the sub-agency charged with distributing subsidies awarded in the Obama stimulus to physicians who adopt electronic medical records, as its baseline measure when providing guidance to physicians on how they would ultimately determine eligibility for federal aid.

The FDA released new guidelines for comment this week on how they will regulate mobile applications, or more specifically, how they will determine when a mobile application is actually a mobile medical device. Taking a cue from the ONC, the agency wrote a document that could be summarized in two simple words, “Intended Use”

“When the intended use of a mobile app is the diagnosis of disease or other conditions, or the cure, mitigation, treatment, or prevention of disease, or is intended to affect the structure or any function of the body of man, the mobile app is a device”.

As in all matters bureaucratic, the subtleties of language, even one or two words among tens of thousands, can have significant ramifications for many stakeholders.

The FDA did a great job of providing a clear taxonomy of the mobile health ecosystem. They offer significant clarity for the different elements and obligations of various stakeholders involved in the design, development and distribution of “mobile medical apps”.

The document makes very clear where, or rather with whom, ultimate responsibility lies for a particular application and its compliance with regulatory oversight. The “author”, or the individual/entity that conceived of AND designed the specifications of the app, bears the final responsibility of applying for and receiving regulatory approval. The “developer”.

“Intended Use refers to the objective intent of the persons legally responsible for the labeling of devices. The intent is determined by such person’s expressions or may be shown by the circumstances surrounding the distribution of the article. This objective intent may, for example, be shown by labeling claims, advertising matter, or oral or written statements by such persons or their representatives”.

One very important distinction made by the FDA was on the matter of how to determine the “manufacturer” of a mobile medical app. This is important because it is the manufacturer who is solely accountable to the regulatory group, though the actual “developer” of the device may be a contracted third-party. A manufacturer is the person or group that conceives of and designs the core requirements and functionality of the device, or the “author”.

“…manufacturers of a mobile medical app would include persons or entities who are the creators of the original idea (initial specifications) for a mobile medical app, unless another entity assumes all responsibility for manufacturing and distributing the mobile medical app, in which case that other entity would be the manufacturer. Software “developers” of a mobile medical app that are only responsible for performing design and development activities to transform the author’s specifications into a mobile medical app would not constitute manufacturers, and instead the author would be considered the manufacturer”.

The report allows handset developers, “If it is possible to run mobile medical apps on BrandNamePhone but BrandNamePhone is not marketed by BrandNameCompany with a medical device intended use, the BrandNameCompany would not be a medical device manufacturer.”

App Stores are also given a pass for now, “É-mobile platforms” are defined as commercial off-the-shelf (COTS) computing platforms, with or without wireless connectivity, that are handheld in nature, include mobile computers such as the iPhone¨, BlackBerry¨ phones, Android¨ phones, tablet computers, or other computers that are typically used as smart phones or personal digital assistants (PDAs)”.

A “mobile medical app” is distinguished as a mobile app that meets the definition of “device” in section 201(h) of the FD&C Act and either: (1) Is used as an accessory to a regulated medical device; (2) transforms a mobile platform into a regulated medical device.

There is a clear distinction made that might (but probably won’t) have implications for developers of “closed systems”, such as Apple’s iOS or HP’s WebOS platforms. It would seem under these guidelines Apple and HP could never market their consumer electronics products, such as the iPad or new HP TouchPad directly to providers or health systems without evoking uncertainty as to the “intended use” of the device. Its doubtful the FDA would prevent the iPad 3 from being marketed in the US until it was approved, but a closed system raises more questions than the open system business model of Google and Android.

Apple’s quarterly earnings show the iPad and iPhone have grown to 68% of the company’s revenues. Mobile devices are the future of Apple, and as a closed system the company will need to carefully market its products, or simply welcome FDA approval and aggressively sell their iPads to health systems with iCloud for the enterprise supporting every bed and every health professional on premises.

[Ed. The article below is simultaneously published today by iMedicalApps.com and the Journal of Surgical Radiology (http://www.SurgRad.com), a widely read, peer reviewed journal]

In just a few short years, smartphones with advanced operating systems have sparked a bright new era of mobile medical applications. Although the Blackberry smartphone had been the device of choice for physicians for most of the previous decade, the arrival of Apple’s iPhone in 2007 revolutionized mobile phones. The highly anticipated release of the iPhone software development kit (SDK) a year later immediately launched a wave of mobile software development and, almost immediately, interest in medical software.

As if to underscore this interest, a physician was on stage with Apple CEO Steve Jobs in 2009 demonstrating an early version of Air-Strip, an iPhone application that provided real-time monitoring of fetal heart rate tracings. This was nothing less than a thrilling peak at a possible future where physicians remained connected to their patients’ data, freed from the physical constraints of having to be at the hospital or office.

In the last two and half years, a new world of mobile medical applications has flourished. Currently, there are over 6,000 apps classified as health related across the various app stores, although only 30% are directed to clinicians. Still, with the numbers of physicians using smartphones climbing from an already high 72% to a projected 82% by 2012, the market for clinician oriented apps will only continue to increase.

Here at iMedicalApps we review and comment on mobile medical technology and apps from the perspective of physicians. In this column, we are going to explore the world of mobile apps and ask where medical professionals will be going to look for the medical apps of the future.

App Stores

After the iPhone in 2007, the next major revolution in mobile computing was the iTunes App Store, introduced a year later along with the iPhone SDK.
Suddenly, users could directly browse a huge array of applications directly on their phones and, with a single click, purchase and install software (“apps”) directly to the device. Along the way, the problems of software distribution – all publishers instantly had global reach – and security from viruses and rogue applications were mostly eliminated. By hiding the complexity of application installation from the user, Apple unleashed a commercial juggernaut and within 9 months, one billion apps were downloaded from the iTunes App Store.

The power of simplicity was not lost on other platforms and within a few months, Google launched the Android Market for its then nascent platform. Since then, of course, sales of Android powered phones have skyrocketed and, in December 2010, a dedicated medical section of the Android marketplace was inaugurated. Each of the other major platforms now has its own market, including Nokia (Ovi store), RIM (Blackberry App World), Palm (WebOS App store) & Microsoft (Windows Phone 7 Marketplace).

Web 2.0

In the same period as the smartphone revolution, rapid advancement in web browsers and software technologies has occurred that could conceivably displace the central role of “apps” in the future.

In the first decade after the birth of the world wide web, usually marked by the launch of the first Mosaic “browser” in 1994, the web was essentially a publishing medium. A single entity could broadcast widely using the world wide web but the audience was limited simply to absorbing the content or, at most, purchasing online.

The first “Web 2.0″ conference in 2004, organized by O’Reilly Media, popularized this moniker. Although there is no canonical definition, Web 2.0 pertains to the web becoming a two way medium. The definition often given is “the internet as platform” or “the participatory Web”. By collecting data from users, brand new types of services and companies could be created. One example is Wikipedia, a user-generated encyclopedia. Another is Reddit, a highly successful news site founded in 2005 that relies on its thousands of readers to vote items of interest up or down. By “crowdsourcing” the editorial process, massive amounts of data could be sifted and the publishing process could profitably be automated.  In effect, the rise of a social, collaborative web meant that news, shopping, even software development became group efforts.

The evolution of Web 2.0 was in part facilitated by browser based technologies that allowed for more sophisticated interactions with the user. These were lumped into the memorable but loosely defined acronym “Ajax” (Asynchronous JavaScript and XML). Ajax allows for small portions of a web page to be modified in response to user input, instead of having to reload the entire page. This allows for more fluid interactivity. The original poster-child for Ajax is Google Maps, which can zoom, pan and display map overlays in a way that is still inspiring years after Google acquired and relaunched it in 2005.

Web Apps

While most people do not think of it as such, a website such as Google Maps is an application, only that it resides on a remote server and interacts with the user (executes) within the confines of a web browser. In contrast, an app such as Epocrates or Microsoft Excel resides within the device and directly manipulates the computer, via the intermediary of the operating system.

In fact, until recently all software applications were written exclusively to work within the environment presented by a computer operating system. For much of the last three decades, this usually meant the Microsoft Windows operating system. Until fairly recently, the kind of applications that worked within web browsers were just too simplistic to satisfy the wide variety of users’ needs.

However, the powerful browser based technologies mentioned above are starting to blur this distinction. Certainly, applications can be delivered through the browser much more cheaply and are far easier to distribute and maintain. Google, by giving away its barebones Chrome OS operating system is betting that web applications can deliver enough rich functionality to displace the role of device-specific operating systems such as Microsoft Windows and Macintosh OS X.

The end of Apps ?

While the demise of “native” app development and operating systems in favor of web applications has been regularly predicted for more than a decade, will the benefits of economical app distribution and maintenance finally be enough to overcome the shortcomings of browser based apps ?

The short and safe answer is no. The first reason was inimitably articulated by David Pogue in “The Lessons of 10 Years of Talking Tech” in the New York Times. As he put it:

TV was supposed to kill radio. The DVD was supposed to kill the Cineplex. Instant coffee was supposed to replace fresh-brewed.But here’s the thing: it never happens. You want to know what the future holds? O.K., here you go: there will be both iPhones and Android phones. There will be both satellite radio and AM/FM. There will be both printed books and e-books. Things don’t replace things; they just add on.

More arguments for the continued need for “native” medical apps were proposed by Albert Santalo, CEO of CareCloud – an EHR company, in his guest post on iMedicalApps. His arguments, paraphrased, were:

1. Offline Usability

Native apps can run in offline mode and then synchronize with the server when a signal becomes available. Dropped connections are a nuisance for the average consumer, but for health workers they can be “devastating”.

2. Full Functionality

Web apps cannot access device features and hardware such multi-tasking, Bluetooth, address books, the camera and microphone.

3. User Experience

Web apps lack a dedicated, device-optimized user interface and thus cannot be precisely catered to fit a particular device’s form factor, input methods and screen size. Thus, web apps typically deliver an “abridged” user interface.

Medical Apps Distribution

If “native” medical apps are going to be with us for the foreseeable future, how will physicians continue to find and deploy them ?

A recently published broad survey of the mobile industry by Research2Guidance predicts that the dominant mode of application distribution in the future will be from doctors, hospitals and other care providers, rather than via the current familiar App stores.

While App stores have been a revolution for consumers, this distribution mode is not adequate for health information technology, where isolated data stores are dead-ends. In particular, the ability to reference clinical evidence, prescribe medications, or communicate with other providers is of greatly diminished value unless all parties have simultaneous access to the same patient record.

The current generation of medical apps still emphasizes information retrieval – think Epocrates & Medscape. Although AirStrip Ob and Critical Care stand as a shining example of mobile devices acting as extensions of the doctors’ hands and eyes, the main mode of usage for smartphones remains information retrieval.

Therefore, it makes sense that hospitals and other provider networks will be the ones to develop and distribute intrinsically networked apps for their providers in the future. These future apps will be powerful extensions of physicians’ clinical tools, seamlessly extending their reach from hospitals and offices onto their mobile devices.

The Future of Medical Apps

The future for medical apps is bright. There will coexist both native and web based apps. App stores will continue to thrive and the market for consumer directed health apps will thrive. However, apps directed at physicians will become increasingly better connected to patients’ clinical records and will more likely be distributed by hospitals and other provider institutions.

Finally, a couple of other potential developments to look out for in the future. First is Practice Fusion, a free web-based EHR, which is seeing rapid adoption. If the enthusiastic developer response to the first, limited deployment of its API at the Health 2.0 meeting in July is any indication, there may yet be a flourishing App store within this EHR in the future. Also, look out for the Accelerator Apps Network , a sort of “meta-platform” for health care applications which aims to provide an environment where multiple health care apps can communicate with each other. From their description:

The Health 2.0 Accelerator Apps Network is a growing ecosystem of web applications and services that work together – collaborating 2, 3, 4 and more at a time, serving as platforms for other apps and as interoperable bridges between apps – all to connect and support patients, caregivers and providers

In future columns, we will investigate these items in further detail.

On Tuesday, Apple announced new App Store rules that aim to redirect a larger share of revenues from app subscriptions and content sales to Cupertino. Widely expected by developers and consumers for some time now, these rules will have broad implications as they will apply all forms of digital media accessed through iPhone and iPad apps. The rules essentially mandate that apps that sell content, either as one-time purchases or subscriptions, include an in-app purchase option – with 30% of revenues going to Apple.

As Steve Jobs puts it,

“Our philosophy is simple—when Apple brings a new subscriber to the app, Apple earns a 30 percent share; when the publisher brings an existing or new subscriber to the app, the publisher keeps 100 percent and Apple earns nothing,” said Steve Jobs, Apple’s CEO.

NewsCorp, which recently released “The Daily”, is an example of the standard that Apple is seeking to apply to all digital media developers. While most press around this announcement focuses on the impact on large companies like Amazon, the Washington Post company, and so on, these rule changes will also have big impacts on the fledgling industry growing around mobile medical apps and should serve as a warning to the health IT industry as a whole.

Perhaps the most widely talked about developer that will be impacted is Amazon. As described at Computerworld, Amazon will have to remove its link to its Kindle store from the app. Instead, it will only be allowed to sell e-books via its the Kindle App through Apple’s In-App purchase system, representing a loss of 30% of revenue for Amazon, or online through the Kindle Store. Further, Apple has mandated that the price set for the In-App purchase must be the same as that in other venues like the Kindle Store.

This obviously has clear implications for Epocrates, Lexi, Up-to-Date, MDConsult, and other developers who provide (or will presumably soon provide) medical information at the point of care for a fee. Additionally, Elsevier, Kaplan, and other publishers of medical reference texts will be affected. For those that don’t already utilize in-app purchases and revenue sharing with Apple, it means a hit to their bottom line. Also nestled within Apple’s announcement is another caveat,

Customers purchasing a subscription through the App Store will be given the option of providing the publisher with their name, email address and zip code when they subscribe.

When it comes to medical apps, a big part of their value is access to physicians and other healthcare providers – a high value market. In the sphere of medical apps, this means that Apple will now have access to a very valuable demographic that had previously been hidden among the millions that use the iPhone and iPad. Furthermore, the statement suggests that this information may be denied to developers. As we discussed when we covered the Epocrates IPO, access to this demographic is a key part of the value proposition of app developers – loss of even a fraction of that market could be very detrimental.

What will be more interesting is what happens as electronic health record systems go mobile. Between Epic Systems and Eclipsys alone, 2009 brought in over a billion dollars in revenue. As an increasing fraction of a clinician’s time is spent on mobile platforms, apps like Haiku will begin to gain a lot more value.

While these systems involve far more complicated licensing agreements than say a subscription to a Lexi product, given the amount of money involved here, its tough to imagine that Apple will not eventually seek to claim a piece of the pie. And if that piece is again nearly a third of whatever value it assigns to the mobile platforms of these systems, it could mean a hit to these rather hefty bottom-lines.

Practice Fusion is a free, web-based electronic health record that has seen a rapid rate of adoption over the last two years and, as we reported recently, is currently the largest commercial EHR installation after Kaiser and the Veterans Affairs.

But like all “overnight successes”, the rise of Practice Fusion is not accidental and not without laborious engineering. In fact, important design decisions at its inception have been instrumental in its growth, allowing for rapid iteration of features without incurring heavy development and deployment costs. Matthew Douglass, currently the VP of Product Development, has been through almost the entire history of the company. He was the second person to join the company and continues to lead the engineering process.

In this interview we learn some of the fascinating story of Practice Fusion’s rise, its plans to expand its API (application programming interface) and launch an app store.

We envision that doctors could prescribe an app much like they prescribe a medicine now. – Matthew Douglass

How did you get involved in Practice Fusion?

At the time I was approached by [now CEO] Ryan Howard in 2007, I was working in energy and finance. But, even then, I wanted to do something besides, as I said, “turning millionaires into billionaires”. Ryan had started in 2005 and had just bought a one site EHR that was developed by a family practitioner. I was charged with making it multi-tenant and web-based. Multi-tenant means having all the data stored in a single database, instead of separate for each user. Back then, we worked in coffee shops, communicating electronically. I worked hard for six weeks, including one non-stop 72 hour stretch just before we launched, which has become urban legend around here. Three months later, we went on to the web. That was the beginning of 2008.

How did Practice Fusion initially grow?

We initially charged $50 per month per doctor. Then we decreased it to just $50 for support and training. By the time we went to the web, we were free. This led to rapid growth. We started rapidly signing up physicians. Our very first web user, by chance, was also in San Francisco. With the passage of HITECH act in Feb 2009 [which provided financial incentives for physicians adopting EHRs], we started to get interest from investors. The first were a large Bay Area angel group called the Band of Angels. Later Mark Benioff [CEO of Salesforce] invested. We recently completed a series A round from a venture capital firm [7.2m, 11/24/09, Morgenthaler Ventures]. We don’t do direct sales, meaning door-to-door. Most of our customers find us online. The majority of our users are in California, New York, Florida and Texas.

How did you settle on free as the price?

We found that primary care practices were quite price sensitive, as their real income had stagnated for more than 20 years. We decreased our price until we got to free. We are committed to keeping it free. We feel there are enough other participants in the health care IT ecosystem who can subsidize the EHR, such as device makers, labs, billers, pharmacies, etc. Doctors should not have to pay.

How about advertising revenue?

Ads are a large part of our revenue.

Talk about your implementation

The original EHR was written by a physician, Robert Rowley, who is now the Chief Medical Officer. Our multi-tenant database, where all patients around the country are stored in a single database, has allowed us to scale smoothly by allowing us to release new versions of the software while keeping everybody on the same version. Our architecture also allowed us to easily add a patient portal [Patient Fusion]. Initially we were adding 5-6/day users a week, now we are adding as much as 350 users or about 40-50 practices per day. We have surpassed 60,000 registered users. Just two months ago we were adding 250/users a day, so the rate of growth is accelerating quickly, and we feel that with HITECH incentives in 2011, this may push it higher. We are planning for even greater acceleration.

How many engineers do you have at Practice Fusion ?

We have a total of 53 employees, 17 are engineers and we are hiring 6 more, thanks to the stimulus.

What are your continuing challenges?

A lot of what we do is integration, tying together other systems and suppliers. This does not always show up as an explicit feature. For example, seeing a Labcorp result requires getting a file, parsing it, displaying and storing it. And every single lab is different. e-Prescription integration, such as with Surescripts, and determining formulary eligibility can be very complicated behind the scenes. But because our system is multi-tenant and web-based, we just have to do it one time and all our customers get the update simultaneously.

Tell us about the Practice Fusion Developer Challenge

Last spring, Matthew Holt and Indu [Subaiya, of the Health 2.0 Conference] approached us about posting a Developer Challenge at the Health 2.0 meeting in July. We decided within a week, and launched within 3 weeks. [The Health 2.0 Developer Challenge is supported by HHS but run by Health 2.0]

For our Developer Challenge, we discussed it and decided to go with a limited API emphasizing ways to get real time data into Practice Fusion. We felt that getting the physician real-time measurements [e.g. blood pressure, etc] could be really valuable – instead of requiring the physician or practice to enter all the clinical information. We were very surprised when 35 developers submitted projects, more than any other challenge.

Of the 35 submissions, 25 had to do with medical devices and data transfer. This tells us that there is a market for this connectivity. The winner [Team Critical Systems] was a great example of hacking – a simple bathroom scale was hacked to read the LCD display and the result is transferred directly into Practice Fusion.

Any surprises among the submissions ?

I was surprised that 10 of the submissions did not even submit their own data, but rather co-opted the API to present unstructured data, for example turning a patient intake form into a rudimentary data entry API, e.g. patient submitted “mood” data. This [type of observation] will drive our API strategy. Other types of structured data we had not anticipated such as reporting diagnoses or clinical workflow.

How did you decide on your Challenge ?

There are a lot of medical device manufacturers which already transfer measurements to their own servers. However, this data is isolated. It does not take too much work for them to use an API to transfer this data to patients’ records and allow clinical decisions to be made from this information. This is what could be revolutionary. We already have a dozen companies lined up to work on our API

What future directions are you anticipating for your API ?

We are planning on extending the API enough to allow a limited interface. The first will be scheduling, problem list and medication manager. As with everything else, we will listen to the market. Extending the API has to be carefully done not to disturb published APIs. Developing an API does take away resources from other efforts, but we feel it is important.

What are your mobile plans ?

We will shortly have a Practice Fusion interface which will work on smartphones. It will have limited functionality, giving you the ability to view patients and the schedule. The extension of the API will probably have the same capabilities. We will be bringing our mobile interface, including iOS, Android, and RIM, hopefully in first half of 2011. This will work across all mobile devices with web enabled browsers. We are planning on native apps, depending on marketplace.

The Practice Fusion app store

The biggest enhancement will be a Practice Fusion app store. This is not yet announced although I have a rough date. The idea is that the doctor will have access to all the application within the Practice Fuson network . The app store concept is a way to unify the apps, downloading may occur elsewhere. We put the application as something the doctor can prescribe. The instructions to download the application may be sent to the patient via email.

This is a way for making applications work for you. The buyer could be the doctor, patient, payor, etc. It will be a place where developers can showcase their apps. The apps will be attached to a user’s account but could also be used on other devices, such as a communicating smartphone app.

We envision that doctors could prescribe an app much like they prescribe a medicine now. Right now all a doctor can do is write an order [CPOE] or hand out a pamphlet. But, there are a lot of things in between appointments where a patient can report back to the doctor – maybe compliance with a medication or nutrition plan. A weight monitoring app for a patient trying to lose weight can directly enter weights into their record. Simple alerts can signal patient compliance, or can even provide feedback to the patient herself.

There are well over 3,000 apps in the “medical” section of the App Store for the iPhone. Unfortunately, a growing number of them aren’t medical apps. It’s already difficult enough to parse through the litany of apps available to find quality apps – and then when you add apps that shouldn’t even be in the medical category, it makes the job that much harder.

Lets start with the “top 10 downloaded free iphone medical apps” in the App Store. Notice how the word “downloaded” is in bold. By no means do we think these apps are the best free iphone medical apps – we’ve already chronicled that list in another post.

These are the top 10 downloaded free medical apps in the App Store: Medscape, Sex-Facts, Epocrates, Medpage Today, Marijuana Truth, iAugment, Dream Meaning, Medical Encyclopedia, Body Systems – Anatomy Quiz, and Best Diet foods. Note, Medscape, Epocrates, and Medpage Today are extremely legitimate apps – they even made our top 10 free iphone medical apps list. Sex-Facts, Marijuana Truth, iAugment, Dream Meaning, and Best diet foods will never make any top 10 list of ours.

By our calculations, 12 of the top 25 downloaded medical apps, 48 percent, are mis-categorized and should not be in the medical section. So we looked into this a bit further.

What about the “paid” medical apps section. Surely the paid section would be more populated with apps in the right section – and it was. But again, some very odd choices for “medical apps”. Emergency radio, the 6th most downloaded paid medical app, and Police radio, the 17th most downloaded paid medical app, should clearly not be in the medical section of the App Store. It seems as if the developers threw in the word “EMT”, and Apple figured it sounded “medical enough”.

It’s not as if these apps don’t have other sections they could go in. There are 20 other categories in the App Store, and the apps I mentioned at the beginning could clearly go into the healthcare section.

As the App Store continues to grow at a rapid rate, it would be great if Apple did some housekeeping, and fixed its categories, or at least defined them better. The longer they let apps that shouldn’t belong in the medical section blossom, the more cumbersome the process of going through the apps becomes. Let’s hope this happens sooner than later.

Getting a new medication or medical device approved in the United States requires embarking on path so nightmarish it makes Dante’s Inferno look like the yellow brick road. And while most clinicians and bureaucrats would agree that we need to find a better way, its not hard to imagine how we ended up with such a complex regulatory structure. Going back over 2,000 years to the Hippocratic Oath, the practice of medicine has rested largely on two principles – beneficence and non-maleficence. The latter refers to the idea that we, as clinicians, first do no harm while the former requires that we act foremost in the best interest of the patient. In attempting to uphold these principles, we have created an enormous regulatory structure intended to act as a sieve allowing only those interventions of proven benefit to reach the general public.

I don’t claim its anywhere close to a perfect system. And as there are enormous amounts of money at stake, often involving a very vulnerable group of people, its our responsibility to stay vigilant against those who attempt to manipulate the system as well as treatments that are of questionable value. And there are a small group of app developers whose apps may fall into the latter category with claims to treat acne with light – well, that is unless a patient is willing to hold their iPhone to their face for the next 100 years.

Acne is an incredibly common condition which can significantly degrade quality of life. Up to 10% of Americans experience forms severe enough to leave permanent physical and psychological scars. While many therapies exist, escalation of therapy often involves significant risk. One emerging therapy is in phototherapy – basically using specific wavelengths of light to treat the skin. With a minimal side effect profile, results are promising. A recent review in the British Journal of Dermatology describes a number of small trials that show lesion reduction after treatment with phototherapy. For example, one trial found a blue-red light combination treatment to be more effective than a common topical treatment. Another found no difference between blue light treatment and a topical antibiotic. Its important to note that these trials were small and often poorly controlled, so the best conclusion that can be drawn is that these therapies are promising and warrant further study.

However, at least two app developers have decided to go ahead and bring this therapy to market – FunVid Apps with Acne Light Waves and Archibald Industries with Acne Away Premium. For $2 or $5, respectively, they claim that acne sufferers can watch their acne disappear in as little as 3 days simply by holding their iPhones to the affected area for as little as 1 minute twice a day. Wow!

When I first saw these apps, I was skeptical but decided to give them the benefit of the doubt. Surely, they would back up these claims with some evidence suggesting it works. Unfortunately, the website links on iTunes just go to the developer pages where the apps are not even mentioned. No luck here.

Then I thought maybe the developers had almost stumbled onto a low-cost, effective treatment for acne and further study would vindicate these apps. So I decided to compare the phototherapy these apps provided with that provided in one of the clinical trials. Unfortunately, the dosing of light in these trials is measured in irradiance (J/m2) and the only description of light output I could find for the iPhone was in illuminance (llux/umens) – the key difference between the two is that illuminance is more a measure of what our eyes perceive while irradiance is more a measure of the energy carried by the light. So at best, there is currently no way to show that the iPhone is even capable of delivering the doses of light that have been shown to have some effect in our small trials. At worst, based on my calculations, it would take over 100 years to achieve the same dosage of energy used in a single treatment in one trial of blue light phototherapy (see below for details on calculations).

So where does that leave us? Phototherapy is an unproven but promising medical therapies aimed at managing a condition with potentially severe physical and psychological consequences. I suspect these apps are likely cheap knockoffs of potentially beneficially therapy while providing no supporting evidence of their own.

Knowing that some medical therapies of acne make skin photosensitive, these apps are potentially harmful to patients who use them without a physicians knowledge. In addition, they more than likely provide no benefit to a patient suffering from acne. While these developers do not claim to be medical professionals, they do claim to treat a medical condition and should be held to the same Hippocratic standards that we hold all others in the medical field.

As such, I hope that one of two things would happen here. My preference would be that someone, preferably the developers, prove me wrong – give me some reason to believe that a reasonable argument could be made that these apps are effective. I promise I’d happily recant everything I’ve said. Otherwise, I hope someone – the developers themselves or Apple – pull these apps out of the app store, thereby preventing vulnerable patients on wasting their money on what is likely just a glorified mood light.

Appendix: What follows is the result of my attempt to convert the 207 lux output of the iPhone into an estimate of its irradiance. I include it only in the hopes that someone with a stronger physics background will either confirm or correct my calculations. At 207 lux and a screen area of 0.00425 m2, the illuminance of the iPhone screen is 0.87975 lumens. Using the phototopic luminosity function value of 0.1 at a wavelength of 420 nm, which is used in at least one trial of blue light, the conversion factor for a narrow band light would be 6830 lm/(W/m2). The irradiance would therefore be 0.00012881 W/m2 or 0.000000012881 W/cm2. So to reach the 40 J/cm2 per treatment that was used in the above referenced trial, it would take 126 years.

With over 100,000 apps available for the iPhone/iPod Touch and billions of downloads since the App Store opened just under two years ago, the market is clearly hot. And with the release of the iPad, expect a new flood of apps into the market.  However, a recent article in the New York Times suggests that even with the wealth of options, people generally use only five apps despite having downloaded far more.

The average iPhone or iPod Touch owner uses 5 to 10 apps regularly, according to Flurry, a research firm that studies mobile trends. This despite the surfeit of available apps: some 140,000 and counting.

Another finding that the article notes is that even thought hundreds of thousands of apps are available, the entire user group is generally exposed to the same few thousand apps.

A survey of iPhones, iPod Touch and Android users conducted in July 2009 by AdMob, an advertising network that helps people promote their applications on smartphones, found that people discover apps most often by browsing app stores. And even though the iTunes store is bloated with offerings, people tend to gravitate to the most popular….

“…The top apps featured at the store do change out,” Mr. Putney said. “But most users will never see more than 1 percent of the total apps available.”

These findings are important for iPhone/iPod Touch/iPad users, app developers, and even us here at iMedicalApps, and here’s why. For users, this means that finding the best apps requires some work – a conscious effort to search the app store for things that interest you. That includes looking beyond the most popular medical apps. For developers, this means that reaching potential customers requires finding ways to climb that popularity ladder. For the Malcolm Gladwell enthusiasts, this means finding the Mavens, Connectors, and Salesman (from Tipping Point) – basically the people with large social (or professional) networks who are most likely to adopt early and spread the message about your great app. And for us here at iMedicalApps, it means actively looking for that diamond in the rough, languishing at the bottom of the popularity rankings, and helping our readers discover useful apps they wouldn’t have seen otherwise.

Recently, I posted on a controversial healthcare application that claims to treat seasonal depression. In my post, I talked about the ridiculous app and wondered if the App Store approval process needed to be tweaked when it came to medical and healthcare apps. Then I started wondering if there are actual medical standards the App Store has in place. There was a nice write up done by PC World talking about how the lack of overall set standards are hurting developers and the end users. But what about medical standards in the App Store Approval process?  That’ll be the discussion of this post.

PC World:

It’s OK to post an iPhone app that guides users to (legal) marijuana suppliers, but it’s not OK to post a goofy little app that turns the iPhone into a simulated pot pipe. What’s the difference? Beats me, but it’s becoming clearer and clearer that Apple’s App Store ayatollahs are way too heavy handed and need to lighten up. They are hurting consumers, developers, and ultimately, the company they’re supposed to protect.

The problem is Apple refuses to tell what the OVERALL standards clearly are. They have some set rules, but their approach to controversial issues is to handle them on a case by case basis. The lack of standards can clearly hurt when it comes to apps such as the "Blue Light Therapy" App.

The description of the blue light therapy app is in itself hilarious. (iTunes link). "…clinically proven to fight seasonal depression…." Then a the end "….not intended to diagnose, treat, or cure any disease…". So….Apple rejects goofy apps that mimic a hookah burning tobacco because it doesn’t meet their "standards", but an app that contradicts it’s purpose in it’s own description is totally okay? Interesting….

There is actually a nice site that describes a lot of the App Store rules and how the approval process works/doesn’t work. I searched the web trying to see if there were any sort of standards for Medical/Healthcare Applications submitted to the App Store but I couldn’t find any. If there aren’t even a set of clearly defined standards for the overall app store, then one would assume there definitely wouldn’t be any sort of of higher standards for healthcare or medical apps.

The beauty of the App Store is that anyone with an innovative idea can develop an application. At the same time, anyone with a shady idea, especially medically or healthcare related can develop an application as well. The problem with medical and healthcare apps is, it’s harder for people outside of healthcare to see if they are actually useful. Bringing more scrutiny to the Medical or Healthcare approval process could lead to bigger headaches and issues with an all too familiar slippery slope.

Medicine is a constantly changing field, and there are medical applications in the App Store that are clearly outdated. It should be up to healthcare provider to realize this and it would be too difficult for Apple to police these applications. They don’t exactly know what standard of care is. I don’t think

Apple needs to have a doctor or healthcare provider on their approval board, but for apps in the medical or healthcare category, why not have a simple link in the iTunes description where you can voice a complaint easily? Or better yet, why not reject apps that contradict their healing powers in their own description? Until then, we’ll be here trying to keep you up to date….