July 31, 1997

The Honorable Donna E. Shalala
Secretary
Department of Health and Human Services
200 Independence Avenue, SW
Washington, DC 20201-0004

Dear Secretary Shalala:

The Association For Electronic Health Care Transactions (AFEHCT) is a trade association of:

AFEHCT formed a security work group to explore the issues specific to this area as addressed in the Health Insurance Portability and Accountability Act of 1996. We’ve enjoyed working with the members of HHS and HCFA who have attended our meetings and have developed a mutually productive relationship. We expect and hope to continue this relationship into the future.

After a number of meetings, the AFEHCT security work group has identified a number of concerns we hope that HCFA and HHS will take into consideration as they formulate policy for the security of individually identifiable health care information:

1. In adopting regulations, it is important to be mindful of the difference between privacy and security.

Too often, these terms are used interchangeably when, in fact, security is the means or methods employed to assure privacy. The task before the Secretary is to adopt security regulations, at a time when the definition of privacy is still being developed or considered.

Absent a clear definition of privacy, a sensible course would be to define security guidelines that focus on (a) the threat or risk to health care information, and (b) the desired outcome or result of such protection, rather than on any particular technology.

2. AFEHCT is concerned that the input received by the Department is strongly biased towards the electronic medical records community.

In the development of the Administrative Simplification provisions of HIPAA, provisions regarding electronic medical records were specifically and cognitively excluded. Therefore the Department's efforts to focus the scope of the security regulations on accommodating the needs of the electronic medical records community is (a) premature, (b) goes beyond the intent of the law, and (c) goes beyond the spirit of the law.

EDI in the health care financial and administrative transaction community is far different from EDI in the electronic medical record community. Developing security regulations with a paramount focus on electronic medical records may result in regulations that are in part and unintentionally hostile to the electronic transaction community which is statutorily a primary focus of the regulations.

3. There seems to be an assumption that clearinghouses will disappear once standard transactions are in place. That belief is not supported by the facts and is not widely held by industry experts.

The clearinghouse functionality is clearly defined within the healthcare industry. It provides much more than simple connectivity. Additional features include network management, payer interface relationships, translation services, vendor certification, etc. Even if all providers began using the adopted standard transaction formats immediately, there would still be a strong, long-term market demand for clearinghouses, if for no other reason than to reduce the number of "provider-payer" relationships or connections that any one provider or payer would be required to manage.

A provider might reasonably be expected to have direct relationships with the 15, 20 or even 30 payers most common in their geographic area. But it would be unreasonable to expect that same provider to establish a new, direct connection to a payer in another part of the country when they happen, however infrequently, to encounter a patient with that coverage. The same would be true for the insurance plan or payer who currently manages connections to thousands of providers and does not wish that number to increase by thousands.

Without clearinghouses, providers would be required to establish trading partner agreements and electronic connections with some portion of the 400 payers, 5,000 hospitals, and 50,000 pharmacies in the United States — the total could be more than 52 million trading partner relationships! (And this number doesn’t even include the thousands of third-party administrators and direct employer payers of self-insured benefit plans.) In contrast, clearinghouses reduce these relationships to under 200,000, one for each participant dealing with the clearinghouse of choice.

4. For health care transactions, a critical business process issue is to support, not inhibit, the ability of clearinghouses to create efficiencies in the marketplace -- a role already recognized in HIPAA.

The clearinghouses fulfill a need that is (a) in the public interest, (b) driven by the market needs of the health care community, and (c) already self-regulated. This is a proven business model that has already accomplished great efficiencies for both providers and payers.

The clearinghouses provide functions that are crucial for supporting electronic transmission of health care information: reformatting transactions into standard data formats, error checking, editing, aggregating, distributing and routing transactions, and producing management and analysis reports. To perform these functions, the clearinghouses "open the transaction envelope" for routing and switching purposes yet ensure security and integrity of the data through administrative procedures, technical tools, and contractual agreements — all of which could be certified by the industry-established accreditation authority; the Electronic Healthcare Network Accreditation Commission (EHNAC.)

Some of these transactions could, perhaps, be supported without clearinghouses, but only with significant decreases in efficiency and increases in cost to both providers and payers. Coordination of benefits, for example, would become extremely costly to administer, if it could be done at all, without clearinghouses. Several of the transactions that are named in the HIPAA legislation, in reality, require a clearinghouse if they are to be done in a real-time mode, particularly the eligibility, referral and claim status transactions.

5. To support efficient and secure transfer of health care transactions, a "chain of trust" is established as transactions flow from provider to payer.

In many cases, multiple clearinghouses are involved as transactions flow from provider to payer. This process has developed and been driven by the needs of the market, in which it is more effective — both administratively and technically — for a clearinghouse to forward certain claims to another clearinghouse rather than creating yet another independent connection with yet another payer. Not only is this process efficient, it enables effective communication, transmission, and interoperability across disparate provider and payer systems.

