File Manager 22.2 Security & Privacy Manual

Contents > Chapter 2

Chapter 2: Fileman Access Codes

If your system has not implemented File Access-by-User, your access to files, fields, and templates will be regulated by which Fileman Access Codes each user has, and what codes have been assigned to those files, fields, or templates. Specifically, each user’s Fileman Access Code is stored in a special variable, which is never supposed to be erased. (If it is, you get to yell at somebody, although you may have to get in line.) The name of the variable is DUZ(0); you will sometimes hear programmers refer to it by name.

DUZ(0), where the user’s Fileman Access Code is stored, is associated with another variable, called simply DUZ. The DUZ variable contains the user’s identification code, and, like DUZ(0), it is never supposed to be erased.

Security at the File Level

At the file level, user access is managed either through Fileman Access Codes or through File Access-by-User. This section discusses the specifics of Fileman Access Codes. For a discussion of File Access-by-User, please see Chapter 3.

In a Fileman Access Code, each individual character has a specific meaning. For example, a specific file might have a “p” for its write access. Any user who had a “p” in their Fileman Access Code would be able to edit the file. Another file might have “Pp” for its write access. In this case, any user who had a “P” or a “p” in their Fileman Access Code would be able to edit the file.

A file might have one character as its Fileman Access Code, or it might have more than one. If it has more than one, then any one of the codes listed will provide access. A user may also have one or more characters in their Fileman Access Code, which represent all the types of files, fields, and templates they have access to.

A list of Fileman Access Codes, and which packages they are typically used for, can be found in Appendix A.

When a user signs into VISTA, the Kernel package verifies the user’s identity. It then sets the value of the DUZ variable to the user’s identification code, and the DUZ(0) variable to the user’s Fileman Access Code. Fileman then uses the value of DUZ(0) to determine which files the user can access, and at which level.

Standalone Fileman is accessed from MUMPS programmer mode. The programmer has a choice of commands they can enter in order to launch Fileman. The commands are summarized in the table below:

Command value of DUZ(0) Symbol table erased?
D ^DI unchanged* Yes
D C^DI unchanged* Yes
D D^DI unchanged* No
D P^DI @ Yes
D Q^DI @ No

The first two commands, D ^DI and D C^DI are functionally identical. Essentially, if a programmer uses “^DI” by itself, C^DI is the default.

*For the first three commands, the value of DUZ(0) is unchanged. That is, if the programmer has previously set DUZ(0) to a specific value, that value is retained. If the programmer has not set DUZ(0), it has a null value.

The symbol table is the part of MUMPS where the programmer’s local variables have been stored. Sometimes the programmer wants to keep these when going into Fileman, and sometimes they want to get rid of them.

In MUMPS, local variables are used only by the programmer who created them. Erasing them will not affect the system, and will not affect any other users. It may affect the task the programmer is working on, but they can usually fix their own mistakes.

As we mentioned in Chapter 1, there is an “all-access” Fileman Access Code: the programmers’ at sign, @. A user with @ as their Fileman Access Code doesn’t need any others; @ will allow the user full access to all files, except the ones specifically locked with ^. On the other hand, a file, field, or template that has @ as its Fileman Access Code is accessible only to programmers.

We mentioned this in Chapter 1, but it bears repeating: if a file has no Fileman Access Code at all, it is available to everyone. There are times when this is perfectly appropriate. Everyone, for example, could have read access to the STATE file; there’s nothing secret or confidential about the names and abbreviations of states.

However, sometimes an absence of Fileman Access Codes is the result of a mistake. If your facility is using Fileman Access Codes for file security, we recommend that you check your files to make sure that they all have appropriate Fileman Access Codes.

Changing Fileman Access Codes on Files

When a user creates a new file in Fileman, the new file is automatically given Fileman Access Codes that match the user’s. This may or may not be what the user wants. For example, if a programmer creates a new file, it will have a Fileman Access Code of “@,” meaning only other programmers can see it.

We recommend that, before creating a new Fileman file, a user should give some thought to what the new file is for, and who ought to be able to use it. After creating the file, and adjusting the Fileman Access Code, the user should document the new file, including its purpose, its Fileman Access Code, and the reason for how the code was set up.

If the user who created the file was not a programmer, they may need to contact the IT staff for assistance in modifying the Fileman Access Code. This should not be seen as a reason to skip this step, or to try to make do without the new file. If the file permissions need to be changed, then the IT staff needs to find the time to change them.

Fileman Access Codes can be set and changed for files created locally. In addition, the Fileman Access Codes that come “pre-installed” on the core VISTA files can be changed, and sometimes should be changed, to meet the needs of your facility. If your organization does make the decision to change these codes, be sure to document what files were changed, and why.

If your facility has changed Fileman Access Codes on the core VISTA files, then the programmer responsible for patching Fileman needs to be careful when installing patches. Some patches may include new versions of these files, and they may re-set your Fileman Access Codes to their old levels. If this happens, your documentation will assist the programmer in getting the files back to the settings your organization has chosen.

Rather than going through all that, there is an option where Fileman can ask, as the files are being installed, whether you want to override the default Fileman Access Codes. However, that option has to be set by whoever is distributing the patch—whether it is National VA, National IHS, OSEHRA, or some other organization. If your facility often uses its own Fileman Access Codes, you might want to ask whoever is sending you patches that they ought to include that option. Even if you ask, you might not get it—but if you don’t ask, you certainly won’t get it.

Security at the Field Level

As we discussed in Chapter 1, Fileman Access Codes can be applied to individual fields, as well as entire files. Even if a facility is using the Kernel-based File Access-by-User option, fields that have their own Fileman Access Codes will still be inaccessible to users without the corresponding codes in their user profile, even if they have access to the file.

This system allows a facility greater flexibility when it comes to giving permissions to users. It may be, for example, that some fields of a patient file should be accessible only to users from Billing, and that other fields only be accessible to physicians. Fileman Access Codes at the field level can allow a facility to fine-tune its user permissions.

At the field level, the possible permissions are read, write, and delete. You may have a programmer try to explain to you that LAYGO access is possible, under certain circumstances, for the .01 field, except it isn’t really for the field, except it’s stored in the field.... Just smile and nod. Read, write, and delete are the only permissions you need to worry about at the field level.

Keep in mind that field-level Fileman Access Codes will only apply to people who can access the file in the first place. They will not apply to end users (who, remember, are not Fileman users). They will not apply to users from another department or service, who shouldn’t have access to the file in the first place. Field-level Fileman Access Codes are a way of refining access for the subset of users who already have access to the file.

The most common use for Fileman Access Codes at the field level is to designate some fields with ^ in their write and delete access. That is, to make these fields updatable only by the computer, and not by any human users.

As with files, your facility can change pre-set Fileman Access Codes for fields. And, as with files, your facility will need to document these changes and take care when patching.

Security at the Template Level

Like files and fields, Fileman templates can have their own Fileman Access Codes. As with fields, templates’ Fileman Access Codes override the Access-by-User permissions, so users who need access to a template will need the corresponding code.

Like new files, new templates are created with the user’s Fileman Access Code as a default. And again, this may or may not be the desired outcome, so the codes should be adjusted if necessary.

Templates can only be given read or write access. The ability to create and delete templates is managed through Fileman options.