File Manager 22.2 Security & Privacy Manual

Contents > Chapter 5

Chapter 5: Other Security Issues

In the first four chapters, we discussed the major issues that arise when discussing security and patient privacy in VISTA: user access, file access, and auditing. In this chapter, we briefly describe some other issues to be aware of.


To keep the database at a reasonable size, your facility may periodically archive some of the records. Archived records are still available in case they are needed, but they are stored in another computer system, or on disk, or printed out in physical files, so that they aren’t taking up space in the system.

An archive is not a backup. A backup is a copy of the entire system, while an archive is a collection of specific records—usually older records—that will probably not be needed anytime soon. Your facility should run backups frequently, but should only archive records a few times a year.

Archiving should be done in accordance with your facility’s overall data-retention strategy. And, unless your facility is exceptionally small, you as the Security officer will not be doing it yourself. You therefore need to have a general idea of how archiving works, and you should be notified whenever it takes place, but you do not need to know in detail how to archive.

In brief, archiving records means extracting a set of records, saving them elsewhere, then deleting the records from the main system. This has security implications in that the archived information needs to be stored securely. Your facility should have policies in place that describe how this is to be managed. If you do not have these policies, you need to draft some and get them approved. Once you have policies in place, part of your role as Security officer is to ensure that the policies are followed.

At present, there is no de-archive tool available for Fileman. Because of the way the archived data is structured, it is possible for a Fileman programmer to write a program for the specific data that needs to be reinserted into the database. However, it is best to limit your archiving activity to records you’re pretty sure you aren’t going to need again.

Complete information on how to archive records can be found in the Fileman 22.2 Advanced User Manual.


Fileman includes an extract tool, which allows super-users to copy a specific set of data from one file into another. This tool is often used to create sets of stable data for studies or analyses. For example, a super-user may want to run some kind of statistical analysis on patient data. To run her analysis, she may decide to extract copies of the records she is interested in, and save the copies to a new file. That way, she can run her analysis on the copied information, rather than trying to run it in the main database, which could tie up the system.

Often, when super-users extract data, they want to store the extracted data in a new file, created for the project they are working on. This can be handled in one of two ways.

You can give your super-users the ability to create their own files, using file numbers not currently in use by your VISTA system. You do this from the File Access Security submenu, as discussed in Chapter 3. (For a complete description of how to use the File Access Security options, please see the Kernel documentation suite.) When super-users create their own files, they automatically have access to the new files, and can proceed with their project. This method has the advantage of minimizing the time that the IT department has to spend creating and modifying files. Its disadvantages is that it’s more difficult to monitor what the super-users are doing.

The alternative method is to require super-users to ask the IT department to create files for them. When files are created in this way, the IT programmer also needs to remember to give the super user access to the new file. The advantage for this method is that it is easier to oversee the super users, and ensure that they are only creating files that are needed. The main disadvantage is that the IT department has to free up programmer time to respond to these requests.

Extracting is the kind of thing that makes life stressful for Security officers. On the one hand, you’d really rather not let the data go anywhere. On the other hand, your super-users are going to need to extract and examine subsets of data in order to do their jobs and keep the facility running smoothly.

Your facility should have a process for extracting data, and that process should include notifying you that the extraction has taken place. Make sure that your super-users understand and follow the process. Part of this may include making sure that the process isn’t too difficult or time-consuming to follow. People are less likely to take shortcuts if they can do it the “right” way in a reasonable amount of time. Review your process, and make sure that all the steps really are necessary for security.

Complete information on the extract tool can be found in the Fileman 22.2 Advanced User Manual.


A filegram is a data format, which can be used to transfer a record from one computer system to another. For example, a veteran who receives medical benefits through VA might visit a VA clinic in another city. That clinic could send the record of the veteran’s visit to their home clinic by creating and sending a filegram (or, more likely, a small group of filegrams).

Filegrams are created by programmers using special Fileman tools. Once created, a filegram can be e-mailed to the appropriate facility. Once it has arrived at the facility, a system manager can use other tools to incorporate the filegram into the appropriate record in that facility’s VISTA system.

There are, of course, security and privacy implications to this process. When patient information is emailed, it needs to be encrypted and emailed securely. Before the system manager installs the filegram, they should check to ensure that it came from a known source, and that it has not been tampered with.

Your facility should have procedures for creating, sending, receiving, and installing filegrams. You as the Security or Privacy officer should work to ensure that these procedures are followed at all times.

Important Files

Fileman, of course, manages thousands of files. A few of these files are important enough to merit special attention:

File Name File Number Global
Data Dictionary 0 ^DD
DD AUDIT File 0.6 ^DDA
FILE File 1 ^DIC
AUDIT File 1.1 ^DIA
USER File 3 ^DIC(3)
NEW PERSON File 200 ^VA(200)

Many of these files have already been discussed. The AUDIT file and the DD AUDIT file store information on data audits and data-dictionary audits, respectively. The data dictionary itself is where files and fields are defined. Note that although almost everyone calls it the “data dictionary,” its name for itself is the ATTRIBUTE file.

The FILE file lists all the files currently in the system, with the exception of the data dictionary. The explanation for this is a little technical, but the gist of it is that by giving it a file number of 0, the Fileman developers “hid” the data dictionary from the FILE file.

Originally, the USER file was where each user’s Fileman Access Codes were stored. At the time of this writing, only IHS is still using the USER file for this purpose, although it’s possible an organization or facility new to VISTA could choose to do it this way as well.

Most sites keep Fileman Access Codes in the NEW PERSON file. For facilities using Kernel’s File Access-by-User, that information is stored in the NEW PERSON file as well. Some sites have dispensed with the USER file altogether, and store all the relevant information in the NEW PERSON file.