President’s Information Technology Advisory Committee 

(PITAC) 

Orlando, February 25, 2004 

Peabody Hotel 

The Internet Security Policy of CMS 

Kepa Zubeldia, M.D. 

President & CEO 

Claredi 

498 N 900 West, Suite 120 

Kaysville, UT 84037 
Members of the Committee, thank you for the opportunity to present a brief summary of a very 

important issue that is costing our industry tremendous resources and getting in the way of a fast, 

inexpensive and secure deployment of electronic communications in healthcare. 

In early October 1997, in the beginning of the Internet explosion, the HCFA Regional Office for 

Region II sent the attached letter to its Medicare contractors. The letter states that due to the lack 

of acceptable encryption mechanisms, the Internet is not to be used for transmission of 

individually identifiable information. This was, at the time, the only written policy for use of the 

Internet coming from HCFA. 

As soon as this letter was sent by Region II, the HCFA Central Office, with assistance from 

industry representatives from AFEHCT, started working on an Internet Security Policy. The 

Internet Security Policy was published by HCFA Central Office on November 24, 1998. I have 

attached the Internet Security Policy as well as a facsimile of the cover letter that was sent with 

the Internet Security Policy to the Medicare contractors. 

The Internet Security Policy allows the use of the Internet by private commercial entities and 

Medicare contractors as long as the specified security mechanisms and Notice of Intent 

requirements are met. While the Internet Security Policy is permissive and allows the use of the 

Internet, the cover letter contains language that specifically forbids the use of the Internet by 

Medicare contractors for Medicare transactions. 

Since the Internet Security Policy was published, the position from CMS has changed. The 

written policy requires any person (not only Medicare contractors) that desires to use the Internet 

for HCFA “sensitive” information to communicate such intent to a specified HCFA e-mail 

address. This is not a request for approval to use the Internet, but only a notice of intent to use 

the Internet. When the Internet Security Policy was first announced, HCFA presented this 

requirement as permissive, without the expectation of a reply to the notice of intent. 

The current “unwritten policy” from CMS is that before using the Internet for individually 

identifiable information about any Medicare beneficiary, the potential user, whether a Medicare 

contractor or a private enterprise, must submit a request to CMS, including a security plan, and 

wait for approval from CMS. This is contrary to the written Internet Security Policy, and, as of 

this date, CMS has not approved any such requests for using the Internet for HIPAA 

transactions or other PHI. 

In fact, even the new CMS Contract for Eligibility Network Service Providers (found in the 

CMS manual) permits the use of the Internet between the provider and the commercial 

clearinghouse designated as Eligibility Network Service Provider, but prohibits the use of the 

Internet between the Eligibility Network Service Provider and CMS Carrier or FI. Now, CMS is 

saying that the Internet may not be used in any point of the communication network when 

transmitting CMS originated PHI, and the use of the Internet no matter where it is deployed in a 

network architecture is prohibited. However, this restraint is not documented anywhere by 

CMS. 

This situation is intolerable. The only approved methods of transmission to Medicare Carriers 
and Intermediaries is via magnetic media, direct point-to-point dial-up (e.g., X/Y/Zmodem, 

Kermit, Bisync RJE) or leased lines. These transmission mechanisms are slow, expensive, and 

prone to errors. In addition, the nature of direct point-to-point dial-up or leased lines forces them 

to be of a hub-and-spoke configuration, with the Medicare contractor as the hub and the 

providers as the spokes. This centralized architecture, and the primitive communication methods, 

are impeding the development of a generalized communications architecture that can support the 

NHII. 

With the recent activity around the Medicare prescription cards, CMS has again asserted the 

need for leased lines between the prescription card issuers and CMS, disallowing the use of the 

Internet. 

In order for the USA to adopt a Health Information Infrastructure that allows the exchange of 

clinical and administrative information, the use of the Internet, with adequate security, becomes 

necessary. Using the primitive dial-up system in a hub and spoke environment will prevent the 

deployment of any Health Information Infrastructure. 

This committee should make the recommendation that CMS must: 1) allow the use of the 

Internet in accordance with the security requirements in CMS’ written Internet Security Policy; 

2) not require a prior authorization, but use a permissive notice of intent, as described in the 

