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 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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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
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
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.
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".
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.
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.
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
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.
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.
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.
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