Apple Targets Health Care with iPhone 3.0 OS

On March 17, Apple announced iPhone OS (operating system) 3.0 software and a new iPhone software development kit (SDK) for developers. The 3.0 software expected to be released this summer. The SDK is in beta form and can be downloaded now. (You can watch the event here. I got better performance after doing a save-as of the video and playing it in QuickTime rather than the browser.) For a general overview of the announcement, I recommend Gizmodo’s coverage, here and here. Gizmodo also has a nice overview of the top 5 smart phone platforms (iPhone, Android, Windows Mobile, Blackberry, Palm Pre) here. Also note that the iPod Touch offers most all the functionality of the iPhone, except for mobile phone features. The iPod Touch would make an attractive alternative to the iPhone (smaller, less expensive) in many health care applications.

The announcement started with some bragging. Apple has sold more than 30 million iPhones and iPod Touches since they were introduced in 2007 to the end of 2008. The market for third party applications, distributed through Apple’s App Store has likewise been phenomenally successful. With this new announcement, Apple signaled their intent to strengthen their hold on games and other consumer apps, and extend into vertical markets like the enterprise and health care.

There are many new features in the 3.0 iPhone software, but the announcement was really more about Apple’s new SDK  for the iPhone. The SDK is what third party developers use to design accessories and software for the iPhone. This new SDK exposes for the first time, about a thousand software features (what Apple calls APIs, for application programing interfaces) that can now be used by third party developers.

Key Features for Health Care

External Accessories:  Apple is going to allow external accessories to interface to the iPhone through a new framework called External Accessories (see 16:12 in the Apple announcement video). External hardware devices will be able to integrate with the iPhone via the dock connector or wirelessly over Bluetooth. This connectivity will support many of the standard protocols implemented on the iPhone in addition to proprietary protocols developed and implemented by third party accessory developers. At 17:40 in the video, Apple calls out medical devices as a target application for their External Accessories APIs, showing a blood pressure cuff.

An important external accessory with strong market demand in health care is the bar code reader. According to Trey Lauderdale, vice president of innovation at Voalte, Inc., “Lots of hospitals use barcodes and many ask us, can I use the iPhone to read barcodes? Now with the EA framework barcode readers can be integrated with the iPhone over Bluetooth or cable.”

Game Kit: A potential hidden gem for health care in the new SDK is a new framework called Game Kit. This framework includes a capability called a voice chat service — effectively wireless VoIP. This allows developers to establish a chat service between 2 points using Bluetooth or WiFi. While some may think this a threat to mobile carrier’s revenue models, a more important market for the iPhone is enterprise wireless VoIP.

Writing data oriented workflow applications for existing wireless VoIP handsets is time consuming and expensive. Each phone manufacturer has different sized displays, many of them very small. And each vendor has their own proprietary Java API for implementing apps on their phones. This means a third party vendor has to effectively rewrite a handset application (including user interface design) for each different phone manufacturer they want to support. There are several major vendors in health care: Cisco, Ascom, Spectralink/Polycom, Vocera, and Avaya. If the iPhone gets both traction in health care with applications, and Apple successfully enters the enterprise wireless VoIP market, they could be a real force in health care.

Voice Recording: There are currently numerous audio recording applications sold through the App Store. These are stand alone apps that do all the heavy lifting of acquiring, storing and managing voice recordings on the iPhone. In the new SDK, Apple makes it quick and easy for app developers to leverage the iPhone’s resources to much of this heavy lifting to add a voice/audio recording feature to any app. Given the interrupt-driven environment at the point of care, voice notes could be a real boon for busy caregivers.  With integration to platforms like Nuance, dictation and Vocera-like workflow automation features could also be more readily available to developers.

Potential iPhone Use Models

There are 3 ways to leverage the iPhone at the point of care, each targeting different needs, productization strategies, and markets. These use models are: virtualized medical device, sensor gateway, and point of care computing device.

iPhone-NIBP

Virtualized medical device:  The blood pressure example shown at the Apple introduction event is a virtualized medical device. Increasingly seen in the physician office market, virtualized medical devices shrink the embedded device down to its bare essentials and move the raw data produced by the sensor to a general purpose computing device, typically a laptop, for final processing and analysis. The sensor includes required front end electronics for first pass signal processing and amplification. The connection to the computer is done via cable or a wireless cable replacement like Bluetooth.