The "chain of trust" is established by the trading partner contracts between providers and clearinghouses, and between clearinghouses themselves. This is "trust" in the data contents and the identity of the parties. Each clearinghouse certifies, secures, and is responsible for its link in the chain.

6. Whatever the form of the security regulations or standards that may be adopted, they should define the desired outcome, not the technical means for accomplishing it.

As a matter of business practicality if not public policy, it is far better to let the marketplace determine and select methodologies — from among the many that may work — to assure that the required level of security is provided.

A good example of defining outcome, not technology, is found in the HCFA EDI Support Document (Subsection 2.3 EDI Enrollment Form.) It states, in part, "The Provider agrees… that it will use sufficient security procedures to ensure that all transmissions of documents are authorized and protect all beneficiary-specific data from improper access."

Another area which lends itself to a definition of outcome versus methodology concerns encryption. It may be appropriate technology when sending transactions over an open network such as the Internet, but encryption is deemed unnecessary when sending transactions over a secure, hard-wired (leased line) connection or an 800 number to a private secure host. Moreover, a specific encryption technology (e.g., SSL) would be appropriate for certain systems, but would not operate in non-TCP/IP environments.

Whatever security requirements are eventually adopted, they must support the interoperability that exists today between providers, VANs, clearinghouses, and payers, all of which communicate in spite of different system architectures, network topologies, and operating systems. This further underscores the need for outcome-based, not technology-based, security requirements.

7. It must be recognized that security requirements, depending on their final form, could have the most impact on the provider community.

Although individual providers, small group practices, and hospitals are increasingly using electronic transactions, a very high proportion are doing so with older, less technically capable systems. Several industry studies have found that less than 25% have Windows-capable computers and most of those are used for word processing or auxiliary functions rather than for practice management. The situation in pharmacies is similar, but in addition there’s a significant percentage of users which still use outdated point-of-sale terminals that cannot support encryption technologies as easily as a PC.

Requiring providers to meet a security requirement would be an acceptable policy, forcing them to adopt a particular technology would not. For providers, the cost of compliance with a specific technical standard, were one to be adopted, could be staggering, forcing some providers to go back to paper-based transactions. If and when required, encryption should be defined only in terms of the desired result, not in terms of the technologies (hardware or software products) used to implement it.

8. Although HIPAA contemplates and provides sanctions for security violations, both the "violation" and the "sanction" need to be defined.

It is essential to define what constitutes a violation, and how sanctions would be applied. Absent a pattern or practice of neglect or abuse, it would be unreasonable to apply a penalty to each transaction in a batch, for example, but this needs to be clarified. Since batches can contain thousands of transactions, maximum penalty levels may need to be defined.

9. Penalties or sanctions should be applied only at the point where the violation occurs; there should be a cap on the penalties that can be applied.

In the "chain of trust," it is necessary to define the point where the violation occurs (whether provider office, clearinghouse, etc.) as the point where the sanction would be applied. Since each provider or clearinghouse is responsible only for its own link in the chain, each would only be responsible for violations within their purview.

Penalties or sanctions, applied unconditionally from the point of transmission to the point of receipt, will unfairly increase the liability to the industry and discourage participation ultimately putting the clearinghouses out of business or turning them away from the business. Yet it is, and has been, the clearinghouses that have been the key enablers of electronic commerce within the healthcare industry.

* * * * *

We have enjoyed working with your staff and look forward to continuing our work with you and your staff on these important issues in the future.

Respectfully submitted,

ASSOCIATION FOR ELECTRONIC HEALTH CARE TRANSACTIONS

Board of Directors

Advantis/IBM Global Network, Denny Blaszczynski
Avicenna Systems Corp., Patrick Kennedy, Executive VP, Marketing & Sales
Blue Cross of California/Wellpoint, Tom Scheibler
Electronic Data Systems Corp., Faye Baggiano, Ph.D.
Envoy Corporation, Kepa Zubeldia, MD, Vice President
HBO & Company, Carolyn Haupert, Vice President
Medic Computer Systems, Larry Watkins, EDI Coordinator
MedE America, Mitchell Diamond, Sr. Vice President
National Data Corporation, Rebecca Cowling, Director Government Sales
Pragmatix, William Abram, President
Sterling Commerce, John Thurow, Director Health Care Industry
The Centris Group, Inc., Ed Jones, Vice President
The Health Information Network Connection, Benjamin Curtis, Vice President
The Halley Exchange, a Company of Medaphis Corp., Tom Hanks, Vice President

Additional Security Work Group Members

Electronic Data Systems Corp., Jim Klein
Envoy Corporation, David Westhorp
HBO & Company, Chuck Meyer, Informatics Standards Liason
IVANS, Mark Bayless, Manager Health Services
National Data Corporation, Jeanne Schulte Scott, Director Gov’t & Legal Affairs
MedE America, David Zimmerman, Vice President Operations & Systems

cc:
Bill Braithwaite, HHS
Barbara Clark, HCFA
Mike Fitzmaurice, AHCPR
Bob Gignilliat, HHS
John Parmagiani, HCFA