The majority of what's been posted on this question as it relates to what HIPAA is and isn't, is incorrect (I won't comment on the EULA issues). As has been suggested, please contact a healthcare attorney, or a security consultant who has worked with HIPAA before acting on any advice posted here. The attorney can help you with what HIPAA is, but they probably won't be able to help much with the details of the HIPAA EDI and security regulations.
To clear some things up though (and I am a security consultant who has been working with HIPAA for 2 years and have performed over 50 HIPAA security assessments in the last 19 months):
1. HIPAA is a law, not a person, or gov't group; it stands for the Health Insurance Portability and Accountability Act of 1996; there were multiple provisions to HIPAA, but what this topic is dealing with is the Administrative Simplification provision, which has three parts: EDI (transactions and code sets), privacy, and security; these three parts have been implemented by the Dept of Health and Human Services as federal regulations; the compliance date for the EDI regulations is Oct 2002, however covered entities can file a one year extension (for EDI compliance only), that doesn't require a complete inventory of all HW/SW; the compliance date for the privacy regulations is Apr 14, 2003; the security regulations are not finalized yet, but when they are, the compliance date will be 2 years from when they become final (however, the privacy regulations pretty much imply that you should comply with the security regulations by 4-14-03 also); business entities required to comply with HIPAA are: all health plans (health insurance companies), all health care clearinghouses, and those health care providers who perform at least one standard health care transaction (as defined in the EDI regulations) in an electronic manner
2. The only SW that can really be deemed to be HIPAA-compliant or not will be applications used to perform the health care transactions defined in the EDI regulations, if done in an electronic manner; any HW, OS or other SW in use not dealing with these transactions will have to be evaluated to ensure that it has security features required by the security regulations (and only really, really old SW and HW won't have these features - ie. DOS-based SW that doesn't implement IDs and passwords)
3. The Proposed HIPAA Security Regulations were published in Oct 98; they are technology-neutral and define well-accepted security controls (technical and non-technical) that should be implemented in a "reasonable" manner to secure information that is determined to be PHI (Protected Health Information - this term is specifically defined in the privacy regulations); basically PHI is medical or financial information about a patient that is stored or transmitted electronically by a HIPAA covered entity
4. The Proposed HIPAA Security Regulations are not in disarray, but define security controls (with required features) in a general, but usable way (if you understand security) so that what is required can be implemented today, without waiting for the final regulations (with the possible exception of the Electronic Signature Standard, which is really a separate regulation, but gets lumped in with the security regulations); the final HIPAA security regulations should NOT be too different from the proposed ones, but may have some clarifications and more specific technical requirements (ie. encryption algorithms, key length)
5. The HIPAA security regulations are 70% policies and procedures and 30% technology; the documented policies required cover information, physical and personnel security in a pretty thorough manner
6. The technical security requirements of the HIPAA security regulations involve the following areas, with some specifics given in the regulations:
a. access controls (system and network)
b. audit controls (system and network)
c. data authentication
d. entity authentication
e. integrity controls during communication
f. message authentication during communication
g. encryption during communication
h. other network controls including:
- alarms, audit trails, event reporting
7. These technical security controls are vaguely defined, but can be implemented if you have a thorough understanding of information security and the security features of the HW/SW in use; they can be implemented now because the regulations do state that a covered entity can determine what is reasonable, as long as they cover what is required
8. The HIPAA Privacy Regulations will be enforced by the Office of Civil Rights (OCR), and will entail complaints being filed with the OCR on suspected compliance violations; there will be no gov't auditing done (from what the lawyers I work with tell me, and they also work with HHS - Health and Human Services - so they should know); the enforcement of the security regulations isn't clear right now, which hopefully will be addressed in the final regulations (it may also be OCR); enforcement of the EDI regulations isn't necessary, because if you don't comply, you basically can't stay in business; non-compliance with the EDI regulations will prevent you from performing the standard health care transactions with insurance companies and/or clearinghouses, which is why you couldn't stay in business, unless you don't accept insurance (if you don't do the standard transactions electronically, you aren't required to comply with HIPAA)
9. You (a HIPAA covered entity) are NOT required to ensure that your business associates comply with HIPAA (your business associates may not be HIPAA covered entities and therefore wouldn't be required to comply with HIPAA); you WILL be required to have a business associate agreement (HIPAA-specific legal verbage added to contracts) with entities determined to be HIPAA-defined business associates (this term is also specifically defined in the privacy regulations)
Hopefully that covers most of the misinformation posted here.
Slashdot Mirror
The majority of what's been posted on this question as it relates to what HIPAA is and isn't, is incorrect (I won't comment on the EULA issues). As has been suggested, please contact a healthcare attorney, or a security consultant who has worked with HIPAA before acting on any advice posted here. The attorney can help you with what HIPAA is, but they probably won't be able to help much with the details of the HIPAA EDI and security regulations.
To clear some things up though (and I am a security consultant who has been working with HIPAA for 2 years and have performed over 50 HIPAA security assessments in the last 19 months):
1. HIPAA is a law, not a person, or gov't group; it stands for the Health Insurance Portability and Accountability Act of 1996; there were multiple provisions to HIPAA, but what this topic is dealing with is the Administrative Simplification provision, which has three parts: EDI (transactions and code sets), privacy, and security; these three parts have been implemented by the Dept of Health and Human Services as federal regulations; the compliance date for the EDI regulations is Oct 2002, however covered entities can file a one year extension (for EDI compliance only), that doesn't require a complete inventory of all HW/SW; the compliance date for the privacy regulations is Apr 14, 2003; the security regulations are not finalized yet, but when they are, the compliance date will be 2 years from when they become final (however, the privacy regulations pretty much imply that you should comply with the security regulations by 4-14-03 also); business entities required to comply with HIPAA are: all health plans (health insurance companies), all health care clearinghouses, and those health care providers who perform at least one standard health care transaction (as defined in the EDI regulations) in an electronic manner
2. The only SW that can really be deemed to be HIPAA-compliant or not will be applications used to perform the health care transactions defined in the EDI regulations, if done in an electronic manner; any HW, OS or other SW in use not dealing with these transactions will have to be evaluated to ensure that it has security features required by the security regulations (and only really, really old SW and HW won't have these features - ie. DOS-based SW that doesn't implement IDs and passwords)
3. The Proposed HIPAA Security Regulations were published in Oct 98; they are technology-neutral and define well-accepted security controls (technical and non-technical) that should be implemented in a "reasonable" manner to secure information that is determined to be PHI (Protected Health Information - this term is specifically defined in the privacy regulations); basically PHI is medical or financial information about a patient that is stored or transmitted electronically by a HIPAA covered entity
4. The Proposed HIPAA Security Regulations are not in disarray, but define security controls (with required features) in a general, but usable way (if you understand security) so that what is required can be implemented today, without waiting for the final regulations (with the possible exception of the Electronic Signature Standard, which is really a separate regulation, but gets lumped in with the security regulations); the final HIPAA security regulations should NOT be too different from the proposed ones, but may have some clarifications and more specific technical requirements (ie. encryption algorithms, key length)
5. The HIPAA security regulations are 70% policies and procedures and 30% technology; the documented policies required cover information, physical and personnel security in a pretty thorough manner
6. The technical security requirements of the HIPAA security regulations involve the following areas, with some specifics given in the regulations:
a. access controls (system and network)
b. audit controls (system and network)
c. data authentication
d. entity authentication
e. integrity controls during communication
f. message authentication during communication
g. encryption during communication
h. other network controls including:
- alarms, audit trails, event reporting
7. These technical security controls are vaguely defined, but can be implemented if you have a thorough understanding of information security and the security features of the HW/SW in use; they can be implemented now because the regulations do state that a covered entity can determine what is reasonable, as long as they cover what is required
8. The HIPAA Privacy Regulations will be enforced by the Office of Civil Rights (OCR), and will entail complaints being filed with the OCR on suspected compliance violations; there will be no gov't auditing done (from what the lawyers I work with tell me, and they also work with HHS - Health and Human Services - so they should know); the enforcement of the security regulations isn't clear right now, which hopefully will be addressed in the final regulations (it may also be OCR); enforcement of the EDI regulations isn't necessary, because if you don't comply, you basically can't stay in business; non-compliance with the EDI regulations will prevent you from performing the standard health care transactions with insurance companies and/or clearinghouses, which is why you couldn't stay in business, unless you don't accept insurance (if you don't do the standard transactions electronically, you aren't required to comply with HIPAA)
9. You (a HIPAA covered entity) are NOT required to ensure that your business associates comply with HIPAA (your business associates may not be HIPAA covered entities and therefore wouldn't be required to comply with HIPAA); you WILL be required to have a business associate agreement (HIPAA-specific legal verbage added to contracts) with entities determined to be HIPAA-defined business associates (this term is also specifically defined in the privacy regulations)
Hopefully that covers most of the misinformation posted here.
Enjoy!