Donate for the Cryptome archive of files from June 1996 to the present

31 January 2013

Stealing Secrets: Patient Safety Data Security


http://www.pso.ahrq.gov/statute/pl109-41.htm

Patient Safety and Quality Improvement Act of 2005

http://www.pso.ahrq.gov/regulations/fnlrule08.htm#IIIB3

3. Section 3.106—Security Requirements

Proposed Rule: Section 3.106 of the proposed rule outlined a framework consisting of four categories for the security of patient safety work product that PSOs would consider in developing policies and procedures for the protection of data. Because § 3.106 contains only two subsections and we received few comments, we will discuss both subsections of the rule together.

Section 3.106(a) proposed that the security requirements of this section would apply to each PSO, its workforce members, and its contractors whenever the contractors hold patient safety work product. If contractors cannot meet these security requirements, we proposed that their tasks be performed at locations at which the PSO can meet these requirements. We stated that the rule does not impose these requirements on providers; this Subpart would only apply to PSOs.

Proposed § 3.106(b) would have established a framework consisting of four categories for the security of patient safety work product that a PSO must consider. We proposed that each PSO develop appropriate and scalable standards that are suitable for the size and complexity of its organization.

The four categories of the framework would have included: security management issues (documenting its security requirements, ensuring that its workforce and contractors understand the requirements, and monitoring and improving the effectiveness of its policies and procedures); separation of systems (required physical separation of patient safety work product, appropriate disposal or sanitization of media, and preventing physical access to patient safety work product by unauthorized users or recipients); security control and monitoring controls (ability to identify and authenticate users, an audit capacity to detect unlawful, unauthorized, or inappropriate activities, and controls to preclude unauthorized removal, transmission or disclosures); and policies and procedures for periodic assessment of the effectiveness and weaknesses of its overall approach to security (determine when it needs to undertake risk assessment exercises and specify how it would assess and adjust its procedures to ensure the security of its communications involving patient safety work product to and from providers and other authorized parties).

Overview of Public Comments: There were no public comments that specifically addressed § 3.106(a) of the rule. Commenters focused instead on the overall security framework established by § 3.106(b). The majority of commenters supported the proposed requirements and emphasized the concepts of scalability and flexibility that were reflected in the proposed rule. Two commenters urged the Department to adopt the HIPAA Security Rule instead. Another commenter suggested that the final rule should emphasize the need for PSOs to maintain up-to-date security processes and urged that the final rule specifically recognize that PSOs can include HIPAA Security Rule requirements in their business associate contracts with providers that are covered entities.

While there were few comments overall on this section of the rule, the specific provision that elicited the most concern was the requirement in § 3.106(b)(2) that patient safety work product needed to be maintained securely separate from other systems of records. As discussed above with respect to obligations of component organizations, commenters expressed concern regarding the potential burden of such a requirement and several pointed to the analytic benefits of being able to readily merge data sets for specific analyses. It was recommended that the final rule permit the patient safety work product and non-patient safety work product to be stored in the same database as long as the security requirements are implemented for the database as a whole.

Another commenter pointed to the confusion, inconsistency, and errors that were likely to result from the rule text in which each paragraph began with the words that a PSO "must address" each security issue within the framework while introductory paragraph (b) indicated that PSOs merely needed to "consider" the security framework.

Final Rule: We have modified the text of § 3.106 both to improve its clarity in non-substantive ways and to incorporate several substantive modifications in response to the comments we received. The changes to § 3.106(a) are for clarity. For uniformity and brevity, throughout § 3.106, we have standardized references regarding the application of security requirements to the "receipt, access, and handling" of patient safety work product. The rule text defines "handling" of patient safety work product as including its processing, development, use, maintenance, storage, removal, disclosure, transmission and destruction.

We have incorporated several modifications to the text of § 3.106(b). We have both simplified the text of the opening paragraph of this subsection and substituted the requirement that "PSOs must have written policies and procedures that address" for the language of the proposed rule that stated the "PSO must consider." We agree with the commenter that retention of the proposed rule language would create confusion regarding what is required of a PSO. By retaining the language that permits a PSO to develop specific standards that address the security framework in this section with standards that are appropriate and scalable, we intend to retain flexibility for PSOs to determine how they will address each element of the security framework.

The most significant substantive change in the security framework is in § 3.106(b)(2), which had required the separation of patient safety work product from non-patient safety work product at all times. Based on comments received, we have modified both the title of § 3.106(b)(2) and the text of § 3.106(b)(2)(i). Section 3.106(b)(2) is now entitled "Distinguishing Patient Safety Work Product," rather than "Separation of Systems," and § 3.106(b)(2)(i) recognizes that the security of patient safety work product can be maintained either when patient safety work product is maintained separately from non-patient safety work product or when it is co-located with non-patient safety work product, provided that the patient safety work product is distinguishable. This will ensure that the appropriate form and level of security can be maintained. This change responds to several comments that opposed the absolute requirement for separation in the proposed rule.

While we have, thus, allowed greater procedural flexibility, we caution PSOs to be attentive to ensuring that patient safety work product remains distinguishable at all times if it is not kept separated. To the extent that patient safety work product becomes co-mingled with non-protected information, there is increased risk of impermissible disclosures and violations of the confidentiality requirements of the rule and the Patient Safety Act.

We have also eliminated a reference to a PSO determination of appropriateness that was in the text of the proposed rule in § 3.106(b)(4)(i) as redundant, since the rule permits a PSO to develop appropriate and scalable standards for each element of the security framework, including this element.