File Manager 22.2 Security & Privacy Manual

Contents > Chapter 6

Chapter 6: Best Practices

Strictly speaking, the material in this chapter is out of scope for a user manual on Fileman. However, your security interactions with Fileman will be driven by a larger set of security procedures, protocols, and regulations, so we felt it was worthwhile to discuss them here. Besides, in creating this manual, we had the assistance of a knowledgeable and experienced VA Information Security Officer, and we decided to take advantage of it.

Your Security Manual (You Do Have One, Right?)

To begin with, you should have a security manual. If your facility is part of a larger organization, such as VA or IHS, you may have a security manual from a national or central office, describing the organization’s overall rules and procedures. That isn’t the security manual we’re talking about.

Your security manual should be specific to your facility. A centrally-produced manual would, for example, talk about physical access to the facility and how entrances can be controlled. But only your security manual could say, for example, that the Emergency entrance on Oak Street is open 24/7. Or that the west entrance is open during clinic hours, and accessible via key-card at other times. And so on.

Your security manual should include the names and contact information of the Security officer, the Privacy officer, and senior managers. It should also include any security-related procedures and protocols developed for your facility. In this manual, we have often said “you should have a process to do such-and-such.” Your security manual is where you keep these processes.

Think back to when you first started your job as the Security officer at this facility. What are the five things you wish somebody had told you sooner? Make sure those things are in the security manual. Can you think of five more things? Make sure those are in the security manual, too. (Although if one of your five things is, “I wish somebody had told me where to find the darned security manual,” you’ll need a different solution.)

Your Privacy Manual

Patient privacy is related to system security, but it is a separate issue. And, as more facilities convert from paper to electronic records, it is an issue of growing importance. You should view patient privacy as its own area of concern. The Security officer and the Privacy officer should be two different jobs, done by two different people (unless the facility is very small). And of course, the Privacy officer should have their own manual.

Like the security manual, the privacy manual should include the names and contact information of the Security officer, the Privacy officer, and senior managers. It should also include any privacy related protocols and procedures developed for your facility. Privacy officers should also do the exercise where they ask themselves about five things they wish they’d known sooner, and include those in the manual.

As with the security manual, a “national” privacy manual, or one from a central authority, won’t have enough detail for you to use at your facility. You need your own privacy manual that includes the specifics of your location.

Your Daily Checklist

A system manager, whose job is to keep a computer system up and running, typically has a daily routine of checks to perform. The checks tell the system manager things like how many users are logging into the system, how much memory is left, how many errors have been generated, and so on. The checks help the system manager identify potential problem areas before they blossom into massive problems.

You, too, should have a daily checklist of tasks you perform to check on the security and privacy of your facility’s VISTA system. For example, you might make it a daily practice to run an audit on the PATIENT file, or some portion of it. You might use the “monitor a user” option to see what a specific user has been up to. And of course, you want to follow up on any security- or privacy related alerts or notifications you received through the system.


So, when we say “run an audit on the PATIENT” file, do we mean that you have to look at every transaction that happened yesterday? Not at all. A much better idea is to look closely at a small sample of the data.

There are a few reasons for this. First, it is a much better use of your time. You have other things to do with your day; you can’t spend it all looking at yesterday’s audits. Second, you are most interested in problems that are widespread, and a widespread problem has a pretty good chance of showing up in a sample. And finally, you will be more alert and watchful with just a handful of audits than you would be if you tried to look at everything.

Therefore, to audit the PATIENT file, use the Print File Entries option as described in Chapter 4, but only look at a small chunk of the data (maybe an hour’s worth). Scan the data, and choose two or three transactions that you find interesting, for whatever reason. Examine these transactions in more detail, until you understand them. What was changed, who made the change, and why? Don’t be afraid to ask questions so you can understand the transactions.

Aside from the PATIENT file, other files that might be worth sampling include PAID EMPLOYEE, NEW PERSON, OPTION, KEY, TITLE, and DG SECURITY LOG. The last of these, DG SECURITY LOG, is part of VISTA’s Registration package. More information on the file can be found in the Registration documentation suite.

Learning What Is Usual

A very important aspect of examining small samples of data is that you will learn what kinds of things are routine. As you become familiar with the kinds of transactions you are seeing, you will begin picking transactions that are “interesting” because they are out of the norm. You increase your chances of finding problems by becoming more familiar with what is to be expected.

Tracking Access

As we have discussed elsewhere, you should be kept apprised of any changes to users’ levels of access. You should have a place where user access is tracked, possibly with your audit log, possibly in a file all its own.

It is not necessary for the Security officer to be part of the process for granting or changing access. Your facility can include you or not, as fits best with their overall operating strategy. Whether you are included or not, however, you do need to be notified of any changes to security access. It is especially important for you to be notified if a user’s access has to be terminated.

You should revisit this list from time to time and make sure that the information you have is up to date, and that the access listed is still needed.

Tracking Local Files

Once your VISTA system has been up and running for a while, the odds are pretty good that your local programmers will begin adding files to the system. We outlined some reasons for this in the “Extracting” section of Chapter 5, but there are many reasons your facility might want to create its own files.

Your facility should have a procedure for how new files are created, and that procedure should include making a record of who created the file, what it is to be used for, and who should have access to it. You should receive copies of all this information, so you can keep track of local files, especially those with security or privacy implications.