The following sections were UPDATED on 12/21/00:

Administrative Requirements


Is your HIPAA question not answered below?? Get it answered by posting a question to our discussion board!
 

1. What is HIPAA? 34. Security vs. Privacy vs. 
Compliance Officer
2. HIPAA Compliance & Compliance Dates 35. HIPAA Return On Investment (ROI)
3. Faxing 36. Electronic Records
4. Transfer of Medical Records 37. Password Management
5. Entity Authentication 38. Paper vs. Electronic Transmissions
6. Chain of Trust/Business 
Partner Agreements
39. Employer or Covered Entity
7. FDA National Drug Codes (NDC) 
Vs. Proposed Standards
40. Healthcare Information Confidentiality Act of 1999
8. PC Anywhere 41. Role of the Clearinghouse
9. Electronic System of Record 
Keeping
42. Electronic Transactions
10. Authorizing Sharing of 
Passwords
43. Retail Drugs and the Internet
11. HIPAA Security Certification 44. Hospital Websites
12. Digital Receipts 45. ID Cards
13. Patient Sign In Sheets 46. Definition of Data Content Compliance
14. Encryption 47. Patient Satisfaction Surveys
15. Biometrics 48. Contingency Plans
16. HHS Authority 49. JCAHO Audits and HIPAA
17. Telephone Notification 
Systems
50. Paper Claims
18. Mobile Computing 
(Palm Pilots, Laptops…)
51. HIPAA Compliance - Who Is Covered
19. HCFA Internet Policies 52. Compliance - Insurance Industry Actions
20. HIPAA Security 53. Order Status Updates
21. HIPAA Security Regulations  - 
Who/What is Covered
54. Implementation of Security Standards
22. Immunization Records - 
Who/What is Covered
55. Digital Certificates
23. Use of US Mail - 
Who/What is Covered
56. Data Elements
24. Insurance Company Efforts 
for new EDC
57. Scanning and Record Retention
25. Transaction and Code Sets 58. Transaction Final Regulations Corrections
26. Smart Cards 59. Overhead Paging
27. Where to Find HIPAA Rules 60. Final Regulations Download
28. State Law Vs. HIPAA 61. Remote Access
29. Electronic Signatures 62. IT Vendor Contracts
30. HIPAA Enforcement 63. Answering Services
31. E-Mail 64. Wireless Communication
32. HIPAA Compliant Software/Hardware 65. Minimum Compliance vs. Plan for the Future
33. Audit Trails

1. What exactly is HIPAA?
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) was signed by President Clinton on August 21, 1996. The Act is designed to protect health insurance coverage for workers and their families when they change or lose their jobs. Also known as the Kennedy-Kassebaum Bill, provisions of HIPAA intend to ensure patient confidentiality for all health care related information. The requirements of HIPAA apply to any entity storing and/or transmitting patient identifiable information on electronic media. This affects virtually all health care organizations from physicians and insurance companies to health care support organizations. HIPAA contains a crucial section called Administrative Simplification. Provisions of this section are intended to reduce the costs and administrative burdens of health care by making possible the standardized, electronic transmission of many administrative and financial transactions that are currently carried out manually on paper. Administrative Simplification includes sub-sections on the privacy and security of patient data that mandate standards in safeguards for physical storage & maintenance, transmission, and access to individual health information. Compliance with the provisions of Administrative Simplification will be required within the next three to four years and those entities that do not comply with these regulations will be subject to stiff civil and criminal penalties.

Where can I go to access the Privacy rules?
All the HIPAA rules can be downloaded from this site...
http://aspe.os.dhhs.gov/admnsimp/index.htm

TOP


2. HIPAA Compliance & Compliance Dates

I heard that the compliance time frame is dependent on the size of the organization? What size do you have to be to not be compliant in 2 years? 
The dates for compliance to HIPAA regulations are the same for any size provider. An additional year is given to small health plans, albeit I don't know of any health plans that fall into the definition of small (< $5M annual sales - which would be around than 3,000 covered lives). (Posted 10/11/00)

While speaking with a HIPAA coordinator in NJ, she mentioned that her state has been designated as early adopter state for the regulations. Has anyone heard of such a situation? This coordinator has indicated that NJ has only one year to comply with the regulations. 
The Secretary of DHHS would have to determine that the New Jersey law requiring earlier implementation of transactions was necessary before the New Jersey law could supercede the Transaction Regulations. With the exception of Privacy, essentially the Secretary of DHHS would have to agree to any State Law superceding any of the HIPAA Regulations. It appears that the New Jersey law for early adoption may not fit the definition of "contrary" nor be an "obstacle" to the intent of the HIPAA Act - therefore it is likely that it will hold up. This brings up the following question:
1) Could New Jersey practically enforce their early adoption law before the Federal compliance deadline would apply, or is it simply a safeguard in the event that the implementation dates are delayed? The HIPAA legislation states that all "HIPAA regulations", with the exception of Privacy, Public Health and Regulatory Reporting, supercede any contrary provisions of State law. While there is a provision for exceptions, the Secretary of HHS would have to determine that any exception would be necessary. See Sec. 1178 of the Act. (Posted 10/11/00)

Don't federal law and rulings prevail except if the state law and rulings are more stringent? 
More stringent State law can only supercede HIPAA Privacy regulations. See Sec. 1178 of the Act. All other HIPAA regulations supercede all State laws that are "contrary" or are an "obstacle" to the intent of the regulation. The key seems to be the definition and application of "contrary" and "obstacle". For a great article (in PDF format) on this subject by Tom Gilligan of AFEHCT, click here! (Posted 10/11/00)

Could someone please clarify the compliance dates for HIPAA in regards to the proposed Security and Privacy standards? I have noticed many different dates of suspected issuance of the final standards but nothing definitive and no one location to get the correct information.  Why should a healthcare provider should start looking and planning for having to implement and be compliant with the PROPOSED standards?
At this point effective dates for data security and privacy are up in the air. The latest word from the DHHS is the anticipated finalization date for the data security rule is fourth quarter 2000. The rule would then be effective two years from the date the rule is finalized. At this point no one is willing to hazard a guess as to when the privacy rules will be finalized.