This link shows a conventional purpose-built embedded system spirometer, and here you can see a virtualized spirometer. Which type has lower product development and manufacturing costs? Which is probably easier to use? Intel has a white paper that offers a great explanation of virtualized medical devices, using multi parameter physiological patient monitors as an example (pdf white paper). Applying this use model to the iPhone is easy, just write the software for the iPhone instead of a laptop, PC or PDA.

The regulated medical device in this use model has 3 main components: the sensor package, software that is installed on the computer, and an off the shelf computer. Currently the vendor who makes the sensor writes the software, and these constitute the lion’s share of the regulated medical device. The computer is also part of the regulated medical device, but is utilized as an off the shelf component. A Dell laptop, or Apple iPhone aren’t regulated by the FDA or equivalent international agencies. Manufacturers providing off the shelf products used in regulated medical devices often have hoops to jump through, but these are specified by their medical device customers and how they choose to split the regulatory burden between them and their suppliers. (If you’re new to FDA regulations see this post, Facing FDA Regulations for the First Time).

A defining piece of medical device regulations are the marketing claims or intended use for the device. Apple’s description (intended use) of their prototypical blood pressure device started out as an unregulated device. This is one used solely by the patient for their own use for health and wellness (aka the fitness market). As soon as the Apple presenter mentioned that, “users could send their blood pressure data to a physician,” the system became a medical device — in this case, because the data is used for diagnosis.

The markets for virtualized medical devices are currently those with a high sensitivity to price and frequently lack specially trained techs (and thus need to be easier to use). There is nothing preventing virtualized medical devices from entering the acute care market, i.e., hospitals. This product strategy can also be extended to the Healthcare Unbound remote monitoring market. Such devices can and do find use by home health agencies and patients. The patient segment for an iPhone enabled medical device is almost all self-pay (there is no reimbursement for fancy automated solutions like this). Since these remote monitoring markets are extremely price sensitive, virtualized devices offer real potential.

Sensor Gateway:  Many use cases include one or more sensors that acquire patient data. This data must be consolidated and then sent on to anOneTouch-demo application that stores and manages the data. This use model differs from the virtualized device in that the sensor produces data in its final form, ready to be used by the patient or clinician, while the data from a sensor in a virtualized device must be further processed and analyzed before providing usable clinical data. For more on this check out Continua Health Alliance’s vision video.

The sensor gateway example was presented in the Apple event, a blood glucose meter the One Touch from LifeScan (go to 43:25 in the Apple video to see the demo). LifeScan was one of a small group of companies that were provided access to the SDK two weeks in advance of the announcement. Over that time, these early users implemented “proof of concept” applications. Dave Detmers, communications director at LifeScan told me, “Our goal is to make diabetes management as seamless as possible for patients, so that it’s easy to integrate into patient’s lifestyles.” The One Touch demo was a proof of concept showing the potential capabilities offered by the iPhone (which were pretty impressive). While LifeScan plans to have an offering for the iPhone in the future, Dave noted that, “the combination of the One Touch glucometer, software and the iPhone represent what the FDA defines as a medical device.” Further, he noted that an application of this kind would include electronic patient identifiable data, and would have to meet HIPAA requirements.

The One Touch demo represents a gateway dedicated to the sensor made by the vendor. A different business strategy for the gateway use model would have a company creating a multipurpose gateway intended to support sensors from different companies. Other companies like Nokia and Motorola are looking at this model for the remote monitoring. Chronic disease management is dependent on patient’s self management. Chronic diseases like COPD, CHF, and diabetes, need data from multiple sources: diet information, weight, blood pressure, SpO2, and other parameters.

As solution providers struggle to develop and refine systems for chronic disease management, reimbursement for most of these technology solutions has yet to appear. This means that for the foreseeable future, systems of this type will be bought and paid for by patients rather than insurance companies, thus limiting market potential.

Point of Care Computing Device:  The final use model for the iPhone is as a point of care computing device. Based on this latest Apple announcement, the iPhone could replace PDAs, tablet computers and wireless VoIP handsets. I’ve been ranting about the many short commings of point of care computing devices for quite some time. Here’s what I think is needed for the perfect point of care device. There have been many attempts, the C5 mobile clinical assistant, Philips ProScribe tablet, the Emano Tec MedTab, and the OQO UMPC. I’ve even looked at wireless VoIP handsets and PDAs. Both the market and I are still looking.

Besides the obvous limitations (insufficient battery life, small hard to read displays, size and weight), perhaps the biggest barrier for point of care compuating devices is selecting the right applications and designing a good user interface. Charting in the EMR is not a good application for a hand held device (this is why C5 tablets ride around as computers on wheels). But messaging like alarm notification is a great application, as is voice, and certain workflow automation applications like patient flow and perhaps meds administration.

