File Manager 22.2 Security & Privacy Manual

Contents > Chapter 1

Chapter 1: Access Authorization

The first layer of security on any system running Fileman is external to the Fileman package itself. In an integrated VISTA system, access is initially handled by the Kernel package. In standalone Fileman, this function is handled by the operating system’s native security layer. You should familiarize yourself with the underlying security protocols in order to get a complete picture of Fileman security. Please consult your operating system manual, or the Kernel documentation suite, as appropriate.

Before we plunge into the nuts and bolts of how users access Fileman, it is important to note that end users do not access Fileman—at least, not directly. In a VISTA system, the users interact with Fileman through the specific packages they use to perform their job functions. Their Fileman access, therefore, is defined not by Fileman or Kernel, but by Laboratory or Pharmacy or Nursing or IFCAP. Direct access to Fileman in a VISTA system is limited to programmers, system administrators, and super-users (CACs, ADPACs, and so on). And you, of course. This is a key point, and one that we will probably bring up again because it’s important to keep in mind. Fileman users are not end users.

In standalone Fileman, users either have access to the system or they do not; there is not a system native to Fileman that can allow different types of access for different types of user. There is a basic menu system (essentially a very primitive Menuman) that presents the complete list of Fileman options and responds to user input.

This native menu system does not include the SQL projection options or the Fileman management options. These options are available in standalone Fileman, but programmers must know their entry points in order to access them.

It should be noted that a site running Kernel can opt not to use Menuman’s menus for Fileman access. The native Fileman menu system is available to everyone, and programmers in particular often prefer to use it. For the most part, this manual assumes that a site running Kernel is using Menuman for Fileman access. We will make the further distinction—between Kernel sites using Menuman and Kernel sites not using Menuman—if it is important to the feature or option being discussed.

In a system running Kernel, security keys are used in conjunction with Menuman to tailor menu options for users. Menuman menus and options are generally designed for roles, not individuals. But within a given role, there can be individual variations.

For example, one role available in the Laboratory package might be “Lab Tech.” But in a hospital lab, there might be junior lab techs, senior lab techs, supervising lab techs, and so on. Some of the options available to the “Lab Tech” Menuman role might not be appropriate to give to the more junior levels of the staff. The solution is to give the “Lab Tech” menu to all the techs, but use security keys to lock certain options so that only the appropriate staff could use them.

When options are locked, Menuman does not even show them to the user. In our lab tech example, the junior techs would see a Lab Tech menu, but it wouldn’t list all the Lab Tech options, just the ones that they had access to.

With Fileman, users are often given access with DIUSER. But not all of the options in DIUSER are appropriate for all users of Fileman. Some DIUSER options are locked with the security keys described below.

XUAUDITING   This security key is needed to access the Auditing submenu, which contains all of the auditing options. These options are restricted because it’s not a good idea to allow users to turn auditing on and off at will. XUAUDITING should be given to anyone who needs to perform auditing functions, including system administrators, Security officers, and any programmers directly supporting Fileman.

XUFILEGRAM   This security key is needed for most of the filegram options. A filegram is a method for extracting a single record in a portable format. This has obvious HIPAA and patient-privacy implications, so most filegram options are located in a filegram submenu, accessible only to users with this key. The exception is the View Filegram option, which is not locked; any user can look at a filegram. That is, any Fileman user can look at a filegram. Remember that Fileman users are not end users; when we say “all users,” we’re actually talking about a small number of people. The XUFILEGRAM key should be given to system administrators and anyone whose job role includes moving records.

XUMGR   This security key is needed to access Fileman Management submenu, which includes options for installing and configuring Fileman. It is also needed to access many Kernel options. XUMGR should be given to system administrators, some senior programmers, and whichever programmer or programmers are responsible for patching Fileman and keeping it up-to-date.

XUPROGMODE   This security key is needed to enter “programmer mode,” which most programmers need to be able to do. Therefore, this key ends up being given to more people than will actually be using the specific Fileman options it unlocks. These options are the Regenerate SQLI Projection and Purge SQLI Data options. Both of these options have to do with setting up an interface between Fileman and a SQL query engine.

XUSCREENMAN   This security key is needed to access the Screenman menu. This is the menu that allows programmers to create and change Screenman forms. XUSCREENMAN should be given to anyone authorized to manage Screenman forms.

DDXP-DEFINE   This security key is needed to access the Export Tool’s Define Foreign File Format option. The Export Tool is used to move Fileman data into another software format: for example, an Excel spreadsheet. Super-users often use the Export Tool to check and verify data. Most of the formats the super-users need have already been defined, so the ability to define new ones should be restricted to programmers who understand how the tool works, and how to define a new format.

DIEXTRACT   This security key is needed to access the Extract Data to Fileman File submenu. This submenu allows users to extract data from existing Fileman files, and save it in new files that they create. An extracted file is a good option for a user who needs to work with a specific set of data, but does not want to hamper or slow down the main system.

Fileman File Security

The menus and security keys provide access to Fileman’s options, but each file also has its own security. It is possible, therefore, for a user to have access to Fileman, or to a set of Fileman options, but not to have access to any files. In other words, they could select an option, but they could not select a file to use the option on. Users hate that.

