INVOKE DUZ~XUP ICR (4129)

Name

Value

NUMBER

4129

IA #

4129

DATE CREATED

2003/06/30

CUSTODIAL PACKAGE

KERNEL

USAGE

Controlled Subscription

TYPE

Routine

DBIC APPROVAL STATUS

APPROVED

ROUTINE

XUP

NAME

INVOKE DUZ~XUP

GENERAL DESCRIPTION

Noted by Custodian on 11/3/23 that it has been
mentioned in the past that this API needs to be improved. That is, Kernel
needs to find a better solution to allow VistA Kernel direct-authentication of
the actual user logged in to VistA.  Setting the DUZ variable should be done
only by Kernel after verification of valid and secure credentials. If we
continue allowing applications to "arbitrarily search" for an IEN in the NEW
PERSON (#200) file, and then call DUZ^XUP to set the DUZ variable, it may
cause additional problems.

STATUS

Active

XUP

COMPONENT/ENTRY POINT

VARIABLES

DUZ(DA)

VARIABLES

TYPE

VARIABLES DESCRIPTION

DUZ

Output

This procedure returns variable DUZ equal to your
input parameter.  Also, components of the DUZ array are set-up as well.

Input

The required input parameter to DUZ^XUP(DA) is the
internal entry number into file 200.  This is the user IEN of the user that
you want to set the DUZ value and DUZ array to.

SUBSCRIBING PACKAGE

SUBSCRIBING PACKAGE	SUBSCRIBING DETAILS
INTEGRATED BILLING	The IB package has MRA (Medicare Remittance Advice) functionality using a specific, non-human user in file 200. IB MRA would like to be able to re-set the DUZ to be this non-human user so all filing and database activities appear to have been performed by this non-human IB MRA user instead of by the Postmaster. IB MRA is invoking DUZ^XUP at the beginning of a background task to set the DUZ value and DUZ array entries. Routine IBAMTS also must insure DUZ is set since the HL7 multi-thread listener is not passing a valid DUZ. With IB2.0432, in routine IBCAPP for the new IB CBW functionality, a specific non-human user (AUTHORIZER,IB REG) is used for all reg 835 EOB filing processes. IBCAPP would like to be able to re-set the DUZ to be this non-human user so all filing and database activities appear to have been performed by this non-human IB CBW user during these background processes.
LAB SERVICE
IFCAP
REGISTRATION
VISTALINK SECURITY
ORDER ENTRY/RESULTS REPORTING
MAILMAN
CONSULT/REQUEST TRACKING	Added 11/12/20.
HEALTH LEVEL SEVEN	Added 1/31/22 to document access in an existing routine HLCSTCP4. Patch HL1.6174, will include the ICR reference in the routine. The DUZ^XUP access is necessary to initialize the DUZ variables as part of the incoming background filer which is not tied to an actual user. HLCSTCP4 ;SFIRMFO/RSD - BI-DIRECTIONAL TCP ;08/03/2011 13:29 ;;1.6;HEALTH LEVEL SEVEN;109,122,140,157;Oct 13,1995;Build 8 ;Per VHA Directive 2004-038, this routine should not be modified. ; Q ; RDERR & ERROR moved from HLCSTCP2 on 12/2/2003 - LJA ; HLDUZ2 ; compare DUZ and HLDUZ I $G(DUZ)'=HLDUZ D . S DUZ=HLDUZ . D DUZ^XUP(DUZ) Q ;
RADIOLOGY/NUCLEAR MEDICINE	Added 7/11/22,effective with patch RA5192, to use POSTMASTER (DUZ=.5) to update the radiology order status and the CPRS order status to COMPLETE. This update requires who made the change.
DSS RXTRACKER	Added 11/3/23, effective with patch DSHX 2.0 for the DSS RXTRACKER, also referred to as DSHX RXTRACKER. DSHX needs to alter DUZ in routines DSHXOMP, DSHXOMP2, and DSHXOMPX. The provider(s) who prescribed/discontinued the medication in RxTracker (external to VistA) are returned in the HL7 message that is received and consumed by Vista. The processing of the inbound HL7 message is invoked by the multi-listener in the background so there is no user log-in for the instance. The Vista HL7 application DUZ value is that of the user who logged into CPRS/VistA or Postmaster (.5) and not that of the provider/pharmacist who prescribed the medication order in RxTracker. Having the accurate DUZ values will ensure the proper provider/pharmacist is associated with the medication order(s).
OUTPATIENT PHARMACY	Added 3/5/25, effective with patch PSO7.0774, to allow for auto release of pharmacy medications on a host site that were refilled or partial filled remotely via OneVA Pharmacy and dispensed remotely by an automated dispensing device. Since the user performing the release at the dispensing site is not on file locally at the host site, the proxy user PSOAUTORELEASE,PROXY USER is added to the NEW PERSON file (#200) by this patch and the DUZ variable containing this proxy user is required to invoke required ECME/IB APIs. As the actual user performing the remote release of the pharmacy prescription is stored as free text in the REMOTE PRESCRIPTION LOG file (#52.09), and the unique prescription number is stored on the remote dispensing site in this same file, there is a manual method by which the remote user may be identified if necessary. Until the long term goal of using SEC ID to identify remote users via an enterprise pattern that could address application proxy-based scenarios, this intermediate solution is necessary for OneVA.

DATE ACTIVATED

2010/12/16