That said, we treat our data as if it were PHI. We have a Business Associates Agreement signed with AWS, and take all of the precautions they require for an app that would claim it is HIPAA compliant. Technically, we could claim that we are HIPAA compliant, as we don't store PHI. But we didn't want to say that just for the sake of saying that.

The bigger question, in my mind, is about whether or not a situation would arise as you mention. The FDA recently provided a little more clarity on some of this (http://mobihealthnews.com/39775/fda-clarifies-the-line-betwe...). Specifically, Pacifica seems to fall outside regulation as it "Claims to promote relaxation or manage stress when there is no reference to anxiety disorders or other reference to a disease or condition." We try to be pretty careful about the language that we use. We don't mention things like Generalized Anxiety Disorder, Panic Disorder, OCD, etc.

The truth is that it still seems like a grey area. That same article mentions that we should not claim that we treat anxiety if we want to stay unregulated. I think that we're on the fence here. In the future, we will go after FDA clearance in any case. We just need the means to do so.

Disclaimer: I am not a lawyer, I am not your lawyer, and this is not legal advice.

There's a lot more to being HIPAA compliant than how you store PHI. As an engineer, you might view not storing PHI as compliance-by-default (the null case), but I don't think a lawyer would agree. Even if you're correct and HIPAA doesn't apply to you (which I'm not convinced is the case), it'd be like saying "we're PCI-compliant, because we don't store any financial information or process any financial transactions".

For what it's worth, I founded a company that does store PHI, and we had to get a BAA with AWS (though we ended up using Aptible (YC S14)[0] for hosting and compliance, as it's much easier. Using Aptible is like using Heroku (git push to deploy), and they manage not just the data backups/retention/etc. from a technical standpoint, but all of the human training and paperwork aspects to compliance[1].

[0] https://www.aptible.com/

[1] Which, to be honest, is the tough stuff. From a technological perspective, HIPAA doesn't really mandate much that developers of robust applications shouldn't already be doing, but it's the matter of actually demonstrating that you've done everything in compliance with the law that makes things complicated. Having the 'rubber stamp' of a third-party company that specializes in this matter gives immense peace-of-mind as the CTO, compared to the DIY approach.

We open-sourced our HIPAA policies where I work at Catalyze recently. Check 'em out and good luck! http://catalyzeio.github.io/policies/

o_O

I am not your lawyer, and this is not legal advice, but I strongly suggest you talk to an attorney who is experienced with the FDA's regulatory approach right now.

Claims that a product helps treat anxiety are regulated. Claims that a product is based on CBT (or any therapy) are even stronger warning signs.

This does not look like a grey area to me at all.

We really are trying to do right by the FDA. We'll go through the process to get Class I clearance as soon as we have the resources to do so. Until then, we really are not trying to make claims about treating specific disorders.

As for being based on CBT, I have not seen anything that specifically addresses that type of claim. Put another way, we're trying to help people understand the cycle between thoughts, behaviors, and feelings. To us, that's the core of CBT.

"We're carefully avoiding anything that might make us comply with regulations that could potentially get in the way of our harvesting of your thoughts and mental health status"

To repeat : the privacy policy and "about" sections need a lot of work considering the nature of this app.

For what it's worth until we can do that, here's a quick rundown: all data is transmitted over https. While we use Elastic Load Balancers we don't terminate SSL at the load balancer so data makes to our web servers before being decrypted. Any audio recordings are stored encrypted in S3, and our RDS instances are also encrypted. Everything runs in a Virtual Private Cloud. Each service (ELB, EC2 instances, RDS, S3) runs in its own security group with IAM user roles that can be removed and reissued if needed.

We'll try to get this information up on the site fairly soon.

This sounds perfectly honest, and I appreciate you acknowledging that.

I wonder if some of the information shared through the app would start to become "medical history". If you're being careful about your language to avoid clinical terms, but the substance of what your users are sharing is mental health related, I wonder if someone could make a case that you are actually collecting a medical history. But IANAL, so I don't know how that would play out.

Personally, I am not a fan of a general statement like "don't collect any data". As a patient, I am totally ok if a system collects data ON me BUT never ABOUT me. In another words, the data should in no way be identifiable. That way, we continue to make progress while maintaining privacy.

A previous version of that scheme, run under different rules, saw anonymous patient data being sold to insurance companies. (It's now a criminal offence to sell off the data.)

That stupid decision has led to delays.

http://www.bbc.co.uk/news/health-26253440

http://www.bbc.co.uk/news/health-26239532

http://www.bbc.co.uk/news/health-26347026

http://www.bbc.co.uk/news/health-25919399

etc etc.