Policies regarding HIPAA will not change. The language in the first announcement implies that government will simply communicate the existing policies to startups better. I see that as having little to no effect.

The fact is that HIPAA is wide in scope and open to interpretation. Consider some areas that HIPAA covers: encryption of data, monitoring and logging who has access to systems that contain information, monitoring and logging of support personnel, password and access control, monitoring of systems and servers for illegal/unauthorized access, training of personnel in regards to PHI. There are simply too many aspects of HIPAA for start-ups to manage. I believe that communicating HIPAA’s implications to startups will largely help most start-ups conclude that they don’t want to be in healthcare.

Most startups today contain costs via The Cloud, buying only the IT services that they utilize. Early on, when there are few customers, IT spending is low. As customer acquisition ramps up, more services can be purchased as needed. It is very easy to expand using The Cloud, keeping costs proportional to need. Amazon Web Services and Google Cloud, among others, make this possible.

However, the September 2013 update to HIPAA included a provision that made it clear that any business that touches private healthcare information (PHI), such as ISPs and SaaS providers (Amazon, Google, etc), must be covered under a Business Associates Agreement (BAA). Having an ISP sign a BAA is a big deal. Many ISPs made announcements shortly after Sept 2013 proclaiming their support for BAAs. However, the reality is that the barriers to having a BAA signed are quite high. Some examples:

The cost of a single server on Amazon increases by about one hundred times. Amazon will only sign a BAA if a server is run on a “dedicated” instance, which means dedicated hardware.

Google is somewhat vague on their support of BAAs. According to the representative I spoke with, a company must first develop their application on Google infrastructure and then Google will inspect it to make a determination of whether it is worthy of a BAA.

I found Microsoft’s story to be quite amusing. They declare that SQL Server, their own database product, is not HIPAA compliant and will not sign a BAA for an app that uses SQL Server in the Azure cloud environment.

The FDA’s declaration that they will not regulate “general wellness” apps as medical devices is helpful to start-ups. Consider that many start-ups use iterative development processes, such as Scrum. The FDA frowns on such methodologies, favoring the waterfall method, for medical devices. With the FDA’s announcement, iterative development may now be used for apps in the general wellness space. Benefits of iterative techniques are faster releases leading to more innovation via more frequent user feedback.

However, start-ups should not take the FDA’s announcement to mean that quality standards can be relaxed. Quality processes are still needed, regardless of the type of app.

There are some other key benefits too. The process to gain FDA clearance can be quite lengthy. The process is not always consistent and can vary by the representative(s) assigned to the product. Eliminating delays and uncertainty are important when releasing a product.

However, what I find most helpful is the cost savings. Because the process can be complex, especially to the first-timer, the need for expensive regulatory consultants is eliminated.

The recent announcements that ease healthcare product development for start-ups is a mixed bag. There are some benefits to newbies in the space. However, there are certain minimum standards that must be met by start-ups, particularly in terms of PHI. And quality can not be sacrificed regardless of FDA’s decision to not regulate wellness apps as medical devices.