Therefore, when granting a user access to Fileman, it’s important to pair their Kernel/Menuman access with access to at least one file. This will allow the user to at least try out some of their new options, even if they can’t do much yet.

Each file in the system has six possible types of access that can be granted to users. Arranged from lowest level of impact on the database to the highest:

Read access allows users to see what is in the file, but not make changes. Related Fileman options include Inquire to File Entries, Print File Entries, and Search File Entries.

Write access allows users to edit files, but not add or delete records. Related Fileman options include Enter or Edit File Entries, and Transfer File Entries.

LAYGO (learn-as-you-go) access allows users to add records. Related Fileman options include Enter or Edit File Entries.

Delete access allows users to add and delete records. Related Fileman options include Enter or Edit File Entries, and Transfer File Entries.

Audit access allows users to turn auditing features on or off. Related Fileman options include all of the options on the Auditing submenu.

Data-dictionary access allows users to change the nature of the file: that is, change the file and field attributes. Related Fileman options include Modify File Attributes, Utility Functions, and Data Dictionary Utilities.

Although the six levels of access have a definite hierarchy, they are independent of one another. That is, a higher level of access does not “contain” the lower levels. If a user is given write access to a file, they also need be given read access. Otherwise, they’ll be able to edit the file, but not read it, which makes no sense.

These six levels of user access are always available in Fileman; however, there are two possible mechanisms for how the access is actually handled.

Fileman’s native mechanism for user access is the Fileman Access Codes. When this system is in use, each file, field, and template can have its own specific Fileman Access Codes. Codes can then be assigned to users as user attributes.

On a system running Kernel, Fileman Access Codes can be replaced by an alternate mechanism called File Access-by-User. In this method, each user is matched with one or more files that they can access. Users and files are matched through Kernel; users are not given Fileman Access Codes. Sites using this method usually set up standard profiles for different types of users, similar to the role based Menuman options.

The primary difference between these two systems is that under Fileman Access Codes, the default is “fully accessible.” That is, if a file does not have a Fileman Access Code, the system will allow anyone to access it. Fileman Access-by-User is the exact opposite; the default condition is “no access.” If a user has not been matched up with a file, the user will not be able to see or use anything.

If a VISTA system is using File Access-by-User, the Fileman Access Codes are suppressed, with a few specific exceptions.

First, you may have noticed that Fileman Access Codes can be used for files, fields, and templates. But Access-by-User only applies to files. Therefore, if users need to have access to templates, even templates associated to files they’ve been matched with, they have to be given any applicable Fileman Access Codes.

Similarly, if specific fields within a file have been given Fileman Access Codes, the user will need to be given those codes as well. The Access-By-User permissions will not override the field codes.

Finally, two Fileman Access Codes are not suppressed when Access-By-User is active, just because the codes are so useful. The first of these is the “programmer’s at-sign” (@), which gives a user access to every file. Using the @ is easier than manually assigning every single file to the user (and remembering to go back and assign any new files that are created!). The other Fileman Access Code that is not suppressed is the up-arrow (^), which indicates a file that cannot be altered by anyone. This code is typically found in the files that Fileman uses to operate.

The intent is that the ^ overrides the @; that when a file says “nobody can access this,” that “nobody” includes programmers. The ^ does work that way for write access at the field level; however, there have been bugs implementing it elsewhere, including at the file level. The Fileman team is working to fix these, but for now, be aware that a ^ won’t necessarily keep programmers out. It will, however, keep everybody else out.

As a Security officer, your biggest challenge with these two systems (Fileman Access Codes and File Access-by-User) will be if your facility decides to switch from one to the other. Such a switchover requires some painstaking work and attention to detail. On the authors’ “to-do” list is a set of complete instructions for handling this kind of switchover. Until that is available, we strongly encourage you to reach out to other Security officers, either via OSEHRA or your own contacts, to gain the benefit of their experience.

Filemanʼs Own Files

The security measures described so far in this chapter apply to all the files created and maintained through Fileman, with one important exception. The files that Fileman needs to operate—Fileman’s own files—have their own security and their own rules for access. Some of these files are accessible only to those with programmer access: those who have “@” as their Fileman Access Code. Many of these files are not accessible at all, at least not to humans. For the most part, Fileman trusts only software when it comes to its own files. Programmers can, at times, use specialized data-dictionary options to modify these files, but the normal options for editing data will not usually work.

In terms of file numbers, any file with a number below 2 belongs to Fileman. That is, it is one of the files that Fileman needs in order to function.

Practical Application

In both standalone Fileman, and in Fileman as part of VISTA, access to Fileman files and options is managed through menus (for options) and file permissions (for files). As a Security or Privacy officer, you need to be aware of which employees have access to which options and files. You should also be notified when permissions are changed.

Your facility should have a process in place so that employees can request access to the options and files they need to do their jobs, and so that supervisors and managers have the appropriate oversight. You should probably be a part of this process—but even if you are not, you should ensure that part of the process is notifying you of the change.

When Is File Access Security Checked?

