Show HN: TrueVault (YC W14) SDK for iOS – HIPAA compliance made easy for iOS apps
go.truevault.com
go.truevault.com
These things are organizational behavior. I don't understand how you can claim to sell this as a SaaS solution.
Administrative Safeguards = basically encompasses what you described. Technical Safeguards = encryption, authentication, authorization, audit control, etc. Physical Safeguards = media (e.g., HD) disposal/reuse, data backup/restore, access control and validation procedures, etc.
TrueVault handles Technical and Physical Safeguards. Companies like AccountableHQ.com does a great job taking care of Administrative Safeguards for their customers.
Check out the Developers Guide to HIPAA Compliance here: https://github.com/truevault/hipaa-compliance-developers-gui...
The Access Control requirements: Everyone should have an individual user account protected by some kind of authentication, limited to the permissions its user actually needs, and should log off (and/or be automatically logged off) when they're not actively using that account.
Duh? Every multiuser system designed by a remotely competent solo developer does this. Your local Starbucks's POS implements this. So does my small-town public library. And Wikipedia.
Transmission integrity: as far as I know, you have to explicitly go out of your way to not get this for free from TCP. If you're using HTTPS, even better.
Audit controls: Wikipedia seems to nail this one, since Mediawiki is built around versioned storage with nice visualizations of diffs and reporting on changes. Even without considering security, the natural paradigm for a clinical EHR system is read-and-append-only since you are documenting interactions and the past doesn't change. (Sure, mistakes happen, but that's probably worth acknowledging with an explicit correction.) Otherwise, what's so hard about throwing in a logger.log() describing what's happening when a user does something interesting?
I've skipped encryption, but encryption is "addressable" so you don't have to encrypt anything if it would be too difficult. (So long as you document that choice.) Use HTTPs where feasible, like you should be doing anyway? Encryption of database servers doesn't make much sense since they key would be in memory all the time anyway, but maybe pick "encrypted LLVM" when you install the OS? And that's the technical safeguards.
The guide claims that my line of thinking is a trap people fall into, but you don't making a compelling case as to why the technical safeguards are too hard to do yourself or even a burden.
HIPAA isn't talking about static analysis, formal verification, vulnerability research, strong cryptography, hardened kernels, airgaps, side channels, timing attacks, HSMs, 2-factor authentication, etc. It isn't about secure code, nor any of the interesting/"real" security that HN likes to talk about. A HIPAA security audit is a checklist and a very expensive Nessus scan. This isn't Bruce Schneier-level stuff. I'd be surprised if any HIPAA violation was even interesting enough for DEFCON. HIPAA isn't like the FIPS rules. On the technical/software side, it's more like an idiot-check. At least, that was my conclusion after doing a bunch of research for one of my employers.
If I were running a business involving PHI, the thing I'd want most is a lawyer to tell me what I actually need to change based on what the law actually is. It doesn't really seem like help is necessary to implement the technical safeguards.