| DESCRIPTION OF ENHANCEMENTS |
Below is a brief description only of changes included in this patch. For
- Resolution: Screen displays associated with the ordering and
- Resolution: Regardless of where in the queue a report is added, if the
report record does not have the provider listed for any reason, the
word "UNKNOWN" will be stuffed as the provider.
NOTE--this issue has only been reported at one site and is not easily
reproducible. The validity of the fix for this will be internally
verified by development under controlled conditions only. This
option does not contain any safety critical functions for the
blood bank.
Problem # 9:
processing of blood components for a patient have been modified to
When using the option Disposition - relocation [LRBLIDR] there were a
variety of reported problems with the lookup for LOCATION to relocate
blood to.
NOIS: IND-1296-40311 BRX-0597-11400 LEB-0199-20568
- Resolution: The lookup routine LRUC was rewritten. It now uses
FileMan utilities to look up valid locations based on the division of
the user at sign-on.
Problem # 10:
During the option Log-in regular (invoices) [LRBLILR], when the user is
always include a 4 digit year, even if no year was previously
presented the screen to edit units just logged in, if a unit had been
accidentally logged in with an expiration date the same date as the log
in, and the expiration date is edited correctly, the unit is still
flagged as expiring today when re-displayed to the user. This was ONLY a
flag problem. The actual expiration date of the unit always reflected
the date correctly as input.
NOIS: LEX-0197-40288
- Resolution: The option has been edited so that the flags for units
expiring the same day work appropriately.
displayed.
Problem # 11:
During the background process of collecting workload for Blood Bank
accessions, result data was being inappropriately stuffed into fields
which had been starred for deletion. This data was then printing on the
Accession area worklist [LRUWL] report.
NOIS: ATG-0895-32603
-Resolution: The collection of workload data no longer stuffs result data
into inappropriate fields.
Problem # 12:
As of April 23, 1999 the VistA BLOOD BANK Software (v 5.2) is classified
as a Medical Device # BK970021 with the FDA. According to VHA Directive
97-033, Section 4. ACTION part b., the CIOFO would embed in the form of a
comment in routines that contain the controlled software a statement that
the routine should not be modified. According to FDA, if a facility
other than the original software manufacturer makes any changes to the
cleared device, including changes to the software components of the
medical device, this software no longer represents the cleared medical
device and the facility making the modification becomes the medical
device manufacturer of a new medical device.
Problem # 2:
- Resolution: Routines classified as Group A in VHA Directive 97-033
will have the following verbiage inserted in the third line:
; Per VHA Directive 97-033, this routine should not be modified.
Medical Device # BK970021
Problem # 13:
The Patient Merge software introduced a problem in the database
that has affected the way some of the Lab routines determine the
LABORATORY REFERENCE field (#2,63) from the PATIENT File (#2).
- Resolution: Routines LRBLPAB and LRBLPD1 have been modified to use the
It was discovered during Y2K testing of the Donor module of the Blood
function $$LRDFN^L7OR1(DFN) to determine a patient's LRDFN. This
function was introduced in LR*5.2*230 as a defensive programming
measure to prevent an undefined error from occurring when attempting to
determine the LRDFN from the ^DPT(DFN,"LR") node.
Problem # 14:
There may be some old post-init or otherwise unnecessary routines at
sites. These will be removed during the KIDS install if they are
present.
-Resolution: If present on a system, routines LRBLFIX, LRBLFX72,
Bank package that when donor collection information is entered into the
LRBLJ, LRBLPOST, LRBLCON and LRBLXREF will be removed as part of the
KIDS Install.
Problem # 15:
It was reported by Milwaukee via a mail message that when a blood bank
specimen is drawn on one day but not actually accessioned until the next
day, under certain circumstances an undefined error would occur when a
tech attempts to assign units which require crossmatch using the option
Select units for patients [LRBLPIC]. Upon further investigation it was
discovered that the option was attempting to update the field COMPLETION
computer, future times are allowed when entering the fields DATE/TIME
TIME (#68.14,1) for workload purposes. It was further determined that
when the error did not occur, the incorrect workload record was being
updated. It is actually inappropriate to update this field as it is set
when the original accession has the ABO/Rh and ABS results entered.
-Resolution: Coding has been changed so that the field COMPLETION DATE
(#68.14,1)is no longer updated as a result of using the option Select
units for patients [LRBLPIC].
Problem # 16:
The patch LR*5.2*72 inadvertently exported a change in the length of the
COLLECTION STARTED (#65.54,4.2) and DATE/TIME COLLECTION COMPLETED
text allowed in the BLOOD PRODUCT File (#66) field SYNONYM (#66.021,.01).
This resulted in sites being restricted to 5 character synonyms for
entries made to this field after installation of that patch.
-Resolution: The data dictionary for this field is being re-exported and
the SYNONYM field (#66.021,.01) field will now be allowed to accept
entries from 1-25 characters.
a full description please see the Patch Description in the Forum Patch
(#65.54,4.3). This posed a problem during testing in the system being
used for Y2K testing. The scenario where a unit is collected on
12-31-1999 but data is not entered until 12-1-2000 and the date/times
being entered as 12-31@0800 defaults to the current year, which is a
future time. This should not be allowed.
NOIS: ISA-1099-13117
- Resolution: The input transforms of the affected fields will be edited
so that no future dates are allowed.
Problem # 3:
Module.
It was reported by a site via an Outlook message that when logging in
units using the option Log-in regular (invoices) [LRBLILR] and the
barcode scanner is used, if a site's supplier uses Expiration Date
barcodes utilizing a 4 digit year, then the display to the user seems to
indicate that the scanner did not interpret the code correctly. The
correct expiration date was in fact being assigned to the unit, however,
the software was interpreting the input as if the user was manually
inputting the expiration date. This could cause some confusion at sites.
- Resolution: The routine which interprets barcodes has been modified so
that the barcode scanner itself is interpreting the expiration date.
Problem # 4:
The input screen for the fields DIVISION in the BLOOD INVENTORY File
(#65,.16) and ASSOCIATED DIVISION in the BLOOD PRODUCT File (#66.1,.01)
incorrectly made the assumption that a site's division was dinumed to the
INSTITUTION File (#4).
NOIS: WPB-1196-31737
- Resolution: The screen in the following input transforms have been
changed to S DIC("S")="I +$G(^DIC(4,+Y,99))=+$P($$SITE^VASITE,U,3)"
D ^DIC K DIC S DIC=DIE,X=+Y K:Y<0 X"
Problem # 1:
BLOOD INVENTORY File (#65) field DIVISION (#65,.16)
BLOOD PRODUCT File (#66) field ASSOCIATED DIVISION (# 66.1,.01)
Problem # 5:
In a multidivisional site, if the report Patient transfusions &
hematology results [LRBLPCH] crashed for any reason, it could not be
restarted if the name of the Blood Bank accession area was not BLOOD
BANK. This is because in order to restart the crashed report, the option
Delete a user's patient list [LRBLSDPL] needed to be run first. This
option had the accession area hard coded to be BLOOD BANK therefore would
It was determined by the VistA IV&V Y2K testing analysis that several
not always work in a multidivisional site with more than one Blood Bank.
NOIS: BHS-0899-12185
- Resolution: The option Delete a user's patient list [LRBLSDPL] was
modified to determine the accession area for the Blood Bank based on
the user's division at sign-on. Previously, the accession area was
hard-coded to be BLOOD BANK.
NOTE-- the resolution to this problem will not be validated at the sites
as it is not practical to ask sites to force a system crash. The
validity of the fix for this will be internally verified by
development under controlled conditions only. This option does
displays within the Blood Bank software that historically displayed
not contain any safety critical functions for the blood bank.
Problem # 6:
When a unit which was originally scanned during log-in is modified, such
as thawing or irradiating, the unit could no longer be processed using a
scanner. This affected both the Blood Bank as well as the Surgical Risk
Initiative.
NOIS: HIN-1196-40687 ALB-0298-52583
- Resolution: When a unit is modified using the option Disposition -not
transfused [LRBLIDN] and the Unit ID remains the same (i.e. unit not
Month/Day only needed to also display a 4 digit year.
pooled or split) the ^LRD(65,"C", cross-reference is now built if the
scanner was used to process the modification.
Problem # 7:
It was discovered during internal testing by the developer that units
that are modified in error, and the option Edit unit log in [LRBLSEL] is
used to either edit or delete the modified unit, the ^LRD(65,"C",
cross-reference was not being updated appropriately.
- Resolution: Coding was changed to update the ^LRD(65,"C"
cross-reference as appropriate when units are edited.
NOIS: ISP-0899-N0355
Problem # 8:
When executing the option Print all BB patient reports on print queue
[LRBLP PRINT ALL ON QUEUE] if for some reason the first patient blood
bank report added to the print queue doesn't have a PROVIDER the report
bombs with an undefined and none of the reports will print. Also, if a
patient blood bank report added in the middle of the queue doesn't have a
provider, the report will print the provider of the report just
previously added to the queue.
NOIS: ALB-0899-52597
|