Health plans, providers & clearinghouses should begin implementation efforts now. There are going to be very few changes in the Security NPRM and those will largely be definitional (e.g. definition of a small plan will be aligned with SBA's definition of small business, $5M or less in revenue) and clarifications (e.g. paper and oral covered if they are the source or progeny of an electronic record). The biggest change is the removal of Electronic Signature from the Security regulations and attaching it to another regulation later on (maybe an identifier standard). HIPAA represents good business practices and good stewardship. Many of the requirements of HIPAA reflect things we need to do to avoid legal & operational risk as well as live up to our fiduciary responsibility as caretakers of such information.

Even if HIPAA were set aside (which is not likely), the health care industry needs to improve the way it cares for information. This is becoming more and more critical as members/patients demand privacy protections, cyber crime increases and our use of web applications increase. The short answer is we don't have final effective dates for the data security or privacy rules but it is a good idea to begin the process of improving our information security practices for legal, operational & stewardship reasons.

When the Privacy Legislation is finalized, what is the expected compliance date? 
All the HIPAA regulations have the same compliance deadlines (2 years + 2 months)

Why should a health care provider start looking and planning for having to implement and be compliant with the PROPOSED standards before they are even finalized? 
Why waste 3 - 6 months waiting for a final regulation that will have very few changes (less than 3%), and most of those changes we are aware of and are minor. One of the things we should have learned from Y2K was the earlier we start, the longer we take, the better the outcome and less it costs. There are going to be very few changes in the Security NPRM, and those will largely be definitional (e.g., definition of a small plan will be aligned with SBA's definition of small business, $5M or less in revenue) and clarifications (e.g., paper and oral covered if they are the source or progeny of an electronic record). The biggest change is the removal of Electronic Signature from the Security regulations and attaching it to another regulation later on (maybe an identifier standard).

After two years of delays, the transactions and code sets rule--the first of the long-awaited and highly anticipated HIPAA final rules published in the Federal Register --ultimately could be revoked if the controversial privacy rule is snared in ongoing bureaucratic ranglings, which it has been for some time.....? 
I think the language in the preamble concerning the Privacy Regulations could simply represent a "shot across the bow" of Congress. HHS has maintained from the beginning that Privacy is better served through legislation - not regulation.

TOP


3. Faxing

My concern was more to the method of transmission, as opposed to the source of the information. In other words, if the information does indeed fall under the criteria set forth by the regulations, does that mean that the means of communication must encrypt the information that is passed on the line? Or that the location of the transmitting and receiving fax machines needs to be considered for privacy concerns? Is a privacy disclaimer on a cover sheet sufficient?
Yes, under the scenario you describe, faxes would be covered, encryption would not be required and a disclaimer alone may not suffice. The biggest issue with faxes is authentication of the receiving party. It may be a lot better in the long run to replace faxes with secure email. Of course, that means you have to have some means of securing the email and also ensuring it is only read by the receiver, which means some form of digital signature which invokes the aspect of non-repudiation and authenticating both the sender and the receiver, which leads us into some form of digital receipt.

I am unclear as to how the regs impact patient data that is faxed. Our hospital deals with a number of outside physicians, and the medical records dept. faxes a number of transcribed records to their offices. I am wondering how to classify these faxes, since the transcribed data is the output of an electronic system. Can anyone comment on this issue?
Any patient information that is the progeny of an electronic record is covered. The only time faxes are not covered is if the information faxed is neither derived from an electronic record nor has been the source for an electronic record. For example a fee slip that was the source for data entry would be covered. There is support to that position within the Security NPRM as well as the Privacy NPRM.The only pure mention of faxes in the security NPRM is on page 43245, second column that is a reference that excludes fax transmissions from electronic transmissions. That is a reference to the transmission mode itself, not to the information contained within the fax. It is in this context that fax transmission is excluded from the protections required on page 43255 which allude to requiring encryption on open networks, including dial-up lines. PLEASE NOTE: Encryption is not a requirement for closed networks, an entity is free to choose encryption OR access controls. Faxes are included in the definition of "Health Information" - see below. However, all of this must be looked at from the perspective of what DHHS intends. It has been DHHS's intent and position all along to protect the source and progeny of patient information stored electronically. They do not feel that it is reasonable to protect patient information stored electronically and NOT protect the source of that information or the progeny (paper, oral, etc.). I would fully expect the final security regulations to better clarify that position. This has been communicated in a number of presentations by DHHS (e.g. presentations made at WEDI, AFHECT and NMHCC). To further support that position is the comments in the Privacy Regulations that make it clear that DHHS believes that they have a solid foundation to cover paper and oral records as well as electronic. It is their position that it is inconceivable that congress intended that paper and oral communications would not be covered if the information were also maintained electronically.

Will a "Chain of Trust" agreement with a physician's office be enough to cover automatic remote faxing generated from a legacy system? How can I guarantee that the fax was received and secured by only the intended individual at the Dr.'s office? Or, Will that function no longer be secure enough for HIPAA?
If any agreement would be applicable, it would be the Business Partner Agreement - which is contraindicated for sharing of information with physicians for the purpose of treatment. The problem is that you can't guarantee that the fax was received and secured by only the intended individual. Even given the leeway that covered entities have of complying with HIPAA requirements, at this time I don't see any way for a covered entity to be able to justify automatic remote faxing of patient information to unmanned fax machines under HIPAA. There is simply no way to protect the information and authenticate the recipient. There may possibly be a way to retain the usage of faxes if you were to have an agreement that detailed the secure placement of the fax machine and specified strong procedures for sending and receiving the fax. I think you should start thinking about replacing faxes with secure email messaging. You will have the same problems and issues with automated printing (especially automated remote printing) of patient information to unmanned printers.

Would everyone agree that emailing (using attachments or not) is ALWAYS a better method versus faxing (for security and privacy issues) for transferring consumer information across organizations? If no, what are instances you believe that email/Internet should not be used for transferring consumer information across organizations?
I cannot think of an instance where a fax would be equal to or better than email, with the provision that the email has the appropriate security methodologies. I don't think that email can be used -at least outside the organization - without encryption - and if the email were used for referrals, orders, prescriptions, etc. I would probably recommend the use of digital signatures and some form of digital receipt (not necessarily PKI).

My understanding is that faxes generated within a computer system vs. a fax machine are covered. If this understanding is correct, then any alpha pager message that is auto generated would also be covered.
Good point about computer generated faxes. Also two-way pager messages are covered whether or not they are generated automatically.

Does anyone have information whether alpha messages sent to pagers containing patient information would come under the security regs? 
Yes it would be - in order to be sent to an alpha pager the information at some point would reside in electronic format.

Referring to the data security rules for faxes, it is my understanding faxed documents are not covered under the draft data security rules. 
Faxes are not covered to the extent that the transmission is excluded from the protections - (e.g. having to encrypt dial-up lines). If the information is the source or progeny of an electronic record that information is clearly covered and the method of communication of that information e.g. faxes and oral.

How are you handling other entities that require copies of records "faxed" such as individual physician practices, insurances, etc? A faxed copy of a paper record is considered electronic data. Are you requiring an agreement in writing that they are HIPAA compliant? 
If any agreement would be applicable, it would be the Business Partner Agreement - which is contraindicated for sharing of information with physicians for the purpose of treatment. The problem is that you can't guarantee that the fax was received and secured by only the intended individual. Even given the leeway that covered entities have of complying with HIPAA requirements, at this time I don't see any way for a covered entity to be able to justify automatic remote faxing of patient information to unmanned fax machines under HIPAA. There is simply no way to protect the information and authenticate the recipient. There may possibly be a way to retain the usage of faxes if you were to have an agreement that detailed the secure placement of the fax machine and specified strong procedures for sending and receiving the fax. I think you should start thinking about replacing faxes with secure email messaging. You will have the same problems and issues with automated printing (especially automated remote printing) of patient information to unmanned printers.

TOP


4. Transfer of Medical Records

We have a client that is an outpatient surgical center. Once in a while they have to transfer a patient to a hospital. I am told that the customary way to transfer the patient's medical records to the hospital is to give them to the ambulance driver for delivery. How should this be done to comply with the HIPAA standards? 
This is not a chain-of-trust application - Business Partner Agreement maybe - but possibly not because of the exclusion for purposes of treatment. If the information in the paper charts is also maintained electronically, then it will be surely covered under HIPAA. It appears to falls under the formal record processing and education sections of Security (probably not Privacy since the disclosure is for the purpose of treatment). The ambulance personnel should have adequate security awareness training and there should be a procedure for transferring information that at a minimum would (a) log the removal or copying of the record, (b) have the ambulance driver sign for and be accountable for the record and (c) also be able to document and log the receipt of the record by the receiving hospital. This would provide a closed loop of accountability. This is meant as a basic outline - the actual policy, procedures and implementation would be more detailed. This is exactly the type of scenario that the assessments are meant to uncover and address.

I have a request from a physician that wants to download medical records to his home PC as well as print medical records on his home printer. Would the records that he downloads and/or prints at home be covered by HIPAA regulations? If so, which ones? Also, would this fall under a "chain of trust" agreement? It seems that this would extend the HIPAA umbrella out to cover him. 
Access to patient records for the purpose of patient care does not restrict a physician's access to only their patients. For example, it would not be unusual for a radiologist to compare an MRI or mammogram against results from patients for whom they are not providing care. There may be many scenarios related to patient care that would provide a foundation for a provider to access records of patients that are not theirs - without the authorization of those patients whose records they are accessing. DHHS was very concerned about Security or Privacy rules that could negatively impact patient care, so they gave providers a lot of leeway. It depends on the purpose or intent of the access. Physicians are also covered by the educational requirements in both Security and Privacy whether or not they are employees. Any patient information (even demographics only) would definitely be covered both in electronic and paper form (paper and oral which are either the source or progeny of the patient information maintained electronically - and includes transcription to a computer file). Chain of Trust concept from the Security regulations extends protections to external trading partners for whom we exchange patient information electronically - Since the physician is not a trading partner (typically clearinghouse or payer), they would not fall under the Chain of Trust requirements. Business Partner Agreement from the Privacy regulations extends a long list of terms to both trading partners and other vendors who we may not exchange information electronically, but who may have access to the information during the course of providing services (e.g. software vendors, consultants and maintenance firms). - Business Partner Agreements are NOT required for the purpose of treatment, payment and healthcare operations so the physician would probably NOT be required to have a BPA. However, the physician would fall under internal confidentiality agreements and security awareness training required for internal staff, employees and external vendors.

TOP


5. Entity Authentication

What other authentication technology could prohibit the sharing of log in IDs (from the initial point of log in) as completely as biometrics? 
Biometrics may do a good job and for many institutions it will be a reasonable and cost effective solution for specific environments. I have a problem with it being presented as a global; one size fits all, solution. In many places biometrics is overkill and has some user acceptance and usability issues. Remember, the key to HIPAA Security compliance is not providing absolute, bulletproof, protection, but taking reasonable and diligent precautions appropriate to the entity, taking business and cost into consideration Forced automated logoff combined with simple id and password (and strong password enforcement) will suffice in most areas. There are alternatives to biometrics that provide reasonable authentication and work better in some environments - including proximity sensors and tokens.

Where in the Security or Privacy regs does it state that for access over the Internet you need 2-factor authentication? 
I don't believe it does. HIPAA Security regulations require a baseline of user id and password - not user id plus token/ biometric/etc. I don't see anything in the HCFA Internet policy that would require user id plus token/biometric/etc. The policy specifically states that the policy guidance is consistent with the proposed HIPAA Security requirements. It does speak in some detail to authentication and user identification. While the HCFA Internet Policy authority applies directly only to government programs, its existence serves to establish a reasonable baseline for commercial as well. I think it would be extraordinarily difficult to justify deploying something less than what is contained in this policy. While the term "irrefutably" is contained only once in the Security NPRM preamble (and once in the glossary), I don't think that the context and usage of it can be extrapolated to mean a requirement for 2-factor authentication. I think the authentication guidelines that occur many times throughout the document of user id plus password OR token/biometric/etc. serve to clearly indicate that HHS does not consider the definition of irrefutable to include a requirement for 2-factor authentication. While 2-factor authentication is certainly used, I don't see enough wide spread use to consider it a de-facto standard - especially in the healthcare industry. For something to be a de-facto standard it has to have wide use within its industry. As an example, a client of ours submits health information to 350+ payers and only one requires 2-factor authentication. You could successfully argue that 2-factor authentication is a de-facto standard for authentication in some industries - but you could also argue that for some industries the de-facto standard for physical security is dual 12 foot chain link fences topped with 3' of concertina wire and armed canine patrols. If the vendors of 2-factor authentication products are successful in making a strong enough business case, it will be adopted by the healthcare entities and at some point may become a de-facto standard. Encryption and authentication are not options - the consistent message from HHS on how encryption and authentication is implemented is clearly up to the entity. Considering the guidelines we currently have, including the HCFA Internet policy, the entities do have some leeway and 2-factor authentication is not required. They have the freedom to choose the implementation that is appropriate for their business, taking cost into consideration. They are of course free to choose to deploy multi-factor authentication including biometrics, tokens and DNA analysis. Since you mention certificates I have attached a recent article detailing the problems inherent in distributed PKI - and the reasons that it is not being widely adopted in ANY industry. (The HCFA Internet policy document specifically mentions centralized (as opposed to distributed) key management) as being appropriate.

TOP


6. Chain of Trust/Business Partner Agreements

I have a few questions, but first, here is some background. Magellan is a managed care organization. We provide clinical and claims payment services to our customers. To be more specific, we receive membership data from our customer. This data is then entered into our clinical systems. When care is authorized, we either send the customer an electronic authorization (when we are not providing claim payment services) or we send an electronic authorization to our own claim system (when we are providing claim payment services). For those customers for whom we are providing claim payment services, we send out electronic encounter information via an 837 transaction. Finally, providers either send us claims via a clearinghouse or directly to our offices.
1) It appears that we are a vendor in one instance (providing claim payment services) and a covered entity in another (authorizing care). Is that true or would we just be covered by a Business Partner Agreement with our customers? Since we are the middleman with a clearinghouse, do we need an agreement with them as well? Where would the BPA apply as opposed to a Chain of Trust? 
2) When the electronic authorization we generate goes to an internal claims system, must it conform to the HIPAA transaction format standards? For consistency we will probably go that route anyway, however, we would not be bound by the 26-month law if it is not covered. 
Thank you, in advance, for your response. 