When a user is in Fileman, whether standalone or as part of a VISTA installation, Fileman checks their security permissions every time they access a file. It’s pretty straightforward. However, Fileman permissions can also be checked at other times.

As we mentioned at the beginning of the chapter, end users do not typically have direct access to Fileman. This means that most users do not have access permissions to Fileman files. Yet end users read, update, and even add to files all the time, using VISTA options. How does that work?

When programmers are building VISTA options, they can use a variety of MUMPS commands that tell Fileman what is going on. For example, they might use a command that tells Fileman the user will be adding a record. If that command is used for the option, Fileman will not check the user’s permissions for the file when the option is invoked. Fileman is expecting the user to add a record, and because VISTA said it was okay for the user to add a record, Fileman doesn’t check the permissions. This is how, for example, an admissions clerk can add a new patient to the PATIENT file, even though she doesn’t have any kind of Fileman access at all.

For the most part, these options belong to the standard VISTA packages as they are installed. Any security implications have already been identified and described in the documentation for those specific packages, so you should have that information at your disposal.

However, if the programmers at your facility create special VISTA options for users, and if any of those options include the ability to see or change the database, then you as the Security officer need to be aware of them. If you don’t have one in place already, set up a notification process that will give you visibility for any new options your programmers create that will affect user access to the database.

Understanding ^DIC and ^DIE

There are literally thousands of commands, or calls, that can be used to create options. Fortunately, you don’t need to learn them all. There are two calls, however, that can interact with Fileman’s file permissions, so it is a good idea to understand a little about how they work.

The first is ^DIC. This is a lookup call; that is, it allows the user to look up or select records in the database. The second call is ^DIE. This is an edit call, which allows users to edit records in the database.

That’s pretty straightforward so far. But VISTA developers discovered fairly early on that when users are looking up records, they often end up wanting to add a record. And when users are editing records, they often end up wanting to delete a record.

Of course, just because users want to do something, that doesn’t make it a good idea. Programmers have flexibility when using these calls, so that they can allow users to perform these additional functions, or not, as the situation warrants.

When a programmer builds an option using ^DIC, they can specify that the option is lookup-only, that the user will not be allowed to add records under any circumstances. Or, the programmer can specify a “LAYGO lookup,” meaning that a user who has LAYGO access to the file would be able to add records.

In an option built with LAYGO lookup, Fileman allows the user to look at the data without checking their file permissions. Fileman, remember, is working with a ^DIC; it is expecting the user to be looking up and selecting records.

What Fileman isn’t really expecting is the user wanting to add records; there is a different call for that. However, because the programmer has set up the option to allow LAYGO lookups, Fileman doesn’t automatically refuse a request to add records. Instead, Fileman knows to check the user’s file access permissions. If the user does have LAYGO access to the file, Fileman proceeds with the transaction. If the user does not have LAYGO access to the file, the transaction is not allowed.

So far so good. However, programmers can add one more wrinkle into a ^DIC option. A programmer can set the option to allow LAYGO-lookup, and include a special variable called DLAYGO. This variable tells Fileman not to bother checking permissions—that any user who wants to add a record can do so. In effect DLAYGO gives LAYGO access to all users using that particular option.

There is a similar, but not completely identical, situation with ^DIE. Options built with ^DIE allow users to edit. Programmers can also allow deletions from the option, simply by including the file’s .01 field as one of the fields that can be edited. As you probably know, deleting a record’s .01 field will delete the entire record. Therefore, if an option built with ^DIE includes the .01 field, record deletion is possible.

If a user attempts to delete the .01 field, Fileman knows to check whether the user has delete access to that file. If the user has delete access, Fileman gives the okay and the transaction is allowed. If the user does not have delete access, the transaction is not allowed, and the .01 field is not changed.

There is, as you may have guessed, a special variable that programmers can use with ^DIE options that tells Fileman not to check a user’s file permissions. The variable is DIDEL, and it essentially gives delete access to all users using that particular option.

Because ^DIC and ^DIE interact with file access security, it is important to understand how they work.

Access from Another File

As you have probably seen, the data files in Fileman are highly interconnected. Files point to other files, which point to other files, which point to yet more files. Computed fields can pull data from all over the place. This is part of what makes VISTA such a useful tool in medical informatics.

It can be difficult, however, to track Fileman permissions through all those pointers. So at the present time, Fileman does not even attempt it. When a user has Fileman access to a file, they have access only to that file. If they try to “follow” a pointer to edit or even read another file, Fileman will not allow it unless the user specifically has access to that file as well.

Because of this, you may occasionally need to give users access to pointed-to files in order for them to fully manage the files they control. Such access is usually granted on a case-by-case basis.

Security and the Line Editor

The Line Editor is one of VISTA’s two native word-processing tools. Most users prefer the newer Screen Editor.

However, the Line Editor includes an ability that the Screen Editor does not have. Using the Line Editor, a user can copy lines from another “document” (that is, any other word-processing field) into the document currently being edited. Basically, a user can use the Line Editor to grab text from anywhere and paste it into their document.

When a user does this, however, Fileman does check their file permissions to ensure that they have read access to the file they’re trying to use.

[return]