FDA clears Withings iPhone blood pressure cuff

By: Brian Dolan | Jun 20, 2011        

Tags: | |  |
Withings announced this week that they’ve received FDA clearance for their iOS-compatible blood pressure monitor, allowing for its immediate availability in the US for a $129.99 retail price. The release marks the first time an FDA-approved BP cuff includes direct connectivity with an iOS device. First announced at CES this year, the monitor runs on three AAA batteries and works in conjuction with an iPhone, iPad or iPod Touch.
Users start the testing by using the free iOS app, which delivers results about thirty seconds later. These results, including date and time, can then be e-mailed to a physician via the app or instantly synced to health monitoring services like Microsoft HealthVault and Google Health. If the user also owns Withings body scale, that data will also be included in the monitoring graph.
Check out the full press release after the jump.

Withings Blood PressureWithings announced that the FDA has provided its iOS-powered blood pressure monitor with 510(k) clearance, and the company wasted little time making the device commercially available in the US. The FDA filed 510(k) clearance for the device about one month ago — on May 20, 2011 and the device went on sale over the weekend.

According to the FDA’s 510(k) clearance notice, the device is intended to be used in this way: “The Withings Blood Pressure Monitor, Upper Arm Type: BP-800 is [a] noninvasive blood pressure measurement [system] intended to measure the systolic and diastolic blood pressures and pulse rate of an adult individual, over age 18, at home by using a non-invasive technique in which an inflatable cuff is wrapped around the upper arm. The cuff circumference is limited to be 9′-17′ (22cm-42cm) for Upper Arm type.”

First announced at Consumer Electronics Show (CES) this year, the monitor, which retails for $129.99, runs on three AAA batteries and works in conjuction with a iPhone, iPad or iPod Touch. Users start their testing by using a free iOS app, which they are prompted to download immediately after plugging the device in. Results of the test are delivered about thirty seconds later, and alert users to unhealthy BP ranges. These results, including date and time for tracking purposes, can then be e-mailed to a physician via the app or instantly synced to health monitoring services like Microsoft HealthVault and Google Health. If the user owns a Withings body scale, that data will also be included in their results graph.

Also announced at CES was iHealth’s blood pressure cuff, which also connects to iOS devices but makes use of a cradle instead of just the standard dock connector cord that Withings’ device uses. iHealth’s device secured FDA clearance in early February, just weeks after the CES event and is now for sale at Apple Stores for under $100. The FDA 510(k) clearance letter for the iHealth device provided indications for use that were in effect identical for the Withings device.

Check out the full press release after the jump. Keep reading>>

Advertisement

Mobile health: How to comply with HIPAA

By: Brian Dolan | Jun 17, 2011        

Tags: | | | |  |

Adam GreeneBy Adam H. Greene, JD, MPH, former Senior Health Information Technology and Privacy Specialist at the HHS Office for Civil Rights, where he was responsible for applying the HIPAA Privacy, Security, and Breach Notification Rules to health IT, now a partner in the Health IT/HIPAA practice of Davis Wright Tremaine.

Once you have established that your mobile application is going to be subject to HIPAA, the next step is making sure that it allows its users (HIPAA covered entities or business associates) to fully comply with the HIPAA Privacy, Security, and Breach Notification Rules. You will need to focus on how your application shares protected health information, what security measures are in place, and how a user can tell if the information has been breached.

First, your application must allow the covered entity to comply with the HIPAA Privacy Rule. Generally, this means that the application does not make any uses or disclosures of “protected health information” that are not permitted by the Privacy Rule. If your application sends patient zip codes to you or a third party for the purpose of market research or for another impermissible purpose, then this would cause the covered entity to violate the Privacy Rule (unless the covered entity has obtained the patient’s authorization). Presumably, you are not interested in exposing your users to millions of dollars of potential HIPAA liability. Accordingly, you should avoid altogether having your software make any disclosures of protected health information that are not permitted under HIPAA — even if you have received the covered entity’s or business associate’s consent (they may be unaware that they are getting themselves into hot water by agreeing).

If your application uses protected health information and is used by the covered entity to make treatment or payment decisions about the individual, then it may be part of the covered entity’s “designated record set.” An individual has a number of HIPAA privacy rights with respect to information in their designated record set (such as medical and billing records). This includes the right to see a copy of the designated record set and to request a correction of any information. Accordingly, if your application is part of the designated record set (because it is used for purposes of treatment or payment decisions), then you should think about how the user can provide a copy of the patient information to the patient upon request. Additionally, if the patient believes information is incorrect, can the user reflect this in the application? Can the application allow the user to modify the information or to add a note reflecting the patient’s disagreement?