1) You are both a covered entity (health plan) and a Business Partner. It depends on the role you play. Rule of thumb. If you are performing services for a covered entity that would not be covered directly - then you are their Business Partner and would be controlled by their BPA (even though you are a covered entity in other roles). If you are performing services that are directly covered by HIPAA then you are a covered entity in that role (e.g. health payments). If you contract with a vendor to perform services that you would ordinarily perform as a covered entity (e.g. utilization review) then you would need a BPA to control that vendor (even if they were a covered entity). The Chain of Trust comes to play when two covered entities are transmitting information, but neither is a BP of the other.
2) As long as you are able to receive and transmit covered transactions in the standard format, you can translate those in-bound standard formats to a non-standard format that your system can accept. (Posted 12/21/00)

Can you please point me to some samples of Chain of Trust Partner Agreements (per HIPAA requirements)? 
Chain of Trust and Business Partner (or Associate) Agreements are one area that it is going to be prudent to hold off until final regulations before drafting language. There has been a lot of confusion propagated that confuses the purpose of the COT and the BPA. They have two separate intents. 
1) The Business Partner (Associate) Agreement (BPA) is a Privacy Regulation concept intended to be used between a covered entity and their non-covered business partner (or possibly clearinghouse) to provide accountability back to the covered entity in an attempt to extend HHS's limited authority over providers, clearinghouses and payers. The covered entity is held responsible for the non-covered entities violations and essentially acts as an HHS proxy to try to control non-covered entities that are business partners of the covered entities and have access to patient information. The BPA provision is very detailed and provides a laundry list of required terms included giving the covered entity audit provisions and requiring the Business Partner to comply with the covered entities privacy policies. The terms are detailed in the Privacy Regulation.
2) As it stands now - the "Chain of Trust" (COT) is a Security Regulation concept that is intended to be applicable only between covered entities (e.g. provider to payer or clearinghouse). It is intended to supplement language now in existing trading partner agreements (or required the use of a trading partner agreement for those entities not currently using one) to ensure the passing of accountability to another covered entity. In the COT concept a provider would have a COT contract with a clearinghouse who in turn would have a COT contract with other the payer (or another clearinghouse who would have a COT contract with the payer) - so that the accountability is passed from provider to clearinghouse (to clearinghouse) to payer. This eliminates the need for the provider to have contracts directly with each payer (and each clearinghouse along the path) to whom they are sending/receiving transactions since a "Chain of Trust" would have been established between all those entities that would ensure that the accountability is passed between each entity handling the information. 
The COT language to be included in a trading partner agreement can be as simple as: 
"Both parties of this Agreement understand that any transactions (should refer to existing contract language which describes the transactions) communicated between the parties contains patient information and agree to hold all patient information, including demographics, that comes within their control strictly confidential, and provide all reasonable protections to prevent unauthorized disclosure of such information. Furthermore, both parties agree to comply with all current applicable Federal and State laws and/or regulations regarding the security and confidentiality of patient health care information including, but not limited to, any regulations, standards or rules propagated under the authority of the Health Insurance Portability and Accountability Act of 1996 (HIPAA)". 
The above is not legal advice or recommended contract language for your particular situation. This should be an area that your legal department would craft language that would be consistent with your existing agreements - or language generic enough to used for agreements that the another party drafts. Note: It is important that your institution have a contract approval process in place that would ensure that any trading partner contracts would contain conforming language prior to execution. Conversely, a contract management process should be in place that identifies all existing contracts and ensures that they are re-negotiated to include conforming language prior to renewal dates. (Posted 9/15/00)

How are you treating those affiliates whom hospitals have traditionally "volunteered" patient information to? I am talking specifically about physician practices or groups like Radiologists or Pathologists that are either given direct access to the database or have the information transmitted to them in some fashion. Should we enter into "Chain of Trust" with them? 
I would take the position that pathologists, radiologist and the like are acting as providers in the patient care continuum and would be considered providers - which for disclosures for the purposes of treatment would not require a Business Partner Agreement. Nor would a patient authorization for release of information or disclosure of release of information to the patient be required. In fact, pathologists and radiologists may represent a group that has the greatest need for access to a broad range of patient information (e.g. not their patients) for comparative analysis in the diagnostic process and denying or restricting their access to patient information for the purpose of treatment (comparative diagnosis) may reduce the quality of patient care. All of which could put the institution that denied or restricted access to the information at risk.

I work for a hospital that "networks" with physician offices. The physician's offices have access to our electronic patient information via our computer systems. The physicians are not employed by the hospital and they do not send patients to our facility exclusively. Will we need to have a chain of trust agreement with every physician who has access to our computer systems? 
Chain of trust would not apply and if only the physician has access to the information and it is for the purpose of treatment, then you would not need the business partner agreement with the physicians. However, if the purpose were for billing or any other reason you would need the Business Partner Agreement with organization. The exemption of providers from the Business Partner Agreement provision for the purpose of treatment is based on sound ethics. DHHS is concerned about putting any obstacles in the path of patient care and imposing BPA's for the purpose of treatment has the potential to slow the communication of patient of patient information in a critical situation and negatively impact patient care and outcome. For that reason I would not advice imposing a BPA (for the purpose of treatment) on the provider community. To do so could increase risk of negative patient outcome - and increase litigation risk. However, security and privacy awareness training and enforcing security and privacy policies is a "must do". Even though a BPA is not required, you should still have some form of confidentiality agreement with the physician and in any case would still need to provide security awareness training to those physicians.

We are beginning to venture out into the world of allowing physicians who are NOT our employees look up their own patients in our electronic system. Because of the upcoming regs, we'd like to do it once, the right way. So, we are in the process of coming up with a rough draft of a Chain of Trust Partner Agreement. I was wondering if anyone would like to give me some input on what should be included and the correct wording. 
The physicians would not fall under the chain of trust agreements of the security NPRM and the privacy NPRM specifically excludes physicians from the Business Partner Agreement for disclosures for the purpose of treatment. Sec. 164.506(e) "Except for disclosures by an entity that is a health care provider to another health care provider for treatment purposes would require a covered entity to maintain documentation that would demonstrate that they have entered into a contract that meets the business requirements of this part with each of their business partners. Your concern about the physicians should be focused on policy, education awareness and enforcement.

I have a client that is a health claims re-pricer (they optimize claims for insurance company.) under HIPAA they are considered a clearinghouse. Here the rub, the guild lines definition for CoT agreements state the Data integrity and confidentiality need to be preserved. My clients allows the access of it customers onto their servers to view reports etc. based on the data integrity statement, should network security provisions also be included in the CoT? 
There seems to be a lot of mixing and matching between the "chain of trust" language in the Security regulations and the Business Partner Agreement in the Privacy regulations. The original intention of the "chain of trust" trading partner language was to circumvent the need for providers to have to negotiate trading partner contracts with every payer to whom they submitted/received transactions. In the chain of trust concept, a provider could have a single trading partner contract with a clearinghouse that, in turn, would have trading partner contracts with the payers - those contracts would all contain the chain of trust language that ensures the security continuity. The chain of trust language can eliminate the need for about 50M + contracts. The chain of trust language was intended to serve as a conduit between covered entities NOT as a contract between non-covered entities. The Business Partner Agreement in the Privacy regulations would cover that function, which is far more detailed than the simple chain of trust language concept. There might be some changes to the chain of trust concept in the security NPRM, so this is one narrow area where it may be advisable to take a look at the final rule before implementing contractual changes. It would still be advisable to include at least the contract approval process in a current security assessment.