Internet Security Policy; and 3) require that the Medicare contractors implement standard 

communication mechanisms appropriate for the HIPAA transactions over the Internet. In 

addition, as any new communication requirements are defined by CMS, such as requirements for 

NCPDP transactions, prescriptions, eligibility, etc., there must be at least one communication 

option that uses the Internet, in addition to whatever other communication options CMS may 

specify with point-to-point dial-up or leased lines. 

As CMS opens the use of the Internet for health information, in accordance to CMS’ own 

Internet Security Policy, the rest of the industry will accept its use and enable the 

communications systems necessary for the deployment of a National Health Information 

Infrastructure. 

I want to thank the Committee for its attention to this very urgent matter. 
REGIONAL OFFICE HMO/CMP LETTER # 97-11 

TO: ALL REGION II HMOs/CMPs 

SUBJECT: Use of Internet Technology Involving Beneficiary Identifiable Information 

Reply Requested by October 10, 1997 - ACTION 

The purpose of this bulletin is to outline HCFA policies and expectations concerning the use of 

Internet technology involving beneficiary identifiable information. It also reminds plans that any 

member and product outreach marketing materials must be approved by the HCFA Regional 

Office prior to release on the Internet. 

In an effort to decrease administrative costs and provide customer friendly services, many plans 

and insurers have taken advantage of technology for many administrative functions, such as 

claim submissions, eligibility inquiries, and claim status inquiries. Traditionally, electronic data 

interchange (EDI) has been employed for these functions, using both batch and interactive 

transactions. 

The increasing use of the Internet promotes potential opportunities for functions currently 

limited to EDI. However, the open communication environment of the Internet presents many 

security issues. 

Privacy Act provisions apply to any record in a “systems of records” that is retrievable by an 

individual’s name, social security number or other personal identifier. “Other personal 

identifier” includes any new identifier assigned by the plan to designate a member. Any 

personally identifiable and confidential information must be properly protected from disclosure 

and be made available only to approved staff on a “need-to-know” basis. The Privacy Act 

protects information maintained in hard copy and electronic formats. 

HCFA Information Systems Security Officers have determined that acceptable encryption 

mechanisms are not currently available for Internet use to insure the degree of privacy HCFA, 

plans, and contractors are required to maintain. This determination does not include internal 

networks with dedicated communication lines (e.g., a T1 line) which are secured from external 

access. Therefore, individually identifiable information may not be made available 

through the Internet or any internal environment which is not secured from external users.

As a result, any activities using the Internet or an unsecured internal network where the 

plan provides individual information must cease immediately. Prohibited activities include, 

but are not limited to, claim/encounter submission, claim status inquiries/responses, eligibility 

inquiries/responses, remittance notification, and individual utilization information. The above 

activities may take place on secured and dedicated communication lines on a “need-to-know” 

basis. 
Page 2 - 

Please submit, to the attention of Mitchell Croll of my staff, a summary of any activities you 

engage in using the Internet or externally accessible systems. If you have “dial-up” systems that 

do not use secured, dedicated communication lines, please include a summary of activities using 

these systems, as well. The summary should include not only administrative activities 

mentioned above, but also any member and product outreach, which is subject to review as 

marketing materials prior to release. 

The prohibition of Internet use is not intended to decrease administrative savings available using 

EDI. Plans are encouraged to utilize EDI to reduce administrative costs and increase efficiency. 

 Final regulations regarding the standardization of EDI transactions are due out no later than 

February 1998. These regulations are being promulgated under the authority of subtitle F of the 

Health Insurance Portability and Accountability Act (HIPAA) of 1996 and will impact all 

insurers and all lines of business. If you need further information regarding the standardization 

requirements defined in HIPAA, there are many Internet resources. Please see the attachment to 

this bulletin for more information regarding HIPAA and EDI standardization activities. 

If technological advances are achieved that will provide the proper level of security, HCFA will 

readdress its policy related to the use of the Internet and internal networks. We will notify plans 

of any future policy changes regarding the use of the Internet, as well as the status of regulations 

regarding EDI. 

Please call Mitchell Croll (212) 264 - 2668, if you have any questions regarding the use of the 

Internet or EDI standardization activities. 

\S\ 