Second, you must ensure that your application is reasonably secure. Ideally, the user, as a covered entity or business associate, should include your application in the user’s overall HIPAA Security Rule risk analysis, identifying potential threats and vulnerabilities to protected health information. You can greatly assist the user by also conducting your own risk analysis, employing appropriate safeguards, and making this information readily available to the user. Is it reasonable for your application to encrypt patient or enrollee information to protect against loss of the mobile device? If your application transmits protected health information to an electronic health record system or patient/enrollee, is it reasonable to encrypt the information in transit to protect against the threat of interception? Whether safeguards such as encryption are appropriate may vary based on a number of factors, such as the type of information and the availability of other safeguards (such as general controls). Whatever determination you make should be readily available to the user, such as “the application does not encrypt information because … , so you may want to turn on the encryption feature of your mobile device.”

Another security issue to consider is user authentication. If your application allows the user to remotely access a covered entity’s protected health information, does the application include a reasonable means for the covered entity to verify the identity of the user? The limitations of the mobile device may be an issue, such as when the covered entity uses multifactor authentication (e.g., a physical token and a password or PIN) for remote access to an electronic health record, but the smartphone does not support such an authentication scheme. Ideally, your application should also include an access log to the extent that information is stored locally on the device, so that the covered entity’s records can reflect when a patient’s or enrollee’s protected health information has been accessed.

Third, the HIPAA Breach Notification Rule requires covered entities to report breaches of protected health information (currently defined as impermissible uses or disclosures that create a significant risk of financial, reputational, or other harm to the individual). Covered entities are expected to report breaches that they discover, or through reasonable diligence would have discovered. Accordingly, you may want to consider how your application fits into the covered entity’s or business associate’s breach detection program. If your application is compromised, is there any way for the user to be alerted?

Finally, while the above recommendations are focused on ensuring that your users are able to comply with HIPAA, there may be circumstances where you must comply as well. If you have access to protected health information (such as through the installation or support of your application), then you may be a business associate of the covered entity or business associate who is the user. In such circumstances, you will need to enter into a business associate agreement with the user. In addition, you will be required to limit your uses and disclosures of protected health information in accordance with the Privacy Rule, comply with all requirements of the Security Rule, and notify the covered entity or business associate of any breaches of the protected health information in accordance with the Breach Notification Rule. As a business associate, a failure to follow the Breach Notification Rule is currently subject to civil money penalties, and a failure to follow the Privacy and Security Rules will be subject to penalties in the near future (rulemaking on business associate liability has not yet been finalized).

Adam H. Greene previously served as the Senior Health Information Technology and Privacy Specialist at the HHS Office for Civil Rights, where he was responsible for applying the HIPAA Privacy, Security, and Breach Notification Rules to health IT, and now is a partner in the Health IT/HIPAA practice of Davis Wright Tremaine. Mr. Greene’s full bio is available at here.

Audacious, sure, but is a Tricorder achievable?

By: Brian Dolan | Jun 16, 2011        

Tags: |  |

Brian Dolan, Editor, MobiHealthNewsMarty Cooper, the inventor of the modern cell phone, has on occasion credited the fictional TOS Communicator device, featured in the 1960s television series Star Trek, as inspiration for the mobile phone. While the mobile phone has served as the de facto platform for most mobile health services today, yet another device from the very same popular science fiction series could inspire a new generation of inventors: The Tricorder.

Yesterday I had the pleasure of participating in a “visioneering” meeting set up by the X Prize Foundation, which is working to set up a new X Prize that would incentivize the development of a device similar to the handheld diagnostic device featured in Star Trek. Qualcomm has already agreed to fund the development phase of the Tricorder X Prize (the name may change), but a prize sponsor for the competition (one of the prizes is a $10 million check) has yet to sign on.

For those unfamiliar, the X Prize Foundation has set up a number of “audacious” yet “achievable” competitions over the years, including private space flight; self-driving cars; affordable genome sequencing. A Tricorder-like device is right up there.

“What we’re trying to do is develop a mobile solution that can diagnose patients, better than or equal to a panel of board certified physicians,” Michael Timmons, X Prize Foundation spokesman, told NPR in an interview this week. “So essentially what it would do is enable anyone, pretty much at any location, to quickly and successfully assess health conditions.”

Qualcomm Vice President Don Jones provided NPR with his vision for the type of system this competition might inspire:

“Come up with sensors, software, kind of innovative approaches to collecting data and information to make it really, really easy to make a diagnosis. And do it in a way that’s relatively inexpensive, lightweight, small, portable,” Jones said. “And as minimally invasive as possible.”