1. How do I get a sample of a chain of trust agreement?
2. What about information that has been stored electronically such as cardiology tests, GI tests and then printed out for the paper storage. 

1) Chain of Trust language would normally not be a stand-alone contract, but would be language inserted in a trading partner agreement - or added as an addendum to an existing trading partner agreement. I would seek competent legal counsel for COT language that would fit with your existing trading partner agreements.
2) For any covered entity that transmits or receives a HIPAA covered transaction, any identifiable patient information stored anywhere electronically is covered and while there is differing opinion, I believe that it is still covered when printed to paper - and that the paper that is a source of that electronic record is also covered.

TOP


7. FDA National Drug Codes (NDC) Vs. Proposed Standards

Does anyone know if the FDA will be tasked to conform to HIPAA standards and if so, when? 
Actually, the FDA assigns both 10 and 11 digit NDC codes which are included in the standard as the draft regulation stipulates the use of NDC as maintained and distributed by the FDA. Therefore, it's not a question of whether or not FDA will comply with HIPAA, but rather what code structures, rules, and length FDA distributes. Additionally, the proposed regulation states, "the specific data elements for which NDC is a required code set are enumerated in the X12 implementation guides". Both the 10-digit NDC code formats (4-4-2, 5-3-2, & 5-4-1) and the 11 digits NDC code format (5-4-2) are included in the X12 implementation guides. The code is actually populated using two segments - an identifier segment (837 segment ID SV101-1) which is a 2-position identifier that indicates which format your using and the code segment (837 segment ID SV101-2), which is the code itself. The implementation guide allows for up to 48 alpha/numeric values for coding, which obviously accommodates either 10 or 11 position codes.

TOP


19. HCFA Internet Policies

Does information have to be encrypted, or does the person gaining access just have to be authenticated to gain access through a secure portal. That is if I send the patient information to you in a file, does the data inside need to be encrypted, or do I just have to encrypt, or assure that the person gaining, (receiving) the information is the person authorized? 
You should encrypt the information AND ensure authentication of the entity. 

A question has been raised regarding the HCFA internet security policy. Patient satisfaction data is transmitted from acute care facilities to both our 3rd party contractor who reports the data to us and to our corporate divisional offices. Our interpretation is that as acute facilities we do not fall under the HCFA internet policy as this applies to contractors and agents of HCFA. Additionally, we feel that HIPAA is really addressing this issue for us as provider organizations. Are there other acute facilities that transmit patient data now that feel the same way? 
You are correct that the HCFA Internet policy does not have direct authority over your institution and that HIPAA Security regulations do have authority. However, HIPAA Security regulations require encryption for communication patient information (which includes all patient information, even demographics) over the Internet, and DHHS will look to the HCFA Internet Policy as establishing reasonable and diligent encryption methodologies. It would not be prudent for a health care organization to ignore the policy that HCFA sets for Internet transmission of patient information.

TOP


20. HIPAA Security

1. We have Patient Monitors (i.e. Agilent Viridia) that display a patients  vital signs, the charge nurse will key the patients name into the system and  it will be displayed along with the vital signs. Is this display of patient information allowed by HIPAA privacy regs?
2. We have a homecare division and have just started issuing laptops to the visiting nurses to enter patient information such as; diagnosis, orders, meds, etc. Currently they download this information into our network but plans are to allow dial-up access so they can transmit through phone lines. Is this considered a closed network and does this data need to be encrypted? 

Laptop or workstation encryption is not a HIPAA requirement and will probably not be needed in the vast majority of the cases. It will depend your risk assessment that balances costs against threat and impact. 1) The display of that information is allowed, however it must be restricted to personnel who need to know that information and protected from unauthorized persons (e.g. public) begin able to view it. 2) The Security NPRM does make mention that dial-up lines should be encrypted. Depending on your current dial-up it may make sense to evaluate replacing it with a VPN.3) More important than whether encryption is required for dial-up is the development of appropriate policies, procedures and protections for those laptops - and any other dial-up environments. These are essentially the same issues that we are working to address for home based transcription, visiting nurses, physical therapists, etc.

TOP


21. HIPAA Security Regulations  - Who/What is Covered

My company will be implementing ASP where instead of our clients (hospitals/laboratories) storing patient data/results in their facilities, this data will be stored at our site which our ASP clients can then remotely access. Because of this, I assessed that the Security and Privacy standards will then really have significant impact to our organization to the point that we have to pattern our implementation the same way as a health provider will normally do. Am I right in this regard or am I just worrying too much? 
Under the current Privacy NPRM you would be required, through a contract (Business Partner Agreement) with your provider customer, to agree to comply with the Security and Privacy rules. You would also need to be able to have a process in place to be able to comply with your provider customer's privacy policies and agree to a number of other terms, one of which would make you the target of a patient lawsuit in the event you violated the provisions of the agreement. Even if the final Privacy rule appears sans the Business Partner Agreement provision (remote possibility - but not likely), I could not imagine a provider organization not requiring - at a minimum - that their ASP at least self certify compliance to the Security rule and agree to support the providers privacy policies. (Posted 11/21/00)

I work for a research and consulting firm that receives and sends patient data stored electronically via email and snail mail. How do I find out about the laws regarding these transmissions? Are there any regulations for companies hired by health care providers? 
You are not directly covered by HIPAA regulations, however each covered entity you exchange data with is responsible for ensuring that all patient data (that is the source or progeny of an electronic record) transmitted over an open network between you is sent encrypted. Specifically, you would be affected by the Business Partnership Agreement clauses. In addition, the proposed privacy regs would make it more difficult for health care providers to use or disclose identifiable health care information for research purposes. Under the Privacy NPRM you would not need to obtain patient authorization for research as long as it is covered under an IRB. (Posted 11/21/00)

I attended the WEDI SNIP (Strategic National Implementation Process) meeting. It was pointed out by one of the attendees that providers who do NOT submit ANY EDI transactions are NOT required to comply with ANY of the Security regulations. Is this true? 
I think that the advantages of using EDI far outweigh the costs of complying with HIPAA security. My personal opinion is that If a provider has submitted a HIPAA covered transaction I don't think they can go back. Once a HIPAA covered EDI transaction has been submitted or received, then all patient information maintained electronically is covered, including demographics - which indicates that it is no longer dependent on the submission or acceptance of HIPAA covered transactions. However, it may impact small providers decisions on whether to start using EDI....

How does DHHS define "reasonable and appropriate? 
That will be a business decision of that entity - not a mandate by HIPAA Security regulations. 

DHHS representatives have publicly stated many times that reasonableness and flexibility are part of the founding principles to the security regulation and are not going away. In fact, Gary Christoph, Ph.D., CIO HHS/HCFA, addressed the WEDI conference last March and stated that the foundations of the security regulations were not changing and covered entities could safely start their assessment process. 

We may be going farther with security technologies than is reasonable or expected under HIPAA. Any time we provide access to information there is risk associated with that access. The decisions on what risk levels are acceptable and how much to spend mitigating risk are business decisions, not technology decisions. 

The Security NPRM is very clear on how HHS expects organizations to address security issues. Note the uses of "reasonable" and "appropriate".1) Security NPRM, Page 10 -1st column: "The standard does not address the extent to which a particular entity should implement the specific features. Instead, we would require each entity to assess its own security needs and risks and devise, implement and maintain appropriate security to address its business requirements. How individual security requirements would be satisfied and which technology to use would be business decisions that each organization would have to make." It goes on to state: "Inherent in this approach is a balance between the need to secure health data against risk and the economic cost of doing so. Health entities must consider both aspects in devising their security."2) Security NPRM, Page 20: "HIPAA requires... maintain reasonable and appropriate administrative, technical and physical safeguards to ensure integrity, confidentiality, and availability of the information. The safeguards also protect the information against and reasonably anticipated threats or hazards to the security or integrity of the information. 

This means that we are NOT directed to deploy; (1) encryption on laptops, (2) PKI, (3) single-sign-on, (4) biometrics or (5) buy any other technology that does not make business sense in our organization. In fact, we are mandated to assess before we buy. With a few rare exceptions (e.g. providing a firewall for a currently unprotected Internet connection or securing an obvious deficiency), this means that we should not be considering technologies without having already done our assessments (including risk & cost analysis) and made business decisions on addressing security policies and procedures. At that point, search and selection of technologies focuses on how to best enforce and support our business policy decisions (most of which will not require any technology to enforce and support).

Does the security standard only cover electronic transactions? The security standard definition of health information - means any information, whether oral or recorded in any form or medium, that-...It further states (142.306) An entity must apply the security standard described in 142.308 to all health information pertaining to an individual that is electronically maintained or electronically transmitted. So if the medical record is electronically maintained and then transferred in paper form is it covered under the security standard? 
1) There is language in the current Security NPRM that addresses paper records in a left-handed manner. It has been understood from the beginning that the intent was not to let paper (and later oral) communication that has the same content as is stored electronically slip through the cracks. Expect coverage of paper and oral to be covered and clarified in the final Security rule. 2) Congress doesn't have to do anything to expand coverage to paper and oral. The OMB (GAO) report is very clear that coverage of paper and oral is well within the current authority of DHHS under the HIPAA legislation.

