Removing CPRS invalid Additional Signers

[kdt...@gmail.com]

Hey All,

We have been having great success with intra-office messaging by
creating notes and identifying the nurse etc as an Additional Signer
from within CPRS.

My problem now is that I have all the old, inactive users showing up
on the list of possible additional signers. I had this problem when I
first started, and someone posted how to remove them from the list. I
have tried to find that thread but can't seem to locate it. They
showed back up after installing some TIU patches. Now I want to
remove them again.

Can anyone tell me how to limit the user that show up as possible
additional signers of a CPRS note?

Thanks
Kevin

[Rich Vertigan, CPRS Developer (retired)]

Are they showing up in the "AUSER" xref on file 200? That's where the
list comes from, and it screens out inactive users with $
$PROVIDER^XUSER. We often had problems where that xref needed to be
rebuilt, for whatever reason. since it wasn't being automatically kept
up to date.

[kdt...@gmail.com]

Rich,

No, the users that are showing up are not in the AUSER xref from 200.
It seems like this was a CPRS parameter when you told me how to fix
this before.

Thanks
Kevin


On Nov 2, 11:45 am, "Rich Vertigan, CPRS Developer (retired)"

[kdt...@gmail.com]

I just looked in CPRS, and it seems that the RPC that is returning the
list is:

ORWU NEWPERS

I'll have to trace through this later and find out why the extraneous
people are showing up.

Kevin

[David Whitten]

Entry in the REMOTE PROCEDURE File

NAME: ORWU NEWPERS TAG: NEWPERS
ROUTINE: ORWU RETURN VALUE TYPE: ARRAY
DESCRIPTION:
Returns a set of New Person file entries for use in a long list box.

Code:
NEWPERS(ORY,ORFROM,ORDIR,ORKEY,ORDATE,ORVIZ,ORALL) ; Return a set of names from
the NEW PERSON file.
; SLC/PKS: Code moved to ORWU1 on 12/3/2002.
D NP1^ORWU1
Q

Generally NP1 uses the "AUSER" xref on ^VA(200,

NP1 notes:
; PARAMS from NEWPERS^ORWU call:
; .ORY=returned list.
; ORDATE=Checks for an active person class on this date (optional).
; ORDIR=Direction to move through the x-ref with $O.
; ORFROM=Starting name for this set.
; ORKEY=Screen users by security key (optional).
; ORVIZ=If true, includes RDV users; otherwise not (optional).
;

ORALL isn't documented, but basically it uses the "B" xref on ^VA(200,
ORVIZ also uses the same "B" xref, but if ORALL=0 it skips a
$$PROVIDER^XUSER screen on people

so you need to look at the actual broker call to see if the ORVIZ
variable is non-zero and the ORALL variable
is non-zero to know which choice happens.
so since the

[kdt...@gmail.com]

Dave, (and anyone else)
Thanks for looking at this with me.

The line in NP!^ORWU1 is below
..I +$G(ORALLUSE)=0,'$$PROVIDER^XUSER(ORIEN1) Q ; Terminated users.

I think this says that if ORALLUSE=0, then check $
$PROVIDER^XUSER(ORIEN1), and if that is false, then quit (don't return
user on list.)

The change that has occurred in my system is in $$PROVIDER^XUSER. And
frankly I don't understand the logic of the code. It doesn't seem to
make any sense. I (thankfully) modified the ZSAVE on my system to
first make a backup of source files when changing them through
patches. So I can go back and see what it used to be.

Here is my original function.
PROVIDER(XUDA,XUF) ;See if user qualifies as a CPRS provider
;At this time the only test is that the user isn't terminated
N %,X1,X2
S X1=$G(^VA(200,+$G(XUDA),0)),X2=$S(X1="":"",1:1)
S %=$P(X1,U,11) I %>0,%<DT S X2="0^TERMINATED^"_%
Q X2
;

Here is the function now (comments below)

PROVIDER(XUDA,XUF) ;See if user qualifies as a CPRS provider
;XUDA = IEN of Record in New Person File
;XUF = Flag to control processing
; 0 or not passed, do not include Visitors
; 1 include Visitors
N %,X1,X2,XUORES
;Test to see if XUDA Passed:
I '$D(XUDA) Q ""
;
;Test for valid IEN:
S X1=$G(^VA(200,+$G(XUDA),0)),X2=$S(X1="":"",1:1) Q:X2="" ""
;
;See if user has XUORES Security Key:
S XUORES=$D(^XUSEC("XUORES",XUDA))
;
;Test for Access Code:
I $P(X1,U,3)]"" Q 1 <--- any person with an access code is
considered a provider!!!???
;
;Test for a Termination Date not in the Future
;AND Not owner of XUORES Security Key:
S %=$P(X1,U,11) I %>0,%'>DT,'XUORES Q "0^TERMINATED^"_%
;
;Test if user has XUORES Security key:
I XUORES Q 1
;
;Tests for Visitors:
I +$G(XUF),$D(^VA(200,"BB","VISITOR",XUDA)) Q 1
I $D(^VA(200,"BB","VISITOR",XUDA)) Q "0^VISITOR"
;
;Default:
Q "0^NOT A PROVIDER"
;

Notice above that any person with a value in field 0;3 (ACCESS CODE)
leads to an immediate label as being a provider.
I have numerous old employees that have a valid termination date. But
the act of terminating them didn't automatically remove their access
code. So now they are being returned as valid users.

This seems like a bug.

Kevin

On Nov 4, 6:49 pm, "David Whitten" <whit...@worldvista.org> wrote:
> Entry in the REMOTE PROCEDURE File
>

...

[kdt...@gmail.com]

On Nov 4, 7:55 pm, "kdt...@gmail.com" <kdt...@gmail.com> wrote:
>
> This seems like a bug.
>
> Kevin
>