If it comes to fruition, the Tricorder X Prize competition will become a key catalyst for mobile health devices and services. Actually, after spending the last day and a half with two dozen healthcare “visioneers” discussing the potential future for health devices and services, I am certain it already has.

INVITATION: MobiHealthNews is very excited to announce that next month we will host our second webinar: Mobile Health Midyear Update. I’ll be discussing my take on notable events that happened during the first half of 2011 along with a good number of predictions for this year’s remaining months. Let me know if you have any tips for what’s to come. (Be sure to register here — it’s FREE!) Special thanks to our sponsor Ciber, who will present their take on mobile health trends along with a strategy session on consumer engagement. Tune in July 21 at 2PM EST.

Advertisement

When HIPAA applies to mobile applications

By: admin | Jun 16, 2011        

Tags: | |  |

Adam GreeneBy Adam H. Greene, JD, MPH, former Senior Health Information Technology and Privacy Specialist at the HHS Office for Civil Rights, where he was responsible for applying the HIPAA Privacy, Security, and Breach Notification Rules to health IT, now a partner in the Health IT/HIPAA practice of Davis Wright Tremaine.

The Health Insurance Portability and Accountability Act (HIPAA) Privacy, Security, and Breach Notification Rules can be a daunting challenge. Sometimes, the biggest question facing mobile application developers is not how to comply with (or make sure users are complying with) HIPAA, but rather whether HIPAA even applies. To understand whether software falls under the HIPAA rules, a developer must answer two questions: (1) Who will be using the application, and (2) What information will be on the application?

The HIPAA Rules only apply to HIPAA “covered entities” and their “business associates.” They do not apply to health care consumers or to other types of entities. Covered entities include health plans (including employer-sponsored group health plans), entities known as health care clearinghouses (which convert health care claims and other administrative transactions into or from a standard format), and health care providers — but only if the health providers electronically conduct certain transactions, such as submitting claims to health plans electronically. A business associate is an entity that handles “protected health information” on a covered entity’s behalf, such as a health information exchange organization sharing health information on behalf of a health care provider, or a pharmacy benefit manager operating a health plan’s prescription benefit.

Additionally, the HIPAA rules only apply to “protected health information,” information that identifies an individual and that relates to an individual’s physical or mental health, health care services to the individual, or payment for such health care services. There are exceptions for employment records and records of educational institutions. The fact that an individual has received services from a covered entity is itself protected health information. Accordingly, the name or address of an individual, although publicly available, is protected health information when residing on a covered entity’s computer if the presence of the information suggests that the individual is or was a patient or enrollee of the covered entity. Protected health information also includes otherwise anonymous information that includes a date of service (anything more detailed than a year). Accordingly, an e-mail referring to “the patient who was in last week” is protected health information, because it includes a date of service that can be used to identify the patient.

A mobile application developer will need to analyze whether the software will be used by a covered entity, such as physician, hospital, or health plan, and whether it will include any protected health information: individually identifiable information about health, health care services, or payment for health care services. An application that assists a physician with following up with patients would need to be designed to allow the physician to comply with HIPAA. Likewise, a mobile application for use by health plan employees to obtain an individual’s enrollment information remotely would need to be designed in accordance with HIPAA.

In contrast, an application that is for use by patients is not going to fall under HIPAA; an application on a person’s smartphone that assists the user with following a medication schedule would not fall under HIPAA because there is no covered entity involved. Even if the application permitted the user to send information to her physician, the application would not be subject to HIPAA, although the information would become subject to HIPAA once the HIPAA-covered physician received it.

An application that is to be used by a covered entity but does not involve protected health information would also not be subject to HIPAA; an application that provides a nurse with “de-identified” influenza statistics would not be subject to HIPAA because it does not use individually identifiable health information. Note that if the application allows the nurse to add information about the hospital’s influenza patients (such as that an individual came in with H1N1 symptoms today), then the patient information will be subject to HIPAA.

Other types of entities, such as public health authorities, are not covered entities either — an exception may be if they are also providing a health plan or providing health care services. Accordingly, a mobile application for a local government epidemiologist that assists with a public health investigation would generally not fall under HIPAA.

In determining whether an application falls under HIPAA, the developer should focus on the user, rather than the distribution channel. If a health plan provides enrollees with an application that allows them to track their weight on their smartphone, the application is not subject to HIPAA (since it is used by a non-covered entity – the enrollee – on the enrollee’s smartphone). If the application stores data on the health plan’s server, however, the information on the health plan’s server would be subject to HIPAA.