Gail Weinreb 

Director 

Health Plans Branch 

Attachment 

bcc: RO Systems Security Coordinators, RO I-X 

RO Lead Managed Care Contacts, RO I-X 

Dick Golliday, OIS 

Jarrett Hicks, CHPP 

Yolanda Robinson, CHPP 

 Rason Taru, OIS 
All questions should be addressed to Bill Pollak, (410) 786-3018, wpollak@hcfa.gov. 

A talking-point paper describing highlights of the new policy has also been attached to this 

memorandum.

In summation, the policy does away with the restriction on use of the Internet, but does not give

organizations the authority to begin utilizing this media without obtaining full coordination and 

approval from all parties in the communication process, making allowances for software and/or

hardware upgrades or changes, and notifying HCFA of their intent.

At this time, Medicare health transactions (e.g., claims and remittance advices) between

providers and intermediaries/carriers are not to be transmitted over the Internet. Implementation

issues remain to be resolved for such transmissions and we will be providing further guidance in

the near future.

2 Attachments 

 Gary G. Christoph, 

Ph.D. 

It is important to recognize that while the policy document is "permisive" in nature, i.e., it allows

the Internet to be used in a manner that had been prohibited in the past, it does not allow this 

utilization without a significant degree of planning and coordination by parties desiring to utilize 

the Internet. For example, paragraph 8 of the policy requires that all organizations subject to 

OMB Circular A-130 "modify their Security Plan to detail the methodologies and protective 

measures" that will be used for transmittal and to "adequately test implemented measures." 

Clearly this will require a specific planning effort. There are also a number of financial, technical 

and contractual implications that must be considered. Some organizations will have start-up 

costs associated with hardware and/or software; others may need to work out certain trading

partner agreements, etc.

The new HCFA Internet Security Policy has now been finalized (attached). It will become part

of the HCFA Information Systems Security Program Handbook. This new policy establishes the 

basic security requirements that must be addressed to transmit HCFA Privacy Act-protected

and/or other sensitive HCFA information over the Internet.

TO All Center/Office Directors

 HCFA Press Office 

All Regional Administrators 

FROM Director

Office of Information Services

SUBJECT HCFA Internet Security Policy

 Health Care

Financing Administration

HCFA

 Memorandum
HCFA INTERNET SECURITY POLICY 

DATE OF ISSUANCE: November 24, 1998 

SUBJECT: Internet Communications Security and Appropriate Use Policy and 

Guidelines for HCFA Privacy Act-protected and other Sensitive HCFA Information. 

1. Purpose. 

This bulletin formalizes the policy and guidelines for the security and appropriate use of 

the Internet to transmit HCFA Privacy Act-protected and other sensitive HCFA 

information. 

2. Effective Date. 

This bulletin is effective as of the date of issuance. 

3. Expiration Date. 

This bulletin remains in effect until superseded or canceled. 

4. Introduction. 

The Internet is the fastest growing telecommunications medium in our history. This 

growth and the easy access it affords has significantly enhanced the opportunity to use 

advanced information technology for both the public and private sectors. It provides 

unprecedented opportunities for interaction and data sharing among health care providers, 

HCFA contractors, HCFA components, State agencies acting as HCFA agents, Medicare 

and Medicaid beneficiaries, and researchers. However, the advantages provided by the 

Internet come with a significantly greater element of risk to the confidentiality and 

integrity of information. The very nature of the Internet communication mechanisms 

means that security risks cannot be totally eliminated. Up to now, because of these 

security risks and the need to research security requirements vis-a-vis the Internet, HCFA 

has prohibited the use of the Internet for the transmission of all HCFA Privacy Actprotected and other sensitive HCFA information by its components and 

Medicare/Medicaid partners, as well as other entities authorized to use this data. 

The Privacy Act of 1974 mandates that federal information systems must protect the 

confidentiality of individually identifiable data. Section 5 U.S.C. 552a (e) (10) of the 

Act is very clear; federal systems must: "...establish appropriate administrative, technical, 

and physical safeguards to insure the security and confidentiality of records and to protect 

against any anticipated threats or hazards to their security or integrity which could result 

in substantial harm, embarrassment, inconvenience, or unfairness to any individual on 