There are no FDA regulatory requirements when an iPhone is used as a general purpose computing platform for unregulated software. An iPhone used for alarm notification meets the definition of a medical device. In fact the FDA has recently published a rule calling out alarm notification systems for regulatory enforcement. Any application that connects to a medical device using the announced External Accessory framework, would likely be regulated. But for the most part, this point of care computing is an unregulated market opportunity.

While not perfect, serveral features make the iPhone attractive for the point of care. Regulatory requirements and the way vendors design their products will require some degree of device duplication at the point of care. So far this has impacted PDAs and barcode readers. And over time, this duplication will likely subside and may even disappear. Until that happy day, users need devices that are light weight and easy to carry. Infection control and fluid ingress is always a concern with devices sporting keyboards. The iPhone’s touchscreen eliminates cracks and crevases where infections can hide on other devices. And the relatively large high resolution display (and underlying software tools) make designing a user interface that’s easy on today’s caregivers’ eyes.

But the iPhone is not perfect. The thousands of third party products designed for the iPhone were mentioned in the Apple announcement. Lauderdale with Voalte has found these vendors to be very accomodating in meeting the special needs of health care. “Case manufacturers have been very responsive in helping us improve the iPhone’s ability to withstand repeated drops, and stand up to harsh hospital disinfectants.” Battery life is addessed two ways, writing software to conserve power and through the use of external batter packs. Projects are underway to extend battery life to 12 hours and/or provide easily swappable battery packs with something closer to an 8 hour battery life.

At the HIMSS 09 exhibition next month, I expect to see at least one vendor with products based on the iPhone. Health care is not just another vertical where you can dress up a horizontal market product with some marketing and “partners” and watch the sales roll in. The core mission of health care is diagnosing and treating people — saving lives. If you sell light bulbs, that’s not an issue. If you’re targeting clinicians and the point of care, you’re going to end up having to meet some regulatory requirements and do some engineering to fine tune your product.

The iPhone’s ultimate success in health care will depend on how effectively Apple supports this vertical market and the smart developers and entrepreneaurs attracted to the iPhone. Hospitals alone could add several million additional iPhones to Apple’s sales, business they otherwise would not get.

UPDATE: Blog mobihealthnews has an interview with Dave Detmers of LifeScan, who I quote above. The last paragraph is the most interesting. At Chilmark Research, see John Moore’s consumer oriented slant on the iPhone 3.0 announcement.

UPDATE: Here’s an interesting discussion of iPhone apps as promotional vehicles. Remember the metal gestational age wheel from Corometrics? Useful, durable, and a pervasive branding message found in virtually every labor and delivery department. There are many valuable applications that could prove invaluable to caregivers and clinicians.

Share

