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 privacy policies when they change?
5) The vendor can and should be compelled to comply with the HIPAA security
rule on an organizational level in the same manner that a covered entity
could comply. The vendor should at least self-certify organizational
compliance to the HIPAA security rule. There should be language that states
how often the vendor needs to provide updated self-certification of
compliance to the Security rule. When there are viable third party
accrediting bodies that will certify HIPAA Security compliance, the covered
entity may want to consider requiring HIPAA Security compliance
certification from an accrediting body.
6) When it comes to transactions, the covered entity may want to require the
vendor to comply with STFCS (Standard Transaction Format Certification
System) for any formats that the vendor's product generates. STFCS is
available from EHNAC (Electronic Health Network Accreditation Commission) at
www.ehnac.org to certify
any transactions formats as compliant to the HIPAA Transaction
implementation guides. (Posted 11/21/00)
My company is installing a Virtual Private Network that may not meet
the 128-bit encryption standard. As an internal auditor, I am concerned that
we would not be "HIPAA compliant" in using a lesser standard in
"electronically" transmitting patient identifiable information. I
was told that according to the vendor, HIPAA compliance only applies to
patient information sent over the internet. This is contrary to my
understanding. Is the vendor correct and I am I being overly cautious? Or if
the company buys a product based on a vendor interpretation of the regs.
Does the company have any recourse if later found out of compliance?
I would caution you not to depend on your VPN vendor's interpretation of the
HIPAA Security NPRM. They are dead wrong in any interpretation that "HIPAA
compliance" is only for Internet transmission of patient information.
It is up to your organization to understand the HIPAA regulations, develop
policies and procedures appropriate for your organization and ensure that
you have adequate technologies to support your policies & procedures. If
you choose a vendor product that does not support your policy &
procedures then you have a problem - not the vendor.
1) Under the HIPAA Security NPRM, encryption is only required for open
networks (e.g. non-private, Internet, dial-up, etc.) - all other
implementations of encryption are optional.
2) Neither does the HIPAA Security NPRM mandate a specific level of
encryption or type of algorithm. We obtain our guidance on minimum
encryption levels from the HCFA Internet Policy, Published November 1998
that details requirements for transmission of patient information over the
Internet. Those levels are 112 bit symmetric (3-DES), 1024 bit asymmetric
and 160 bit elliptical.
3) There are a number of different types of VPNs, configurations and usages.
I would need to know a lot more about what you are trying to accomplish
before making specific VPN recommendations - but there is no shortage of VPN
vendors that can provide 3-DES (112 bit symmetric) or better encryption.
4) If anyone needs a copy of the HCFA Internet Policy send me an email with
"HCFA Internet Policy" in the subject line and I will email it
back. There is no such thing as HIPAA compliant software or hardware. There
are not going to be any magic product fixes for HIPAA security. There are
good technology products that can help us implement and enforce policies and
procedures; however, these products (software or hardware) in themselves
cannot be HIPAA compliant. It is the organization that is compliant - not
the products. A product that may be great for one organization may not fit
another one. I strongly suggest completing your assessment and developing
your security strategy, policies and procedures BEFORE purchasing any third
party security products. Then look for products and/or outsourcing that can
help enforce and support those policies and procedures. There are going to
be a number of organizations that can use the security features of their
current systems & applications without having to purchase third party
products.
15. Biometrics
Is Biometrics the way to go for security?
Biometrics has made great strides in increasing accuracy and reducing cost.
There might even be places for biometrics within your organization. However,
the clinical environment may not be one. I don't think the potential of
biometrics is necessarily in strong identification and I reject the
arguments that biometrics are the "only" way to ensure identity
and audit trail. Simple id, password and possibly PIN may not be as strong
as biometrics, but I think that they would be acceptable in 99% of the
environments. The requirements are for authentication that is appropriate -
not absolute. The decision for the strength of access control is a risk
avoidance/acceptance decision that should be made at the sr. management
level based on the risk assessment. There are other alternatives for
stronger levels of identification than simple id & password.
Technologies using VPNs, tokens, password controls or proximity sensors
provide a stronger level of authentication without the potential drawbacks
of biometrics.
33. Audit Trails
It is my understanding that most or all of the HIMS have some sort of
record or audit trail that they generate. The key here is understanding what
is the level of granularity there is in the filtering of the information
gathered and is there a consolidation process that will allow the
information to be gathered across the enterprise? With the right filtering
techniques within a consolidation tool, the information would be very
manageable.
Not necessarily - there are many HIMS, especially those targeted for small
to mid-size practices that do not support audit trails. Any audit trails
would have to be from a third party. There are also a number of HIMS that
would require expensive upgrades to enterprise level databases to provide
the audit trails.
As a Registered Health Information Administrator, I cannot fathom
running an audit trail on every single patient record (well into the
hundreds of thousands annually for a 100 bed facility), then filing the
trail, on paper or electronically, for a period of 7 years (Indiana
retention law). How often must the audit trail be run in order to assure no
unauthorized access has occurred? Monthly? Quarterly? Annually? Can anyone
imagine the hard disk capacity, file room capacity, or FTE's required to do
this and then maintain it forever? This is a crazy waste of our rapidly
dwindling health care dollars.I suppose we could charge the patient for this
service. Yeah, right.
There is the decision to be made of how long is "useful". There
are some strong arguments that are made by the privacy advocacy groups that
lean toward useful is forever. However, archiving the information for 7
years if probably a good compromise.
Does anyone know the exact size text size of the audit report that is
"maintained", I mean the information that is stored that has
identified the user that gained access to the patients files. After all hard
drives are cheap. 15 gig for $100 with 7200 rpm. The audit, and the software
to create reports that satisfy the requirements could be more expensive than
the hard drive. Also does anybody have any opinions concerning the length of
time necessary for storage of an audit trail...(e.g. who and when someone
may have accessed the residents medical record.)?
It's not only the storage - its all the other ancillary "stuff"
that it touches. The immediate physical storage itself is cheap. However,
additional CPU cycles, I/O bandwidth (which may require an upgrade in
storage technology), the additional considerations for disaster recovery,
management and reporting of the information are all items that have to be
taken into consideration when we look at implementing audit trails.
Depending on the types of audit trails enabled - and if they are enabled at
OS or application levels and how often you archive them - you can wind up
doubling or tripling the storage requirements for the databases and
applications - same for CPU and I/O requirements. The physical size and
other requirements for implementing audit trails depends on the granularity
of the audit trails enabled and the amount of information tracked. For
example, audit trails of only user log-on and log-off activity may be
trivial, logging file user accesses a little more intensive, logging record
modifications and additions fairly intensive and logging record reads for
user access to every data element in a record is extremely intensive. There
are NO hard and fast rules for audit trails - only that you have
"them" at some level. Neither is there a requirement that they are
system driven - they could be paper logs. The extent and depth of audit
trails are up to the individual organization, based on their assessment and
what the organization decides they need to accomplish with them. A couple of
ideas about audit trails.
***The last thing in implementing audit trails is to activate the audit trail mechanisms that produce the audit trail data.
1) Establish what it is you need to accomplish with the audit trail. For example, each entity will establish a balance between access controls and audit trails. The narrower the population that has access to the information and the stricter the access controls, the less the need for audit trails. Each entity will decide what the balance is for their organization based on security controls appropriate for their organization. Develop the policies and procedures for monitoring and enforcement.
2) Develop exception reporting that delivers the outcomes desired - this is very important since a key part of the security rule is that any audit trails must be monitored and we don't want to have to hire 20 people to sift through gigabytes of data.
3) Determine what audit trail information is needed to drive the exception reports - take into account all the types of audit trail information that is available and at what levels you need the information (file, record, element, OS, etc.).
4) Figure out what required information your current systems & applications can produce and what the impact will be when you turn them on (e.g. turning on NT audit trails could drive performance to its knees).
a. If current systems & applications can deliver what you need proceed to step 5
b. If current systems & application cannot deliver what you need
i. Re-evaluate the requirement - you may not really need it.
ii. If you really need it and you don't have it already - Investigate & purchase 3rd party and current application vendor products - take into account that some 3rd party products may be able to centralize the information from all applications & systems, reduce the performance cost and make the management and reporting process easier.
iii. Proceed to step 5
5) Implement the audit trails - test reporting and review outcomes.
6) Review outcomes and requirements on an on-going basis. You may have to add more data, but more likely you will be able to reduce the information needed as you work with the reports.
Any comments on who will be held responsible for establishing system
activity logs on an existing system - the vendor or the health
organization?
1) While audit trails are required, it is up to the organization to develop
audit trails that are consistent with their strategic security plan that
takes into account their risk assessment, senior management's decisions to
accept or avoid risk, which may be based on their size and business
needs.
2) I do not expect that larger institutions would have software that does
not provide reasonable audit trail capabilities and the small institutions
may be able to use audit trails provided at the system level.
3) Audit trails should not be implemented without understanding how the
information they produce is going support and enforce the organization's
audit trail policies. The fewer the audit trails to accomplish that, the
better. a. Any audit trails implemented must also be monitored. Audit trails
take a toll on performance and increase storage costs. Therefore, the goal
should be to deploy the minimum level of audit trails that satisfy the need
of the organization. You should first determine what you desire as the
outcome of audit trails and what information is needed to produce meaningful
exception reports that support those outcomes. Once that is established -
ONLY those audit trails that produce the desired information should be
implemented.
16. HHS Authority
Didn't HHS exceed their authority by covering paper and oral
records?
The new report by the OMB reviews HHS's privacy regulations and concludes
that HHS was within their authority in covering paper and oral records. To
quote page 8 of the report: "We find nothing in HIPAA that restricts
HHS' rulemaking authority related to identifiable health records to
electronic data only. HHS states in the preamble to the proposed rule that
it has authority under HIPAA to set privacy standards that apply to all
individually identifiable health information, including information in a
non-electronic form. The privacy protections afforded individuals by HIPAA
would in effect be negated if health information lost its protection merely
by being printed or read aloud.
34. Security vs. Privacy vs. Compliance Officer
1. Should one to use existing personnel and expand their roles, or
establish a new position?2. If you currently have a compliance officer,
should you plan for either of these two roles to be filled by that person?3.
Should either position be filled by someone with a strong technical
background?4. What role will the Director of Health Information Management
(Medical Records) play? Where should the organizational responsibility for
HIPAA compliance efforts fall, information systems, medical records, risk
management or another area?
I think some HIPAA roles could be natural targets for integrating into the
compliance office and taking advantage of dollars already spent. E.g.
Education, hot line and incident reporting. Fact is HIPAA shouldn't be
focused on one office or function. Having said that, someone has to take the
leadership and executive sponsorship roles. One answer for some
organizations is to set up a separate PMO, or equivalent, for HIPAA - with
representation and resource contribution from all departments. (Posted
12/15/00)
In reviewing the proposed HIPAA Privacy & Security Regs, and
comparing them to OIG Compliance Program Guidance for the various sectors of
the health care industry, I have noticed a several distinct resemblances
between a Compliance Officer, a "Security Officer" & a
"Privacy Officer", as well as between the administrative
requirement of the proposed privacy rule, the security standards of the
proposed security rule and OIG Compliance Guidance. Has anyone come across a
compelling reason why the three positions (Compliance Officer, Privacy
Officer, Security Officer) should not be combined into one position provided
that the job description/charters/ resolutions, etc reflect all the
duties?
One of the issues with non-healthcare experienced security personnel is the
patient care issue. People that don't understand the healthcare operations,
interactions between departments and overall clinical needs could wind up
implementing procedures that could wind up to be detrimental to patient
care. It is entirely predictable that a security process could be
implemented in such a manner as to compromise (deny or delay) access to
patient information at a critical time that would create a negative patient
outcome. There will be times when security best practices collide with
patient care best practices - patient care better win - every time - no
exceptions. (Posted 10/17/00)
I am an Information Security Officer, is HIPAA my
responsibility?
I think we need to draw the distinction between "Information Security
Officer" and the Security Officer needed under HIPAA regulations.
1) Under HIPAA, the Security Officer is responsible for the security process
for the entire enterprise, not just IS. Therefore, the Security Officer has
to be at a high enough level to take on the responsibility for the entire
organization and have the authority to back it up across all departments.
(Recipe for disaster = lots of responsibility + little authority)
2) Since about 75% of HIPAA Security is non-IS related (Admin policies &
procedures, physical security, assessment, etc.) it is going to be very
organizational dependent on whether it makes sense for the Security Officer
to be out of IS.
3) Like the Corporate Compliance Officer, The Security Officer should be
free from conflict of interest and operate outside the bounds of the
traditional organization chart. For larger organizations, the ideal would be
for the Security Officer to report directly to a board committee.
HIPAA doesn't provide any specific suggestions about organizational
placement of the security officer. Do you have any suggestions?
It depends on the organization. There are organizations that the Chief
Compliance Officer is also the Security Officer and Privacy Officer and it
works well for them. A Security Officer does not necessarily have to be
technically oriented, as long as they have resources that do understand the
technical components. I think it is more important that whoever fills that
role understands security from an operational and process perspective, and
can relate to the workflow needs of each department of the organization. For
that reason, IS may not be the best place for the Security Officer. I think
it also points to the importance of a Security Committee with broad
representation that can help drive the assessment and implementation process
throughout the organization.
17. Telephone Notification Systems
We utilize an automated phone notification system to remind patients
of appointments. The phone message itself contains no patient identifiable
information and we exclude specific clinic references if specific health
care issues could be inferred, i.e.. we don't use "HIV Clinic or Family
Planning, etc. The message might state "You have an appointment at
Montbello Clinic with Dr. Brown at 2:00 p.m.". We cannot guarantee that
the call will only go to the patient, it might be picked up real time by a
spouse, roommate or be delivered to an answering machine or in some cases to
a wrong number. We ask patients if they don't want to receive a reminder and
what phone number to be used for the call. The system that generates the
info for the calls and the server that processes the calls reside in house.
I would appreciate comments on how this process might be impacted by the
HIPAA Privacy and Security standards.
I think there is are potential problems using these systems. There are no
methodologies to ensure voice message delivery to the correct person. They
be taken by anyone answering the phone (house guests, roommates other family
members, etc.) or may wind up in a community voice mail or answering machine
(family, roommates, etc.) It would not be unreasonable for a patient to not
want ANYONE to know that they have an appointment with ANY physician. There
is also a reasonable chance that the physician's name or the facility itself
may be unique enough to identify what type of and specialty may be unique
enough to identify the type of may be Dr. Brown indicates a potential health
issue. We are currently working with a client to replace this type of voice
messaging with a secure email system (which can also provide secure
messaging between docs, etc.).
35. HIPAA Return On Investment (ROI)
I'm trying to calculate the return on investment (quantitative savings
and qualitative improvements in business and relationships) and would
appreciate any input as far as where the returns are achieved. Also, I've
seen a fairly large number of presentations from consultants and vendors at
conferences recently who say that HIPAA will be the key to e-Commerce. I can
point to a large number of cases where people have created highly successful
e-Commerce initiatives without HIPAA. While there is value to improving
security it's hard to see why this is going to be so Earth moving. Why do
they continue to say HIPAA is so necessary for e-Commerce?
There are huge benefits to HIPAA.
1) Will significantly increase the number of electronic transactions for
both payers and providers - decreases costs by an estimated $1Billion per
month when fully implemented.
2) Since HIPAA Security reaches out and touches every corner of an
organization there is an opportunity to use it as a catalyst to examine and
improve business process and implement technology that may improve
productivity as well as support security policies.
3) I'm not sure that HIPAA is necessary for e-Commerce (e-Health). However,
it may help as encourager to be able to give organizations and individuals
the peace of mind that e-Commerce (e-Health) initiatives meet a standard of
protection and privacy of patient information. (Posted
10/31/00)
What is your view on the ROI of HIPAA?
When it comes to "working" claims prior to sending acute care
claims for the hospitals, there is plenty of room for process improvement.
However, that is not typically the case for ambulatory claims. Even given
the handling issues on the acute care side, the ROI on HIPAA can still
stand-alone. There are some significant advantages to standardizing the
formats and code sets. It is estimated that the industry is wasting about $1
Billion per month just on not standardizing transactions. Here are a handful
of examples...1) Standard claims format eliminates the programming and payer
relationship time spent maintaining disparate formats and tracking the
differences in requirements from payers. It will also heat up the
competition among clearinghouses and can drive payers working together to
set-up central web enabled sites for receiving claims -thereby eliminating
the clearinghouse charges. 2) Standard remittance advice provides a viable
method via the X12 835 to automatically post payments. Most institutions
today only post electronic remittance advice (ERA) for Medicare and less
than a handful of other commercial/government payers. This is because of the
cost of programming their A/R system to handle disparate (and mostly
proprietary) ERA formats. Also, the unreliability of most commercial ERA
precludes their use. This ability to post ERA will generate a huge
savings.3) Only a few payers today handle eligibility and authorization
requests electronically, most again are proprietary formats. Under HIPAA,
all the payers will have to provide these capabilities via EDI that will
save providers enormous amounts of money.4) Standardized code sets eliminate
the maze of proprietary local codes that some payers are using today.
Standardizing on these codes will eliminate a great deal of effort on the
provider's part to try to track and implement these disparate code systems.
5) When the attachment standard is approved, it will eliminate huge efforts
of consolidating information and "mailing". Incidentally - when
the ICD-10 sets for diagnosis and procedure are rolled out it will eliminate
most needs for attachments since the ICD-10 code sets contain a much deeper
level of information than what is available today. There is also ROI
possible on Security, provided it is addressed properly. HIPAA security
implementation can act as a catalyst to re-engineer and improve workflows,
and introduce workflow and productivity improving technology.
18. Mobile Computing (Palm Pilots, Laptops…)
What kind of policies are organizations putting in place to protect
data on Palm Pilots and laptops?
With the exception of physical controls, those issues will not be a lot
different than protecting information on the desktop workstations. The
challenge is going to be enforcing and monitoring the policies. Depending on
the organization, that may mean using NT, bios passwords, etc.
Our medical center has research areas that recruit public volunteers
for various studies, e.g. drug effectiveness. Of course, the records are
electronic and identifiable back to an individual. Does HIPAA apply to these
electronic records?
I believe the short answer is yes...
1. We use a generic Novell login to get into the desktop, thereafter,
a nurse must use a unique login and password to enter into the patient care
database. If I understand correctly, this meets all existing HCFA, HIPAA and
JCAHO standards.
2. Our problem resides in the use of workstations within the acute care
hospital environment: we never know which pc will be available for our use
for the 3.5 minutes we have available for review and documentation. Due to
this, we use a generic login with separate application based logins.
Although it isn't pretty, it works. What is your feeling on this when the
proposed regulations are subject to change? I cannot sell the idea of
spending money to meet standards that are not finalized.
To answer the first question, it would be more helpful to know more about
your environment. However, if such an environment is set up in a manner that
a generic login gives users access to ONLY a desktop - and that desktop
denies the user the ability to access any patient information, including any
directories or files which may contain patient information (e.g. Word,
Excel, Access databases, text files, etc., etc. that may contain patient
information) - without the user entering a specific user id and password to
access patient information, then you may have an argument to using the
generic login to access the desktop. Then, you would need to ensure that all
your audit trail requirements not include information at the system level.
Therefore, all your audit trails would have to come from some application
level generation (including Word, Excel, Notepad, etc.).
Now, assuming you could set up such an environment, I would question the reasons why you would want to negate the use of system level audit trails - which would not be useful with generic system logins. I don't know what your audit trail requirements are going to be, but I would think that you would want the option of using potentially less granular system level tracking rather than having to depend so heavily on application level audits.
By the way, the internal control requirements for HIPAA Security and Privacy far exceed the external control requirements. Assume you have a covered entity that does not have access to an open network (e.g. Internet) and you'll find that amount of work needed to comply has not been reduced very much.
In answer to the second question, I'm not sure that a shared workstation environment - especially in the clinical areas - has much choice in using a generic network login. It appears as though your nursing caseload is already high and it reduces the time available for patient care to have the clinical staff to re-login. To compensate by increasing the nursing and physician staffs doesn't make a lot of sense either. Unfortunately, this is one of the areas where best security practices may conflict with the realities of patient care - and reducing patient care should not be an option.
This will lead to drawbacks in that you will lose some system level audit trails. Audit trail issues are where you are going to have to be careful and denying access from these workstations to applications such MS Office may be necessary. Additionally, you have to think about other areas where the lack of system level authentication could compromise audit trails (e.g. email, Internet access, etc.).
One option may be Single sign on (SSO), which probably has the best potential for these environments and may provide the opportunity to at least recover the productivity lost in enforcing automatic logoff. Most SSO products will provide audit trails to the application access level - but again, most single sign on products do not handle the system login level very well in a shared workstation environment. Remember, when choosing single sign on, it is going to be important to really dig in at the evaluation stage to determine which vendor is going to handle the multi-use workstation environment the best. (Posted 11/21/00)
I am struggling with the issue of password change intervals, and would
be grateful to anyone who would provide me with some direction.
There is a lot of conflicting opinion on forcing password changes. There is
one camp that believes that forcing password changes actually increases the
risk because it increases the likelihood that the user will write down their
id & password in an easily accessible place. Another camp insists that
best practices dictate changing them every 30 days. I don't think there is
any "right" answer and each entity will have to justify how they
apply it their business and develop policy accordingly. This is another one
of the risk acceptance/ avoidance decisions that need to be decided and
documented at the organizational level. I would not recommend IT making this
decision unilaterally and attempting to impose it on the rest of the
organization. (Posted 9/15/00)
38. Paper vs. Electronic Transmissions
I feel it is too soon to
write off the HCFA 1500 or the UB92 paper format as not being able to be
successfully converted to a HIPAA compliant transaction. In fact, some of
the work I've seen done on this to date shows that there are some ways to
overcome this data content gap. What is your opinion?
When it comes to translation of the 1500 (and even the NSF) to the837 v.
40.10 HIPAA compliant implementation I have some concerns. The methodologies
that I have seen to date for translation from the 1500 and NSF to the 837 v
40.10 implementation involve deriving and plugging data from deduction,
static tables and interpolation - all of which to some extent involve
"creation" or manipulation of claim information. This carries a
risk of changing the information that is used for adjudication that can
result in overpayment or underpayment of claims. I can tell you from
personal experience that using those methodologies for Medicare claims can
create issues with fraud and abuse compliance that, at best, can be very
difficult to explain to the OIG. The commercial risk may not be as great -
but I wouldn't count it out. There is also no practical way to provide
translation of some of the current coding to correctly populate the
Transaction. "J" codes don't translate to NDC, trying to provide
local code translation back to standard codes doesn't make sense and
translating coding practices such as the current anesthesia coding to
compliant coding would be convoluted.Providers are going to have to make
changes in their processes and I think it would be far better for the
provider to incorporate those changes to capture and provide the needed
information at the front end of the process then try to "create"
it on the back end. (Posted 9/15/00)
39. Employer or Covered Entity
My organization is a covered entity. However, within the
organizational structure we have a couple of services that if they were
"stand alone" would not be covered entities as they do not perform
any electronic transactions. 1) One is a nurse advice line. They collect
some patient demographics as a part of the call process and do have an
information system that stores this information. And if the caller is a
patient of the organization the information may be communicated to their
primary care provider. 2) The other is a poison/drug center (the 800# called
in an emergency). This center provides poison triage service for a
multi-state region. It also has a business line that contracts with
manufacturers to take, record, and report (back to the manufacturer)
exposure/reaction to various sorts of chemicals (the Material Safety Data
Sheet stuff) and for some drug companies is the national center to take
calls of potential adverse drug reactions - which are then reported to the
drug company and the FDA. For all functions some patient data is collected
and reported. OK, now for the question. It seems the adverse drug reaction
is covered public health activities addressed in disclosure without
individual authorization - at least to the FDA, but not to the drug company.
I'd appreciate thoughts on how the privacy rules about the use or disclosure
of protected health information and need for authorization for release of
information impact these entities?
1) These would still appear to be covered entities under the provider
definition. 2) All the activities appear to be treatment, payment or
healthcare operation oriented in that they contribute to the improvement in
patient care. 3) While disclosure to the drug company is a question mark,
you may still be able to make the argument that it is for the purpose of
improvement in quality of patient care. You would probably not have to
obtain authorizations for disclosure, but may have to track disclosure to
the FDA & drug companies. 4) That being said, the legal eagles may see
disaster coming with that opinion. (Posted 10/31/00)
Could someone help me better understand
the following: As a covered entity (we are a hospital system) we are required
to comply with all the final rules and standards for EDI transaction,
including Health Care Premium Payments and Coordination of Benefits
standards. HHS comments on the final rules indicate that Employers/Sponsors
are not required to meet the standards (although they are encouraged to
consider doing so). Does this mean that as a covered entity we must fully
comply, even though we are also acting as an Employer, the same as
non-covered entities, with regard to EDI transactions for our employees
premium payments to their selected health plan? This seems to be a bit
unclear to me, and perhaps not completely equitable. Other employers do not
have to comply, but as an employer and a covered entity, we must.
If an employer is taking on the "role" or functions of a health
plan as defined in the rule then they would be a covered entity for that
role or function and would have to comply with the standards for those
transactions that would be applicable to that role or function. In fact, one
of the examples given for application of the final rule is an employer who
is self insured and therefore has established a health plan, is a covered
entity in that role or function and must ensure that their business
associates (e.g. insurance companies acting as TPAs) conduct their
transactions (on their behalf) using the applicable standards. See Example 2
- Federal Register page 50317, third column. (Posted
9/19/00)
40. Healthcare Information Confidentiality Act of 1999
Does anyone have a link to the Healthcare Information Confidentiality
Act of 1999 (HICA)?
HICA (The Health Information Confidentiality Act of 1999) was never passed.
It was attempt at comprehensive privacy legislation that never made it out
of a Senate markup committee. (Posted 9/19/00)
This question is hard for me to formulate in an understandable manner,
but here goes: The rule defines a clearing house as an entity that (a)
Accepts non-standard transactions and translates to standard transactions,
or (b) Accepts standard transactions and translates to non-standard
transactions. Can it accept non-standard transactions and translate into a
different non-standard transaction? Can a provider (hospital) use a
clearinghouse and send claims in a non-standard format (part (a) above) for
transmission to a payer or 3rd party payer who has enlisted the
clearinghouse so they can accept non-standard transactions (part (b)
above)?
It appears that a provider can send a non-standard format to a clearinghouse
that in-turn converts it to another non-standard format for a payer (without
any apparent requirement for it to reside in standard format at any point in
the standard format). The caveat is that both entities must have a contract
with the clearinghouse for translation and that the clearinghouse must be
able to accept a standard transaction in the payer's behalf.
However, the argument may be moot because of some practical limitations.
1) Providers send transactions to more payers than a clearinghouse would
have translation agreements with. Most payers will be able to accept the
standard transactions directly and would want the clearinghouse to send them
the standard transaction. Therefore, the provider would still have to
provide the minimum data set to the clearinghouse to enable the translation
to the standard format for payers not contracted for translation with the
clearinghouse.
2) The vast majority of PPM/HIS vendors will give providers the capability
of sending standard transactions. It will be advantageous for the payers to
be able to accept standard transactions to reduce their clearinghouse costs.
For some of the same reasons it will be advantageous for the providers to
send standard transactions - especially since they will have to be able to
provide the minimum data set. (Posted 9/19/00)
I think that this "maximum field length" question is one
that is still open to interpretation. I haven't seen any citation in the
Rules that is absolutely clear on this. (If you have one, I'd love to see
it.) Until I see a citation that is not open to interpretation, I'm going to
interpret the rule as saying that, while we have to be able to accept a
standard transaction that uses the maximum length on every field (in other
words, we can't reject the transaction just because a given field has more
characters than I can handle), 1. My MIS doesn't need to store the full
maximum length of every field. I can truncate the field before I store it in
my system. 2. I can accept fewer characters than the maximum in my DDE or
browser-based application (since, given #1, I wouldn't have any place to put
the extra characters in my MIS anyway). Citations proving me wrong are
welcome.
Although you are probably technically correct in regards to receiving and
processing an 837, you may want to look at a couple of potential problems
with handling it in that manner - especially since the use of the last name
doesn't end with you. There would be complications if a provider sends you
an 837 with a 30 character last name (not likely but with hyphenated last
names could occur and we'll use it here for the sake of an example). If you
truncate it to 25 characters to fit your system, you would not be able to
accurately populate the last name field in the 835 that would be returned to
the provider - this would create a problem for the provider and not be
responsive to the rule. This would not be the case in a provider system
whose system's last name field length is only 25 characters. If they
truncate the last name to 25 characters and send it an 837, the return 835
last name field would still match the last name in their system. They would
have a problem however, if they generated a 270 from information in a
truncated last name in their system. The last name in the 270 would not
match the last name in the health plan system and could generate a false
denial (unless of course the health plan also truncated the last name to 25
characters). (Posted 12/15/00)
I have a couple of questions related to the adoption of the 837
transaction related to COB as follows:
1. Is it true that a health plan will always require a trading partner in
order to conduct COB transactions with other payers?
2. If a trading partner does not exist, the health plan can dispose of the
COB information and leave COB to the provider? I need clarification on this
point.
3. I am having problems finding the distinction between claim and COB data
elements in the 4010 Implementation Guide as referenced in the Federal
Register. Do you know where I can actually find the notes that identify when
a particular data element is to be used for COB?
1. I am not sure what you mean by Trading Partner in this context. Payers
could certainly send COB directly to one another and they would be Trading
Partners. If what you mean is Clearinghouse - there is no requirement for a
Clearinghouse for COB transactions.
2. Again - I'm not sure what you mean by Trading Partner - If a payer sends
a claim to another payer for COB, they are both Trading Partners. It doesn't
make sense that the payer would dispose of the information and leave COB to
the Provider - They would only be receiving a COB if they had an agreement
to receive COB entity sending it.
3. For COB usage in the 837 read the implementation guides. See page 28 in
the Institutional Claim Implementation Guide, page 30 in the Professional
Claim Implementation Guide and page 26 in the Dental Claim Implementation
Guide.
4. Once a health plan has a Trading Partner agreement with ANY entity to
receive COB transactions electronically, they must accept them in the HIPAA
Standard (837). See page 50336 of the Federal Register (final Transaction
Rule). (Posted 12/15/00)
I am a software vendor producing claims for Laboratories. My question
has to do with the eligibility piece of the transactions ruling. Do any of
you understand if the requirement is that eligibility must be checked and an
authorization remitted to allow the provider to bill? Or is it that if the
provider chooses to know eligibility prior to providing service, the
required secure eligibility-checking format must be used?
That would depend on the business practice of the provider. Eligibility or -
more likely - authorization prior to billing could also be mandated in the
contract between the provider and the health plan. There is no requirement
in HIPAA for providers to request either eligibility or get authorization
before performing services. However, if a health plan provides eligibility
and/or authorization services then they have to electronically accept and
respond via the standard eligibility and authorization standards. (Posted
12/15/00)
If a payer receives a covered transaction, for sake of dissuasion a
claim, and forwards that to another payer, does the transmission between the
two organizations have to be in the HIPAA X12 format or can they use
existing proprietary formats for this business?
Once a health plan has a Trading Partner agreement with another Health Plan
or ANY other entity to receive COB transactions electronically, they must
accept them in the HIPAA Standard (837). See page 50336 of the Federal
Register (final Transaction Rule). (Posted 12/15/00)
Here is a standard transaction question. Our company (a healthcare
system) offers health benefits to its employees via a self funded
"PLAN". It uses a Third Party Administrator (TPA) to run the plan.
The TPA is a wholly owned subsidiary of the company. So, in this case, we
are a provider, payer, employer, and business partner.
1. If the company's personnel office sends new enrollee information
electronically, to the TPA, does it have to be in the standard format?
2. If the TPA sends monthly "Encounter Information" to personnel,
does that have to be in standard format? (And then, how would they view it.)
They currently get something like an excel spreadsheet which can be viewed
using common hardware and software.
1) I do not believe that there is any requirement for transmission of HIPAA
standard transactions between a covered entity and any other non-covered
entity, including business partners. 2) You can essentially demand a
standard transaction from your health plan. The health plan must provide you
with a standard transaction for any service that they provide that could be
conducted via a standard transaction. That includes services such as; claims
acceptance, remittance advice, claims status, eligibility, enrollment and
authorization). They do not have to provide a standard transaction for a
service they do not provide nor for a service that does not have a
corresponding standard transaction (e.g. check payment). (Posted
12/6/00)
Any reaction to the Insurance Industry's statements today that they
intend to effectively gut the transaction standards and implementation
plan?
I don't yet see evidence of a strong support base to any implementation
delay from the payer community - not even from the Blue payer community for
which the delay initiative is purported to have emanated. (Posted
11/21/00)
I have it from a reliable Insurance source that the industry will not
allow unique provider ID's as it will destroy their current systems. They
would have to be reworked and it would be too costly. They are going to
fight it all the way.
1. Even if the implementation was delayed on a federal level, New Jersey has
actually passed legislation shortening the implementation period to 12
months and it appears that some other states could be ready to follow suit
(e.g. Utah). Since the opinion appears to be that these State laws are not
contrary to HIPAA, and therefore not superceded, then any federal delay in
implementation would be moot - at least for national payers, or those not
willing to give up their healthcare business lines in those states. It
wouldn't take very many states to put a monkey wrench in any federal
implementation delay.
2. The transactions are perceived to be the primary driver for ROI - there
is just too much money on the table ($1B per month) for a delay to get a lot
of congressional support.
3. There are components of the implementation guides that could be extremely
problematic for some entities. SNIP is currently collecting a list of these
issues and working on developing strategies for complying. If SNIP could not
find a solution, then there may be reason to ask for a delay of a particular
component to the implementation guide until resolution - but not the entire
transaction.
Regarding provider identifiers: I don't think there is a high risk of
non-compliance by Federal or State agencies. HCFA appears to be sending
signals that they will be very aggressive in compliance issues and they have
a pretty good size hammer. The States have been notoriously resistant, but
the signal so far from HCFA is that they are not very sympathetic to State
non-compliance. (Posted 11/21/00)
Today, in almost all cases, clearinghouses return claim status reports
to their providers electronically in a text format. Those reports are most
commonly printed to hard copy, reviewed (hopefully), and stored on paper.
These reports include status messages ranging from front-end rejects (claims
rejected by the clearinghouse) to detailed adjudication messages from the
payer. Does HIPAA require that the clearinghouse now return these status
messages to the provider in the ANSI 277 or is it only if the provider
requests it? Can the reports continue to be sent in a text file? If so, does
the text file have to meet HIPAA's data requirements?
Clearinghouses can translate standard format and content to non-standard
format and content for either payers or providers. Therefore, they can
accept a payer's 277 and translate it into a non-standard format and content
(e.g. text file) for the provider. Also, the 277 is not a covered HIPAA
transaction, so you're free to do whatever you and your trading partner
agree. (Posted 11/21/00)
Can I send the 277 as an unsolicited claim status if I have an
business agreement with a provider to do so?"
Yes (Posted 11/21/00)
Here is the situation: A payer organization (let's call it "Big
Payer") has developed a system whereby it supplies for all of its
providers in their state, the ability to FTP HCFA 1500 flat files to them.
Big Payer provides this system either for free or at a nominal fee to their
providers.
1) Under HIPAA, can the payer continue to receive HCFA 1500 flat files from
their providers? (Big Payer promises to translate the flat files coming in
from the providers into HIPAA compliant 837's before they ship them off to
their backend adjudication systems)
2) Under HIPAA, can the provider continue to send HCFA 1500's to the payer
or would the provider be considered negligent and in violation of the Final
Rule - possibly risking fines? The final rule clearly states that only
Clearinghouses can receive and translate non-standard formats.
3) Can Big Payer simply state that they are now both a Clearinghouse and
Payer and "get around" the requirements that way?
It is my perception that there are several payers out there who plan to
continue to accept HCFA1500's flat files, NSF, and UB files. These payers
state that they will re-format the claims for the providers to a HIPAA
compliant standard. Obviously, unless the HIPAA-police investigated, no one
would be the wiser as to whether the payer actually reformatted the claims
or not. (fyi - "Big Payer" does not represent any particular or
specific payer organization of which I am personally aware)
Assuming that the entity is a payer and not a clearinghouse ….
1) No - the payer can only receive non-standard transactions from a
clearinghouse.
2) No - you are correct the provider can only send non-standard transactions
to a clearinghouse for translation.
3) I suppose "big payer" could set up a subsidiary that operates
as their clearinghouse. However, any the provider still would not be able to
send a HCFA-1500 flat file - so simply taking in a HCFA-1500 or NSF isn't
going to fly - even to the clearinghouse.
To clarify item 3: here is a "data content" provision in the Transaction Rule which requires that any communication done using non-standard format still must contain the standard data content, however, it is a requirement only for direct data entry. A provider can send non-standard format and content to a clearinghouse to be converted into standard format and content and submitted to a payer. Conversely a payer can contract to a clearinghouse to receive information from a provider in a standard format and content and convert it from a provider and convert the standard format and standard content into non-standard format and non-standard content.
However there still is a problem that providers may have with sending less information than is required in the standard data content. While there may be some information that a clearinghouse could effectively create and/or manipulate - coming from direct experience with the OIG - I can tell you that when it comes to content that is used for adjudication - if there is not a direct 1 to 1 correlation of the translation of non-standard content (e.g. codes) to standard content, that the provider could run into some fraud and abuse issues. The OIG wants to know that the information sent by the provider for adjudication is the information received by the intermediary.
The paper form content does not lend itself to accurate translations. One Example: When you look at Box 33 on the 1500 form, it typically contains the provider's remittance address - that is where they want the check sent. However the 837 is looking for both the pay-to address and the address where services took place. The adjudication rules could be much different for the place of service than the remittance address. For example, if the remittance address were in Chicago, IL and the place of service was in Bloomington, IL the payment rate would usually be less for Bloomington than for Chicago. Therefore, any claims sent with a place of service of Bloomington and a remittance address in Box 33 of Chicago could be overpaid. Conversely, if the place of service was Chicago and remittance address Bloomington, the provider could be underpaid.
While there are ways to get around this one issue from the clearinghouse side it requires quite a bit of coordination. For example, the clearinghouse and provider could agree that the provider always populates the place of service in Box 33 and the clearinghouse could populate the remittance advice address in the 837.
Unfortunately, that is not the only issue. Another example is that there is not always a direct translation between the code sets (e.g. place of service, type of service, etc.) used on the 1500 and the current NSF with the code sets in the 837 data elements. The bottom line is that while it is theoretically possible for a clearinghouse to accept non-standard data content, I would not advise a provider to send non-standard content because of some of the problems that could occur in the translation process. (Posted 10/31/00)
Are providers required to submit claims and claims status requests in
standard format to Medicare and Medicaid FISCAL INTERMEDIARIES? (In other
words are intermediaries regarded as clearinghouses or as health plans under
the law?)
Medicare and Medicaid Intermediaries are payers and, like all payers, cannot
accept non-standard transactions. Providers have to send standard
transactions, unless they use a clearinghouse and payers must receive
standard transactions, but they also may use a clearinghouse to receive
standard transactions and translate into non-standard transactions. (Posted
10/31/00)
After reading through the regulation, I have some questions:
1) Are TPAs a business associate or a covered entity?
2) When interacting with the TPA as an employer, the employer is not a
covered entity. (Enrollment data)?
3) When interacting with the TPA as a payer, the employer is a covered
entity. (Payment information)? If they exchange standard transactions with
the same TPA, as a provider, do they have to comply with the rule?
1) In most all cases a TPA will be a covered entity. Since they are actually
adjudicating and paying claims - even on the behalf of the employer - they
fit the health plan definition.
2) An employer would not be a covered entity except to the extent for which
they operate as health plan
3) An employer using a TPA for all the administration of the plan would not
be a covered entity and would not have to exchange information with the TPA
in a standard format. (Posted 10/31/00)
I am wondering if anyone can
clarify/verify how a transaction must be processed in the following
scenario: When a Provider and Plan use the SAME Clearinghouse, must the
Clearinghouse translate the Provider's Non-Standard transaction into a
Standard format (internally) prior to translating it into the Plan's
Non-Standard format?
It would seem that this is the only way to comply with the regulations set
forth for Clearinghouse transmissions between Senders and Receivers. I
understand the requirement of the minimum data set usage for the provider
sending claims to a clearinghouse since the provider would have to send all
the data necessary for the clearinghouse to translate into the standard
format. However, since the payer may be contracting the other way - that is
the clearinghouse to receive standard format and translate into non-standard
format - there should not be a requirement for the payer to have to change
their non-standard format to accept information that they do not need or
want. (Posted 10/17/00)
Employers are not covered entities under HIPAA; they are not required
to use electronic transactions, and if using them are not required to use
the standard specified in the 45 CFR Parts 162.1501 and 162.1701. If an
employer (sponsor) chooses to send an electronic transaction for these
functions in a non-standard format are health plans required by the rule to
accommodate and accept the non-standard transaction?
It is a business decision by the health plan and would depend on the health
plan's contract with the employer - they don't have to take anything they
don't agree to take. However, since the employer pays the bills they may
want to make some accommodations. (Posted
10/17/00)
Two questions
1. If a physician-type provider-entity electronically requests a service
from my entity, i.e. some testing/treatment, that transmission should meet
the security standard, right? As opposed to the transaction standard? I mean
the definition of "transaction" doesn't seem to include requests
for service, etc....so the requesting provider entity is obligated by HIPAA
to transmit the request (if electronic) in a secure fashion. Right? I would
hammer out this expectation with an agreement / COT / contract, etc.
2. The definition of *health information* includes information
"received".... the information that is received should be
transmitted to our site and arrive in compliant format, right? Should I be
able to expect that? Isn't this the point of simplification?
1) It doesn't sound like the transactions you are speaking of are any of the
named transactions, so there is no format standard to comply with.
2) The security regulations speak to the protection of ANY patient
information - whether or not it is communicated using a transaction
standard.
3) I presume you are speaking of requests for OR scheduling, lab, radiology,
etc. Since you are both covered entities, I would lean toward some form of
trading partner agreement with chain of trust language.
4) I am not sure what information you are speaking of in your second
question - if it is information covered under the Transaction regulations
then it would need to be in a standard format. (Posted
10/11/00)
I am unclear about the relationship between ASC X12N and HL7 formats.
I don't see HL7 mentioned anywhere in the Transaction standards for HIPAA.
Has anyone out there gotten an answer to this yet?
1. HL7 formats tend to be inter-organizational - but intra-application. That
is, formats for sharing information between disparate applications.
2. ANSI X12N formats are designed to be used for the communication of
information between organizations for specific purposes (e.g. 837 = claims,
835 = remittance advice, 270/271 = eligibility request/response, 277/278 =
authorization request/response, 834 = Enrollment).
3. All the HIPAA Standards for formats are ANSI X12N based version 40.10
(except for pharmacy, which is NCPDP). There are no HL7 standards adopted by
HHS for HIPAA. However HL7 is expected to be a part of the claim attachment
draft standard, which may be published later this year. Indications point to
HL7 being used in conjunction with ASC X12 275 for: Ambulance, Emergency
Department, Rehabilitative Services, Medications, Notes, and Lab Results
4. You can download all of the implementation guides for the ANSI X12N
standards at the Washington Publishing site www.wpc-edi.com
- all are available at no charge. (Posted 10/11/00)
43. Retail Drugs and the Internet
Given the following scenario, I'm curious to know if HIPAA will have
an impact: Patient accesses, through his/her own ISP, a portal that allows
the patient to request a refill. Information requested is standard
demographics and the prescription number. Since this scenario carries no
medical data, other than the prescription number, is this transmission
impacted by HIPAA in terms of security and/or patient privacy?
1) The pharmacy fits the definition of provider (e.g. health services) and
therefore is a covered entity.2) Patient demographics are covered under the
protections and...3) I think the prescription number would be a unique
identifier linked to patient information and therefore also covered. Under
the Security NPRM - the information transmitted over the Internet would need
to be encrypted. Using a secure server and forcing the patient to use a
browser supporting 128 bit SSL should serve the purpose. For authentication,
the patient could use a password & id - provided that appropriate
policies and procedures were in place for identification and management.(Posted
10/17/00)
Would the ISP be considered a Business Partner? If so, then would the
Data Security and Privacy requirements apply?
The connection between the pharmacy and the ISP is only an issue if the
pharmacy gives the ISP access to patient information in the course of
providing services. If the information is encrypted from the patient's
browser to the web server at the pharmacy - then the ISP would not have
access to patient information and would not be a Business Partner. However,
if the ISP hosted the web server and personnel at the ISP had access to
patient information that was stored on that server, then the ISP would be a
Business Partner and they would have to comply with Privacy and Security as
part of the terms of their agreement with the pharmacy. (Posted
10/17/00)
How can the covered entity, in this case the pharmacy, force the
person requesting the prescription refill to encrypt the request, even if
the pharmacy is providing a web site for receiving the protected
information?
The web server can be set up to restrict access only to those persons using
browsers which support a 128 bit encrypted SSL session.
(Posted
10/17/00)
How will the HIPAA rules apply to hospital websites that have on-line
nursery's listing baby's date of birth, parents' first names, etc?
The hospital would not be able to post that information without the
patient's authorization. You also need to make sure that your privacy
policies cover all areas of potential or anticipated disclosures of patient
information outside treatment, payment or healthcare operations - you will
still need the patient's permission to disclose, however if an area of
disclosure it is not stated in your policy then you will not be able to make
such disclosure - with or without the patient's permission - until you
change your policies and make notification. (Posted
10/17/00)
45. ID Cards
Rumor in the PBM world says that "group number" will be
required on ID cards by HIPAA. Does anyone know of any foundation to that
rumor?
There is not a mandate for a group number on an id card. However, there is a
health plan identifier NPRM that will be released that would set up an
identifier for each health plan (not necessarily the group)- so it would
behoove the payer to include their health plan id on their id cards. (Posted
10/17/00)
46. Definition of Data Content Compliance
We are looking for a clear, concise definition of data content
compliance, at least as clear and concise as we can get. Is it correct to
say data content compliance addresses the following areas:
1) Absolute or conditional requirement of a data element as defined in the
IG AND
2) Data element definition/usage based on the IG (a Provider Identifier is
always an id of a provider) AND
3) Data attribute compliance - data type (numeric, string etc.), field
length and field values (std values)?
For example, If a provider (a covered entity) is sending claims information
to it's contracted clearinghouse (also a covered entity) in a proprietary
format what data must be included and in what form?
1) Must a data value be provided for all absolutely required data elements
from the 837 IG plus those that are conditional that become required based
on the condition(s) being met (i.e. if the provider is an ob/gyn then....
must be included)?
2) Must the meaning of each data value comply with the intended definition
of its defining data element as outlined in the IG?
3) Must the values themselves match the requirements in the area of data
type, min/max field length and use the std values where applicable?
I agree with your interpretation of "content" compliance as it
relates to the IGs. The use of IG "content" requirements would
apply to direct data entry situations where the standard content
requirements (data content and data condition requirements) must be met, but
not the format requirements. Regarding clearinghouses, I believe the final
regulation is clear on this point. In summary, it allows a clearinghouse to
accept non-standard transactions (e.g., nonstandard format and/or
nonstandard data content) and translate it into a standard transaction. I
interpret this to mean that any nonstandard data content may be sent to the
clearinghouse so long as the translation "rules" agreed to between
the sender and clearinghouse clearly define the "map" from
nonstandard to standard content, including conditional data requirements.
This does not mean that a sender must provide the data in the standard
content requirements or provide data elements for each required and
conditional field, but rather provide the minimum data needed to
generate/translate information by the clearinghouse into data that meets the
content and format requirements for required and conditional fields. This
requires detailed analysis of transactions that you may be looking at for
such clearinghouse translation services. If absolute rules cannot be defined
for translating certain information into the standard format/content, you
would need to send such information using the standard. I would expect that
many nonstandard elements can be translated using such rules, but you may
find that it is not feasible to define rules for every nonstandard data
element. Your question regarding address changes from members to health
plans via the internet suggests an 834 consideration. The health plan is not
required to conduct such transactions using the 834. There are two major
points to be made here. First, health plan members are not covered entities
and the health plan may conduct such transactions as deemed appropriate
concerning format and content. Second, if a non-covered entity, such as an employer, sends enrollment transactions using the 834, the health plan must
accept the standard transaction for processing. (Posted
10/17/00)
47. Patient Satisfaction Surveys
Our hospital is considering using an outside source to survey our
patients. We would send them a list of patients who would in turn send
survey questionnaires to our patients. The survey cover letter would have
our hospital's logo on the cover letter. The results are used to provide us
with performance indicators that can be used for quality improvement. Will
HIPAA require that we get the patients permission to send their information
to the survey organization, or will a chain of trust agreement
suffice?
1) Disclosing patient information to an outside non-covered entity acting on
your behalf is not a Chain of Trust issue - it is a Business Partner
Agreement issue.2) If you can make a strong enough argument that quality
improvement would be covered under "healthcare operations" then no
patient authorization would be necessary. (Posted
10/17/00)
I was told that there is a federal mandate (HIPAA?) that states that
our entire facility must be backed up by emergency generators so we can
continue to function in the event of an emergency/disaster that results in
the loss of normal utility power. Is this correct? If so, is there a date
that the emergency power system must be in place and functioning? Is there a
dollar limit that we are expected to spend? Which systems are required to
have connections to the emergency power supply, if not all? Will fines be
imposed if these requirements are not met?
HIPAA is the federal mandate the, however, it is not nearly as specific as
you have referenced. HIPAA tries to provide standards for EDI to streamline
the processing of information between providers, payer and clearinghouses.
To that end the standards specific are variety of regulations to protect
this information. The Security Standards require a covered entity to
"assess potential risks and vulnerabilities to the individual health
data in its possession and develop, implement, and maintain appropriate
security measures." The regulations go further to specify specific
areas that need to be considered. The following were excerpted from the
proposed regulations:
(3) A contingency plan, a routinely updated plan for responding to a system emergency, which includes performing backups, preparing critical facilities that can be used to facilitate continuity of operations in the event of an emergency, and recovering from a disaster. The plan must include all of the following implementation features:
- An applications and data criticality analysis (an entity's formal assessment of the sensitivity, vulnerabilities, and security of its programs and information it receives, manipulates, stores, and/or transmits).
- Data backup plan (a documented and routinely updated plan to create and maintain, for a specific period of time, retrievable exact copies of information).
- A disaster recovery plan (the part of an overall contingency plan that contains a process enabling an enterprise to restore any loss of data in the event of fire, vandalism, natural disaster, or system failure).
- Emergency mode operation plan (the part of an overall contingency plan that contains a process enabling an enterprise to continue to operate in the event of fire, vandalism, natural disaster, or system failure).
In a nutshell, the plan needs to assess their security needs within this context and make a business decision regarding the need for a backup power source. (Posted 10/17/00)
I have heard (haven't verified) that JCAHO and other accreditation
bodies will be surveying re HIPAA. Makes sense to me, but does anyone have
an actual cite to something written about JCAHO's plans regarding HIPAA?
It is my understanding that if during an audit, JCAHO uncovers a HIPAA
Security violation that they will address that in their audit process.
However, passing a JCAHO audit will not mean that a hospital is HIPAA
Security compliant. (Posted 10/17/00)
50. Paper Claims
Currently we use a UB-92 and a HCFA 1500 to submit paper claims,
regardless of the format used for EDI. Silly me - I assumed that when health
care moves to the identified X12 837 standards that paper formats would be
revised to essentially mirror that data content and format. I'm now pretty
sure I am wrong, that we will continue to us the UB-92 (or its successor)
and the 1500. I've looked at the NUBC and NUCC websites and haven't found
them particularly helpful in answering this question. Can you clarify the
paper formats in the brave new HIPAA world?
It is my understanding that NUCC looked at modifying the HCFA-1500 to
contain the minimum data content required in the X12 837 ver. 40.10
Implementation Guide, figured out that it would take a three-page form to
handle it and decided that they would not change the 1500. I don't know what
happened with NUBC, but I haven't heard of any new UB-92's coming up. (Posted
10/31/00)
51. HIPAA Compliance - Who Is Covered
I was wondering if you could point to a website that had definitions
of various terms used under HIPAA compliance. (I.e. Chain of trust,
Clearinghouses, etc...)
The Security NPRM, (available at http://aspe.os.dhhs.gov/admnsimp/index.htm)
has a comprehensive glossary of terms, including acronyms, in Addendum 2,
starting on page 43271 of the Federal Register. (Posted
11/21/00)
1. If a provider contracts out his coding...is the individual coder
required to comply with HIPAA regs (they transmit the data to the payer for
the provider)? I would assume yes, if yes then a chain of trust is required?
2. If a provider dictates charts over the phone, it is then transcribed and
E-mailed back to the provider, is the dictation service required to comply
and the provider?
3. For small practices, if they provide one of the 9 items, then they are
required to comply right? Basically, when is a small practice not required
to comply?
1. The provider would be expected to have a Business Partner (Associate)
Agreement with the coding firm that would contractually obligate the coding
firm to comply with the Security & Privacy Rules. Chain of Trust is not
applicable (since COT is a small subset of the Business Partner Agreements).
2. The provider has to comply and have a Business Partner Agreement with the
transcription service.
3. Correct. The only time any size practice is not required to comply is if
they never transmit any of the 9 covered transactions. Those are the
triggers.
Note: In 1&2 above, even with a BPA, if the provider's business
partner violates the Security or Privacy rule, it is the provider who is
accountable to HHS.
(Posted 11/6/00)
52. Compliance - Insurance Industry Actions
Any reaction to the Insurance Industry's statements today that they
intend to effectively gut the transaction standards and implementation
plan?
Here are a couple of articles for source - point & counterpoint. Both
articles are from Health Data Management....
Hobson to Payers: No HIPAA Delays This Year
Rep. David Hobson (R-Ohio) is warning health care payers he will oppose
premature efforts to delay implementation of the transactions, security and
privacy rules stemming from the Health Insurance Portability and
Accountability Act of 1996. Hobson was sponsor of HIPAA's administrative
simplification provisions. The action follows an aborted attempt in
September by the Blue Cross and Blue Shield Association and the Health
Insurance Association of America to get a two-year implementation delay.
Federal officials published the final HIPAA transactions and code sets rule
in August, and expect this year to publish the final security and privacy
rules. Compliance is required 26 months after publication. Hobson recently
sent a letter to HIAA President Chip Kahn voicing opposition to delays.
Noting more than four years have passed since HIPAA was enacted, Hobson
wrote, "It is my understanding that there may be a concern among some
of your members that this two-year implementation timeframe may not be long
enough. At this point, I would be actively opposed to arbitrarily extending
the implementation timeframe beyond two years without a substantial dialogue
over the benefits of any extension." (Nov. 1)
Payers to Push HIPAA Delays
Two major health care payer organizations will ask Congress next year to
delay implementation dates for information technology standards mandated
under the Health Insurance Portability and Accountability Act. The
organizations differ, however, on their proposed timetables and how hard
they will fight. Federal officials recently published a final rule setting
national standard formats and code sets for electronic health care
transactions. The government expects late this year to publish final rules
setting standards for the security and privacy of all electronic health data
and at least some paper-based data. The payer associations contend the HIPAA
rules require changes to computer systems and business practices that cannot
be completed within the existing timetables. The Blue Cross and Blue Shield
Association, Chicago, will push for a four-year implementation timetable for
HIPAA's final transactions and code sets rule, instead of the 26 months
granted under the act. The association assumes the security and privacy
rules will come out together with their own implementation time frame.
"We will engage the 107th Congress in this debate," says an
association spokesperson. "This is a very big issue. This has nothing
to do with the goals of the legislation. It has more to do with the nature
of the implementation." The spokesperson, however, conceded the
association has not ruled out asking for other changes to HIPAA
requirements. "At this point, we will focus just on extending the
implementation time frame. But that's not to say we won't add new tactics to
our plan." The Health Insurance Association of America, Washington,
will request Congress to consider a longer implementation timetable for all
HIPAA rules. But the association hasn't decided what timetable it will ask
for, or how hard it will fight, says Kathleen Fyffe, federal regulatory
director. "We think the law intended for easy movement of the industry
toward standardization, but the regulations have overcomplicated the
implementation approach," Fyffe contends. (Nov. 3) (Posted
11/21/00)
When our departments update the status (OSU) of an
order to "complete", or "canceled", this sends certain
information to our financial system, which then debits/credits the running
bill, overnight. If the OSU is not performed, then, the bill does not get
incremented / decremented. OSU is therefore a critical step, but the
information doesn't directly create the bill; it dumps it into a financial
bin of sorts, and the financial system creates the bill. The question: Does
our "Order Status Update" meet the definition of a
"transaction" (administrative/financial data), or does it become a
'transaction" when the financial product increments/decrements the
bill, during the overnight? I would assume at the least the OSU qualifies as
a confidentiality and security issue, but when that data movement become a
financial / administrative issue, and therefore a "transaction".
This may seem like splitting hairs but it's important in the sense of data
ownership, and deciding where/when to apply the HIPAA yardsticks to the data
transmission.
The OSU is not a covered transaction - but the information contained is
covered under Security. (Posted 11/21/00)
54. Implementation of Security Standards
I see a problem here.
Don't the HIPAA proposed security rules allow, for scalability
reasons, somewhat broad latitude on the specific implementation for a
security standard? That is, a covered entity states their implementation of
the standard via their P&P and then must realize or enforce that stated
standard. For example, HIPAA says there must be an automatic logoff but one
covered entity says their standard is a 5-minute grace period and another
states 10 minutes. Both are HIPAA compliant in my opinion. If the ASP vendor
must conform to each covered entity's security procedures specified in the
business partner agreement, doesn't that make the vendor a slave to many
masters? And if a specific and different technical solution is specified by
different covered entities via their business partner agreements, wouldn't
that be near impossible to manage?
Yes - The ASP would have to comply with the Security Rule as an organization
-but not their product - product on its own can't be compliant. The ASP's
product security features would have to be able to support the covered
entity's policies and procedures (which may have a lot to do with work flow
process and may vary dramatically between entities) which would be part of
contractual issues between the covered entity and the ASP. As part of the
BPA, the ASP would also need a process in place to support the covered
entities' Privacy Policies. that's a problem. One solution may be for the
ASP to have their customers directly manage the security features of their
product. Don't forget -There may be vast differences in "need to
know" for ASP customer's staff and the product would have to be
flexible enough for information to be filtered differently for each entity,
depending on its job descriptions, work flow, etc. Audit trail policies will
also vary widely, as will user id, password policy, screen design,
authorization controls, etc. etc. And then there are remote access issues
and, and, and Given the above, there is an upside in that the ASP can add
value in working with their customer to provide security features tailored
to support their client's policies & procedures. (Posted
11/21/00)
Can a user with a Digital Certificate use a single Digital Certificate
to access multiple PKI applications, or will that user have to have a
separate Digital Certificate for each PKI system needed to access? An
example of this is a doctor has works both in his/her own practice and is
also a member of a hospital staff. This doctor needs to access the following
systems:
1. PKI system for his/her own practice to access medical records of patients
2. Hospital PKI system to access hospital information
3. Lab PKI system to view lab results for his/her patients
4. Medical Equipment Ordering PKI system to order medical supplies
5. Billing PKI system to access billing records for patients
If a person needs to access these five (5) systems which all use PKI and
Digital Certificates for authentication, is it possible for the person to be
issues a single Digital Certificate to maintain, or will the person have to
have five (5) separate certificates; one for each system?
Short answer - not now and probably not soon - at least in today's
environment. Long answer - see WEDI/AFEHCT Interoperability Pilot
Report to HCFA - www.edisec.org
(Posted 12/15/00)
We currently have a Web site developed by our ASP that allows our
providers to check our database for eligibility, claims status, etc. The
site uses digital certificates for security and encryption. I would like to
do some due diligence on the CA contracted to provide the certificates and
the adequacy of the security provided by the certificates themselves. Does
somebody have a checklist of questions to ask, things to look for, etc. or
is there a Web site that provides this kind of information?
Take a look at the WEDI/AFEHCT Internet Interoperability Report issued to
HCFA. You can find it at www.edisec.org
under Final Report Approved by WEDI and AFEHCT. (Posted
12/15/00)
It is my understanding if you are using PKI technology, there is a
generic certificate that belongs to the vendor or entity providing the
certificate service, and the user would have a unique certificate that is
identifiable by their User's ID/Password logon information. This would mean
that the system recognizes all the different certificates by the unique
logon information given that user.
The weak point is still the trust relationship for access to the
certificate, whether it resides on a workstation or as with some PKI
products that the certificate is accessible from a central server via a user
id and password. The authentication is still no better than password and
id.... So why not just use the user id and password to begin with and skip
the PKI and certificate? (Posted 12/6/00)
I see two good reasons to use PKI and digital certificates rather than
simple user IDs and passwords for user authentication:
1) PKI supports persistent digital signatures, which provide long-term
integrity and accountability for transactions. Simple passwords don't do
this.
2) PKI provides a manageable system for sharing encrypted data among a
large, diverse group of people, who may or may not have ever met. Simple
passwords aren't manageable here.
I don't deny the point that in the scenario below (shared workstation
storing digital IDs for all users, digital IDs protected with passwords) the
degree of authentication can be similar to those for straight passwords. If
this is acceptable, fine. If not, there are many ways to mitigate these
risks to varying degrees: - Store certificates on hardware tokens -
biometric readers - proximity tokens - enforce strong passwords - user
training re: shoulder surfing, etc. And certainly the situation is much
better when users have their own workstations. Still, even if we grant that
PKI does not improve your authentication story over passwords (I don't),
persistent encryption and digital signatures are tools that are very
valuable to organizations grappling with HIPAA and the Internet, and can
easily justify PKI deployment. These are the "killer apps" for PKI;
I think of authentication as an added bonus. What is your opinion?
I think that "easily justifying deployment" is not so easy. Aside
from not seeing any requirement to use PKI for encryption;
1) High cost of PKI adoption and deployment.
2) Questionable need for ubiquitous persistent encryption. In some
circumstances, persistent encryption may be detrimental and could delay
access to information needed to make patient care decisions.
3) Need for additional add-on authentication modalities (biometrics, tokens,
etc.).
4) I don't see any advantage of managing PKI. PKI appears to have huge
management overhead - e.g. issuing certificates (which in health care may
mean including some variation of professional credentialing), controlling
certificate access, certification revocation, and certificate renewal, etc.
5) Lack of interoperability between PKI vendors and certificate authorities
(e.g. access to common CRLs - certificate revocation lists.
6) Lack of standards for health care certificate policies. I have no way of
easily knowing that a certificate issued by another entity meets my internal
identification policy standards.
7) Lack of standards for health care certificates or health care certificate
levels which would control usage (e.g. MD (DEA?), RN, PA, DDS, Therapeutic,
Patient, Lab, etc. etc.) - X.509 standard contains essentially "local
use" fields that have yet to have agreement to standardized content for
health care usage.
8) Portability issues - how do you use the same certificate for a physician
practicing at 3-4 hospitals, 2 office locations and home? Remembering that
each hospital and/or office could be owned by a different entity and each
choosing different vendors and or CAs. (Posted 12/6/00)
56. Data Elements
In the transaction specifications, each data element has a minimum and
a maximum length, for example the patient last name has a maximum length of
35. Does this mean that if the data element has a maximum length of 35, that
the field in the software application, practice management software, for
patient last name must be a length of 35 or can it be different length such
as 25 characters?
The field lengths are maximums and the ANSI formats are variable length not
fixed length such as the NSF - you could certainly have field lengths in
source databases less than the maximum - as long as they contained accurate
information. If they were longer than the maximum you would have to truncate
the source data. (Posted 12/6/00)
57. Scanning and Record Retention
Would we, as a managed care plan,
be safe in shredding the paper claim that we receive, which is then scanned
into a document imaging system, and then the data from the image is uploaded
into our claims processing system? If it's recommended that we should retain
the paper for a period of time, how long before it could/should be shredded?
I believe our current practice is that the paper is shredded once the claim
has been processed (either paid or denied).
There is nothing in HIPAA that would contraindicate that practice. However,
before moving forward you need to check if there are any other controlling
State laws. (Posted 12/15/00)
When scanning documents electronically,
according to HIPAA, are we required to maintain a copy of the original
document on file, or can it be destroyed and maintain the electronic copy in
a data warehouse? My question is generated from the record retention
guidelines and wanting to be sure we are compliant with them.
HIPAA appears to be silent on maintaining original source documents. It only
requires that the same protections be applied to the documents that are the
source of the electronic record. While destruction would certainly ensure
that original source documents were not used for disclosure -
"protection" could also be argued to mean protection from
destruction. From what I have seen so far, I believe/think that destruction
of source documents that had been imaged would not be a problem, but
destruction of source documents that were used in data entry (e.g. fee
slips) - and not imaged - would not be advisable. However - rules other than
HIPAA apply to source documents and/or record retention that may help
clarify or support your decisions. I have attached an excerpt from the AHLA
listserv that may help. The following appears to accept an electronic image
in lieu of the original paper document. There may be other laws and
regulations that would address destruction of source documents, including
local and/or state laws, for which I am unaware. For a reference, please see
HCFA's Hospital Manual, Chapter 3 - Admission Procedures, Section 301 (at http://www.hcfa.gov/pubforms/10_hospital/ho300.htm)
which states:301.3Documentation to Support Admission Process. -Retain a copy
of completed admission questionnaires in your files (or on-line) for audit
purposes to demonstrate that development for other primary payer coverage
takes place.It is not necessary that the completed questionnaire be signed
by the beneficiary. Hard copy questions and responses may be retained on
paper, optical image, microfilm, or on microfiche. Hard copy and data must
be kept for at least 10 years, in accordance with the Department of
Justice's (DOJ's) record retention requirements, after the date of service
that appears on the claim. (See §480 for information about the
documentation to be used in a hospital review.) If your admissions questions
are retained on-line, you are required to retain negative and positive
responses to admission questions for 10 years, in accordance with DOJ's
record retention requirements, after the date of service. On-line data may
not be purged before then. ALSO SEE THE FOLLOWING WHICH IS AN EXCERPT (http://www.hcfa.gov/pubforms/13_int/a3693.htm)
(Posted 12/6/00)
58. Transaction Final Regulations Corrections
I heard that DHHS recently made some changes to the final transaction
standards after they were published. What are they?
The primary change is in the definition of health plan that has become more
succinct and inclusive. Most of the other changes are typo corrections. Here
is the new definition of "Health Plan":
"Health plan" means a plan, program or organization that provides
health benefits, whether directly, through insurance, reimbursement or
otherwise, and includes but is not limited to-
1) A policy of health insurance;
(2) A contract of a service benefit organization;
(3) A membership agreement with a health maintenance organization or other
prepaid health plan;
(4) A plan, program, agreement or other mechanism established, maintained or
made available by a self insured employer or group of self insured
employers, a practitioner, provider or supplier group, third party
administrator, integrated health care delivery system, employee welfare
association, public service group or organization or professional
association; and
(5) An insurance company, insurance service or insurance organization that
is licensed to engage in the business of selling health care insurance in a
State and which is subject to State law which regulates health
insurance." (Posted 12/11/00)
59. Overhead Paging
We use overhead paging to direct our patients to various clinics within our office. We heard that this would be a HIPAA violation, what would you recommend as a solution? Some facilities are providing their patients with pagers - similar to what you find at some restaurants. That way they can notify the patient without voice paging. (Posted 12/15/00)
60. Final Regulations Download
Do you know where I can download copies of the regs in Word format?
Seems to me I saw that some place, but for the life of me I can't remember
where.
The HHS Administrative Simplification web site has both PDF and Word Perfect
versions. Look in both the final and proposed rules sections. http://aspe.os.dhhs.gov/admnsimp/
61. Remote Access
Do you have an opinion regarding the practice of Physicians and/or
Hospital Administrators (non clinicals) having access from their home
computers to information on the hospital's system? Since these computers can
be used by wives, kids, etc and are often left on and unattended, would this
be a problem for the hospital that gives access to these individuals? Some
of these individuals use the hospital internet access their home computers
because they can only access these systems through an internet connection.
The Hospital does have policies and procedures, but the actual practice may
not be consistent with what is on paper. In review of the practices in
anticipation of HIPAA, this question has come up. For illustration purposes,
several MDs have access on their home computers to the ER patient list with
names, addresses, diagnosis, etc. An on call specialist may look at the ER
list before leaving home to see if there are any other patients he might be
asked to consult on. In one instance, an administrator saw that of the 6
patients in the ER, two were his neighbors. He called the ER nurses to
inform them that they were friends of his. Others have access to view
patient data from ICUs. These screens have some demographic patient data.
Surgeons, for example, may be on call and wish to review patient data about
blood pressure or medication action and order treatment changes over the
phone before coming into the hospital. I would think the response would also
apply to computers with hospital access in the MD or administrators offices.
This is essentially the same issue that we find for home based medical
transcription and coding. There are numerous issues - and there are
certainly some risks that will not be able to be eliminated - but the
benefits in many cases will outweigh the risks. It will take some work and a
lot of it has to do with developing effective policy and education. While it
is definitely more secure to do away with remote access to patient
information from clinician's home computers, we also have to weigh the
benefit to patient care that occurs when clinicians do have access to
patient information from their home - or other remote locations. Essentially
another issue of security best practice versus patient care - where do we
have the most to lose or gain? For non-clinicians - it is partially a need
to know issue. If they need to have access to the information at the office
- what are the benefits to them having that same access from home? This is a
different risk paradigm since patient care may not be involved, but again
may be worth the effort to continue to give them remote access. What are
risks and costs of not having remote access and can you mitigate the risks
of granting remote access through policy, education and technology to the
extent that you can justify it (taking the cost of mitigation into account).
(Posted 12/15/00)
An IT system is a tool, and no tool can be compliant. An entity cannot
be compliant without enablers. IT products are enablers. So how can I enable
HIPAA changes (electronic of course), without an enabler? As for the answer
the question what is a HIPAA (compliant database, enabled database, database
management system) compliant product? It is a product where the vendor has
taken the trouble to read and familiarize themselves with the regs (final of
course), they can walk me through the operational aspects of their product,
and show me where the tool facilitates/enables HIPAA compliance, because
their system has the technical, administrative, and physical safeguards
built into the product. Consequently, I have a high comfort level that this
system is an enabler that is making my HIPAA compliance easier, rather than
keeping me up at night thinking of work-arounds because the vendor decided
HIPAA compliance is an entity solution. As for the database issue, I would
never recommend that we purchase a database that did not facilitate
role-based access to different levels of information within the database. I
sure would not recommend the purchase of a database where it is simply
general access, and it has no tie-ins to my network management systems, and
the role based security designations we went to trouble to develop. With the
imminent publication of the privacy and security regs, I think a lot of
organizations are going to be actively looking at their various IT systems,
and looking for upgrades that facilitate their compliance efforts. This
saves me the aggravation of placing administrative safeguards where there
should/could be technical safeguards. The other option is that we return to
paper, let HIPAA bygones be bygones. Sounds like CAVEAT EMPTOR, market rules
- get me HIPAA enabled/compliant/facilitator vendor, or anyone who makes my
life easier and cost efficient, and I will snap up their relevant
product.
1. I think we have an issue of semantics in the usage of
"database". A database can take a lot of forms from flat file,
ISAM/VSAM, DBF, various versions of SQL, Proprietary (e.g. MUMPS, PICK),
etc. A DBF type, flat file ISAM/VSAM or MUMPS database on its own does not
typically have any of the attributes for which you say are necessary. It is
the development of the application code controlling the access, insertion,
editing, deleting and creation of information within the database that
creates all of those attributes. Some databases such as MS SQL Server,
Oracle, DB2 have access control and audit built into the database itself -
however the application code controlling the information in the database
would normally still control role based access.
2. As far as administrative versus technical safeguards. Without the
administrative policies and procedures in place you don't know what features
you are seeking in technical safeguards.
3. The database, except for general directory access, would normally not tie
into your network directory management systems. The fact that your network
gave a user permissions or access to the directory for which your database
resided, would have nothing to do with what information the user would be
able to access within that database. It would just give the user access to
the application and the database, not control how they accessed information
within the database.
4. A health plan doesn't have an option to return to paper.
5. CAVEAT EMPTOR is very appropriate when dealing with vendors claiming to
be HIPAA compliant - there just isn't such an animal available. Most vendors
are going to be more than happy to try to build in any reasonable security
features for their customers. But they need to know from their customers
what they need - and if their customers don't know what their own needs are
the vendor isn't going to be much help. It is up to the covered entities to
ensure that whatever security features they have in their systems and
applications are configured and implemented properly. It's kind of like
purchasing NT because it is C2 (Orange Book) compliant. It is, but only when
you have it configured properly and hold your tongue just right.
6. Do you really want your vendor deciding what your security policies and
procedures are going to be? Maybe so... but they're not the ones
accountable. (Posted 12/15/00)
I don't fully agree with your definition of electronic information
covered. Per the statute...
"SEC. 1172. (a) APPLICABILITY.--Any standard adopted under this part
shall apply, in whole or in part, to the following persons:
1. A health plan.
2. A health care clearinghouse.
3. A health care provider who transmits any health information in electronic
form in connection with a transaction referred to in section 1173(a)(1).
The statute specifically references coverage of transactions defined by the
statute, at least for providers. This wouldn't necessarily include a Word
document, Excel spreadsheet, etc. Using a broad brush approach, it would
seem to me appropriate to protect identifiable information no matter the
form. This doesn't mean, though, that just because it's electronic the
information is protected by HIPAA. As an example, a small provider could
store a considerable amount of data electronically, up to and including the
patient record. If the provider does not transmit health information in
connection with a defined transaction, the data stored is not covered under
provisions of HIPAA. Again, I don't think this should serve as a reason to
not adequately protect the data.
1) Section 1172 of the Act that you reference only defines the trigger for
when a provider is covered under the Act - not that the Security Rule
applies only to transactions. That is, once a provider transmits any health
information using a covered transaction, then the Act applies to them - and
the regulations promulgated under the Act. Notice that the reference to
transactions only applies to providers - health plans and clearing houses
are covered without reference to transactions.
2) I have included some language from the Security NPRM - which would cover
any provider that transmits a covered transaction.
a. Fed. Register Page 423258 45 CFR 142.306 (a): "§ 142.306 Rules for
the security standard. (a) 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
b. Federal Register - Page 43245, 1st column: " In this proposed rule,
we propose a standard for security of health information. This rule would
establish that health plans, health care clearinghouses, and health care
providers must have the security standard in place to comply with the
statutory requirement that health care information and individually
identifiable health care information be protected to ensure privacy and
confidentiality when health information is electronically stored,
maintained, or transmitted.
c. Fed. Register Page 43246, 1st column: " The security standard is
applicable to all health care information electronically maintained or used
in an electronic transmission, regardless of format (standard transaction or
a proprietary format); no distinction is made between internal corporate
entity communication or communication external to the corporate
entity."
d. Federal Register - Page 43248, 1st column: "Under our definition,
the security standard would be a set of requirements adopted or established
to preserve and maintain the confidentiality and privacy of electronically
stored, maintained, or transmitted health information promulgated either by
an organization accredited by the ANSI or HHS."
e. Fed. Register Page 43258 - 3rd column: "Security of health
information would not be solely tied to the standard transactions but would
apply to all individual health information electronically stored,
maintained, or transmitted."
f. Fed. Register Page 423258 45 CFR 142.306 (a): "§ 142.306 Rules for
the security standard. (a) 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. (Posted
12/21/00)
Recently, I was asked if medical answering services under the
following scenario would fall under HIPAA: Patients call their physician and
are greeted by the service. The service records the patient's name,
telephone number and symptoms/diagnosis. The information is stored in a
computerized paging system which then pages the physician. We now have
patient identifiable data stored electronically. IMHO, the answering service
would fall under HIPAA regs beyond any trust agreement the physicians or
hospitals have the service sign. Comments?
I would agree that it would be covered under HIPAA - just as transcription
to a computer system would be covered. Additionally, the oral conversations
with the patient by the answering service personnel would also be covered,
since they are the source of the electronic information. One point of
clarification - the answering service is not covered by HIPAA; they would be
a Business Associate of the covered entity and would be controlled by their
BPA with the covered entity - not HIPAA.
What I would be interested in is comments on what the risk is that the
answering service will abandon their health care customers rather than have
to conform to the terms of a BPA. If not, will they be able to pass on the
additional costs to the covered entity? What are the odds that the answering
service is even aware of HIPAA and its potential impact to them? Though the
information is stored electronically, it is specifically used for treatment
and not for a covered transaction; therefore it could be exempted from HIPAA.
Other thoughts?
The information is covered regardless of whether it is used in a covered
transaction. Once a covered entity uses one of the covered transactions -
all identifiable patient information is covered - even demographics and
patient information not used for transactions. You may be thinking about the
portion of the Privacy Rule that states that patients do not have to
authorize disclosure of their information for the purpose of treatment,
payment or health care operations. That does not mean that you do not have
to protect the information.
I tend to look at this in the context of a business associate. If we
are to assume that the business associate definition found in the final
Transaction and Code Set will also be used in the final Security rule, a
business associate "means a person who performs a function or activity
on behalf of a covered entity." Is the answering service providing a
service on behalf of the provider, who is a covered entity? In my opinion,
the answering service is providing a service and therefore is covered under
HIPAA. The next question then is what part of HIPAA must they comply with as
a business associate? Again, the process would be to look at the rules to
determine the applicability. They do not fall under the Transaction and Code
set rule since they are not processing electronic transmissions. Looking at
the proposed security rule, they would need to comply since they are
maintaining individually identifiable health information electronically, and
are more than likely transmitting this over a network. Lastly, they would
also need to comply with the proposed Privacy rules since again, they are
maintaining individually identifiable health information electronically, or
have on paper what was most likely the progeny of the electronic
record.
Although the outcome may be similar - the Answering Service is not directly
covered under HIPAA and is not subject to the same penalties or federal
enforcement of HIPAA rules. The guidance to the relationship between the
Answering Service and the covered entity is in the Privacy Rule.
1. The Answering Service would definitely fall under the definition of
Business Associate in the final Transaction Rule - however - Business
Associates are not covered directly under HIPAA, unless they already meet
the definition of "covered entity" - which the answering service
does not. I think you may have misread the portion of Sec. 160.103 that
states that "...a business associate may be a covered entity...".
The intent of that statement is to inform the reader that covered entities
such as Clearinghouses could also be Business Associates, not to convey that
Business Associates could be covered directly under HIPAA - (unless of
course they were already covered entities as defined two paragraphs later in
Sec. 160.103). Another example could be a physician contracting with a
Health Plan to perform case management or review would be directly covered
under HIPAA as a Provider and in their role of performing services on behalf
of the Health Plan would also be a Business Associate of the Health Plan.
See page 50365 of the Federal Register.
2. The Privacy Rule covers the contractual relationship between the covered
entity and their Business Associate. As a Business Associate of the covered
entity, the Answering service would be governed by their contractual
relationship with the covered entity as mandated in the Privacy Rule
(currently Business Partner Agreement). Under the Privacy Rule the covered
entity is responsible for ensuring that their Business Associates sign a
Business Associate (Partner) Agreement and agree to specific terms detailed
in the Privacy Rule. Therefore the Answering Service, if they decide to
continue to do business with the covered entity, would be ruled by the terms
of their Business Associate (Partner) Agreement, which would mandate that
the Answering Service comply with the Security and Privacy rules and provide
sanctions against the Answering Service if they violated those terms.
3. If the Answering Service violates the terms of their Business Associate
(Partner) Agreement with the covered entity (e.g. unauthorized release of
patient information, failure to protect the information, etc.), the covered
entity could be held responsible for those violations and under the Privacy
Rule must enforce the sanctions mandated within the Business Associate
(Partner) agreement.
There are 2 things that I can see as being issues for HIPAA as the
initial source of the patient information: (1) It would be a part of the
Computerized Patient Record that is affected by HIPAA and (2) that the
information that ends up on the claim is affected by HIPAA. The source is
computerized and classified as needing to be secured and private at the very
least as well as the HIPAA implications as the data continues through the
medical process. Thoughts?
The information only has to be maintained electronically to be covered by
HIPAA. It doesn't matter if it is an electronic patient record, text file,
Word document, Excel, transcription/voice file, etc. (Posted
12/15/00)
Our organization is embarking on a project involving handhelds, Compaq
iPAQs, and a prescription writing application called Allscripts. The iPAQs
will be transmitting wirelessly. The task I have is trying to make this
situation as secure as possible. I have already posed numerous questions but
I wanted to see if any of you had any suggestions that I might have
overlooked. Some of this is pretty new but I was hoping that someone might
have a little experience already.
Since it is likely that wireless will be considered an open network - I
would ask what are you doing for encryption? (Posted
12/21/00)
65. Minimum Compliance vs. Plan for the Future
We can take the approach of converting the standard data into what we
need today to do our business (then convert them back for outgoing covered
entities) or change our systems at the core to adopt the field lengths and
ANSI Code Set values. I am curious what those on this list serve are
planning on doing. I know that the second approach can be much more costly,
but should bring some Positives for the Insurance plan out of all of this
work. Either approach will reach compliance, but the second (I believe) will
prepare the organization to gain benefits from HIPAA in the reduced impact
of HIPAA's future regulations.
1) As the Transaction standards evolve you are going have on-going issues of
migration to new versions and concurrently being able to accept older
versions. There still needs to be some work done on migration strategies,
sunset dates, etc. Therefore, even if you change some of your core systems
to be at least content compliant, you will still have need for some
intermediate translation stage in the long term. I doubt you would want to
be in a position of having your core systems natively accepting or
generating the standard formats.
2) You may not have time, resources or budget to change core systems in time
to make the deadlines.
3) Practically, taking the intermediate translation approach make some sense
both in the short and long term. You can use the initial process it help
determine what areas of the core system would benefit the most from an
overhaul and you can prioritize accordingly. (Posted
12/21/00)