whom information is maintained." One of HCFA's primary responsibilities is to assure 

the security of the Privacy Act-protected and other sensitive information it collects, 

produces, and disseminates in the course of conducting its operations. HCFA views this 
responsibility as a covenant with its beneficiaries, personnel, and health care providers. 

This responsibility is also assumed by HCFA's contractors, State agencies acting as 

HCFA agents, other government organizations, as well as any entity that has been 

authorized access to HCFA information resources as a party to a Data Release Agreement 

with HCFA. 

However, HCFA is also aware that there is a growing demand for use of the Internet for 

inexpensive transmission of Privacy Act-protected and other sensitive information. 

HCFA has a responsibility to accommodate this desire as long as it can be assured that 

proper steps are being taken to maintain an acceptable level of security for the 

information involved. 

This issuance is intended to establish the basic security requirements that must be 

addressed for use of the Internet to transmit HCFA Privacy Act-protected and/or other 

sensitive HCFA information. 

The term "HCFA Privacy Act-protected Data and other sensitive HCFA information" is 

used throughout this document. This phrase refers to data which, if disclosed, could 

result in harm to the agency or individual persons. Examples include: 

• All individually identifiable data held in systems of records. Also included are 

automated systems of records subject to the Privacy Act, which contain 

information that meets the qualifications for Exemption 6 of the Freedom of 

Information Act; i.e., for which unauthorized disclosure would constitute a 

"clearly unwarranted invasion of personal privacy" likely to lead to specific 

detrimental consequences for the individual in terms of financial, employment, 

medical, psychological, or social standing. 

• Payment information that is used to authorize or make cash payments to 

individuals or organizations. These data are usually stored in production 

application files and systems, and include benefits information, such as that found 

at the Social Security Administration (SSA), and payroll information. Such 

information also includes databases that the user has the authority and capability 

to use and/or alter. As modification of such records could cause an improper 

payment, these records must be adequately protected. 

• Proprietary information that has value in and of itself and which must be 

protected from unauthorized disclosure. 

• Computerized correspondence and documents that are considered highly sensitive 

and/or critical to an organization and which must be protected from unauthorized 

alteration and/or premature disclosure. 

5. Policy. 

This Guide establishes the fundamental rules and systems security requirements for the 
use of the Internet to transmit HCFA Privacy Act-protected and other sensitive HCFA 

information collected, maintained, and disseminated by HCFA, its contractors, and 

agents. 

It is permissible to use the Internet for transmission of HCFA Privacy Act-protected 

and/or other sensitive HCFA information, as long as an acceptable method of encryption 

is utilized to provide for confidentiality and integrity of this data, and that authentication 

or identification procedures are employed to assure that both the sender and recipient of 

the data are known to each other and are authorized to receive and decrypt such 

information. Detailed guidance is provided below in item 7. 

6. Scope. 

This policy covers all systems or processes which use the Internet, or interface with the 

Internet, to transmit HCFA Privacy Act-protected and/or other sensitive HCFA 

information, including Virtual Private Network (VPN) and tunneling implementations 

over the Internet. Non-Internet Medicare/Medicaid data communications processes (e.g., 

use of private or value added networks) are not changed or affected by the Internet 

Policy. 

This policy covers Internet data transmission only. It does not cover local data-at-rest 

or local host or network protections. Sensitive data-at-rest must still be protected by all 

necessary measures, in conformity with the guidelines/rules which govern the entity's 

possession of the data. Entities must use due diligence in exercising this responsibility. 

Local site networks must also be protected against attack and penetration from the 

Internet with the use of firewalls and other protections. Such protective measures are 

outside the scope of this document, but are essential to providing adequate local security 

for data and the local networks and ADP systems which support it. 

7. Acceptable Methods. 

HCFA Privacy Act-protected and/or other sensitive HCFA information sent over the 

Internet must be accessed only by authorized parties. Technologies that allow users to 

prove they are who they say they are (authentication or identification) and the organized 

scrambling of data (encryption) to avoid inappropriate disclosure or modification must 

be used to insure that data travels safely over the Internet and is only disclosed to 

authorized parties. Encryption must be at a sufficient level of security to protect against 

the cipher being readily broken and the data compromised. The length of the key and the 