14 comments

  1. Great article! When I saw the pressure cuff during the announcement I was hoping someone would start generating some ideas for healthcare applications.

    Ever since the first generation iPhone, we’ve been day dreaming of ways to use them in our hospital system – do you think there is a use for patients directly? Maybe giving them to inpatients to keep in touch with friends and family – simple maybe, but might be something patients really appreciate.

  2. Nick, as you note in your blog (click Nick’s name in his comment above), customer satisfaction in health care is all about the experience. Provided there’s meaningful value that can be delivered on an iPhone given to the patient, rather than through conventional means, I can see innovative providers giving patients iPhones.

    I can just as easily see hospitals giving iPhones to staff, say those over worked nurses they want to retain, for use at the point of care and during their off hours.

  3. Insiteful and throrough analysis, Tim. (as usual)

    iPhone is quite provacative in how they are creeping into the medical field. This release has the prospect of making an all out assault on iPhone’s official entre into hospitals. It’s going to be interesting to see how quickly hospital IT departments start considering the iPhone to replace the VOW and push-to-talk devies they now have in the clinical settings.

    Not sure if you’ve looked at what AirStrip has been doing. Their business model is very intriguing. We’re kinda headed in the iPhone direction (being pulled into it by physician demand, if nothing else.) It’s going to be interesting to watch how the iPhone form factor might evolve to fit some specific demands in the acute and long-term care markets.

    Again, great job!

  4. Since I know you are a member for the Apple nation, I’m not surprised that you would follow this one closely ;-)

    Whether IT is comfortable or not (and they are not), or whether the application vendors are ready (they are not), iPhones are definitely creeping into the hospital enterprise. Apple has done such a phenomenal job of making the smartphone be a user-centric device that is not just geek chic, but one that feels necessary for day-to-day life.

    Walk around a hospital today. You see this with residents, but also with the significant population of doctors who traverse from their private practices to the hospital enterprise. These intelligent consumers will demand these smarter uncrippled devices, other issues be damned (security, asset management, cost, etc…).

    What’s necessary for the iPhone (or Android, or Blackberry) to reach critical mass will be right applications (built properly for this type of form factor), and some interface tweaks, ergonomic adjustments (think “buttonology”) and practical ruggedization. Clearly Apple first went after the mass market, but now it can explore a different kind of ubiquity.

    In the end, I think this is great disruption, as the user will win in the end. I’m looking forward to see how this unfolds.

  5. Epiphany has promoted using the iPhone since its introduction to allow cardiologists to read ECGs instantly. (You can see demo here.)

    The most critical ECG is the one coming in on an ambulance, a ST Elevation Myocardial Infarction (STEMI). With a STEMI patient, time is tissue.

    Goal by ACC/AHA is to reduce the door-to-balloon time (D2B) below 90 minutes. Single diagnostic is the ECG. Allowing the interventionalist to bypass the ED and go straight to the cath lab saves minutes.

  6. Caston: I first covered AirStrip’s introduction, with a few follow up posts (here and here). Being the obsessive photographer, I also got a couple photos (here and here). AirStrip is very cool, and has remarkable performance. Maybe this year we’ll see MP4 Solutions introduce remote monitoring for other medical devices.

    Kenny: You’re right, the smart phone that best meets market requirements will win.

    Jim: Thanks for sharing our application. It should be a real boon for highly mobile cardiologists.

  7. Tim: Excellent article, thanks for your insights.

    I am a physician as well as a computer aficionado. I have been working on a simple but elegant program that would allow patients to track their symptoms on the iPhone, and monitor the results. My program also allows them to email the results to their doctor if they wish, and the doctor can use those results to make a diagnosis, or to track the user’s progress.

    This program does not involve accessories (but future programs will likely exploit the use of accessories).

    From what I read in your article, my program would qualify as a medical device! So, would I have to get approval from the FDA? Am I covered by simply disclaiming, “This program has not been approved by the FDA to diagnose or treat any illnesses?”

    (Rhetorical question- do all the existing iPhone applications that track caloric intake and weight- and allow reports to be sent to a doctor- also count as a medical device?)

    Since all apps must be approved by Apple to be in the AppStore and since Apple takes 30% of the profits, is Apple partially responsible/liable? Especially since they have announced their support of such medically-related programs?

    I hear Apple may be opening a specialty AppStore for high-end programs (ie, more expensive games designed by large studios). I would like to see the creation of another AppStore for Medical-related Apps. And intrinsic to this store would be a partnership with between Apple, third-party programmers and the FDA, to ensure the safety of individuals and the public at large, as well to provide a fast and easy review process.

  8. Your product sounds great — as one who gets migraines, I’d love to be able to track symptoms (and diet) so my neurologist and I can evaluate therapy.

    How you state the claims for your product has significant impact on whether it qualifies as a regulated medical device. While there is some wiggle room, claims (or intended use) must reasonably cover the expected use of the software. You can’t say a medical device is not a medical device, just because you say so. A recent example is “secondary” alarm notification systems. In the law, there’s no such thing as “secondary.” Alarm notification systems are medical devices, and the FDA’s proposed MDDS rule calls this out. Vendors are simply trying to avoid regulation — which won’t work in the long run.

    Calorie counting apps, and maybe even your app (depending on features and claims) are classified as “information exchange” or automated record keeping — and thus, not medical devices. The most recent FDA guidance on products of this type was published in 1989, and it’s worth a read (pdf).

    In general, the FDA currently uses their regulatory discretion and does not take enforcement actions against the type of product you describe. THIS CAN CHANGE ANY TIME. From comments recently made by Don Witters at TEPR+, it is clear that they are concerned about the safety risk in software similar to yours, and are evaluating how they might be regulated. Another example here are CPOE systems that have repeatedly injured or killed patients over the past few years.

    Software manufacturers in this space would be well advised to develop a regulatory strategy, both for the day the FDA publishes a new draft rule for software and to manage liability and regulatory risk. I expect the FDA to do something on this during Obama’s first term.

    The App Store raises a couple of interesting questions. First, the law states that only the vendor with regulatory approval may market, promote and sell a regulated device. This does not rule out dealers or resellers (which is where the App Store would come in), but this places special requirements on Apple’s App Store. It takes more than calling yourself a dealer to be a medical device dealer.

    The second issue comes to one of value. In the consumer, or even small business market, Apple provides a valuable service for which theY extract a third of the value of the transaction. In much smaller vertical markets — especially for products that are actively sold, rather than “ordered” over the Internet — the App Store provides little value.

    Medical dealers or value-added resellers earn about 40% margin for making in-person sales calls (and closing the sale), installing systems, training users, and providing after-sale services. Apple does none of these things.

    It will be interesting to see what approach Apple takes with high value iPhone apps for vertical markets, and how the market reacts.

  9. Tim: Thank you so much for all your insights. What a fascinating time to be in the medical and information businesses.

  10. Pete McMillan

    Apple probably doesnt know what a mess it is getting itself in to with FDA regulations.

    Personally, I would hate to see the physicians in our hospital demanding to use the iPhone as a medical device. The biomed dept has enough issues with bona-fide medical devices, without adding the support of a consumer device in to the mix.

    A device built for in-hospital use has to meet very specific criteria – cleanability, sterilizability (where required), stability, immunity to RF interference, low RF emissions, reliability, support parts availability, long support life, 5-7 years support after discontinuance etc. iPhone is a commercial device that will probably be outdated and replaced by a new model in 2 years. The parts will be discontinued in another year or so. What will we do then with all the users stuck with the last year’s models?

  11. Tim, great article.
    A biomed company named Cardicell is doing the same but the other way around – they develop an iPhone device for their medical sensors. Their products will be FDA approved. I would use their device in my hospital and not the iPhone for various reasons part of which are support and regulation.

  12. Interested to read about this – trying to write a blog post on the BT/Wireless possibilities – medical related apps are one.

    Not sure if this article
    http://www.apple.com/iphone/enterprise/doylestown.html
    From the Apple website has been talked about.

    Apple’s future roadmap screams future integration and a push into the Science field. Would be interesting if Apple had had deep level talks with the FDA…

    http://www.apple.com/science/

  13. Tom,

    The article you reference is a case study of physician adoption of the iPhone. Many new vendors in the market focus on physicians. Watching TV shows like House, you’d think hospitals only employed doctors a few nurses and zero techs.

    Just the opposite is true. Most physicians don’t work for the hospital, and are greatly out numbered by nurses and techs — who represent a much bigger market for point of care computing solutions.

    While it’s great that EMR vendors are writing client apps for doctors to run on their iPhones, this won’t have a big impact on hospital operations. Arguably, the iPhone could be a big help in driving physician adoption of EMRs, though many of the important modules, like CPOE, would be hard to squeeze into an iPhone.

    Of greater potential impact are apps from companies like Voalte, who are targeting nurses and techs.

  14. I have a question:
    If a patient uses an IPhone (or any digital camera) and securely uploads images to a doctor’s website, would that be regulated in any way? Are there potential legal issues with this?
    For example, if a dermatologist wants to allow patients to send them patient-taken pictures of skin issues so that they can make a preliminary diagnosis, would that be regulated or would there be any legal issues?