Does the HIPAA security standard indicate a need for encryption of patient information on diskettes being sent from an outside laboratory to a provider? Previously, the information had been sent hardcopy and re-typed into the appropriate system. The concern is that re-typing takes time and can produce errors, whereas "cut and paste" could be employed if diskettes with unencrypted information were sent. Further, unencrypted diskettes would not be sent by courier, but by FedEx (or other carrier), for example. And the package would have to be signed for by designated office staff. 
The diskettes are covered under the "media controls" requirement. That is, if the data is not being sent over an open network, there is no need for encryption. However, you would need documented media controls in place.

If I used a VAN for transmitting confidential data and that network gets hacked due to negligence on someone's part, (I can provide technical examples but I don't want to bore non-technical folks) who is held liable for that? I have looked at VAN's before and they have no liability on such actions and say that the user of the network is responsible for their own security. Any feedback? 
At the very least VAN's would have to be part of the Chain of Trust concept in Security and are probably considered a Business Partner under Privacy because they have access to patient information and are performing services on behalf of the covered entity.

TOP


22. Immunization Records - Who/What is Covered

Can anyone enlighten me on whether immunization records fall under private patient information? We are going to give people (within our organization) the ability to check immunization records via a web browser. Now of course I asked all the important questions (e.g. is the connection encrypted and is access authenticated, etc.), however during the course of our conversation, the individual I was working with said that immunization records are considered public information and therefore don't fall under HIPAA requirements.
This is the first time I've heard that position and I don't think it is accurate. If you are a HIPAA covered entity you have to protect all the patient information (including demographics) maintained electronically by you - period. Even if a state agency makes that same information public I don't think that exempts you from protecting the information that is under your control. If a state reporting agency requires you to report immunizations and that state agency then makes them public their disclosure is beyond your control - and outside of HIPAA's purview. Even though the HIPAA regulations provide the ability for HIPAA covered entities to disclose patient information to meet state reporting requirements, HIPAA doesn't give HHS authority over those state reporting agencies and if the state reporting agencies make the information public I don't think there is anything that can be done about it.

TOP


23. Use of US Mail Who/What is Covered

I was wondering if you think HIPAA applies to medical information being sent by regular mail, either on paper, disks, or any other medium. In essence, an electronic medium would be mailed via a regular postal service. 
HIPAA Transactions & Code Sets applies to the covered transactions no matter how they are delivered - Internet, BBS, diskette, tape - any electronic media - no matter how it is submitted - (e.g. diskettes in regular mail or FedEx). HIPAA Privacy (therefore security) covers paper that is the source or progeny of an electronic record (e.g. claim printed from information residing on a computer system).

TOP


24. Insurance Company Efforts for new EDC

From the July 27th ePharm online newsletter:
"AETNA, CIGNA, and OXFORD join initiative for new EDC Exchange"
Three major health insurers say they are joining an effort to develop digital standards for many administrative tasks performed by physicians. The MCOs, along with 23 others, are members of a group called the Coalition for Affordable Quality Healthcare. The goal for the group is to standardize the credentialing process for physicians, along with claims submissions and patient eligibility processes. The group says it will attempt to create one process that would be available on line or through electronic data communication. Is this effort not a duplication of what HIPAA has proposed?
 
No this is not at all a duplication - in fact this can be seen as a positive outcome of the HIPAA standardized transactions that will wind up helping the providers. The coalition appears to essentially be setting themselves up to bypass the clearinghouse by providing a central web site with a single, standard methodology for providers to directly submit/receive to payers HIPAA standard transactions (claims, eligibility, authorizations, etc.).While the coalition could use formats other than HIPAA standards as a transition until the final implementation date of the HIPAA standard transactions, they would have still have to comply with the HIPAA standard transactions. What format(s) they are going to start with (HIPAA standard, NSF/Proprietary or both) is unknown at this point. The standardized credentialing process is outside and beyond HIPAA, since HIPAA does not include a credentialing transaction.  also think it has a good chance of succeeding - these are some of the same players that started the old NEIC (National Electronic Information Corp.). They have a history of being able to put something like this together and make it work.

TOP


25. Transaction and Code Sets

Can a provider send non-standard transactions to the clearinghouse, who then in turn could send these same non-standard transactions on to the health plan (Assuming a contract is in place between all parties of course)? 
That's pretty much correct, IF the provider has a contract with the clearinghouse AND the payer has a contract with the clearinghouse to provide those services. There are a couple of stumbling blocks however - translating from proprietary/NSF is not as straightforward as it first appears. On the provider side, by the time the provider goes through the process of figuring out what changes they are going to have to make to deliver enough information to enable the clearinghouse to make an accurate translation they might as well produce the HIPAA compliant transaction in the first place. Especially since providing that information would probably mean that the provider would need to produce a proprietary (or NSF) format that is significantly different than the one they are preparing today. A couple of examples:1) There are a number of ANSI 837 data elements that do not directly correlate to existing NSF or proprietary data elements. Providers would have to examine the codes currently sent to their clearinghouse and ensure that the clearinghouse was able to accept the updated codes that correlated with the ANSI 837 data elements.2) Providers have to provide the correct NDC codes in place of current J codes - clearinghouses could not translate from J to NDC.

Do providers have to comply with the transaction code set component part of HIPAA? 
Transactions, Codes and Identifiers standards are going to have a significant impact on the provider community as well as the payer community. However, the HIPAA Transactions standards do supercede State law and we shouldn't see any conflict. The only regulations that do not supercede state law are the Privacy Regulations - in which case State laws that are more restrictive than the Privacy Regulations retain primacy. Providers do need to be concerned with regulations other than Security and Privacy. Here are a few areas where considerable thought and planning need to take place, and this just scratches the surface. Transactions - (1) Format conversions & content gaps between application data and ASC X12 standards, (2) Impact on business process (e.g. processes and system changes to ensure capturing all the information required to populate (or import) the ASC X12 standards, (3) Impact on related systems & data structures, (4) Trading partner coordination, (5) Training... Codes - (1) Elimination of local codes & accompanying system migration and payer coordination, (2) Elimination of "J" codes (replaced by NDC), (3) Migration strategies, (4) Coding training (e.g. can no longer use surgical codes + modifier for anesthesia billing - must use anesthesia codes), (5) ICD-10 preparation, (5) History conversions (cross-walk?)... Identifiers - Provider - (1) Transition & migration from proprietary to NPI, (2) Elimination of existing schemas with built in intelligence, (3) Timing, (4) Roles and coordination with clearing houses, providers & health plans... Identifiers - Patient (if ever)... Identifiers - Health plan...

I am hoping that someone can help me clarify an issue concerning the relationship between the 837, Health Care Claim Submittal, and the 835, Health Claim Payment/Remittance Advice. It is my understanding that the 835, Health Claim Payment/Remittance Advice, is the response to the 837, Health Care Claim Submittal. Meaning that if a provider decides that a transaction is to be electronic, the payer MUST accept the standard. Specifically, if a claim is submitted electronically, the payer MUST accept it. If the provider wants an electronic Claim Payment/Remittance advice, the payer MUST provide it in the 835 standard electronic form. Only if the provider decides he/she would rather receive paper, would the payer be able to return the 835 information in a non-electronic format. Is this the understanding that everyone has? 
The payer has no choice in the matter. If they are providing the service manually or proprietary EDI now (e.g. claims, ERA, eligibility, referrals & auths, etc.) they must provide those services via EDI and accept and deliver the HIPAA standard transactions, including the code sets.

Is it true if providers do nothing with ANSI, that they can continue to file claims to clearinghouses which will convert providers NSF format to ANSI and forward the claims on to the appropriate payers? 
Yes it is... But that does not mean that the provider will not have to do some work on the NSF to support the required ANSI data elements and codes. For some data elements there is not a direct correlation between NSF codes and ANSI codes. You need to be careful with clearinghouses translating NSF to ANSI 837 40.10 to ensure that the translations between NSF codes and ANSI codes retain their meaning and intent. It will be easier to retain accuracy going from 837 to NSF than from NSF to 837. There is even the potential for Fraud & Abuse compliance issues.

TOP

 


8. PC Anywhere

We are in the midst of going through vendor selection for various departments here at our hospital. Vendor selection also means RFI's/RFP's, and we are trying to include some verbiage in those that the vendor will adhere to all mandated regulatory issues that come up (or will strive to in a particular timeframe), including HIPAA's pending regs. We are also trying to make sure the vendor will use the best possible secure method to support the software (housed in our facility) remotely. Up to this point, it was either direct dial-up, frame or web access. Many vendors say they will use PCAnywhere version 9.0/9.2 to support these hospital systems. What is your interpretation of the HIPAA security regs concerning remote access/support? What will you expect from your hospital/medical vendors for support? 
While technically HIPAA does not apply to vendors in that HHS has no authority over them, practically the vendor's organizations will need to comply with HIPAA Security regulations, as it will be up to the providers, clearinghouses and payers to ensure that the vendors they do business with are able to protect any patient information for which they have access. If the current Privacy Regulations are finalized, vendors will be covered under the Business Partner Agreement and as part of the terms will be required to comply with HIPAA Security and Privacy rules. However, simply including "the best possible secure method..." language into a contract may not be in the best interest of the covered entity since it is also incumbent upon the covered entities to apply reasonable requirements to their vendors and specify what they want, which they should be able to be negotiated with the vendor. For example, using PCAnywhere for the vendor to dial in and support the user may be acceptable if the policies and procedures covering its' use are strong enough - e.g. if the phone line is not physically connected unless the user agrees to "connect" it for a one time use, monitor the access and disconnect after the vendor is finished. What is more important is understanding what steps the vendor is taking organizationally to protect patient information that they have access to during implementation, training and support. This includes their policies, procedures, confidentiality agreements, employee training, etc. etc. - essentially how the vendor would meet the same organizational criteria as contained in the HIPAA Security regulations. Furthermore, I think there are two separate issues with HIPAA Security compliance in the vendor community - (1) product compliance and (2) organizational compliance. While a vendor would not be in a position to certify that their products are HIPAA compliant - since that would depend on their customer's implementation - they would be in a position to respond to their customer's requests for specific features/functionality that the customer may want to implement to support their HIPAA policies. t is reasonable for covered entities to expect their vendors to certify compliance with the HIPAA Security regulations on an organizational basis. Since the covered entities are taking the responsibility for any unauthorized release of information by the vendor, then covered entities should be able to expect that their vendors are at least complying with the HIPAA Security regulations and are protecting any patient information the vendor is exposed to in the course of their business relationship. The failure of a vendor to agree to organizational (internal - not product) compliance with the HIPAA Security regulations should send up a red flag.