It is worth noting that, while health-related applications that are not used by covered entities or business associates are not subject to HIPAA, they may be subject to other privacy and security laws. For example, if the software is sharing user information in violation of a privacy notice, this could represent a deceptive trade practice subject to the Federal Trade Commission’s enforcement authority.

Tomorrow, in part two of this series, we will look at what an application developer should do if their application is subject to HIPAA.

Adam H. Greene previously served as the Senior Health Information Technology and Privacy Specialist at the HHS Office for Civil Rights, where he was responsible for applying the HIPAA Privacy, Security, and Breach Notification Rules to health IT, and now is a partner in the Health IT/HIPAA practice of Davis Wright Tremaine. Mr. Greene’s full bio is available at http://www.dwt.com/People/AdamHGreene

By 2016: 80M wearable wireless fitness sensors

By: Brian Dolan | Jun 15, 2011        

Tags: | | | |  |

Garmin wireless sensorAccording to a new report from ABI Research, wearable wireless sensors for fitness and wellbeing will surpass 80 million devices by 2016. This figure will eclipse other wireless sensors markets, including professional and home healthcare monitoring. In its report, ABI notes a range of factors will influence the uptick in devices: wireless protocol standardization, new device availability, as well as changing social patterns that encourage people to record and share fitness performance data.

“There is real and strong growth potential for wearable wireless devices in the consumer market today,” said ABI Research principal analyst Jonathan Collins in a press release. “These devices don’t require the same level of complexity and regulation to deploy that healthcare devices do.”

The new wireless standards that are spurring this growth include M2M (cellular-enabled) and short range connectivity (i.e. Bluetooth or ANT+). This market will have an estimated 46 percent compound annual growth rate from 2010 to 2016.

“Enabling online fitness data collection and sharing will drive key new revenue streams,” said Collins. “Online applications also bring the promise of a social networking effect, with participants sharing their results with friends or new groups formed within the application, thus spurring further adoption.”

ABI Research reported back in 2009 that 400 million wireless sensors would reach the market by 2014.

Read the full press release after the jump. Keep reading>>

HHS offers SMS toolkit for disaster response

By: Neil Versel | Jun 15, 2011        

Tags: | | | |  |

Photo Credit: James Gathany, Centers for Disease Control and Prevention

Photo Credit: James Gathany, Centers for Disease Control and Prevention

Acknowledging the power of text messaging to spread information fast, the Department of Health and Human Services has produced a toolkit of prepared messages for state and local authorities to disseminate during a disaster response.

A collaborative effort of five HHS divisions, the messages are meant to complement television and radio public-service announcements produced by the Centers for Disease Control and Prevention, according to government officials.

“During a disaster, the state or local agency can download and distribute the new public health messages using their existing cell-phone emergency message distribution systems. Community residents should contact their local emergency management agency to learn whether text message alerts are available in their community and to register if available,” according to an HHS press release.

Sample messages include: “To help care providers, keep a list of drugs and dietary supplements with you. More info from CDC 800-232-4636 or http://go.usa.gov/jvZ“; and “Prevent child drownings. Keep kids from playing in or around flood water. More info from CDC 800-232-4636 or http://go.usa.gov/bGa.”

Though the texts have not been tested in a real disaster situation yet, HHS spokeswoman Elleen Kane says that the messages are based on existing PSAs. “We felt pretty confident that they will be effective,” Kane tells MobiHealthNews. HHS reports that more than 400 entities have expressed interest in using the messages.

Public health agencies seem to be receptive to the idea. “It’s efficient, because a lot of times you just need to send very simple messages, and sometimes you need to send messages to a lot of people,” Dr. Georges Benjamin, executive director of the American Public Health Association, says.

Benjamin says that the association convened a meeting at its Washington headquarters two years ago to discuss risk communication via social media. “It’s just beginning, but we’re seeing it more and more,” he said.

Benjamin noted that the Food and Drug Administration used text messaging and Twitter during the 2009 recall of peanut products and said that since the 2007 mass shooting at Virginia Tech, many schools have been working with local authorities to develop plans for text communication for future emergencies. “There’s no question there’s a lot of interest in this and that [texting for disaster response] is going to explode,” he said.

HHS limited each message to 115 characters so users can add local details as necessary. Standard SMS texts have a capacity of 160 characters, including spaces.

HHS says the department worked with state and local agencies to develop the messages. In addition to the CDC, other participating HHS branches include the FDA, the HHS Office of the Assistant Secretary for Preparedness and Response, the HHS Office of the Assistant Secretary for Public Affairs and the Substance Abuse and Mental Health Services Administration.