Capital Hilton
16th and K Streets, NW
Washington, D.C. 20036
Major Topic: Perspectives on Security Issues in Implemention of Administrative Simplification Provisions of PL 104-191
DR. LUMPKIN: I would like to ask our afternoon panel to introduce themselves, and then we'll start with Miss Forbis for the first presentation.
MS. FORBIS: I'm Pat Forbis with the American Association for Medical Transcription.
MS. ZAKOWOROTNY: Cindy Zakoworotny, American Health Information Management Association.
MR. ZUBELDIA: Kepa Zubeldia with the Association for Electronic Health Care Transactions.
MR. SANOVIC: I'm Randy Sanovic, director of information systems security at United Health Care Corporation.
MS. FORBIS: On behalf of our association, thank you for the opportunity to once again provide testimony before this committee.
For the purposes of today's record, I will reiterate that AAMT is the only professional association representing medical tarnscriptionists, the medical language specialists whose responsibility it is to assure that dictated health care information is complete, consistent, clear, correct and current and credible.
We support the patient's right to confidential, private and secure health care documentation. AAMT currently participates in ASTM's 31.22 subcommittee on health care information and documentation. As chair of the confidentiality, security and privacy subgroup, I am pleased that our ASTM standard on management of security and confidentiality of dictation, transcription and transcribed health records recently -- yesterday -- passed on second ballot, and is now an ASTM approved standard. We will provide the committee with the specific designation as soon as it is available.
If I just might add, we are very excited about this, because it is very good.
We conservatively estimate that 250,000 persons are engaged in the high growth, unregulated industry of medical transcription. The number of startup companies doing business as medical transcription services is constantly increasing.
Mergers and acquisitions among medical transcription companies and health care providers have created organizations that are responsible for interstate, intrastate and offshore transcription and transmission of virtually billions of lines of clinical information, most of which is patient identifiable.
Because the complex process of dictation and transcription creates a substantial portion of documentation in a patient's record, and because advances in technology provide an opportunity to address information security issues, we draw the committee's attention to the following with regard to dictation and transcription.
Medical transcription as it is simply known is often out-sourced into an environment in which little if anything is known about individuals or companies to whom work is contracted. Whether transcription is out-sourced or done in house, policies governing security issues must be thoroughly addressed.
Security concerns include the following. Dictation is sometimes done in insecure environments or on unsecured equipment such as cellular phones. Patient identifiable information is often transmitted by public media, including fax, e-mail and Internet, without data encryption and with no precautionary measures taken to insure unauthorized access. Often there is not an appropriate acknowledgement that data has been received.
Access to dictation and transcription systems may be password protected, but passwords are rarely changed and systems often permit users to bypass password entry. Access to voice and text files is often undetected because of the lack of audit trails. Audit trails rarely extend to transcription services or remotely located medical transcriptionists, even though work may be done in locations other than where the patient is treated, including across state lines and in English-speaking foreign countries.
Data repositories exist in some medical transcription services, and in offices of sole proprietors, as well as within institutions with little attention being given to information security policies. It is not unusual for unencrypted patient identifiable information to be stored in voice files as well as in backup files on floppy disks or in computer files. Some indeed are retained in hard copy.
Retention, access, destruction and disposal issues are often not addressed adequately, if at all. Access to transcribed documents by personnel other than the originator and the transcriptionist, including clerical staff, sometimes results in inappropriate changes to those documents. This access is frequently made without unique identifier or audit trail.
I want to again assure this committee that medical transcription lends itself well to being a legitimate home-based occupation. Hundreds if not thousands of highly qualified and reputable home-based medical transcriptionists and services are dedicated to providing the greatest possible security for health care information, and they support the laws that will protect it.
Our recommendations include the following. We encourage the committee's adoption of the ASTM E-31.22 standard on management of the security and confidentiality of dictation, transcription and transcribed health records. Patients must be adequately informed. Patient access to their health records should also provide the opportunity to review an audit trail of the parties accessing their information.
We encourage ongoing education and policy review regarding security issues be provided for all employees and contractors who have access to patient information. Medical transcription companies serving as data repositories and potentially as data marketers raise security questions. Standards must be adopted that will assure the protection of stored encrypted health care information, including its access, retention, destruction and disposal.
We encourage the requirement that audit trails identify each individual who accesses patient information.
Again, the American Association for Medical Transcription urges strong penalties be adopted and enforced for those who fail to adopt policies and practices that insure the security of identifiable patient information.
In summary, the expertise of qualified medical transcriptionists is unmatched when it comes to the dictation and transcription processes of health care information, including security issues. We believe medical transcriptionists can contribute to the important work that is being done on behalf of patient care documentation, and we offer our assistance to you.
Again, on behalf of AAMT, we thank the committee for the opportunity to be here today.
MS. ZAKOWOROTNY: Good afternoon, Dr. Lumpkin and members of the subcommittee. My name is Cindy Zakoworotny. I am a registered record administrator, and I am testifying on behalf of the American Health Information Management Association.
I am a member of a AHIMA task force on information security, and I am director of the medical record department at Hartford Hospital in Hartford, Connecticut. On behalf of AHIMA's 37,000 members, thank you for the opportunity to address the subcommittee on issues regarding security and the implementation of the administrative simplification provisions of the Health Insurance Portability and Accountability Act of 1996.
AHIMA is very much aware of the importance of the task which the National Committee on Vital and Health Statistics has been charged with under the administrative simplification subtitle of Public Law 104-191. Our complete written statement answering the questions posed in your letter of invitation has been submitted for the record.
Protecting health care information has always been important, but it has never been as hard to do as in today's health care environment. Information security in a computerized health record has been a topic of discussion in Congress, in research and standards development organizations, in the media and in health care organizations throughout the United States.
For the record, protecting electronic health information, the report states, the prospect of storing health information in electronic form raises concerns about patient privacy and data security. For although information technology allows the use of advanced technical mechanisms to limit access to health information, it also introduces new vulnerabilities.
One of the most compelling reasons for information security is that patients are becoming more concerned about the privacy of their health information. Security disasters reported in the press have given patients good reason to be cautious when disclosing personal information.
A second reason for looking at security practices is the utility of computer-based health records. Today's health care information can be transmitted faster, sorted and analyzed easier, retained longer and broadcast farther than in the past.
The American Health Information Management Association believes the use of computers to collect, maintain and store health information is an appropriate and critical advancement in health care. But such systems must be carefully designed and monitored, and those with access to health information must be educated about their responsibility to protect its confidentiality.
AHIMA also believes that organizations must regularly review their health information security programs to insure they reflect changes in technology, the addition of new equipment, and any potential internal or external threats to the information. Patients must be confident that the sensitive information they share with health care providers will be handled responsibly, and safeguards to protect their information are in place. Without such confidence, patients may withhold critical information that could affect the quality and outcome of care and the safety of the public.
An effective information security program will, one, protect and properly manage enterprise data, information networks and systems from unauthorized access, modification, destruction or loss, two, improve patient and staff confidence in the organization's ability to provide a respectful work and patient care environment, three, minimize the liability exposure and financial loss to the enterprise, four, insure compliance with information security industry standards, five, promote credibility of the organization as an actively responsible partner in a health care delivery system or in its community, six, position the organization as a leader in the arena of information security.
A security program should address areas of confidentiality, integrity, reliability, accessibility, accuracy, durability and accreditation. Security can become a complex and costly activity when applied to information, but as a key resource of an enterprise, information must be protected from the threat of intentional and accidental harm.
As our reliance on computerized information increases, so does our vulnerability to attacks that either alter or destroy data or share information inappropriately. It may be hard to convince an organization to make the commitment required to implement a comprehensive security program. But potential risks for not doing so include lawsuits, negative publicity and customer dissatisfaction that could ultimately lead to patients turning to other providers for their care, or more significantly, to keeping critical information from their providers.
The job of creating an information security program requires the participation and support of several people within an organization. Organizational commitment demonstrated by sponsorship from top management and physician leadership is critical to the success of a security program.
Frequently, a multidisciplinary team holds the responsibility of defining, implementing and monitoring a security program. Many organizational approaches can be taken to create the information security team. Attached to this testimony are several examples. Important elements to consider in defining a structure is to be certain that all appropriate functions will be represented in some fashion, and that a team can be built that will work hard, stay educated, understand the issues and develop the right strategies for the organization.
Suggested team members include health information management professional, information systems director, information security manager, risk manager or health care attorney, human resources representative, key representatives from patient care areas, including physicians, and ancillary system representatives.
Comprehensive and ongoing are the key words associated with an information security training program. A training program should have the goals of raising the awareness of the participants regarding security issues, improving information security practices and protecting confidentiality. Everyone who has access to information about the patients must be trained, including physicians, staff, administrators, volunteers, students, vendors and consultants. While a training program must be designed to reach each of these categories on a regular basis, the approach to each category may differ.
In summary, AHIMA advocates that all health care organizations, their consultants and vendors commit to a strong information security program. It is critical that consumers have trust in the health care delivery system.
Thank you for the opportunity to testify, and I would be happy to answer any questions.
DR. LUMPKIN: Thank you.
MR. ZUBELDIA: I want to thank the subcommittee for extending the invitation to testify today, representing the clearinghouses and other members of AFEHCT. It is a privilege and a special opportunity, not only for AFEHCT, but also for my employer and for myself.
Coming today representing the Association for Electronic Health Care Transactions, I have the pleasure of serving on the board of AFEHCT. My position with Envoy is the vice present of technology, in charge of Internet activities and representative to the ASE X-12. I also co-chair the interactive health care claim (word lost) group within X-12, and I am a member of the IEEE.
Preparing today's presentation, I had meetings with a number of the other clearinghouses, large and small clearinghouses, as well as practice management vendors, members of AFEHCT. The views I bring represent a summary of all those meetings.
It is important to note that although competing with each other in the market, the AFEHCT members share common views regarding the needs, benefits, expectations and pitfalls of administrative simplification.
As a background, the Association for Electronic Health Care Transactions is a voluntary trade association comprised of health care claims clearinghouses, practice management companies, software vendors, credit card issuers, value added networks, health insurance and health data processors. A summary list of our members of AFEHCT is attached at the end of the testimony.
The marketing which we work is in between physicians, hospitals, labs, billing services and the payors, payors like Medicare, Medicaid, Blue Cross/Blue Shield. There are a number of bidirectional data relationships in this market, backed by contractual trading partner relationships. This is unique and very distinct from the Internet, where there are no underlying contracts.
These are very complex relationships. The market pressures and business opportunities have caused the creation of a network of clearinghouses, were to go from one end to the other, you may have to go through multiple clearinghouses in the process.
The clearinghouses not only perform the reformatting function for which they are well known, but also the aggregation, verification and distribution of transactions, not only claims, but all kinds of health care transactions. Performing these functions, the clearinghouse achieves through administrative simplification with the clearinghouse as a trading partner in the transaction, taking responsibility for the data itself, you can simplify the processing and the administration of both payors and providers.
In previous testimony to the commission, we have shown the complexity of the environment, getting up to 57 million trading partner relationships. One of the unusual characteristics of health care is that the age of most systems is relatively ancient compared to other environments. A substantial portion of the data processing infrastructure was deployed in the '80s. Typical systems used terminals in a shared environment. They don't have graphical windows and graphical use of interface. We found that less than 25 percent of the practice management offices have Microsoft windows of any kind installed, and most of the time it is used for transcription and word processing and other non-practice management business functions.
The situation in pharmacies is even worse. There is little penetration of graphical use or interfaces, and a substantial number of pharmacies still use point of sale terminals like credit card devices to verify eligibility and file their claims.
Also, the health care connectivity to the Internet is among the lowest in all industries. Recent studies show that less than five percent of the health care practices are connected to the Internet. This is probably a result of the combination of the old equipment not supporting TCPIP, and the fear of security intrusions when connected to the Internet.
Privacy and security are two very different concepts. Even today, we have seen migration of the talks between security and privacy, and it is more now a privacy meeting than a security meeting, so I'll try to (words lost) security.
Related to the issue of security is the issue of controlling the access to the information. The ultimate security is achieved when all access is denied, but this is not the goal of our security policies. Rather, the policies are to control the appropriate access to the information with reasonable protection, given the risks involved.
In our research of security issues in health care, we have found a lack of evidence of inappropriate access by breaking through existing technical security barriers, specifically by wiretapping communication lines or similar attacks. The reported cases involved confidentiality breaches by individuals that have legitimate access to the information, or the careless lack of security measures to protect the information. A large number of systems out there have a password system with a blank password.
It is far more difficult to control the access by authorized individuals that abuse their security privileges than to control the access by outsiders. Given the need to know of authorized individuals, technical security barriers that control the intent of the access are impossible to implement. This is an area where the security policies are more important than the technology.
Currently, over 99 percent of the health care administrative transactions take place over private networks such as X-25 packet switch networks, frame relay, private virtual circuits, direct dial-up circuits, most of the time with toll free numbers, point to point leased lines and S&S circuits, either dedicated or multi-drop.
As the Association for Electronic Health Care Transactions, we feel that these connectivity options available today are secure enough without using encryption for today's uses. Only an insignificant fraction of the health care data is being transmitted over the Internet in the several pilot projects currently in progress. All of this Internet data is being encrypted, most of it at the application level.
Clearinghouses are a party to the transactions. Without clearinghouses, the number of trading partner relationships would balloon up to 52 million trading partner relationships. We have calculated this number independently by two different sources, and we come out with the same numbers.
In contrast, clearinghouses reduce the trading partner relationships to under 200,000, one for each participant dealing with a clearinghouse. Clearinghouses provide functions that are crucial for supporting electronic transmission of health care information, re-forming transactions into standard data format, checking, editing, aggregating, distributing and routing transactions and producing management and analysis reports.
To perform this function, the clearinghouses open the transaction envelope. They insure the security and integrity of the data through strict procedures, technical tools and contractual agreements. Several of the transactions that are named in the HIPAA legislation in reality require a clearinghouse if they are to be done in real time, particularly the eligibility, referral, claim status and coordination of benefits.
Clearinghouses, due to their centralized data management, provide a security environment that is much easier to manage than the millions of point to point connections that would be required in the absence of clearinghouses.
In the health care environment, with over 50 million trading partner relationships, it is the implementation of the security policies in a manageable environment that insures the protection of the individual privacy.
To support efficient and secure transfer of health care transactions, a chain of trust is established as the transactions flow from provider to payor. The chain of trust is established by the trading partner contracts between providers and clearinghouses and between clearinghouses and payors and clearinghouses and themselves. There is a terminology problem here. Security experts use the terms trusted third party and chain of trust with meanings that are totally different from the meaning of those terms in our context. This is a difference that has confused many security experts. In our context, a chain of trust is established by business relationships, regardless of the data being encrypted, digitally signed or digital certificates. The clearinghouse as a trusted party takes part in the business transaction and is entrusted with the data. It is not a third party; it is actually a party to the transaction itself.
The role of the clearinghouse as a party to the transaction is crucial in achieving the administrative simplification, while at the same time providing the security and control necessary to preserve the confidentiality of the data.
An in-depth analysis of the security will not be complete without assessing the different risks involved. Different security measures are appropriate for each level of risk. For instance, releasing the date of birth of a patient while irrelevant in a city like Washington, D.C., would be relevant enough to identify an individual in a small rural area. Risk assessment must take a global view and not just concentrate on specific technology solutions.
It is theoretically possible to break through any level of security, so it is necessary to a company to have security barriers with a security policy that will adequately cover the case of a security breach. As Senator Bennett explained, the policy will assure that whoever breaches a security barrier will be very sorry that they even tried. It is a combination of technology and policy that becomes effective.
In the last few months, the security group in conjunction with HCFA and the DHHS has been compiling a director of security standards that will be applied to health care. A preliminary finding is that there is not one single standard or even a family of standards that could be adopted by the Secretary.
The best candidate deserving serious consideration is the European Community standard. It is a pre-standard, it is a draft. It is called security categorization and protection for health care information systems, and you have it attached behind the testimony.
Most of the health care security documents reviewed lack a general focus, and concentrate instead on specific technologies to solve specific problems. Typically, a problem they are trying to solve is the transaction of data over an open network such as the Internet or use in authentication in an open environment without trading partner agreements.
A single set of security standards cannot be applied to all of health care without a complete risk analysis, affect and specifically concerned about the general requirement for encryption and electronic signatures in all electronic transactions as proposed by other institutions. Some have proposed that all transactions flowing between the provider and the payor or between two payors or other trading partners must be digitally signed and encrypted end to end. Using end to end encryption will make the data invisible to the clearinghouses. Using end to end digital signatures will prevent the clearinghouses from aggregating and distributing the health care data.
Either of these two measures will effectively wipe out the ability of clearinghouses to perform their administrative simplification function that is so vital in health care. We are in favor however of the discriminate use of encryption and digital signatures when appropriate.
One point worth mentioning today is that the specific transactions defined by HIPAA are implementable using X-12 standards and NCPDP. The USC X-12.58 standard defines the security structures to be used with all X-12 formats. In fact, it defines the technical requirements to provide assurances, either at the transaction set level or the functional group or both. It allows secure and non-secure transactions inside the same envelope. There is little justification for looking elsewhere when protecting X-12 transactions.
In summary, as recommendations, the standards adopted by the Secretary should be in the form of security policies instead of specific security technologies. In some cases, the specific policies will restrict the choice of technologies. However, both the development of new technologies at an accelerated pace, as well as the existence of a substantial health care administration legacy base should be enough reasons to not regulate today the technologies to be used.
The benefit of policy versus technology will be an enduring standard. The use of encryption and digital signatures should not be implemented end to end, but between adjacent trading partners. These technologies should only be used when required to support a security policy, or when their use doesn't interfere with other business processes. Mandating the universal utilization will not bring administrative simplification and could cause a collapse of the system. Assessing the security risks, costs and benefits must be a part of the process.
Thank you for the opportunity of presenting this testimony to you.
MR. SANOVIC: Mr. Chairman, members of the subcommittee, thank you for the opportunity to offer a statement about this important concern.
My name is Randy Sanovic. I am the director of information system security at United Health Care Corporation. United Health Care is a national leader in health care management, serving purchasers, consumers, managers and providers of health care since 1974. Over 75,000 employers offer our products to millions of Americans. Our networks include 3,000 hospitals, 50,000 pharmacies and 265,000 health care providers.
In my position at United, I am responsible for the corporation's overall information system security posture. I have over 18 years of professional management level experience in information security, with two major multinational corporations. I am a certified information system security professional, and a member of the National Computer System Security and Privacy Advisory Board. I am also a two-term, six-year elected member of the board of directors of the International Information System Security Certification Consortium, known as ISC Squared.
On behalf of the management of United Health Care, I am happy to be part of this session and to assist in any way I can. My oral presentation is a short synopsis of the more specific answers to the committee's questions that were attached to the speaker invitation letters. So trying to read along with me will leave you searching a bit.
United Health Care has consistently supported the incremental market reform principles underlying the Health Insurance Portability and Accountability Act of 1996. Overall, the act is a victory for Americans, and its passage demonstrates that good faith by all parties has led to meaningful compromise in the country's best interests.
In general, the federal reforms espoused by the act will help stabilize and sustain the private market by insuring that all market players compete under the same high standards. United Health Care views protecting our members' confidential information to be of utmost importance. We have explicit information and security policies and standards that are mandated by executive management and widely disseminated for compliance within the corporation. As appropriate, external users are informed that to connect with United Health Care's information systems, they must comply with information and security policies and standards. These policies and standards are formally reviewed on an annual basis and revised and updated within the annual review period as necessity dictates.
Fortunately, at United Health Care we consistently have had top management support and commitment to data security. Top executive management from the CEO on down formally signs off at least annually on revised and new information security policies.
As information security director for United Health Care, I am responsible to upper management for the corporation's overall information security posture. I don't however perform such responsibilities alone. I am fortunate to be assisted by five very effective directors and managers who report to me and in turn focus their staffs on the issues and project that compose United Health Care's information security program.
We also believe that the health care industry in general is most definitely very interested in assuring information security, and in protecting the confidentiality of the information in its trust. That is why companies such as United Health Care have committed staffing and resources to hire information security directors and security officers and an information security staff.
As information security issues receive more attention in the general press, Americans are becoming better educated and demanding greater security for their personal information, in health care as in other industries. United Health Care and other companies want to be responsive to those concerns.
In recognition of this, United Health Care supports uniform federal standards for electronic data transactions, including privacy of individually transmitted health records and payment information that are applicable to all health plans. It is good to keep in mind, however, that most health insurers and plans are primarily transmitting payment information today, not actual medical records. Certainly, security is no less important when dealing with personally identified data, but do the standards need to respect the type of data, for example, payment versus clinical data?
As with many other industries, health care is driven by ever-changing external business requirements. As a result, it is important to educate the business segments of the health care industry, so that everyone is cognizant of the important security issues and privacy considerations, and educated as to the industry standards and federal and state laws. Also, we are learning a great deal from the current security implications of the year 2000 changeover.
Two issues that we believe need greater industry a attention are the appropriate use of the Internet and dealing with unsecured telecommunication networks. We do not and will not transmit patient identifiable information over the Internet unless it is suitably protected. We depend heavily on external standard organizations and vendors to recommend and implement universally accepted standards and their products, which we in turn evaluate and implement to provide prudent and reasonable security protection for our information assets.
We also depend on professional certification organizations such as the International Information System Security Certification Consortium to test and provide us with certified information security professionals that are broadly enough experienced, both technically and operationally, to contribute significantly to enhancing our information security programs.
United Health Care endorses the subcommittee's charter and invites further discussion in any area of concern. Thank you again for this opportunity.
DR. LUMPKIN: Thank you. Questions? I have one for Miss Forbis. Is it true that many of your members believe that physicians are dictators?
MS. FORBIS: Yes.
DR. LUMPKIN: Okay, just checking. I just thought we needed to break the ice a little bit.
MR. SCANLON: I can ask Randy to discuss his own question. You identified the potential difference between administrative payment data and clinical data, indicating that most of the EDI transactions now are on the payment side. What differences would you see in the national standard that would apply to you?
MR. SANOVIC: Well, I think that clinical data, especially that that identifies the individual as to treatment and certain diagnosis should be encrypted and hidden from view, and pass through any telecommunications network in that fashion.
On the other hand, I do believe that certain other information, much the same as the financial industries are handling a certain amount of accounting type information for accounts payable, accounts receivable, whatever it may be like that, probably does not deserve the same level of standard or the same level of protection.
I think to just across the board require encryption of everything would be misleading and inappropriate, and would use up quite a bit of resources, and cost just a lot of money that someone would end up paying for. In our case, it would be the general public, I think.
DR. FRAWLEY: Pat this is just going back to some of your testimony that talks about transcription being done in foreign countries. I'm just curious, those vendors who are providing those services by using transcriptionists in foreign countries, do you know what type of disclosure if any they are making to their clients?
MS. FORBIS: It is my understanding that unless the client specifically asks that question, that it is not necessarily disclosed.
DR. COHN: The discussion in this panel has really gone through much more than almost any other panel, in the sense of very technical discussions versus more policy. I was struck as I was reviewing the relatively extensive handout from Dr. Zubeldia -- in your recommendations around security standards, obviously you took a very technical view of things. You also made reference to the X-12.58 security standard in preference to other standards that we perhaps are a little more familiar about. I think I was not even well aware of that standard. Can you explain a little more about that standard and why that would be your preferred standard to other standards that might be implemented?
MR. ZUBELDIA: X-12 is relatively unique compared to other standards that we have been talking about. ASTM, HL-7, some of these other standards do not have the syntactical structures necessary to coney information between two different entities. X-12 does.
As part of the communications group that defines the X-12 syntax, they have defined the security syntax for providing the assurances within X-12. I have a copy of it here. If you want, you are welcome to make a copy of it.
The X-12 standard incudes this security syntax to envelope all X-12 transactions. It allows you to secure a single segment, if that is what you want to do. You secure the patient I.D. number, and not encrypt the rest. It provides for digital signatures, digital certificates, certification authorities, the same as everything else, as part of the X-12 syntax.
Most if not all the X-12 translators already understand the X-12.58 syntax for encryption and digital signatures and protection of the information. So what we see from -- because I am also a co-chair on X-12, what we see from the X-12 perspective is that the other standard groups are developing security structures to solve a problem that X-12 has solved many years ago, maybe 10, 15 years ago. Those security structures can envelope anything you want to put in it, including an X-12 transaction. So they have that obligation. But X-12 itself has its own security syntax.
DR. COHN: I actually want to look towards Kathleen to see if she can illuminate that further for me.
DR. FRAWLEY: I'm totally confused. I'm sitting here talking to Bill, in terms of -- I have never seen the draft standard before.
DR. COHN: Is this a draft standard?
MR. ZUBELDIA: It is not a draft standard, no. It is part of the X-12 syntax. It is called X-12.58, and it has been a standard for about 10 years, standard, not a draft. There was a change in X-12.58 syntax about three years ago to accommodate certificate revocation lists and digital certificates. There is also an X-12 transaction to do key exchange without having to use the security envelope. So you can do key exchange independent of the envelope.
DR. LUMPKIN: Let me see if I -- not being technical, I need to see if I can understand the portion of this that we are talking about. Much of what we have discussed today has to do with security in relationship to entity A, and their doing their business. Now we are talking about entity A sending it through clearinghouse B on to payor C. How that is packaged and the security that is involved in it, that is what is regarding the standard you are talking about in relationship to X-12? Are you really talking about, once you've got it packed up and --
MR. ZUBELDIA: X-12 is a syntax for transferring information between two entities, not within one entity, but between two distinct entities. HL-7 is within one entity.
DR. LUMPKIN: Right.
MR. ZUBELDIA: So X-12 has built into the syntax of how to transfer information, the procedures on how to transfer and encrypt the information and compress the information, digitally sign it, between two separate entities.
The reason why we looked into this was because, until July 9, we had been told that the security sections of HIPAA applied only to the transactions, and only the transactions needed to go under the security measures. On July 9, I requested clarification and was told that, no, the security applies to everything. So now there is much debate to secure medical records and other things that are not the HIPAA transactions. But the X-12 will cover the HIPAA transactions for encryption when it is necessary.
DR. BRAITHWAITE: Kepa, when we heard earlier from Mayo that they used PGP as an encryption methodology to send X-12 transactions from point A to point B, from your perspective, that is redundant? Or is PGP a method that could be used within the X-12 syntax?
MR. ZUBELDIA: PGP is a security envelope that can envelope anything you want to put in it. We are doing transactions with Mayo using PGP, and we find it a very inexpensive way to do it. The PGP license is very, very inexpensive compared to other security mechanisms.
So we are using PGP because it is convenient, it is inexpensive, it works in all kinds of systems, regardless of translator or whether they have a translator or not.
In May we did about 300,000 claims over the Internet using PGP. That is just a drop in the bucket, but it is 300,000 transactions in one month.
DR. LUMPKIN: But to follow up, I think the question is, they could also have used the X-12 security standard instead of PGP?
MR. ZUBELDIA: Yes, they could, but they didn't.
DR. BRAITHWAITE: Do you know why that decision was made?
MR. ZUBELDIA: Convenience and cost. PGP is chapter and it is more convenient. It works in all kinds of legacy systems, interoperability; there are all kinds of benefits to PGP.
MR. BEATTY: Just to emphasize, when I did my presentation this morning, we considered a clearinghouse one of our trading partners. In a situation where we were doing EDI transactions with Envoy NAIC, there was point to point and there was no need for the sorting and distribution. So we felt that it was easier for us and less expensive to do it just directly using PGP, rather than incorporating the X-12 syntax.
MR. ZUBELDIA: Another thing I would like to mention is that we only use PGP when sending data over the Internet. We do not use encryption in our millions of transactions that are going over other lines.
MR. SCANLON: If I can follow up Kepa again, Kepa, you indicated that virtually 99 percent of the health care administrative transactions, the EDI transactions that take place now, are over private networks, which I guess means dedicated restricted access lines among the partners, and a very small fraction over Internet. Could you characterize the security policies, if they are similar enough, that are employed in the private networks? Is there a way to characterize them in terms of what the security policies are and the percentage of coverage?
MR. ZUBELDIA: Private networks typically -- it is a dial-up line to an 800 number or a local number. It then goes through a switched virtual private circuit.
We have never seen anybody tapping into the line on a network like that, never heard of it. The wiretap act will give us enough protection to sue that person. The information is sent unencrypted, but it would require to physically tap onto the line.
Let me also mention that the security risk of somebody tapping onto the line is much lower than somebody breaking into a computer system in a hospital, where they have access to all the medical records stored in that system. So by tapping onto a physical line will get a small fraction of records pretty much at random without knowing where they are coming from.
So there is a difference in the risk, but still, we feel there is adequate law protection with the wiretap act to protect in that case.
DR. COHN: Can I change topics slightly?
DR. LUMPKIN: Please.
DR. COHN: Only because I thought we needed to do more work in this area to understand where it fits in. I am sensing that this and the other standards we have been describing are probably not in conflict, they are really complementary.
Now, having said that, I actually have a question for Mr. Sanovic. First of all, were you here this morning?
MR. SANOVIC: Yes, I was.
DR. COHN: Okay. In my reading for the record, it was the report from the National Research Council, they identified as a concern as they were reviewing issues of security the issue of secondary uses of data, especially by non-provider organizations. At least, that is how I interpreted some of their recommendations and concerns as expressed.
Obviously, you probably fall into one of those secondary organizations. And certainly, in your testimony you have commented extensively on protections of your network and for your providers logging on to the network and all of this. I was actually wondering, internally within your organization, whether your standards are such that you feel comfortable with the -- is it seven or eight items that were identified for the record, as security policies within your organization? Are these consistent with how your organization protects health care information within the organization?
MR. SANOVIC: Yes. I think you have two bounds to consider. You have the external networks and the internal networks, and the internal networks tend to be protected by multiple firewalls and multiple routers and filters. Then you have your intranets that reside inside that firewall. It is the protection mechanisms outside externally that you have to be real careful. If you lock into another provider's or sharing information outside of your own network, then you are open to anything that an outsider has access to that network that you are sharing from.
So that is where your protection mechanisms have to be bounded, at least by your firewalls and routers and filters coming into your internal networks. And internal networks we tend to protect very, very closely. We do have dedicated lines, like Kepa was mentioning, to protect those. It takes multiple types of firewalls and multiple types of routing systems to do this, and it is not free, and it is hard to do in some cases.
DR. COHN: If I can ask a follow-up question, the issue of these recommendations had a lot to do with policies and procedures internally. They included individual authentication of users, access control to insure that users only have access to legitimate information, audit trails. Are you comfortable with all of those as recommendations that you have already implemented?
MR. SANOVIC: Yes, I am comfortable with them internally. Externally, we still have to deal with external entities, businesses we in some cases manage or don't own but manage, and of course we share information from the outside. We are very protective of bringing that information in appropriately. We won't let it reside and being brought to us on the Internet like some external entities would like to do, because I think it is now a let's do Internet type of year, and everybody is trying to use it as a free medium. In some cases, we work around that by getting information via CDs or by tape, and not letting it come over the Internet unless it is suitably encrypted.
So yes, internally I am comfortable with the mechanisms, some of which are legacy mechanisms like changing I.D.s and expiring I.D.s and passwords, things of that nature. Externally, the telecommunications networks I think need great protection, and we have to be cautious of our free use of the Internet as a transport medium, because unless you make it secure, it is not going to be secure, it is going to be out in the open.
DR. COHN: So you do do audit trails and all of that?
MR. SANOVIC: Yes. We even monitor our use of the Internet, and how we access it. There is no expectation of privacy in using our computer systems for business use. In other words, we selectively monitor and assure ourselves that they are being used for business use purposes. Our policies dictate that use. So we go in and use various tools and methods of monitoring what is going across our internal and coming through our external network connections.
It takes a lot of time to do that. I have some very talented people. You can't do it all the time, because you can't review all that data. But we do take action where we find something inappropriate happening or a weakness that we should close off immediately. Most of them would come from external sources, so we take great care in that.
DR. LUMPKIN: Well, thank you. I think certainly we appreciate the information from the panel, and we are going to move on to our next panel on vendors.
The last panel for today is our panel of vendors. If we could start off with Mr. Ripps and go from there?
MR. RIPPS: Thank you for the opportunity to address this committee on the important issue of data privacy and security standards.
Public Law 104-191 creates numerous opportunities to improve the health of our nation by establishing policies to support the explosion of new technologies. This committee plays a critical role in consulting with the Secretary of the Department of Health and Human Services to adopt standards. These standards will not only impact vendors, but caregivers and patients alike.
As a privacy officer at Health Point, I along with my colleagues and management team applaud all activities to get to a standard in this area. We believe we have a vital role and stake in the policies that affect security and confidentiality standards.
Health Point, if you're not familiar with us, is a general partnership between Glaxo Wellcom and Physician Computer Network. We market a computerized patient record system called Health Point ACS. Our company is fairly new; in fact, it is only 18 months old. But we have more than 130 employees dedicated to the ambulatory care marketplace. These employees are working in the area of product development, -- in fact, over half of them are working on product development -- quality assurance and building open near real-time interfaces to support high quality health care.
The health care system and providers have been responding to the increased pressure to reduce costs, and now realize that quality becomes a competitive survival tool. The environment necessitates the caregiver to not only document patient encounters, but also to aggregate this information.
The ambulatory computerized patient record software is a revolutionary new generation of information tools that has benefitted from advances in software and the introduction of appropriate hardware. The appropriate computerized record system can satisfy these needs. However, a paper based system will not.
If CPRs are fully adopted, the CPR may be one of the greatest medical tools since the stethoscope. The CPR can provide the following: information that is portable, legible, accurate and complete, information real time that defines and supports understanding of disease process, information from queries that can monitor the effectiveness of procedures and medications, and information systems that can support patient safety, and lastly, information systems that can create efficiencies in the health care system.
Although the CPR will solve many problems facing today's health care system and caregivers, a host of other important issues, specifically, information security, privacy and confidentiality, must be addressed.
As stated in 1969 by Alan Weston, professor of public law and government at Columbia University, here is the dilemma. The computer is threatening our levels of privacy as never before, but it also offers more protection of privacy than we have had heretofore. As always, the machines are neutral. The answer depends on what man or woman will do with them.
At Health Point, we believed from the beginning that if we could set the standards by providing leadership in our industry, competitive forces would support imitation and innovation. For example, we have made a serious commitment in resources, both people and dollars, in our privacy principles, organizational policies and training we provide to our employees, distributors and end users. We have also made the same commitment in our product to address the issues many people have talked about today: authorization, authentication, access, audit trails and data integrity. Our principles, organizational policies and a summary article are attached to my statement.
I'd like to detour from my written testimony to briefly demonstrate how we have deployed these features in our product. Let me summarize my slides in advance by saying, we believe your internal security will determine your external vulnerability.
I just have a brief few slides to go through. In the earlier panel this morning, in fact the first panel, people talked about if vendors will address these issues. If you look at the last page of my testimony, the three key issues that I will be talking about around these slides are going to be authorization, authentication, how to handle access within our system, and then lastly, how we have addressed audit trails and data integrity. So I'll move through some quick slides real quick.
The first slide you see here, in that particular system we have embedded that every user has her own user name and password. In fact, the password is encrypted. What you will see on the next slide under authentication is, within our system we have a mandatory five-digit alpha numeric user name and password. Every caregiver has her own caregiver I.D. code within our system, and like the window prompts, the caregiver I.D. entered already exists, so you cannot duplicate it.
We have password editing that is set up. It is user controlled. It is unique for the user. Again, it is five digit alpha numeric. We also have a system enforced password length, and you can change this at will. In this case, you will see, the prompt assistant tells the user the password must be five characters long.
The system administrator or security administrator within the doctor's office has the ability to reset passwords on the event that one has forgotten. Within our system, we also prompt the caregiver for grace days. The grace days are 20 more days of grace log-ins. This can be user defined. In an advance slide, I will show how we have controlled that.
The system also monitors new passwords from old passwords and tries to manage some of the issues around authentication. The password can be set within our system at anywhere from 10 to 90 days. That is a site setup function. You can disable a caregiver upon -- if they leave the office or resignation, and that is an important function as well.
DR. LUMPKIN: Disable the password, not the person, right?
MR. RIPPS: Yes, right, disable the password, not the person. If you do enter an invalid password, if you are trying to use someone else's, or an invalid user name, the system will come back and prompt you with a window, letting you know someone else tried to access as you being a user I.D. or you using a password.
In terms of access, you can define the access within our system. It is user defined, so for an individual we have managed access. We have also done it by data elements. The way we have broken up our system, there was a lot of thought put around that, because from office functions, i.e. work flow, all the way to the history and physical report, the progress note, you can modify particular sections and you can give read, write or no access at all. You can also do it by types of caregivers or groups as well. So we have tried to pay attention to some of the standards that are out there.
Lastly, we can do it by patient. We think that was also an important consideration. We have addressed the need to know within our audit trail. You will see a reason required, if not preferred caregiver, and our audit trail tracks the reason that it was accessed.
We have also done in patient specific. In this case, you will see a prompt: you do not have permission to access a chart for patient Margaret Driver, in this case. You have user notification in terms of attempted access. There was one successful log-in attempt with our system. Again, the caregiver sees that when they log in.
The system administrator has the ability to disable the functions. Here is just a prompt reminder: would you indeed like to disable this particular caregiver? In terms of access again, we have tried to control the consecutive invalid access attempts. In this case, we have used one to five attempts, trying to make it useful. We also have an expiration of access privileges. That becomes important. Again, the grace days can be five to 20 days.
You can also manage access by contact. Caregivers have certain care paths in their assessment of plan. That may be their way of treating patients.
We have a time-out feature. We call it a suspend function. We think in the process of delivering health care that is more important than a system setup or time-out, for example. Caregivers using our system may be doing a physical exam that took longer. So in that case they can just suspend the system instead of having the system turn out on them, then log back in with their I.D. and log back in with their password.
We have audit trail and standard security reports within our system. We use Oracle as the database engine and sequel, so we have created a set of standard reports. Within every caregiver, in the log-in information, we keep an ongoing log on count and failed attempt by caregiver.
This is an example of one of our log-in reports. That measures the name, the average time, log-ins, total log-ins and percent of doubtful log-ins. We can also run the same reports by caregiver or by function area.
We think data integrity is also an important component of a health care information system. In our situation, we give certain caregivers the ability to change complaint text or the HMP report. The system will prompt you if you are editing within the structured field. In this case, the window says, have you changed the meaning of the text. So the system will follow you along.
Lastly under data integrity, the minute the record is saved, everything is time, date and provider stamped. It can no longer be changed. The way our system works is, it becomes an amendment to the original record. Again, that supports the audit trail.
That is just a brief overview of some of the things that we have tried to do within our system. I've got a little more I'd like to summarize, and then I'll finish.
As I said earlier when I started the slides, we believe that, if I could summarize this set of slides, your internal security determines your external vulnerability. Unfortunately, like many people have talked about this morning, customers themselves are very interesting to us as an information security vendor. While customers are asking us about product specific security features, I think customers know what they want, but very few of them know what they need.
Let me give you a graphic example of this. In preparing for my testimony, I thought about how could I quantify what customers want? The following summary is from our internal sales department, which handles our requests for information and proposals.
In 1996, the most frequent questions about privacy, security and confidentiality were: what security features do you have, how is confidentiality within practices managed. That is open-ended; oftentimes it is simply yes or no. It should not surprise you, because many of you on this panel know, in order to understand these issues, you must have a working knowledge about technology, policy development, and basic understanding of the vocabulary associated with this field.
Twenty percent of the RFIs we have received did not even address security last year. It would be nice to see RFIs ask about authentication, authorization, audit trails and data integrity, just to name a few examples.
In today's business environment, everybody must be able to demonstrate the value proposition in the business case. As a CPR vendor, we are always looking for standards. Fortunately and unfortunately, standard security feature software is changing quickly. For example, we have looked at voice authentication devices, retinal scan technology, token devices and signature recognition. Most of these technologies are not mature, and just moving in some cases out of beta.
We certainly think smart cards and tokens can be useful. However, we feel as though encryption certainly will leapfrog some of these technologies.
We spend a great deal of time establishing physical security with our customers. Many of our customers use decipher locks as well as key or limited access. We know the literature supports up to 80 percent of the security breaches occur internally.
We have done a great deal in terms of our product design to reduce or eliminate this threat. Our company's privacy training addresses employee awareness, physician awareness, patient awareness. I predict in the near future that organizations will develop policies and conduct privacy training for their employees, much like they do today on the issue of sexual harassment.
We would like to recognize the thoughtful development of education resources and programs developed by HIMA, CPRI and CHIM. As revolutionary health care information technology continues to mature, regulated standards would be helpful. After all, the issue of confidentiality and privacy is extremely critical to widespread adoption. Standards should alleviate most of the fears and concerns about health care information technologies.
We recommend that you develop federal policies that create a uniform national framework and a set of rules that can be applied consistently from state to state, that is, federal pre-emptive legislation. We would also like to work with you to identify criteria that defines a minimum benchmark for product features and functionality that is technology independent.
Accreditation bodies must play a role, and we would like to see incentives or tax credits for organizations that integrate, develop and/or adopt this technology. We also think there is a role to define uniform standards for electronic verification, storage and consent. We have already made a large investment, and continue to do so. Technology can support fair information practice codes. However, simplification will help support this development and deployment. The threat of allowing this important issue to be played out in the market and play on consumer fears will potentially destroy the benefits that powerful information tools can provide in the health care market.
Let me close by discussing the National Research Council's committee's recommendations on technical practices and procedures. We believe they are excellent, and we would like to make a call to industry to follow these examples. The recommendations were not published at the time we developed our privacy principles and organizational policies, but we believe we meet, exceed or in some cases aren't there yet in terms of recommendations. I have summarized them and our responses as follows.
Again, thank you for the opportunity to participate in this important issue.
DR. LUMPKIN: Thank you. Mr. Korpman.
DR. KORPMAN: Good afternoon. I see the eyelids flagging. I'm Ralph Korpman. I think I am the person who has been doing this the longest. Sitting up here, some of us just continue to reincarnate. I am happy to inform those of you that are desperately searching for our handout that it is on a UPS truck. All 75 of them, and my floppy disk. I apologize. I just blew in from overseas this morning.
I'm here representing Health Data Sciences Corporation. Health Data Sciences is one of the oldest of the CPR vendors. It is a division of Medifis Corporation. In my spare life, I am a professor of hematology at Loma Linda University, so I wear several hats, depending on the phase of the moon.
Medifis represents systems at about 2600 hospitals, does financial processing for about 20,000 physicians. So in any typical year, we do tens of millions of financial transactions, which we could talk about, and a lot of the discussions here have been about financial transactions. But I'm not going to spend any time on that because A, that has gotten fairly mature and B, I think it is totally uninteresting.
I realize that people like to retreat to that, because it is what we best understand. But in a capitated world, financial transactions pale in comparison to talking about something that is near and dear to my heart, which is managing care, which is different from managed care.
Most health care data is used for managing care. Of most interest to this group today is an operations optimization CPR environment that we have been delivering for a long time. We are currently spending a lifetime or as close as you get -- there are whole records on about 20 million patients as part of our product sweep.
A pretty broad spectrum of customers. We provide systems for organizations like New York City Health and Hospitals Corps, which is I think second or third behind Kaiser in terms of the size of provisions, and the largest municipal health care provision organization in the United States. We provide systems for Foundation Health, which is the fourth largest for-profit HMO in the country. We provide systems for Genesis, which is now the largest elder care provider. So we have a pretty broad reach in terms of the kinds of patient systems we provide. These are all electronic record, run your health care operation systems, not billing systems.
We have always focused on security. Some people around this table heard me talk about security ten years ago, when nobody cared.
I have made my Top Ten list of what we have learned about security. It is not nearly as clever as David Letterman, but when you have lost your prepared remarks, you have to give your unprepared remarks.
First of all, this is an area that I think has always been of compelling risk to people, and has only been appreciated in the last couple of years because people finally got afraid of the Internet. This has been a risk for the last five years, ten years, you name it. In most institutions, anybody could have walked in and taken a list of positive HIVs and walked out with very little grief. I'm thrilled to see this finally surfacing, because we have always thought it was a big issue.
Number two. Most providers still don't understand the issues here at all. He was being generous. We usually get, do you have security, yes, no, in development. These are from billion dollar IDNs. Some people are very sophisticated in this regard, and we heard from some of them this morning, but that does not represent the commonality of the marketplace at all.
The magnitude of the clinical data dwarfs the magnitude of the billing data. People talk about controlling external transactions, and that is all very interesting, but the magnitude of the billing data is far larger. It is number three.
Number four. There are very different internal-external issues dealing with clinical data, because there are all kinds of states and conditions that are very germane internally, that never transmit externally, but that are very key to the integrity of internal data.
In health care, two events separated by a minute can have a radically different meaning from exactly the same two events separated by a day. The kind of state information you have to track and the integrity of making that track changes your profile dramatically in terms of what you need to secure.
Number five. There are infinite permutations -- now we are going to talk about some of the risks -- in acquired security/privacy/confidentiality wrinkles. Just when you think you have seen them all, you run into another.
One of the downside risks of legislating it, which we will come out in support of before we're done here, is that you will miss a permutation and cause a problem. I'll give you just a couple of surprise cases, one at least.
In New York City, we keep a visit list. It doesn't have any secret information on it at all. It just says, when you came to the -- interacted with the system. This is a completely integrated system, in-patient, out-patient, does all those things. That is something that displays to the clerk so they know they can collect the five dollar copay if they can ever get it, or whatever, make sure you are on your meds.
Well, if you are a 14-year-old coming in once a week for asthma with your mother, so every week you have another things, asthma visit, asthma visit, asthma visit, and then you come in in between your two asthma visits by yourself and have your abortion, and the next time you come in, all of a sudden the clerk says, oh, I see you were here on Friday and the mother goes, huh?
So even something as simple as, did you interact with the health care system at all for certain peoples' purview becomes a major issue. So you have to be able to permute this at the finest level, based on where you are standing, who is looking and when they are looking. Anything that doesn't get down to the least level of granularity, it turns out, eventually you have to throw out.
We started out here with big, broad, sweeping things, and now we are down to each little thing being separately securitizable, because short of that, you eventually run into a case that becomes so horrible that people either throw the baby out with the bathwater or don't get in the bath.
Security is costly if you tack it on, and not very expensive if you build it in. The biggest expense of security that you heard talked about here today is CPU cycles. If you are going to PGP stuff or whatever, then you are going to use cycles. But cycles are getting so cheap on a relative basis that the issues that really concerned us once upon a time have become throwaway issues. We finally reached a point that I kept on thinking would happen next year, and it took about 30 years to get there. There are now more cycles to spend than you actually need to run the software you are trying to run. For years, your software was always ten percent ahead of the number of cycles that you had available, and it is just less an issue now.
Design issues are serious, and back designing security into an insecure system is almost impossible, because somewhere along the authentication level, you lose it.
Something people tend to forget is that the comparative here is the paper medical record. It is about the least secure document of any sort going on. I love to go to institutions that tell me how secure they are. I have 100 percent success rate of putting on a white coat, taking my Loma Linda I.D. badge and turning it backwards, and walking in and getting any number of medical records. I say, how many do you want me to get? Ten? Okay. I'll walk out of the hospital carrying ten records. A place I had never been before. It is just not an issue.
Anything we do should probably be an improvement over that. We don't want to do something so heinous that we don't get the improvement over the paper record. We have seen people say, fine, we'll just print it all out and be done with it, and then we really haven't gotten anything.
There are a whole host of basic issues -- I'm not going to review them here, and some of them have been up already, access, audit and integrity. But there are other issues such as durability. If you don't have a record that is always available, then it turns out people will print everything out. So when a system is down or when the data is purged or something, they can get it. Then you have all this stuff sitting in a closet, completely unsecured or as poorly secured as the current paper records.
So there are many twists. This is all laid out in the paper testimony, so you can read it. But there are many, many twists here that aren't normally considered. We consider encryption, and that is nice, but not necessarily germane.
Number nine. To be effective, there are other key issues that I haven't heard mentioned here. Transparency to users and ease of use is like way up here. If you create something that is so difficult to use, people won't use it, then you're dead. They will just complain loud enough until eventually, you turn it off. We have systems that people access in and out of hundreds of times a day. They go from room to room, going down the hall. So you have to create something that is secure and facile simultaneously. That is a lot harder than creating something that is secure.
It has to be real time interventional. I heard many people up here talking about how they will run reports tomorrow to tell you who did something wrong yesterday. I can think of no less good use of a computer resource than doing that. If somebody is about to do something inappropriate now, the point of the system is to stop them from doing it now, not to log an audit trail that tells you when the cow is already out of the barn.
I have trouble taking any of that seriously, because the point is to have real-time applicability of your security controls, not post facto applicability of your security controls.
Last but not least of my Top Ten, everything we are talking about here -- there is a wrinkle that I have only heard referred to. That is, one of the great potential benefits of having all this data on electronic form instead of paper form is that, if you non-denominate it properly, we can get extraordinary reach into the best way to care for patients.
A part of any security/privacy/confidentiality set of thoughts is now to non-denominate data and deliver it to anybody who wants it, really, who can start to churn through it and do something on a public health basis for masses of data.
I have run several clinical studies, I know some other people around this table have as well, where you couldn't get 100 good patients data, because by the time you did all the chart abstracts, it was worthless. But if you can get 100,000 patients, you can begin to wash out some of the noise statistically. That is of enormous value. I think rules to non-denominate data -- we spend a lot of time working on this -- are every bit as important to the public health as rules to control nominated data.
A few words about standards. They do exist. I am amazed that no one around this table -- I came in a little bit late, so maybe you started out to talk about the orange book standards, the DoD trusted computer system evaluation criteria. Those guys have spent more time than any of us around here contemplating security issues. They are not one for one transportable to health care, and they spend a lot of time with documentation artifacts that don't really make a lot of difference to health care providers.
But most of what they do is pretty important. For instance, we provide systems for the Canadian military hospitals that also care for the Premier and members of Parliament and whatever, and they are real concerned about security. We provide C-3 systems. Everyone understands orange book systems, and those are pretty secure, and we are getting ready to provide B-2 systems. We buy these off the shelf from other people that have had them certified on an operating systems basis, and we make our applications fit.
So there is a set of standards that, while not one for one applicable, certainly need to be looked at in the context of doing this, because they are understood and they are validatable.
The encryption standards I think have had lots of -- we use SSL and PGP as appropriate for doing our encryption. PGP is cheap, it always works. It is not very fast, but if you have enough cycles, it doesn't matter.
There are policy standards. I don't know if you know, but the province of Quebec has a comprehensive health care -- both policy and technology standard for health care information systems, which I would be happy to copy the committee on if you don't have it. They even did an English translation so you can read it.
But they validate systems. They have policies which you must follow. They have technologies which the systems must meet, and it is not bad. It is not perfect, but they have actually thought it through, and I commend that to you.
Then of course, there are all the other organizations we heard talked about today.
A couple of technical points, just to answer your technical questions that were in here. We think password validation is not enough. Passwords are easy. Letting users choose their own passwords is fatal; they always pick their birth date, their marriage date, their mother's maiden name or whatever, things that are fairly easy to get.
We use a token. We always have. To get on the system you must have the token and a password selected by the system. It will give you a choice of ten words and you can pick any one of them you think you can remember. If you don't like those, it will give you another ten. But you have no choice as to the words. You pick one, and then every few days it gives you another list and you get to do it over again.
If you don't have both a token and a password, you don't get on the system, just like you don't get money out of your ATM machine unless you have the ATM card and the password. It seems to me that getting health care data should be at least as rigorous as getting money out of your ATM machine.
We have a thousand security classes every day, securitized against every person, so we can be very selective. You have to be able to take it to the lowest possible level.
We encrypt anything that goes external. A lot of our things are point to point, where we control both ends of the wire, on campus things for a lot of IDNs. But things that are out over the Internet, you have no choice. We use 1024 bit encryption for exactly the same reason the gentleman brought up earlier here. We expect this to last a long time, and other than the fact that we can't export it, which is silly in itself, it will likely carry us long beyond the time that I care. Whereas, other ones are easier to -- and we use end user certificates. We use all the things that have become fairly conventional for external -- we used to call external dial-backs for all our external dial-in lines. You cannot dial in; you can only dial in and be called back.
Our goal has been to make it in all cases at least as secure as the paper record. Otherwise, I can get on the phone and say, hi, this is Dr. Korpman. Would you give me the HIV scores on my patients A, B and C? In almost all cases, somebody will say, sure, here they are. I can just as easily be Dr. Lumpkin, and who would know? It is that kind of thing. So we believe we are far more secure than that. Even remotely, you must have a token and a password.
We store all our data redundantly in a fault tolerant mode, so that the issues of, do I print copies of this out in case the computer will go down are avoided. Otherwise it is going to get printed out, because you can't afford to be without medical data.
Audit trails, we audit everything. It takes us no time, it takes us no grief. We know every access to every piece of data by every person. We control it in an interesting fashion. Some people can only get to the data on their patients. If you are a nurse and you are assigned to beds one to ten, and that is what you're going to do today, -- again, this is under the organization's control, but typically, that is what you get. If you are a physician, you typically have access to all the data, because doctors see patients in curbside consults, whatever. But if you are coming in to someone who is not your patient, the system interrupts you before you get in and says, we are going to log this access to someone who is not your patient, and we are going to report it to the following people. If it is legit, fine, and if it is not, you'll stop.
The worst thing to do is to go tell a bunch of physicians, you can't get at those patients. So they can get in, it is up to them, and it works well.
We actually just in the last month had two cases, one in the Midwest and one in the East, in one case a politician, in another case a sports star, that were in hospitals. In each case a hospital employee went in and looked, assuming nobody would -- an unauthorized employee that shouldn't have been looking at this, and within hours, one was dismissed and one was sent home for a week. It is something we do in real time all the time, because security and auditability tacked on afterwards doesn't make much sense.
Physical security is natural. You don't lock your computer room, then shame on you.
You asked about patient identifiers. We use an internal known only to us, encrypted patient identifier for doing everything. We keep cross keys also encrypted to all those external identifiers, the hospital number, the medical records number, the visit number, the social security number, whatever. But internally, we track these things with our own number. If we are doing transactions to other systems, we send the encrypted number, gather back the encrypted data, store it against our stuff.
So all of our patient transactions internally are done against a number that nobody knows except for the system. That has been fairly effective at putting another layer of security through the system.
So in summary, security has always been an issue. We are thrilled to pieces to finally see a cognizant group worrying about it.
The problem with security is that it is fairly technically complex. Very few people understand it, other than the fact that they should have some.
Now, I am not a great fan of a federal role for anything that can be avoided. But here is a case where I do think in concurrence with what we heard from a lot of other people that a minimum expectation set, your system should provide authentication in the following ways, auditability in the following ways, permanence in the following ways, persistence in the following ways, and I have got a list of these in the written testimony, which you will get here as soon as UPS comes off strike, or I'll make some more. I think it would be of great benefit.
I'm all for tax credits or whatever. I don't think you need them. If the rules appear, the customers will request them and the vendors will do them. We'll all be happy about it, because the guy who gets there first gets a few more customers, so they will all race out to do it, and that is okay, that is the way the marketplace works.
But because the buyers are so unsophisticated, and because the risks are so high, and the political prominence so profound, I think it is one of those areas where -- and not use PGP or DI; I think that is silly, but something that says it must meet B-2, if you want to be easy about it, or it must have the following authentication features, auditability features, whatever, on a policy level that is going to be implemented in whatever technology, would be exactly the right kick in the shorts. I think it would definitely be an improvement for patient care.
I think the time has come, and I think it is probably resting in the right place. Thank you. MR. PROCTOR: I am pleased to be here, and would like to thank you for allowing me to testify before this subcommittee.
EDI within health care is an area in which I am intensely interested, and the opportunity to be involved in the deliberations of security standards is very exciting for me.
My involvement with EDI in health care began many years ago. After graduating from college, I became involved in managing my father's radiology practice. We purchased a micro computer and I wrote the programs to accommodate his billing. After realizing the inefficiencies of paper claims, I approached Medicare and asked them to let me transmit claims to them via telephone. They agreed to let me work with them on a pilot project, and in 1981, we began transmitting.
In 1994, I was introduced to a new technology that I was convinced would impact health care EDI in a far more fundamental way than electronic claims, the Internet. A friend and I were discussing the Clinton health care proposal, and I remarked that I would like to get a copy to read. He sat down at a terminal and logged in to several universities, looking for the legislation. He found it soon enough at a university in Germany. I still remember my amazement as he hopped around from computer to computer all over the world.
After spending two more years investigating the Internet phenomenon and its applicability to health care, I decided to leave my position with the practice management company and to found Passport Health Communications, a company devoted exclusively to the use of the Internet for health care.
One of the main advantages of the Internet is its presence or ubiquity. One of the main concerns of the Internet is security, and much of our effort at Passport Health Communications has been to understand the security issues and the solutions.
I would like to make three main points, and in so doing, answer some of the questions that you have asked.
First, I would like to make the point that the Internet is the technology that will be used to deliver health care transactions, especially the set of transactions you were charged with investigating. The reason this is important to understand is that legislatively, you can play an active role in the process by developing standards that are Internet friendly, where you can play a reactive role by requiring Internet unfriendly standards, we would like you to choose Internet friendly standards.
Let me give you an example. One of the questions was, did we select DES or SSL Entwine. We have chosen to use SSL, because it is a much better choice for Internet-based commercial applications.
Secondly, security should not be seen as a restrictive technology, rather, an enabling technology. Let me give you an example. One of the biggest fears in the Internet has been the use of credit cards. Recently, a new standard that allows a person to make a purchase over the Internet has been developed by the credit card industry. The process they use insures the merchant never even sees the customer's credit card number. Thus, the transaction is actually more secure than handing your credit card to a waiter that disappears for five minutes, or ten or 15. In this instance, the proper use of security actually enhances trade, rather than restricts it.
In a recent address to the National Press Club, Donna Shalala said, quote, almost 75 percent of our people say they are at least somewhat concerned that computerized medical records will have a negative effect on their privacy, close quote. While privacy is an ethical issue that must also be decided upon, security is the vehicle that makes it work.
For a security solution to be enabling, it must be highly effective, easily deployed, low cost and non-intrusive. Many companies using the Internet use security tools that meet all these criteria. In a recent DHHS public meeting on security, John Parmiagiani spoke on the use of digital signatures. He said, quote, we have an opportunity for a much higher level of protection or security than we have in any kind of hard copy or manual process, close quote. The Internet is an extremely effective platform for using digital signatures.
Much has been said about keeping the cost down and developing a solution that is not prohibitive for small players. The Internet offers the way to meet the objectives laid out by John, and meets the requirements he laid out as well. These include a technology neutral solution, interoperability and the use of standard tools.
To make digital signatures work, you need a certifying authority. This is someone that issues the digital signature and then verifies that the recipient of the signature is indeed who they say they are. The certifying authority then electronically verifies or certifies the identity of that individual for future transactions with other parties.
I believe the government could play a role in defining the standards a vendor must meet, and then allowing them to be the certifying authority for health care providers. Such an approach would be low cost and would allow small vendors as well as large ones to participate.
Thirdly, I'd like to encourage the committee to come up with improvements that head us in the right direction, rather than a comprehensive solution that is difficult to enforce.
One of the questions touched on the use of smart cards and biometrics for authentication. While I believe these will be the solutions we use in a few years, I don't believe it is practical today. I think the standards should accommodate the use of those solutions, but not require that we start there.
One of the questions for the hearing was, quote, how should these policies and procedures be communicated to internal and external users as well as consumers, close quote. I'll bet you can guess my answer to that question. In preparing my testimony, I accessed your website. It was there that I found a transcript of Donna Shalala's presentation to the National Press Club. I was also able to find out that John Parmiagiani made a presentation on security last month. While sitting in my office, I was able to look at his slides on my screen and listen to his 40-minute presentation at the same time.
We at Passport Health Communications believe that the Internet offers a great opportunity to cut health care costs by delivering data in a more timely, accurate and efficient manner. We also believe that HIPAA offers an opportunity to propel the momentum even more, and look forward to being involved with the implementation of HIPAA.
Thank you for this opportunity to address the subcommittee.
DR. LUMPKIN: Thank you. Dr. Baker?
DR. BAKER: Good afternoon. I'm Dixie Baker and I am the chief scientist for the Center for Information Security Technology at Science Applications International Corporation, a large consulting and systems integration firm.
I have been working in information systems security for over 16 years, and for the past two years, most of my work has been in the health care industry. I now am the security architect for a major HMO and a principal investigator for a research project that is building a system to provide secure Internet access to highly sensitive patient information. Much of my testimony today will draw from recent experience in these two projects.
As I respond to the specific questions I have been asked to address, you will notice that my observations and comments tend to center around the following two major points. One, privacy protection is necessary, but not sufficient. Health care security requires protecting both the confidentiality of patient information and the integrity and availability of health care data, software programs and services. Privacy clearly is an important social issue, but integrity and availability are critical human safety issues. Perhaps the most challenging aspect of health care security is obtaining the optimal balance between privacy and safety. Secondly, security technology is necessary, but not sufficient. Security technology provides important functional capabilities, including authentication, access control, encryption and auditing, which you have heard about today. However, security technology is only as strong as the information system components upon which it depends. Effective health care security requires a dependable and responsive information system architecture.
Now let me address the specific questions I was given. First regarding products. SCIC is not a product company. However, our research project with the National Library of Medicine is developing a prototype system to provide highly secure access to patient information over the Internet. This system will be deployed within the University of California-San Diego medical system, and ultimately will be delivered to the government, so I will respond to this question from the perspective of that product.
PCASSO, which stands for Patient Centered Access to Secure Systems Online provides a number of security features. But more importantly, it is built on a high assurance architecture. The PCASSO access mediator comprises a server that runs on Data General's E2 DGUX operating system and the trusted Oracle 7 database management system, which collectively enforce a role based access control policy. The access mediator uses label-based access control to separate and protect five hierarchical levels of sensitivity: non-patient identifiable, or low, patient identifiable, or standard, patient deniable, which is like HIV, AIDS, abortion, adoption, mental health, guardian deniable and patient deniable.
PCASSO uses the secure socket layer SSL encryption protocol and public key encryption to mutually authenticate the client and the server, after which it authenticates the user, using a challenge response protocol. Following authentication, all transactions between the client and the server are encrypted, using secret key encryption. Individual users are granted access to data and the ability to perform specific functions, based upon their assigned roles. All actions are audited, and SCIC's computer misuse detection system is used to detect potential intrusions.
Unlike most other systems, PCASSO also has design features and functional capabilities to protect the client environment, which in the prototype is presumed to be the highly insecure Windows 95 environment.
The second question regarding customer needs. Health care providers are asking for guidance in implementing security that will enable them to conduct their business while complying with legal and regulatory requirements, avoiding costly legal suits, and presenting themselves in a good light to the existing and potential patients.
As I mentioned in my introductory statement, I think one of the greatest challenges of health care security is to effectively manage the balance between privacy and safety, that is, protecting patient privacy without unduly constraining the system, such that critical information is not available when it is needed for care.
Some specific security capabilities that customers are asking for are efficient and user acceptable authentication, including single sign-on, role based access control, ability to get to the information they need from wherever they are, assurance of high quality data, accreditation of user actions, particularly access to patient records, digital signatures, secure e-mail, secure Internet and web access, secure remote access, secure networks, convenient security administration, secure communications with patients, and protection against viruses.
You asked the question, is cost a factor. Of course, but so are costs associated with fines, lawsuits and the loss of patients and members resulting from bad press.
Regarding technology from other industries, and can technology be used from other industries, definitely. Most of today's security technology came out of the Department of Defense. Specifically, the DoD's trusted computer systems evaluation criteria published in 1985 define the requirements for operating systems, and was later extended to database management systems and networks.
The TC SEC C2 rating has become an industry standard, and is the minimal requirement for all government systems. The TC sets functional and assurance requirements with the basis of the European and the Canadian standards and the new international common criteria. Similarly, encryption technology originated within the DoD, and has been broadly adopted.
The banking industry is a good model for how security technology that originated within the DoD has been applied in a non-government commercial arena. Several large banks are using the same label based access controls used by the DoD to protect classified information, and encryption has been used in banking for decades.
Unfortunately, many health care enterprises are incorrectly assuming that electronic commerce will provide a ready-made solution for securely transmitting health care information over the Internet. Although electronic commerce solutions clearly have a role in health care with respect to purchases and sales, they fall far short of providing a solution.
Electronic commerce solutions address one part of the problem, the transmission, specifically, credit card information. Also, they assume shared risk between the credit card holder and issuer, an approach to risk management that is not applicable to health care.
PCASSO is a good example of how security technology developed for other industries can be used in the health care domain.
Regarding risk and how we communicate it, thanks to media coverage, most health care enterprises recognize the importance of taking appropriate steps to protect the privacy of their patients and members. But we attempt to broaden that focus to see the complete business problem, protecting privacy and human safety. So this question relates directly to my first major point.
In my opinion, the most serious security threats to health care enterprises are those that threaten the integrity and availability of critical systems, programs and data. These threats include insiders and outsiders as well as malicious and misbehaving software programs.
Seeing is believing, so one of the most effective ways we found to help a client see these threats, and the associated risks and exposures, is through our penetration testing and vulnerability demonstration. In our penetration exercises, a penetration team attacks a client's secured system. Obviously, clients have us do this only when they think their system is secure. Yet, we have about a 90 percent hit rate, in many cases resulting in a total takeover of the system. Interestingly, very few firewalls prove resistant to penetration.
Regarding security architecture, this question relates to my second major point: no security component can be any more trustworthy than the components upon which it depends. So from a technology perspective, it is essential to look at the entire architecture and the dependencies inherent in it.
In general, the lower in an architecture the security capability is integrated, the more difficult it is for a malicious or misbehaving user or computer program to circumvent it. The higher in the architecture a security capability is integrated, the easier it is for a malicious or misbehaving user or computer program to circumvent it. So for more assurance, build an infrastructure that provides security services to applications, rather than adding security bells and whistles to applications.
Developing an effective security architecture must be tightly coupled with developing the overall information security architecture. Particularly in health care, the focus must be on developing a dependable system, which goes a long way toward developing an effective security architecture.
Developing the security architecture involves performing a risk assessment, developing a strategy for attaining an effective balance between risk avoidance, risk acceptance and risk sharing, developing a security policy determining what technology is needed to enforce the security policy and specifying security standards, and designing and integrating this technology into the overall architecture.
Finally, how do you avoid technology dependent security procedures? The best way to avoid dependency upon a particular vendor or technology is to specify standards, either de facto or de jure, whenever possible.
For example, by specifying a C2 operating system, the enterprise is assured that its system will have the hardware isolation of system and application execution domains, as well as essential security features such as user authentication, identity based access control and auditing. Yet, they will still have a wide range of specific products from which to choose.
Similarly, a number of products support the open group's distributed computing environment and CURBEROS authentication. A growing number of web products support SSL and JAVA, and most encrypted products use RSA for public key and DES for secret key encryption.
Thank you. I'd be happy to answer any questions.
DR. LUMPKIN: Thank you very much. Any questions? Simon.
DR. COHN: I think I actually need the help of the panelists on this one. I am in my own mind trying to put together a framework for what we need as a committee to be doing. I think I am beginning to see the overall picture, and I am a little uncertain where the various pieces that have been identified by the panelists, things like C2, B2, all of these other things, fit into these pieces.
Maybe the committee can help me on this one, but I certainly appreciate that there is a need for security within these information systems. There is need for policies around security. There is also a need for security having to do with linkage outside of these systems and between systems. There are probably others that just haven't come to me quite yet.
First of all, I should ask the committee, is that an appropriate framework to begin to look at these things? Those three items? I see people nodding their heads. So where do these various acronyms that you have thrown out fit into those areas, the orange book, C2? Dixie, you had a couple of ones that you added on.
DR. KORPMAN: Orange books, C2, those are all pieces of the same thing.
DR. COHN: Do they handle all of the issues that I have just described or do they focus on one versus the other?
DR. BAKER: I spent about 14 years evaluating products for the NSA against the TC set. So I probably have it tattooed on my back.
Basically, it is a hierarchical structure of functionality as well as assurance. It begins with C2, which is the minimal requirement. C2 to me is the very fundamental of security. You don't even have a chance of getting security unless you have hardware isolation of execution domains, which means that the operating system is protected from applications.
So if you've got a virus or a Trojan horse or some malicious code, or even a bad user that wants to do bad things, that cannot affect the operating system, which is a traffic cop of the system. And C2 has that. Windows 95 doesn't. Windows 3.1 doesn't. So you don't even have a chance with those kind of things.
In addition, it has authentication of users, it has access control based upon your identity or membership in a group, and it has auditing.
Then they go up. In B1, you add label based access control, which enables you to do what we are doing with PCASSO. The system structure that identifies files will have a label in it, and that enables you to do that. It goes up through A1, and basically going up the chain, you are looking at assurance, which is the degree of confidence you can have that the operating system at work is doing what it is intended to do. A1 is mathematical proof of correctness of the specification. C2, B1 has very little assurance at all.
When we evaluate those systems, we do functional testing but no penetration testing. B2 is the first that has penetrating testing, which is primarily that, and the fact that it is modular in its structure are the reasons why we targeted that.
DR. KORPMAN: Simon, there are no products that you can find out about that are A1 compliant. B2 is about the end of the commercially purchasable -- and a lot of military stuff takes place on B2.
DR. BAKER: Gemini Systems has an A1. Give them credit. But it is not generally usable.
MR. PROCTOR: I feel like to some extent, you are starting with a clean slate. What I feel like is needed is not a lot of detail, in terms of giving people specific direction. But there is a policy need, and part of the role that you're going to play too I think is to legitimize some of the things that people are doing.
I think some of the confusion in some of the issues with vendors is really not knowing what the legitimate issues are. I think that if you legitimize some of the directions people were taking, that would be a very valuable thing for the industry.
DR. KORPMAN: The orange book is the archetype of what I think this group should do. It doesn't say buy this system from this guy in this way, and use this encryption mechanism. It says, if you are to meet these criteria, this is what your system will do. You cannot screw up this part from this part, period. Depending on what level you are, a higher level, more things.
We can come up for health care -- we can certainly piggyback off those, because everything in the orange book is germane to the health care system, it is germane to any computer system. But we can also say, with regard to authentication, this is what your system has to be able to do. It doesn't matter how you use it. I don't care if you scan retinas or look at pinky fingers.
With regard to auditability, this is -- with regard to changes, the whole issue in the Bennett bill had impossible, for instance, criteria for editing and maintaining change records and passing them down the line for emendations to records. But you have to have criteria for emending records. When you emend a record, how does it change, how do you record the change, who gets the data, and how permanent is that, how accessible to your records have to be, how persistent do your records have to be.
Without any technology at all, you can come up with a set of criteria, and I'm sure any of the vendors here would be happy to help and any of the providers would be happy to help; there is a lot of expertise floating around here that deals with things that are good to have, and then the marketplace will sort out how to get them. I don't think you're going to be looking for anything that somebody doesn't have somewhere already. But there are many ways you can get to B2, but when you are at B2, you are at B2, and you know what you have, and who cares how you got there?
That is I think the level at which regulation would be of merit, not use PGP or secure sockets or whatever. Not that there is anything wrong with those, but you should have a non-crack codable key at least 128 bits or 512 bits, or pick whatever number suits you, securing your Internet available transactions. People will find out what to do beyond that.
I suggest on top of the orange book, there are significant things upon which one can immediately rely that are useful. They are just not enough.
DR. LUMPKIN: Let me follow up on that question. I think that for this work group, what I am hearing being recommended for us is a departure from everything else we have done in the last six months of our short life, which is to adopt standards. The standard says that the record shall be this long, and in this particular place you can either put a yes or a no, and everybody is going to do it that way.
What I hear you describing are not standards, but requirements and specifications. A standard is something that you look at the 32nd place in this data string, and it is either going to be one of the accepted values. One can tell whether or not you meet that standard. A requirement means that you need to have a test mechanism or organization to verify that you have in fact done that.
So the mechanism of insuring compliance is totally different than we have been looking at, also.
DR. KORPMAN: And such organizations do exist. We send our stuff to Hughes. You can send it lots of places to have those kinds of verifications made.
DR. LUMPKIN: Is that a fair description? Does that define what we are grappling with? I think if we are looking for a standard, what I am hearing is, it ain't out there and it shouldn't be out there, as much as the requirements and expectations and specifications.
DR. FRAWLEY: On the NRC study committee, we studied that for a long time, and we chose not to go with recommending standards as much as saying there are lots of different approaches that organizations can take. I think the last thing we want to see in this area is very prescriptive, one size fits all approaches, because I think will do more harm to industry.
As Ralph pointed out, people are going to get very creative and figure out very quickly how to develop products, and the market will shake itself out.
DR. LUMPKIN: Let me just take this one step further. What we are describing is also different. What we have done in the first six months is deal with how separate entities deal with each other, and we have not been prescriptive on how they communicate data within that entity. In fact, what we are dealing with, except for our brief discussion about some of the encryption standards in X-12, we are really talking about the internal work of some sort of definable structure. I think our challenge is dealing with that definable structure, to the extent we have a very variable health care system with multiple structures in place.
DR. KORPMAN: IF I can just make a comment, one of the great failings of all these discussions, not this particular group, but all the discussions in this area have been, they have always retreated to the X-12 level of, here is a payor and here is a sender, and how do we get interesting billing transactions -- yes, there is a clinical data construct, but it is the last one that got thrown in there for the heck of it.
It has always been the inter-party transactions, because that is where the money went, and if you want to find out what is going on, you find where the money went. All of the real important data is not claims data, it is health care data. And all of the real dangerous security data is not really claims data, it is health care data. It is all inter-organizational.
If you look at the general geographies, in each geography, what we are ending up with is depending on the size of the geography, two, three, four, five, six major players who are writing capitated contracts for big groups of people. They have their network, and you basically get your health care inside their network for practical purposes, and that is the way it is sorting out.
So the real issue is, if you are in the Kaiser network, then you're going to be in Kaiser. Yes, you might be out in the desert and get permission to go someplace else, but the issue is really, all this data is floating around in Kaiser, and that is where the risks are, and that is where the data both in the public health interest and certainly in the interest of Kaiser is. That is where the differentiation between the providers will become, because if Kaiser can do a better job of taking care of their patients than Foundation, then Kaiser will win the very odd, in this country, competitive war of who is the better health care provider.
High quality eventually always wins because it costs less and secondly, it always wins in any of these environments. So this is a very key area, and looking at inter-organizational transactions is important. But it has been almost the exclusive focus of everybody for a long time. That is why I am delighted to see it going elsewhere, because the risks are elsewhere.
MR. BLAIR: Apparently the orange book was developed and C2 specifications were developed before there was widespread use of the Internet. Maybe you could help us understand whether applying C2 standards or specifications -- will that be consistent with some of the emerging security technologies that are being used to try to add security to the Internet?
DR. BAKER: I'd like to respond to that. The C2 and the TC SEC and -- well, first of all, let me go back and say that security is definitely one of those phenomena that suffers from the weakest link phenomenon. If we are talking about exchanging health care data between entities, you can't ignore how well it is protected at the ends of that connection. If I am working for Kaiser and I am exchanging data with PacifiCare, and PacifiCare's health care security policy is weaker than mine, then I take on their risk, because I am exchanging data with them.
Now, what you will get from TC SEC is strength in the end nodes, in the hosts, the operating systems, and you will get protection in the host. There are other standards out there -- we just mentioned TC SEC, but there is also the IP SEC. They are adding security to the IP protocol. There are all kinds of -- that would address the link between them.
So the idea is that you come up with an architecture that from end to end protects the integrity and the availability and the confidentiality of data. You can't avoid any of it.
I think the worst mistake this committee could do is to come up with a list of bells and whistles and throw it out there, security bells and whistles and throw it out there to health care providers and say, okay, you've got to have passwords of eight characters or less, and you have to have access control and you have to have auditing every five minutes, and you have to review it eery Tuesday at three. That is why too fine a granularity for this committee to be targeting, besides the fact that technology changes too quickly. Next week, your recommendations would be totally out of date.
So I think looking at existing and emerging standards, de facto and de jure, is the right way to go, and to come up with the right combination of those to provide end to end protection.
DR. KORPMAN: Just a short answer is that the orange book is necessary, but not sufficient to securing end to end stuff. For the environment which was developed, it is very good, and I see no reason to recreate it. There were some people in health care that strongly believe it should be recreated, because since it came out of the DoD, it must be no good for health care, and they are very vociferous about it.
But we looked at it and said, we can do this. It is well tested and well thought through. Now, it doesn't cover everything. That is why I said you need at least that, but you peg a few of these things and start to put them together, and you have a start. Some of it is uniquely health care, and you really have to go back to the CPRIs or the HISBs to put this together, like what kind of authentications do you really think are important to health care, as opposed to a general system, and what kind of auditability do you want to have. Some of it is very generic. Everything has to be worked this way all the time. It is some mix of the generic IT standards and the health care specific implementation.
Again, there are state variables that have to persist in health care that really don't matter in most other environments. So it requires some collusion of both the standards that are already there and the health care community standards tweaking. All the pieces are there. Government is best when they can place a small shoe in the rear anatomy and push it.
DR. BAKER: We should also mention the common criteria. The TC SEC actually is being overtaken by events, and now, as of January of last year, there is an international standard that converges TC SEC and the European IT SEC and the Canadian CTC PEC. They all came together and they came up with a common criteria that is specifically designed so that you can develop a protection profile that is specifically targeted toward health care. That was talked about earlier. One of the handouts includes a draft protection profile for health care.
MR. BLAIR: I kind of hear from Ralph and Dixie in unison, feeling very comfortable with heading down this path. How about our other vendors who are guests here? Do they feel comfortable with this?
MR. RIPPS: I appreciate your asking. I was kind of thinking about it. Being one of many vendors who are marketing a computerized patient record, and also knowing for the most part about how little implementation is really occurring with this type of technology today, I am pretty convinced that our solutions will be the vehicle or the collection tool that begins to get on this highway that needs B2 or C2 type of technology.
I think you have to go back to the basics sometimes and say, if this is our collection tool, or the vehicle in which we are going to begin to move information, what should the end user, in this case the physician and the patient, expect in this part of the process? We think as one vendor that we can make that collection a little better than the paper based standard today, and that we have a responsibility to be involved at that very simple level.
It is fun and exciting to talk about encryption and technology, and it is an area of expertise that two of my colleagues have far greater than I do. For me, it is a hobby that I read now. But in a sense, when I look at lava lamp encryption, and that seems to be the new mathematical formula last week in The Economist, so be it.
So I advocate, get back to the basics. The basics are policy, education and technology. That is where I think we can play a role.
MR. PROCTOR: And I think from my standpoint, I would probably reiterate that I feel like what we need are guidance in terms of some of the standards that will be perused, as opposed to specific implementations of those standards. I agree that the market will bear out good solutions to accommodating that direction.
MR. RIPPS: Let me tell you, security does not sell our CPR system.
MR. PROCTOR: Nobody cares.
MR. RIPPS: Nobody cares. We wish they would, because we think we do pretty well.
MR. PROCTOR: And they need to care.
MR. RIPPS: That's right.
DR. MOR: Over the last six months, we have grappled with a number of these issues, particularly in the commercial side, when people are talking about who is exchanging what information, mostly commercial information that has little bits of clinical data associated with them. What is internal and what is external has always been a big issue.
I continually am convinced that there is no such definition of what is internal and what is external, because at the rate of gobbling that occurs and disgorging that occurs in the industry, what was once a partner will be a competitor. Somebody's records are left disjointed between two entities that are now there, and somebody, the individual consumers, including all the docs and providers in between, need to have some sense that there is a standard mechanism by which everything is treated the same, regardless of whether it is internal or external, at the level of the patient record.
I think to the extent that these standards exist, or guidelines, they should be applicable across the internal and external barrier. Have I understood that properly?
DR. KORPMAN: Are you talking security standards?
DR. MOR: Yes.
DR. KORPMAN: Clearly, security standards should be applicable. Now, when you are talking about who gives what data to whom, now you're into political turf that I wouldn't begin to discuss.
DR. MOR: Those are issues related to privacy and data ownership and those kinds of things, which I think have to be grappled with at some point. But security is what I was talking about.
DR. LUMPKIN: And the other piece is that we do have the computerized patient record on our -- it is on our menu.
DR. MOR: Closer and closer.
DR. LUMPKIN: It is our entree, but we are still working on the appetizers.
DR. COHN: First of all, just based on your last comment, I would remind everyone that as we look at the information in these transaction standards, and especially as we move to claims attachments, we are going to get very confused about what is clinical data and what is administrative data. I think security had better handle all of it. An ICD-9 diagnosis of something, of a sexually transmitted disease or HIV or psychiatric problems. It doesn't matter to me whether it is an administrative transaction standard or in the text of a clinical note. So I think we need to be aware that this needs to apply to all of them.
Now, having said that, I just wanted to clarify in my own mind, as we have been talking about all of these security standards, I am a little unclear about -- there seems to be some line at which security standards stop, and then there are policy standards. There may be policy standards being worked on by ASTM or whatever, but there is a line between the security standards and then the policies and procedures around the security standards. Is that correct? Is that how those things fit together?
DR. KORPMAN: There is not a line. Neither one can exist without the other.
DR. COHN: Right.
DR. KORPMAN: You can have the world's best policies, but because humans are humans, unless you have technology to make sure they are generally followed, you won't get anywhere. Similarly, you can have great technology, but leave your computer door open and somebody can just go in and hack it out because they can take the disk home with them.
That is why I think the Quebec model is nice, because it addresses both of those. It is several years old now, so we could do a lot better if they did it now, but you clearly need both.
One of the nice things this group could do is say, you have to meet the following policy criteria and the following technical criteria. Do it any way you like, but this is the end result from the patient's perspective.
DR. COHN: And just to make sure I understand, these B's and C's and all of this stuff, are the criteria we are describing, as opposed to how to do it?
DR. KORPMAN: Yes, those are criteria. There is no implementation lore in there.
DR. BAKER: They have nothing to do with policy. Policy is nothing but a set of rules to be enforced, period. Then once you get your set of rules to be enforced, you could in fact enforce the entire policy without any security technology at all. You just could say, here's our procedures. You come in the door and you sign the guest book, and you say I'm here, then you go and use your computer and you sign out. But technology is what helps you enforce the policy.
Every health care enterprise has to decide how their policy will be enforced, how much will be enforced through procedures, how much will be enforced through sanctions, how much will be enforced in the technology.
DR. KORPMAN: All those organizations I carried the medical records out of had a policy that says I can't do that. But they don't have the technology to stop me from doing it.
DR. FRAWLEY: In the NRC study, we categorized five threats within a health care entity, and four out of five threats were internal. So if you look at the report very carefully, what we say is to have adequate security, you have to have organizational practices and technology. So you can't have one, as Dixie pointed out, without the other.
So if you look at Chapter 6, it gives you an array of what an organization should do in terms of organizational practices, and talks about enforcement and disciplinary action. One of the things that we found in the site visits was that there were different standards of conduct. We would talk to nursing staff who would tell us that they knew of coworkers who had been terminated. Yet, physicians had engaged in the same behavior and were still practicing in an organization.
The other thing of course is the technology solutions. That is where the dynamic is constantly changing. But what we found when we went into organizations and sat down and met with users, and looked at what they are doing, the problem that we saw -- and the report said it loud and clear -- is that people have got books and books and books of policies, or medical staff rules and regulations, but nobody is enforcing it.
We asked questions like, do you have audit trails? Yes. What do you do with them? Don't look at them. Well, what good is it? So that was the kind of schizophrenic behavior we observed during our 18 months, was that people had lots of things they could show us, but then when you went to the nursing unit, you saw anything but what the CEO had told you was going on in the organization.
DR. KORPMAN: One of the things that never gets properly discussed here that is absolutely key is, if these things are not applied in real time, they are just not worthwhile.
MR. PROCTOR: One of the things that I was interested in is to not get too detailed on some of the rulemaking, either on the policies or the standards. As I said, you start with a clean slate, so if you could do a few good things, that would be -- we in our state are going to start making eligibility data available via the Internet. One of the contracts that the state presented us with to sign, we had to sign that nobody that used our product would smoke. That had to do with something with child protection. It just crawled all over me. I was going to argue with the lawyers and all, but the president of our company said, no, go ahead and sign it, because it is unenforceable and it doesn't matter if you sign it, anyway.
So we signed the thing saying nobody smoked that uses our product, for that particular eligibility. That is why I'm saying, you can get a little too far with details.
DR. LUMPKIN: Let me see if I understand that comment. We have got to go back to the drawing board on our regulations that deal with smoking?
MR. RIPPS: I just want to also -- we have heard a lot about organizations and associations. I just want to maybe bring to light again that there are 450,000 plus ambulatory practicing physicians. While they may not have the luxury or the resources to develop policy, to be thinking about the issues that large organizations have come before this group today to discuss, these people are beginning to implement technology like ours.
Let me assure you that disclosure is a very interesting issue for them. Just from what I have heard from one recent physician, you can pretty much get a subpoena off the shelf today, and how do I train my employees.
So I want to bring to your attention that it is not just enterprises and IDNs, but in fact, the ambulatory care marketplace will make up those future IDNs, and has some very unique issues themselves, which often overlap what you have heard today.
DR. LUMPKIN: I just want to follow up on that. I think that what we also consider as our charge is the realization that many of the people who are physicians and other clinicians in practice are there to take care of patients, and part of our job here is to set the standards, so that when they get that thing off the shelf, or someone comes in their office, they won't have to know what the security requirements are.
DR. KORPMAN: It has got to be transparent to the real health care provider, because they don't care. They should, but they don't, and they shouldn't have to.
MR. RIPPS: What is interesting is, most vendors are still struggling just within their own product to try to deliver a usable interface, let alone a usable security feature. So we also think we've got a dual job in that area.
MR. ZUBELDIA: I have a question. I am concerned from what I am hearing about the C2. I understand that the C2 is the minimum level of security to having a reasonable protection against an intruder. Given that there will also be policies, do you believe that it will be required for all of the existing legacy health care systems to migrate to C2 before they can actually become capable of having a secure medical record? Or will the policies wrapped around existing legacy systems be sufficient, even though they are not a C2 level system?
DR. BAKER: Up until Bill Gates' day, all operating systems were C2. NVS is C2, DMS is C2, Unix is C2. Well, generic Unix except for auditing is C2. Then when the PCs came along, they threw away all the computer science books and started all over again.
Now with NT, they are coming back around. Legacy systems are C2. They have no problems, they have security authentication, access control and auditing.
DR. KORPMAN: And you can protect these differently by doing like we do, which is keeping the denominating information away from the legacy systems. The legacy systems aren't going to go away, because there is a lot of investment there. They will fade away over many years, and 20 years from now, someone will still be running the very last XYZ system that the three engineers that built it there with their canes, and put it together.
But you can stop sending it denominated information. So it may have endless lab results, but you don't know who they belong to. The sourcing system which then does everything else knows to whom they belong. So there are other ways of fixing this besides going back and tweaking on your MVS based systems and trying to make it B2 or whatever suits you.
DR. BAKER: By the way, I should mention that that opinion was my own and not that of my employer.
DR. LUMPKIN: We are running over time. I'll take one last comment.
PARTICIPANT: I want to preface, my opinion is not my employer's opinion necessarily. But I worked with health care for the past year, but like Dixie, I've worked 16 years in the DoD computer security world. I'm just using that as an example; it is a Unix system. They advertise their C2. There are other deck operating systems that are Unix flavor.
The problem is, if you just install the system as you get it out of the package and you begin using it, you don't realize, but you have to turn on a lot of flags indicators, to activate the C2 properties. They are almost C2, but they might be good enough for the health industry. I'm not sure you have to study each one.
I just had experience with certain ones, and certain versions. Each newer version gets better and better, each time they release it with C2 properties. But it is a big system administrator -- I hate to use the word headache, but it takes a lot of time, and you have to analyze what performance hit, which isn't that much you're going to do, to put audit trails on.
But you do have to turn it on. You have to take an action with these commercial systems. They don't just come completely workable, just like when you install the MT server. It is not only important to turn on flags, but the order in which you install things. If you have Oracle, Cybase, Infomix, we all use these database management systems to handle all these data. We found out in a test lab, the order in which you install these things depends on how often the MT server crashes. Now, if that isn't crazy.
So the system there is still settling down, too. But she is right, our C2 system -- they are better than a system without any, much better.
MR. ZUBELDIA: My question was more, can we achieve the same security level by putting the computer in a room with terminals without a network connection, without connecting to the Internet, and know that those legacy systems, as long as they are not connected to the Internet, they are workable? Because if we can achieve that, then I think it will be a much easier migration in health care than trying to say everybody has to use C2 as a minimum. There are PCs that in a single doctor's office are in a room that nobody else has access to. Maybe a $25 lock on the door is all they need. That sort of policy can have a real significant impact, if we tell all those doctors that run PCs that now they have to start running Unix with C2. I see a problem there.
DR. KORPMAN: But there aren't very many, in my observation, rooms that are locked that only one person has access to. They are mostly PCs flapping out in the breeze, which anybody can wander by and use, and they have no protection for starters. Even a legacy system that has a bunch of terminals that anybody can walk in and out of is just as compromised. I think Dixie is right: the weakest link is your level of security.
MR. ZUBELDIA: So we are going back to what was the recommendation that we made on security. I think we have to make sure that our policy is there, when the policies will limit the choice of technologies that you use. Maybe the technology is the C2, or maybe the technology is a separate room for it.
DR. BAKER: What I mentioned before, what I think should be C1, in fact, is separation of -- hardware separation of execution domains. PCs don't provide that, period. I don't care if you don't have authentication, if you don't have access control, if you don't have auditing, I don't even care. But to me, if you care at all about the integrity of data, and we should in health care, you shouldn't be using the PC.
Now, if on that PC you are doing something where the integrity of data and the integrity of applications doesn't matter, I don't care what you use. But if my health care data are on there, and if you are doing something to my record, then I want to make sure that you've got a dependable information system. You don't get that from PCs.
That is not the same as legacy systems, though, because legacy to me is VMS, NVS, Unix. Those are fine.
DR. LUMPKIN: Let me just throw out one of my prejudices, so you can understand this. We'll take it down to my favorite obstetrician-gynecologist, who runs a two-person office on the first floor of a building on Western Avenue in Chicago. It is my wife. If you say that she can't use her PCs, in our security standards we have a major problem here.
It is not just for her and her practice. I think it is a major problem throughout this country, because the health care system, while we are talking about maybe 58 million people who participate in HMOs, over 94 million are in some version of an IPA, and you have a lot of independent practitioners who are dealing with more fee scheduled -- managed fees rather than managed care.
Our recommendations have to work there as well as for the large networks. I think that is going to be our challenge.
DR. KORPMAN: But your wife should still -- her patients should still be entitled to a minimum level of authentication, a minimum level of auditability, a minimum level -- set the levels out, people will figure out the solutions, including cobbling up what you do to a PC to make it work better, or going to NT-5, which will fit it, or whatever the right solution is.
That is why you don't want to say you must use NT-5 and you must use Unix and this, that and the other thing. So maybe even the orange book is a start, but not a finish. But I certainly think we can lay out what a patient should be entitled to on a policy basis, that becomes technology, that says you should be entitled to at least the following things from your information system, because this is your life, it is not just your bank account.
MR. RIPPS: Just a little more dose of reality to that practice group, I suspect they probably don't even have the space to house a secure server, or if they did, they would prefer to --
DR. KORPMAN: NO, NT runs on the same thing as --
MR. RIPPS: Oh, but that is not the issue here. The issue is a secure server, physically secure.
DR. BAKER: You can put an NT on your desktop.
MR. RIPPS: That is not the issue. My point is that that is real world, and the solutions need to take into account not only the technology, but the policy and training issues.
DR. COHN: I do know that we are running out of time here. There is no question -- first of all, I wanted to thank the panelists. I think this has been a terribly interesting session.
However, I did think for the committee, -- and this is just the start of the discussion, and we need to figure out some way to get a greater knowledge of the applicability of this information into any recommendations that we may want to forward to the committee. I have come away being tantalized by the information, but not feeling like I have had enough information to really figure out how it really all fits in.
DR. LUMPKIN: We are going to spend tomorrow afternoon trying to figure this out. One of the things that we hope to get from these hearings is how comfortable we feel moving towards a decision, and also how uncomfortable we may be in moving towards a decision.
So I think it has been very useful and a very helpful discussion.
MR. BLAIR: Kathleen and I are mumbling to each other about, it would be really helpful if a number of the folks that were here today -- I don't know how many of them will be returning, a representative from AFET and maybe Dixie and Ralph and a few others that could help us reconcile some of the open issues. Could we inquire whether these folks will be here tomorrow?
DR. LUMPKIN: The meeting tomorrow is an open meeting. While the primary purpose will be for us as a committee to discuss, we will not have a hearing format. Certainly there will be opportunity for those in the group to help us try to seek clarity.
DR. COHN: This is tomorrow afternoon, right?
DR. LUMPKIN: Tomorrow afternoon. We will have some more panels in the morning, and then in the afternoon we will try to see if we can resolve this.
DR. FRAWLEY: But if people can't stay for tomorrow afternoon, we do have a full committee meeting on September 8 and 9. So maybe if we come away with questions tomorrow afternoon, we could forward them, and ask for people --
DR. KORPMAN: I can't be here tomorrow afternoon, but we have been beating on this forever. The 8th and 9th works okay, actually. We'd be happy to come back and offer whatever we have to offer. I think by tomorrow afternoon, you're going to be resolving internal confusion factors. It will be a month before you are ready to hear other questions that we should really have talked about. That would be my guess.
DR. LUMPKIN: Now, the 8th and 9th is a full NCVHS committee, so watch our web page for the agenda, and you'll be able to see how much time we will be devoting to security.
DR. COHN: I was actually also going to comment that one of the options we also have is to identify additional questions, in letter form, that we can send to you to ask you to respond to, which might also help.
DR. LUMPKIN: And feel free to send us unsolicited -- based upon this comment and what you have heard, if you think there is an area that we would benefit from in drawing additional materials, feel free to send that to us.
DR. BAKER: I plan to be here tomorrow morning if you do want to continue. I can certainly do that tomorrow afternoon.
DR. LUMPKIN: Thank you. Then we will reconvene tomorrow at 8:30. Thank you.
(The meeting was adjourned at 6:42 p.m., to reconvene Wednesday, August 5, 1997 at 8:30 a.m.)