There are two key areas where business leaders argue that laws and regulations are impeding innovation: the Health Insurance Portability and Accountability Act (HIPAA), which protects the privacy and security of patient data; and the U.S. Food and Drug Administration approval process, which software companies say is too ambiguous about which types of software will be regulated.
HIPAA, first signed into law in 1996, was updated in the HIPAA Omnibus Rule required by the HITECH Act of 2010. The update strengthened privacy, security and enforcement provisions, but many people designing mobile health applications say it did not simplify policy and technical language. Some complain that instead of specifying how to comply, the regulations offer only high-level recommendations. The U.S. Department of Health and Human Services (HHS) refers developers to other resources such as the National Institute of Standards and Technology (NIST) for recommendations on how to encrypt data, for instance.
"The patient should have access to their health data and should very easily be able to say who else they want to share it with," says Dr. Divya Dhar, CEO of Seratis.
“The fact that there is HIPAA means that a secure messaging service like ours is important,” Dhar said. “Without it, people would just use things like iMessage and Android SMS.” On the other hand, she says, HIPAA can hinder innovation. “Because data gets locked in, you are unable to use it for the big data analytics piece,” she said. “Even if a patient came to you and wanted to share that data, you would have to go through several hoops to make that happen. The patient should have access to their health data and should very easily be able to say who else they want to share it with.”
Dhar said her company had to hire attorneys to make sure its solution complied with HIPAA policies when providers put it in place. “The policy piece is hard to decipher on your own, and we worked with a very good firm, but obviously that is extremely expensive.” App developers say the law should be written so people can implement it without having to hire lawyers to understand its basic elements.
In fact, one startup, Atlas Health in Nashville, Tenn., has built its business model around helping other startups meet HIPAA requirements. “The company’s founding was inspired by my own experience as an independent software developer working for small health-care organizations — people with ideas for the next big mobile health app,” said Philip Misiowiec, president of Atlas Health. “I realized areas of HIPAA are really murky. You have to spend a lot of time digging through it. It is like reading an encyclopedia.” There are high-end consulting groups that can solve HIPAA woes, but they are expensive, he said. “A two-person company developing a mobile app doesn’t have that kind of money, so that is where we come in.”
Misiowiec said he has made several recommendations to the federal Office of the National Coordinator for Health IT (ONC). “First, they should develop a simplified guide that says here is how HIPAA applies to you, the possible use cases and what you need to do — with specific guidelines, including bringing what NIST recommends into that same document.” Second, he said, the ONC should create and maintain an online community for developers to share information. “If you look at the developer community, there are a lot of great resources like Stack Exchange,” said Misiowiec. “Just having a resource to post questions would be helpful.”
Morgan Reed, executive director of ACT, the App Association, which represents approximately 5,000 app companies and IT firms, said there is a huge disparity in the quality of user experience in the applications available in health care and in other sectors of the economy. “It’s not as though there are no good ideas out there, but health care is often where good ideas go to die,” he said. At least part of the reason involves regulatory barriers people face when developing apps in this space.
"It’s not as though there are no good ideas out there," says Morgan Reed, executive director of ACT, the App Association, "but health care is often where good ideas go to die."
“If you are merely using a cloud service as a waypoint as data moves on to a care team and it is end-to-end encrypted, why require business associate agreements?” Reed asked. “If every single waypoint has to have a business associate agreement, that is going to slow down the ability to move forward on some of these technologies, especially in one key area: the quantified health solutions such as Apple’s HealthKit and Fitbit, as those products start being more useful.”
Another problem app developers face is outdated documentation on HHS websites. For programmers, examples are key to how they learn and build their business model, Reed said. But if the examples given predate the iPhone and only reference BlackBerry, then that leads to uncertainty. “The examples are so out of date that you can’t make a coherent case to your venture capitalists or investors,” he added.
Some analysts and consultants argue that the language of HIPAA security rules is ambiguous by design to put the burden of determining what compliance means on the regulated organizations themselves, based on their own structures, size and budgets. They say companies should be careful about demanding that HHS provide more specificity, because they may not like the more rigid framework drawn up in response.
Reed said the industry is glad that HHS takes a technology-neutral approach to HIPAA, and he admits that the ONC and HHS’ Office for Civil Rights are in a difficult position of trying to ensure the privacy and security of data on one hand and accessibility and flow of data on the other. “They are absolutely trying to figure out how to take advantage of this enormous explosion of mobile health apps that can change patient outcomes,” he said. “They have to figure out how they can restructure documents that are going on 10 years old to reflect high-speed Internet, mobile devices and wearables, and it is all coming at them now, and not just on the patient side, but on the physician side as well.”
ACT recently sent a letter to U.S. Rep. Tom Marino, R-Pa., asking Congress to push HHS to make changes to HIPAA. Among its suggestions are that “HHS should provide HIPAA information in a manner that is accessible and useful to the community who needs it. The agency should draft new FAQs that directly address mobile developer concerns.” It also asks that the Office for Civil Rights improve and update guidance on acceptable implementations. “Given that HIPAA is a federal statute that mandates several requirements, OCR should provide implementation standards — or examples of standard implementations that would not trigger an enforcement action — instead of leaving app makers to learn about these through an audit,” the letter said.
Calls for Change at the FDA
If grumbling about HIPAA compliance is commonplace, the complaints about the FDA approval process are much louder and insistent. Facing a growing number of applications that move data (and sometimes care recommendations) between devices, providers’ electronic health records and patients’ mobile devices, the FDA has sought to understand which ones pose a potential patient safety risk and require a formal approval process. So far, the FDA is taking a fairly hands-off approach and requiring approval for few types of applications while it learns more about the burgeoning market. But that ambiguity is tough on entrepreneurs seeking venture capital funding.“I know developers who have opted to go into other things rather than mobile apps they think would be subject to FDA approval now or in the future,” said Joel White, executive director of the Health IT Now Coalition, which represents patient groups, provider organizations, employers and payers. “And I know companies that are building regulatory risk premiums into their product development, which would make them more expensive,” he added. “Either the products don’t get developed or they are more expensive. Either way, it is not a good situation, which is why we want more clarity so we can have an environment that promotes innovation.”
“There should be greater certainty about which technologies will be regulated, by whom and to which standards,” said Mike Marchlik, vice president of quality assurance and regulatory affairs for health IT company McKesson, in an email interview. “The current model of using the 40-year-old device definition and statute to govern modern health IT creates significant uncertainty, subjects health IT regulation to the changing political landscape, and therefore has the potential to stifle innovation.”
He noted that lawmakers have been working with health-care stakeholders and patient and provider organizations to define categories that ensure patient safety, foster regulatory certainty and promote innovation. Last year legislation was introduced in both houses of Congress that would create three definitions of health-related software: “medical software,” “clinical software” and “health software.” Only medical software would be subject to regulation by the FDA.
In response, the FDA, working with ONC and the FCC, issued a lengthy draft report (the FDASIA Health IT Report) that recommends a similar three-bucket regulatory risk-based framework, but doesn’t set the categories in stone and leaves some questions unanswered, critics say. (The report also calls for the creation of a Health IT Safety Center to study issues related to patient safety.)
A fundamental tension has developed between the FDA on one hand and software companies and some members of Congress on the other, explained Bradley Merrill Thompson, general counsel of the mHealth Regulatory Coalition. “Members of Congress want to lock the definitions and process in, and FDA is saying we don’t know enough to draw those lines with enough certainty that a year from now we won’t need to revisit them,” he said. “FDA is saying you need to leave us flexibility about what causes harm and allow us to be flexible in how we apply the rules. Innovators are saying we don’t know whether our product will be regulated or not and investors need to know. There has to be some compromise between those positions.”
"If you actually drop the pins in the sandbox on regulatory guidance and pour concrete around those pins in an embryonic and evolving market, you might do a disservice to the market," says Anand Iyer, chief data science officer at WellDoc.
One technology executive who believes the FDA’s approach is the correct one is Anand Iyer, chief data science officer at disease management software company WellDoc, based in Baltimore. His company received FDA approval for its “mobile prescription therapy” software more than five years ago. The company’s BlueStar platform is used to help diabetes patients adhere to physicians’ treatment recommendations.
Iyer said the FDA was wise to develop an approach called “enforcement discretion,” which leaves it to the manufacturer to conduct a risk analysis and assure stakeholders that it has followed good manufacturing processes and that it doesn’t believe its product is going to create any residual risk to a patient.
“I think this was helpful,” Iyer said. “It offers flexibility. Truthfully it is too early to be more prescriptive. If you actually drop the pins in the sandbox on regulatory guidance and pour concrete around those pins in an embryonic and evolving market, you might do a disservice to the market. You might constrain it in ways that could be completely wrong.”
Iyer said WellDoc solved issues with the FDA through informal dialog. There is a formal process called 513(g) that companies can use to go on record to officially ask the FDA for its perspective and feedback on something. “We have not done that yet,” Iyer said. “We were fortunate to be part of many public-private, open-forum discussions with the FDA. These were open things we would just discuss and debate,” he said. “They also have held summits with the FDA, NIH, FTC, National Science Foundation and others to create a cross-governmental perspective on mobile health applications as it relates to regulation, risk and patient safety.”
Yet others still see much room for improvement. The FDA’s approval process is badly in need of repair on a couple of different levels, said Thompson. One is the threshold question of defining with precision what it does and does not regulate. “We have been asking since 2011, over three years, to publish a guidance document defining the portion of clinical decision support software that they intend to regulate,” he said.
In the FDASIA Health IT Report, the FDA said it would figure out later what to do about clinical decision support, according to Health IT Now’s White. “Later is now for companies like IBM trying to put products based on Watson on the market that link people with clinical trials using clinical decision support,” he said.
Another unanswered question relates to accessories and connected health. “The old rule was that if something connects to or plugs into a medical device, it is a medical device regulated in the same manner,” Thompson said. “Well, now everything is connected to everything else in a network, so that rule doesn’t make sense anymore. We are scratching our heads trying to figure out where medical devices stop and start. FDA promised us guidance on that, and it is not out yet.”
The FDA also could be nimbler in response to developer requests, suggested Reed. “We have been forthright and aggressive with the FDA about some of the timelines to get through the 510(k) or the 513(g) process. [A 510(k) is a notice of intent to market a medical device.]
The idea that you have to wait for 100 days to hear back on something is not reasonable.” The developer community says that even an answer of “no” is better than no answer at all. “Then at least they know how to begin to address the problem or do something differently,” Reed said. “It is the nonexistent answer that kills.”
Speaking at a conference symposium last February, FDA senior policy adviser Bakul Patel told the audience that in 80 percent of the cases, the agency had met the statutory 90-day timeframe under the 510(k) process, according to a report in Health Data Management.
Patel described the oversight as focused on a small subset of apps that present the greatest risk to patients, while the vast majority of apps do not require active FDA oversight because they do not meet the definition of a medical device under the federal Food, Drug and Cosmetic Act, the report said.
By its definition, digital health is at the nexus of clinical innovation, behavioral science innovation, pharmaceutical innovation, and consumer electronics and gadget innovation, WellDoc’s Iyer said. That requires a complementary structure of policy and regulation and data security and privacy. He said you could imagine that complicated picture in one of two ways: One is a shoelace that has 16 tangled knots in it. The other is the intersection of freeways 405 and 10 in Los Angeles — chaotic but well structured. Every onramp and offramp has a purpose.
“That is the future you want to invoke: well structured, highly complex, with lots of moving parts, but it works,” Iyer said. “This is the mother of all freeway interchanges, and I think the traffic is starting to flow. People were reticent to get on the onramp, but now you see more people getting on.”