Trackbacks/Pingbacks

  1. Facing FDA Regulations for the First Time :: Medical Connectivity - [...] If a patient uses their cell phone to create and send an SMS to their doctor, the phone is …
  2. Apple Targets Health Care with iPhone 3.0 OS :: Medical Connectivity | ComputerPortions.Com - [...] See the rest here:  Apple Targets Health Care with iPhone 3.0 OS :: Medical Connectivity [...]
  3. The Best is Yet to Be | Job Searching Blog - [...] Apple Targets Health Care with iPhone 3.0 OS (medicalconnectivity.com) [...]
  4. 400 reasons why Big Pharma needs to think about the iPhone « S&R Blog - [...] has even targeted healthcare use with the iPhone through the introduction of its new 3.0 operating system, which allows …
  5. Dear Mobile Manufacturers, Show Me a Truly Connected World – An Open Letter | Artefact | User Experience Design Blog - [...] to medical accessories through a standardized framework that senses, captures and controls [...]
  6. Backup Home « - [...]     iPad with Health Care     iPhone 3.X OS Health [...]
  7. Dear Mobile Manufacturers, Show Me a Truly Connected World – An Open Letter | Artefact - [...] to medical accessories through a standardized framework that senses, captures and controls health [...]
  8. Navigating Regulatory Uncertainty for Smartphones | Medical Connectivity - [...] For example, Apple came perilously close to claiming the iPhone was a medical device during their iOS 3.0 intro …

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>