TOP


26. Smart Cards

Does anyone have advance knowledge of how healthcare smart cards will be affected by HIPAA Privacy and Security regulations when finalized? Will PINs suffice or will there be a need for encryption as well? 
PINS will suffice for authentication, but encryption will still be required over the Internet. In essence:
1) While you may not see the terms "irrefutable" or 2-factor authentication - there is in fact language in the Security NPRM that requires that a minimum level of authentication used be a user id plus (password, biometric, token, etc.) which is in fact 2-factor authentication.
2) You will find the term "user authentication" and "non-repudiation". While these terms are found in the Electronic Signature portion and the Electronic Signature is currently optional, the security standard also mandates that each covered entity "maintain appropriate security to address its business requirements..." While it will be up to each entity to determine what is appropriate for their organization, I would be surprised if entities that are sending messages between physicians, pharmacies, labs, etc. would not conclude that it is in their best business interest to make sure that the entities sending them information are who they say they are (e.g. strong authentication polices) and that they would not want persons sending or receiving patient information to be able to deny that they either sent or received such information (non-repudiation).
3) I believe that the current iteration of the Electronic Signature portion will be removed from the final Security Rules and we will see some changes to it that may include requirements for electronic signatures over open networks.
4) While the HIPAA Security NPRM requires encryption over an open network (e.g. Internet), it does not require authentication stronger than user id and password.
5) Non-repudiation is not certain simply with the use of multiple factor authentication or certificates/PKI. I agree that non-repudiation can, in fact, occur in architectures that do not use traditional PKI; enforcement of non-repudiation has more to do with the policies associated with identification of the user and the process of assigning the related id and password (or PIN, token, certificate or biometric). If the user does not have to present strong identification (e.g. picture id and licensing for a physician) prior to them being issued an id, password (or PIN, token, certificate, biometric, etc.) then there is no assurance that the person is who they say they are. In fact, there are significant issues when using certificates that are bound to browsers since anyone who gains access to the machine (browser) could impersonate the user. 
6) Under your definition of two factor authentication - the common use of biometrics would be a single factor authentication - that is a person's fingerprint (or other biometric) is typically is used alone and not in conjunction with password, token, PIN, etc.

TOP

 


9. Electronic System of Record Keeping

What is the scope of the "electronic system of record keeping" referred to in the proposed privacy regulations? 
If you take a look at the security NPRM, it is very clear that it covers all identifiable patient information maintained electronically, even demographic. Which would include identifiable patient information in any system in any context. The privacy regulations serve to clarify and expand the scope beyond "electronic" to paper and oral communication that is either the source or progeny of electronic information.

TOP


10. Authorizing Sharing of Passwords

Does anyone know what the HIPPA regulations are related to the sharing of passwords? Are there any regulations that specifically address employees "authorizing" other employees to use their password? If they "authorize" the employee to use their password is that in accordance with the regulations? If so, do the regulations differ in regards to sharing hospital e-mail/internet passwords vs. sharing health information systems passwords? 
1) There are requirements for establishing authorization policy, procedure and controls. This policy would need to specifically preclude users from sharing their password and id's.
2) Password sharing would also be contrary to the requirements for a unique user id and make any audit trails useless.
3) Executives giving their assistants access to secure email would also preclude compliance with the electronic signature requirements of authorization and non-repudiation. Although this is a common practice in healthcare, it goes against any accepted information security practices

TOP


27. Where to Find HIPAA Rules

Where can I go to access the Privacy rules? 
All the HIPAA rules can be downloaded from: http://www.aspe.os.dhhs.gov/admnsimp/index.htm

TOP


28. State Law Vs. HIPAA

Don't federal law and rulings prevail except if the state law and rulings are more stringent? 
More stringent State law can only supercede HIPAA Privacy regulations. See Sec. 1178 of the Act. All other HIPAA regulations supercede all State laws that are "contrary" or are an "obstacle" to the intent of the regulation. The key seems to be the definition and application of "contrary" and "obstacle". For a great article (in PDF format) on this subject by Tom Gilligan of AFEHCT, click here! (Posted 10/11/00)

Does HIPAA supercede state law?
For an excellent, in-depth treatment of the issue of preemption of state law as it applies to the HIPAA standards for transactions, code sets, identifiers, and security click here for a paper (in PDF format) by Tom Gilligan, Executive Director & Washington Representative for AFECHT.

I have a question about the state privacy law issue. Doesn't the regulation provide for a means by which states have to apply to HHS to have its law(s) certified as being "stricter" or "stronger" than the HIPAA Rule? 
I don't see any provision in the HIPAA legislation or the Privacy regulations that requires a State to apply to HHS for determination if an existing state privacy law would retain primacy. There is simply a process to apply for an "administrative determination" or "advisory opinion", but it appears to be optional. If a state wanted to enforce their privacy law, they appear to be free to make their own determination that the law was "stricter" and attempt to enforce it. In the process, they would also probably wind up having to provide justification to the courts that their law was in fact stricter. It is clear that the intent of the HIPAA legislation is to make compliance to HIPAA regulations a reasonable process of conforming to a single set of rules, not subject to the vagaries of a multiplicity of State laws and regulations, while giving States some limited leeway in specific circumstances. The fact that the Privacy regulations do not supercede more stringent State law may have more to do with congress' intention that privacy be legislated, not regulated. Except for the Privacy regulations, whether or not a State law is more restrictive does not enter into the decision process. HIPAA regulations (Transactions, Security, Code Sets & Identifiers) supercede contrary state laws - whether or not the state laws are more stringent. There are some areas open to exception, but the Secretary of HHS must approve them - at least this should provide us a central source where we can track any exceptions. However, that does not mean that Privacy regulations do not supercede contrary State laws that are less stringent. Privacy is the only regulation that establishes a "floor" and is specifically precluded from superceding more stringent State law. (See Sec. 262/ Sec. 1178.(a)(1)(B) and Sec. 264(c)(2) - which is also one very good reason why privacy should be legislated, not regulated. Now all we have to do is figure out how to identify when a State law is "more stringent" (e.g. would a State law having a stronger penalty prevail even if the that law actually required less from the covered entity?).

I just ran across this information on bill S-323 that has passed in New Jersey. This bill enables the Commissioner of Banking and Insurance to set a timetable for the use of electronic transactions. The timetable is to be issued within 90 days of the date the federal Department of Health and Human Services adopts rules establishing standards for health care transactions.If the Commissioner sets the timetable for 12 months does this force the adoption of HIPAA transactions in half the time as the HIPAA law has allowed? Does anyone know of other states that have issued similar laws? 
That's an interesting concept for New Jersey to set its own timetable since the HIPAA legislation supercedes State Law except for Privacy (and a few other exceptions that the Secretary must approve for regulation of health plans, prevent fraud & abuse, State reporting or controlled substances). I'll be interested to see how that legislation pans out. Additionally, the only HIPAA Regulations that supercede less demanding State Laws are the Privacy regs all other HIPAA regulations supercede ALL contradictory State Law (not just less demanding). Albeit there are some exceptions in some areas, I don't see where those exceptions include time lines. However, there is nothing that would prevent an individual organization from attempting to impose a more demanding timeline - it just wouldn't have the impact of law.

TOP


11. HIPAA Security Certification

The security standard, section 142.08 (a) (1) requires a "certification" (an evaluation that the security requirements have been met. The regs specifically say that the certification can be done "internally or by an external accrediting agency".Do you know whether there will be a governmental agency assigned to this task (seems doubtful) or will outside consultants be permitted to do it? Can vendors offer certification as part of their services? 
EHNAC (Electronic Health Network Accreditation Commission) is gearing up to provide HIPAA Security Certification to provider, clearinghouse, and vendor organizations - (note that the certification for vendors is for the organization - NOT a product certification). Last time I talked to JCAHO they will include some HIPAA aspects to their audit and if they observe a violation will incorporate it in the audit, however, passing a JCAHO audit will not mean the organization is HIPAA Security compliant. 

Will JCAHO require HIPAA compliance? 
The last conversations we had with JCAHO - their position was essentially as follows (paraphrased): "If HIPAA violations are uncovered during the audit, they will be addressed as part of the audit process, however passing a JCAHO audit will not certify that the audited organization is HIPAA compliant".

TOP


29. Electronic Signatures

Is there anyone out there currently using non-digital electronic signatures for physicians, and what ramifications / crossover issues (if any) do you anticipate when the digital requirement is passed? 
The Electronic Signature section of the security regulations will most likely be pulled and inserted into another regulation at a later date. I think when that happens that the requirement for digital signature may go away - but retaining the property requirements of authentication, non-repudiation and integrity. I would wait for the electronic signature regulations to appear (or re-appear) before making decisions internally on electronic signatures. (Posted 9/15/00)

We currently have our radiologists and pathologists signing reports with an encrypted Provider Identification Number "PIN" which attaches the "Signature on File" label to the report. Our software vendor states they do not have the capability to do "digital" signatures. Can you verify that HIPAA will not allow electronic signatures with an encrypted PIN and explain to me what they are defining as "truly digital" along with their reason? 
Under the definition of digital signature - you must use certificates with public and private keys. PINS do not qualify - Here is an "official" definition of digital signature used by EHNAC (Electronic Health Network Accreditation Commission). Digital Signature - Transformation of an electronic message or record using an asymmetric cryptographic-based algorithm so that a person having the initial message and the signer's public key can verify that the transformation was created using the signer's private key that corresponds to the signer's public key and that the electronic message or record has not been altered since that transformation. Under the current regulations, use of electronic signatures are optional. However, we anticipate that the Electronic Signature section of the Security Regulations is being carved out of the Security Regulations and will show up in another regulation. We do not expect the final version of Electronic Signature to require the use of digital signatures - however we do expect that whatever type of electronic signature used will maintain the following properties: Message Integrity, Authentication and Non-repudiation. We also expect that Electronic Signatures will be required for messages sent over the Internet.

TOP


12. Digital Receipts

I'm not clear what a digital receipt means. I understand the concept. Could you clarify that for me? What equipment will accomplish providing a digital receipt? 
A digital receipt essentially provides an end-to-end verification that (1) the message was read and (2) the person to whom the message was addressed was the person that read the messaging (non-repudiation) and (3) there is an audit trail maintained to track both the sending and receiving of the messages. There's a lot more going on behind the scenes, but it essentially operates as follows:
1) The sender digitally signs the outbound message using their unique identifier that ensures the sender is who they say they are (password, PIN, biometric, token, etc.). The message time, signature, etc. are then logged.
2) The receiving party cannot read the message until they enter their unique identifier (password, PIN, biometric, token, etc.) which ensures the message is read by party to whom it is addressed. Upon the receiving party entering their identifier, the message is opened and a receipt is generated and signed with the receiving parties digital signature. This forms a digital receipt that can be sent back to the receiving party and matched to the sending message log (which can be kept centrally or on the sending parties site). One of the keys to the process are the policies that establish what is required to verify the users identity prior to assigning their unique identifiers. Unless the policies are strong (e.g. require the user to present picture id + credentials to a notary), you still are not sure that the user is who they say they are.