quality of the encryption framework and algorithm must be increased over time as new 

weaknesses are discovered and processing power increases. 

User authentication or identification must be coupled with the encryption and data 

transmission processes to be certain that confidential data is delivered only to authorized 

parties. There are a number of effective means for authentication or identification which 
are sufficiently trustworthy to be used, including both in-band authentication and out-ofband identification methods. Passwords may be sent over the Internet only when 

encrypted. 

(footnote) 1 We note that the Health Insurance Portability and Accountability Act of 

1966 (HIPAA) calls for stringent security protection for electronic health information 

both while maintained and while in transmission. The proposed Security Standard called 

for by HIPAA was published in the Federal Register on August 12, 1998. The public 

had until Octber 13, 1998, to comment on the proposed regulation. Based on public 

comments, a final regulation is planned for late 1999. Policy guidance contained in this 

bulletin is consistent with the proposed HIPAA security requirements. 

ENCRYPTION MODELS AND APPROACHES

Figure 1 depicts three generalized configurations of connectivity to the Internet. The 

generic model is not intended to be a literal mirror of the actual Internet interface 

configuration, but is intended to show that the encryption process takes place prior to 

information being presented to the Internet for transmission, and the decryption process 

after reception from the Internet. A large organization would be very likely to have the 

Internet Server/Gateway on their premises while a small organization would likely have 

only the Internet Client, e.g., a browser, on premises with the Internet Server at an 

Internet Service Provider (ISP). The Small User and Large User examples offer a more 

detailed depiction of the functional relationships involved. 

The Encryption/Decryption process depicted graphically represents a number of different 

approaches. This process could involve encryption of files prior to transmittal, or it could 

be implemented through hardware or software functionality. The diagram does not 

intend to dictate how the process is to be accomplished, only that it must take place prior 

to introduction to the Internet. The "Boundary" on the diagrams represents the point at 

which security control passes from the local user. It lies on the user side of the Internet 

Server and may be at a local site or at an Internet Service Provider depending upon the 

configuration. 

FIGURE 1: INTERNET COMMUNICATIONS EXAMPLES in PDF.

Acceptable Approaches to Internet Usage 

The method(s) employed by all users of HCFA Privacy Act-protected and/or other 

sensitive HCFA information must come under one of the approaches to encryption and at 

least one of the authentication or identification approaches. The use of multiple 

authentication or identification approaches is also permissible. These approaches are as 

generic as possible and as open to specific implementations as possible, to provide 

maximum user flexibility within the allowable limits of security and manageability. 

Note the distinction that is made between the processes of "authentication" and 

"identification". In this Internet Policy, the terms "Authentication" and "Identification" 
Encryption/

Decryption

Process

Internet

Client

Internet

Server

ISP

Inte

Clie

BOUNDARY

Internet

Server at

an ISP

Inte

Clie

BOUNDARY Internet Server ISP

Internet

BOUNDARY

SMALL ORGANIZAT

LARGE ORGANIZA

GENERIC MODEL

Internet Service Provider

(ISP)

Note: 

b

Local Site

FIGURE 1: INTERNET COMMUNICATIONS EXAMPLES
are used in the following sense. They should not be interpreted as terms of art from any 

other source. Authentication refers to generally automated and formalized methods of 

establishing the authorized nature of a communications partner over the Internet 

communications data channel itself, generally called an "in-band process." Identification 

refers to less formal methods of establishing the authorized nature of a communications 

partner, which are usually manual, involve human interaction, and do not use the Internet 

data channel itself, but another "out-of-band" path such as the telephone or US mail. 

The listed approaches provide encryption and authentication/identification techniques 

which are acceptable for use in safeguarding HCFA Privacy Act-protected and/or other 

sensitive HCFA information when it is transmitted over the Internet. 

In summary, a complete Internet communications implementation must include adequate 

encryption, employment of authentication or identification of communications partners, 

and a management scheme to incorporate effective password/key management systems. 

ACCEPTABLE ENCRYPTION APPROACHES

Note: As of November 1998, a level of encryption protection equivalent to that provided 

by an algorithm such as Triple 56 bit DES (defined as 112 bit equivalent) for symmetric 

