Files > USR AUTHORIZATION/SUBSCRIPTION

name

USR AUTHORIZATION/SUBSCRIPTION

number

8930.1

location

^USR(8930.1,

description

This file associates users with actions on documents. Actions are of 2 kinds: authorization actions such as the signature action, which an associated user is authorized to perform, and subscription actions, such as an unsigned document notification, which the associated user "signs up to receive." An action may be associated with a USER CLASS in the User Class file (e.g. Staff Physician class) AND/OR with a USER ROLE in relation to the document (e.g. author of document). If an Authorization/Subscription entry has both User Class AND User Role, the AND FLAG field permits these requirements to be "AND'ed", that is, a user must both belong to the User Class AND must fill the User Role in order to perform the action. If the AND FLAG has value OR, or has no value, then User Class and User Role within the same entry are "OR'ed". Each file entry associates an action with 1 user class and/or 1 role. The entry makes this association for a given Document Definition (e.g. Progress Note) of a given status (e.g. Unsigned). Multiple file entries for the SAME action/Document Definition/document status allow association with more than one user class/role. Such entries are "OR'ed": that is, if a user belongs to the user class/role of one OR another of these entries, the user may perform the action. User classes automatically INCLUDE user subclasses of the given class as defined in the User Class file. Document Definitions exist in hierarchy in file 8925.1, with Classes at the top level, Document Classes at the next level down, and Titles under Document Classes. Authorization/Subscription entries may be defined at any of the above levels. For example, an authorization which applies to most or all Progress Notes should be defined at the Class level for Document Definition "Progress Note." On the other hand, an authorization which applies only to Progress Notes of Title "Dental Hygiene Note" should be defined at the Title level for Document Definition "Dental Hygiene Note". When using authorizations/subscriptions to determine whether a given user should receive/may perform a given action for a Document Definition of a given Title, code begins by checking entries for that action and status FOR THAT TITLE. If ANY such entries exist, then entries for higher Document Definition levels will be ignored, and the user passes/fails based on that level alone. Thus, if a Title is linked with a certain action, status and user class, then rules for that Title, action, and status should be entered for ALL user classes which can perform the action on the Title, since broader authorization (e.g. Provider class) set at higher levels (e.g. Progress Notes) is ignored. If such entries do NOT exist, the next higher level of Document Definition is checked. And so on. If no entries are found on any level, no users can perform/subscribe to the action for the given Document Definition and status.

Fields

#	Name	Location	Type	Details	Index	Description
.01	document definition(+)	0;1	POINTER	8925.1	B	This is a Document Definition of Type Class, Document Class, or Title from the Document Definition File 8925.1
.02	status(+)	0;2	POINTER	8930.6
.03	action(+)	0;3	POINTER	8930.8		This is the action to be permitted for a given document type and status.
.04	user class	0;4	POINTER	8930	C	This is the User Class which is being authorized to perform an action on a document of the type and status indicated.
.05	and flag	0;5	SET OF CODES	&:AND !:OR		This field allows the ADPAC to indicate whether the conditions specified by User Class and User Role should be logically "AND'ed," or logically "OR'ed," as they will be unless otherwise specified. i.e., if you want to specify that an unsigned discharge summary may be signed by a user, where: User Class = Provider AND User Role = Author, then you'll want to set this field to AND.
.06	user role	0;6	POINTER	8930.2	D	This identifies the role of the user with respect to the document in question (e.g., Author/Dictator, Expected Signer, Expected Cosigner, Attending Physician, etc.).
1	description	1;0	WORD-PROCESSING			For most entries, the meaning of the entry will be clear from the description of the associated event in the TIU Event file. In some cases, that may not suffice, in which case this field may be used to further For example, if an entry associates the Signature event with a document of status completed, it might help to note in the description field that such a signature is a walkup signature. It should not be necessary to describe consequences in this field - those descriptions may be gotten from the associated protocol descriptions instead. This field will be used when persons associating users with user classes wish to know the meaning of events associated with certain user classes.
2	prerequisite action	PRE;E1,245	FREE TEXT
3	consequence	POST;E1,245	FREE TEXT