For the purposes of this document, a remote site is defined as a site that remotely connects to and accesses a centralized electronic database to enter and store surveillance data even though paper forms may be stored locally. The central database is located in a different physical location than the remote site and usually in a different city. A satellite location is defined as a site that collects and electronically enters surveillance data in a local database and then sends the electronic data file to a central location. If remote and satellite sites maintain case report forms or other surveillance information with personal identifiers, the central location should not be maintaining duplicate copies of the case report forms. Surveillance staff should discourage providers from maintaining duplicate copies of HIV/AIDS case reports after they have been reported to the health department.

The statewide HIV/AIDS case database should be housed in only one location (excluding electronic backups and replication for disaster recovery); however, as states with multiple database locations move to more centralized operations, the number of satellite locations within a state should be kept to a minimum, thereby keeping the data collection and storage as centralized as possible. If the system is decentralized, each remote and satellite site should maintain only cases within that site's jurisdiction, and must meet the same physical security requirements discussed in section Physical Security.

If, after discussing a records retention schedule, program staff decide to retain the hard copy case report form even after the record is entered into the reporting system, they should consider removing or striking out the name on the report before storage. The state patient number would still provide linkage, when necessary, to the name in the reporting system while improving record security. This practice would decrease (1) the number of places where names are stored, (2) the amount of time they are held, and (3) the number of persons who may have access to them in the future.

Security software that controls the storage, removal, and use of data maintained in the reporting system should be in place at all locations where the electronic surveillance data are maintained. Security software may include such protections as user identifications, passwords, boot protection, encryption algorithms, and digital signatures. Additionally, an area may maintain names outside of the reporting system and use a state ID number to link name and surveillance information when needed.

Data Movement

Requirement 19 Surveillance information must have personal identifiers removed (an analysis dataset) if taken out of the secured area or accessed from an unsecured area. (GP-1)

Requirement 20 An analysis dataset must be held securely by using protective software (i.e., software that controls the storage, removal, and use of the data). (GP-1)

Requirement 21 Data transfers and methods for data collection must be approved by the ORP and incorporate the use of access controls. Confidential surveillance data or information must be encrypted before electronic transfer. Ancillary databases or other electronic files used by surveillance also need to be encrypted when not in use. (GP-1)

Electronic files stored for use by authorized surveillance staff should be encrypted until they are actually needed. If these files are needed outside of the secure area, real-time encryption or an equivalent method of protection is required.

This requirement also applies in those situations where surveillance data are obtained electronically from external sources (clinical data management systems and laboratories) or as part of a separate health department data collection system (Careware for example). Extracts from those systems need to be protected as if they were extracts from the surveillance data system. Additionally, those systems within the health department need to be held to the same standards as the HIV/AIDS surveillance systems. External agencies are to be encouraged to review their procedures, and approved data transfer methods need to be used.

Requirement 22 When case-specific information is electronically transmitted, any transmission that does not incorporate the use of an encryption package meeting the Advanced Encryption Standard (AES) encryption standards and approved by the ORP must not contain identifying information or use terms easily associated with HIV/AIDS. The terms HIV or AIDS, or specific behavioral information must not appear anywhere in the context of the communication, including the sender and/or recipient address and label. (GP-2)

The intent of this requirement is to eliminate the possibility that a third party may identify a person as being a member of an HIV risk factor group or HIV infected. For example, when trying to locate an HIV-infected person during an NIR (No Identified Risk) investigation or interview, do not send letters or leave business cards or voice messages at the person's residence that include any terminology that could be associated with HIV, AIDS, or the health department. These precautions need to be taken in case a family member or friend discovers the letter or card or hears the voice message. Similarly, if a third party calls the telephone number listed on a card or letter, that party should not be able to determine by a phone greeting that it is an HIV/AIDS surveillance unit (or the health department); nor should a third party be able to obtain that information by pretending to be the case patient. This may require the use of some confirmation mechanism to assure that the person calling really is the case patient and not someone pretending to be that person to discover confidential information. For additional information on confidential interview techniques, you may request CDC interview guidelines by contacting your CDC program consultant.

If secure fax or encrypted e-mail transmissions are used at all (although CDC strongly discourages their use), care must be taken to avoid linking HIV or risk factor status with identifiable information about a person. This may include ensuring that the terms HIV or AIDS do not appear in the fine print at the very top of a fax indicating who sent it and that these terms do not appear in more obvious locations in the letterhead and body of the fax. Other important steps include thinking about who else besides the intended recipient may have access to faxes on the receiving end and the possibility of misdialing the fax number or using the incorrect e-mail address.

Requirement 23 When identifying information is taken from secured areas and included on line lists or supporting notes, in either electronic or hard copy format, these documents must contain only the minimum amount of information necessary for completing a given task and, where possible, must be coded to disguise any information that could easily be associated with HIV or AIDS. (GP-1)

One purpose of this requirement is to make it difficult to link an individual's name on a line list with HIV/AIDS should that line list fall into the hands of an unauthorized person. Terms that could be associated with HIV/AIDS include CD4 count or opportunistic infection (OI). Programs should consider using less recognizable terms, codes, or abbreviations such as T-lymphocyte count or OI. In some circumstances, just the word "count" may suffice. While risk factor information (e.g., injection drug use or sexual orientation) may not necessarily be associated with HIV/AIDS, it nevertheless is highly sensitive. Wherever possible, risk factor categories must be coded to help minimize the possibility of a breach. A coding scheme for transmission category is already built into the reporting system and should be used when there is a need to generate line lists with risk factor categories. When surveillance staff write notes, they should make it a habit to use these risk factor codes. For example, instead of using the phrase injection drug user or the readily decipherable abbreviation IDU, a code could be substituted.

