13.2 REQUIRED VS. ADDRESSABLE SPECIFICATIONS


13.2 REQUIRED VS. ADDRESSABLE SPECIFICATIONS

As already explained in the general overview in chapter 5, the Security Rule consists of a number of broad standards and, in some cases, implementation specifications, which define certain aspects of the general standard in more specific terms. Those specifications are further categorized as required and addressable, while standalone standards (i.e. without additional specifications) are always interpreted as required. The Rule has been significantly revised since the last public draft in that it now refrains from referring to specific technologies, providing instead more widely applicable requirements for 'reasonable' protection. The actual meaning of the keyword 'reasonable' is certainly open for interpretation, with many additional variables factoring in the equation, like size of the organization and its security budget, amount and sensitivity of EPHI that the CE is dealing with, etc. It would certainly be inappropriate to require same level of security protection (and, correspondingly, funding) from a multi-billion dollar corporation, dealing with EPHI of many thousand people, as from a four people physician office which serves fifty individuals. For instance, a Fortune 500 corporation will have hard time convincing jury that an access control policy of not sharing passwords and blocking floppy drives provides 'reasonable' means of protection, while it might suffice for a small office environment. However, the Security Rule makes it clear that for compliance even the smallest entities will have to demonstrate some level of ongoing protection of the electronically stored and transmitted information about its patients .

Also, it is important to remember that a CE has not only to implement something, but also to be able to justify its choice before an audit or a jury, often consisting of non-technical people. Therefore, in the long run, a large CE will be better off demonstrating more than just 'reasonable' level of protection in order to protect itself from the future claims accusing it of negligence.

Implementation of the required specifications is mandatory, meaning that all CEs must implement some kind of protection of the prescribed type. However, each CE has flexibility in choosing technical means to achieve compliance, and the chosen implementation may vary greatly. For instance, emergency access procedures may vary from establishing and maintaining a 24x7 backup facility with mirrored hardware and autonomic power generators, to daily backups on floppy disks, stored in doctor's drawer at home. In both case, the procedures for accessing data in emergencies has to be clearly documented and the personnel should be trained to obtain and restore the data, should a catastrophic failure occur. Documentation and training are therefore just as important for compliance with regulation as the proper technical implementation.

For addressable specifications, Security Rule specifies alternative ways of dealing with them: implementing, implementing with a comparable solution, not implementing or using a completely different approach. When implemented the prescribed approach, or using a comparable solution, the same reasoning as with required standards should be applied. For example, if a CE decided to use SSL to address the transmission security, it will certainly be viewed as an acceptable comparable solution. However, if this SSL implementation has implementation shortcomings that might reveal the transmitted data, and the CE is aware about this fact, but is trying to save few dollars by going with cheaper implementation, it might quite rightfully be accused of negligence should a case be brought up against it.

However, a CE is not in a position to not implement an addressable specification just because it does not feel like doing it at the moment. It should better have a pretty convincing reason for such a decision. For instance, a doctor might decide that he is not going to use encryption for its e-mail communication involving EPHI, because not all of his addressees possess necessary software. However, his office policy states and he adheres to the policy of always obtaining patient's permission first for such a non-secured transmission to protect himself against a possible lawsuit should this information be intercepted. An alternative approach would be anonymizing the EPHI prior to transmission and sharing identifying information out-of- band or in a secure manner.




HIPAA Security Implementation, Version 1.0
HIPAA Security Implementation, Version 1.0
ISBN: 974372722
EAN: N/A
Year: 2003
Pages: 181

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net