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: Good morning. We are going into our second day. My name is John Lumpkin and I get the honor of chairing this work group this morning.
I would like to welcome everyone to the second day of hearings in regards to security issues. I would like to review the agenda for today and then we will go around and do introductions and go into the first panel.
I think we are broadcasting on the Internet today. So, to all of you out there in Internet Land, welcome.
What we will be doing today is that we will be having two panels this morning, breaking for lunch and then the work group will begin to discuss what we have heard. This will begin a day and a half meeting of the work groups. These are, of course, open meetings and as we discussed yesterday, we would encourage those of you who interest to sit and listen and assuming that we have time and we expect to, we also will give you an opportunity to participate somewhat in discussion.
I will just warn you that, however, I will give priority to members of the committee in this discussion process.
Having introduced myself, I think we will go around the table and start off with Bob.
MR. GELLMAN: My name is Bob Gellman. I am a privacy and information policy consultant in Washington and a member of the committee.
MR. VAN AMBURG: George Van Amburg, Michigan Public Health Institute and I am a health care researcher and member of the committee.
MS. BALL: Judy Ball from the Office of the Assistant Secretary for Planning and Evaluation, HHS. And I am staff.
MR. BLAIR: Jeff Blair, IBM Healthcare Solutions and ANSI Healthcare Informatics Standards Board and I am a member of the committee.
MS. FRAWLEY: Kathleen Frawley, the American Health Information Management Association, member of the committee.
DR. BRAITHWAITE: Bill Braithwaite from the Office of the Assistant Secretary for Planning and Evaluation of HHS and I am staff to the subcommittee.
MS. GREENBERG: Marjorie Greenberg, the National Center for Health Statistics and executive secretary to the committee.
DR. COHN: Simon Cohn. I am a physician the CIS coordinator for Kaiser Permanente and a member of the committee.
DR. MOR: I am Vince Mor. I am chairman of the Department of Community Health at Brown University and a member of the committee.
MS. COLTIN: I am Kathy Coltin. I am director of clinical measurement systems at Harvard Pilgrim Health Care in Boston and a member of the committee.
DR. LUMPKIN: We will take the panel last and start with the audience. Laura, if you would start.
[Further introductions off microphone.]
MR. BREED: My name is Charles Breed from PGP, Pretty Good Privacy, Incorporated.
MR. MEYER: Chuck Meyer, HBO and Company.
MR. MC CORD: Jim McCord, Oacis Healthcare Systems.
MR. DVORAK: Carl Dvorak, Epic Systems.
MR. BECHTEL: Ron Bechtel, HDX.
DR. LUMPKIN: We will start out with Mr. Breed.
MR. BREED: Good morning. My name is Charles Breed. As I said, I work for Phil Zimmerman's company, Pretty Good Privacy. My background in the security field has been pretty extensive over 14 years. I worked for Hewlett-Packard, Citgo(?) Systems. I was responsible for their security products and then most recently I am on my way to Munich to host the working group for the IATF for an open PGP standard.
What I want to talk about this morning is just briefly the history of PGP and then the underlying technology and how it applies to the health care industry. Before I do that, I want to mention that I dropped off some posters for the panel today. These are hot off the press. They are about two or three months worth of work and just to show the -- those who don't get them, it just has all the cryptographic technology that is used today an dhow it is applied in different applications.
So, it talks about past(?) rays attacks, different key lengths, different protocols, certificates, trust models, different standards under the IPS(?) and NIST. So, if anybody wants one of these, just give me your business card and I will send some to you.
So, this is what is rolled up on your table there.
The history of PGP is well-known to a lot of folks. Phil Zimmerman first shipped the product in 1991. It has been considered one of the strongest cryptographic algorithm packages out there. Since the company has been incorporated about a year and a half, we have focused on making it more commercially viable, ease of use, and have added a lot of applicabilities for other transfer modes for EDI and other uses in electronic commerce.
The big benefits of the PGP technology is that it can treat data that is stored, as well as data in motion and that is a typical storing forward transactions, with records and statistics. E-mail, spreadsheets can be handled with PGP where they are encrypted. Prior to transmission, they are encrypted with extremely strong technology.
In my testimony, you will read that one of the chief staffs on the National Security Agency said that if all the computers in the world, about 260 million of them were put to work on one single PGP encrypted message, it would take an estimated 12 times the age of the universe to crack that one message.
We use open standards, and when I say "standards," it is probably one of the most overused terms. There are de facto standards. There are national standards, state, federal, local and international. We use the best algorithms that are available and those are determined by open peer review from the scholastic -- the colleges and universities, as well as the commercial application.
But PGP can handle this data that is either stored or in real time and this is very important for transmitting data that you have no idea where it is destined or how it is going to be used in the future, unlike some other technologies, which just secure a channel. A channel would allow -- prevent against attackers, such as men and mental attackers.
So, if I am sending a message between two points, technologies such as SSL, secure sockets layer, will prevent men in the mill(?) attacks, but when that data comes out the pipe at either end, it is then in the clear and attacks can certainly happen there. So, PGP protects this data while it is at rest or while it is in motion.
The next real benefit is the certificate structure and this is something that is very subtle, but extremely important and that is PGP allows you to have multiple signature IDs or identifications, as well as multiple signatures or assertions upon that. For example, if you have a physician that has different authentication and access rights, you can have multiple signatures from insurance patients, other physicians that allow different levels of authority, what they can do.
So, within this one certificate of an individual, there can be assertions made from their employer, their hospital, their physicians, their insurance companies, as to what they were able to get access to and there is auditing and tracking to do that.
With other technologies, such as the ANSI X509 certificate model, it is very static in nature, where there is only a single assertion and a single identifier of that individual. With the PGP model, you can make assertions in a dynamic mode. Instead of one static set of IDs, you can add and subtract different signatures as that certificate travels or needs to change over time.
The other big benefits of using PGP is, again, the strong cryptography. We use what is best out there in the market. We stay ahead of the attackers and crackers that are out there by using the best algorithms. The PGP library uses a whole variety of technologies, not just one, such as our public key algorithms that we use are both RSA and the Diffy(?) Helman public key algorithms. The Diffy Helman allows you to have a different key pair for signing versus encrypting, so individuals can keep a separate key pair for signing as well as encrypting.
On the symmetric algorithms, we use Cast and Idea and DES and triple DES. We have algorithms that have been approved by NIST, both digital signature standard algorithm, DSS, as well as -- and soon to be triple DES.
The other interesting things about using the PGP technology is that it is very openly available. There are over 80 companies worldwide shipping PGP-based technologies. It is used internationally at great lengths. It is widely available because the source code is published and freely available. This is a very unique aspect of PGP.
I recently visited the folks up in Redmond, Washington of Microsoft and presented them with 6,000 pages of printed source code and they thought I was crazy because Microsoft would never release the -- you know, the secret ingredients of their secret sauce up there; where in the security realm it is very different. You need to publish source code because it has to be open for peer review to see if there is any back doors or any areas that can be attacked.
The best way to ensure that you have a strong algorithm is to show it to everyone and let them see if it can be broken or cracked or whatever. So, we openly publish this.
The peer reviews that we have gotten on the new 5.0 library have been extremely well-received and that is the products that are based on today they are shipping. Also, the widespread use of PGP is a big advantage. It is used in electronic commerce. It is used in EDI. It is used in a lot of health industries. It is used in aerospace at great length and it is used on a personal basis.
The technology is very easy to use from an end user or patients or even a physician's point of view and it is also easy to use from the administrative point of view, where you can track and audit and set up keys from a central database and also set policies. You can set policies that then get distributed down to the individual level.
The other hot topic nowadays is key recovery and key escrow. With the PGP technology and the public key, you can enforce what we call message recovery, which is Encrypt 2 and you would encrypt to the organization that wants to be able to recover copies of the message if necessary as opposed to escrowing keys because the main point is you are trying to get at the message or the data. You are not trying to get at the individual's key.
So, by forcing encryption to a main recipient corporation, insurance company or hospital, they are always guaranteed that they can get access to the data that is sent.
So, those are the main points of the PGP technology. It works in Storenbord(?), as well, you know, data in rest, data in motion, strong cryptography, openly available and extremely widely used.
That is the main points that I wanted to get across and please take time to read my testimony and if you ever come across terms that you are not sure of, hopefully, the cryptography poster that we are handing out helps you out.
Thanks.
DR. LUMPKIN: Thank you.
MR. MEYER: Dr. Lumpkin, members of the subcommittee, I appreciate this opportunity to address the issues surrounding security of health care information as defined by Public Law 104-191. I am Chuck Meyer. I represent HBO & Company in the standards development community and on several policy boards within the industry. Although my focus has not been on security, my involvement with X12, HL7, ASTM and the ANSI Healthcare Informatics Standards Board has certainly given me some exposure. My most recent experience is as a member of the Association for Electronic Health Care Transactions work group on security, which delivered its recommendations to the Secretary last week.
HBO & Company represents a broad spectrum of application systems covering the full gambit of products inherent in the health care enterprise. Surprisingly there is little dissention with this diverse group of products on the issue of security of health care information. Each walks a fine line balanced between respect for the patient's privacy and the need to provide meaningful data to the caregiver and clinician.
Given that we develop systems, our focus is generally introverted and fixed on access to the discrete data representing the patient record as stored and maintained by our systems. We are confident that reliable applications are readily available to protect messages being exchanged between the various participants in the enterprise. Even though the public has been aroused by reports of security violations on the Internet, I am not aware of any reports of health care information being intercepted. Admittedly, there is relatively little activity involving health care data on the Internet. In any case, we are of the firm opinion that data at rest faces a significantly higher risk of disclosure or subversion than does data in transit.
Security of data at rest is multifaceted since such data is a composite of electronic and paper forms. While we are focused on the electronic form, the physical security of the reams of paper forms that make up the patient's medical record must not be overlooked. The need for significant improvements in the procedures for the storage, maintenance and distribution of paper medical records was pointed out most recently in the NRC publication "For the Record: Protecting Electronic Health Information."
Their assessment of risk clearly demonstrated the need to address physical security of the medical record as the first priority. We are supportive of the process of risk assessment and the subsequent development of suitable responses to minimize, if not eliminate, that risk. The NRC publication documents that process and it is also used in the European pre-standard draft "Medical Informatics: Security Categorization and Protection of Healthcare Information Systems. The members of the European Union are strong advocates of patient privacy and the ensuing security mechanisms that ensure it. ISO and European standards deserve consideration for inclusion in the security standards adopted by the Secretary.
It is imperative that the current effort underway to improve care while defining cost effective and efficient treatment plans is supported. This cannot be accomplished without access to the clinical data and outcomes specific to a given diagnosis. The plethora of public health initiatives would be less than effective if not supported by valid statistics culled from health care data.
Yet the public is extremely leery of any access to their information regardless of the benefit. Many are of the opinion that access is uncontrolled and unlimited and, subsequently, support extremely stringent controls. Admittedly, there is a need to identify the patient in the case of communicable or sexually transmitted diseases. However, for the most part, collection of information to support research does not require the patient's identity. The public's perception is contrary to reality. The resolution would appear to be an extensive educational campaign to make the public aware of the checks in place to protect the privacy of their data while supporting ongoing research. Concurrently, the attributes of patient data that would constitute an individual's identity must be defined and clarified. Protecting the information is fairly straightforward once it is identified.
That protection takes the form of access control. Access to health care data has broader concerns than just research. Access controls are as important during the episode of care as after. During treatment, there is no question that the patient has been identified. However, what clinical data is available under what circumstances is essential to privacy.
The dichotomy faced by vendors is providing access controls that protect the patient but don't hinder the caregiver. We are supportive of the approach that defines stakeholder roles and assigns an access level to each role. An orderly or nurse's assistant may only be able to determine the patient's location and the service that they are scheduled to provide. At the other end of the spectrum, the attending or primary care physician would have full access to the patient's medical records.
It should fall to the standards development organizations, in a cooperative effort, to define these roles and the appropriate level or levels of access. Access would, of necessity, need to be defined to a level of granularity that would support the assignment of specific data elements to the access level. IN essence, an access model would be constructed and interact with a data model and role model; thus, supporting the mapping of allowable data to a specific role through authorized access.
Conceptually, the access model could be mapped over a vendor's database in a close corollary to the standard. ASTM has prepared a draft document addressing the concept of an access matrix. Their guidelines could provide the basis for evolving this process.
HBOC is also supportive of the concept of establishing an initial minimal set of security requirements that could be quickly achieved as espoused by Michael Fitzmaurice. "Setting the bar low" is his term.
Once the industry as a whole has attained a comfort level with security, the regulations could begin the process of adding rigor through ever more stringent requirements and granular access levels. A progressive approach to security would be much more easily accepted and supported by the vendor community in general and HBOC specifically.
Note that all of our discussions have revolved around guidelines, procedures and processes. As a vendor an developer of software, we are adamantly opposed to the definition of a technology-based standard. This would tend to stifle innovation and development. Further, such technology could literally be obsolete by the time a regulation was published. It is imperative that the regulations address the "what and why" of security, allowing the "how" to become an implementation issue.
As I stated earlier, our focus tends to be drawn inward towards our database. We must, however, at least be aware of the basic tenets of transmission security. A crucial issue from the vendor's perspective is the scope of the regulation. Given that certain data exists in the format of one of the nine standard transaction sets, at what point does that data need to be secured?
This is actually a media question, which must be resolved by the regulations. I do not believe that there is anyone in my organization or in the industry as a whole who would not support a requirement for secure transmission over the Internet. By the same token, how appropriate is that level of security to transmission over a private network? Taking it to the extreme, would that level of security be necessary for transactions on a diskette or magnetic tape, as has been suggested by members of the HIPAA infrastructure team in the past?
A realistic assessment of the security risk represented by the various media used to transport the standard transaction set will be essential to the preparation of a viable security matrix. Perhaps, within the concept of minimal requirements, only transmissions over the Internet require full encryption. More likely, there will be specific data elements that require protection during transmission over more secure media than the Internet.
A clear definition of use will eliminate a significant amount of thrashing on both sides of the connection. Another facet of the media question regards backup media and equipment repair. The guidelines must establish clear procedures for the storage and disposition of backup media. The same considerations must be extended to system media that might contain sensitive data. Such information must be cleared from the hard drive prior to being given to a technician for repair.
In summary, HBO & Company is highly concerned that data at rest be given due consideration under the legislation. The standards should take the form of guidelines and procedures defining the "what and "why" of security. Access control is essential to the implementation of security standards. Access control should be defined by a cooperative effort of the standards development organizations. Finally, the standards must not be technology specific.
Thank you for this opportunity to address the committee. I will be available to answer questions at your convenience.
DR. LUMPKIN: Mr. McCord.
MR. MC CORD: I am Jim McCord, the CEO of Oacis. I am happy to be here today representing my company and our piece of the industry. I should say that as the CEO, I am not a security expert. I am here because my staff unanimously agreed that my absence from the company wouldn't hurt anything and I happened to be in Washington anyway.
Oacis supplies very large-scale clinical information systems, which are sometimes called automated medical records and are built around a comprehensive database called a clinical data repository. We do business both domestically and internationally. So, we face the security issues that obtain in all of these markets.
We understand that the legislation focuses primarily on claims related data and not necessarily the clinical information that we provide, but even claims data contains clinical content in the form of diagnostic codes and these are at least as sensitive to individual confidentiality concerns as of the VDI(?) transactions. So, I am going to focus mostly on the clinical content issues that address -- the issues that we have to deal with in the clinical information systems business.
It is hard to imagine a computer system that contains more sensitive information than an Oacis clinical data repository. A typical repository includes micro-level clinical data fed from dozens or hundreds of sources automated and manual. Some of our clients have repositories that include hundreds of thousands of patients covering multiple years, thousands of data elements and tens and even hundreds of gigabytes of data. These are getting to be very large databases.
Although each provider can make different decisions on exactly what is in the repository and who can access it for what purpose, there is no doubt that most of these repositories are much more complete than a paper chart and far more accessible.
Because of the sensitivity, our clients and their patients are increasingly concerned about confidentiality and security of clinical data. As more organizations put advanced clinical systems into production, they find it a challenge to balance the needs for confidentiality with quick and simple, adequate caregiver access to the patient information. That is going to be a common theme among all the vendors here and providers. Every time you put an additional security constraint on the system, you make it harder to use. As has been said, the most secure library in the world is the one where all the books are on the shelf and the doors are locked. That is not a very useful library.
The balancing act is a significant issue in the acceptance of automated systems. If physicians have to wait 45 seconds while the system authenticates and audits a piece of clinical information, it says they will most likely never use the system. I can assure you they will never use the system.
Similarly, if security features are too stringent, a caregiver either may be denied access to a piece of critical data, with consequent potential for compromising patient care or users will find ways around the restrictions by sharing access codes or badges that render all of the technical precautions useless.
I, and many other vendors, have seen our systems in use in hospitals where passwords are stuck on post-it notes on the terminals. Furthermore, we find that every health care organization we serve has a different set of standards for privacy issues. These are often dependent on their own policies. They are usually conditioned by external rules.
Our major concern -- this is my main message -- is not so much the lack of standards but rather the lack of uniform policies. The current patchwork of state legislation on patient health care privacy in an electronic world is very complex to navigate and difficult to solve technically.
The way we have attacked this is to build a security system that is sort of infinitely flexible and configurable so that it can be configured by each plant, based on their own local policy. For example, security can be imposed down to the individual data element by a person, by a patient. This works but it is very complicated and takes a long time and a lot of money to implement.
We believe that uniform policies would have reduced the cost of developing clinical information systems and allow us to provide secure solutions that are much closer to our clients' needs, while still maintaining the ability to customize them where you have to.
Our recommendation is that before security standards are selected for clinical data, there should be a national confidentiality policy with a global view and this should be put into legislation to provide a framework so these standards can be set and met. Obviously, this policy has to be framed in the U.S. context, but it should look to policies established by other countries so that software and systems vendors can compete more effectively in the international marketplace. We certainly see different policies in our European and Asian implementations than we do here.
For example, the policy be crafted with knowledge of the European Union's 1995 Directive on Data Protection. European countries seem generally ahead of the U.S. in establishing policies for security of clinical data and there is much we can learn there.
A national policy must also be capable of being implemented at a reasonable cost so that it doesn't further increase health care costs or delay the benefit that these systems can provide. For example, policy should not make a blanket requirement, such as all events or access will be audited. If taken to its extreme, such requirements would create an audit trail databases that are much larger than the repository itself and these are already pushing current technologies.
We have some clients who have simply set up the system so that every access of the unit record is recorded, not which data elements were accessed, and then patients are entitled to see that log. So, patients are allowed to see who was looking at their record. And that has turned out to be a very effective security policy. You have to make it widely known around the institution that that is available, but those are the kind of things you can do that don't require a lot of technical lab work.
Policy must also encompass all segments of the health care continuum, including all these people that are mentioned in my testimony; certainly, the patient, the clinician and other people have to use the data. And it is also important that the policy take into account different uses of the data, both direct care and then historical analysis for diagnosis, clinical research, where you don't necessarily need to identify the patient and public health research.
Finally, and most effectively, the policy must not impede a clinician's ability to render quick, efficient quality health care since that is what these systems are being built for in the first place. And that comes back to the issue of additional security often makes the systems harder to use.
We are concerned that appropriate standards be selected for implementation of a national policy. The lack of good standards has been and continues to be a major impediment to the large scale adoption of automated medical record systems. That isn't only security standards. It has to do with issues like vocabulary and many other things that get in the way of effective automated medical record.
In the current federal legislation, we encourage the use of ANSI X12 standards for claims processing, but in the broader context of the medical record contents, such standards are not as relevant.
For security in the electronic medical record, two checklist items that we see very often in the RFPs that we respond to are the CPRI Security Features for Computer-Based Patient Record Systems and occasionally although not as often, the Institute of Medicine's so-called gold standard. Although neither document has been approved by an ANSI certified standards development organization, there is still reasonable starting points, given the lack of any official standards.
Although we have never received any client inquiries about ASTM E1869, the standard guide for confidentiality, we feel the standard may also be a good starting point for defining the confidentiality of the electronic medical record.
For transfer of information, we recommend the HL7 standard, which has wide acceptance in the health care industry. Almost all vendors support HL7 interfaces. We do a lot of interfacing and much prefer to see that as an interface.
We feel that HL7 has among the broadest representation of support from both the provider community and the vendor community and that will help make it easier to implement a standard quickly.
I would like to recommend to the subcommittee that certain areas be taken into account during the process of proposing health care security standards, including the need for common vocabulary of terminology, a clear demarcation between communications and content standards, reasonable selection and implementation of auditing requirements and a clear definition of non-identifiable health data.
Finally, I would like to encourage the committee and its subcommittee to work closely with the national and international standards development organizations, as well as with all the stakeholders. We have to get buy-in from the people who are going to use these systems, as well as those who develop them; otherwise, they won't be implemented or people will find ways to get around them.
Thank you very much.
DR. LUMPKIN: Mr. Dvorak.
MR. DVORAK: Good morning. My name is Carl Dvorak, vice president and head of research development for Epic Systems in Madison, Wisconsin.
Thank you for affording me the opportunity to present our views on this important topic today.
By way of background, Epic develops software for large integrated health care delivery systems, managed care organizations, medical groups and hospitals. Our systems include computerized patient records, managed care, appointment scheduling and patient accounting.
Epic has been developing systems since 1979 and our computerized patient record system, in particular, has approximately 13,000 licensed users and one of the single largest CPR sites in the nation, almost 800 providers with several thousand trained users processing last year over 2.5 million patient encounters and over 5 million computerized orders on line.
Epic believes that a medical record system should protect the confidentiality and privacy of patient information. The computerized system can in many cases provide higher levels of security than possible with conventional paper records. Audit trails can show how and when records are accessed and the types of information accessed. The computer can deny inappropriate access, et cetera.
Through improper management, however, computerized systems can provide a fast and efficient means to compromise the privacy of hundreds of thousands of patients in a single incident, efficiency not possible with traditional paper records. We, as well as any other vendor health care organization, have at our disposal an excellent set of policies and implementation details to choose from in order to provide excellent security and privacy.
Most responsible vendors already adhere closely to the guidelines created, summarized and published by such groups as CPRI, NRC, AHEMA(?) and others. We recommend the committee utilize this existing work to its fullest.
Internal and external security auditors have reviewed our systems from both the features and use perspective at several large organizations over the past several years. The most common findings from these audits were procedural in nature, including issues like retiring of user accounts for persons no longer employed.
How does Epic help clients identify security risks, threats and exposures? With the introduction of medical information systems, especially computerized patient records, Epic recommends that health care organizations define the role of an application security administrator.
This person's job would be to manage all the security aspects of these applications with the defined support commitment from technical, legal and user communities. The security administrator should have a high level of confidence in the information systems area and in the medical field.
One of the most significant problems that we find when installing medical systems is that customers struggle to clearly understand what kind of information they should protect and from whom. We generally work in a consultative manner with our customers to help them develop and implement security policies and procedures.
Although most misuse of computerized medical data is the internal access, both internal and external incidents can be equally damaging and require planning to avoid. We generally categorize security needs in the following areas: first, user identification.
I will skip parts of the testimony that are written in essence of time here.
We recommend standard password procedures and one thing to point out, a password that is too complex to remember will often be written on a post-it note and attached to a clinician's monitor or, worse yet, forgotten at a time when it is really needed. I don't know how many of us have secured a word document and forgotten the password, but it is not a pretty sight.
Other emerging technologies may be helpful in providing access to medical data. These include biometric devices, thumb print, voice print and one time password generators. It is important, however, that access controls not encumber the clinician to the extent that to avoid inconvenience of reidentifying themselves, they leave devices signed on to the system in an insecure state.
Even with session timeouts, unattended devices represent the most common means for inappropriate access to any system. In terms of encumbering physicians, one of our customers kindly pointed out to me how much money it costs for every one second delay a computer system generates in practice and it was significant when you added up over a thousand clinicians for a year.
Category 2, user access to information, the development of security classifications database is critical to implementation of an acceptable security system. These classifications represent a mesh between job function and user access permissions.
Users should be assigned a security classification for each job function or unique role they play in the health care delivery process. Every health care organization is unique and, therefore, systems should provide flexibility and a setup and definition of user security classifications.
Also to remember in a paper world run by people, exceptions can be explained, understood and acted, at least most of the time. In a computerized world, provisions need to be employed that allow users to manage the exceptions that can arise in critical patient care areas.
Appropriate security overrides are needed so that in cases where medical necessity dictates, users can override the often rigid security structures in a CPR. Most often these mechanisms employ a dual user sign-off, a statement of justification for the access and a supervisory notification system.
Category 3, protection of sensitive patient information. Each organization needs to create and clearly communicate a common definition of sensitive information. This varies from state to state and even between facilities within a state. This can be a complex area due to potential inference issues when studying medical data.
For example, a pattern of pneumonia prophylaxis may indicate HIV. Based on a pattern, users can suspect things that they don't necessarily have data to justify. This is especially obvious when you look at claims data. There has been a lot of discussion lately about is claims data medical data. I would suggest that claims data leaves a fingerprint behind of what the treatment plan is and whenever you know what the treatment plan is, it is fairly reasonable to infer what the problems were in the first place.
A medical data system should provide security that prevents reviewing of orders and encounters that have been marked as sensitive by anyone other than the providers responsible for those orders or encounters or their supervisors or designated proxies. The ability to secure tests and encounters should be available on demand for use in cases where patients request that information be held confidential and not be available for use as part of the patient's general medical record.
Category 4, audit trails. Careful monitoring of user access to information should be implemented. Periodic reviews of access to information may be used to identify inappropriate access patterns. A CPR or any medical system should provide a comprehensive audit trail of all user accesses to modules for each patient. This audit trail should include user ID, date and instant of access, module accessed and operation performed.
This deferred method of user monitoring can play an important role in managing access to information. Clearly, real time checks should and do avoid the most common breaches of security, but there are situations where it is not clear whether a provider has legitimate need to access the information or not.
This is especially common in large facilities where providers cover for each other regularly and rotating staff provides services to patients. Audit trails not only provide a deterrent to misuse of data, they also provide an important mechanism to allow organizations to discover new and interesting techniques for the misuse of data.
Electronic signatures and co-signatures, Category 5. In many situations, especially in fast-paced clinical environments, it is necessary to revalidate the user who is placing an order or updating a chart to ensure that an unauthorized party is not using the person's unattended work station. This revalidation verifies that the original user is the person placing the order by requesting his or her user ID and password be restated.
Attempting to place inappropriate orders for controlled substances can be one of the more common misuses of clinical systems.
Physical security. Organizations need to consider appropriate physical security measures, including procedures and policies for printers, work stations, remote networks and modem access. Existing systems provide various levels of protection against unauthorized log-ins via dial-ups, remote access. Dial-back modems and password protected remote access services are common front ends at providing mode access security for medical information systems.
One area that we discovered in doing this for the last several years, printers should be thought of as photocopiers in the medical records area. Access to printers should be controlled and output distribution should be regulated and managed. We find a tremendous amount of information is printed out and basically left sitting because people didn't have time to go to the printer to get it or didn't understand the importance of disposing of it properly when done. Usually, it winds up in an unprotected wastebasket.
Standard procedures should be followed to guarantee integrity and availability of computer systems, including backups, highly available configurations and disaster recovery planning.
Category 7, analytical reporting access management. As stated before, a major difference between a computerized environment and a paper environment is the accessibility to the large amounts of data. This access provides one of the most significant benefits of automating patient records, at the same time it presents the greatest potential danger to patient privacy.
Malicious use of large volumes of data by an organization is an obvious misuse of data and should be punishable by law. Data for use in analysis should be scrubbed before allowing access. The scrubbing techniques may include encoding patient identifiers with a special report key. Users would then be able to study the reports, but not obtain any specific patient data without obtaining report key.
Access to the report keys could be controlled administratively by internal review boards. It is important to realize that there can be security issues with the use of aggregate data, especially when trying to prevent access to information about any particular patient. A user can take data elements that are in general considered available for anonymous analysis and combine them with other information the user does possess to synthesize a reasonably accurate assumption.
For example, if you know a friend of a certain age, gender, ethnicity and physical dimensions was seen in a certain facility by a provider at about a certain time, you may be able to obtain detailed information for that encounter, even if the encounter has been stripped of all patient specific information, including identifying numbers and things like that.
Category 8, Internet access to information. Internet plays a key role in the future sharing of health care patient data. Internet-based approaches will likely become more popular than point-to-point interface base sharing of data through traditional means, such as HL7. Information will not only be shared with other health care providers but also with patients themselves.
This provides a unique opportunity for improved service and outcomes for patients who begin to participate in their own care via Internet-enabled CPRs. The Internet security area is experiencing vast investments in technology to exploit the potential for electronic commerce. The array of technology developed for general Internet use will likely allow for the use of medical data to be safely extended across the Internet.
Category 9, exchanging data with third parties. Third parties, such as electronic commerce clearinghouses and reference laboratories or other testing agencies have traditionally provided adequate protection for data through the use of secured internal systems and private networks. For any potential transmission over public networks or the Internet, we recommend simple and effective security measures, such as PGP file level encryption be used.
The largest potential for compromising data when dealing with a third party is typically not the transmission of the data to the third party, but rather how well that third party manages their responsibility for that data once they have it.
I have identified some potential roles for government involvement. In light of the recent legislation and time frame specified, the government could play many key roles in defining security guidelines for health care. We suggest consideration be given to the following:
No. 1, support basic education and awareness of security needs and approaches available to health care organizations.
No. 2, sponsor the development of security standards and guidelines through existing standards organizations. Through recommendations submitted by groups such as CPRI, AHEMA and NRC provide excellent frameworks for health care data security. We see no need to recreate their work.
No. 3, provide legislation and enforcement guidelines for misuse of health care data within and across organizations. I saw this morning on CNN, they just enacted the income tax browsing penalties of one year imprisonment and $100,000 fine for anybody caught browsing a tax return they are not entitled to look at.
Be careful not to mandate any particular implementation of security measures, but rather address the concepts and the level of protection to be provided. This will be key to providing a competitive marketplace, which will help to reduce overall costs.
Probably most importantly, No. 5, work to encourage a common set of security guidelines and definition across all states. Variations by state increased the cost of implementing automated systems of any kind. Focus on the ownership of medical data and the process for transferring and sharing ownership of that data across and within organizations.
Six, provide recommendations suitable for large outpatient organizations not strictly conceived through a hospital paradigm.
Seven, provide a national standard for the definition of appropriate security measures for medical data. Our customers find that in the absence of a definition, they spend a significant amount of time and energy developing one internally. Our experience in general has been that security is a continuum and our customers try to balance cost with an acceptable level of risk.
And, eight, create a third party auditing or certification process similar to ISO 9000 or GCHL(?), where organizations can receive a stamp of approval from an independent body.
In summary, we think it is important to remember that a simple security standard that is theoretically less secure, but widely implemented, will likely protect more patients than a complex standard that is theoretically more secure but not widely implemented. We hope that simplicity of implementation and management is given a high priority as recommendations are presented.
Epic appreciates the opportunity to have participated in this process and extends an invitation for further discussions in this area as the committee may feel appropriate.
Thank you.
MR. BECHTEL: Mr. Chairman and members of the committee, I am Don Bechtel, an advisory analyst responsible for strategic and technical planning at HDX. I also co-chair the ANSI X12 Eligibility Work Group within the Insurance Subcommittee.
On behalf of HDX and SMS, HDX's parent company, I would like to thank you for the opportunity to testify before you today on this very important subject.
I have brought with me 75 copies of my written testimony, which is detailed and addresses a number of the issues that were specific to your questions. My verbal comments, however, will focus on a few key aspects of this material, which we have experienced some hard won knowledge.
Before I begin my comments, I would like to introduce my company to those of you who do not know us. More than 28 years, SMS has focused exclusively on serving the information technology needs of participants in the health industry. We have made it our business to develop, deliver and support the information solutions that help our customers meet their varied and changing business needs.
Our customers include a wide range of health organizations, such as integrated health networks, multi-entity hospital organizations or health organizations, community health information networks, physician groups, government health facilities, managed care organizations, health benefit plan administrators and payers.
Based on customer need, our solutions can include any combination of clinical, financial and administrative applications, enabling technologies and integration and support services. SMS established HDX, the company I work for in 1991, as a separate subsidiary to provide EDI clearinghouse services to the health care providers and payers.
This was in direct response to customers' requests to help them with issues stemming from managed care initiatives. Transactions that we process today primarily deal with health care-related administrative and financial issues and include eligibility claims and remittance advice.
HDX's eligibility service is designed to be integrated with a provider's information system so that the eligibility inquiry transactions can be generated as a byproduct of normal business processes, for example, admission, registration, scheduling functions. And the eligibility response transactions can automatically update patient account information.
HDX is currently in joint development with several payers to implement an ANSI X12 278 transaction for the purpose of authorizations, referrals and notifications. Like our eligibility service, this service will operate on line with real time processing that occurs as a byproduct of existing application functions, like order entry.
I mention these two services to illustrate the need for EDI transactions to be integrated within the applications they serve. EDI transactions are designed to be used by people. They are not used by business application or -- I am sorry -- EDI transactions are designed to be used by people. They are designed to be used by the business applications.
Users of these applications are granted access to the associated patient information because it is their job to work with this data. We must be careful not to impose additional security hurdles to the users of EDI when authorization and authentication have already been granted to them by the application they are using, for which EDI transactions are supplying or getting information.
To do so would be redundant and would make the integration of EDI less beneficial. The benefits of EDI are most realized when human interactions are reduced and system-to-system interfaces are seamless. Together with our customers, HDX has proven this with our eligibility service. We can show our customers are saving time, money, improving information quality, reducing costs and have reduced staffing requirements.
A concern is that we don't encumber these transactions with independent security requirements, which remove them from behaving as interactions within applications. We are also concerned that unnecessary processing or overhead is not added to meet extraordinary security measures making response times unworkable for real time interactive processing.
There are many secure network implementations today, which can safely and securely process the transport of EDI transactions. Recommendations to the Department of Health and Human Services should not limit the type of implementations used if they can meet stated security criteria, using an acceptable security method.
The problem that we have today is these standards and criteria are not defined. Consequently, there is much confusion about what should be done to properly and reasonably handle individually identifiable information at each point in the process. This has resulted in conflicting state statutes, inconsistent regulations by federal and state departments and unclear jurisdictional interpretations. It has become very difficult for responsible organizations to determine what the proper course of action should be for a given set of circumstances.
Need for data security standards around which the health industry can rally has never been greater. So, what can we do?
First, a number of basic security principles or guidelines should be defined for policies and procedures related to the personnel that access the health-related information: detecting data at rest in computer files, electronic media and paper; accepted technical practices that restrict and control access to applications of data; acceptable criteria for network communication technologies to authenticate and protect confidentiality of data while it travels the network, and recoverability.
The public and private sectors in health care should work together in partnership to maximize their strengths. As we have learned in the X12 standards development process, transactions we build together by consensus are much stronger than those we build in isolation. Meeting the needs of all organizations is much more likely to occur in such an environment. We believe there should be a model security strategy for each transaction, where some transactions may require more security than others, due to the sensitivity of the data they carry or different security measures, due to the processing environment in which they operate, for example, batch versus real time.
Further, we believe that there should be a security model for the various network implementations, which should describe acceptable security standards and practices when using the Internet versus the Internet. It should also differentiate private lease networks from open networks and address the security requirements of each.
The inherent qualities of one network infrastructure versus another, such as SNA, X12, TCBIP, should be recognized where these different communication protocols will also use different tools and standards to accomplish the same goals. The same criteria should be established for each implementation but different standards may be needed, based on the technology.
It would be important to allow the business needs of each organization to dictate the implementation -- to dictate what implementation is appropriate. To manage this, a set of operational criteria must be defined to determine when an implementation is valid and certifiable. It is our hope that a standards development organization will be identified to establish by consensus these criteria for security standards, which must be met by the various networking infrastructures.
The selected organization must work in cooperation with the other standard setting organizations responsible for standards used, for data transactions, security algorithms and network protocols. Selected authorization organizations should work as an industry consortium such that the benefits of each security standard could be balanced with the cost of implementation.
It is important to keep the cost of our products and services fair and reasonable as the cost of purchasing an operating information system is ultimately recovered from the fees our customers charge their customers.
Another concern related to cost is performance. As vendors, we must maintain operational price performance ratios where degrading performance to satisfy unnecessary or redundant security practices will have a detrimental effect on the systems value to the customers.
Performance cost of some security practices will significantly increase system requirements in order to support the expanded calculations needed for encryption and the possible data storage needed for logging and audit trails. Use of data security standards will allow vendors to develop solutions that meet stated criteria at a cost effective way without putting unnecessary specificity on the solutions, which must be incorporated.
In summary, the security standards for health information should describe minimal criteria to review and authorize user access, describe minimal criteria on how user access to applications should be authenticated, describe how data should be scored and maintained, describe minimal network responsibilities for moving health information between organizations and application endpoints, describe how data should be formatted while traveling between organizations, i.e., encrypted or not.
Members of the committee, this concludes my statement. Thank you.
DR. LUMPKIN: Thank you.
Questions?
MR. GELLMAN: Mr. McCord, did I hear you say that your experience was that sort of basic audit trails were very effective and --
MR. MC CORD: Well, it is hard to say because the sample sizes are small, but some of the most effective procedures that I have seen in our client base has been to develop very basic audit trails, where you simply record the fact that the record was accessed without worrying about which data elements and all of that. But the key issue is telling the patients they are allowed to see that audit trail, to see who was accessing their record and then let the entire house staff know about that this procedure is in place. It forms an effective deterrent to --
MR. GELLMAN: How do you know it is effective?
MR. MC CORD: Well, the anecdotal evidence that I have gotten has been that the -- what the institution would consider an appropriate access by people who ought not to have been browsing the record, for example, has fallen significantly after the policy was put in place.
MR. GELLMAN: You mean, before statistics?
MR. MC CORD: Yes.
MR. GELLMAN: So, you mean they had some measure beforehand of how much --
MR. MC CORD: Well, they had the audit trail.
MR. GELLMAN: No, but before they had the audit trail, they had some measure --
MR. MC CORD: They had the audit trail before -- the change was that -- the audit trails were always there. I don't know any system that doesn't have an audit trail. The question is do you tell patients and providers that this is now available to be perused. And after that was announced and publicized, the inappropriate browsing went down.
MR. GELLMAN: Second question. You said in your statement that you would prefer to see a confident -- you would prefer to see confidentiality legislation first and security standards later. Suppose I told you that we weren't likely to have confidentiality legislation for two or three or five years. Do you still feel that way?
MR. MC CORD: No. Some policy is better than no policy. I think all of us have basically said that this morning, that perfection is the enemy of progress here and something is better than nothing.
MR. VAN AMBURG: All of you have talked about passwords and audit trails and various techniques to monitor access to files, but none of you have talked about techniques or methods to identify files that may be corrupted by misbehaving software, mischievous software or subtle sabotage. Have any of you been working on this and how important do you feel this is in the health care area?
MR. DVORAK: I will take a shot at it.
You asked several questions in there. In terms of corruption that is due to computer system failure, I think people have to be very careful and provide pretty much industry standard approaches to fail-over devices, consistent checking, integrity checking of data, things like that. That is fairly well-documented science that is used in lots of application areas, not just health care. It is very important for everybody.
In terms of mischievous programs, the risk that we see out there is not really due to somebody crafting a specialized virus on a Windows 3.1 machine that is going to attack a particular vendor's application and try to suck the very patient data right out of the application on that Windows work station through shared memory.
In terms of a threat, that is actually a very small threat. One of the larger threats I see out there is that any kind of data processing organization is going to have a certain set of people who have access to the data and will have very low level access to that data, with permissions on the operating system and things like that.
What we recommend is provide effective means to isolate their programming staff from the production data systems. One of your largest exposures to a disgruntled employee is likely to be somebody who has got the intelligence to go in and do subtle things to the records, take away penicillin allergies in every tenth patient. That would make things very, very difficult for an organization to track down and discover and find and deal with.
So, those are the kind of threats that we work with most particularly and our recommendation has typically been to isolate technical staff from the production box to the extent possible within the organization to prevent a potentially disgruntled employee from doing something to that system. The obvious ones, you know, if they delete the whole thing -- and we have had that happen. We have had a disgruntled employee, who an organization had given low level permission to delete the entire thing, just zapped it one day. And they didn't think they would get caught, but through the miracle of audit trails, they got caught. It was identified to a particular person at a particular time in a particular place, who came back early from lunch. And the person was dealt with.
But the real scary thing in my mind is the more subtle things, the crafty programmer, who is going to get in there and damage data in such a way that you will never know it, that could adversely effect patients and liability cases and things like that. The only prevention for that is to not give access to do that.
Anybody else?
MS. FRAWLEY: I was following up on an earlier question.
This goes back to the question of audit trails. We had a number of vendors yesterday afternoon, who testified on the value of audit trails, plus a number of providers yesterday, who also spoke on this issue. And I would like to read two different sentences from two different testimonies.
Mr. McCord, your testimony says, for example, policies should not make blanket requirements such as all events or access will be audited. Such a requirement would create audit trail databases three to five times the size of the clinical repository itself, which has already strained the limits of current technology.
Mr. Dvorak, you said a CPR should provide a comprehensive audit trail of all user accesses to modules for each patient. This audit trail should include the user ID, date and instance of access, module accessed and operation performed.
This subcommittee this afternoon has to come to consensus on audit trails in order to develop recommendations that go forward to the full committee on September 8th and 9th, with a letter then forwarded to the Secretary of HHS with our recommendations. So, obviously, before 4:30 this afternoon, we have to reconcile the lack of consensus on the value of audit trails.
So, I am specifically directing my question to Mr. McCord and Mr. Dvorak, but other panelists feel free to respond.
MR. MC CORD: I don't think there is any inconsistency between what Carl and I said. It is a matter of how much detail you record on that access. The simplest access is simply that I, Jim McCord, looked at Mary Jones' record on a particular date and that is that.
The next level down would be maybe addressing what Carl addressed. I looked at the payroll system. I looked at the billing system. I looked at the medical record. And the worst is I looked at all the positive HIV results for her over the last three years. And the more detailed you get, the harder the computer system has to work. And the issue is striking a balance.
I don't think anybody disagrees with the value of audit trails. They are the single most effective deterrent to misbehavior and, as Carl said, he found a person who actually damaged a record. If you have to have a rule, keep it simple is what I would say.
MR. DVORAK: I would concur. What we do is we basically track -- sort of a slightly finer granularity. We know if somebody went into chart review. We know which encounters they looked at. What we do is we basically stamp each encounter or each order that somebody looks at with the user, the time they did it and whether they just viewed it or they actually modified it.
That is the level of granularity we get to. What we have also found very effective is we show when any user ever looks at an encounter or every looks at an order, they see at the bottom of that order a listing of everybody who has looked at the order in the past and what they have they done with it.
So, we are not down to the data element level, which would be a very burdensome thing to do and would generate more traffic and audit trails and actually traffic in real work. But that does provide an excellent deterrent and it is very helpful to show it on the screen, so that when a provider looks at a record, they know their name is going to be on that list. It is a very effective deterrent.
MR. MC CORD: I remember sitting in a meeting with the CIO for a major academic institution with a bunch of her doctors and she just casually mentioned this audit trail. One of them looked and said I didn't know that. You have to get the word out.
MR. BECHTEL: I would also concur that the SNS systems perform very much the same way as we have just heard Mr. Dvorak and Mr. McCord describe.
MR. MEYER: My comment relevant to audit trails would be specific to the fact that as we have in all facets of this legislation, keep in mind the diversity of systems that we are dealing with. The legacy systems have traditionally focused their audit trails on who has changed the record, not who accessed it or who did the last inquiry because their focus has been someone changed something. I know who changed it and what it was changed to and if that was incorrect, I know the person responsible.
To try to enforce upon them a need to now expand that, to say who last inquired or what is the inquiry history upon this record might become overly burdensome.
Also, back to Mr. Van Amburg's message there, it is extremely difficult, as Carl pointed out, to detect subtle changes and I think few if any of our systems could do that automated. And to have a manual audit process would be ludicrous. Those malicious attacks that you see in my mind at least are more often directed toward the organization than toward the individual. The intent is to destroy the general ledger system, eliminate billing information, as opposed to going in and trying to manipulate someone's medical record.
The malicious individual rarely sees benefit from changing the test scores on a single individual in my mind versus destroying the billing process. So, it would be more an issue of concern from that perspective on the general back office procedures of the organization or the provider of the hospital than the clinical data, generally speaking.
MR. DVORAK: I would point out there -- when you deal with very large organizations, there are always the radicals and exceptions out there. We had a case where a user attempted to put a positive HIV result on an employee, which would instigate a follow-up call and follow-up on HIV. They, again, were identified.
I think it is important to remember that as this gets bigger and bigger and spreads across the country, there will be all manners of people who attempt to do damage to things and it is not just general ledger systems and things like that. They will find new and creative ways to alter information and wreak their havoc.
DR. LUMPKIN: Just as a follow-up, are you aware or do you use artificial intelligence technology to review the audit trail, so that, in fact, you are not -- you may not necessarily need to keep all the audit trails, but just those that sort of fit a profile?
MR. DVORAK: We don't use artificial intelligence at this point. We have certain sort of prescribed algorithms to check on certain cases that we think are obvious. One of the more classic checks is to -- we define a system where we can determine with a certain degree of surety whether the person has a probable reason to look at that record and sometimes probable reason, if you are working in the urgent care dependent, you get a much broader probable reason to look at records.
If you are working in practice in the clinic on a certain day, you have less reason to look at people outside your schedule, although you do need to. So, what we try to do is run analysis through the audit trails routinely that tries to look at those cases where we can identify a person who maybe has a higher frequency of what we consider inappropriate accesses outside their domain. That is about as best as you can do with right now, which is sort of a -- it is a slushy technique, but it allows people to see what are the kinds of trends people use in looking at data and they can then add that to the list of things to check for.
MR. MEYER: HBO Systems as a point of case would prefer to take the focus on eliminating that access up front as opposed to detecting that it occurred. So, we very much tried to limit the domain of information and if, for example, you are not a resident on the psych ward, you don't have access to psych data.
Now, admittedly, as Carl pointed out earlier, there are circumstances where you have systems professionals that have access to systems data. But, again, you almost have to come down to enforcement of an ethical code of practice there because if you, quote, unquote, limit their access, you limit your capability to evolve and maintain and support your system.
So, I mean, there is give and take on that.
DR. LUMPKIN: Well, let me follow up on that just to give you a hypothetical example.
I am working in the emergency department. A patient who is well-known to me, who comes in, who has got sickle cell anemia and a hot gall bladder, who has indicated to me that they have had a recent psych admission and they are refusing care and want to sign out of the hospital and I have to determine whether or not there is enough of a psych history to commit this patient because they may not be able to make that decision.
If you have a general level restriction that only people who are in the psych ward have access to those psych records, I am in an impossible situation.
MR. DVORAK: We call that a break the glass situation and basically what happens there is we try to allow you to break the glass to get at that information. It usually involves two users signing off on it and a supervisory notification. And you have to state your purpose.
So, you can break the glass, but then everybody knows you broke the glass. That is a very strong deterrent. People aren't going to break the glass and routinely scan people's records because they will get caught. The only exception to that has been situations where it is justifiable -- not justifiable but for one reason or another, if an individual feels it is more important to get information than to keep their job.
So, if Michael Jordan checks in to a center, it may be worth more money or more -- it may feel better to the person to understand why than to keep their current job. That needs to be understood. What happens, there is -- you only let certain levels of people break the glass. What you really are trying to do is correlate that with people who respect the importance of their job and don't want to get fired.
MR. MEYER: Wouldn't in that situation procedurally a psych consult solve that scenario? I mean, admittedly in certain trauma scenarios -- but he wouldn't be talking to you in a trauma scenario. So, there is one -- procedurally, that could be addressed. The consulting psychiatrist or psychologist could provide that information. Alternately, yes, there are procedures that can be established to say contact with the appropriate systems security officer could subsequently grant you access to that information. It would be a delay, but nonetheless to delay in that case is in support of the privacy and confidentiality of patient information.
So, that is about the only response that I can give in that scenario.
DR. LUMPKIN: Well, it would work at a teaching hospital, where you have a psych consult on board. At a community hospital, where I have worked, where they have had psych units that -- the psychiatrists don't seem to carry beepers the way some of the other --
DR. COHN: Can I take my question now, which actually turns out to be sort of a follow-up almost of this question and it isn't on audit trails, but it is on the general question of sort of the appropriate level of security that the community should be seeking.
Now, Chuck, you had -- actually in your written testimony had advocated establishing an initial minimal set of security requirements, quoting "setting the bar low." Now, I guess that -- we had heard yesterday from a number of other vendors, who strongly commented that you needed to build security into the system from the beginning or else it became a very expensive thing to add on afterwards.
Now, I am finding there is a little problem I am having -- I mean, I can understand policies and procedures, starting low and then advancing them, but in terms of actually putting it into system capabilities, can you explain this one a little further to me, as well -- I am curious if any of the other speakers have a comment about what sort of, you know, fundamental security features we should be advocating.
MR. MEYER: Certainly, the design of systems needs to include considerations for security aspects. I think most all of the systems available today, be they Windows-based or even legacy systems, provide at the minimum nominal password support, access control, audit trails, et cetera, et cetera. I mean, we have not been blind to this issue for the last 20 years.
When I say set the bar low, I am talking about in establishing the standard, define a set of policies and procedures that -- or maybe just a step beyond where we are currently at, clarifying the situation of security, making it very obvious to those systems that may be lagging in the marketplace, that if they don't step up to this, they are going to become non-competitive per se, if they don't already recognize that.
I agree that with any scenario, to try to do add on to a product is detrimental to the good keeping of that product. However, to establish a standard and then build that into the design for the next iteration of your product is certainly not overly expensive.
DR. LUMPKIN: I have the same question. Maybe I can ask a follow-up to your follow-up of the follow-up to the other question. And that was would it be consistent with what you are suggesting to set the bar for the year 2000 at one level, but have some vision as to where we ultimately expect to go in, let's say, 2002 or 2003, so that those who are building towards -- building systems today can understand where we are going, yet the bar that we would expect people to jump over at some date certain would not be so high as to be cost prohibitive.
MR. MEYER: Well, certainly, I think that is a viable approach. I mean, if nothing else, we have to anticipate, as Mr. Gellman pointed out, what might be coming down the pike in the form of privacy and confidentiality legislation. Because security is, in essence, the mechanism that ensures that confidentiality. So, we have to at least be farsighted enough to say we expect these to be primary privacy issues; therefore, our security standards have to address at least to that level or be approaching to it.
I, again, cannot stress enough the need to be policy and procedural based and I give very heavy weight to the European pre-standard as taking that approach, developing an assessment level, identifying what type of information falls under that assessment and what is appropriate to counter that and then how we implement that, using PGP or encryption or whatever is the next step.
MR. DVORAK: I had a comment on that as well. As people building systems, it is very important to build systems to be added on to. It is not necessarily a bad thing to add on to a system. If it is a good system, it is something that is planned, how to add additions to the system because over time our systems today will become legacy systems if we don't. And whenever you put a system in place, folks like Charles and his friends can spend six months or seven months and find new and creative ways to break it. So, I think as you build systems that try to comply with security, you need to have the foresight to build in the opportunity to add new features over time.
MR. MC CORD: Many modern systems basically have security construction kits and you can use those construction kits to get just about any level of protection you want. The trouble is that the more detail you get, the more you are forcing people to make too many decisions. If you had to protect down to the item level by physician, by patient, you might literally be looking at decision tables with tens of millions of entries and no one is going to do that.
So, even if the technology is there to provide infinite levels of protection, you have to have some reasonable stopping point or things will just be ignored.
DR. COHN: This is just a follow-on, just to make sure that I really understand this one. Because I am sort of hearing sort of two slightly different things from the group. I am hearing -- let me see if I can conceptualize it.
John had identified saying start here and then move to something better with a vision sort of over the next couple of years. And I guess I am hearing a number of you saying, well, you know, give us six months and we can create the ability to have really good security now. So, it really isn't that big of a deal. And it is just really more that the people issues and policy and change issues are the things that become the big issues.
Am I misunderstanding, that it is not an issue from any of your sides as vendors in terms of being able to put the potential for real good security, for optimum levels of security in your systems. It is really more the people issues and the change issues.
MR. DVORAK: I would suggest that most of the systems that have been built in the last three to five years probably have more security in them than your recommendations will probably indicate starting out. So, yes, I think it is really more of an issue of getting a common consensus of what adequate security really is that people can use and grow with and then as things add to that over time, as your techniques are developed to break the latest encryption, then people need to be ready to adapt to that over time.
MR. MC CORD: Now, there is an issue with a huge installed base of legacy systems, as Chuck was talking about, that weren't built that way and they do have some problems. I agree with what Carl said. The modern systems are pretty flexible, but, again, it is not just technology or even the people in the policy. It is the cost of doing it. It is the performance hits on the system.
Those will always be with us. There is always a tradeoff here no matter how good the technology gets.
MR. MEYER: And I would certainly agree with that. There is no intent, but there is certainly a product bias involved here. The newer systems as represented by Oacis and Carl's products certainly have had the capability to react more quickly and build more security into their systems. There is no question about it. It is much, much easier to go in and change a Windows-based product than it is to rewrite 25,000 lines of Cobal. I mean, there are just inherent differences in the systems.
However, we as vendors recognize that it is -- and we have been working on this for a period of years -- it is time to drag those people out of the eighties and start moving forward. And we are all working on enterprise systems, plants over-based. We are incorporating the new technologies and that is coming along. Looking for a bar to set the level is very, very appropriate for us in that mode.
MS. FRAWLEY: Just a follow-up on Simon's concern.
The NRC study committee, if you look at Chapter 6, because we found on most of our site visits in our briefings that most of the industry doesn't even have a security perimeter, and we are not talking the vendor applications here. We are talking users.
We made site visits where the password for people was RN and MD or the four digit doctor code that was posted throughout the hospital. So, when you walk into an organization and you see that is the level that you are at, then we can't jump, you know, ten steps up.
So, I think that the point that Chuck was making is that we have to start at least defining what the threshold is, get everybody to that level and if you look at the NRC report, there is some let's get the bar here and then two to three years from now, move people along to this stage and then, hopefully, down the road to here.
But we have a significant problem in this country that most people using clinical information systems have totally inadequate organizational policies and procedures. So, you cannot come out with recommendations saying we are going to do x, y, z, when we have organizations that haven't even come up with adequate password control.
MR. BLAIR: I have two questions. They both relate to what suggestions you have on the thresholds for encryption. Yesterday, Dixie and Ralph Cortman(?) wound up, I think,, giving us some very useful education on how we could strengthen and provide thresholds for security and it included, from what I can determine, one end of the spectrum.
We also had testimony from a person -- and I forget how to pronounce his name -- Kapas(?), from Affect(?). Is that correct? And Don, you are here also representing some form of health data exchange, health data network, and we were cautioned not to wind up going too far in extreme with respect to encryption.
Let me get to the specifics of my question. It seems as if what I am hearing, everybody seems to agree that if we use the Internet, we need to have encryption procedures. The second level below that is if we are using clearinghouses or value-added networks, I am hearing from the vendors that deal with those or the standards organizations that deal with those, that that might be a problem if we require encryption over value-added networks and for clearinghouses.
Then the third level, of course, is -- I think what I heard from Dixie and Ralph Cortman, that maybe we have to look at this from the standpoint of the weakest leak, in which case encryption may be even required even within an organization.
So, my first question is going to be where should the threshold be drawn? Is there any consensus on that?
The second part of the question on encryption is the scope or domain of what gets encrypted, which would be do we just need to encrypt the identifier or patient identifiable information or do we have to go all the way to encrypting clinical information?
So, there are two questions and I would like to hear your recommendations as to the thresholds for both.
MR. BREED: That was a lot of questions.
I am more of a security and cryptographer than I am familiar with this industry. So, I mean, you really need to determine what your policies are going to be for access control and guidelines and things like that. I can't help you with that. But the underlying technology, you have to have something that guarantees data integrity, encryption through confidentiality and adds privacy and also non-repudiation of the signature.
I mean, those mathematical things can be done today through, you know, a whole variety of algorithms. How you apply those is really the tough part and I think that is kind of what this group is wrestling with. I am kind of below that line, where I provide the tools to do all that data integrity and digital signatures and non-repudiation and encryption and if you can't read it, you can't break it, you know, all that stuff.
But how you use hammers and screw drivers and pliers is something more for you experts than I can answer.
MR. BECHTEL: Speaking from the point of view of a clearinghouse for HDX, to your questions, Jeff, I think there is definite concern about adding overhead to the processing of transactions, when the process the volumes that we do. However, as I noted in my written testimony, we have recently added encryption to all the transactions that we are moving on our interactive network.
We have recently added encryption to the on-line transactions that we process on our network today. The encryption algorithm that we used, however, was not a standard encryption. This was a proprietary implementation that we used.
The reason we did this is it was something we could do easily and quickly with a network change that we were implementing. We felt that some level of encryption is valuable and should be done.
We have looked at other encryption algorithms like RSAs or DES and have evaluated the cost of using those with the transactions that we are doing today and the time to process those algorithms versus what we did in our proprietary solution is many times slower. We are spending about 4 milliseconds on each transaction today just in the encryption process of what we have implemented in a proprietary solution.
It approaches almost a second when you start moving into some of these other more complicated algorithms. So, to add that kind of overhead to the process in time and the number of transactions you are doing, that can be quite detrimental.
DR. LUMPKIN: Can I just break in here? Can you give us a frame of reference of what is the normal time for a transaction and, so, where is that -- what are the milliseconds to --
MR. BECHTEL: We are processing something on the order of about 50 transactions per second through our switch. If you start to add those kinds of overhead to those transactions, you are going to reduce the number of transaction throughput we are getting.
MS. FRAWLEY: I just need to clarify something. Using your proprietary form of encryption, so that adds 4 milliseconds?
MR. BECHTEL: Yes.
MS. FRAWLEY: Okay. Let me ask you this. If you used PGP, what would the time be? We are trying to get a sense of -- I mean, if we recommend something, what would be the appropriate standard?
MR. BECHTEL: I do not have the specifics and I wouldn't want to go on record as giving you those, but I could certainly get those for you. And I would be glad to offer that information to you.
MS. FRAWLEY: Mr. Breed, do you have any comments?
MR. BREED: It is just a -- I mean, you are just
-- PGP uses algorithms, which are based on mathematical functions and, basically, the longer the key length you use, the longer it will take to encrypt something, but it is usually -- or if you at the end user desktop, it is absolutely insignificant. If you are on any type of a desktop machine to send or encrypt or digitally sign or verify a signature from a single user, it is insignificant, but at a server side, where you are doing these 50 transactions per second or whatever, it is something that can be solved by throwing more horsepower at it.
It is an issue. It is an issue for network devices, too. I mean, if you have got -- had a router products of Cisco(?), you turn encryption on it, you know, slows the box down dramatically. This is physics that we can't change.
MR. DVORAK: I would like to add one comment to the encryption discussion and that is encryption is sort of fun and interesting to talk about. You can draw nice pictures about it. My concern is that if we send people down the path of encryption, what we are really missing is the notion that we need to prioritize all the different security threats and risks.
In encryption, getting data off a live network is probably one of the most significant arts in computer science. It is very difficult to do, just if it is plain text. I think when you go over the Internet, you have to be aware that Internet service providers can sometimes take a four or five megabyte dump of traffic and can go peruse it for interesting things. So, across the Internet you have to be careful.
But within a health care organization, I think that the prioritization of security threats needs to take place first so that we don't send the world on an encryption path, when, in fact, we are leaving millions of records unsecure because encryption is going to take people a long time to get through and there are much more other important things that could be done to protect patient records.
MR. BLAIR: Before you conclude your remarks, could you give us what you would suggest or recommend should be the thresholds for encryption, both in terms of scope and in terms of what it is being transported over?
DR. LUMPKIN: I think that we have had the structure placed before us, that we have data in motion and data at rest. I think what we would be interested in your recommendations for levels of encryption in those two domains.
MR. DVORAK: In different kinds of motion it sounds like.
MR. BECHTEL: I think I would first suggest that the networks that we are using today for the clearing house functions are fairly well secured networks in the sense that these are private lease lines. They are not on the open internet and I personally believe that, yes, they could be invaded, but it would be very difficult to invade these kinds of networks.
So, I question whether encryption, as Carl has mentioned, is really the first order of business. I think the first order of business might be authenticating where your transactions are coming from, knowing the authenticity of those transactions that you are processing and, you know, the origin of the transactions within the applications that are requesting them.
MR. BLAIR: If I hear you then, you say encryption is only appropriate for Internet communications?
MR. BECHTEL: I would suggest at this time that that would be true.
MR. BLAIR: And what would you feel would be the minimum level of what we encrypt? Would it just be the identifier or all patient identifiable information or all clinical information?
MR. BECHTEL: Certainly the information that you are encrypting is going to take -- you know, the more data you encrypt, the more time you are going to spend. So, the more we can limit the amount of time we are spending on that, the better. So, I think if we can identify a set of information that we want to be hidden, that is the information we should be encrypting.
MR. BLAIR: Could we hear from Chuck of HBOC, as well?
MR. MEYER: I was kind of at the other end of the line, Jeff.
Jim, did you have anything specific to --
MR. MC CORD: I would only say that there is a technical issue and a market issue here. No vendor would be able to do anything with the Internet without encrypting the data, even if we thought it didn't matter. We have just put a browser front end on our repository primarily to provide cheaper access into doctors' offices and their homes, and we encrypt everything, all inbound, outbound transactions because we couldn't sell it otherwise.
MR. MEYER: I think that is going to be the general consensus, Jeff. There is no question that if you are going to operate on the Internet, you need to be secure, absolutely. However, below that level -- and I, too, can speak somewhat from a clearinghouse perspective because with our acquisition of psychere(?) psi(?) data, we moved into that arena as well.
We are not supportive of encryption to the Internet level on our private networks and value-added networks. As Kepa pointed out in her earlier presentation, much of that access is already controlled under other legislation. In order to intercept that type of information or access from the provider's office to the van, for example, you would be committing wire tap, illegal wire tap. There are severe penalties for that.
Secondly, we see little -- and that may change in the future, but we see little emphasis on hackers or others to target specific medical information and the effort needed to try to capture information specific to Michael Jordan, among the other millions of transactions that are running through there is going to require massive resources.
Thirdly, on the value-added networks, for the most part, you would need like technology to interpret the information if you did intercept it. You would need a main frame or an NVF(?), et cetera, et cetera, et cetera, because otherwise the X.25 packets and the information contained would be meaningless to you.
So, there is a lot of stuff that comes into play there. Now, we are absolutely against any encryption intolerance to our specific system, specifically at this point in time. The overhead to retrieve decrypt, present, return recrypt and store would just blow response time out of the window, as far as I am concerned. And I might be a little naive there. I am sorry, but that is our opinion.
As to the appropriate domain of information, we are certainly supportive of the encryption of patient identifiers. The question that you run into there is what is truly the scope of identifying information. Truly, it is easy to say, well, I will encrypt my medical record number and my patient account number and my MPI number. But if you know the person's address, can you not identify them?
If you know the person's birth year, social security number, telephone number, can you not identify them? So, you know, that -- there is a scope creek(?) that comes into play there that is extremely difficult to handle.
MR. BREED: You have got to break this down to the most fundamental level here is you need to know your attackers. What are they trying to get at? Where are the attacks? Are they access control attacks? Are they really sophisticated type of attacks? Are they trying to just delete things, modify things?
So, if you have an understanding of what your attacks are, you can then prevent. If you put a huge padlock on your front door and they break through your window, you know, it didn't help you all that much.
Then the second thing is what do you attack? What are you trying to protect? If the data you are trying to protect is worth $10, you don't spend a million dollars to protect something that is worth 10 bucks. Also, data has the notion of time, where tomorrow's winning lottery number has a huge value today, but after they announce the numbers, it has no value tomorrow. So, how long do you need to protect it?
The notion of not needing to protect internal data is a little dangerous. If you have any modem on your network, I do have a hobby of linear indifferential crypt analysis attacks, with just a Pentium PC, I can read anything you have anywhere on any data with any type of packet analyzation stuff.
So, I don't care what operating system, I don't care what data, I can do scans for all types of dictionary attacks and names and modify things and do immense damage.
MR. BLAIR: Are you suggesting that even within an installation --
MR. BREED: Very much, yes.
MR. BLAIR: -- encryption of the identifier or patient identifier --
MR. BREED: Yes. Anything across the Internet, you need to encrypt the whole damn thing.
MR. BLAIR: Chuck, is that contrary to what you would feel comfortable with?
MR. MEYER: Well, obviously, Jeff, I am up against an expert here and I am nowhere his qualification. What I was presenting was simply the opinion as expressed by those I have conferred with within my company. Certainly, if the standard that is adopted requires that, it will come up that level. However, I think you are going to have a hard row to hoe in selling that down the line.
MR. BREED: If people are attacking it, you need to protect it. If you are not worried about a threat, don't protect it.
MR. MEYER: And that is the key issue, risk assessment. Where is the threat and how do you provide for it?
MR. BREED: I don't protect my newspaper in my mailbox because if someone wants to take it, it is 50 cents. You know, there is not a padlock on my --
MR. MEYER: I would also point out that in the presentations that were made on -- from Kepa and others on that side of the industry, more to the point was authentication of the message versus encryption of the message and the problem that end-to-end authentication would cause, i.e., only authentication between the provider and the payer, that would not allow the clearinghouses to perform their function. We need authentication at the level of a chain of trust. I don't think that there is any question that we all want to know that we got this message from who we think sent it to us and that, in fact, they validated that the message is correct, but that needs to go from provider to clearinghouse to clearinghouse to payer and there is this chain of trust that is established through the contractual relationships and the business partner relationships that ensure that and the authentication is simply validated.
DR. LUMPKIN: Carl, you didn't weigh in on this.
MR. DVORAK: In general, I think what Charles says is right, but I think it is important to remember that no matter what we do to protect and encrypt the data, somewhere, sometime, somebody will break it. People still steal $40 million chunks of money from banks that are very well protected.
So, I think it is still very important that we prioritize our threats and deal with them in terms of the most opportune issues first. And I think encryption will truly be lower on that scale than these other issues.
MR. ZUBELDIA: First, let me say there are two different kinds of encryptions we are talking about. What Don is saying that takes 4 milliseconds is symmetric key encryption. For instance, in Europe all the telephone systems and the cellular phones, the DSM, use encryption. In a telephone, you don't have a very powerful CPU. However, it takes less than 5 percent of the CPU power to do encryption on real time conversations.
So, that is very easy to do. There is a phase that happens prior to the symmetric key encryption and that is the key exchange that has dual purpose, authentication and to convey a symmetric key. The key exchange phase is extremely expensive. At Envoy(?), we have done some benchmarking on how long this is going to take and we found that using this cell and depending on the size of the certification that the other party will have and whether we use a client certificate or browser certificate or both, it takes anywhere between 1 and 2 seconds of time to do the key exchange and simply because the certificates are large and they are computationally intensive to calculate the keys. So, if we as a clearinghouse were to encrypt everything, it would take 2 seconds for the incoming message and 2 seconds for the outgoing message to a payer and then you add another 2 seconds and 2 seconds for the response. So, we are adding 8 seconds overhead for the encryption when the switch today ?takes under 3 seconds to do the switching.
So, we are going from 3 to 11 seconds. That is very expensive in time. However, we go with a proprietary algorithm using symmetric key encryption and don't do key exchange, don't do authentication, then encryption is very inexpensive. So, we are looking now at maybe using a proprietary algorithm or something like DES that uses symmetric keys and maybe establish a key exchange once per month with our clients, using PGP.
Now, the other problem that we run into is that there is a lot of terminals out there that do not have the capability of doing this period. Those point of cell devices do not have the computing power to solve the problem and we cannot solve it by putting more iron, more horses in our shop. We cannot speed up the encryption by adding horsepower in our shop when at the other end we have a 386 or a Pentium doing this encryption and key exchange because we are not going to speed up their process.
That has been a realization that was shocking. We thought, well, if encryption adds 50 percent overhead, we will just buy more computers and take care of it and it doesn't take care of it. Most of the time on the key exchange, although it is computationally intensive, it is related to the time it takes to actually transmit the data.
If you are going to send a 5K certification in both the actions, that takes time and no matter how fast the CPU is, it is still going to take time. So, that is why we are very strongly cautious about what encryption is used,, what technology is used and making sure that we don't require encryption for all the data that is now going through a private network that is not subject to attacks, like the Internet is.
Now, on the Internet we do need encryption. Let me add another thing on the advantages of encrypting everything as opposed to just encrypting the patient identifier. When you encrypt the patient identifier, you add overhead for each patient identifier, similar to adding a key exchange for each patient identifier.
If you encrypt everything, the overhead is minimized, plus, you run into the advantage of being able to compress the data before encrypting. It is not cost effective to compress a patient identifier, but it is cost effective to compress a 5 megabyte file down to 1 megabyte file and then encrypt it and most -- well, some of the encryption programs, specifically PGP will compress the data before transmitting. So, by encrypting everything, you run into that advantage.
Also, the X12.58 provides facilities for compressing everything before encrypting. So, there are some advantages to compress everything because you will have less overhead.
MR. BLAIR: Let me repeat this back to you to make sure that I understood what you just told us.
You are indicating that you are not really concerned with whether or not we come up with a minimal standard that requires transcription over value-added networks or not. You are just concerned that we don't specify the technology that you must use. That is the first point that I thought I heard.
The second point is that in terms of the scope of the encryption, you have the opposite problem that a vendor of a clinical data repository would have. In your case, it is going to be easier for you to encrypt the entire batch of messages, rather than to try to separate out the identifiers. Is that correct?
MR. ZUBELDIA: That is correct. On real time transactions, it may also be easier to just encrypt the whole thing rather than just the identifier.
MR. DVORAK: Can I just stick in one analogy? And then I will shut up so you go on break.
One thing that is important is we consider authentication techniques for providers to use when they are using clinical systems and providers to identify with this. You should think of something that is going to be fast and efficient and a provider will need to sign a computer -- to sign at a computer station approximately about the same amount of times they sign their signature today. You want something that is as fast and efficient as signing your signature because that is probably how many times you are going to end up doing it as we continue to progress with automated clinical information systems.
DR. LUMPKIN: Thank you.
I would like to thank the panel. We can see that there is --
MS. COLTIN: John, I had a question before you conclude with the panel.
DR. LUMPKIN: We are about half an hour late.
MS. COLTIN: It is something that hasn't been covered and I would like to get it in.
DR. LUMPKIN: Okay. And just because you are asking this question, we are going to skip the break. So, I just wanted to tell the panel if they are in the audience, not to leave because we will move right into the next panel.
MS. COLTIN: Okay.
This is actually going back to the issue of audit trails and tracking and the concern that was raised the size of the records that are kept, you know, for tracking. I think I heard consensus around the need to track inquiries, as well as tracking additions and alterations, at least from those who are working with clinical data.
What wasn't as clear to me is that within inquiries there are different types of inquiries. There are the inquiries to the individual patient record and then there are the analytic reporting inquiries that are made across populations of records.
Are you taking any position with regard to audit trails for those sorts of inquiries and, in particular, differentiating inquiries that do require individually identifiable information versus inquiries that do not? In other words, the output on the other end may be individually identifiable as opposed to where it is not.
MR. MC CORD: I don't really know if I can contribute much to that. Most of us here at the table are more interested in the patient-by-patient inquiries and our systems are all optimized for that, to be quick to get at a particular patient record and a piece of data within that record. A cross sectional analyses like you are talking about really are a different animal. They require the databases to be indexed differently and they are tuned for a different purpose.
We have a lot of clients who do those kind of cross sectional analyses, since we serve a lot of academic medical centers and they just unload the database into a different database, re-index it and then do their analysis. And we don't really try to impose any restrictions on that. That is their business how they choose to handle that.
So, I guess I can't really speak very well to differences in policy on cross sectional versus longitudinal access.
MR. DVORAK: I did have some comments in the written information that one of the approaches that people recommend is to take -- to basically scrub the data for analytical reporting purposes and then assign a report key to that data and then in order to get access to the patient identifying information, you have to get approval to use the report key and approval to use the key could be audited and the report contents could be set aside.
That could be a mechanism to audit who has looked at a cross section of information. It is still very difficult and it assumes you are not going to share it with the office people and things like that. It is clearly one of the more difficult areas to manage.
DR. LUMPKIN: Thank you. A very stimulating discussion. We appreciate you coming and presenting.
DR. LUMPKIN: I would like to reconvene from our non-break.
Our next panel -- I will just ask the members of the panel to introduce themselves and then we will start off with Dan Staniec.
MR. STANIEC: I am Dan Staniec, the executive vice president of the National Council for Prescription Drug Programs. We are an ANSI accredited standard development organization in the pharmacy services sector of the health care industry.
MR. BARRETT: I am Lee Barrett with my hat on today as executive director of the Electronic Health Care Network Accreditation Commission or EHNAC.
MS. KRATZ: I am Mary Kratz with the University of Michigan Medical Center and I am here today representing the Health Level 7 Standards Development Organization.
MS. LOVORN: Hi. I am Jan Lovorn and I am chair of ASDM 3120 on data and system security for health information.
DR. LUMPKIN: Dan.
MR. STANIEC: Good morning. Thank you for the opportunity to present to this panel security standards recommendations of the National Council for Prescription Drug Programs, NCPDP, an ANSI accredited standard development organization.
I am Dan Staniec, executive vice president of external affairs. I am a member of a number of pharmacy organizations, including the American Pharmaceutical Association, National Community Pharmacist's Association, the Academy of Managed Care Pharmacy, as well as ASC X12, HL7, the Work Group for Electronic Data Interchange, WEDI, the Health Informatics Standards Board, the Object Management Group and a participant at UN/EDIFACT meetings.
I am also a board member of the Computerized Patient Record Institute, CPRI, and the University of Arizona College of Pharmacy.
As I mentioned earlier, NCPDP is an ANSI accredited standard development organization for the pharmacy services sector of the health care industry. Our ANSI approved scope statement reads: The cope of the standards the NCPDP develops are those for information processing for the pharmacy services sector of the health care industry.
Regarding the development of pharmacy standards, NCPDP is the forum where pharmacy meets four times per year to develop standards. Our 1,159 members are employed by organizations from virtually every type of pharmacy organization in the United States. Some examples of these types of organizations include: chain pharmacies, the independent pharmacies, drug manufacturers, Blue Cross Blue Shield organizations, federal/state agencies, health maintenance organizations, pharmacy benefit management companies, telecommunication and systems vendors and wholesale drug distributors.
Our membership consists of three specific categories, with a fairly equal number of members in each category. These categories are the providers and the producer, the payer, the processors and the telecommunication system vendor/general interest. As you can see, NCPDP does represent the voice of pharmacy in the standard development arena.
We have also submitted NCPDP's telecommunication standard to ANSI to become an American National Standard and look for this transaction to be one of the first health care transactions being considered this honor.
I would like to respond to the last few questions on your list addressed to the standard development organizations. With the limited time frame to present, I cannot discuss company specific or business partner issues related to security. Our answers will address the concept of the actual transmission of pharmaceutical claims utilizing NCPDP's telecommunication claim standard from an industry as a whole.
Question No. 1, what standards presently exist regarding security? The NCPDP telecommunication claim standard does not really define security standards. As you may know, the International Standards Organization, ISO, has defined a framework for the definition of telecommunications standards. This standard, known as the open system interface standard, delivers a seven layer hierarchy of functions with a telecommunication network. The applications layer provides all services directly comprehensible to the users applications. In other words, this is the level that interfaces with the users application.
The applications layer identifies the user and sets an agreed upon level of security and makes one user responsible for error recovery. The existing standard development organizations define the presentation layer, which restructures data in the required format.
There is no known problem in the pharmaceutical industry with respect to the transmission of data. The exchange of roughly 6 billion prescriptions sent electronically using the NCPDP telecommunication claim standard has occurred over the past few years.
I would like to briefly describe again the actual telecommunication claim standard developed by NCPDP. I am a retail pharmacist and I worked on Saturday mornings. I do have a password and I do have access to certain databases and, again, I transmit the information. I type it into the computer, the patient's name, the name of the drug, the NDC number, the name of the physician and I hit the send key and that is sent electronically usually through a switching company and then it turns around and switches to a particular payer. It could be a PBM or a processor.
It goes through a verify -- a number of databases, eligibility, if the drug is covered, if the pharmacy is covered, if the doctor is covered. It goes through the database. It goes back to the switch. It goes back to the pharmacy in a matter of seconds.
So, again, just to confirm, this is interactive, on-line real time communication of data. The data that is transmitted electronically using the NCPDP telecommunication standard is all coded. And I think that is important to point out, is that, again, there is a specific number for the drug, which is the NDC number.
So, the other end of the receiving party knows that with a particular NDC number that it is Valium 5 milligram bottle of a thousand, broken down by that specific NDC number. The pharmacy identification, they know what pharmacy it came from. It was a specific NCPDP provider number that we maintain in the industry. So, we know that it is a certain Revco or Walgreens or WalMart store. Again, it is like a fax machine.
I send it to a particular number. It will go to that number. Again, the doctor/prescriber, we support the HCFA MPI effort. There are various numbers being used at this time. Again, the patient/cardholder, usually it is the social security number. Sometimes it is a policy number, but, again, that information sent in a matter of seconds.
Regarding Kepa's comment earlier today, we certainly support his position that we are against encryption. Again, we are not using the Internet with our telecommunication standard. It is done within a closed network and the cost, again, increases the efficiency of the electronic claim. As Kepa pointed out, the number of seconds will actually increase by encryption and also, too, I have heard that the cost, between 15 and 20 thousand dollars per pharmacy -- again, what is the perceived benefit of adding this?
Are we actually seeing a benefit based on the amount of cost being involved. And also, too, Kepa pointed out the technology, whether the pharmacy at the POS, point of service, level has the capability to transmit this type of encoding and encryption.
Question No. 2, what plans are underway to address security requirements? Various companies, such as Pharmacy Benefit Management Companies, continue to enforce existing security standards at the company level as the new technology evolves.
Question No. 3, do you feel that there is a need for the Federal Government to provide leadership in this area?
Yes, there is a need for the Federal Government to provide leadership in this area, but only from an enforcement type perspective. It is imperative that the private sector should create security standards for the health care industry. We do support a joint SDO effort. We have worked with ASTM, working in the Health Informatic Standard Board to create a unified type standard.
At this time, we cannot endorse the ASTM security standard due to the fact of the extra costs, as well as not necessarily having the technology available at the retail pharmacy end to accept the ASTM security standard. We are certainly open for suggestions and having a joint SDO effort is what our recommendation is.
NCPDP thanks you for the opportunity to testify today. I look forward to responding to any other questions that you may have.
DR. LUMPKIN: Thank you.
Mary.
MS. KRATZ: The Health Level Seven ANSI accredited standards development organization endeavors to standardize the format and protocol for the exchange of certain key sets of data among health care computer application systems. HL7 has formed a special interest group on security to address the practical implementations of secure transactions between systems in health care environments today. The objective of SIG Secure is to identify user requirements, the services needed to meet those requirements, the mechanisms for providing security services and the specific implementations of security mechanisms.
As a representative of the University of Michigan to many health care standard development organizations, I, Mary Kratz, thank you for the opportunity to be here today. My participation in HL7, X12, ASTM, HISB and CORBAmed has focused on the many aspects of health care security.
As co-chair of the HL7 SIG Secure and the HISB work group on security, I have observed that the demand for secure electronic health care systems is growing exponentially. The need for secure transactions, driven by public emphasis on patient privacy issues, provided the impetus for the development of ad hoc security solutions. Increased automation of labor-intensive administrative tasks has revealed the need for further security in both clinical and financial processes.
The scope of HL7's secure transaction SIG is limited to providing network and Internet security mechanisms for HL7 transactions at the application level, independent of underlying transport. The SIG is focusing on the use of HL7 in communications environments where there is a need for authentication, encryption, non-repudiation and data integrity. This group directs its efforts on insuring the mechanisms are available for implementing a secure HL7 transaction and not on standardizing security policies.
HL7's SIG Secure has identified related works of other standards development organizations as well as publicly available specifications and has attempted to leverage that work. The HL7 organization is also interested in participating with the efforts of the Internet Engineering Task Force. A CommerceNet trial using e-mail protocols, such as Secure MIME, encapsulates HL7 messages and is being explored for further feasibility.
HL7 secure transaction SIG has drafted a white paper that details our efforts to date. This white paper is available on the Web at the HL7 server on Duke University.
Security Services: The health care industry, as all industries, requires the use of a broad range of electronic services. The basic service types required for all forms of electronic commerce include network services, things like local area networks or wide area networks; commerce services. We have talked over the past couple days about digital identifiers and smart cards. Business processes and applications, things such as events and transaction services. These include invoices, payments, inventory management.
The level of electronic exchange in health care will inevitably increase. Therefore, it is important to undertake to secure electronic exchanges to the necessary level to meet our security obligations. Services unique to the health care market include clinical practice management, eligibility and enrollment processes, health care claims and remittances. These unique health care services are currently accomplished by using basic transaction mechanisms.
HL7's SIG Secure provides a comprehensive, although not exhaustive overview of the work being done by ANSI standard development organizations and other entities in the United States and Europe to develop health care and electronic commerce security standards. We propose that security requirements are roughly analogous across the Intranet, Extranet and the Internet, but it has been widespread public attention given to the Internet, which has both raised concerns and accelerated the rate of security technology deployment. The security mechanisms being developed for electronic commerce on the Internet will provide useful solutions for the health care domain.
Implementation definitions for secure HL7 transactions have been the majority of the work done by HL7 SIG Secure. The mechanisms to implement secure HL7 transactions have been identified as data encryption standard or DES, secure socket layer, SSL, secure electronic data interchange over multi-purpose Internet mail extensions or MIME and Pretty Good Privacy or PGP.
Security mechanisms depend on how robust your implementation of the specification is. This stuff is not really that easy. As both Netscape and Microsoft have found out, even the best crypto-programmers money can buy leave implementation holes behind. The industry should support crypto-packages from vendors who are among the best and constantly keep their security products updated as holes are discovered.
The implementation profiles suggested by HL7's secure transactions SIG enable security mechanisms for today's health care environment. Technology mechanisms are dynamic. These profiles, no doubt, will be obsolete shortly after publication. The security profiles for health care environments, as with all environments, will need to be adjusted to incorporate new technology mechanisms. Definitively laying out security requirements for health care systems gives product vendors guidelines to incorporate security mechanisms into their products. An implementation workshop is scheduled for the HL7 January meeting to review detailed secure HL7 transaction implementations.
Of course, we realize that the number one security risk is internal from users with access rights to the very information that is being protected. Robust definition of requirements, services and mechanisms to provide implementation is only one aspect of security. Our efforts are focusing on securing health care transaction not on security policy. Training and policy, although outside the scope of HL7 SIG Secure, is substantial work as well. We feel that collaboration amongst the various health care organizations working on health care security is important. HL7 SIG Secure has developed has developed a glossary of health care security terms in collaborations with the efforts of CPRI.
HL7 Version 3.0 encompasses the definition of a reference information model and a domain information model for health care. The definitions of these models starts with defining use case scenarios. As HL7 models information exchanges in the health care domain, SIG Secure's role will be to provide security use case scenarios for the health care domain as they apply to HL7 Version 3.0 reference models.
The National Research Council report is an excellent start on assessing the issues of security for our industry. However, the industry needs a common ground where people can meet to address issue and define policy. No one standard development organization can cover all aspects of health care security. Security experts from outside the health care domain have asked me personally for a group to target if they are to provide expertise to our industry.
The health care industry needs to address the following policy definitions before HL7 can enable standardization and secure implementation profiles: harmonization on current SDO and PAS security definitions; audit trails and/or audit mechanisms that will be used by regulatory agencies in the health care domain; standardized access control lists and access control matrices; standardized health care role definitions that we can base these access control lists on; EDI messaging profiles that provide practical implementations of secure EDI. This includes the definition of how EDI message wrapping should be defined for health care transactions.
Content modeling of health care information. One area where selective protection might be useful is where different entities sign different portions of a piece of information; for example, the electronic medical record, or different portions are encrypted to different recipients.
The standardization of the electronic medical record will enable appropriate security mechanisms to be enabled.
Definition of a threat model and, most importantly, a trust model; address consistent information system architecture for health care environments; dissemination of information regarding health care security so that the industry may have the opportunity to review and formulate a unified response to security.
The use of strong cryptography is essential in today's electronic world.
I thank you for the opportunity to review the aspects of secure electronic transactions.
DR. LUMPKIN: Thank you.
Mr. Barrett.
MR. BARRETT: Thank you. My name is Lee Barrett and I am executive director of the Electronic Healthcare Network Accreditation Commission or EHNAC. It is a pleasure to appear here on behalf of EHNAC and before the Subcommittee on Health Data Needs, Standards and Security. I would like to thank you for the opportunity to testify.
My statement summarizes the views and the concerns of EHNAC and its accreditation activities as they relate to the health care industry and electronic transactions of health information addressed by the Health Insurance Portability and Accountability Act of 1996.
Let me begin by telling you about EHNAC. With the help of industry work groups, EHNAC establishes clear criteria against which clearinghouse and value-added network performance is measured. The four major areas evaluated include privacy and confidentiality, technical performance, business practices and resources. EHNAC defines its evaluation and accreditation procedures, including different accreditation levels, methods for granting and revoking accreditation, probationary periods and provisional accreditation. These steps are intended to represent full disclosure of the process and rules under which accreditation will operate, giving participants as clear an understanding as possible of the expectations and the process to be undertaken.
The EHNAC accreditation process provides an independent peer evaluation of an organization's ability to perform to certain industry-established criteria. The process allows companies to review their existing performance levels and to bring those levels into accordance with industry-established criteria with the help of the accrediting body and industry mentors.
Accreditation supports continuous improvement of an organization while helping to raise the standards of an industry as a whole, evaluating performance measured against industry-established criteria. It offers a viable alternative to government regulation. The accreditation process and the work of an independent accrediting body protect the interests of the general public while providing a benchmark for prospective users to evaluate service capabilities.
Some of the following comments will address the question is we were asked to discuss, as well as any other issues that could be of concern to the process of accreditation.
The first question was: What standards presently exist regarding security? Well, the following criteria has been established by a committee of over 50 individuals, which represent a very broad-based coalition of value added networks, VANs, and clearinghouses and other interested parties. This set of criteria is presently being reviewed to assure that the use of the Internet, Intranet and other electronic transmission sources are appropriately safeguarded.
Standard 1 is privacy and confidentiality. This addresses really accredited companies having appropriate administrative technical and physical safeguards to ensure the integrity and confidentiality of protected health care information. These safeguards must protect against any anticipated threats or hazards to the security or integrity of such information. Some of the measures then to ensure data security organizations shall have policies to protect against disclosure of personally identifiable health care data. We have a number of examples that we look for as evidence, including things like personnel handbooks, employee privacy and confidentiality agreements, nondisclosure agreements, as some examples.
Second, shall maintain all necessary resources to ensure continuing compliance with data security policies, including secure methods of access to and transmission of data. Again, some of the samples include employee privacy and confidentiality, company policies, employee contracts and nondisclosure agreements.
Three, shall provide educational resources to ensure employee training sufficient to maintain compliance and, again, we look at training program descriptions, general description of password protection procedures and others.
Next, shall use protected health care information about individuals only as is necessary for the processing of appropriate electronic transmissions. Again, we look at very similar levels of documentation and evidence, including general description of password protection procedures.
Next is shall refrain from selling or otherwise using personally identifiable data in such a way as to violate privacy or confidentiality as defined by government standards.
Here, we are looking for samples of evidence, including, again, employee contracts, non-disclosure agreements and a general description of password protection.
Lastly, we have what are called "shoulds," an organization should look to adhere to. This one is should have plans for utilizing or supporting encryption as a security measure in compliance with any legislation requiring it.
The next question dealt with: Are the existing standards adequate for adoption by the Secretary of HHS? EHNAC refers to its process and documentation as criteria, rather than standards. All of these criteria certainly could be adopted by the Secretary with the potential inclusion of some additional forms of documentation, if warranted. As previously indicated, EHNAC is undertaking a review of our existing criteria to assure that Internet, Intranet and other electronic means are included. As other business and industry needs are identified, EHNAC has developed the consensus-based process to address the requirements and assure compliance.
The next question is: What standards must organizations meet to be accredited by your organization? A hundred of the "shalls" that I previously just went through have to be in compliance and 30 percent of those that are in the "should" category need to be complied with.
Some of the areas, again, in general that we have got, we have got four major areas. Criteria 1 is privacy and confidentiality with accredited companies having appropriate administrative, technical and physical safeguards to ensure integrity and confidentiality of protected health care information. These safeguards must protect against any anticipated threats or hazards to the security or integrity of such information.
Next is technical performance and under technical performance, accredited companies must provide their customers the capability to send and receive data transmissions electronically in appropriate formats, while assuring security, privacy and confidentiality, timeliness and accuracy, which includes effective safeguards and recovery procedures against viruses, transmission interruptions, data handling errors and other internally or externally caused problems.
This capability includes compliance with generally accepted industry formats, such as UB92, the national standard format and Accredited Standards Committee X12 and any other government-mandated standards. Electronic Data Interchange or EDI means the computer application-to-application exchange of business data in a standard format, using a telecommunications network.
The next criteria is Criteria III, which is business practices and, again, we are looking at accredited companies having business practices that facilitate the maintenance of the technical performance criteria and must exhibit truth-in-advertising, such as the company must actually be doing what it says it will do for its customers. To qualify in this criteria area, accredited companies must have procedures for measuring customer satisfaction, provide non-restricted systems of access, adequately provide for customer education and training and have standard contract or service agreements.
Lastly, Criteria IV is resources and this is an area in which accredited companies must possess the physical, human and administrative resources necessary to maintain a high level of technical performance and business practices. These resources must include plant and equipment facilities adequate to conduct the company's current and anticipated business volume; qualified professional and staff personnel and professional development programs to keep up with changes in the industry. While resource-related criteria are primarily expressed in terms of inputs, they are required because of their basic role as guarantors of effective outcome performance.
The next question was: What plans are underway to address security requirements? In addition to the criteria we have already established, EHNAC has a standards committee that is comprised of a broad-based coalition of participants from various sectors of the health care industry, who review the current criteria and recommend changes where appropriate. For example, the committee is going to be meeting on August 12th to consider criteria for inclusion to address the Internet including provisions regarding security for this particular medium.
Although the criteria that we have established is stable, the committee is always reviewing the documentation to assure consistency, assure the appropriate levels of coverage, assurance of the business necessity and the information required to achieve compliance.
EHNAC also collaborates with other industry organizations, such as the Association for Electronic Healthcare Transactions, AFECHT, and others to incorporate other business requirements and to educate and increase awareness concerning the HIPPA legislation and the aspects of security and confidentiality.
EHNAC also works with the other standards organizations to assure that their development efforts and requirements are also incorporated, where appropriate.
Do we feel that there is a need for the Federal Government to provide leadership in this area? Yes, absolutely. We feel that the government should be actively involved in industry discussions and assist in some of the following ways:
One, to legislate accreditation of VANs and clearinghouses. This will increase the quality of the industry participant and will reduce the hassle factor for those entities seeking companies, which meet certain standards, similar to those standards that have been established by NCQA and JCAHO.
Second, the development and enhancement of security and confidentiality criteria and standards.
Third is support education and industry programs to increase awareness and understanding.
And, four, actively participate on the committees to assure that Medicare and other governmental business requirements are incorporated.
Support of these initiatives are going to help to assure that the industry is best positioned to incorporate criteria and standards for security and confidentiality. These areas have become critical and will be even more so as patient records and other clinical information get transmitted through multiple sources.
Thank you for the opportunity to present our perspectives on the issues associated with security. EHNAC looks forward to a continued and productive relationship with NCVHS.
DR. LUMPKIN: Ms. Lovorn.
MS. LOVORN: Hi. Good morning.
ASTM wants to thank you for this opportunity to present this testimony for the subcommittee today.
My name is Jan Lovorn and I am here representing the American Society for Testing and Materials, Division II on Security. ASTM is an American National Standards Institute approved standards body, as has been mentioned before. It is one of the largest voluntary consensus standards developers in the United States. It has over 30,000 members.
Membership in ASTM is open to anyone with an interest in the subject addressed by a committee or a subcommittee. All members participate in the development of standards either at meetings, via ballots or both.
ASTM standards work is initiated on the basis of industry need. Security standards were already in development upon passage of the HIPA Act of 1996. Industry had previously identified requirements for confidentiality/privacy of information, integrity of data, user authentication, access control, user authorization and non-repudiation for both health care claims and medical records.
Future development of security standards will be based on the health care industry, including government, doing the identification of requirements and then subsequent requests for standards. Occasionally there have been focus groups developed to gather -- to evaluate industry needs.
Division II includes three subcommittees that have jurisdiction over security-related standards. There is E31.17 on privacy, confidentiality and access is involved in writing standards relating to implementation and policy. E31.20, of which I am char, on data and system security for health information, is involved in writing the technical specifications, i.e., things like digital signatures. E31.22 health information transcription and documentation is involved in the standards related to transcription.
ASTM E31 members have a variety of backgrounds, including health care providers, hospitals, insurance companies, vendors, pharmaceutical industry and, importantly, I think, here, security information professionals that have been doing security in other markets.
The process is one of consensus. A major factor involved in this process for E31 has been the identification of possible common terminology and concept models from both financial and other information systems. The subcommittees, particularly E31.20, have attempted to build on this information security terminology and models as they apply to health care.
This has not been done in a vacuum. This has been done taking what was already there in the outside world in security and bringing the best of that into health care. The subcommittee under the direction of Dr. Rick Peters have tried to develop an internal and core framework on which to build health care information systems.
The criteria used to develop the framework included using existing technology for the core, developing flexible standards to allow vendors and providers solutions and products to decrease cost, evaluating industry standards and developing standards with health care specific requirements only where absolutely necessary and providing for interoperability to allow easier exchange and processing of health care information.
As I said earlier, none of this was done in a vacuum. While health care has some unique security requirements, generally the requirements are similar to what is going on in other markets, particularly like the financial industry and we have attempted to use the best of that.
The ASTM subcommittees have been closely following the standards efforts at ANSI, including X9 and X12 and IETF for the Internet, NIST or some standards on -- which I will get into in a minute, and other health care information standards bodies, such CEN, HL7 and CPRI. ASTM has been working closely with Margaret -- and I am going to try to say her last name correctly -- Amatayukul and Ted Cooper of CPRI, Mary Kratz and Jack Harrington of HL7 and Gary Beatty of X12 in coordination of the standards efforts for a unified approach to security and its implementation.
ASTM also has an ongoing relationship with HCFA in support of the provisions of HIPAA and including Bob Mays and Barbara Clark and will continue to support standards in response to the market requirements.
Two of the health care industry's concerns include unauthorized access to computerized health care information by curiosity seekers and external breach of security by computer hackers. Health care organizations are moving towards integrated delivery systems to include communications, information systems, accounting and billing systems, radiology, medical records, laboratories, was well as remote access to all these systems.
This drive to a computer-based delivery system is based on the need to automate patient records, the demand for comparative outcomes data and to provide decision support for caregivers. There are also business requirements for the use of electronic commerce for payment of claims, as well as ordering and payment for vendors and suppliers. Identification of security requirements to meet these business needs has driven E31 to develop standards for policies and procedures, as well as technical specifications.
The current E31 standards related to security include for E31.17 policy, E1869-97, the Guide for Confidentiality, Privacy, Access and Data Security Principles for Health Information. That is approved. Draft standards include the draft standard specification for audit logs for use in health information systems. All these drafts are going to be out for ballot to the committee at the end of this month.
Draft standard guide for amendments to health information, including computer-based records.
Draft standard guide for training of persons who have access to health information.
And draft standard guide for individual rights regarding health information.
My committee, 31.20, we have one already out there. It is E1762 and that is for authentication of health care information. Particularly, it addresses multiple signatures that may be required on medical records. There is a list of requirements in there that I think is well-stated to tell what needs to be done in the industry.
We have a draft standard guide for Internet and Intranet security. That is getting -- all of these are getting ready to go out to ballot the end of this month. Draft standard specification for authentication of health care information, using digital signatures. A standard guide for user authentication and authorization and draft security guide for a framework for health care information. And we have a new one on data permanence and data recovery that is in draft and that probably will go out for committee review.
For E31.22, we have a standard guide for management of the confidentiality and security of dictation, transcription and transcribed health records. Right now, that is on the main ballot. It is awaiting ASTM approval and assignment of a number.
This is the current list; however, additional standards may be developed based on industry needs and identified requirements. These approved standards are published and available from ASTM. Draft standards will undergo balloting during the fourth quarter of 1997. Barring negative votes requiring revision, the documents will be approved in early 1998 and ready for publication and for implementation.
I have a few copies of the draft standards available for review. Teresa has a copy of -- I think, of everything that I have mentioned that you can look at. We will discuss -- you can obtain the standards from myself or from Teresa. I have listed an address and a phone number.
As an organization, ASTM does not certify or accredit suppliers or other organizations. In hearing some of the discussion earlier, I think that there is some ongoing stuff going on out there in the other security industry that we need to start -- that we are monitoring currently. Generally, certification or accreditation of products is left to contractual agreement. However, there are several validation tests available through NIST for cryptographic modules and digital signatures. ASTM is currently closely monitoring efforts by NIST and by the ANSI X9 committee to develop validation tests for algorithms, such as digital signature, RSA. There is already one out for DES, for triple DES, additional digital signatures. Right now there is one for DSA, but there is not one for RSA or for the new eliptical DSA that is coming out.
For data integrity, this is starting to look at message authentication codes. Cryptographic key exchanges, I have heard that discussed earlier. For your encryption, for digital certificates, this is validation of the processing of your X509 certificates and for key management protocols.
Those are looking to be in place probably the middle of next year, going out to the voluntary labs for accreditation.
Within ASTM, consensus means that all affected parties are involved in the standards development process. This includes participation by the producer, the user and general interest components, which include government and academia. Since government is seeking to adopt standards, it is critical that the government representatives participate in the standards development process and play a leadership role in indicating their needs.
HCFA has been very active in our division on helping us identifying those needs when we have missed some or to expand on them. With industry input, government can perform a leadership role by dispensing information and coordinating the determination of industry needs.
ASTM and E31 is pleased with the current active involvement of various government agencies, AHCPR and HCFA in the standards development process.
I want to thank you again.
Two other things, I want to respond to some discussion I heard this morning. Financial institutions have protected electronic financial transactions successfully for years. It is important to remember that while the timing of doing some of the security is important, most of this is transparent to the user and it does not affect the day-to-day business of how things go on. For on-line, in-line transaction processing, the financial industry have been doing this for years securely and it does not add very much time to the processing of the information, depending on where you place the security and for the need for where you place the security.
I would like to clear up a little confusion that I think I heard earlier. There are four things that I think that we need to remember and one is that any organization needs to do a risk assessment, to identify where the security requirements are and develop a policy and then use the standards as they are out there now to require vendors to provide the mechanisms to meet the policy and that in the implementation of the security mechanisms that this can be applied anywhere.
Well, let me go back to the location of the security. The security can be located at the application or your user level. It can be located at a WAN level. It can be located at the local area network level. It depends on the risk associated with that organization and with that information. In the implementation of the security mechanisms, for example, you may decide that you want to digitally sign things and you can have the user sign it, a care provider, a doctor or a nurse can sign the medical record.
If it needs to be included in a health care claim, then the hospital can digitally sign or someone for the hospital. It depends on where you want and where the requirement is for this, where you need to implement the security mechanisms and how much it is going to affect your processing time and how much it is going to affect your users.
Thank you again.
DR. LUMPKIN: Thank you.
Questions from the committee?
MS. FRAWLEY: Lee, just two questions.
How many VANs and clearinghouses are there in the United States? And then the second question is: How many are accredited by EHNAC?
MR. BARRETT: As far as the number of VANs and clearinghouses, that is changing daily, Kathleen. As far as the total number, I am not sure of what that total number is right now. It is a fairly large number, but as we are seeing with the acquisitions, that is shrinking very rapidly.
As far as the number that we have got accredited, we have a total of six organizations that have gone through that are totally accredited right now. We have got another five that are going through the process right now. So, the self assessment process, as many of you have probably seen a lot of the criteria, it pretty extensive and can take anywhere from three to -- we have seen anywhere from three to eight months for an organization to put together all of the documentation necessary to submit.
MS. FRAWLEY: Just give a ball park, what percentage of the industry is accredited?
MR. BARRETT: Probably less than 10 percent.
DR. LUMPKIN: So, when you say a large number, do you mean large in the hundreds as opposed to large in the thousands?
MR. BARRETT: As far as the number that are out there, the number of clearinghouses and VANs probably between one to two hundred. Again, there is a number of smaller ones that I am not even including in that, but I am talking about in the major category.
DR. LUMPKIN: Kepa.
MR. ZUBELDIA: -- and sometimes we laugh at the numbers but that is pretty much the only source we have. They publish the largest 100 clearinghouses. Clearinghouse No. 1 processes around 50 claims per month. So, to give you an idea, the top ten clearinghouses probably process about 80 percent of the business.
MR. BLAIR: Would you mind just mentioning the names of some of those top ten clearinghouses? And maybe you could indicate which ones of those might be accredited?
MR. ZUBELDIA: Envoy NAIC(?), which is the company I work for.
[Laughter.]
NBC, HBOC, IMS in Fountain Valley, California, Merrick(?) Computer Systems, Memphis, HVX -- basically, the largest clearinghouses are represented in this room also.
MR. BLAIR: Are any of those top ten accredited?
MR. BARRETT: The way it is, Jeff -- it is an interesting question. Several of the specific -- because of the acquisitions that have been going on, okay, what we have not done at this point is accredited, for example, an Envoy Corporation or we have not accredited an NDC Corporation and all of the clearinghouses underneath it. For example, if you look at an Envoy, you have got not only Sanabtech(?), but you have got several others that fall under that whole umbrella.
What we have done is, for example, we have accredited specific companies, clearinghouses, under a particular umbrella, for Envoy. For example, we have got Sanabtech is, in fact, an accredited organization. Another one that falls under that is Professional Office Systems, which is also under that umbrella, but there are several others now that fall under an Envoy umbrella that have not gone through it.
So, what has happened -- and, for example, the same thing with NDC. We have got several companies there that are also under NDC that are under the clearinghouses, under their umbrella, that have gone through the accreditation process. But we are in the process, because of the acquisitions, it is becoming very muddied, especially when people start asking, okay, well, are you part of -- you know, we are Envoy. Well, is Envoy accredited? Well, the answer is "no," only in certain clearinghouse -- or certain clearinghouses are.
In fact, we are talking with the Envoys and we are talking with the NDCs as a corporate entity about looking at corporate-wide accreditation, rather than just -- because it has become very unclear what somebody is looking at in an organization like that.
So, those discussions are going on.
MR. MOORE: I had a question for Dan and Jan. Did I hear you right, Dan --
DR. LUMPKIN: Bob, can you use that little device?
MR. MOORE: Yes.
This concerned the ASTM effort in pulling together the standard organizations. I know you listed off X12 and so forth. Is NCPD included in that?
MS. LOVORN: It has not been up to now.
MR. MOORE: Dan, you had said that you did not recommend or NCPD did not recommend the ASTM security standard?
MR. STANIEC: That is correct. Yes, I have worked with Rick Peters at the Health Informatics Standard Board, participating in some of their meetings, but I have had our membership look at it and, again, with the technology available, we are concerned about the cost. I have been told that there is 15 to 20 thousand dollar cost initially for each pharmacy to include this type of standard, also with a $300 maintenance fee and also the technology to implement that standard.
Again, not to say we don't endorse it, I think we need more time to work with ASTM in either the Health Informatics Standard Board or possibly a joint SDO effort.
MR. MOORE: Well, I think the SDO effort started and maybe NCPD should be becoming a part of it because you are under consideration as one of the major changes in the standard with the claims set being the NCPD pharmacy claim. And security is going to be a big issue in any of the standards that we put out for electronic commerce. If that presents a big problem, then it would have to make us take another look at NCPDP if we couldn't be secure or feels that it is secure in its transmission of data meeting the standard.
So, I am just saying up front this is one of the big considerations and we have talked about this at a variety of meetings. So, we need the -- I just wanted to make -- highlight that to the committee that it becomes a consideration.
MR. STANIEC: Bob, I appreciate your concern, but, again, I have balloted my membership. If there has been any breach of security with the NCPDP standard, over 1,200 members and 210 companies, I have not heard one concern about the security of the NCPDP standard.
The ASTM security standard, again, I am not that familiar with, but, again, just because they are balloting it, working with it, just to plug it into certain areas of health care because it is a security type standard, I think that needs to be revisited.
There are other areas to look at also. Object oriented technology is a possibility. I don't think we should just endorse one standard or one technology at this time because the way the technology moving in the future, I think that, you know, it would obsolete in a matter of years.
So, I think, you know, taking a step back, but just to rest assure to the national committee, our standard is very secure. You can talk to your Medicaid states, Bob. You know, 45 of them use the NCPDP standard and it is very secure.
MS. LOVORN: Bob, he is right. I mean, a lot of things they use, they use dedicated phone lines. The thing is you have to look at a cost benefit ratio. If I start using not dedicated phone lines but switched phone lines and I add security to it, the cost tradeoff may be -- it is okay to go ahead and implement security that way because it will provide a cheaper overall cost.
The thing about security you have to remember is you have to look at what your requirements are. You have to do your risk assessment. You have to do cost benefit, what you are willing to do -- pay for versus what kind of protection you are going to get.
We have tried to look at that as part of -- as ASTM 31.20, to identify those kinds of requirements and say, okay, here is what is going on. ASTM 31.20 has also developed a security framework that has looked at all the industry standards that we can find out there in the information security world and identified those that are applicable to the health care industry. That standard will be available through ASTM.
DR. LUMPKIN: Vince.
DR. MOR: I have two questions, I guess, about a structural definition of "standards." One, I believe, Mary Kratz, you suggested in your recommendation that standardized health care role definitions be developed. Could you explain what you mean? I mean, a doctor is a doctor is a doctor. A nurse is a nurse is a nurse. And, therefore, they are only allowed so much discretion. Is that what is meant?
MS. KRATZ: What is meant, that in order to define security mechanisms, such as using something like an X509 certificate that you can define individual users across the health care domain, but within the domain we have doctors that work at different locations or, perhaps, across different departments. So, he might have a role as a physician but that role might be different for the oncology department as it is for the faculty diagnostic unit. So, he would play a different role depending on where he is practicing within the environment.
DR. MOR: But your recommendation that those be standardized to facilitate transport from organization to organization, is that what you are suggesting?
MS. KRATZ: Yes.
DR. MOR: I always get worried about that because that ends up that there is some regulatory or prescriptive component that ends up altering the way in which organizations might naturally evolve in terms of their clinical processes or ways of doing business. So, I just worry about that level of standardization. I understand that it is always easier to write code if it is structured in.
MS. KRATZ: I think we need some level of standardization over what we have today, which is where every organization is doing things uniquely and perhaps we don't need to get down to a fine level of granularity, but we need some level of standardization.
DR. MOR: The second question pertains to -- Lee Barrett, in your recommendations on the resources side, you have a statement saying that the relationship between inputs and outcome performance is well-established. Is it? I mean, I get back to Bob's question. Are these systems set up in such a way that there is some kind of performance standard so somebody could go in and say let me see if I can attack this and there is some level of rating about your attack vulnerability or -- because you have got a lot of structures built into what the requirements are in the input end for accreditation. They are structural requirements but not necessarily any outcome standards or outcome performance measures.
MR. BARRETT: It is a good question, but, I guess, when I was stating it, the EHNAC accreditation process primarily is focused on the output side. So, the criteria that we have established has been more looking at that whole output side, even though there is -- there is a lot that has been established as far as the input pieces. What we have tried to do is to focus on the outcomes in our criteria and that is what I was trying to say, as far as a relationship between -- because that is really our focus is on the outputs.
DR. MOR: I am sorry. I don't -- I didn't see anything here on outputs or outcomes. Maybe I don't understand this business well enough.
MR. BARRETT: We have got a whole set. What I didn't include in here, but I do have as part of my testimony, is a complete set of all of our criteria and if you looked at all the criteria that we have got, it is specific outcomes based. So, we have got -- the self-assessment process that people go through is very extensive. Primarily, again, it is -- and all the accreditation procedures, if you can look at our self assessment is really outcomes based. That is where we focused.
DR. MOR: But you don't have somebody who sort of would go in like a state inspector and try to sabotage your system or something like that.
MR. BARRETT: No.
DR. MOR: There is nobody who actually tries to do that.
MR. BARRETT: No. The only thing that does occur is once somebody goes through -- not a state inspector, but we have a process that they go through where somebody submits their self-assessment, which goes through all the outputs and then we have a site evaluation that is done by a site evaluator, who goes through and looks at all the criteria to assure that what has been submitted, in fact, can be demonstrated, but it is not at the state level.
DR. MOR: Or even some firm that does it.
MR. BARRETT: No. It is really EHNAC -- EHNAC does that process of the site evaluation as well.
MS. FRAWLEY: Mary and Jan, I would like you to both comment on this. I know, Mary, you were here yesterday and, Jan, you just arrived today. Yesterday afternoon for the first time, the committee heard about a standard X12.58, which having traveled in standards circles for awhile was a big surprise to me and several of my colleagues here at the table.
In talking to Gary Beatty last night from X12, I understand that it is not a standard that is widely disseminated through the industry. So, obviously, before the committee makes a recommendation, I would like to hear from both of you as experts on your assessment of that standard.
MS. KRATZ: I have read the X12.58 standard and it basically defines security as a message wrapping mechanism. I don't feel that the security, as it was written, and I understand that there has been -- it has been updated since last I read it, really addresses secure message wrapping.
Within HL7 we have had discussions where we really feel that there is a three-tiered message wrapping approach that will need to be addressed. One is at the level of perhaps like an operative note for a physician, something that a physician would digitally sign that we want an authentication mechanism there, something at the message level, where an entire report or an entire claim might be getting sent and we would want to authenticate that particular message and then a third level of wrapping, which would be at the organizational level, that the University of Michigan is we send a transaction to our trading partner and want to authenticate that that message is secure as we send it from our organization to our trading partner.
The X12.58, when I last reviewed it, didn't address that.
MS. LOVORN: The X12.58 Version 2, addresses the transaction sets that go within an electronic exchange. It can do encryption. It is a wrapper. You can either put it at each transaction set or you can put it by what they call functional groups. But it only applies to those particular transactions that are being sent. It has nothing to do with -- perhaps if you have included a medical record or part of a medical record insider there, there would have to be separate security that is outside the purveyance of X12 and X12.58, as far as protection is concerned.
It is only designed to protect the transaction sets. The reason that it hasn't been used is because there hasn't been any requirements up to now that it actually be used. I was involved in some of the discussions before Version 2 finally went out and other committee members were. And it matches a lot of what we have set up in the standards that we have doing in E31.20, but it is based on the transaction sets, you know, your 837s and -- I can't remember the other numbers, for your health claims or any other -- for your electronic tax filing or your payer and vendor exchanges.
You can additionally sign each one of the transaction sets or you can sign a group of them or you can sign the whole set of them if you have more than one functional group or more than one transactions. That is all X12.58 addresses.
MS. KRATZ: Can I add one small comment I forgot?
The X.9 subcommittee, which apparently is working in the finance industry is working on addressing this for their industry and they would welcome collaboration with the health care industry. I haven't had time to look at it, but did get an invitation to look through their stuff.
MS. LOVORN: Right. I am on X.9F1, which is cryptographic tools for data transactions and we are looking and an awful lot of things are going on. There has been a lot of, at least in E31.20, in E31 generally, there has been a lot of cross fertilization with what is going on in the industry right now to make sure that we are in step with them and that we don't want to get out of step with them, to allow providers and vendors to come up with solutions that are cost effective, that may be able to be used across more than one industry, so that you can have scalability and, you know, the cost is associated with selling more of one product, by having particular options that could be set based on what industry or market that you are using.
MR. BLAIR: In some of the other testimony and here today, we have heard what appears to be a growing consensus on the need to approach this whole issue in terms of making an assessment of the security risks that a particular organization has. From there, you wind up saying you draw up the policies that are appropriate to address those risks and exposures and threats and from there you begin to look at what standards or technologies would help you address that as you go to the particular vendors.
Like I say, it seems as if there seems to be -- I haven't done a poll, but a large number of folks seem to feel like that is the approach we should take. The question I have on that particular approach is as we begin to have more and more networks, if we use that approach, do we run the risk of having particular health care institutions or particular private networks or even individuals working on the Internet adopt a bunch of policies appropriate for their institutions, which technologically are incompatible in terms of either authentication or encryption with other institutions? And if so, how do we address that?
MS. LOVORN: We have attempted to look at that as far as the requirements, for example, in E1762. We have attempted to look at that in E31.20, particularly with the standard E1762, which looks like authentication of health care information, to set up a set of requirements. One of the requirements is requiring interoperability, to be able to do that and that if you are going to be interoperable with other people and you follow this standard, these are the things you need to do.
Remembering that, depending on whether something is a closed system and you are only exchanging information within your own organization, requirements are different because we can't go in there and say this is how you have to do it. All we can say is once you decide to exchange information with somebody else, to do it successfully and be able to read it and handle it at both ends, here are the things you need to do.
MR. BLAIR: So, we do have --
MS. LOVORN: That issue has been looked at and there are requirements and we have set that up and all the E31.20 standards is to allow for interoperability.
MR. BLAIR: So, you feel -- I guess maybe I am still groping here. You are saying you have looked at the issue and you have asked folks to consider interoperability. How far down do we need to get to achieve interoperability? Because from what I understanding there is a number of different encryption technologies and I don't know if they are compatible.
MS. LOVORN: If you use things like X509 certificates for some of this, you signal the other end with what you are doing and you can send keys protected in a way such that they can decrypt at the other end, as long as you are signalling what it is and you send them way of obtaining a key.
MS. KRATZ: I am not sure if I understand the specifics of your question, Jeff, but my experience in my travels through CorbaMed(?), I discovered that the Mitre Corporation has a threat model taxonomy that the Corba Security Services have used to define -- we had some talk yesterday about the Orange Book and the definitions that are defined in that, which was published in 1985.
Many of the cryptographers that I have run across in my travels basically say that the Corka Security Services are what we can expect to see in the future of technology and that the Orange Book will basically be obsolete because it was written before the advent of distributed systems.
So, in reviewing the threat model taxonomy in the Corba Security Services, I see robust definitions that policy could be adopted and appropriate and take us in to the future.
MS. LOVORN: In fact, the United States and the European Community are looking at identifying a common set. They are calling it the common criteria to replace the Orange Book or instead of having it set up as one particular model, it allows you to pick which level of security you might want, for example, for confidentiality and for data authentication and you can pick which level your system needs. It allows for a modular development of a system. It is designed to make it much easier for organizations to decide how much security they really need.
DR. LUMPKIN: I think I have a concern as I am trying to synthesize what we have been hearing over the last day and a half. First of all, my major concern is that we don't confuse simplification, which is the title of the section, with standardization because you can standardize, which will not simplify the process.
As we are trying to get our arms around the security issue, we have been hearing from the various sectors that we should not adopt a single standard for security, but rather should be looking at the requirements and the guidelines and procedures. How does that play out in the one or the two physician office, who participates in multiple health plans? And if they adopt different methodologies of achieving these guidelines and procedures, does that make it simpler for that individual practitioner or does it, in fact, make it more complex if we are not more specific in what we are doing?
MR. BARRETT: Can I give a perspective?
DR. LUMPKIN: Please.
MR. BARRETT: I think your example is a good one. I think, if I looked at it from the standpoint of the physician out there and I looked at from having a variety of different standards, I guess it comes down to what I have also heard being here this morning is that it comes down to what is the risk, the risk assessment? I think what Jeff was saying is true. There is a risk assessment. What is the risk?
Based upon the risk, though, and based upon the policies that are determined by, say, this committee or the industry, I think that if we are going to put certain policies in place, then we also need to have certain standards recommended. Otherwise, you are going to be in the position where you have got just that situation, where you are going to have a couple of different physicians that might have a variety of different approaches, a proprietary and some other standardized approach. I think it can increase the amount of hassle, the hassle factor, out there for the physicians that we are trying to, in fact, minimize.
And I think it just -- it is going to cause a lot more ambiguity, rather than to come up with some minimal -- if the policy is we are going to put a level of security into the systems, then I think a certain level of standards need to also be recommended to set a threshold. I heard the conversation before. It really talked about a threshold and setting some minimal threshold. If a minimal threshold is to be established, I think there should be a minimal set of standards also.
Otherwise, I think it just causes that much more confusion in the industry, an industry that is already suffering from tremendous confusion. So, the more we can do to minimize some of that, the better.
MS. KRATZ: I have an answer to your question.
My answer to your question, to simplify and to standardize for primary care physicians in rural settings, for instance, is Internet, Internet, Internet. Twenty-five bucks to get an America-on-Line connection, launch a Web browser. If we can do electronic commerce and put credit card numbers on the Internet, why don't we feel that a health care claim would be secure?
DR. LUMPKIN: I think Jeff had his hand up first. Did you want to respond, Jeff, or a different question?
MR. BLAIR: I am kind of expanding -- I know that the folks from ASTM and HL7 and CPRI have all been working together. So, forgive me if I am asking things that you have already covered. You may have already been working on some of these.
Mary, you mentioned the fact that within the HL7 Security SIG, you are trying to key a lot of this security risks and threats and policies to the use cases, which makes an awful lot of sense and for those folks who have not been to HL7 meetings, one of the things that they are trying to do is a lot of modeling and it is derived from use cases so that they could wind up applying information systems models to as close to real world scenarios as they can.
When I heard that, I mentally started to tie together the use cases you had with Kathleen's comment that you all have been working on some security frameworks where in different scenarios, you could come up with different thresholds. I am tying that to the comment yesterday, where they said give us thresholds, give us minimums, but it is hard to do unless you think of it in certain scenarios.
Is this what all of you are figuring will tie together the use cases, the frameworks, so that we could have thresholds?
MS. KRATZ: I think the answer to that is "yes." HL7, the small working group that has addressed the white paper, looked at the ASTM framework and thought that it was reasonable to adopt and in our upcoming working group meeting, we will address that with the larger group. And we see a very good tie between collaborating amongst the different efforts.
I personally also see the need for a joint work group on health care security, as Dan suggested, and have proposed to Rick Peters that the ANSI HISB be given that proposal at their next meeting and that, perhaps, that might be the appropriate group to perform the harmonization.
MS. LOVORN: And I agree. I mean, that is what we thought we do, was the use cases would drive, you know, okay, insurance companies may do it this way or they will -- for example, if I sign up say with Aetna PPO, then they are going to have some policy and, hopefully, it is common enough across Aetna and some of the others because it would be to their benefit and then the provider, the small provider like you are talking about, either can log on to do the things, using the Internet connection or they can just send it out, for example, even to a clearinghouse and let them handle it and split it out however way it needs to go.
There are several different scenarios of how some of this stuff can be done. I think what you are talking about is the case users, like what HL7 is looking at some of these scenarios and then tying in the standards to meet the requirements of that scenario.
MR. BARRETT: Jeff, it is Lee. I guess, based upon the standards efforts, I think HISB is probably a good forum since all the SDOs are there. And I would agree with what Dan is suggesting, is that we take the scenarios, we take what standards are out there and we come up -- have an opportunity to have that group come up with some specific thresholds if there are going to be thresholds that will be determined. But that may be the best forum to at least get all of us together as we all have been working together to address this particular issue.
MR. STANIEC: As I stated earlier, Jeff -- this is Dan Staniec -- I think the security threshold is a great idea, again, working through HISB. As a matter of fact, we do have Rick Peters speaking from ASTM at an educational forum. I apologize. I don't want to give you a plug, but we have other speakers, Simon and Bill, and, you know, the NCPDP membership is very interested about security and, you know, Rick has been sending me e-mail messages about it, but, obviously, not one SDO can handle this and we certainly will cooperate with organizations with HISB. I think that is an excellent function for HISB to take on that endeavor.
MR. BLAIR: Just jumping ahead as I listen to you here, if those use cases -- those use cases may not have included the pharmacy section scenario environment. If so, then that would allow us to wind up recognizing a level of risk or the lack of level of risk within the pharmaceutical transactions that would be appropriate for that.
The other piece would be do the use cases also reflect evaluated networks and clearinghouses because we can wind up -- what you are saying is within HISB we could pull this altogether and expand those use cases so that we will cover all of health care. Yes?
PARTICIPANT: It is at least a forum, I guess, to do that.
MS. LOVORN: I agree. This is Jan.
MS. FRAWLEY: Following back up on John's question before about his two providers with multiple health plans, we heard from vendors yesterday afternoon and again this morning about their different concerns in terms of the committee's recommendations. While I was sitting here, I realize that the hospital I used to work at, we had ten different applications and many of the vendors are sitting in this room and, obviously, the concern about that if everybody goes off and does their own thing, I am sitting back in a hospital. You know, how do I deal with the fact that I have got ten different systems that aren't interoperable? Some are legacy systems. Some are network-based. And, you know, I am now sitting there trying to manage, you know, the administrative, the financial, the clinical information systems and provide user access.
So, I would like to just let anyone on the panel weigh in. Any thoughts there?
MS. KRATZ: As I had this discussion with a number of cryptography folks, they said for the health care industry to really address interoperability in a secure fashion, we need to do what the finance industry did and that was to agree to some basic architectural requirements and from that we can have a security reference model that will enable our industry to securely transact.
MS. LOVORN: I agree.
MR. BARRETT: I think it comes back to, we have got to have a base set of what that criteria is because if we don't have a base set, the whole issue comes down to that -- and your scenario is going to continue to repeat, where you have got hospitals, whether it is a hospital or it is a physician office -- and I go into them all the time, where they have got anywhere from two to ten different terminals to submit to different payers. Can that continue? The answer is "no."
So, there has got to be some level set that -- so that we get to some base level of standards that are going to be used. Otherwise, we continue to proliferate a proprietary set and we are going to continue to have the ten different inputs that any one of these entities is going to use. So, I think that is why we have got to -- we have got to look at some way of setting some level of threshold if we are going to go and put in -- you know, start to look at the whole security issue and start putting in, mandating what we are going to do.
We have got to have those. Otherwise, it is going to continue to proliferate.
MS. FRAWLEY: I have one more question. This is directed to Dan.
The National Research Council study committee, one of the concerns that the committee identified and did meet with was pharmacy benefit management companies, who are receiving individually identifiable information and in turn passing that back along to employers. So, I do know that some of your constituents come from pharmacy benefit programs.
So, I guess, kind of following up on Bob's point earlier, I guess one of the things that we need an assurance from is the fact that, you know, organizations are going to be responsible in the handling of individually identifiable health information. While it may not necessarily go to the level of a technical standard, you know, that there has to be again some baseline policies and procedures in place, information security awareness programs and so forth.
I think that was probably one of the most troubling things to the NRC study committee, was what we saw and what companies showed us in terms of actual computer printouts going back to employers. So, I just raise that. You know, you don't necessarily need to respond, but, again, just a concern.
MR. STANIEC: I appreciate that, Kathleen. I did talk to several of the largest PBMs in the country prior to my testimony, talking about their policies and procedures. And they do have those in place.
Now, again, I know a lot of pharmaceutical companies may receive information from pharmacies, but, again, that is not patient identifiable. When we are talking patient identifiable, I agree with you, there has to be some level of security to maintain confidentiality of that patient.
DR. LUMPKIN: Well, thank you very much.
At this point we are going to conclude the hearing portion of our meeting, but we have one other comment. Thank you, Kepa, for reminding me. Kepa had a clarification that we were going to get on the discussion at the end of the last panel and then after that, we will break for lunch.
MR. ZUBELDIA: Yes. This is a clarification to a question that Jeff asked, on the use of encryption by clearinghouses and VANs. We believe, strongly believe, that the lease line that works, that the private virtual circuits that we use today, do not necessitate encryption. When they said that encryption should be used, that is for Internet use but not on private networks. We have not seen breaches of security through private networks or even dial-up networks.
Also, I want to clarify the distinction between VANs and clearinghouses. VANs will be able to deal perfectly well with encrypted data end to end because VANs do not get into the envelope. They don't look at the data. They don't know whether it is encrypted or not. So, it shouldn't matter doing encryptions with VANs.
However, clearinghouses will have to decrypt the data, verify signatures, reencrypt and re-sign. So, the overhead for clearinghouse and VANs is totally different and the needs for both are totally different.
DR. LUMPKIN: Let me clarify what -- so, for a system that uses a dedicated line or a dial-up, you are not suggesting -- you are suggesting that the data does not require encryption but encryption would only be required for use of the Internet?
MR. ZUBELDIA: For use of open networks, such as the Internet.
DR. LUMPKIN: Thank you.
We will reconvene at 1:30.
[Whereupon, at 12:02 p.m., the meeting was recessed, to reconvene at 1:42 p.m., the same afternoon, Wednesday, August 6, 1997.]