| IA # | Name | Type | Custodial Package | Date Created | DBIC Approval Status | Status | Usage | File # | General Description | Remote Procedure | Routine | Date Activated |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| IA # | Name | Type | Custodial Package | Date Created | DBIC Approval Status | Status | Usage | File # | General Description | Remote Procedure | Routine | Date Activated |
| 1544 | USRLM CALLS | Routine | AUTHORIZATION/SUBSCRIPTION | 1996/06/18 | APPROVED | Active | Controlled Subscription | The Scheduling Developers would like the following on-going integration agreement with the Authorization/Subscription Developers: Use of the following USRLM calls: $$ISA(USER,CLASS,ERR) - Boolean - Is USER a Member of CLASS? $$SUBCLASS(DA,CLASS) - Evaluate whether a given USER CLASS is a DESCENDENT of another class $$CLNAME(CLASS) - Given a class, return the Display Name $$WHOIS2(MEMBER,CLASS)- Given a Class, return list of CURRENT members Parameters: USER - Pointer to File #200 CLASS - Pointer to File #8930 DA - Pointer to File #8930 ERR - [Optional] Error Variable to contain error message MEMBER is name of array (local or global) in which members are returned in alphabetical order by name - indexed by number i.e. @MEMBER@(1 ...n) @member@(0) = ien of8930^usr class name^count of members @member@(1..n)= 1 2 3 4 5 6 7 8 p200^p8930.3^classname^effectdate^inactdate^username^title^mailcode Note: For pieces 2,4 & 5 - Only one of potentially many is returned These calls are part of the User Class Membership functions that PCMM uses for sites that choose to use the user class functionality. |
USRLM | |||
| 1545 | GLOBAL READ OF USR & USR(8930 | File | AUTHORIZATION/SUBSCRIPTION | 1996/06/18 | Withdrawn | Private | 8930 | The Scheduling Developers would like the following on-going integration agreement with the Authorization/Subscription Developers: Read access to the following global: ^USR(8930 (The USR CLASS File (#8930) We do the following operations: o Read of ^USR(8930,ien,0) o $DATA check of ^USR(8930) o $DATA check of ^USR( o $ORDER read of ^USR(8930,"B",SCX) o $ORDER read of ^USR(8930,"B",SCX,SCI) o Look-up, using ^DIC o RPC Broker Lister lookup of File #8930 o The USER CLASSIFICATION Field (#.02) of the STANDARD POSITION File (#403.46) points to File #8930. o The USER CLASS Field (#.13) of the TEAM POSITION File (#404.57) points to File #8930. o The USE USR CLASS FUNCTIONALITY Field (#801) of the SCHEDULING PARAMETERS File (#404.91) does a $DATA check in its input transform for the existence of the ^USR global - requiring this global for the value 'YES' to be set. |
||||
| 1546 | READ OF USR(8930.3 | File | AUTHORIZATION/SUBSCRIPTION | 1996/06/18 | APPROVED | Active | Private | 8930.3 | The Scheduling Developers would like the following on-going integration agreement with the Authorization/Subscription Developers: Read access to the following global: ^USR(8930.3 (The USR CLASS MEMBERSHIP File (#8930.3) We do the following operations: o $DATA check of ^USR(8930.3,"B",Y) as a screen for the PRACTITIONER Field (#.03) of the POSITION ASSIGNMENT HISTORY File (#404.52). o $DATA check of ^USR(8930.3) as part of our post-init routine, SCMCPST, which sets the USE USER CLASS FUNCTIONALITY Field (#801) to 'YES', if this global exists (and other conditions are true). |
|||
| 2324 | DBIA2324 | Routine | AUTHORIZATION/SUBSCRIPTION | 1998/02/10 | Other | Controlled Subscription | When checking if a user should have access to a particular document TIU needs to determine if a user is a member of a class that can access the document. Therefore TIU requests permission to call the function ISA^USRLM. Health Summary needs to extract user class data to build a class selection list for Health Summary Parameters referenced by the Parameters tools in the Parameter file. Therefore GMTS request permission to call the function WHATIS^USRLM. Health Summary needs to retrieve the name (.01) of a user class referenced by the Parameters file. The call to CLNAME^USRLM will return the Class display name (.04). |
USRLM | ||||
| 2325 | DBIA2325 | Routine | AUTHORIZATION/SUBSCRIPTION | 1998/02/10 | APPROVED | Active | Controlled Subscription | When checking what a user can do with a document, (read, edit, etc.) TIU needs to evaluate the user's authorization. Therefore TIU requests permission to call the function CANDO^USRLA. |
USRLA | |||
| 2329 | DBIA2329 | Routine | AUTHORIZATION/SUBSCRIPTION | 1998/02/19 | APPROVED | Active | Controlled Subscription | USRLFF is a library of file functions for providing read access to various AUTHORIZATION/SUBSCRIPTION data. |
USRLFF | |||
| 2712 | DBIA2712 | Routine | AUTHORIZATION/SUBSCRIPTION | 1999/01/14 | APPROVED | Active | Private | The function ISTERM offers an approved means of identifying whether a user is currently terminated, as supported by DBIA 10060, until such time as Kernel provides a comparable function. |
USRLM | |||
| 3008 | POINT TO USR CLASS (#8930) FILE | File | AUTHORIZATION/SUBSCRIPTION | 1999/12/07 | APPROVED | Active | Controlled Subscription | 8930 | ||||
| 3028 | DBIA3028 | File | AUTHORIZATION/SUBSCRIPTION | 2000/01/31 | APPROVED | Active | Controlled Subscription | 8930.3 | QUASAR A&SP STAFF File, #509850.3, will point to USR CLASS MEMBERSHIP FILE, #8930.3. USR does not normally permit storing User Class memberships. Generally membership is checked on the fly using APIs to determine a permission, or checked and then a result is stored which does not point to the USR file. For example, the TIU document file has field COSIGNATURE NEEDED which stores the result of a lookup in the USR file and in TIU parameters. |
|||
| 3104 | Direct Read of USR ACTION FILE (#8930.8) | File | AUTHORIZATION/SUBSCRIPTION | 2001/03/26 | APPROVED | Active | Private | 8930.8 | TIU frequently sends "You may not..." messages such as "You may not ATTACH this UNSIGNED TELEPHONE NOTE TO AN ID NOTE." In order to create such messages, TIU reads the B cross-reference of file 8930.8 to get the record number of a given action, and then reads pieces 5 and 7 of the 0 node to get the USER VERB and the USER VERB MODIFIER for the given action, for use in feedback messages such as the one above. |
|||
| 3128 | Direct Read of USR ROLE FILE (#8930.2) | File | AUTHORIZATION/SUBSCRIPTION | 2001/03/26 | APPROVED | Active | Private | 8930.2 | In evaluating whether a user can perform a particular action on a given TIU document, TIU needs the record number in the USER ROLE FILE of each role played by that person with respect to the document. These roles are determined by examining various fields of the document, and then the role record number is read from the B cross-reference of the USER ROLE FILE. |
|||
| 3129 | Direct Read of USR AUTHORIZATION/SUBSCRIPTION FILE | File | AUTHORIZATION/SUBSCRIPTION | 2001/03/26 | APPROVED | Active | Private | 8930.1 | Document Definition titles for Interdisciplinary Notes may not be used for both ID parent and ID child notes. If there are rules permitting a title to be used for ID parent notes, any existing rules allowing it to be used for ID child notes are ignored. Therefore, ID notes needs to know if rules exist permitting a title to be used as an ID parent. To evaluate this, TIU reads the AR and AC cross-references of the AUTHORIZATION/SUBSCRIPTION FILE (#8930.1). |
|||
| 3355 | EXPORTING NEW ASU STATUS ENTRIES | File | AUTHORIZATION/SUBSCRIPTION | 2001/04/13 | APPROVED | Active | Private | 8930.6 | Periodically, when new functions for document management are introduced by applications making use of ASU, it is necessary to introduce new definitions for the state (or status) of the object being acted upon, following the new processing event. One example is support for the retraction of a TIU Document that was entered in error for the wrong patient. To implement retraction, we needed to be able to identify the new status "retracted," and declare business rules specifying privileges for specific users to act on such documents. Such extensions necessitate adding new entries to the USR RECORD STATUS FILE (#8930.6), and distributing them with patches that implement the new functionality. ASU grants permission to TIU to issue such updates to the USR RECORD STATUS FILE (#8930.6), until otherwise agreed. |
|||
| 3409 | DIRECT READ OF USER CLASS FILE | File | AUTHORIZATION/SUBSCRIPTION | 2004/11/29 | APPROVED | Active | Private | 8930 | TIU requests the ability to directly read the "B" cross reference of USR(8930 (The ASU User Class File #8930). This is to support the ability to check if a specific USER class exists. |
|||
| 3775 | TIU DIRECT READ OF USER CLASS FILE | File | AUTHORIZATION/SUBSCRIPTION | 2002/10/07 | APPROVED | Active | Private | 8930.3 | TIU requests the ability to directly read the ASU User CLass Memebership File #8930.3 - ^USR(8930.3, specifically the "AUC" cross reference and the 0 node fields (#.03) EFFECTIVE DATE and (#.04) EXPIRATION DATE to verify the user's membership status. |
|||
| 3776 | TIU DIRECT READ OF USER CLASS FILE | File | AUTHORIZATION/SUBSCRIPTION | 2002/10/07 | APPROVED | Active | Private | 8930 | TIU requests the ability to directly read the ASU User CLass File #8930; specifically, ^USR(8930, using only the subclass multiple ^USR(8930,D0,1,D1,0) -- the SUBCLASS field (#.01) to verify a user's applicable subclasses and membership status. |
|||
| 4119 | CALL TO USRPS23 | Routine | AUTHORIZATION/SUBSCRIPTION | 2003/06/05 | APPROVED | Active | Private | Patches TIU*1*137 and USR*1*23 create new Document Definitions and a new User Class and new Business Rules in support of Anat Path. They are sent out as a combined build. The actual creation is done in an option sent out with TIU*1*137 but run after the distribution is installed. Being able to create both the TIU and the USR entities from one option makes less work for sites, and ensures that the Document Definitions do not get created without the Business Rules which restrict their use. This agreement permits TIU to call MAIN^USRPS23 and to kill the temp global created in USRPS23: ^TMP("USR23"). |
USRPS23 | |||
| 4127 | CALL TO USRPS24 | Routine | AUTHORIZATION/SUBSCRIPTION | 2003/06/11 | APPROVED | Active | Private | Patches TIU*1*165 and USR*1*24 create new Document Definitions and a new User Class and new Business Rules in support of Patient Record Flags. They are sent out as a combined build. The actual creation is done in an option sent out with TIU*1*165 but run after the distribution is installed. Being able to create both the TIU and the USR entities from one option makes less work for sites, and ensures that the Document Definitions do not get created without the Business Rules which restrict their use. This agreement permits TIU to call MAIN^USRPS24 and to kill the temp global created in USRPS24: ^TMP("USR24",$J). |
USRPS24 | |||
| 4935 | Use of AD xref in file 8930 | File | AUTHORIZATION/SUBSCRIPTION | 2006/12/04 | Expired | Private | 8930 | CPRS requests the ability to do a direct global read of the AD cross-reference of file 8930. The OR ALLERGY ENTERED IN ERROR parameter has identified CLASS as one of the entity levels that can be set for this parameter. Because a user can belong to multiple classes and multiple classes can have values in this parameter, the AD cross-reference is used to determine the "parent" class of the class that is set in the parameter. The child class is used to identify whether a user can or cannot mark an allergy as entered in error. As a result, all higher level (parent) classes are removed from consideration when determining if the user can take the action. If more than one child class has a value then those will be compared against each other and any "yes" value will allow the user to mark an allergy as entered in error. This is a temporary agreement until The Authorization/Subsciption utility is able to write an API to provide the above funtionality in a standardized way. |
||||
| 6088 | VPR READ OF USER CLASS | File | AUTHORIZATION/SUBSCRIPTION | 2014/08/15 | APPROVED | Active | Private | 8930 | The Virtual Patient Record (VPR) needs the User Classes to accurately apply ASU business rules in the Health Management Platform (HMP) client. |
2016/05/09 | ||
| 6089 | VPR READ OF ASU RULES | File | AUTHORIZATION/SUBSCRIPTION | 2014/08/15 | APPROVED | Active | Private | 8930.1 | The Virtual Patient Record (VPR) needs the Authorization/Subscription rules to accurately apply ASU business rules in the Health Management Platform (HMP) client. |
2014/09/05 | ||
| 6146 | VPS READ OF 8930.3 | File | AUTHORIZATION/SUBSCRIPTION | 2015/01/20 | Withdrawn | Controlled Subscription | 8930.3 | VA Point of Service Kiosks needs to read global references in the USER CLASS MEMBERSHIP FILE #8930.3. |