encryption, 1024 bit algorithms for asymmetric systems, and 160 bits for the emerging 

Elliptical Curve systems is recognized by HCFA as minimally acceptable. HCFA 

reserves the right to increase these minimum levels when deemed necessary by advances 

in techniques and capabilities associated with the processes used by attackers to break 

encryption (for example, a brute-force exhaustive search). 

HARDWARE-BASED ENCRYPTION: 

1. Hardware encryptors - While likely to be reserved for the largest traffic volumes 

to a very limited number of Internet sites, such symmetric password "private" key 

devices (such as link encryptors) are acceptable. 

SOFTWARE-BASED ENCRYPTION: 

2. Secure Sockets Layer (SSL) (Sometimes referred to as Transport Layer Security - 

TLS) implementations - At a minimum SSL level of Version 3.0, standard 

commercial implementations of PKI, or some variation thereof, implemented in 

the Secure Sockets Layer are acceptable. 

3. S-MIME - Standard commercial implementations of encryption in the e-mail 

layer are acceptable. 

4. In-stream - Encryption implementations in the transport layer, such as pre-agreed 

passwords, are acceptable. 
5. Offline - Encryption/decryption of files at the user sites before entering the data 

communications process is acceptable. These encrypted files would then be 

attached to or enveloped (tunneled) within an unencrypted header and/or 

transmission. 

ACCEPTABLE AUTHENTICATION APPROACHES

AUTHENTICATION (This function is accomplished over the Internet, and is referred to 

as an "in-band" process.) 

1. Formal Certificate Authority-based use of digital certificates is acceptable. 

2. Locally managed digital certificates are acceptable, providing all parties to the 

communication are covered by the certificates. 

3. Self-authentication, as in internal control of symmetric "private" keys, is 

acceptable. 

4. Tokens or "smart cards" are acceptable for authentication. In-band tokens involve 

overall network control of the token database for all parties. 

ACCEPTABLE IDENTIFICATION APPROACHES

IDENTIFICATION ( The process of identification takes place outside of the Internet 

connection and is referred to as an "out-of-band" process.) 

1. Telephonic identification of users and/or password exchange is acceptable. 

2. Exchange of passwords and identities by U.S. Certified Mail is acceptable. 

3. Exchange of passwords and identities by bonded messenger is acceptable. 

4. Direct personal contact exchange of passwords and identities between users is 

acceptable. 

5. Tokens or "smart cards" are acceptable for identification. Out-of-band tokens 

involve local control of the token databases with the local authenticated server 

vouching for specific local users. 

8. REQUIREMENTS AND AUDITS 

Each organization that uses the Internet to transmit HCFA Privacy Act-protected and/or 

other sensitive HCFA information will be expected to meet the stated requirements set 

forth in this document. 
All organizations subject to OMB Circular A-130 are required to have a Security Plan. 

All such organizations must modify their Security Plan to detail the methodologies and 

protective measures if they decide to use the Internet for transmittal of HCFA Privacy 

Act-protected and/or other sensitive HCFA information, and to adequately test 

implemented measures. 

HCFA reserves the right to audit any organization's implementation of, and/or adherence 

to the requirements, as stated in this policy. This includes the right to require that any 

organization utilizing the Internet for transmission of HCFA Privacy Act-protected and/or 

other sensitive information submit documentation to demonstrate that they meet these 

requirements. 

9. Acknowledgment of Intent. 

Organizations desiring to use the Internet for transmittal of HCFA Privacy Act-protected 

and/or other sensitive HCFA information must notify HCFA of this intent. An e-mail 

address is provided below to be used for this acknowledgment. An acknowledgment 

must include the following information: 

Name of Organization 

Address of Organization 

Type/Nature of Information being transmitted 

Name of Contact (e.g., CIO or accountable official) 

Contact's telephone number and e-mail address 

For submission of acknowledgment of intent, send an e-mail to: 

internetsecurity@cms.hhs.gov. Internal HCFA elements must proceed through the usual 

HCFA system and project development process. 

10. Point of Contact. 

For questions or comment, write to: 

Office of Information Services, HCFA 

Security and Standards Group 

Division of HCFA Enterprise Standards -Internet 

7500 Security Boulevard 

Baltimore, MD 21244