 |
| HIPAA IMPLEMENTATION
EXAMPLE |
Overview
The number of providers in this office example is of less
importance than the technologies in use and the insufficient volume or revenue
to justify employment of a HIPAA administrator.
There are a number of
ways by which this example health care provider office may implement the HIPAA
requirements. This example does not necessarily represent the only way in which
such an implementation can occur.
This provider office, as described
above, would normally evaluate and self-certify that the appropriate security
is in place for its computer system and office procedures. The evaluation would
probably be done by a knowledgeable person on the staff who, as you will read,
is assigned the responsibility of security and privacy officer, or perhaps by
one of the practitioner partners.
Let's Get Started
First, the office might
assess actual and potential risks to its information assets. Then, to establish
appropriate security, the office would develop policies and procedures to
mitigate and manage those risks. These would include an overall framework
outlining information security activities and responsibilities, and
repercussions for failure to meet those responsibilities.
Next, this
office would develop contingency plans to reduce or negate the damage resulting
from processing anomalies or catastrophies. An account would be established
with a reputable offsite data backup service to safely and securely backup all
data files. This office would need to periodically review its plan to determine
whether it still met the office’s needs.
The office would need to
create and document a personnel security policy and procedures to be followed.
A key individual on the office staff would be charged with the responsibility
for assuring the personnel security requirement is met. This responsibility
would include seeing that the access authorization levels granted are
documented and kept current (for example, records are kept of everyone who is
permitted to use the PC and what files they may access), and training all
personnel in security. We emphasize that these requirements are scalable. The
requirement for personnel clearance procedures could be met in a small office
with standard personal and professional reference checks, while a large
organization may employ more formal, rigorous background investigations.
 |
This same
individual would also be charged with the responsibility for security
configuration management and termination procedures. For this example, the
security configuration management requirement would be relatively easy to
satisfy; the necessary features could be part of a purchased hardware/software
package (for example, a new PC might be equipped with virus checking software),
or included as part of the support supplied with the purchase of equipment and
software. Termination procedures would incorporate specific security actions to
be taken as a result of an employee's termination, such as obtaining all keys
and changing combinations or passwords. A "position description" document
describing this person’s duties would specify the level of detail
necessary.
This office would also need to ensure that they have
activated the internal auditing capability of the software being used to manage
their health data files so that it tracks who has accessed the data. It is
expected that the capability of keeping audit trails will become standard in
all health care software in the near future, spurred on by the health
information privacy debates in Congress and at the State level.
This
office would document compliance with many of the foregoing administrative
security requirements by including them in an "office procedures" type of
document that would be required reading by new employees and always available
for reference. Requirements that would lend themselves to inclusion in an
"office procedures" document include: contingency plans, formal records
processing procedures, information access controls (rules for granting access,
actual establishment of access, and procedures for modifying such access),
security incident procedures (for example, who is to be notified if it appears
that medical information has been accessed by an unauthorized party), and
training. Periodic security reminders would include visual aids, such as
posters and screen savers, and oral reminders in recurring
meetings.
Physical access controls would be relatively straightforward
for this office, using locked rooms and/or closets to secure equipment and
media from unauthorized access. The "office procedures" manual would include
directions for authorizing access and keeping records of authorized accesses.
Media controls and work station use policy instructions would be developed by
the office and would include additional instructions on such items as how to
dispose of data no longer needed, logging off when leaving terminals
unattended, and scheduling times for automatically backing up data files to a
secure offsite data vault.
Safeguards for the security of work station
location(s) would depend upon the physical surroundings in the office. This
office might meet the requirements by locating equipment in areas that are
generally populated by office staff and have some degree of physical separation
from the public. Security awareness training would be part of the new employee
orientation process and would be a periodic recurring discussion item in staff
meetings.
|
The technical
security services requirements for access control, entity authentication, and
authorization control would be achieved by implementing a user-based data
access model (assigning a user-name and password combination to each authorized
employee). Other more elaborate access models could be employed if desired, but
probably unlikely for this small provider office. For example, the role-based
access process groups users with similar data access needs, and context-based
access is based upon the context of a transaction - not on the attributes of
the initiator. By assigning full access rights to a minimum of two key
individuals in the office, implementation of the emergency access feature could
be satisfied. Audit control mechanisms, by necessity, would be provided by
software featuring that capability. By establishing and using a message
authentication code, data authentication would be achieved. Use of the password
system mentioned above could also satisfy the unique user identification
requirement.
If our example provider decided to contract with a third
party to handle claims processing, a claims processing contract would be the
vehicle to provide for a chain of trust requiring the contractor to implement
the same security requirements and take responsibility for protecting the data
it receives from the provider.
If the health care provider and the
claims processing provider choose to use the Internet to transmit or receive
health information, encryption must be used by both. They would procure and use
commercial software to provide protection against unauthorized access to the
data transmitted or received. This decision must take into account what
encryption system the message sender and recipient use. There are a choice of
encryption algothryms including the CIA grade Blowfish technology which has
never been broken. On the other hand, health information when transmitted via
other means such as VANs, private wires, or even dial-up connections may not
require such absolute protection as is provided by encryption. This example
health care provider would likely not be part of a large area network
configuration, therefore, only integrity controls and message authentication
would be required and could be provided by currently available software
products, most likely provided as part of their contract with their claims
processing provider.
|
Enforcing Security Policy
Once in place, security policies must be acknowledged and
enforced. All organizational staff as well as consultants, contractors,
vendors, and trading partners accessing confidential information would sign a
confidentiality agreement acknowledging that they understand and will adhere to
that organization’s security practices. Policy enforcement is important in
delivering the message to staff that organizational security is a serious issue
and that breach of confidentiality is a punishable offense. Policies must be
administered consistently across all levels of staff and throughout all sites
and departments. A process would spell out the following:
- What to do if a
breach of confidentiality is witnessed.
- To whom and how a
breach would be reported.
- How a breach would be
investigated and reviewed.
- How a breach would be
discussed and shared in relation to the affected patient (if any), the staff
person who discovered it, the staff person who committed it, and the staff
person’s supervisor (confidentiality of the patient, the offender, and the
reporter are important)
- How a breach would be
punished
- How overall patterns
of breach behavior would be reported and monitored
A common approach
classifies breaches and subsequent discipline into levels assigning more
importance to malicious breaches (i.e., looking up information in a health
record in an attempt to cause harm) than to inadvertent breaches (leaving a
computer terminal signed on to a patient’s record). Staff would thoroughly
understand the classification of breaches and associated disciplinary
action.
- Level I –
Inadvertent breach: accidental, often due to
lack of education or awareness. Examples may include failing to log off a
computer terminal or sharing passwords. Often these breaches do not result in
actual patient information being exposed or shared. Punishment might include
verbal warning and mandatory re-education for first offense up to termination
for repeated offenses.
- Level II –
Intentional breach without malice: accessing a
patient record with no legitimate business purpose for doing so. This might
mean accessing a friend’s or relative’s record out of curiosity or
releasing patient information inappropriately. Punishment might include written
warning for first offense up to termination for repeated offenses.
- Level III –
Intentional breach with malice: accessing a
patient record with the intent to use it for personal gain or to harm someone.
Punishment would include termination for cause.
|
|
|
|
