See the comments about Schneier's new book http://news.ycombinator.com/item?id=1113641

Given that you are using a tool stack that, well, has historically had a large number of security issues and that is difficult to get clarity on be cautious.

It is possible to build capable and relatively secure systems using php but it takes a correspondingly greater effort to do so. You will want to pay special attention to the global php settings (if you turn on register_globals even in development you deserve to get sued for malpractice) and you will want to understand the different layers of encryption that support your application. You also need to engineer your applications workflow with an eye towards separating out different kinds of access. A patient filling out a form should not be able to access any other patient records. A doctor or clinical assistant should be able to view only those records their role requires; any patient record access should be recorded in an audit log that is not accessible to any user directly.

Also, drop mysql for postgres; php support for postgres is very good and postgres supports in database public key encryption which you will want.

Can you expand on the postgres public key encryption - is this a function that encrypts/decrypts based on some files on the server (or in a database column)?

pgcrypto is a set of extension functions that are available from within PL/SQL

http://www.postgresql.org/docs/current/static/pgcrypto.html

You do need to understand what the functions are doing and it doesn't handle key management for you.

HTTPS. Firewall that prevents outside network access to servers with HIPPA data. Encryption of data in the db (eg, don't store plaintext social security numbers in a table). All backups are encrypted. Files with PII (patient identifying information) are encrypted. Data access strictly limited to small set of people.

Now that I've blown a bunch of stuff at you, I'll say that my experience is that most of HIPPA (and IRB study stuff, even stricter) is about defining and implementing a coherent policy to minimize risk. It is a colossal pain - where I work, we do medical research and integrate with actual clinical data collected from the hospital. It's not uncommon to find clinical staff keeping excel or word docs full of patient data on non-secured systems. Minimize the places where you get data from people so that you don't have to be accountable for those things - in other words, try not to have people emailing you excel sheets in the clear. We're putting https web apps in front of people to load data that way (parsing files on the fly) and not storing the files at all - during the parsing, we'll put the data into our backend and encrypt that data in our Oracle db. We're wrangling with key management right now - we want to load data automatically, but to not store keys in the db or on the OS in a way that would be easily accessed if the db server was literally loaded onto a truck and taken away.

I'm not a MySQL experienced person, but I'm sure it probably has something similar. You're right to be cautious - I've seen estimates that notifying people when data is leaked and handling the cleanup (providing credit monitoring, etc) is huge, $3K to $5K per client.

This is what I was afraid of. The company I work for has never had to handle this sort of data before, and were VERY close to just dropping all the client info into a standard, non-encrypted database.

Thanks for your insight. I have a feeling we may hand this project off to someone that is experienced with HIPAA development so nobody gets screwed.

I am a programmer/analyst in a hospital. I administer several systems and have my hands in most of the databases. Outside of work, I consult and write healthcare software.

You store it the same as you would any sensitive information -- behind a locked door with a ridiculous amount of audit data. It's more about identifying improper access (nurse A looking at patient B when she's not in his "circle of care") than it is about preventing it, for legitimate users of course.

You do not need to encrypt the contents of the database or any such extreme measures.

Something else to remember is that there is no bulletproof "HIPAA-Compliant" stamp. It's more a set of guidelines and best practices that you're trying to follow. Most vendors do not provide a row-by-row audit table for every single action, for example, but they should.

Interesting - our hospital written policy is that SSNs must be encrypted when stored. Other PII is somewhat less restrictive.

But, we had a high-profile case where a server with a file of SSNs and patient names was hacked. There was no evidence the person(s) who hacked the server ever knew this particular file existed, but it generated a bunch of headaches here. Maybe policy makers went off the deep end in response.

HIPAA compliance is no joke.

Take a look at documentation provided by the Joint Commission (JCAHO) which certifies hospitals and CCHIT for generalized standards (no one ring to bind them all in terms of compliance for software), also HIPAA.org.

You may want to review the CMS HIPAA checklist (http://www.cms.gov/hipaa/).

As a best practice, I've seen basic "PHI" or personal health information (identifying info like name, Bday, sex, SSN) encrypted, but this is not 'required.' Some programmers/sites go further and encrypt everything, as stated by others below.

Careful with the email transmission; various legal concerns (and some regulatory standard interpretations) mean most 'sites' keep this info on LANs or HISs or perhaps on web hosted sites.

Take a look at Kaiser's KPConnect PHR portal, which is powered by Epic, as an example. You can dig up plenty of stuff about that system on Google.

Generic presentation of concerns, but worth a quick skimming: http://npag.org/NPAG_images/NPAG%20Health%20IT%20Prez-Kenned...

For nifty open source stuff, check out popHealth (by Mitre), OMHE (for mobile) and hData (XML).

http://code.google.com/p/omhe/

http://www.projecthdata.org/

http://projectpophealth.org/

You might want to look into data blinding, stronger/stricter permissions, and even audit tables (if data changes, insert a duplicate of the row into a separate audit table).

However as long as you have it internally set up (not on the Internet) and make encrypted backups (so stolen backups are worthless) your risk will be much less.

I was reading through the HIPAA guidelines and it mentioned something about auditing almost everything that happens on the system. Is that standard practice when doing HIPAA development?

I have a degree in Medical Record Administration and one of my past positions was Manager of Medical Records and Privacy Officer for a hospital. The Office of Civil Rights enforces the HIPAA Privacy and Security Rules. You can check out their HIPAA website at http://www.hhs.gov/ocr/privacy/ You can also review the Security Rule which sets forth guidelines for protecting electronic data. This can be found on http://www.hhs.gov/ocr/privacy/hipaa/administrative/security... - click on "Security Rule Standards - Final Rule" under Security Rule History. It's a pain to read because it's written by the government, but it may have the info you need.

As a sub-topic, if I were to catch some form data, write it to a file, compress and encrypt the file (password/key protected) and then email it to a health provider, is that viable alternative to actually storing information?

Of course, the temporary files would be deleted immediately.

You can also find sample security rule compliance policies that different organizations have created. For example, University of California has theirs at http://www.universityofcalifornia.edu/hipaa/docs/security_gu...

You might want to look at some open source software like Open Clinica:

http://www.openclinica.org/page.php?pid=97