To fix this "bug", I changed it to this on my system, and now it acts
as it should. Essentially I changed the order of the tests. If
first screens out terminated users.

Kevin

PROVIDER(XUDA,XUF) ;See if user qualifies as a CPRS provider
;XUDA = IEN of Record in New Person File
;XUF = Flag to control processing
; 0 or not passed, do not include Visitors
; 1 include Visitors
N %,X1,X2,XUORES
;Test to see if XUDA Passed:
I '$D(XUDA) Q ""
;
;Test for valid IEN:
S X1=$G(^VA(200,+$G(XUDA),0)),X2=$S(X1="":"",1:1) Q:X2="" ""
;
;See if user has XUORES Security Key:
S XUORES=$D(^XUSEC("XUORES",XUDA))
;
;Test for Access Code:

;"//kt original line --> I $P(X1,U,3)]"" Q 1

;
;Test for a Termination Date not in the Future
;AND Not owner of XUORES Security Key:
S %=$P(X1,U,11) I %>0,%'>DT,'XUORES Q "0^TERMINATED^"_%
;
;Test if user has XUORES Security key:
I XUORES Q 1
;
;Tests for Visitors:
I +$G(XUF),$D(^VA(200,"BB","VISITOR",XUDA)) Q 1
I $D(^VA(200,"BB","VISITOR",XUDA)) Q "0^VISITOR"
;

;Test for Access Code: ;"//kt move line down from above.
I $P(X1,U,3)]"" Q 1 ;"//kt move line down from above.

[Woodhouse Gregory]

On Nov 4, 2008, at 4:55 PM, kdt...@gmail.com wrote:

Dave, (and  anyone else)

Thanks for looking at this with me.

The line in NP!^ORWU1 is below

..I +$G(ORALLUSE)=0,'$$PROVIDER^XUSER(ORIEN1) Q  ; Terminated users.

I think this says that if ORALLUSE=0, then check $

$PROVIDER^XUSER(ORIEN1), and if that is false, then quit (don't return

user on list.)

Yes.

[Skip Ormsby]

Kevin are you using the 'User Management' option - Deactivate a User to terminate your users?

-skip

[kdt...@gmail.com]

Skip,

No. Is that the problem? I was using Edit Existing User, and setting
the DISUSER field and the termination date from the screenman form.
Shouldn't that inactivate a user?

But even if I used the wrong method to deactivate a user, don't you
agree that a person that has a termination date not in the future
should not be considered a provider? If you switch the order of tests
as I did in my prior post, it makes more sense.

Thanks
Kevin

[David Whitten]

I would even go so far as to wonder if this subroutine is mis-named.
currently, it looks like a pretty good bit of code to see if someone is
an active USER, but being a PROVIDER is more than being a user, methinks.

Right now, if you have a actively employed janitor who has an account
in your system, the code allows that person to be chosen as a possible
additional signer.  I think there is a real problem with that kind of business logic.

David

[Rich Vertigan, CPRS Developer (retired)]

The "PROVIDER" tag is left over from whatever earlier logic was
contained there before Skip introduced the more comprehensive logic
you see now. It was probably not renamed so as not to break existing
functionality that already called it. I don't remember what that
earlier logic was, but I think at one time it was more appropriate to
having the PROVIDER tag.

> > > >>>>>> Kevin- Hide quoted text -
>
> - Show quoted text -

[Skip Ormsby]

You are correct Rich, and I too have long forgotten what was contained in the original code. 
Folks the development rules within the VA are such that the owner of the file/code involved is responsible for making the changes or giving the 'Ok'.  For example, because DD belongs to FileMan, I had to approve all DD changes, even though the file in question belonged to the package that was making a DD change. 
In the case of the the code in question, the code belongs to Kernel and I worked very closely with the OR team for the specifications.  The reason the code was changed was because the routine: ORWU1 was $Ordering through the "B" xref of the New Person(#200) and was taking a very long time to create a list, which was including the Postmaster, Shared Mail, etc. One of the first things I did was ask the DBA at the time the question - Who is a Provider?  And the answer was - Anyone who provides a service to the patient.  So working with OR team, we came up with the code you see now, minus the code that tests for the XUORES security key and the AUSER 'new style' cross reference (a short list) which is now used by ORWU1.
So why was the XUORES security key check added?  It is designed for those providers who do not have access to VistA but are consulted with about a patient.  For example, there are VA Hospitals that regularly enter a patient consult with a Medicine Man.  It is designed for that that kind of of situation.
Kevin to answer your question about the difference between Termination and DISUSER, DISUSER is a method of 'suspending' a users access to VistA.  For example, at the hospital I was at, we were affiliated with the local university, so we had residents who would rotate in and out.  I left the hospital in 1998 so I am speaking now in that time frame.  Before we had the ability to DISUSER, we were required to Terminate a resident, even though we knew they would be back on the next rotation.  The trouble was, termination cause all sorts of unintended consequences, which in turn caused headaches in Pharmacy and Lab. just to name a few.  However with DISUSER we could suspend the resident's access but not cause the unintended consequences and when you reomved the DISUSER flag, they were allowed VistA access without further ado. When you DISUSER a user they stay on the "AUSER" xref for 540 days (assuming you have the nightly option: XUAUTODEACTIVATE       Automatic Deactivation of Users scheduled) this is to allow enough time for Rxs, etc. orders to clear.  Termination of course is the hammer down.  You certainly would not want to have outstanding orders and folks acting on those orders for a physician who lost his/her license.

-skip

[kdt...@gmail.com]

Fair enough, Skip. Thanks for this reply.

So it sounds like I was not terminating old users properly.

Thanks
Kevin

> ...
>
> read more »