KuY | Atkk
Korjauspaketti 9
|
KuY | Atkk |
Korjauspaketti 9 |
Hellevi.Ruonamaa@uku.fi |
Näillä sivuilla on ensin yhteenveto korjauksista ja muutoksista ja sen jälkeen on kunkin VA:n korjauksen sisällöstä tarkempi kuvaus. Muutoksia käsitellään tarkemmin 5. Kernel-FixIT-päivässä 10.2.2004 Kuopiossa.
Uusia globaaleja:
^MXML- ja ^XUSSPKI-globaalit
Uusi rutiinien nimialue:
MXML-alkuiset rutiinit.
Tiedostoihin tulevat muutokset:
Korjauspaketin mukana tulee muutoksia seuraaviin tiedostoihin:
FILE: SIGN-ON LOG
KAIKKI KENTÄT
FILE: SPOOL DOCUMENT
FIELD NUMBER: NAME
FILE: INSTITUTION
KAIKKI KENTÄT
FILE: BUILD
DD NUMBER: FILE
FIELD NUMBER: RESOLVE
POINTERS
FIELD NUMBER: DATA COMES
WITH FILE
FILE: ROUTINE
FIELD NUMBER: PATCH LIST AT CHECKSUM TIME
FIELD NUMBER: KIDS INSTALL DATE
DD NUMBER: PATCH (sub-file)
FILE: TASKMAN SITE PARAMETERS
FIELD NUMBER: TASKMAN JOB LIMIT
FILE: KERNEL HENKILÖ
FIELD NUMBER: KOTIPUHELIN
FIELD NUMBER: TYÖPUHELIN
FIELD NUMBER: LISÄPUHELIN 3
FIELD NUMBER: LISÄPUHELIN 4
FIELD NUMBER: COMMERCIAL PHONE
FIELD NUMBER: FAX NUMERO
FIELD NUMBER: DISUSER
FIELD NUMBER: CURRENT DEGREE LEVEL
FIELD NUMBER: PROGRAM OF STUDY
FIELD NUMBER: LAST TRAINING YEAR
FIELD NUMBER: DEA#
FIELD NUMBER: NON-VA PRESCRIBER
FIELD NUMBER: TAX ID
FIELD NUMBER: EXCLUSIONARY CHECK PERFORMED
FIELD NUMBER: DATE EXCLUSIONARY LIST CHECKED
FIELD NUMBER: ON EXCLUSIONARY LIST
FIELD NUMBER: EXCLUSIONARY CHECKED BY
FIELD NUMBER: PATIENT SELECTION LIST
FIELD NUMBER: MULTIPLE SIGN-ON
FIELD NUMBER: MULTIPLE SIGN-ON LIMIT
FIELD NUMBER: PRIMARY MENU OPTION
DD NUMBER: CPRS TAB (sub-file)
DD NUMBER: SECONDARY MENU OPTIONS (sub-file)
FIELD NUMBER: SECONDARY
MENU OPTIONS
DD NUMBER: ACCESSIBLE FILE (sub-file)
FIELD NUMBER: DATA DICTIONARY ACCESS
FIELD NUMBER: DELETE ACCESS
FIELD NUMBER: LAYGO ACCESS
FIELD NUMBER: READ ACCESS
FIELD NUMBER: WRITE ACCESS
FIELD NUMBER: AUDIT ACCESS
DD NUMBER: PERSON CLASS (sub-file)
FIELD NUMBER: Effective
Date
DD NUMBER: VISITED FROM (sub-file)
FILE: XML ENTITY CATALOG
KAIKKI KENTÄT
FILE: PERSON CLASS
KAIKKI KENTÄT, DATA MUKANA
FILE: PROGRAM OF STUDY
KAIKKI KENTÄT
FILE: PKI Digital Signatures
KAIKKI KENTÄT
FILE: PKI CRL URLS
KAIKKI KENTÄT
FILE: KERNEL SYSTEM PARAMETERS
FIELD NUMBER: PKI Server
FIELD NUMBER: DEFAULT MULTIPLE SIGN-ON
FIELD NUMBER: DEFAULT MULTIPLE SIGN-ON LIMIT
DD NUMBER: VOLUME SET (sub-file)
FIELD NUMBER: MAX SIGNON
ALLOWED
FILE: PARAMETER DEFINITION
KAIKKI KENTÄT
FILE: ALERT
DD NUMBER: ALERT DATE/TIME (sub-file)
FIELD NUMBER: DAYS FOR
BACKUP REVIEWER
Kuopion yliopistossa tehdyt muutokset:
1. Kernelin virhelista näyttää päiväkohtaisella
listalla myös option nimen, jos sellainen on saatavissa. Muutos tulee
rutiineihin XTER1A (virheiden näyttö) ja %ZTER (ZTER) (muuttujien
ristiviittauksen teko). Tämä suurentaa virhelogin tilavarausta,
sillä se tekee automaattisesti muuttujien indeksoinnin. Alkuperäisessä
versiossa indeksointi tapahtuu vasta kun virhe on valittu katsottavaksi.
Tällä hetkellä muutokset ovat kommenteissa ja otettavissa
haluttaessa esiin. Riveillä on merkintä ***HR M2 15May2003
Muutos auttaa erityisesti RPCBroker-sovellusten yhteydessä ilmenevien
virheiden selvittämistä.
2. Vaikka käyttäjän VERIFY NEVER EXPIRES-kentän
arvoksi oli asetettu ’Yes’, päätekäytössä pyydettin
kuitenkin vaihtamaan salasanaa. Korjatussa versiossa pyyntö on estetty.
Kaikki VA:n korjauspakettien muutokset:
XU*8*230: Subject: NEW FIELDS IN NEW PERSON FILE FOR CPRS READ-ONLY
XU*8*228: Subject: Fix to the BSA formula
XU*8*232: Subject: FIX ERRORS IN XUAF4
XU*8*233: Subject: ADDING KIDS NOTIFICATION FOR ESS
XU*8*156: Subject: Menu Rebuild Rewrite -- Part 1
XU*8*157: Subject: Menu Rebuild Rewrite -- Part 2
XU*8*225: Subject: ZISTCP and ZU fixes
XU*8*245: Subject: Manila RDV fix.
XU*8*147: Subject: MUTUALLY EXCLUSIVE KEYS ASSIGNMENT
XU*8*237: Subject: FIX TERMINATED USER ERROR
XU*8*243: Subject: Fix Count for 'Remove a TYPE of error'
XU*8*174: Subject: MODIFY FORWARDING OF UNREAD ALERTS
XU*8*238: Subject: Remove Conflicting Command
XU*8*244: Subject: XGKB fix.
XU*8*217: Subject: Institution file & the Reasonable Charges project
XU*8*241: Subject: ZIS Prohibited time fix.
XU*8*220: Subject: Device Lookup API
XU*8*236: Subject: Hui/VHA CIO SD&D Pharmacy Data Interchange
XU*8*218: Subject: Institution file & VA/Dod CMOP project
XU*8*259: Subject: Disable XUHUI Protocols
XU*8*239: Subject: Hui/VHA CIO SD&D Pharmacy Data Interchange
XU*8*254: Subject: ACCESS REMOTE DATA
XU*8*247: Subject: Edit 'Edit an Existing User' form
XU*8*191: Subject: Support for Cache on OpenVMS
XU*8*255: Subject: Adds/Edits to PERSON CLASS DD
XU*8*260: Subject: CORRECT MISSPELLING IN STATE FILE
XU*8*252: Subject: AUTO SIGN-ON DISABLES DELETE KEY
XU*8*222: Subject: 7 NOIS and 2 E3R fix.
XU*8*246: Subject: ADDRESS INDEXING FOR GMT
XU*8*271: Subject: Fix to XU*8*191 bug.
XU*8*266: Subject: Undef at PCHK2+1~XUHUI
XU*8*264: Subject: PERSON CLASS UPDATE
XU*8*189: Subject: XLFDT Midnight conversion
XU*8*229: Subject: KIDS Fixs
XU*8*272: Subject: PHONE FIELDS
XU*8*274: Subject: Fix to Tasked DEACTIVATE user.
XU*8*267: Subject: DEA API and INST DEA #
XU*8*263: Subject: REINDEX THE USER KEY'S [XUSER KEY RE-INDEX] FIX
XU*8*269: Subject: Add LOCKING to XUESSO1.
XU*8*257: Subject: ISO Menu
XU*8*276: Subject: INFORMATIONAL PATCH FOR NEW EMPLOYEE WITH ONE NAME
XU*8*278: Subject: Cache/NT %ZIS4 fix.
XU*8*240: Subject: STDNAME~XLFNAME: CHECK FOR SUFFIXES IMMEDIATELY
AFTER COMMA
XU*8*282: Subject: Person Class Expired
XU*8*258: Subject: Multiple Sign on Update
XU*8*262: Subject: MFS / ZL7 Generic Master File
XU*8*286: Subject: Micro Surgery String Length Problem
XU*8*224: Subject: Fix KSP call.
XU*8*273: Subject: Switch Identities Fix
XU*8*280: Subject: New version XLFDT Midnight fix.
XU*8*301: Subject: Name Standardization Wrong File Component Deletion
XU*8*253: Subject: Merging Users' Menu Structures
XU*8*296: Subject: NEW PERSON DD CHANGES
XU*8*297: Subject: SHOW MORE OF THE SPOOL DOC NAME
XU*8*300: Subject: PERSON CLASS API
XU*8*277: Subject: Stop USERINFO errors.
XU*8*291: Subject: CONVERT SPOOL DOC TO MAILMAN MESSAGE
XU*8*251: Subject: CLINICAL TRAINEE CORE DATASET
XU*8*283: Subject: PKI pilot support
XU*8*288: Subject: Updated DEA~XUSER API.
XU*8*307: Subject: State File Check/Clean-up
XU*8*304: Subject: KIDS FIXES
XU*8*310: Subject: FIX DEVICE FORMS
XU*8*313: Subject: BCMA Contingency Support
XU*8*308: Subject: SUPPRESS SERVER BULLETIN
XU*8*324: Subject: Allocation Failure During Transmission
XU*8*316: Subject: Reporting Options for Alerts
XU*8*311:Subject: TRANSITIONAL PHARMACY BENEFIT PROJECT - PHASE II
XT*7.3*58: Subject: MXML parser
XT*7.3*57: Subject: Merge BCMA data
XT*7.3*61: Subject: XINDEX UPDATE
XT*7.3*59: Subject: XTRMON FIX
XT*7.3*63: Subject: Fix to missing line in XPAR.
XT*7.3*64: Subject: Lookup field for Parameter Definition file
XT*7.3*66: Subject: XINDEX check for patch number
XT*7.3*67: Subject: XML parsing fix
XT*7.3*72: Subject: Add Column Headings to Parameter Options
XT*7.3*74: Subject: ADJUST PARAMETER TOOLS HELP DISPLAY
XT*7.3*69: Subject: Undef EXTPTR~XPARDD fix.
XT*7.3*76: Subject: FIX BUILD~XTRUTL
Alkuperäisten korjausten kuvaukset:
XU*8*230
Subject: NEW FIELDS IN NEW PERSON FILE FOR CPRS READ-ONLY
1. This patch was created to allow CPRS to restrict access of
users in the NEW PERSON (#200) file to specific CPRS GUI tabs.
XU*8*228
Subject: Fix to the BSA formula
Problem: The Body Surface Area calculation in XLFMSMT returned the wrong
values. A check of the Web for BSA showed that the formula had been
entered switching the powers.
Fix: Enter the formula correctly. Sample value BSA(100,43)
= 1.00
XU*8*232
Subject: FIX ERRORS IN XUAF4
Th function $GET was added to the sub-functions STATUS^XUAF4(%) and
NS^XUAF4(IEN) to protect against a bad pointer in another file.
XU*8*233
Subject: ADDING KIDS NOTIFICATION FOR ESS
Patch XU*8*185 modified KIDS to send a copy of the installation message when a facility installs a patch or a package back to the VHAESSRESOURCE exchange user.
This patch XU*8*233 addresses the issue of a sequence number of a patch
not being sent back inside the message. This is in anticipation of the
Enterprise Support Solution (ESS) system replacing NOIS.
XU*8*156
XU*8*157
Subject: Menu Rebuild Rewrite -- Parts 1 & 2
NOTE: BECAUSE THE NEW DATA STRUCTURE IS STORED IN THE OPTION FILE YOU CAN EXPECT THIS FILE TO INCREASE IN SIZE EQUAL TO THE SIZE OF YOUR CURRENT ^XUTL("XQO") GLOBAL. IN SEATTLE THIS AS 13 TO 20 MEGABYTES. SINCE ^DIC(19) IS JOURNALLED YOU SHOULD EXPECT A CORRESPONDING INCREASE IN JOURNAL SPACE AS WELL WHEN THE MENUS ARE REBUILT.
This patch changes the way in which the compiled menus in the global ^XUTL are built. It prevents the jump system from becoming unavailable for long periods of time while the global is rebuilt. Instead of deleting ^XUTL and then rebuilding it, the menu trees are first built into the ^TMP global and then merged into a new cross reference of the Option File [^DIC(19,"AXQ")]. When a user logs onto the system the menu system looks at ^XUTL to be sure that the trees needed for that user to jump are available in ^XUTL. If they are not, the trees for that user' Primary Menu, Secondary Menus, and the Common Options are merged into ^XUTL from ^DIC(19,"AXQ"). This cross-reference, then, holds the master copy of the jump trees which are made available in ^XUTL only as they are needed.
A change was also made to the user reactivation software because when a user is reactivated there is no guarantee that his or her jump trees will be present in the ^DIC(19) cross-reference. If they are not present then the software queues a small TaskMan job to build them so that the user can use the up-arrow jump.
A new menu is created [XQBUILDMAIN] which has 4 options on it. "Is There
a Menu Rebuild Running Right Now" [XQRIGHTNOW] tells you if there is menu
rebuild activity on your system. "Kick Off Micro Surgery" [XQKICKMICRO]
will force the menu system to see if there is work to do for Micro Surgery.
"Most Recent Menu Rebuilds" [XQSHOWBUILDS] shows a list of the recent rebuild
activity on your system. "Build Primary Menu Trees" [XQBUILDTREE]
is the tradition menu tree building option, which wasdeleted by XU*8*156
and re-installed on this menu.
XU*8*225
Subject: ZISTCP and ZU fixes
Problem: The call to Intersystems' license share should only be called for Telnet and TCP connections. Not for LAT. Fix: This patch changes ZU to check the type of device and only call the Intersystems License share code for Telnet connections, this is done for both DSM and Cache.
Problem: TCP clients on Cache were opened in 'mumps' mode, this caused some problems when talking with DSM systems. This caused problems with HL7. Fix: This patch changes the way that TCP devices are opened on Cache systems to be in packet mode. This makes it behave more like the way that DSM does.
Problem: ZISTCPS would halt when told to stop. When called from a job started by Taskman the task would not be cleaned up. This caused problems with HL7. Fix: To have ZISTCPS just QUIT when told to stop.
Problem: VMS and DSM utilities require the job number in hex, but Taskman
listing would just show the job number in decimal. Fix: In a task listing
of running tasks, include the job number in hex whenthe job numbers is
greater that 2048.
XU*8*147
Subject: MUTUALLY EXCLUSIVE KEYS ASSIGNMENT
This patch corrects the following issue:
Field: MUTUALLY EXCLUSIVE KEYS(#5) in File: SECURITY KEY(#19.1) now allows key management personnel to:
1. Enter a security key that should not be given to anyone, see example #1.
2. Or should not be held with another security key(s), see example #2.
3. Option:Enter/Edit of Security Keys [XUKEYEDIT] has been revised to allow input of the Field: MUTUALLY EXCLUSIVE KEYS(#5) in File: SECURITY KEY(#19.1). For example using the Security Key 'XM GROUP EDIT MASTER':
NAME: XM GROUP EDIT MASTER
DESCRIPTIVE NAME: Edit other users' mail groups
DESCRIPTION: People who need to be able to edit
other users' mail groups and add new users to them should be assigned
this key.
Holders of this key may edit any mail group, except personal mail groups. (Personal mail groups are those which only the organizer may edit or use.)
The following users should NOT be given this key, because they already
possess the privilege this key grants:
- Holders of the XMMGR key.
- Clinical Application Coordinators, as identified in
file 8930, USR Class, belonging to the TIU package.
Select Key Management Option: ENter/Edit of Security Keys
Select SECURITY KEY NAME: XM GROUP EDIT MASTER
DESCRIPTIVE NAME: Edit other users' mail groups Replace
PERSON LOOKUP:
KEEP AT TERMINATE:
DESCRIPTION:. . .
. . .
Holders of this key may edit any mail group, except personal
mail groups. (Personal mail groups are those which only the organizer
may edit or use.)
The following users should NOT be given this key, because they
already possess the privilege this key grants:
- Holders of the XMMGR key.
- Clinical Application Coordinators, as identified in file 8930
USR Class, belonging to the TIU package.
Edit? NO//
Select SUBORDINATE KEY:
GRANTING CONDITION:
Select MUTUALLY EXCLUSIVE KEYS: XMMGR
Are you adding 'XMMGR' as a new MUTUALLY EXCLUSIVE
KEYS (the 1ST for this SECURITY KEY)? No// Y (Yes)
Select MUTUALLY EXCLUSIVE KEYS:
4. Finally a New option [XUEXKEY]:
Allocate/De-Allocate Exclusive Key(s) [XUEXKEY]
**> Locked with XUEXKEY
has been created to allow Allocation and De-Allocation of a Mutually
Exclusive key(s) to a primary key. This option has been added to
the 'Key
Management [XUKEYMGMT]' and requires that the 'Security Key'
XUEXKEY to be allocated before it can be accessed. For example:
Select Key Management Option: Allocate/De-Allocate Exclusive
Key(s)
Select Primary Allocated Key(s): ZZKEN1
Select MUTUALLY EXCLUSIVE KEYS: ZZKEN1
Are you adding 'ZZKEN1' as a new MUTUALLY EXCLUSIVE
KEYS (the 1ST for this SECURITY KEY)? No// Y (Yes)
Select MUTUALLY EXCLUSIVE KEYS:
Example #1:
===========
To allow a key NOT to be accessed by any user, set the primary key
Exclusive to itself. An example would be setting key 'ZZKEN1' as
Mutually Exclusive Key to 'ZZKEN1', any attempt to give this key to a user
will result in the below message being displayed:
"Key 'ZZKEN1' may not be given to any user at this time no action taken"
Select Key Management Option: Allocation of Security Keys
Allocate key: ZZKEN1
Another key:
Holder of key: ORMSBY,SKIP
SO
Another holder:
You've selected the following keys:
ZZKEN1
You've selected the following holders:
ORMSBY,SKIP
You are allocating keys. Do you wish to proceed? YES//
ZZKEN1 being assigned to:
ORMSBY,SKIP
Key 'ZZKEN1' may not be given to any user at this time no
action taken
Example #2:
===========
Using the 'XM GROUP EDIT MASTER' key as an example, by setting the
Mutually Exclusive field with 'XMMGR', the user will not be able to be
given access to both keys simultaneously. Should any attempt be made
to assign the 'XM GROUP EDIT MASTER' key to a user that has already been
assigned the key 'XMMGR', the following message will be displayed:
"You are not AUTHORIZED key 'XM GROUP EDIT MASTER' with EXCLUSIVE key
'XMMGR' no action taken"
Select Key Management Option: Allocation of Security Keys
Allocate key: XM GROUP EDIT MASTER
Another key:
Holder of key: ORMSBY,SKIP SO
Another holder:
You've selected the following keys:
XM GROUP EDIT MASTER
You've selected the following holders:
ORMSBY,SKIP
You are allocating keys. Do you wish to proceed? YES//
XM GROUP EDIT MASTER being assigned to:
ORMSBY,SKIP
You are not AUTHORIZED key 'XM GROUP EDIT MASTER' with EXCLUSIVE
key
'XMMGR' no action taken
XU*8*237
Subject: FIX TERMINATED USER ERROR
This patch XU*8*237 adds $S and $G to the line SHO+1^XQLOCK to fix
problem (undefined variable) that occurred when an application coordinator
tried to use the OPTION: All the Keys a User Needs [XQLOCK1] and selected
a non-active person in FILE: New Person (#200) with no primary menu and
no ^VA(200,IEN,201) global defined.
XU*8*243
Subject: Fix Count for 'Remove a TYPE of error'
The routine XTERPUR is modified to update the error count for
the day when a user selects the option: Remove a TYPE of error [XUERTRP
TYPE].
XU*8*174
Subject: MODIFY FORWARDING OF UNREAD ALERTS
Alerts are used to send time sensitive notifications for information or for further processing. When created, some alerts may specify a number of days for forwarding to a supervisor or to e-mail surrogates. If the alert remains unread after this period of time the alert is forwarded, if possible, to a supervisor or e-mail surrogate as indicated. A problem has been reported when after the alert has been forwarded to the backup individual, it is repeatedly reforwarded on following days until the alert is removed either manually or as a result of normal alert removal (SHR-0100-70069). This patch corrects this behavior, so the alert will only be forwarded once.
In addition, there have been some who wanted these unread alerts forwarded to a specific individual, e.g., someone in QA, who would monitor unread alerts and could insure forwarding to proper individuals if they could not process them fully (ASH-0100-31970). To assist in this capability, the current patch also adds a 'DAYS FOR BACKUP REVIEWER' (#.15) field to the 'ALERT DATE/TIME(#1)' subfile of the 'ALERT(#8992)' file. In addition, it adds an 'XQAL BACKUP REVIEWER' entry in the PARAMETER DEFINITION (#8989.51) file, and an option, Set Backup Reviewer for Alerts [XQAL SET BACKUP REVIEWER] on the Alert Management [XQALERT MGR] menu.
If an alert is generated with a number of days specified in the
variable XQAREVUE, after the specified number of days has passed if the
alert remains unread, and if a valid entry is present in the ALERT BACKUP
REVIEWER parameter for the User, Service, Division, or System entities,
the alert will be forwarded to the indicated individual at the lowest level
found for processing.
XU*8*238
Subject: Remove Conflicting Command
This patch removes a command that is not necessary and conflicts with the M-to-M Broker.
Other than removing this one command, this patch is equivalent to XU*8*234.
For those sites which do not install various packages, e.g., CMOP, etc.,
this patch may be installed without installation of patch XU*8*234 (which
was released as a part of YS*5.01*71). However, if such a site subsequently
installs XU*8*234 after this patch, this patch should be installed again.
XU*8*244
Subject: XGKB fix.
Problem reported by Gail Thomas with XQORM1 Routine - CAPRI (GUI) View Registration: While working on a broker call that will allow CAPRI GUI to View Registration, the user is calling routine EN1^DGRP and storing the data into a file. While testing the broker call the below routine (which is embedded within DGRP) would change the output device back to the terminal. This causes some of the data to be stored to the file and the other to the screen. Routine XQORM1 calls XGF that calls XGKB to reset escape processing. The code uses $I when setting up escape processing but uses IO(0) for the reset.
Fix: To use $I for the reset also.
XU*8*217
Subject: Institution file & the Reasonable Charges project
XU*8*241
Subject: ZIS Prohibited time fix.
Problem: The Site found that they had errors from midnight until 00:01 am. The cause turned out to be data in the FILE: DEVICE FILE (#3.5) that made the "TIME" node non-null, but not with a prohibited time. This caused the PROHIBITED TIMES check to screen out the device when the current time was between midnight and 00:01 am.
Fix: To check only the correct piece of the node.
Problem: Sites can now run more that 1000 jobs on a single box.
The Database Description (DD) for the FIELD: MAX SIGNON ALLOWED (#2) of
the FIELD: VOLUME (#41) of the FILE: KERNEL SYSTEM PARAMETERS (#8989.3),
limited this value to 1000. Fix: The DD for the FIELD: MAX SIGNON ALLOWED
(#2) of the FIELD: VOLUME (#41) of the FILE: KERNEL SYSTEM PARAMETERS (#8989.3)
was increased to 10000. The FIELD: TASKMAN JOB LIMIT (#6) in the
FILE: TASKMAN SITE PARAMETERS (#14.7) was increased to 9999.
XU*8*220
Subject: Device Lookup API
This patch adds a new routine, XUDHGUI, that will provide developers an API to retrieve the first 20 devices that meet the specifications passed. In addition to the documentation supplied in this patch check the Kernel Web Page for more information on Kernel API's:
http://vista.med.va.gov/kernel/apis/device^xudhgui.htm
------------------------------------------------------
or
http://vaww.vista.med.va.gov/kernel/apis/device^xudhgui.htm
-----------------------------------------------------------
DEVICE^XUDHGUI(.LIST,STARTING POINT,DIRECTION,RIGHT MARGIN RANGE)
.LIST = Where the data will be returned
STARTING POINT = Where to start the $ORDERing
of the Global.
"P" will only return devices whose name starts
with "P", "P*" will return up to 20 devices
the first starting with "P".
DIRECTION = Whether to $ORDER up or down from starting point
RIGHT MARGIN RANGE = To specify a width
range of devices:
For exact width: "132-132"
For at least width: "132"
For a range: "80-132"
Returned: IEN^NAME^DISPLAY NAME^LOCATION^RIGHT
MARGIN^PAGE LENGTH
XU*8*236
Subject: Hui/VHA CIO SD&D Pharmacy Data Interchange
This patch is in support of the Hui/VHA CIO SD&D Pharmacy Data Interchange project. The project provides a method for the one-way electronic transfer of prescription orders from an external system to VistA.
In summary this patch consists of the following parts:
1. Three routines.
2. Two new style cross-references to monitor changes to
specific New
Person File fields. See the 'Documentation
Changes' section for
details.
3. Two new protocols. See the 'Documentation Changes'
section for
details.
If sites do not wish to utilize this functionality, nothing needs to
be done besides installing the patch. If sites want to utilize this functionality,
more information on the setup and the data elements are documented on the
VistA Documentation Library.
XU*8*254
Subject: ACCESS REMOTE DATA
Patch XU*8*254 modifies routine XUESSO1 to fix a problem which may have
been introduced by patch XU*8*245: Users were unable to access remote data
via CPRS (Computerized Patient Record System).
XU*8*247
Subject: Edit 'Edit an Existing User' form
1) This patch removes the message "USER has no ACCESS CODE", which appeared in the "Edit an Existing User" Screen of the XUREACT USER Form when a user selected the option: REACTIVATE A USER [XUSERREACT] with a person having an access code.
2) The field DOB (#5) of New Person file (#200) is added on the "Edit an Existing User" Screen of the XUEXISTING USER form.
3) This patch also deletes the "AF" cross-ref of New Person file
#200 for accounts that may have installed XU*8.0*138 entered as error.
XU*8*191
Subject: Support for Cache on OpenVMS
1. This patch introduces Support for Cache on OpenVMS, as requested by the National VistA Support (NVS) team.
2. Part of the failure in this check is that the syntax check for the Directory was not complete. The improved check is included for both Cache and DSM versions of %ZISH.
3. $$STATUS^%ZISH did not correctly check for end-of-file. This was because Cache in version less than 3.0 used the error trap to signal when a EOF was reached. With Cache 3.0 this has been fixed and %ZISH has been recoded to work as expected.
4. ZTMGRSET was updated to show that it supported Cache/VMS.
XU*8*255
Subject: Adds/Edits to PERSON CLASS DD
This is an enhancement patch. The patch adds and edits Data Dictionary
(DD) of Person Class file (#8932.1). The enhancement was requested by the
National Uniform Claim Committee (NUCC).
XU*8*252
Subject: AUTO SIGN-ON DISABLES DELETE KEY
Problem: After Auto sign-on was turned on, the delete key was disabled
from the screen man full screen editor. The site used VT320 and the terminal
type would be set to VT100 but only if auto sign-on was in use and the
client agent was running.
Fix: To save off the home device characteristics before calling the
client agent as part of the auto sign-on.
XU*8*222
Subject: 7 NOIS and 2 E3R fix.
Problem: The CPRS Parameter information that is viewable from User Inquiry
is not useful. The package defaults are shown for users that do not have
specific CPRS entries. This made it confusing as to what users had special/non-standard
set-ups.
Fix: The call is changed to show only entries specific to the user.
Problem: Some combinations of security keys would not wrap correctly.
If sent to a device that didn't wrap, the data was not printed and it looked
like the user did not have all the security keys.
Fix: Correct the print routine in XUSER1.
Problem: The option "Output routines", "Input Routines" get a 'noroutine'
error on Cache
Fix: Add cache to the list of both options.
Problem: The TaskMan cleanup routine XUTMK failed to delete a local
variable in a loop and if there were sufficient data it would cause a STORE
error.
Fix: Kill the local variable in the loop.
Problem: When a user had the DISUSER flag set by the "XUAUTODEACTIVATE"
scheduled task, the user could still access old "Continue" options.
Fix: When the "XUAUTODEACTIVATE" sets the DISUSER flag it will remove
the "Last Option" entry from file 200, if the users Primary or Secondary
menu is changed the "Last Option" entry will also be removed.
Problem: If the DISUSER flag was deleted instead of changed to NO then
the trigger on this field would not run to set today's date into field
202.04.
Fix: Add a DELETE code to the cross reference.
Request: "Noticed that the routine MANUAL^XUINPCH2 contained in patch
XU*8.0*159, did the clean up on terminated users by stuffing an expiration
date on the person class code. Will this feature be added to the
XUSERDEACT option under User Management, so future deactivations on users
will stuff a date in the expiration date field for person class code?"
Fix: Added to the XUSTERM routine to set an expiration date for the
person class.
Problem: Parameter entries in file 8989.5 for an individual user are
not deleted when the user is terminated.
Fix: Added to XUSTERM a call to a new entry point DELUSR^XPAR3.
This fix will need patch XT*7.3*60 to start working.
XU*8*271
Subject: Fix to XU*8*191 bug.
Problem: Patch XU*8*191 caused Cache/NT sites to loose the ability to
correctly read HFS files. One of the applications affected is KIDS.
Fix: Check the OS type and set the correct parameter for normal file
reads. i.e. for VMS it is "RV" and for NT it is "RS".
XU*8*264
Subject: PERSON CLASS UPDATE
Patch XU*8*264 updates data for Person Class file (#8932.1). Twoexisting
records (180 and 659) are inactivated, and sixty new records (675 through
734) are added to Person Class file. This patch has been requested by Information
Assurance to keep Person Class current with recent changes to the NUCC
(National Uniform Claims Committee) Healthcare Provider Taxonomy.
XU*8*189
Subject: XLFDT Midnight conversion
During the investigation for patch XU*8*168 it was found that many of the date functions did not handle midnight correctly. This patch makes the treatment of midnight consistent across all functions in XLFDT. Midnight is represented as 58882,0 in M $H and as 3020319.24 in FM. Both of these are in keeping with the ISO 8601 standard that delineates how it will be represented.
Problem: A call of W $$FMADD^XLFDT(3010723,-3,0,0,0) returns 3010720
But a call of W $$FMADD^XLFDT(3010723,0,-72,0,0) returns 3010719.
These should return the same value.
Fix: The code corrected to handle negative hours that are a multiple
of days.
Problem:
1. If the call to extrinsic function $$HL7TFM^XLFDT(HL7date/time[,Local/Uct])
is made with the second parameter "L" but the value of the first parameter
did not have an offset, the call will abend with an undefined error on
variable %TZ at HL7TFM+10^XLFDT.
Fix: The code was changed to see that %TZ always has a value.
2. A second issue that this raises is how to classify the date/time
when there isn't a timezone. From the HL7 doc's it should be considered
to be a local time.
Fix: If the HL7 date/time doesn't have a timezone, see that it is considered
as a local time.
Problem: If the call to HL7TFM^XLFDT was made with just a YYYY or YYYYMM it would get treated as a time and not a date.
Fix: To fix this a new third parameter has been added to the call to indicate that the value to be converted is just a time value. This allows the full range of HL7 dates to be converted.
Range checks were added to many of the calls. It is assumed that
input dates have been validated by the creating application.
The range of accepted $H dates: "2,0" to "99999,86399".
The range of accepted FM dates: 1410102 to 4141015.
The range of accepted HL7 dates: 18410102 to 21141015.
From ISO 8601:
5.3.2 Midnight
The complete and extended representations for midnight, in accordance
with 5.3.1, shall he expressed in either of the two following ways:
Basic format
Extended format
a) 000000
00:00:00 (the beginning of a day);
b) 240000
24:00:00 (the end of a day).
The representations may be reduced in accordance with 5.3.1.4.
NOTES
1. Midnight will normally be represented as (0000) or (2400)
2. The choice of representation a) or b) will depend upon any
association with a date, or time period.
3. The end of one day (2400) coincides with (0000) at the start
of the next day, e.g. 2400 on 12 April 1985 is the same as 0000 on 13 April
1985. If there is no association with a date or time period both a) and
b) represent the same clock time in the 24-hour timekeeping system.
The functions changed are HTFM, FMTH, HDIFF, FMDIFF, HADD and FMADD.
The biggest change is in HADD and FMADD and their rollover from one
day to the next.
Time zone values
EST -0500
CST -0600
MST -0700
PST -0800
Time zone offset example.
UTC GMT EDT EST CDT
CST MDT MST PDT PST
1000 6 AM
5 AM 4 AM 3 AM
2 AM
1100 7 AM
6 AM 5 AM 4 AM
3 AM
1200 8 AM
7 AM 6 AM 5 AM
4 AM
1300 9 AM
8 AM 7 AM 6 AM
5 AM
These examples of the problem and fixed responses, assume a computer
in the PST time zone.
Before examples:
Check $$HTFM, 58412 is 3001204
Call with 58411,86399 result 3001203.235959
Call with 58412,0 result 3001204
<<Lost time
Call with 58412,60 result 3001204.0001
Check $$FMTH, 3001204 is 58412
Call with 3001203.2359 result 58411,86340
Call with 3001203.24 result 58411,86400
<<Invalid result
Call with 3001204.000001 result 58412,1
Check $$FMADD, adding minutes
Call with 3001204.2359 plus 1 result 3001204.24
Call with 3001204.24 plus 1 result 3001205.0001
Call with 3001205.0001 plus 1 result 3001205.0002
Check $$FMADD, subtracting minutes
Call with 3001205.0001 minus 1 result 3001205
<<Lost time
Call with 3001205 minus 1 result 3001204.2359
Call with 3001204.2359 minus 1 result 3001204.2358
Check $$HADD, adding minutes
Call with 58412,86280 plus 1 result 58412,86340
Call with 58412,86280 plus 2 result 58412,86400 <<Invalid
result
Call with 58412,86280 plus 3 result 58413,60
Check $$HADD, subtracting minutes
Call with 58413,120 minus 3 result 58412,86340
Call with 58413,120 minus 2 result 58413,0
Call with 58413,120 minus 1 result 58413,60
After Examples:
Check $$HTFM, 58412 is 3001204
Call with 58411,86399 result 3001203.235959
Call with 58412,0 result 3001203.24
<<Correct
Call with 58412,60 result 3001204.0001
Check $$FMTH, 3001204 is 58412
Call with 3001203.2359 result 58411,86340
Call with 3001203.24 result 58412,0
<<Correct
Call with 3001204.000001 result 58412,1
Check $$FMADD, adding minutes
Call with 3001204.2359 plus 1 result 3001204.24
Call with 3001204.24 plus 1 result 3001205.0001
Call with 3001205.0001 plus 1 result 3001205.0002
Check $$FMADD, subtracting minutes
Call with 3001205.0001 minus 1 result 3001204.24 <<Correct
Call with 3001204.24 minus 1 result 3001204.2359
Call with 3001204.2359 minus 1 result 3001204.2358
Check $$HADD, adding minutes
Call with 58412,86280 plus 1 result 58412,86340
Call with 58412,86280 plus 2 result 58413,0
<<Correct
Call with 58412,86280 plus 3 result 58413,60
Check $$HADD, subtracting minutes
Call with 58413,120 minus 3 result 58412,86340
Call with 58413,120 minus 2 result 58413,0
Call with 58413,120 minus 1 result 58413,60
Check $$FMTHL7
Call with 3001204.123 result 200012041230-0800
Call with 3001204.2334 result 200012042334-0800
Call with 3001204.24 result 200012050000-0800
Check $$HL7TFM
Call with 20001205000000-0800 result 3001204.24
Call with 200012050000-0800 result 3001204.24
Call with 20001204123000 result 3001204.123
Call with 200012042334-0800 result 3001204.2334
Call with 20020124120138 result 3020124.120138
Check $$HL7TFM UCT time
Call with 20001205000000-0800 result 3001205.08
Call with 20001204123000-0600 result 3001204.183
Call with 200012042334-0800 result 3001205.0734
Call with 20020124120138 result 3020124.200138
Check $$HL7TFM to local time
Call with 20001205000000-0800 result 3001204.24
Call with 20001204123000-0600 result 3001204.103
Call with 200012042334-0500 result 3001204.2034
Call with 20020124120138 result 3020124.120138
XU*8*229
Subject: KIDS Fixs
Problem: The way that KIDS files new entries from the PARAMETER TEMPLATE
(#8989.52) file on the target system. The exported entries get filed,
but the "B" x-ref on the PARAMETERS multiple (field 10) doesn't get filed.
This causes the Edit Parameter Values with Template [XPAR EDIT BY TEMPLATE]
option to fail as it does not see any parameters to edit within the template.
Fix: Set the flag to have FileMan cross reference the data.
Problem: When queuing during patch install. The user tried to
queue the patch for 9:00PM at night but omitted the word PM from the time.
The system didn't prompt me that it was a wrong time in the past (9:00
AM) nor did it prompt me to reenter the correct time. It went and
installed the patch immediately as if it accepted the default value of
NOW. The patch required users to be off the system during installation
but because it installed immediately during working hours it triggered
NOSOURCE errors in the system error log.
Fix: Added a screen to require the time to be in the future.
Problem: Install did not install every thing because user doing the
install didn't have full FileMan privilege. (DUZ(0)="@")
Fix: Temporally give user DUZ(0)="@" for install.
Problem: KIDS does not DELETE AT SITE when requested to do so
for HL LOWER LEVEL PROTOCOL PARAMETER, HL LOGICAL LINK, or MAIL GROUP.
Additionally, installer is prompted to supply a coordinator for a MAIL
GROUP, even when it is marked as DELETE AT SITE.
Fix: Add delete code for HL LOWER LEVEL PROTOCOL PARAMETER and HL LOGICAL
LINK.
Problem: Some functions like assembling the list of routines and moving
them into the Build sets up large, local arrays, so large as to cause an
abend with an allocation error.
Fix: File the data at least every 100 entries.
Problem: Note that although Data Comes With File was edited to NO, values in logically related fields Site's Data, Resolve Pointers, May User Override Data Update, and Screen to Select Data were not cleared of their values even though the pop-up window for editing these field only appears if Data Comes With File is answered YES, and so there is an understood relationship (i.e. values in these fields make no sense if the answer is NO to Data Comes With File)
Maybe the data would not be picked up, but the Build is misleading to
the viewer and the Build serves as valuable documentation for patches.
The developer has to use work around of while value is YES, to @ sign each
of the populated fields in the pop-up window before changing Data Comes
With File to NO.
Fix: Have code in the form reset the fields when the SEND FULL OR PARTIAL
DD (#222.3) is changed to Partial. Only works in the ScreenMan Form.
Problem: The build print KIDS option is not displaying all the fields.
Especially, the one time run routine deletion fields. DELETE ENV ROUTINE,
DELETE PRE-INIT ROUTINE, DELETE POST-INIT ROUTINE.
Fix: Changed routine XPDDP to print the fields.
Added two fields to the ROUTINE file (#9.8) and the code to fill
them.
1. KIDS INSTALL DATE (#7.4) to track when KIDS loads routines.
2. PATCH (#8) a multiple to track the checksum of a routine for
each patch when a KIDS transport is made.
XU*8*272
Subject: PHONE FIELDS
Patch XU*8*272 updates the HELP-PROMPT for phone fields - PHONE (HOME) (#.131), OFFICE PHONE (#.132), PHONE #3 (#.133), PHONE #4 (#.134), COMMERCIAL PHONE (#.135), and FAX NUMBER (#.136) - in the New Person file (#200) to help users input data for the fields more efficiently.
Old HELP-PROMPT: Answer must be 4-20 characters in length.
New HELP-PROMPT: Answer must be 4-20 characters in length. Only
numeric/punctuation characters will be allowed.
XU*8*274
Subject: Fix to Tasked DEACTIVATE user.
Problem: Patch XU*8*222 made a change that required a variable that
was not in the symbol table when the task to DEACTIVATE a user was run
in the future. If the deactivation was not schedule to run in the future
there wasn't a problem.
Fix: Set the required variable in the tasked entry point.
XU*8*267
Subject: DEA API and INST DEA #
The Drug Enforcement Administration/Veteran's Administration Public Key Infrastructure (DEA/VA PKI) pilot project requires an Application Programmer Interface (API) to obtain the value stored in the DEA# field (#53.2) in the NEW PERSON file (#200). This patch provides this new API and also adds a new field, FACILITY DEA NUMBER (#52), to the INSTITUTIONfile (#4). The specific API information follows:
$$DEA^XUSER([FLAG])
Reference type: Supported, Category: PKI, Integration Agreement: 2343
Description:
This routine will return a user's DEA number, if it exists in the DEA#
field (#53.2) of the NEW PERSON file (#200). If the DEA# field value is
null, the value returned depends on the optional FLAG input parameter,
see below.
Input Parameter
FLAG (optional) This flag controls what is returned when
the user does not have a value in the DEA# field (#53.2) of the NEW PERSON
file (#200).
* FLAG is null or "0" -- This routine will check to see if the user has values in the VA# field (#53.3) of the NEW PERSON file (#200) and the (new) FACILITY DEA NUMBER field (#52) of the INSTITUTION file (#4). If values are found in both of those fields, this routine will return the following:
FACILITY DEA NUMBER field (#52)_"-"_VA# field(#53.3)
* FLAG is "1" -- This routine will check to see if the user has a value in the VA# field (#53.3) of the NEW PERSON file (#200). If a value is found in that field, this routine will return that field value. Otherwise, this routine returns an empty string.
Output
DEA# DEA# field (#53.2) value or the value returned based
on the (optional) FLAG input parameter, see "Input Parameter" above.
Example 1
DEA# (#53.2) field is "AB1234567"
FACILITY DEA NUMBER field (#52) is "VA7654321"
VA# field (#53.3) is "789"
If the FLAG input parameter is null or "0", this API would return "AB1234567".
If the FLAG input parameter is "1", this
API would return "AB1234567".
Example 2
DEA# (#53.2) field is null
FACILITY DEA NUMBER field (#52) is "VA7654321"
VA# field (#53.3) is "789"
If the FLAG input parameter is null or "0", this API would return "VA7654321-789".
If the FLAG input parameter is "1", this
API would return "789"
Example 3
DEA# (#53.2) field is null
FACILITY DEA NUMBER field (#52) is "VA7654321"
VA# field (#53.3) is null
If the FLAG input parameter is null or "0", this API would return "".
If the FLAG input parameter is "1", this
API would return "" In both cases it returns an empty string.
XU*8*263
Subject: REINDEX THE USER KEY'S [XUSER KEY RE-INDEX] FIX
This patch modifies the routine XUSMGR to fix the following problem:
A variable DIK(1) was set up inappropriately for the option "Reindex the
users key's" [XUSER KEY RE-INDEX].
XU*8*269
Subject: Add LOCKING to XUESSO1.
Problem: Duplicate entries in New Person File from RDV.
Fix: Our best guess is this is caused by two RDV coming at the same
time and not having one process see the other before starting to add the
user a second time. If this is correct, the use of a LOCK to make adding
of user by RDV a sequential process will correct the problem.
Problem: QUIT command is after a comment and can't be reached.
Fix: Move to its own line.
XU*8*257
Subject: ISO Menu
Patch XU*8*257 re-builds the Information Security Officer Menu [XUSPY]. More options and menu options are added to the menu. This is an enhancement patch, and the enhancement has been requested by the Health Information Security Service.
Information Security Officer Menu [XUSPY]:
-------------------------------------------------------------
Information Security Officer Menu (System Security)
User Security Menu (Review Users)
User Inquiry
List users
User Status
Report
Find a
user
Switch
Identities
Show the
keys of a particular user
See if
a User Has Access to a Particular Option
User Audit
Display
Deactivate
a User
Reactivate
a User
Fileman Security Menu (Access to VA Fileman
Files)
Inquiry
to a User's File Access
List Access
to Files by File number
Print
Users Files
Delete
Users' Access to a Set of Files
Single
file add/delete for a user
Fileman
Access for the ISO
Print File Entries
Search File Entries
Inquire to File Entries
Audit Menu
Fields Being Audited
Data Dictionaries Being Audited
Purge Data Audits
Purge DD Audits
Turn Data Audit On/Off
List File Attributes
Menu and Option Security (Menu Management
Review)
Option
Function Inquiry (Inquire)
Option
Access By User
Print
Option File
Diagram
Menus
Abbreviated
Menu Diagrams
Show Users
with a Selected primary Menu
List users
holding a certain key
Keys For
a Given Menu Tree
Secure
Menu Delegation
Show a Delegate's Options
List Delegated Options and their Users
Print All Delegates and their Options
Option
Audit Display
Audited
Options Log
Audited
Options Purge
System Audit Menu (Maintain System Audit
Options)
Establish
System Audit Parameters
Display
the Kernel Audit Parameters
Server
audit display
Super
Search Message File
Program
Integrity Checker
Bulletin
Selection
Patient
Inquiry
MAS Parameter
Entry/Edit
Access Monitor Menu
Display
of Programmer Mode Entry List
Programmer
Mode Entry Log Purge
Failed
Access Attempts Log
Failed
Access Attempts Log Purge
Device
Failed Access Attempts
User Failed
Access Attempts
Print
Sign-on Log
Security Officer Menu
Display
User Access to Patient Record
Enter/Edit
Patient Security Level
Purge
Non-sensitive Patients from Security Log
Purge
Record of User Access from Security Log
Note:
- (Text) is the old name.
- Some menus/options may be locked or "OUT OF ORDER MESSAGE"
at sites.
XU*8*278
Subject: Cache/NT %ZIS4 fix.
Problem: ZIS4ONT has the same problem in its REWIND code as ZISFONT
had with using "RV" for the open parameters on the Cache/NT systems.
Fix: Have ZIS4ONT check the OS to select the correct open parameters.
In testing another patch it was noticed that Cache changed the format
of the IP address data returned by $ZIO between 3.x and 4.x, The
ZIO code was changed to work with both formats.
XU*8*240
Subject: STDNAME~XLFNAME: CHECK FOR SUFFIXES IMMEDIATELY AFTER COMMA
1. Bug fixed: STDNAME^XLFNAME was not accounting for suffixes (except DR) immediately after the comma in the passed name. For example, if the name is:
SMITH,JR JOHN
STDNAME^XLFNAME was interpreting "JR" as the Given (First) Name and "JOHN" as the Middle Name.
With this patch, STDNAME^XLFNAME looks for the suffixes JR, SR, DR, MD, ESQ, DDS, RN, and 1ST through 10th immediately after the first comma of the passed name. If it finds any of those suffixes before the given name, they are moved to the end, and STDNAME^XLFNAME returns AUDIT("SUFFIX")="".
2. Bug fixed: If you made a call to NAMECOMP^XLFNAME, and passed in a name that has DR immediately after the first comma, before the given name, an undefined XUNM("SUFFIX") error would occur. For example:
>S ZZNAME="SMITH,DR JOHN" D NAMECOMP^XLFNAME(.ZZNAME)
%DSM-E-UNDEF, undefined variable XUNM("SUFFIX")
-DSM-I-ECODE, MUMPS error code: M6
%DSM-I-ATLABEL, N2+7^XLFNAME:1 . S
XUNM("SUFFIX")=$$JOIN(XUNM("SUFFIX"),"DR")
3. Bug fixed: If you make a call to STDNAME^XLFNAME and pass in a name part that contains only punctuation:
a. That name part would be returned as one of the
name components;
b. Some of the other name components may fail to
be returned.
This patch changes the behavior so that name parts that consist only of punctuation are removed from both the standard name and the name components returned by the call.
Example 1:
>S NAME="SMITH,!@# JOHN" D STDNAME^XLFNAME(.NAME,"C") ZW NAME
Before patch:
After patch:
------------
-----------
NAME=SMITH,JOHN
NAME=SMITH,JOHN
NAME("FAMILY")=SMITH
NAME("FAMILY")=SMITH
NAME("GIVEN")=!@#
NAME("GIVEN")=JOHN
NAME("MIDDLE")=
NAME("MIDDLE")=
NAME("SUFFIX")=
NAME("SUFFIX")=
Example 2:
>S NAME="(DEC)." D STDNAME^XLFNAME(.NAME,"CP") ZW NAME
Before patch:
After patch:
------------
-----------
NAME=
NAME=
NAME("FAMILY")=.
NAME("FAMILY")=
NAME("GIVEN")=
NAME("GIVEN")=
NAME("MIDDLE")=
NAME("MIDDLE")=
NAME("SUFFIX")=
NAME("SUFFIX")=
XU*8*282
Subject: Person Class Expired
1. MANUAL^XUINPCH2 has added the current date to the Person Class Expiration Date for both Terminated and DISUSER users if that field is current non-existent.
This patch modifies the MANUAL^XUINPCH2 to add the current date to the Person Class Expiration Date for only Terminated user if that field is current non-existent.
2. There is a typo 'Switch too' in the routine XUS3A.
This patch corrects the typo from 'Switch too' to
'Switch to'.
XU*8*258
Subject: Multiple Sign on Update
1. New Service request: #20020605 Multiple
sign-on from only one IP. Preface: In today's VA Workplace it has become
impossible for Clinicians to accomplish their work from a single VISTA
Session. Many users need to have a Telnet session, CPRS, and VISTA Imaging
open at the same time. Two issues:
a.
Security - We don't allow multiple sign-ons for security reasons. This
is primarily caused by users not obeying rules. In the past users logged
on in one location then left the area and signed on elsewhere. In doing
so they violate Patient Confidentiality and VA Security Policy.
b.
Licenses - Every sign-on requires a license. If a user signs on in multiple
locations we eventually run out of licenses. NOTE: CACHE counts multiple
sign-ons from a single IP as 1 license.
Fix: Add a new value to the DEFAULT MULTIPLE SIGN-ON field (#204) in the KSP file (#8989.3), "Only one IP" and the same change to the MULTIPLE SIGN- ON field (#200.04) of the NEW PERSON FILE (#200). Make changes to the Sign- on log file (3.081) to track the IP of the user. Change the code to check the flag and file to limit a user to multiple sign-ons from only one IP address.
DD changes:
New Person File (200):
MULTIPLE SIGN-ON (200.04) add to the set of codes:
;0:NOT ALLOWED;1:ALLOWED;2:Only one IP;
MULTIPLE SIGN-ON LIMIT (200.19) New field, number;
Kernel System Parameters file (8989.3):
DEFAULT MULTIPLE SIGN-ON (204) add to the set of codes:
0:NO;1:YES;2:Only one IP
DEFAULT MULTIPLE SIGN-ON LIMIT (219) New field, number;
SIGN-ON LOG (3.081): Complete DD sent.
One way for sites to use this would be to set the field DEFAULT MULTIPLE SIGN-ON (204) in the Kernel System Parameters file (8989.3) to "Only one IP". Also setting the field DEFAULT MULTIPLE SIGN-ON LIMIT (219) to a value of 5. Then if some users need other settings they can be set by the fields in the New Person File (200). Because a Terminal server only has one IP address a user could go to another Terminal Server Client and still sign-on up to the sign-on limit.
2. The print template XUSEC LIST has been modified to provide more useful information. One change is in the ELAPSED TIME column a "*" after the value indicates that the record was forced closed.
3. NOIS: BRX-0102-11431. The problem mentioned in this (closed) NOIS has been fixed. XUP will store DATE/TIME for last sign-on.
4. Also added are two Parameter Definitions
for the XUP routine. XUS- XUP SET ERROR TRAP to control if XUP should set
an error trap for programmer errors and XUS-XUP VPE to control if XUP will
drop into the VPE programmer environment if an option is not selected.
The default is to work as it has in the past.
XU*8*286
During certain KIDS installs which are run at large sites with
lots of menu options on their system, a String Too Long error may result
when Micro Surgery attempts to update the menu tree. This patch presents
modified routines that will prevent that error. Instead of storing
the data in a singe variable string which can grow too large, we now put
them into an array.
XU*8*224
Subject: Fix KSP call.
Problem: The call KSP^XUPARAM("WHERE") would return the Mailman network
name and not the domain name pointed to by the Kernel System Parameters.
Fix: Return the Domain name pointed to by the Kernel System Parameters.
XU*8*273
Subject: Switch Identities Fix
The problem is the Switch Identities [XUTESTUSER] option appears to
get an <UNDEFINED> error if the user being selected does not have the
proper key(s) for their primary menu.
XU*8*301
Subject: Name Standardization Wrong File Component Deletion
If the file number being passed to API, DELCOMP^XLFNAME2, begins with
the same number as another file that is registered in the NAME COMPONENTS
file (#20), then the Name Component's entry for that file maybe deleted,
instead of the Name Component for the file that was passed. For example,
if the file number being passed is 2, meaning delete the Name Component
entry for an entry in the PATIENT file (#2), then there was a possibility
that the Name Component entry for an entry in file 200 would be deleted.
This is because the "X" flag for an exact match was not passed in the $$FIND1^DIC
call.
XU*8*253
Subject: Merging Users' Menu Structures
Merging Users' Menu Structures
When a user is reactivated and there are no "^" jump compiled menus for that user in the ^XUTL global then the software tries to merge the necessary data from the master copy in ^DIC(19,"AXQ") in to the global. When several users are reactivated at the same time several merges were triggered. This patch prevents this and causes the merges to take place in an orderly fashion.
Likewise, when a user signs onto a system in a cluster that and does not have the most recent data structures to use a merge is triggered. A system of flags and locks are now used to control all merges within the Menu System.
XU*8*296
Subject: NEW PERSON DD CHANGES
The Kernel Part III post routine, XUINCON - BUILDS ACCESSIBLE FILE MULTIPLE, sets the NEW PERSON (#200) file's ACCESSIBLE FILE (#200.032) sub-file's WRITE ACCESS (#5) field to zero at D1+1^XUINCON. The Set of Codes field definition does not define 0 as an allowed value. This causes "0" to display during display functions instead of null or NO.
To fix this, "0" (meaning NO) is being added to the set of codes for this field and the others in this multiple.
This patch contains no routines; only the DD changes.
XU*8*297
Subject: SHOW MORE OF THE SPOOL DOC NAME
This patch concerns the SPOOL DOCUMENT (#3.51) file.
1. The length of the "B" xref on the NAME (#.01) field is increased from 30 to 63 characters so that more of the name appears when the user enters '?' to get a list of spool documents when using option [XU-SPL-PRINT] Print A Spool Document. The post-init (POST^XU8P297) for this patch will kill the existing "B" xref and reindex the NAME (#.01) field. Here's the new DD for that field. Nothing's changed, except the size of the "B" xref.
2. The print template [XU-ZISPL-USER] is altered so that the first 44 (up from 20) characters of the spool document names are shown when using option [XU-SPL-LIST] List Spool Documents. During the install, you will see the following message:
The following Routines were created during this install:
XUCT02
XUCT02 is the routine into which the print template is compiled.
XU*8*300
Subject: PERSON CLASS API
This patch concerns the PERSON CLASS (#200.05) subfile of the NEW PERSON (#200) file.
1. The API $$GET^XUA4A72, given a person and a date, retrieves the active class for that person on that date. It can get confused when confronted with problems such as those above, and return an error (no active class for this person on this date) for 5/18/2000, for example. This patch makes the API a bit smarter. It will return the last person class for 5/18/2000. It will return the same one (not the first one) for 11/1/1996.
2. When a new PERSON CLASS record is added to the multiple, the expired date of the previous one is set to the effective date of the new one. If the effective date of the new one is prior to the effective date of the previous one, this results in records such as those marked "problem" above. To remedy this, we add a simple check: If the Effective Date of the previous class is greater than the Effective Date of the new class, then we set the Expired Date of the previous class to be the same as its Effective Date.
3. Patch XU*8*49 purportedly prevented you from adding a new PERSON
CLASS record with an effective date prior to the effective date of the
previous one. It didn't work. This patch does. A new
input transform on the Effective Date (#2) field sees to it.
XU*8*277
Subject: Stop USERINFO errors.
Site was seeing this error "<UNDEF>USERINFO+4^XUSRB2" in there error trap. It is believed to be from the user not completing the sign-on when they have to change there Verify Code during the GUI sign-on.
Fix: Change the code to check that DUZ is greater that zero before continuing. Because this code should never be called if DUZ is not set, Code will also set the XWBSEC to tell broker to raise an error.
XU*8*291
Subject: CONVERT SPOOL DOC TO MAILMAN MESSAGE
When converting a spool document to a MailMan message, the user can
now enter the subject of the message, select the basket when addressing
to himself, address the message to anyone else, and choose whether the
message should be from himself or the Postmaster.
XU*8*251
Subject: CLINICAL TRAINEE CORE DATASET
This patch was created to assist the VHA Office of Academic Affiliations (OAA) in capturing core data for VHA clinical trainees that use the Veterans Health Information System and Technology Architecture (VISTA). To achieve this, a new PROGRAM OF STUDY file (#8932.2) is created, new fields and a new cross-reference are added to the NEW PERSON file (#200), and the forms, input templates, and print templates that are used to edit and display the data in the NEW PERSON file are modified to include the new fields. New options, a print template, and a form are also provided for entering and displaying clinical trainee data.
2. A record-level new-style cross-reference is added to the NEW PERSON
file to set an index whenever fields for clinical trainees being tracked
by OAA is changed:
New file: PROGRAM OF STUDY (#8932.2)
-------------------------------------
3. The PROGRAM OF STUDY file is created to hold the list of the programs
of study that can be associated with a clinical trainee. This file is pointed
to by the new PROGRAM OF STUDY field (#12.2) in the NEW PERSON file (#200).
The data dictionary for the file is as follows:
Option: Add a New User to the System [XUSERNEW]
Form: XUEXISTING USER
Input Template: XUNEW USER
-------------------------------------------------------
4. The form and input template used by the Add a New User to the System option are modified to include the fields in the NEW PERSON (#200) file identified by OAA as core clinical trainee data elements. Some of the fields to be added already exist in the NEW PERSON file; others are added to the NEW PERSON file by this patch. If the person is assigned a Program of Study, it is assumed that the user is a Clinical Trainee. If the person entering the data responds "YES" to "Is this person a Clinical Trainee?", the following field is made required:
12.2 PROGRAM OF STUDY
Option: Edit an Existing User [XUSEREDIT]
Form: XUEXISTING USER
Input Template: XUEXISTING USER
-------------------------------------------------
4. The same changes made to the form and input template used by the
Add a New User to the System [XUSERNEW] option are made to the form XUEXISTING
USER and input template XUEXISTING USER used by the Edit an Existing User
[XUSEREDIT] option. See "Option: Add a New User to the System [XUSERNEW]"
above for a description of those changes.
Option: Reactivate a User [XUSERREACT]
Form: XUREACT USER
Input Template: XUREACT USER
----------------------------------------------
5. The same changes made to the form and input template used by the
Add a New User to the System [XUSERNEW] option are made to the form XUREACT
USER and input template XUREACT USER used by the Reactivate a User [XUSERREACT]
option. See "Option: Add a New User to the System [XUSERNEW]" above for
a description of those changes.
Option: User Inquiry [XUSERINQ]
Print Template: XUSERINQ
---------------------------------------
6. The print template XUSERINQ used by the User Inquiry option
was modified to display the following fields from the NEW PERSON file for
clinical trainees:
12.1 CURRENT DEGREE LEVEL
12.2 PROGRAM OF STUDY
12.3 LAST TRAINING YEAR
Option: OAA Clinical Trainee [XU-CLINICAL TRAINEE MENU]
Type: Menu
-------------------------------------------------------
7. This is the menu that contain the Clinical Trainee, items #8 and #9, but each site can make this menu available to any user that needs to access the data.
Option: Edit Clinical Trainee [XU-CLINICAL TRAINEE EDIT]
Form: XU-CLINICAL TRAINEE
--------------------------------------------------------
8. This new option invokes a new form that can be used to edit the clinical
trainee data for users in the NEW PERSON file that haven't been terminated.
This new option is attached to OAA Clinical Trainee [XU-CLINICAL TRAINEE
MENU], which in turn is attached to the User Management [XUSER] menu.
Each site can make this option available to any user that will be entering
this data.
Option: Inquiry Clinical Trainee [XU-CLINICAL TRAINEE INQUIRY]
Print Template: XU-CLINICAL TRAINEE INQUIRY
--------------------------------------------------------
9. This new option invokes a new print template that can be used
to display the clinical trainee data for users in the NEW PERSON file.
This new option is attached to OAA Clinical Trainee [XU-CLINICAL TRAINEE
MENU], which in turn is attached to the UserManagement [XUSER] menu.
Each site can makethis option available to any user that will need to view
this data.
Routine: XUSER2
---------------
10. This routine is modified to add a new REQ entry point that can
be called from the XUEXISTING USER, XUNEW USER, XUREACT USER, and XU-CLINICAL
TRAINEE forms. This entry point makes fields #12.1, 12.2, and 12.3 available
or unavailable for editing, and makes those fields along with the other
fields being tracked by OAA required or not required, depending on whether
the person is designated as a clinical trainee.
XU*8*283
Subject: PKI pilot support
Pharmacy Benefits Management (PBM) Strategic Healthcare Group, in collaboration with the Drug Enforcement Administration (DEA), requested the development of the first Public Key Infrastructure (PKI) VistA pilot project, named Public Key Infrastructure for Electronic Prescriptions Pilot Project. The objective is to develop an electronic order entry system for Schedule II controlled substances using digital signatures. A Memorandum of Understanding between the DEA and the Department of Veterans Affairs authorizes only specified sites to use the full functionality of this pilot, although additional functionality is included that will benefit non-pilot sites. This patch contains the functionality required for this pilot and lays the foundations for the future implementation of the PKI once the DEA regulations are revised and published. It is installed with the PKI functionality disabled and will not have any impact until the PKI functionality is enabled. PKI functionality can be enabled via Computerized Patient Record System (CPRS) parameters at a site level and a user level. Additional hardware and software is required from various sources before PKI can be implemented at a site. DO NOT enable the PKI parameters until all required software and hardware has been installed.
To make this project viable, modifications to the following packages
were identified:
National Drug File (NDF) V. 4.0
Kernel V. 8.0 (This patch and XU*8*288)
Computerized Patient Record System (CPRS) V. 1.0
Pharmacy Data Management (PDM) V. 1.0
Outpatient Pharmacy (OP) V. 7.0
Controlled Substances (CS) V. 3.0
Web sites with more information:
Overview of VA PKI projects:
https://vaww.webdev.med.va.gov/techsvc/projects/vapki.asp
The VA PKI project, for this project:
http://vaww.va.gov/techsvc/projects/vapkidea/vapkidea.asp
Files to get from the download sites.
"HinesPKIUserGuide.doc", This
is a word document to help in the installation and implementation of PKI
for DEA/VA Schedule II drugs.
"cert_how_to_updated11-5-02.pdf", This is from a DEA contractor and shows how to view a DEA Cert.
"Krn8_0p283sp.pdf", This documents the digital signature from the Kernel point of view during the development phase.
"XuDigSigSC.exe", This is the self extracting ZIP file with the install files for the Signing COM object.
"XuDigVerify.exe", This is the self extracting ZIP file with the install files for the Verification server.
***
This patch creates a new global ^XUSSPKI, which should be placed
before installing the patch. Following national deployment, a site
could see approximately 3000 characters in this file for every Schedule
II, III, and IV out patient drug that is prescribed. This data must
be held for a minimum of two years.
***
Post install instructions only for a site in the pilot:
1. Use the "Kernel PKI Parameter Edit" option [XUSSPKI EDIT] to edit/enter the IP address of the Verification Server.
2. Use the "Mail Group Edit" option [XMEDITMG] to add users to the "XUSSPKI CRL SERVER" mail group.
3. If you need debug information, use the General Parameter Tools option [XPAR MENU TOOLS] to set the value of the XUSC1 DEBUG parameter to 1 for debug logging.
4. From EVE, go to TaskMan's "Schedule/Unschedule Options" option and schedule "XUSSPKI CRL UPLOAD" to run once an hour.
5. From one of the national download site get the following files.
a. XuDigSigSC.exe This is a self-extracting ZIP file of a install disk, that expands into C:\temp\PKI-c\. Switch to this folder and Double click on the SETUP icon. This will install the signing COM file (XuDigSigSC.exe) into C:\program files\vista\Common files\ and register it.It installs a COM object that is used by CPRS when doing a digital signature. It will need to be installed on each workstation.
b. XuDigVerify.exe It gets installed on the Verification Server, a Windows 2K Pro box provided by the site. This is a self- extracting ZIP file of a install disk, that expands into C:\temp\PKI-v\. Switch to this folder and Double click on the SETUP icon. It runs two services that are used by Pharmacy to verify the digital signature.
Install/implementation guide doc, This is a word document to help in the installation and implementation of PKI for DEA/VA Schedule II drugs.
XU*8*288
Subject: Updated DEA~XUSER API.
This patch updates the DEA API that was added with patch XU*8*267. The changes are to allow a USER IEN to be passed in to use inplace of the current DUZ. The second update is that if the institution doesn't have a DEA# on file a check is done to get the PARENT FACILITY and see if there is a DEA# for that entry.
The DEA/VA PKI pilot project requires an API to obtain the value stored in the DEA# field (#53.2) in the NEW PERSON file (#200). This patch provides this new API. The specific API information follows:
$$DEA^XUSER([FLAG][,USERIEN])
Reference type: Supported, Category: PKI, Integration Agreement #2343
Description:
This routine will return a user's DEA number, if it exists in the DEA#
field (#53.2) of the NEW PERSON file (#200). If the DEA# field value is
null, the value returned depends on the optional FLAG input parameter,
see below.
Input Parameter
FLAG (optional) This flag controls what is returned when
the user does not have a value in the DEA# field (#53.2) of the NEW PERSON
file (#200).
* FLAG is null or "0" -- This routine will check to see if the user has values in the VA# field (#53.3) of the NEW PERSON file (#200) and the (new) FACILITY DEA NUMBER field (#52) of the INSTITUTION file (#4). If values are found in both of those fields, this routine will return the following:
FACILITY DEA NUMBER field (#52)_"-"_VA# field(#53.3)
* FLAG is "1" -- This routine will check to see if the user has a value in the VA# field (#53.3) of the NEW PERSON file (#200). If a value is found in that field, this routine will return that field value. Otherwise, this routine returns an empty string.
USERIEN (optional) This value can be used to get the DEA# of some user besides the one that signed in. In CPRS to check that a students teacher has the required DEA#.
Output
DEA# DEA# field (#53.2) value or the value returned
based on the (optional) FLAG input parameter, see "Input Parameter" above.
Example 1
DEA# (#53.2) field is "AB1234567"
FACILITY DEA NUMBER field (#52) is "VA7654321"
VA# field (#53.3) is "789"
If the FLAG input parameter is null or "0", this API would return "AB1234567".
If the FLAG input parameter is "1", this
API would return "AB1234567".
Example 2
DEA# (#53.2) field is null
FACILITY DEA NUMBER field (#52) is "VA7654321"
VA# field (#53.3) is "789"
If the FLAG input parameter is null or "0", this API would return "VA7654321-789".
If the FLAG input parameter is "1", this
API would return "789"
Example 3
DEA# (#53.2) field is null
FACILITY DEA NUMBER field (#52) is "VA7654321"
VA# field (#53.3) is null
If the FLAG input parameter is null or "0", this API would return "".
If the FLAG input parameter is "1", this
API would return ""
In both cases it returns an empty string.
It adds a menu item "Institution DEA# edit" (XU-INSTITUTION-DEA),
to the Kernel Management Menu (XUKERNEL) to allow the entry/edit of the
institution DEA# value.
XU*8*307
Subject: State File Check/Clean-up
XU*8*304
Subject: KIDS FIXES
The routine ^XPDKRN does not have the option to backup a transport global. This patch adds it. The post-init deletes the global ^DOPT("XPD"), and then recreates it with the added option. If you select the Full Comparison in the option [XPD COMPARE TO SYSTEM] Compare Transport Global to Current System, data that is exported for a file is not compared if the "Update the DD" question was answered NO. That's not right. The data should be compared regardless of whether the DD is updated. This patch fixes that in routine ^XPDCOMG.
If you select the Full Comparison in the option [XPD COMPARE TO SYSTEM] Compare Transport Global to Current System, and items (such as mail groups, options, etc.) to be deleted do not exist on the current system, KIDS will report that they are to be ADDED. This patch fixes that in routine ^XPDCOMG.
Under the "Build File Print" option,
a. If you simply press return at the BUILD NAME: prompt, it should
exit. Instead it prompts for DEVICE:
b. If the patch description contains lines that are longer than
80 characters, it should wrap the lines. Instead, it may truncate
them.
This patch fixes both these problems in routine ^XPDDP.
In the FILE (#9.64) subfile of the BUILD (#9.6) file, let's say that
the DATA COMES WITH FILE (#222.7) field is set to YES, and the SITE'S DATA
(#222.8) field is set to MERGE. If DATA COMES WITH FILE is changed to NO,
SITE'S DATA remains unchanged. That can be confusing. It should be
deleted, as should other fields associated with data. This patch
fixes that by adding a new style xref (AD) to the following field:
XU*8*310
Subject: FIX DEVICE FORMS
Kernel patch XU*8*69 deleted fields *FORM FEED (#10) and *BACK SPACE (#12) from the DEVICE (#3.5) file, but neglected to remove references to them in various FORMs and INPUT TEMPLATEs. This patch corrects that in the following:
FORMs
INPUT TEMPLATEs
------------- ---------------
XUDEVICE CHAN XUHFSDEV
XUDEVICE HFS
XUSDPDEV
XUDEVICE MT
XUSPLDEV
XUDEVICE SDP
XUDEVICE SPL
This patch also removes the POST ACTION ON CHANGE for the SUBTYPE (#3)
field from the FORMs. Whenever the SUBTYPE was changed, it had the
effect of copying the RIGHT MARGIN and PAGE LENGTH field values from the
TERMINAL TYPE (#3.2) file to the DEVICE (#3.5) file. With patch XU*8*69,
these fields in the DEVICE file should only be populated if they need to
differ from the values in the TERMINAL TYPE file.
XU*8*313
Subject: BCMA Contingency Support
Patch XU*8*290 sent the existing extended action Option XU USER TERMINATE
out in such a way that it removed existing actions that had been connected
to it.
The PRE-INIT will try and add the 5 known national options back onto
the XU USER TERMINATE extended action option.
The POST-INIT for this patch will run the XU USER TERMINATE option
for terminated users after a date chosen by the installer.
This patch includes support for the BCMA Contingence plan by providing
protocol events for:
User Add Event (XU USER ADD)
User Change event (XU USER CHANGE)
User Terminate event (XU USER TERMINATE).
These are in the option file and can be linked to there. The user's
IEN will be in the variable XUIEN at the time of the call. Each protocol
will create an array XUSR that will hold a set of fields from the NPF.
The XU USER TERMINATE protocol is not new. Both the old variable XUIFN and the new XUIEN will be defined. The exact place in routine XUSTERM that it is called from has changed.
The error occurs when we are using the option Reactivate a User [XUSERNEW], and place "^" at prompt of the question: "Do you wish to add this user to mail groups? NO//"
Site requested something to track when and who changed the access code,
and when and who changed the verify code.
Fix: The data was being hard set into the access/verify code fields
because FM was not reentrant in the early days. This code has been
changed to use a FileMan DBS call. Now the access/verify code fields
can be audited.
XU*8*308
Subject: SUPPRESS SERVER BULLETIN
When a server message is processed, a bulletin is sent to a mail group to notify the mail group. If there are no members in the mail group, the server message is rejected. This is as it should be.
If the server option field SUPPRESS BULLETIN (#224) is set to YES, then no bulletin is sent. This is also as it should be.
The problem is that even when bulletins are suppressed, the mail group associated with the bulletin is still checked, and the server message is rejected if no members are in the group. That's not right.
If the SUPPRESS BULLETIN (#224) field in the OPTION (#19) file is set
to YES, then this patch will not check any mail group associated with any
bulletin.
XU*8*324
Subject: Allocation Failure During Transmission
During transmission of the Clinical Trainee data is was possible for an allocation error to occur and the data not to be transmitted, yet VistA would "think" it had been transmitted. In cooperation with the Office of Academic Affiliations(OAA) this patch will do the following:
1. Fix the allocation error.
2. Install a new menu option so a current count of Clinical Trainees can be obtained.
3. Install a new MAIL GROUP. Persons that are members of this mail group will now receive a message that will indicate how many records were transmitted to the Office of Academic Affiliations(OAA).
4. Execute a post install that will do the following:
a. Re-index the "ATR" cross reference.
b. Retransmit all persons who are indicated
as Clinical Trainees.
XU*8*316
Subject: Reporting Options for Alerts
This patch provides several reporting options for Alerts, including ones that: list users with large number of alerts in the ALERTS file (#8992); list alerts for a specified user from a specified date; list alerts for a specified patient for a specified day or date range. Since the retention period for alerts in the ALERT TRACKING file (#8992.1) is currently a site parameter, some users may have alerts in the ALERTS file that no longer are present in the ALERT TRACKING file, data from both sources is used when necessary.
This patch adds the following options:
Report Menu for Alerts (XQAL REPORTS MENU)
This menu provides several options for generating reports on alerts for users or patients.
User Alerts Count Report (XQAL USER ALERTS COUNT)
This option is used to generate a report on users who have more than a specified number of alerts in the ALERTS file (#8992). The report covers a specified range of dates, and can be sorted by user name, number of alerts, or by service/section. In addition, the report in each of these formats may be generated by Divisions if desired.
For each user who has the specified number of alerts or more, the report includes the user name, the section/service for the user, the number of alerts in the ALERTS file, the last sign-on date, the number of Critical alerts or Abnormal Imaging alerts, and the date of the oldest alert.
The counting of alerts may also be restricted to those alerts which contain specific text or phrases.
Critical Alerts Count Report (XQAL CRITICAL ALERT COUNT)
This option is used to generate a report of users who have more than a specified number of alerts containing the word 'critical' or the words 'abnormal imaging' between the specified start and end dates. The report is presented in descending order for the number of critical/abnormal imaging alerts present.
For each user who has the specified number of critical/abnormal imaging alerts or more, the report includes the user name, the section/service for the user, the number of alerts in the ALERTS file, the last sign-on date, the number of Critical alerts or Abnormal Imaging alerts, and the date of the oldest alert.
List Alerts for a user from a specified date (XQAL ALERT LIST FROM DATE)
This option is used to obtain a list of alerts from the ALERT TRACKING file (#8992.1) for a specified user for a specified date range. The user may select all of the alerts to be displayed, or enter specific text or phrases to select only alerts which contain the specified text. In the latter case, the user may also select to see only those alerts which match the criteria and are only info only alerts, only action alerts, or both.
The listing includes the internal entry number for the alert in the ALERT TRACKING file, the date and time the alert was generated, the message text of the alert, and information about any option or routine to be executed for processing the alert.
Patient Alert List for specified date (XQAL PATIENT ALERT LIST)
This option is used to obtain a list of alerts for a specified patient from the ALERT TRACKING file (#8992.1) for a selected date range (it is recommended that this range be only a few days at most, since every entry in the ALERT TRACKING file in the selected date range must be checked to provide a complete listing of alerts for a patient).
A prompt is provided to obtain a quick scan listing of dates with at least some alerts for the patient on it based on OR and DVB alerts (other patient related alerts need to be identified by looking at each alert's message text and are included in the full list, but not the quick scan).
The user may select all of the alerts to be displayed, or enter specific text or phrases to select only alerts which contain the specified text. In the latter case, the user may also select to see only those alerts which match the criteria and are info only alerts, only action alerts, or both.
The listing includes the internal entry number for the alert in the ALERT TRACKING file, the date and time the alert was generated, the message text of the alert, and information about any option or routine to be executed for processing the alert.
View data for Alert Tracking file entry (XQAL VIEW ALERT TRACKING ENTRY)
This option can be used to obtain a listing of data in captioned format
for selected entries in the ALERT TRACKING file (#8992.1). The internal
entry numbers for the entries to be listed must be entered individually.
XU*8*311
Subject: TRANSITIONAL PHARMACY BENEFIT PROJECT - PHASE II
As part of the Transitional Pharmacy Benefit project - Phase II, this patch introduces the following new fields to the NEW PERSON file (#200). These fields will provide Outpatient Pharmacy V. 7.0 package, the flexibility to enroll "NON-VA" Physicians into the NEW PERSON file (#200), to process medications prescribed by the "NON-VA" Physicians. This is a requirement of the Veterans Health Administration (VHA) Directive 2003-047.
1. NON-VA PRESCRIBER field (#53.91) - to identify a physician as a NON-VA person or not. A value of 1 indicates that this person is a NON-VA Physician.
2. TAX ID field (#53.92) - TAX ID of the NON-VA Physician's Privat Clinic, where the prescription was written.
3. EXCLUSIONARY CHECK PERFORMED field (#53.93) - Department of Health and Human Services provides an exclusionary list of Medical Practitioners (providers excluded are those who are not allowed to receive payment for government services due to various reasons). A value of 1 indicates that an Exclusionary Check was performed for this physician.
4. DATE EXCLUSIONARY LIST CHECKED field (#53.94) - The date Exclusionary Check was performed.
5. ON EXCLUSIONARY LIST field (#53.95) - The NON-VA Physician
was he/she on the Exclusionary Check List. A value of 1 indicates that
the
Physician was on the Exclusionary Check.
6. EXCLUSIONARY CHECKED BY field (#53.96) - User ID of the person
who made the entry.
XT*7.3*58
Subject: MXML parser
This patch releases a XML parser that was commissioned by the VA architects. Developer documentation can be found on the VistA Documentation Library under Infrastructure in the Kernel ToolKit session. Here is the URL: http://vista.med.va.gov/vdl/#App12
Sample Use:
Create a XML file:
^TMP($J,1) = <?xml version='1.0'?>
^TMP($J,2) = <!DOCTYPE BOOK>
^TMP($J,3) = <BOOK>
^TMP($J,4) = <TITLE>Design Patterns</TITLE>
^TMP($J,5) = <AUTHOR>Gamma</AUTHOR>
^TMP($J,6) = <AUTHOR>Helm</AUTHOR>
^TMP($J,7) = <AUTHOR>Johnson</AUTHOR>
^TMP($J,8) = <AUTHOR>Vlissides</AUTHOR>
^TMP($J,9) = </BOOK>
Invoke the SAX interface:
D EN^MXMLTEST($NA(^TMP($J)),"V")
. . . See what happens.
Check the DOM interface:
>S HDL=$$EN^MXMLDOM($NA(^TMP($J)))
>W $$NAME^MXMLDOM(HDL,1) <<Write
the name of the first node
BOOK
>S CHD=$$CHILD^MXMLDOM(HDL,1) <<Get the child
of the node
>W $$NAME^MXMLDOM(HDL,CHD) <<Write the child name
TITLE
W $$TEXT^MXMLDOM(HDL,CHD,$NA(VV)) <<Get the text
of the child
1
>ZW VV
VV(1)=Design Patterns
List all the sibling nodes
>S CHD=$$CHILD^MXMLDOM(HDL,1)
>S SIB=CHD
>F S SIB=$$SIBLING^MXMLDOM(HDL,SIB) Q:SIB'>0 W
!,SIB,?4,$$NAME^MXMLDOM(HDL,SIB)
3 AUTHOR
4 AUTHOR
5 AUTHOR
6 AUTHOR
>
Some notes, Defined values are case sensitive, In the first line, <?xml
must be in lowercase. Lines can only be broken at whitespace.
Here is a URL for more data from Microsoft and their XML notepad:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxml/html/xmlpadrun.asp
XT*7.3*61
Subject: XINDEX UPDATE
Problem: XINDEX reports an error on the use of $ESTACK, $ETRAP
and $ECODE.
Fix: To recognize that $ESTACK, $ETRAP and $ECODE are valid variables.
Problem: XINDEX reports ]] as an error. Part of the 95 standard.
Fix: Check and allow ]] in routines.
Problem: XINDEX report writes past the right margin.
Fix: Improve the new line check.
Problem: Bad code like 'D EN^DDIOL=("some text")' would cause
XINDX5 to error out.
Fix: Improve check for valid routine names before checking if
they exist.
Problem: The XINDEX program marks a QUIT not followed by two spaces
as a warning if the most resent TAG did not accept parameters. Thinking
that it had removed the next command from the line being analyzed it would
attach it back on the string. If the text added back was not a valid
M command the line would get a "UNDEFINED COMMAND (rest of line not checked)"
error.
So M code like this:
Q:DIQGWPB "$CREF$"_DIQGR_DA_","_$$Q^DIQGU(P)_")" Q:DIQGWPO $NA(@DIQGETA)
Would cause two error messages.
W - QUIT Command followed by only one space.
F - UNDEFINED COMMAND (rest of line not checked).
The UNDEFINED COMMAND error should not happen.
Fix: Check that the text added back would make a valid M command.
Problem: XINDEX did not have patch 48 on second line.
XT*7.3*59
Subject: XTRMON FIX
Problem: When using the OPTION: "Monitor Routines for Changes"(XTRMONITOR)
with a range and the range ended with an "A" (Like XMA) then the starting
point would be invalid causing an error. Monitoring all routines or a range
like XUS worked ok.
Fix: Change how the start of the range is checked.
Problem: The entry XPAR ALL ENTITIES is missing from FILE: PARAMETER
DEFINITION(#8989.51).
Fix: Send out the entry.
Problem: In BUILD^XTRUTL, if the list of routines includes a routine
that has been auto deleted during the install, and is not the first routine
in the list, it will display the patch list of the previous routine.
Fix: Kill the variable each time thru the loop.
Problem: Internal testing found that in BUILD^XTRUTL the list of needed
patches was not always correct.
Fix: Replace with a better algorithm.
Problem: SQA pointed out that the Routine Summary did not report the
patch list as the Patch Template (appendix B) in the IIS Patch Completion
document shows.
Fix: Change the text to match.
XT*7.3*63
Subject: Fix to missing line in XPAR.
1. A format option in the call GETLST^XPAR was accidentally removed.
This caused errors in some CPRS (Computerized Patient Record System) calls.
Fix: the format option was added back.
2. In the process of executing the cross-references of the Data
Dictionary (DD), a call is made to OUT^XPARDD. If an incomplete record
is encountered it will result in a SUBSCRIPT error.
Fix: In OUT^XPARDD check that the parameter used in the call
to EXT^XPARDD has a value before making call.
XT*7.3*64
Subject: Lookup field for Parameter Definition file
DESCRIPTION:
Managing parameters has gotten very difficult because of the large
number of entries and the way they are named by the developers. What makes
sense to a developer does not necessarily make sense to us in NVS or the
users at the sites. I'm requesting a Keyword lookup field be added to the
Parameter Definition file so users can group parameters in a way that makes
sense to them.
IMPACT:
The addition of this field would allow a site to group parameters in
a meaningful way. For example, a parameter which doesn't have the word
PRINT anywhere in it's name or display name, might have PRINT added as
a Keyword because the user associates this parameter with one or more print
functions. This same parameter might also have something to do with Lab
so the addition of Lab as a keyword.
A search for Lab OR Print will find this parameter.
RECOMMENDATION:
The recommendation is simply to add a Keyword lookup field/index to
file 8989.51.
Solution: A new multiple KEYWORD (#4) field has been added to the PARAMETER
DEFINITION (#8989.51) file with a whole file lookup cross-reference.
Sites can add Keywords to help in the lookup. A new option has been included
to allow editing of the new Keyword field. Option "Edit Parameter Definition
Keyword" (XPAR EDIT KEYWORD) has been added to the option "General Parameter
Tools" (XPAR MENU TOOLS).
XT*7.3*66
Subject: XINDEX check for patch number
Problem: It is easy to miss a routine that doesn't have the patch on
the second line.
Fix: At the programmer prompt, running XINDEX and selecting a BUILD,
will check that each routine has the patch number on the second line.
Running OPTION: Calculate and Show Checksum Value [XTSUMBLD-CHECK] or OPTION:
Routine Summary List [XT-BLD RTN LIST] for a build will also check for
the patch number on the second line of each routine. These options
are usually executed at the programmer prompt by running CHECK^XTSUMBLD
and BUILD^XTRUTL
Make sure that options: "Routine Summary List", "Version Number Update",
"Old Checksum Update from Build", Old Checksum Edit, are on the KIDS "Edits
and Distribution" menu.
XT*7.3*72
Subject: Add Column Headings to Parameter Options
Patch XT*7.3*72 fixes a problem that has been reported in NOIS PUG-0702-50868. The problem is that there is no column headings for fields displayed in the options 'List Value for a Selected Entity' [XPAR LIST BY ENTITY], and 'List Values for a Selected Parameter' [XPAR LIST BY PARAM].
XT*7.3*74
Subject: ADJUST PARAMETER TOOLS HELP DISPLAY
The help listing in Parameter Tools displays two columns of data, each the same width. The data being displayed, though, can vary in width require- ments. This patch will check the data it needs to display, and adjust the column widths accordingly.
XT*7.3*69
Subject: Undef EXTPTR~XPARDD fix.
Patch OR*3.0*141 deletes bad values from the Parameters file but for sites that have turned on auditing, the audit requires the current external value, the DD has an output transform with a call to $$OUT^XPARDD(Y,"I"). This calls the EXTPTR sub-routine that doesn't handle bad data and causes the error.
Fix: The $$EXTPTR^XPARDD function will now handle invalid input data.
Example:
KDE>W $$EXTPTR^XPARDD("A",8989.3) = > A
KDE>W $$EXTPTR^XPARDD(2,8989.3) = > 2
KDE>W $$EXTPTR^XPARDD(1,8989.3) = > NXT.KERNEL.FO-OAKLAND.MED.VA.GOV
KDE>W $$EXTPTR^XPARDD(3,100.9) = > LAB RESULTS
KDE>W $$EXTPTR^XPARDD(3,100.93) = > 3
If the input doesn't get a valid entry, the input value is returned.
XT*7.3*76
Subject: FIX BUILD~XTRUTL
The API BUILD^XTRUTL aborts if a routine in the build is not found.
This can happen, for instance, when a pre- or post-init is set to delete
after installation. This patch fixes that.