TOP


30. HIPAA Enforcement

Who is going to enforce the HIPAA regs? 
The Department of Health and Human Services has created an office to handle information technology privacy and security matters. HHS announced the formation of the privacy and security office in a notice in the Sept. 5 edition of the Federal Register. The office specifically is responsible for implementing programs to comply with federal privacy and security legislation; monitoring information security and evaluating security safeguards; establishing an HHS team to respond to privacy and security breaches; and developing security policies and guidance for HHS. The creation of the privacy and security office is part of a reorganization of the HHS Office of Information Resources and Management. More information about the privacy office is available at www.access.gpo.gov/su_docs/aces/aces140.html. (Posted 9/15/00)

There is considerable confusion regarding HIPAA enforcement. I've heard statements to the effect that "it won't be enforced because there is no funding for HIPAA cops and the States roles.
The Office of Civil Rights will be enforcing the civil penalties for privacy violations. The DHHS reasoning is that the right of privacy of medical records is a fundamental civil right. That does put a different twist to a $25,000 penalty. Concerning Penalties: In order to try to put more teeth into the civil penalties, the "Office of Civil Rights" will be enforcing the civil side - Dept. of Justice will take the criminal side. In fact, there is a memo from the Dept. of Justice to the OIG requesting that if OIG fraud and abuse investigators uncover any privacy violations that those violations be referred directly to the Dept. of Justice prosecution. The memo may be found at http://www.hipaacomply.com
For Privacy Act Violations: 
Chief, Public Integrity Section 
Criminal Division 
U.S. Department of Justice 
Washington, DC 20530

TOP


13. Patient Sign In Sheets

Does anyone know of any HIPAA regulations as it relates to patient sign-in sheets and 'calling' of patient's names in a waiting room? 
Patient sign in sheets could be a privacy issue since the information associated with a patient signing in would be effectively released to any other following patient. Calling of patient's names may also be a privacy issue if the name being called was the progeny of an electronic record.

TOP


31. E-Mail

Here's a paragraph from HCFA:"User authentication or identification must be coupled with the encryption and data transmission processes to be certain that confidential data is delivered only to authorized parties. The reg goes on to talk about appropriate methods of authentication and identification. My question: WHO is the USER? The individual, or could it be the business? 
The user can be an individual or an entity. The authentication needs to be appropriate to the usage. For example, it would not be appropriate for physician-to-physician communication to be authenticated at the entity level; and it would be appropriate when transmitting/receiving claim transactions to authenticate at the entity level. What is critical are the policies used to establish authentication identification, whether it is entity or individual. Meeting the non-repudiation provision is only possible with strong authentication (registration) policies - whether or not you use certificates and PKI. 

HCFA's Internet Security Policy lists three types of encryption: a minimum of a 112 bit algorithm for symmetric encryption, 1024 bit algorithm for asymmetric systems, and 160 bits for Elliptical curve systems. Could someone please explain/give an example of what falls under each of these categories? 
For patient information in an email or email attachment sent via the Internet (or other public network), you should pay attention to the synchronous encryption that is most often represented by PGP (128bit), 3DES (112 bit) and SSL (128 bit option). Elliptical is good technology, but not in widespread use yet, and asymmetric is typically a system level (e.g. workstation to server login) usage. From a practical standpoint, what is also going to be very important in communicating patient information between and from providers to labs, pharmacy, clinical applications, and patients are the three properties of electronic signature; Authentication, Non-Repudiation and Integrity. That is; you need to have policies and methodologies in place to know for certain that the person sending/receiving the message is who they say they are (cannot claim their secretary or nurse must have sent/received the message using their computer) and the message cannot be tampered with in transit. 

Has anyone come across guidelines re: in-house use of email that contains patient identifiable info, as it pertains to necessary job processes? For example, a billing clerk sending an email to the Medical Records Director for coding information on a certain patient account. 
Policies vary by organization. It has been my experience that developing policies that are "rule centric" does not work well. That is, if your goal is only to develop policy that is "HIPAA compliant" then the policies developed focus only on the compliance and not how best to serve the organization. Email is a good example of being able to use the HIPAA regulations to drive workflow improvements. There are a lot of variables that have to be taken into account before you can develop policies that work for your organization. Determine how your organization is currently using email. Email usage tends to develop on an ad hoc basis with each department/individual determining what's best for them - sometimes without regard to impact on other departments (or regulations) - [note: This is not necessarily a bad thing, having the users help develop the processes can lead to some great innovations. It's just important to guide the process and be able to share the innovations] It is a good practice to involve all the departments impacted to develop an email strategy on how the organization can best use email to improve work flow and productivity. Then you can figure out how to enable that strategy and be compliant with HIPAA. 

A few areas to consider as you move forward.
1) It is important to differentiate the handling of operational (e.g. billing questions) email from clinical (e.g. Rx, consults & lab results). Further, some clinical email may be able to be controlled through applications (e.g. EMR) while some could be an ad hoc a cut & paste of lab results. Clinical email has a much higher chance of being forwarded outside the organization.
2) Do you allow automatic forwarding of email outside the organization. It is not unusual for a physician to have their organization email forwarded to their personal email address or vice versa.
3) If you are using email for consults, Rx, etc. You need to consider the use of secure messaging (e.g. digital signatures).
4) Consider developing and using forms that alerts the users to the fact that patient information is contained in the email. You could develop different form types for clinical vs.. operational.
5) How is the staff to handle email initiated from outside your organization that contains patient information?
6) Consider web enabled email or using a third party to outsource secure communications.
7) Controlling long email threads. You may have instances where long email threads containing several responses of non-patient information hide an early response that does contain patient information. 

How should e-mail be secured? 
One of the issues with email is authentication of the sender and receiver. WEDI and AFECHT have completed an Internet operability pilot for HCFA and have a draft report available on the WEDI web site http://www.wedi.org. You might want to take a look at that report before making a decision on how to handle email.

TOP


14. Encryption

In our Health system we have several physician practices that we own and manage. Web sites have been developed for these practices so that the physician's patients can request appointments, prescription refills, or other information on-line. We are confident that the information coming into the practice is secured. The problem is the reply to the patient. How can we confirm the identity of the patient? In other words, how can we assure that the information being sent back to the patient can only be retrieved by that patient? We can put in passwords and log in codes for the patients to use but does that meet the intent of the HIPAA regulations? 
Assuming that you are correct and inbound information is secured, then you can set up a secured server and store encrypted patient messages on that server that the patient can access using an id and password. The key is that you need to set up registration policies so that you have assurance that when you issue an id's and passwords to a patient that you are sure of their identity. WEDI and AFEHCT boards have recently approved the final version of the WEDI/AFEHCT Interoperability Report to HCFA. This is a very comprehensive report that addresses many of those areas - including PKI, certificates and VPNs. I would suggest a read of that report before setting up patient access or making any decisions on encryption, certificates, PKI or the like. You can find that report at www.edisec.org. (Posted 10/31/00)

