NATIONAL COMMITTEE ON VITAL AND HEALTH STATISTICS
SUBCOMMITTEE ON HEALTH DATA NEEDS, STANDARDS, AND SECURITY
PERSPECTIVES ON SECURITY ISSUES IN IMPLEMENTATION OF ADMINISTRATIVE SIMPLIFICATION PROVISIONS OF PL 104-191
AUGUST 6, 1997
Charles C. Meyer
Informatics Standards Liaison
HBO &
Company
Doctor Starfield, members of the subcommittee, I appreciate this opportunity to address the issues surrounding security of health care information as defined by PL 104-191. I represent HBO and Company in the standards development community and on several policy boards within the industry. Although my focus has not been on security, my involvement with ASC X12, ASC HL7, ASTM, and the ANSI Healthcare Informatics Standards Board (HISB) has certainly given me some exposure. My most recent experience is as a member of the Association For Electronic Health Care Transactions (AFEHCT) work group on security, which delivered its recommendations to the Secretary on Friday, August 1.
HBO & Company represents a broad spectrum of application systems covering the full gambit of products inherent in the health care enterprise. Surprisingly there is little dissention within this diverse group of products on the issue of security of health care information. Each walks a fine line balanced between respect for the patient's privacy and the need to provide meaningful data to the caregiver and clinician. Given that we develop systems, our focus is generally introverted and fixed on access to the discrete data representing the patient record as stored and maintained by our systems. We are confident that reliable applications are readily available to protect messages being exchanged between the various participants in the enterprise. Even though the public has been aroused by reports of security violations on the Internet, I am not aware of any reports of health care information being intercepted. Admittedly there is relatively little activity involving health care data on the Internet. In any case, we are of the firm opinion that data at rest faces a significantly higher risk of disclosure or subversion than does data in transit.
Security of data at rest is multifaceted since such data is a composite of electronic and paper forms. While we are focused on the electronic form, the physical security of the reams of paper forms that make up the patient's medical record must not be overlooked. The need for significant improvements in the procedures for the storage, maintenance, and distribution of paper medical records was pointed out most recently in the NRC publication FOR THE RECORD: Protecting Electronic Health Information. Their assessment of risk clearly demonstrated the need to address physical security of the medical record as the first priority. We are supportive of the process of risk assessment and the subsequent development of suitable responses to minimize, if not eliminate, the risk. The NRC publication documents that process and it is also used in the European pre-standard draft Medical Informatics: Security Categorization and Protection of Healthcare Information Systems. The members of the European Union are strong advocates of patient privacy and the ensuing security mechanisms that ensure it. ISO and European standards deserve consideration for inclusion in the security standards adopted by the Secretary.
It is imperative that the current effort underway to improve care while defining cost effective and efficient treatment plans is supported. This can not be accomplished without access to the clinical data and outcomes specific to a given diagnosis. The plethora of public health initiatives would be less than effective if not supported by valid statistics culled from health care data. Yet the public is extremely leery of any access to their information regardless of the benefit. Many are of the opinion that access is uncontrolled and unlimited and, subsequently, support extremely stringent controls. Admittedly there is a need to identify the patient in the case of communicable or sexually transmitted diseases; however, for the most part collection of information to support research does not require the patient's identity. The public's perception is contrary to reality. The resolution would appear to be an extensive educational campaign to make the public aware of the checks in place to protect the privacy of their data while supporting ongoing research. Concurrently, the attributes of patient data that would constitute an individual's identity must be defined and clarified. Protecting the information is fairly straightforward once it is defined.
That protection takes the form of access control. Access to health care data has broader concerns than just research. Access controls are as important during the episode of care as after. During treatment there is no question that the patient has been identified; however, what clinical data is available under what circumstances is essential to privacy. The dichotomy faced by vendors is providing access controls that protect the patient, but don't hinder the caregiver. We are supportive of the approach that defines stakeholder roles and assigns an access level to each role. An orderly or nurse's assistant may only be able to determine the patient's location and the service they are scheduled to provide. At the other end of the spectrum the attending or primary care physician would have full access to the patient's medical records.
It should fall to the standards development organizations, in a cooperative effort, to define these roles and the appropriate level or levels of access. Access would, of necessity, need to be defined to a level of granularity that would support the assignment of specific data elements to the access level. In essence, an access model would be constructed and interact with a data model and role model. Thus supporting the mapping of allowable data to a specific role through authorized access. Conceptually, the access model could be mapped over a vendor's database in a close corollary to the standard. ASTM has prepared a draft document addressing the concept of an access matrix. Their guidelines could provide a basis for evolving this process.
HBOC is also supportive of the concept of establishing an initial minimal set of security requirements that could be quickly achieved as espoused by Michael Fitzmaurice. "Setting the bar low!" Once the industry as a whole has attained a comfort level with security, the regulations could begin the process of adding rigor through ever more stringent requirements and granular access levels. A progressive approach to security would be much more easily accepted and supported by the vendor community in general and HBOC specifically. Note that all of our discussions have revolved around guidelines, procedures, and processes. As a vendor and developer of software we are adamantly opposed to the definition of a technology-based standard. This would tend to stifle innovation and development. Further, such technology could literally be obsolete by the time a regulation was published. It is imperative that the regulations address the "what and why" of security, allowing "how" to become an implementation issue.
As I stated earlier, our focus tends to be drawn inward toward our database. We must, however, at least be aware of the basic tenets of transmission security. A crucial issue from the vendor's perspective is the scope of the regulation. Given that certain data exists in the format of one of the nine standard transaction sets. At what point does that data need to be secured? This is actually a media question, which must be resolved by the regulations. I do not believe that there is anyone in my organization or in the industry as a whole who would not support a requirement for secure transmission over the Internet. By the same token, how appropriate is that level of security to transmission over a private network? Taking it to the extreme, would that level of security be necessary for transactions on a diskette or magnetic tape, as has been suggested by members of the HIPAA infrastructure team?
A realistic assessment of the security risk represented by the various media used to transport the standard transaction set will be essential to the preparation of a viable security matrix. Perhaps, within the concept of minimal requirements, only transmissions over the Internet require encryption. More likely, there will be specific data elements that require protection during transmission over more secure media than the Internet. A clear definition of use will eliminate a significant amount of thrashing on both sides of the connection. Another facet of the media question regards backup media and equipment repair. The guidelines must establish clear procedures for the storage and disposition of backup media. The same considerations must be extended to system media that might contain sensitive data. Such information must be cleared from the hard drive prior to being given to a technician for repair.
In summary, HBO & Company is highly concerned that data at rest be given due consideration under the legislation. The standards should take the form of guidelines and procedures defining the "what and why" of security. Access control is essential to the implementation of security standards. Access control should be defined by a cooperative effort of the standards development organizations. Finally, the standard must not be technology specific.
Thank you for this opportunity to address the subcommittee. I will be available to answer questions at your convenience.
Charles C. Meyer
Informatics Standards Liaison
HBO & Company
587 East SR 434
Longwood, FL 32750-5187
V: (407) 831-8444 Extension
2191
F: (407) 831-9958
E: chuck.meyer@hboc.com