This requirement applies to information or data taken from secure areas. It does not refer to data collected from the field and taken to secure areas. While coding of terms associated with HIV/AIDS in the field is encouraged, there may be occasions when it cannot be done, for example, when uncoded terminology must be abstracted from a medical chart on a No Identified Risk case during the course of an investigation.

Requirement 24 Surveillance information with personal identifiers must not be taken to private residences unless specific documented permission is received from the surveillance coordinator. (GP-1)

Under exceptional circumstances, HIV/AIDS surveillance information with personal identifiers may be taken to private residences without approval if an unforeseen situation arises that would make returning to the surveillance office impossible or unsafe. For example, if a worker carrying sensitive information were caught in a sudden heavy snowstorm, driving home instead of returning to the office would be permissible provided the worker's supervisor is notified (or an attempt was made to notify the supervisor) of the need to return home with the sensitive information. Precautions should be taken at the worker's home to protect the information under such circumstances. All completed, or partially completed, paper case report forms should be transported in a locked satchel or briefcase.

Managing field time effectively can be accomplished by using a variety of creative tactics. Field visits should be scheduled in the most efficient way possible. One option is to assign provider sites to workers by geographic area. For example, all providers in the east sector could be covered by the same worker to minimize travel time between sites. Another option might be to schedule visits so that sites located far from the office receive visits early in the day with staff working their way back to the office by the end of the day. A flextime schedule is another option that a site may wish to consider.

If returning to the secured area creates significant inefficiencies in case surveillance investigations, alternative methods of securing sensitive surveillance information could be considered when developing the policy that satisfies this requirement. Investigators could incorporate the use of pre-addressed, stamped envelopes and drop completed case report forms in the mail before returning home for the day. Tampering with the mail is a felony, and case reports are considered better protected in the mail than at a private residence. This possibility should be accounted for when developing the mail policy discussed in Requirement 9.

Some areas do not complete case report forms on-site, but take notes using shorthand that is not easily translated and does not contain HIV-related terms. Notes such as these could be stored in less secure areas because someone seeing the notes would not understand their meaning. When this method is used, blank case report forms or other HIV-related materials should not be stored at the same location as the notes. Staff using this technique may carry the notes around discreetly (e.g., in a purse or notebook) and then complete official forms when they return to the surveillance office. Other methods to disguise the data, de-identify it, or separate sensitive variables from it could be used to eliminate the need to return to the office at the close of business (i.e., if personal identifiers are removed using approved methods, the information is less sensitive and may be secured off-site). Whatever methods are used, the approved method must be described in the local security policy.

Requirement 25 Prior approval must be obtained from the surveillance coordinator when planned business travel precludes the return of surveillance information with personal identifiers to the secured area by the close of business on the same day. (GP-1)

Policies and procedures for gaining prior approval for not returning surveillance information with personal identifiers to the secured area at the close of each business should be implemented. Refer to the discussion following Requirement 24 for additional considerations.

Back to top

Sending Data to CDC

CDC's policy requires encryption when any moderately or highly sensitive files, any moderately or highly critical information, or any limited access/proprietary information is to be transmitted to or from CDC either electronically or physically. All data that meet these criteria must be encrypted using the Advanced Encryption Standard (AES). See Attachment C for details describing federal encryption standards. Currently, CDC requires that this category of electronic data be sent via its Secure Data Network (SDN). Future considerations may include sending data using the Public Health Information Network Messaging System (PHIN MS). The SDN uses digital certificate technology to create a Secure Sockets Layer (SSL) or encrypted tunnel through which data are transmitted. The SSL is broken once the client browser loses connectivity with the CDC Web server, which is located outside of its firewall.

To protect sensitive data once the SSL is broken and as they move between various CDC servers, CDC requires that sensitive data be encrypted with a product that meets federal standards. To support that requirement, CDC can provide users with a free CDC-produced, Java-based software called SEAL. Some CDC programs will also accept files encrypted with commercially available products. A site must coordinate efforts with CDC if the site wishes to use a commercially available encryption product. Any commercially available product selected must meet federal AES standards.

Note: The HIV/AIDS Reporting System (HARS) transfer files are output with a 40-bit encryption algorithm that does not meet the standards. Therefore, HARS files must be encrypted before being sent to CDC via the SDN. The e-HARS transfer files are output with a 1024-bit SEAL encrypted algorithm that does meet the standards, and, therefore, no additional encryption will be necessary before sending to CDC.

Back to top

Transferring Data between Sites

Many sites have a need to move data within a state or between states. If these data meet the criteria described in the previous topic, Sending Data to CDC, CDC strongly recommends that these data be encrypted. CDC has no mechanism in place to support non-CDC transfers. The sending and receiving sites must agree on the product that will be used for that purpose and identify the method of transfer. CDC will provide, upon request, the full version of the SEAL software; however, SEAL is a Java-based application that is executed within a DOS shell. SEAL does not have a graphical user interface (GUI). Many inexpensive, commercially available, easier to use, object-oriented software products are available for purchase. Additionally, a site may wish to consider the PHIN MS for point-to-point encryption and movement of data. For more details regarding PHIN MS, refer to the Web site http://www.cdc.gov/phin/activities/standards/messaging-
transport.html.

Back to top