Is encryption required over dial-up lines? Is the Background part of the Security and Privacy regulations true requirements? 
Encryption is required over open networks and dial-up lines are considered open networks. The Technical Security Mechanisms section of the Security NPRM is very clear in requiring encryption over "open networks". Also: Security NPRM - Federal Register Page 43255 - 1st half of the first column. Excerpts: "When using open networks some form of encryption should be employed..." AND "These controls would be important because of the potential for compromise of information of open systems such as the Internet or dial-in lines". This lumps dial-in lines into the open network category that requires encryption. Although there were many comments objecting to the necessity of encrypting dial-in lines, my feeling is that the odds lean toward keeping the requirements for encrypting dial-in lines in the final rule.I would also expect that final rule would better clarify the position and HHS would address the comments regarding dial-in lines in the comment-response section of the preamble. Requiring encryption on dial-in lines is a problem area and if the dial-up encryption requirements do go away on final rule, so much the better. However - I don't think we can count on the requirements going away in the final rule. I think the odds are better than 50-50 that it will still be there on final rule and we should start thinking about what we're going to do if it does stick. We may have to move to TCP/IP environments for communication - which wouldn't be all bad since most of those XYZ Modem environments could use a little sprucing up. Yes, since the preamble section is referred to for intent and interpretation of the regulations. (Posted 9/19/00)

Do you think the final rules will require all data being transmitted by wire will need to be encrypted due to; the lack of control over who could view and or record the transmissions as they travel across the carriers of the US phone and data network? 
I think the odds are pretty low that frame relay will be viewed as being a high enough threat to require encryption -it seems to be viewed more along the line of a point to point connection that is a low threat due to the effort and cost of deploying the technology and talent that would be required to compromise it. On the other hand, if the cost to defend against compromise (encryption) is viewed as being low enough you never know....Also - while I remember seeing a number of comments questioning the requirement for encryption of dial-in lines I don't remember any comments that requested frame relay traffic be encrypted. (Posted 9/19/00)

Under HIPAA Security regs any patient-identifiable data being transmitted over the internet must be encrypted. Can someone please point me to a definitive statement on whether or not the same data being transmitted over a point-to-point public switched network facility (dial-up link) must be encrypted? 
Security NPRM - Federal Register Page 43255 - 1st half of the first column. Excerpts: "When using open networks some form of encryption should be employed..." AND "These controls would be important because of the potential for compromise of information of open systems such as the Internet or dial-in lines" This lumps dial-in lines into the open network category that requires encryption. Note: Although there were many comments objecting to the necessity of encrypting dial-in lines, my feeling is that the odds lean toward keeping the requirements for encrypting dial-in lines in the final rule. (Posted 9/15/00)

We need to send information electronically to outside parties for billing, etc. Certainly, any such information that goes outside our private network must not be sent in the clear. Therefore, we are considering the use of PGP, digital certificates, VPNs and such to securely send this info. However, given our resource crunch and the sometimes-less-than-lightning pace at which our organization's wheels turn, this may take a while. As an interim solution, I am thinking about using publicly available compression software (like PKZIP) to send files electronically to selected outside parties. I'd use a password to zip/unzip the file, and the password for each outside party (whether dynamic or static) would be sent separately (perhaps via snail mail or given over the telephone). 
I don't think PKZIP is going to be a solution. Think you're on the right track with PGP and would suggest just going ahead and starting with PGP file level encryption. Its cheap, quick, and easy to put in place and you can always follow-up with the rest of the stuff later. Depending on your risk assessment and resulting policies, you may not need the VPN or certificates. Before deciding on certificates and/or PKI you might want to read the WEDI/AFECHT Interoperability pilot that we did for HCFA - the draft version is on the WEDI website (www.wedi.org). I would however, suggest you figure out your authentication policies and levels prior to deploying.

TOP


32. HIPAA Compliant Software/Hardware

Does anyone have any experience with SSH "secure shell"? We have a vendor stating that telnet to a secure router (using a modem turned off except for approved dial in) is not "HIPAA compliant", and that we need to allow them to implement SSH so they can access our clinical system over the Internet. I see red flags whenever a vendor states that a specific product is or is not "HIPAA compliant" when regulations are not finalized. The only information we have is links to the SSH website they have sent us, no formal description of their product or process. Naturally, we are very cautious regarding outside access to our network and systems. 
Cautious is a reasonable response in this case. The vendor's claim of HIPAA non-compliance may not be substantive. Dial-up telnet sessions through your router may or may not be HIPAA compliant. Your dial-up access control appears sufficient, and while the current Security NPRM alludes to requiring encryption over dial-up lines, there are however some conflicting messages and the final rule could exempt dial-up lines from encryption requirements. While SSH could be a viable method for protecting telnet sessions, I am not sure that I would allow the vendor to dictate the mode of access, especially if you do not have a say in the policy, procedures or process. In fact, allowing the vendor to control the access and not conform to your polices and procedures could be a violation. It is your responsibility to ensure that your vendors are educated and conform to your security policies and procedures. Under the Business Partner Agreement provision, it is your responsibility to have your vendor agree to conform to your privacy policies. Therefore, the method of remote access by your vendors should be consistent with your policies and procedures - not the other way around. (Posted 12/6/00)

Does anyone know of a HIPAA Compliant vendor product for clinical management, or utilization management? While the HIPAA team at our firm is planning and investigating the 278 process for authorizations, another group is looking for a Medical Management system replacement. Any suggestions? 
Even after the final regulations, vendors' products cannot be HIPAA security compliant. It is up to the covered entity to determine their security policies and procedures and select vendor's product with security features consistent with those policies and procedures. (Posted 12/6/00)

A hospital client wants to include boilerplate language on purchase orders with vendors stating that the vendor warrants that the computer software/hardware listed on the purchase order is "HIPAA Compliant" as of the date of purchase. We also want to have standard vendor contract language that binds vendors to be HIPAA compliant. Any thoughts on such a practice? 
The covered entity is responsible for compliance - not the vendor. I don't think you are going to be able to put the onus of HIPAA compliance onto the vendor. Any vendor product's ability to support a covered entity's security policies and procedures is dependent on the covered entity's policies and procedures - which of course may vary dramatically. I don't think you can cover the vendors globally - it would be unreasonable to expect that the vendor would have detailed enough understanding of the covered entities policies, procedures and business environment in order to ascertain whether the security features in their products would support those policies and procedures. The covered entity is going to have to understand what specific requirements they need from the vendor, negotiate the inclusion of those requirements in the vendor's product and then hold the vendor responsible to delivering those specific requirements. Also, since any of the vendor's security features would probably not work well unless they were installed and/or configured properly, the vendor cannot be responsible for the covered entity's failure to properly install or configure their security features. 

The vendor cannot be responsible for providing what the covered entity does not know it needs - especially for changes made in the future. For example, if the covered entity changes some of their business processes, they may need to re-craft their security policies and procedures to reflect those changes. The vendor could not possibly predict what changes the covered entity may make to their business processes and foresee what needs that covered entity would have after they changed their business processes. It is entirely conceivable that a covered entity could select a vendor product that would support their current security policies and procedures and then change those policies and procedures whereby the vendor product's security features could not support them. 

Some specific comments on vendor contracts. 
1) Some of this may work for the Transactions formats, but with Security and Privacy, there are no requirements in HIPAA applicable for a vendor's product to be consistent with. Even with Transactions, the vendor can only provide a HIPAA Transaction compliant format. They cannot ensure HIPAA Transaction compliance, since they are not in a position to ensure that the covered entity has the business processes in place to gather the information required to populate the format (e.g. X12N 837 Claim) or the processes required to use the information received in a format from an outside entity (e.g. X12N 835 Remittance Advice). 
2) Since HIPAA does not apply directly to vendors, vendors cannot be in violation of HIPAA law. They can only be in violation of their contract with the covered entity. Therefore any vendor compliance program would be unable to detect violations of law that doesn't apply to them - and could not be responsible for detecting violations of law for their customers. Although I'm far from being knowledgeable of all the appropriate State laws, I do not know of any State laws regarding healthcare privacy or security that would directly apply to or control vendors.
3) HCFA Internet Security Policy (HISP) is also not law and is binding only upon the HCFA contractors (e.g. intermediaries and carriers). For non-HCFA contractors we look to the HISP as a provider of what should be reasonable and diligent levels of encryption and authentication. However, contained within HISP are many options for encryption and authentication. The covered entity would need to determine which of those options, consistent with the HCFA Internet policy, that they want to adopt and how they want them deployed and implemented. The vendor could not be responsible later for the covered entity changing its direction on adoption. Neither should the vendor be responsible for providing all of the options in the HISP.
4) One of the issues that the covered entity should make sure of is that the vendor has in place a process to comply with the covered entity's privacy policies. Those policies should probably be included as an addendum to the contract and the vendor should agree to comply with them. This also brings up the issue of what is the vendor's responsibility to comply with the covered entity's pri