Chapter 3 Configuring the Application

====================================================================

Configuring the Imaging Site Parameters
Configuring Mail Messages
Configuring Mail Groups
Configuring the Purge, Verifier, and RAID Group Advance Settings
Configuring the Queue Manager
Configuring the Network Location Manager

====================================================================

3.1 Introduction

All the parameters for running the BP applications (Queue Processor/Verifier/Purge) are managed through the Queue Processor GUI. There are multiple parameter windows that you can use to change settings for each BP application. The parameter windows are accessed through the Edit menu on the BP Queue Processor application menu bar.

This is an example of the Background Processor’s Edit menu.

3.1.1 Overall Guidelines

· The three BP applications (Queue Processor, Verifier, and Purge) are installed with a default configuration. However, you will need to configure settings for each one depending on how/when/where you want these applications to run. When the BP is first installed, review the parameters to insure the products are set up according to your site’s needs.

· A BP Server will need to be defined for each Windows server that will be running a task and/or the Purge and/or Verifier.

· A specific task (JUKEBOX, JBTOHD, IMPORT, etc) on the Queue Processor can be run only on one server.

· A task must be assigned to a BP Server before that task will run when the Queue Processor starts.

· Some parameter windows have Apply buttons. Be sure to click the Apply button to commit changes to the database. (Cancel resets any changed parameters.) The windows that do not have Apply buttons are committed when the change is made. The OK button also commits the changes and closes the main parameter window.

3.2 Configuring the VistA Imaging Site Parameters

The parameters on the Imaging Site Parameters window control activities within the Queue Processor as well as the DICOM Gateways, Clinical Capture, Clinical Display and VistARad. The site parameters can be configured for these functionalities:

Access to the image shares
Service account login information
Routing share configuration
Display and capture workstations
DICOM Gateways
Jukebox configuration
RAID Groups configuration

3.2.1 Imaging Site Parameters Window

The Edit > Imaging Site Parameters menu on the Queue Processor menu bar opens the Imaging Site Parameters window used to modify entries in the VistA database. Each of the boxed areas in the window is described below.

Imaging Site Parameters window used to modify entries in the VistA database

3.2.1.1 Administrative Settings

This is an example of the administrative settings.

Field or Checkbox	Description
Current Namespace	Each VHA facility has its own unique 3-character designator. The Current Namespace file is used to store this 3 letter facility designator. It is used in Imaging as the first 3 characters of the 14-character name given to image files captured at this site. The VistA Imaging development and support teams maintain a central database with each sites 3 letter designator. The Current Namespace field is not configurable. This is necessary to ensure that image file names across VHA are unique.
RAID Write Location	All images from the gateways, Capture, etc. will be written to this share. The selected Current RAID Group determines which shares are listed on this dropdown list.
Generic Carbon Copy	Remote share where files will be exported. The share permissions must match the login credentials for the BP Server.
Current RAID Group	The current active RAID Group includes the RAID Write Location (described above). When new images are processed, they are stored on the RAID Write Location share within this group. The RAID Groups are set up with the Network Location Manager.
Import Queue Security	Checks users Imaging security keys for permission to capture images
Site Code	Three-letter acronym for the site location. This is used for AutoRouting and MUSE.
Associated Institutions	This set of institution values will allow users from other institutions to access local images. Note: Right-clicking this field displays an Add/Delete popup menu that can also be accessed from the keyboard by using Shift + F10.
VistARad Grouping	The radiologist can lock/interpret exams for other divisions (including the Parent Institution or other Associated Institutions), when those divisions are included in this set of institutions. Note that this setting controls exam locking and updating, as well as filtering of the UNREAD Exams lists to show only the Institutions that are defined here. Note: Right-clicking this field displays an Add/Delete popup menu that can also be accessed from the keyboard by using Shift + F10.

3.2.1.2 Storage Functions Settings

Storage Function Settings

Field or Checkbox	Description
Jukebox Write Location	Jukebox share where newly acquired images are currently being written.
% Server Reserve	The purpose of the reserve is to provide a significant amount of reserved primary storage to allow time for corrective action to create more space on the shares. Enter an integer between 2 and 50. The system defaults to 5 if the integer is outside the normal range. When the used space on a share exceeds the specified percentage, then actions are taken within the BP (mail message sent, auto purging initiates (if scheduled), etc.). In addition, the AutoWrite Location Update will be disabled and images will be written to that share until the free space is exhausted.
Auto Write Location Update	At the interval of every 20 minutes or 100 images written to a share, the Queue Processor will determine which share within a group has the most space and will use that share as the current write location for newly acquired images. To manually select a RAID Write Location, uncheck the Auto Write Location Update box. Images will be written to the selected RAID share until it is filled or manually changed to another share.
Multiple Namespace	List of all the legacy namespaces that have been used at a site and are reflected in the filenames on the RAID and jukebox shares. Note: Right-clicking this field displays an Add/Delete popup menu that can also be accessed from the keyboard by using Shift + F10.
File Types	File extensions outside of the standard extensions that the BP products will recognize and treat as a standard extension file. Note: Right-clicking this field displays an Add/Delete popup menu that can also be accessed from the keyboard by using Shift + F10.

3.2.1.3 Clinical Workstation Settings

This is an example of the settings available for clinical workstations.

Field or Checkbox	Description
Use Capture Keys	Check users’ Imaging security keys for permission to capture images.
Timeout Windows Display	Number of minutes until the Imaging Display application will close due to inactivity. The default setting is 120 minutes (Range 6 to 600).
Timeout Windows Capture	Number of minutes until the Imaging Capture application will close due to inactivity. The default setting is 120 minutes (Range 6 to 600).
Timeout VistARad	Number of minutes until the Imaging VistARad application will close due to inactivity. There is no default setting.
Default MUSE Site #	MUSE site number that the Imaging Display application will connect to. Site numbers are usually 1, 2, 3, …. If left empty, the field defaults to 1.
Default User Preference	A specified user’s parameter settings will be used for first-time users of the Imaging system.

3.2.1.4 Service Accounts Settings

These credentials are shared between the DICOM Gateway, Image cluster, Jukebox Server, and Background Processor.

Service Account Settings section of window

Field or Checkbox	Description
Windows Username	Domain account used to access the Imaging shares on the RAID and archive (jukebox) share. Both the RAID and archive (jukebox) shares must have READ/WRITE permission to this account.
Windows Password	Domain password used to access the Imaging shares on the RAID and archive (jukebox) share.
VistA Access	Encrypted access code for the Imaging Service Account in VistA. This account will be used to automatically re- log into the application when there is a loss of connectivity between the BP product and the Broker (VistA). Note: The Imaging Service Account must have the MAG SYSTEM security key and secondary menu option MAG WINDOWS.
VistA Verify	Encrypted verify code for the Imaging Service Account in VistA. This account will be used to automatically re- log into the application when there is a loss of connectivity between the BP product and the Broker (VistA).

3.2.1.5 DICOM Interface Settings

DICOM Interface window

Field or Checkbox	Description
DICOM Gateway Write Location	RAID share where newly acquired images are currently being written.
DICOM Gateway Interface Switch Update	Indicates presence of a DICOM Gateway on the system.
Retention Days HL7 – Modality Work Lists	This field is used as the default value, in days, by the DICOM Text Gateway for three different user menu driven purges: · This field is used by the Purge Old Modality Worklist Entries menu option to determine the number of retention days from the date of creation of Modality Worklist Entries. · This field is used by the Purge Old DICOM Message Files menu option to determine the number of retention days from the date of creation of DICOM messages that were sent to commercial PACS. · This field is used by the Purge Old HL7 Transaction Global Nodes menu option to determine the number of retention days from the date of creation of HL7 messages sent from VistA to the DICOM Text Gateway. Note: This value may be overridden by the user when executing any of these menu options.
% Free Space DICOM Messages	Minimum percentage of free disk space for DICOM HL7 messages on the text gateway. A typical value is 25%.
Retention Days DICOM Messages	Number of days to retain DICOM HL7 messages on the text gateway, 30 days is recommended.

3.3 Configuring Mail Messages

When the BP products are running, they generate various alerts and informational messages. These messages/alerts are formatted into mail messages and can be sent to different levels of management within a facility. The Mail Message subject lines describe the condition with the content of the message containing the specific information. The recipients for each Mail Message Subject type can be set up using the Mail Message Manager.

3.3.1 Mail Messages Window

The Edit >Mail Messages menu on the Queue Processor menu bar opens the Mail Messages window used to set up recipients for each message type. The tab Mail Messages can also be selected.

Mail Message window

3.3.1.1 Displaying Mail Users

The list of the hospital users in the Mail Users section is not immediately displayed until you click in the area shown in the previous screen image. The list may take a few minutes to appear depending on the number of end-users defined in the site’s VistA database. The following is an example of a displayed list of mail users.

List of Mail Users in a Mail Group

3.3.1.2 Adding Names

To select a name and associate it with a particular Mail Message type, drag the name from one of the windows on the right to the Mail Message Manager window on the left. The change will be stored in VistA when the name is dropped into the Mail Message category. You can add as many names as needed to each Mail Message on the left.

3.3.1.3 Removing Names

When a user no longer wishes to receive a specific warning/alert, the user’s name can be removed from that particular message list at any time. VistA will be automatically updated to reflect the change.

1. Locate the warning/alert message and right-click the username under the message title.

2. Select Delete from the popup menu displayed.
VistA will automatically be updated to reflect the change.

3.3.1.4 Notification Intervals

The mail messages are sent out to the designated users at specific intervals (default is 6 hours). These intervals can be adjusted per message name. To change a notification interval for a particular Mail Message, follow the steps below.

This is an example of the Mail Message properties window where the transmission frequency can be set as well as displaying the last date and time a message of this type was sent.

1. Right-click a message name and select Properties from the popup menu displayed

2. Change the Transmission frequency (in hours) to the new value.

3. Click OK to close the window.
VistA will automatically be updated to reflect the change.

3.3.1.5 Field Descriptions

The fields for the Mail Message Manager are described below.

Field	Description
Kernel Mail Groups	Alert/ informational message names
VistA Imaging Mail Groups	Complete list of the Imaging mail groups defined in the VistA database. Users in the selected Mail Group will be sent the alert/informational message.
Mail Users	Complete list of users with mailboxes defined in the VistA database.
Security Key Holders	Complete list of the Imaging security keys in the VistA database. Users that have the selected key will be sent the alert/informational message.

3.4 Configuring Mail Groups

Users can be added to existing mail groups using the Mail Groups window. These Mail Groups can be used to send alerts and informational messages to users through the Mail Message Manager window.

3.4.1 Mail Groups Window

The Mail Groups window can be opened using the Edit >Mail Groups menu on the Queue Processor menu bar.

This is an example of a mail group list.

Field or Checkbox	Description
Mail Groups	List of the existing Imaging Mail Groups defined in the VistA database.
Users box
Name	Complete list of users with mailboxes defined in the VistA database.

3.4.1.1 Displaying Mail Users

The list of the hospital users in the Mail Groups section is not displayed until you click in the area shown above. The list may take a few minutes to appear depending on the number of end-users defined in the site’s VistA database. The following is an example of a displayed list of mail users.

List of Mail Users in a Mail Group

3.4.1.2 Guidelines on Adding Mail Groups

Only active VistA users can be added as members to mail groups. An active user has an “IN” basket defined in VistA.
Important: When you add a new member to a mail group, use the same email address as the one in the domain, which may or may not be the same as the user’s address.
This group is initialized during the install process.
The installer is automatically added as a local member.
The G.IMAGING DEVELOPMENT TEAM@D.DOMAIN.EXT is added as a required remote recipient to comply with the Food and Drug Administration requirements.
It is recommended that the local VistA Imaging ADPAC, Imaging Coordinator, and any Imaging managers be added as a member as well as any network administrators who are responsible for the support of the VistA Imaging system.
It is recommended that a local text pager recipient be added as a remote member. The pager service needs to provide email pager response. The standard email addressing format is supported by this system: “name@mail_domain”.
Only individuals with the MAG SYSTEM security key will be displayed in the lookup dialogue for the local mail group.

3.4.1.3 Adding Members to Mail Groups

From the Queue Processor menu bar, select Edit > Mail Messages to open the Mail Groups window or select the Mail Messages tab.
Drag and drop selected VistA users from the right list boxes to the Mail Groups list box.

VistA will automatically be updated to reflect the change.

3.4.1.4 Adding Remote Members to Mail Groups

Right-click a mail group and select Add Remote Mail Member from the popup menu displayed.
Note: This popup menu can also be accessed from the keyboard by using Shift + F10.
In the Adding Remote Member dialog box displayed, type the following:

email username or phone number, followed by the “@” sign, followed by the domain

The system uses SMTP Protocol.

This image is an example of adding a remote member.

Click OK.

3.4.1.5 Deleting Members from Mail Groups

When a user or group of users no longer wishes to receive mail messages for a specific alert, that user/user group can be removed using the following steps:

From the Queue Processor menu bar, select Edit > Mail Messages to open the Mail Groups window or select the Mail Messages tab.
Right-click a user/mail group and select Delete Group Member from the popup menu. VistA will automatically be updated to reflect the change.

3.4.1.6 Specifying Properties for Mail Groups

From the Queue Processor menu bar, select Edit > Mail Messages to open the Mail Groups window or select the Mail Messages tab.
Right-click a mail group and select Properties from the popup menu displayed.
Note: This popup menu can also be accessed from the keyboard by using Shift + F10.

This popup menu can be accessed from the keyboard by using Shift + F10.
This is an example of the Mail Messages sub-menus to add remote members, delete group members and the Mail Message properties.

When the Mail Group (properties) dialog box is displayed, enter the data.
Click OK in the dialog box and then Apply in the Mail Groups window.

This window contains a description of the Mail Group, its Organizer , Organizer type, restrictions, and members.

Field or Checkbox	Description
Description	Describes the purpose of the mail group (Editable).
Organizer	The organizer is the person who set up/created the mail group.
Type	Public: Can receive mail from anyone. Private: Can only receive mail from a predefined Public group. (Display only)
Restrictions	Unrestricted: Used when creating a Public mail account. Anyone can mail to this account. Organizer Only: An organizer can add new members to a "Private" mail group. (Display only)
Member	Lists the users in the mail group.
Member group Name	The parent group name for this mail group.
Remote Member	E-mail address of a VA user who is external to the site but part of the domain.

3.5 Configuring the Purge, Verifier, and RAID Group Advance Settings

The Purge / Verifier / RAID Groups window is used for setting up the Scheduled Verifier, Scheduled Purge and RAID Group Advance activities. In addition, the parameters for the Purge activity are set up through this window.

Selecting the Edit > Purge > Verifier > RG Settings menu on the Queue Processor menu bar opens the Purge / Verifier / RAID Groups window.

3.5.1 Purge Settings

The Purge process is used to remove image files from the RAID when the free space is low or when older and/or not recently viewed image files can be purged to allow room for newly acquired images. It is important to note that no file is purged from the RAID shares if it has not been verified and confirmed as saved on the archive storage (jukebox).

The Purge can be run manually in standalone mode or as a part of the Queue Processor. The Purge Parameters are used to control the purge activities in auto, manual and scheduled modes.

3.5.1.1 Guidelines for Setting Retention Days on Files for the Purge

General guidelines:

· Determine the span of dates of images that will be preserved on the Imaging shares.

· The shorter the timeframe, the more space will be free on the disk when the purge completes.

· Multiple purges may be required to determine the retention days. It is advisable to start with one share with a large retention days value.

· Not all sites capture all the file types specified in the parameter list.

· If the frequency and the results of purging are acceptable, then it is not advisable to change the Purge values.

· If there is still not enough free space after the purge, decrease the Purge Parameters (BIG and FULL files, in particular) and repeat the purge until the desired free space is obtained.

Factors that determine the best set of purge parameters for an individual site are:

· The frequency of purges

· The volume of image acquisition rate

· The volume of image file retrieval

· The use of Pre-Fetch

· The capacity of disk space for VistA Imaging shares

Some sites have extended their RAID capacities and are able to maintain five or more years of images on the shares. These sites may only need to purge once per year to purge off the latest year of images (year 6). Others who have smaller RAID sets have to purge more frequently and can only have a limited amount of images on their shares.

For your site, strive to keep the shares between 80% and 90% full (or between 10% and 20% free space). When the Purge process completes and the resulting free space is in excess of this values, then adjust the parameters accordingly.

3.5.1.2 Configuring the Retention Days Settings

This is an example of the Purge parameters for defining the retention criteria.

Field or Checkbox	Description
Retention Days and Retention Dates box
Full Files	Source: Images from the DICOM Gateways, Clinical Capture workstations and Imports. File extensions: 756,ASC,AVI, BMP,BW,DCM, DOC, HTM, HTML, JPG, MHT, MHTML, MP3, MP4, MPEG, MPG, PAC, PDF, RTF, TGA, TIF, WAV Range: 0 - 99,999 (number of days back from the current date that files should be retained)
Big Files	Source: Images from the DICOM gateway and Clinical Capture workstations. File extensions: BIG Range: 0 - 99,999 (number of days back from the current date that files should be retained)
Abstract Files	Source: Images from the DICOM gateways, Clinical Capture workstations and Imports. Abstract files are derivatives of the TGA/BIG format files. File extensions: ABS Range: 0 - 99,999 (number of days back from the current date that files should be retained)
Photo IDs	Source: Source: Patient photo images from the Clinical Capture workstations. File extension: JPG Range: 0 - 99,999 (number of days back from the current date that files should be retained)

1. Enter the number of days that each file type should remain on the shares based on the 3 file date purge criteria described in section 3.5.1 Purge Settings.

Note: The FULL and BIG files are typically larger file sizes and consume more free space on the shares than the abstracts and photo IDs.

2. As a result of their size, set the retention days to fewer days to free more space.

3. Because the abstracts and photo IDs are smaller files, set the retention days for purging these two types of files to a higher value than the values for the FULL/BIG file retention days.

4. Because the abstract files are viewed as thumbnails on the Clinical Display workstation, set the retention days to retain a minimum of 5 years (1,825 days) on the shares regardless of the capacity of the RAID to make viewing on the Clinical Display workstations more efficient.

3.5.1.3 Configuring Scheduled/Express Purge Settings

This image displays the Background Processor’s Purge settings.

Field or Checkbox	Description
Auto Purge	Enables the Purge to run when the high water mark is reached on a RAID Group.
Last Purge BP Server	BP Server on which the last purge was run
Purge Factor	Multiple of the % Server Reserve. When the free space falls below this value, a purge is initiated on the next available online RAID Group. The default value is 2.
Express Purge Section
Active	Enables an Express Purge
Purge Rate	When the number of image entries that have been evaluated for purging (based on the date criterion), without deletion, the purge process for that share will cease. The default Purge Rate value is 100,000.
Scheduled Purge Section
Active	Enable scheduled purges
Last Purge Date:	Date when the last purge was run
Frequency (in days)	The number of days added to the Last Purge Date to determine the next Scheduled Purge Date. This occurs at the end of a Scheduled Purge. If this field is left blank, the Scheduled Purge can be scheduled for a single event. When the event takes place, the Next Purge Date is cleared.
Next Purge Date	Next scheduled Purge date
Purge Time	Time of day for the next scheduled Purge

Note: Before an automatic purge is set up, a manual purge should be run on a share to make sure the Purge Parameters are set properly.

The automatic purge will use these same Purge Parameters and if not set properly, will result in unsatisfactory results. As the volume of images increases from the gateways, etc, these parameters should be adjusted to compensate for the increase.

Scheduled purges typically are set up on a monthly basis, but this will vary per site. The goal is to keep the shares between 80% and 90% full. Some adjustments in scheduling will need to be made after a scheduled purge cycle has completed.

Enabling Express Purge will greatly enhance the purging process by eliminating unnecessary file traversals that are not candidates for purging and thus significantly decrease the time to purge a share. The Purge Factor is set to control when the purge on a share is terminated. When the number of files that are traversed and not deleted has exceeded the number in the Purge Factor, the purge stops on that share and begins purging the next share (automatic mode).

3.5.1.4 Configuring Purge Date Criteria Settings

This is an example of the image purge criteria.

Purge Criteria
Date Accessed	Date when the file (image) was last viewed on a VI workstation
Date Created	Date when the file was copied to the current disk share
Date Modified	Date when the file was last changed. On the initial save, the Date Created will be the same as the Date Modified.

Any of the three file date/times can be used (date accessed, date modified, date created) to purge the shares. There have been instances where third party utilities have changed the access dates on all the files it “touched” to the same recent date.

When the purge is activated, no files are deleted as none of the file access dates are purge candidates. It is recommended that the Date Modified be used. This date is retained when files are moved across storage media and is a reliable date for purging.

3.5.1.5 Running the Scheduled Purge

The Scheduled Purge option is used when the Purge is to be run at periodic intervals i.e. weekends (when activity is low at a site) or when images are to be kept on RAID for a certain period of time i.e. yearly removing images older than 5 years. The application that runs for the Scheduled Purge is the same as the Manual Purge. Reference the Manual Purge (above) for specific information about the GUI and log files.

Note: Set the Purge Retention Days and Purge By as the Scheduled Purge process uses those parameters.

1. Select Edit > BP Servers.

2. Drag the PURGE task to the BP Server where the purge is to be run (Best if run on an Imaging server).

3. Click OK to close the window.

4. Select Edit > Purge / Verifier /RG Settings tab.

5. Set the following fields:

Field	Setting
Auto Purge	Unchecked
Express Purge \| Active	Checked
Scheduled Purge \| Active	Checked
%Server Reserve	(not used for this option)
Purge Factor	(not used for this option)
Frequency (in days)	(select interval in days)
Next Purge Date	(starting date)
Purge Time	(time of day the Purge will run)

6. Click OK to close the window.

When a Scheduled Purge starts, the time is recorded in the VistA database in the field Last Purge Date. The Frequency is added to this date to determine when the Purge will start next. All online RAID shares will be purged when this scheduled application runs.

Important: The Queue Processor must be in the running state on the server where the Purge is scheduled in order for it to run i.e. the Start button on the Queue Processor GUI must be clicked.

3.5.1.6 Running the Auto Purge

There are two configurations where the Auto Purge is used:

In the first configuration, all the RAID shares are in the same RAID Group.
In the second configuration, the shares are distributed into two or more RAID Groups. The setup is the same for both groups except that the Purge Factor must be set for the second configuration.

The application that runs for the Auto Purge is the same as the manual purge. Reference the Manual Purge (above) for specific information about the GUI and log files.

Important: If the PC that has Scheduled or Auto events is not a server class, the task will not start.

Note: The Auto Purge process uses these parameters: Purge Retention Days and Purge By.

1. Select Edit > BP Servers.

2. Drag the PURGE task to the BP Server where the purge is to be run (best if run on an Imaging server).

3. Click OK to close the window.

4. Select Edit > Purge / Verifier /RG Settings tab.

5. Set the following fields:

Field	Setting
Auto Purge	Checked
Express Purge \| Active	Checked
Scheduled Purge \| Active	Unchecked
%Server Reserve	(use the current value that is set on your site)
Purge Factor	2 (used only with multiple active RAID Groups)

6. Click OK to close the window.

When any share in a single RAID Group configuration has less than the %Server Reserve free space, the Purge will start and process all the active shares in that group. On the multiple RAID Group configurations, the Purge will start on the next selectable RAID Group when the free space on any share in the current RAID Group falls below the Purge Factor times the % Server Reserve. This Purge Factor is set to allow time for the purge to complete on that next RAID Group before the Queue Processor changes the Current RAID Group to that group.

The Express Purge setting (described in a previous section) will dramatically lower the time it will take to purge a share/ RAID Group.

Note: The Queue Processor must be in the running state in order for the Auto Purge to run on the designated server; i.e., the Start button must be clicked.

3.5.2 Verifier Settings

The Verifier validates image storage pointers in VistA by checking the physical locations of those pointers to ensure the file(s) exist on the specific storage media. To maintain a valid database, corrective action is taken when these physical files are not found on the media. In addition to these file checks; the Verifier examines the integrity of the imaging records in VistA. Any corruption is reported in the log files.

3.5.2.1 Scheduled Verifier Settings

This image displays the setting available for scheduling a Verifier.

Field or Checkbox	Description
Last Verify BP Server	BP Server on which the Verifier was last run (Display only, set by application)
Scheduled Verifier
Active	Enables scheduling the Verifier
Check Text Files	Read text files on the RAID shares and determine if: 1) the file is binary or unreadable 2) there are unprintable characters in the file 3) The SSN does not match the one in VistA 4) SOP Instance UID mismatch with VistA 5) Study Instance UID mismatch with VistA 6) SOP Instance UID and/or Study Instance UID are blank 7) SSN in the top part of the text file does not match the bottom.
Frequency (in days)	Number of days added to the date of the last time the Verifier application ran to determine the next time the Scheduled Verifier should be run.
Last Verifier Date	Date when the Verifier was last run
Next Verifier Date	Date of the next scheduled Verifier will run based on the Frequency (in days) parameter
Verifier Time	Time of day when the Verifier will run

3.5.2.2 Guidelines for Setting Parameters for the Scheduled Verifier

The Scheduled Verifier should be setup to run nightly. It will verify the integrity of any image records not validated since the previous Verifier run (Manual or Scheduled). It is suggested that the Verifier be run manually over the entire range of image records before incremental Verifier runs are started. The application that runs for the Scheduled Verifier is the same as the Manual Verifier. Reference the Manual Verifier (above) for specific information about the GUI and log files.

The following guidelines for using the Scheduled Verifier will help maintain the integrity of the Imaging records in the VistA database.

Important: If the PC that has Scheduled or Auto events is not a server class, the task will not start.

· Set the Active check box to enable scheduled runs of the BP Verifier. The scheduled runs of the Verifier will only check the most recent VistA records of new images that have been created since the last Scheduled Verifier run.

· Do not select the Check Text Files check box. The contents of the text files on RAID will be compared to the information in VistA. This processing will slow down the Verifier processing and utilities are not available at the present time to correct any issues that surface.

· The Last Verifier Date field is set by the system and cannot be set by the user.

· When the Active parameter is checked, the Frequency (in days) field setting should be 1 so that the Verifier runs daily.

· Initially set the Next Verifier Date to today’s date. The scheduling frequency will be based on this date.

· Set the Verifier Time to an inactive period of the day –typically after hours when image creation activity is low.

3.5.2.3 Running the Scheduled Verifier

Use the following steps to schedule the Verifier:

1. Select Edit > BP Servers.

2. Drag the SCHEDULED VERIFIER task to the BP Server where the verifier is to be run.

3. Click OK to close the window

4. Select Edit > Purge / Verifier /RG Settings tab

5. Set the following fields in the Scheduled Verifier box:

Field	Setting
Active	Checked
Check Text Files	Unchecked
Frequency (in days)	1
Next Verifier Date	(starting date)
Verifier Time	(time of day the Verifier will run – after hours is best)

6. Click OK to close the window.

7. Click Start on the Queue Processor main window. (The Queue Processor must be in the running state in order for the Scheduled Verifier to run on the designated server.)

When a Scheduled Verifier starts, the time is recorded in the VistA database in the field Last Verifier Date. The Frequency is added to this date to determine when the Verifier will run again.

3.5.3 RAID Group Advance Settings

RAID groups are used to organize RAID shares into logical groups for easy tape backup and restore processing. During the install all existing online Imaging shares are placed into the first RAID Group RG-GO1. This configuration is the same that has been in existence for past years. The auto update functionality is also the same. At regular intervals, the current write location will change to the share with the most free space. The Auto-Write function will reset the current write location to provide load balancing within the RAID group. When the % Server Reserve within the group has been breached the Auto-Write will set the next RAID group as the current write group. In addition, when the used space in that RAID Group has reached the high water mark, the next RAID Group that has online shares will become the current RAID Group.

3.5.3.1 Configuring the Scheduled RAID Group Advance Settings

This is an example of the settings for scheduling a RAID Group Advance.

Field or Checkbox	Description
Scheduled RAID Group Advance box
Active	Enable RAID Group Advance scheduling
Last RAID Advance	Date when the last scheduled RAID Group Advance occurred
Frequency (in days)	Number of days added to the date of the last RAID Group Advance to determine the next time the RAID Group Advance will run. If the Frequency parameter is set, the next RAID Group Advance will be scheduled automatically.
Next Advance Date	Date of the next scheduled RAID Group Advance
Advance Time	Required. Time of day of the next scheduled RAID Group Advance

3.5.3.2 Parameter Guidelines for the Scheduled RAID Group Advance

Sites can choose a configuration that suits them best, as follows:

Use the initial configuration where all the shares are in the same RAID Group. The new images will be evenly distributed among all the shares.
Nightly incremental tape backups as well as monthly/quarterly tape backups must be done on a regular basis on all the shares.
Distribute the shares among multiple RAID Groups. Fill the shares in each group to the Server Size, and then switch the current write group to the next. New image files will be distributed over all the shares assigned to that group.
Nightly incremental tape backups as well as monthly/quarterly tape backups must be done only on that RAID Group.
When it has reached capacity, a final full backup should be done on all the shares and nightly incremental tape backups and monthly/quarterly tape backups started on the next current write group.

3.5.3.3 Running the Scheduled RAID Group Advance

This option is applicable when the there are multiple active RAID Groups.

1. Select the Edit > Purge / Verifier /RG Settings tab.

2. Set the following fields in the Scheduled RAID Group Advance box:

Field	Setting
Active	Checked
Frequency (in days)	Set by determining how long a span of time images will be written to a set of shares in a Group.
Next Advance Date	Set the starting date when the system will move to the next RAID Group.
Advance Time	Set the starting time of day when the system will move to the next RAID Group.

3. Click OK to close the window.

4. Click Start on the Queue Processor main window.
(The Queue Processor must be in the running state in order for the Scheduled Verifier to run on the designated server.)

3.6 Queue Manager

The Queue Processor is tasked by other Imaging products and external sources to perform various activities with new images emanating from those sources. These tasks are placed on a queue structure (FIFO with each type of task) in VistA. These tasks are described in section 2.5.3 Assigning Tasks (Queues) to a BP Server.

Note: To execute these tasks, they must be assigned to a BP Server. This can be done using the BP Servers window which is an option on the main BP window.

The Queue Manager window shows each of the queues that have been assigned to a server. It displays Failed and Active status categories under each task. The Active branches show unprocessed entries for new images. The Queue Processor executes each task in a priority order starting with JBTOHD as the highest. When a queue entry for a particular task does not complete successfully, it is placed on the Failed list for that task. The error condition is listed below the Failed entry in the tree. There can be different reasons for the failure for each task. Each one is listed in the Queue Manager tree.

The Queue Manager displays the status counts (Active/Failed) for each task as well as details about the entry. In the Queue Manager the queues are subdivided into a tree structure. The lowest node of the tree represents an individual queue file entry. You can move the active queue pointer to entries anywhere in the queue list for a particular task. The Queue Processor will process entries from this new location. In addition, you can re-queue Failed tasks and delete tasks from both the Active and Failed queue lists.

3.6.1 Queue Manager Operations

The Edit > Queue Manager menu on the Queue Processor menu bar opens the Queue Manager main window.

Queue Manager window used in Edit operations

3.6.2 Purging a Queue

Circumstances may arise when single or multiple queue entries need to be deleted. One example involves JBTOHD tasks. When JBTOHD entries have not been processed in a period of time (a day or more), the usefulness of retrieving these images diminishes. There may be hundreds of these queue entries for a study. You can select multiple entries using the Queue Manager and delete them.

1. Select the entries to be deleted

2. Right click in the selected area.

3. In the popup menu displayed, select Purge Queue.
Note: This popup menu can also be accessed from the keyboard by using Shift + F10.

This popup menu can be accessed from the keyboard by using Shift + F10.
Piurge Queue option on popup menu

4. Acknowledge the verification popup. The entries will be deleted and the Active/Failed queue count will be changed to reflect the change.

This image depicts the confirmation window for the task action selected.

3.6.3 Re-Queuing a Failed Image File

The Queue Processor will attempt to process an entry three times to get a successful result. After the third attempt, the entry is placed in the Failed category. In most cases the cause of the failure can be corrected and the Failed entry re-queued with success.

1. Right-click a failed entry in a task and select Re-queue from the popup menu, as shown in the example.
Note: This popup menu can also be accessed from the keyboard by using Shift + F10.

This popup menu can be accessed from the keyboard by using Shift + F10.
This is an example of the sub menu available for the queue task.

2. Click Yes in the confirmation message shown.

This image depicts the confirmation window for the task action selected.

The queue entry will move from the Failed queue to the Active queue for that task. The queue counts will be updated.

3.6.4 Setting a Queue Partition

Each task has an active queue pointer that designates the next entry to be processed. This pointer can be manually moved to begin processing at another location in the queue. A typical situation may be when a queue entry is corrupted. The queue pointer can be moved to the next entry where processing continues with the rest of the queue entries for that task.

1. To move the active queue pointer (Set Queue Partition), right-click a failed entry in a task and select Re-queue from the popup menu, as shown in the example.
Note: This popup menu can also be accessed from the keyboard by using Shift + F10.

This popup menu can be accessed from the keyboard by using Shift + F10.
Re-queue option on popup menu

2. From the popup menu, select Set Queue Partition.
The entries above the selected one will move to the Failed queue. The selected entry will be the top entry in the Active queue and will be the next queue entry processed.

NOT PROCESSED in queue

3.6.5 Accessing Import Queue Properties

You can access the failed Import Queue properties by right-clicking a failed IMPORT queue node and selecting Import Queue Properties.
Note: This popup menu can also be accessed from the keyboard by using Shift + F10.

This popup menu can be accessed from the keyboard by using Shift + F10.
Import Queue Properties option on popup menu

When you right-click the Failed queue item and select Import Queue Properties, the same Import Queue Properties window is displayed showing file values to help you debug the problem. For details, see section 4.6.3.3 IMPORT Queue Status Report.

3.7 Network Location Manager

The BP processor applications send/receive images to/from physical devices and networks using different types of media. These types of media need to be recorded in the VistA database. The information that is stored includes the type of media, the location, online status, security access, etc. This information can be entered into VistA using the Network Location Manager.

RAiD tab in Network Location Manager

3.7.1 Configuring the Network Location Manager

The Edit > Network Location Manager menu on the Queue Processor menu bar opens the Network Location Manager window. Seven types of entries are displayed using the tabs and are described in the table.

Function	Description
RAID	RAID shares on the Imaging server cluster. Note: Use “MAGnH” names for these shares. “n” is a unique number . “H” indicates the file directory structure is hashed.
JUKEBOX	Cache shares on the archive device (jukebox/Archive Appliance) Note: Use “WORMOTGnH” names for these shares. “n” is a unique number . “H” indicates that the file directory structure is hashed.
Routers	Network shares on remote servers/desktops where new images are transmitted using the Imaging AutoRouter product. Security: Access to these locations requires a Windows Username and Password. Note: Use meaningful names as these names are used in the routing rules file (ROUTE.DIC) on the routing gateways.
GCC	External network shares where images can be transferred for non VistA Imaging usage. Security: Access to these locations requires a Windows Username and Password.
EKG	Remote GE Muse server share locations where the Electrocardiograms are stored. The EKG strips can be viewed from these remote locations using the Clinical Display software. Security: Access to these locations requires a Windows Username and Password.
URLs	Remote Image Views is a feature of the Clinical Display software that allows users to view patient images from any VA hospital in the country. These images are processed through a web service on remote server. The URL for this web service is stored here.
Diagrams	Annotation diagrams (templates and mark-ups) are stored at these share locations. The Clinical Display software has a tool that can be used to edit and save these marked-up diagrams for a patient.

3.7.1.1 RAID Tab

Each site has an Imaging RAID (primary) where images from the gateways, scanners, cameras, etc. are stored for quick access for display on VistARad and Clinical Display workstations. This storage resides on the Imaging cluster. Shares can have different capacities for storage. The physical location for each of these shares is stored under the RAID storage type in the Network Location Manager.

To edit the properties of a network location, right-click the entry and select Properties on the pop-up menu.

Note: This popup menu can also be accessed from the keyboard by using Shift + F10.

Displaying/editing properties in the RAID tab

Field	Description
NETWORK LOCATION	Name of a RAID share on the Imaging cluster. Note: Use “MAGnH” names for these shares. “n” is a unique number . “H” indicates the file directory structure is hashed.
IEN	The record number in VistA for this Network Location.
PHYSICAL REFERENCE	The UNC (Universal Naming Convention) containing the server and share name for the RAID storage.
TOTAL SPACE	Storage capacity for the share.
FREE SPACE	Free space remaining on the share.
OPERATIONAL STATUS	Logical state of the share (“ONLINE" or “OFFLINE”).
READ ONLY	If set, data can be read but not written to this share. In addition, Purge and Auto Write will not consider this share as a candidate for purge or new image storage.
STORAGE TYPE	“MAGNETIC” for magnetic media.
HASH SUBDIRECTORY	A hierarchal folder structure will be created/used (default is hashed, display only).

3.7.1.2 Jukebox Tab

Most sites have local archive storage (jukebox). Some sites have a remote archive where multiple sites share the same storage. The images that are initially copied to the RAID are copied from the RAID to the archive device. The archive devices have one or more shares where the images are copied for long term storage. For remote consolidated archive storage each site has its own share to keep the images segregated.

To edit the properties of a network location, right-click the entry and select Properties on the pop-up menu.

Note: This popup menu can also be accessed from the keyboard by using Shift + F10.

Field	Description
NETWORK LOCATION	Name of a share on the server containing the archive device. Note: Use “WORMOTGnH” names for these shares. “n” is a unique number . “H” indicates the file directory structure is hashed.
IEN	The record number in VistA for this Network Location.
PHYSICAL REFERENCE	The UNC (Universal Naming Convention) containing the server and share name for the archive storage.
TOTAL SPACE	Storage capacity for the share.
FREE SPACE	Free space remaining on the share.
OPERATIONAL STATUS	Logical state of the share (“ONLINE" or “OFFLINE”)
STORAGE TYPE	“WORM-OTG” for archive media.
HASH SUBDIRECTORY	A flat or hierarchal folder structure will be created/used (default is hashed, display only).

3.7.1.3 Routers Tab

Some types of images are routed to remote Radiologists using the VistA Imaging AutoRouting software. These images are written to a share on their remote server using the Username/Password contained in the properties of this storage type.

To edit the properties of a network location, right-click the entry and select Properties on the pop-up menu.

Note: This popup menu can also be accessed from the keyboard by using Shift + F10.

Field	Description
NETWORK LOCATION	Name of a share on the remote Radiologist’s server Note: Use a name that reflects the location where these images will be sent. This name is used in the ROUTE.DIC file on the Routing Gateway.
IEN	The record number in VistA for this Network Location.
PHYSICAL REFERENCE	The UNC (Universal Naming Convention) containing the server and share name for the remote storage location.
OPERATIONAL STATUS	Logical state of the share (“ONLINE" or “OFFLINE”).
STORAGE TYPE	“ROUTER”
HASH SUBDIRECTORY	A flat or hierarchal folder structure will be created/used (default is hashed, display only).
ABSTRACT	Abstract files can be copied.
FULL	Full files can be copied.
BIG	BIG files can be copied.
DICOM	DCM files can be copied.
COMPRESSION	Data compression/decompression is used on the files being sent to the remote server. (Either none or JPEG-2000, found on the table, not on the properties page, can be edited by VA Fileman)
USERNAME	Windows login Username for the remote server where the images will be sent. This account must have READ/WRITE access to the remote share.
PASSWORD	Windows login Password for the remote server where the images will be sent.
MAX # RETRY ON CONNECT	Number of times that will be attempted to get a connection to the remote server using the AutoRouter software before a failure message is generated.
MAX # RETRY ON TRANSMIT	Number of times that a copy will be attempted to the remote server using the AutoRouter software before a failure message is generated.
SYNTAX	“UNC”. The connection to the share will be in the format \\server\share_name.(Found on the table, not on the properties page, can be edited by VA Fileman)
SUBDIRECTORY	Name of a subdirectory where files are to be stored. The value of this field is concatenated to the name of the network location (the 'physical name') to create the complete path-name.
RETENTION PERIOD	Time in days that image files are kept on the remote server before they are purged.
LAST PURGE DATE	Date/time of last purge on the remote server.
SITE	Name of the remote location. Note: Use a name different from the NETWORK LOCATION name. This string is displayed in VistARad in the “RC” column.
TIME OFFLINE	Date and time that this server was inaccessible. Set by the routing application, found on the table, not on the properties page.

3.7.1.4 GCC Tab

Photo ID images, etc. can be sent to a remote location directly from the Queue Processor software. These images are written to a share on the remote server using the Username/Password contained in the properties of this storage type.

To edit the properties of a network location, right-click the entry and select Properties on the pop-up menu.

Note: This popup menu can also be accessed from the keyboard by using Shift + F10.

Field	Description
NETWORK LOCATION	Name of a share on the server where the Photo ID, etc. will be sent. Note: Use names to reflect the type of transfer for these shares.
IEN	The record number in VistA for this Network Location
PHYSICAL REFERENCE	The UNC (Universal Naming Convention) containing the server and share name for the remote storage location.
OPERATIONAL STATUS	Logical state of the share (“ONLINE" or “OFFLINE”)
STORAGE TYPE	“GCC” for Global Carbon Copy (Displays as: EXPORT))
HASH SUBDIRECTORY	A flat or hierarchal folder structure will be created/used (default is hashed).

3.7.1.5 EKG Tab

The Clinical Display software has the capability to display EKG strips from local and remote MUSE servers. When a patient is selected, the software maps to these MUSE locations using the NET USERNAME field (#50) login in the IMAGING SITE PARAMETERS file (#2006.1) and looks for the patient data. When it finds the image data, it is copied from the MUSE server to the Display station and viewed by the user.

To edit the properties of a network location, right-click the entry and select Properties on the pop-up menu.

Note: This popup menu can also be accessed from the keyboard by using Shift + F10.

Field	Description
NETWORK LOCATION	Name of a share on the MUSE server where the EKG data is stored. Note: Use names to reflect the type of transfer for these shares.
IEN	The record number in VistA for this Network Location
PHYSICAL REFERENCE	The UNC (Universal Naming Convention) containing the MUSE server and share name.
OPERATIONAL STATUS	Logical state of the share (“ONLINE" or “OFFLINE”)
STORAGE TYPE	“MUSE-EKG”
MUSE SITE #	MUSE EKG network location number. Typically, a site with a single MUSE server that holds EKGs for one site would use 1.
MUSE VERSION #	MUSE software version

3.7.1.6 URLs Tab

The Remote Image Views functionality in the Clinical Display application uses a Network Location entry that points to the VistA Site Service to determine the server and port of remote VistA databases. This Network Location entry is a WEB service running on a centralized accessible server on the network.

To edit the properties of a network location, right-click the entry and select Properties on the pop-up menu.

Note: This popup menu can also be accessed from the keyboard by using Shift + F10.

Field	Description
NETWORK LOCATION	The name of this WEB service. Note: suggested name- VISTASITESERVICE
IEN	The record number in VistA for this Network Location
PHYSICAL REFERENCE	URL name of the location of the WEB service.
OPERATIONAL STATUS	Logical state of the service (“ONLINE" or “OFFLINE”)
STORAGE TYPE	“URL”

3.7.1.7 Diagrams Tab

The Diagram Annotation tool is an optional Imaging component that is accessed from CPRS. The Diagram Annotation tool is used to annotate online diagram ‘templates’ and then save the results directly to a patient’s electronic medical record.

To edit the properties of a network location, right-click the entry and select Properties on the pop-up menu.

Note: This popup menu can also be accessed from the keyboard by using Shift + F10.

Field	Description
NETWORK LOCATION	The name of this template location
IEN	The record number in VistA for this Network Location
PHYSICAL REFERENCE	The UNC (Universal Naming Convention) containing the server and share name for the template location.
OPERATIONAL STATUS	Logical state of the service (“ONLINE" or “OFFLINE”)
STORAGE TYPE	DIAGRAM

3.7.2 Adding a New Location to Network Location Manager

Note: The following procedure applies to all the tabs in the Network Location Manager window.

1. From the Queue Processor menu bar, select Edit > Network Location Manager to open the following window.

The RAID tab is automatically selected.

2. To add a new network location, click the New button at the bottom. The Network Location Properties window will be displayed.

Network Location Properties window

3. Type the Share Name.

4. At the Network Share field, either type the path to the location where images are to be stored, or click the browse (…) button and specify the path.

5. Select the appropriate option at the Storage Type field.

6. Click Apply.

Additional fields relevant to the storage type are displayed. The example below is for Storage Type RAID only.

Note: The STORAGE TYPE field is preselected depending on the Network Location tab selected. If the EKG tab is selected, then the STORAGE TYPE will be set to EKG, and so forth. However, the preselected value can be modified.

7. Leave the Operational Status check box selected by default setting, or clear it.

8. Leave the Read Only check box cleared by default setting or select it.

9. Click Apply to add the changes to the database or click OK to add the changes and exit.

3.7.3 Editing the Properties of a Network Location

To edit the properties of a network location, right-click the entry and select Properties on the pop-up menu.

Note: This popup menu can also be accessed from the keyboard by using Shift + F10.

RAID properties.JPG

1. From the Queue Processor menu bar, select Edit > Network Location Manager and select the appropriate tab.

2. Right-click a row in a table grid and select Properties from the popup menu displayed above.
Note: only the properties applicable to the selected Storage Type are editable.

The Network Location Properties dialog box is displayed. The Share Name and Network Share are displayed based on your selection.

Network Location Properties window

3. Modify any of the enabled settings.

4. Click Apply and OK to add the changes to the database and exit or click OK to add the changes and exit.

3.7.4 Adding a RAID Group

1. From the Queue Processor menu bar, select Edit > Network Location Manager to open the following window.

The RAID tab is automatically selected.

RAID group window

2. Click the Add Group button at the bottom.

A new RAID group is added to the tree. For this example, the name would be RG-ATG5.

3.7.5 GCC Queue for PhotoID

The GCC has a method for exporting photo IDs to a designated share as a post-capture process. Its implementation requires an entry in the IMAGE ACTIONS file (#2005.86). Its purpose is to export the files to a site specified print server or share either within the local area network or external to the local area network.

This protocol was requested by Indian Health Service (IHS) and called for the exported file to have the patient’s DFN included in the file name so that the operator could correctly assign a patient photo IDs.

In order to activate this functionality, create one or more GCC locations to receive the exported photo IDs using Network Location Manager. Edit the protocol in the IMAGE ACTIONS file (#2005.86) using FileMan.

Example:

VA FileMan 2<.0

Select OPTION: ENTER OR EDIT FILE ENTRIES

INPUT TO WHAT FILE: 2005.86 IMAGE ACTIONS

(2 entries)

EDIT WHICH FIELD: ALL// ACTIVE

THEN EDIT FIELD: TAG

THEN EDIT FIELD: ROUTINE

THEN EDIT FIELD: TYPE (multiple)

EDIT WHICH TYPE SUB-FIELD: ALL//<enter>

THEN EDIT FIELD: EXPORT LOCATION

THEN EDIT FIELD: <enter>

STORE THESE FIELDS IN TEMPLATE: <enter>

Select IMAGE ACTIONS NAME: PHOTO-ID COPY

ACTIVE: NO// Y YES

TAG: PID//<enter> **

ROUTINE: MAGQBGCC//<enter>**

Select TYPE: PHOTO ID//< enter>

EXPORT LOCATION: GCC21 <<<this field points to the NETWORK LOCATION (#2005.2) file, select the network location to receive the exported image file.

**the TAG and ROUTINE fields are predefined by VistA Imaging patch MAG*3.0*39 with the routine to be used by the HIS. The files created at the exported location will be named using the patient DFN. If a site wishes to change this, they can use a locally defined routine.

Chapter 4 Queue Processor

=====================================================================

· Application Description

· Setting up

· Tasking

· Understanding Processing

· Starting/Running the application

· Reports

====================================================================

4.1 Application Description

The Queue Processor application is the main application in the BP product suite. It processes all the I/O operations between the RAID shares and the archive device (jukebox). It is important that this process be monitored daily and kept running continuously. It performs the following tasks:

· Copies new images from the RAID to the jukebox.

· Retrieves images from archive storage to the RAID.

· Triggers Purge events ( automatic and scheduled).

· Triggers Verifier events (scheduled).

· Manages disk space consumption specified by the Imaging Coordinator.

· Processes queue entries.

· Creates abstract files from Full/BIG files.

· Processes images from remote cameras and capture device in Clinical procedures.

· Copies images to remote destinations outside of Imaging.

· Watermarks images associated with a Rescinded Advance Directive with the text “Rescinded”.

4.2 Setup Guidelines

Once the Queue Processor is installed, one or more BP Servers are required for processing.
Tasks are assigned to each BP Server. One task cannot be assigned to multiple servers; however a task can be assigned to any server to change the priority of processing.
In addition to setting up the task assignments, there are various parameters that need to be set up as described in this document.
Once the parameters are set up, the Queue Processor can be started to process active queue entries.

Note: The Queue Processor runs without operator intervention and should operate continuously in order to keep pace with the workload. It should be monitored daily and it is highly recommended to task the BP Monitor utility. For details, see Chapter 7 System Monitoring.

4.3 Tasking

The Queue Processor has a set list of tasks that it performs. The specific requests for each task originate on the local Queue Processor or from another VistA Imaging product.

The process is as follows:

1. These requests are sent to the VistA database and are stored on FIFO lists called queues.

2. The Queue Processor dynamically checks these queues to determine if there is work to be completed.

3. When an entry is found, the processing is started based on the queue type.

4. When the processing is successfully completed, the queue count is decremented and the Queue Processor waits for another task to be sent.

5. When the processing fails the entry is re-queued twice before it is placed on a failed queue for that task. Failed IMPORT queues must be manually re-queued; there is no retry.
Note: You will be required to investigate and determine the reason for the failure and re-queue the item once the problem is resolved.

When all the tasks are assigned to one server, the queues are processed in the following order of priority:

· JBTOHD (jukebox to hard drive) restores images to the RAID shares from the archive device based on requests for viewing these images on display workstations or creating missing abstract files.

Note: images can only be viewed from the RAID shares.

This is a graphical display of a JBTOHD queue task. Clinical display workstation, VistARad and/or the Abstract queue add a request to JBTOHD QUEUE TO COPY IMAGES FILES FROM THE Jukebox to VistA Imaging share for the Clinical display workstations or VistARad to access.

· PREFET (pre-fetch) populates the RAID shares with images that were requested on display workstations by users with the MAG PREFETCH security key.

he jukebox to VistA Imaging share for Clinical display workstation and VistARad to access. Note: only users who have the MAG PREFETCH security key can create PREFET queues.

· ABSTRACT creates thumbnail files with the .abs file extension, when this file type does not exist for an image set. These file derivatives only exist for certain types of files and can only be created when the Full or BIG files are present for an image set. Queue types Import and VIC Photo ID will generate ABSTRACT queue.

This is a graphical display of an ABSTRACT queue, VistA capture workstation and/or the Import queue add a requests to the ABSTRACT queue to create thumbnails (ABS derivatives) of images.

· IMPORT provides a means for external applications to store images in the VistA Imaging environment using the IMPORT API. It also watermarks images associated with a Rescinded Advance Directive with the text “Rescinded”.

IMPORT queue process diagram. External applications add a request to the IMPORT queue to capture external images (typically, clinical procedures, Veteran ID Cards, and IMed Consents) in the VistA Imaging environment.

· JUKEBOX copies images from a RAID share to a long-term archive device (jukebox).

This is a graphical display of a JUXEBOX queue. When capture applications such as VistA capture workstations and DICOM Gateway acquire new images, they add a request to the JUKEBOX queue to copy these images from VistA Imaging share to the jukebox for long-term archival storage.

· DELETE removes images from the VistA Imaging shares. The DELETE queue is set when an end-user, who has the MAG DELETE security key, selects an image to be deleted in the Clinical Display software. Typically, these are images that are of poor quality or saved against the wrong patient.

DELETE queue diagram. VistA Display Workstations add a request to the DELETE queue to remove any image files from the shares that are poor in quality or contain the incorrect identity of a patient.

· GCC (generic carbon copy) copies images to specified remote locations.

This is a graphical display of a GCC queue. Capture applications such as VistA Imaging clinical capture can add a request to the Generic Carbon Copy (GCC) queue to export images to a windows share on an external commercial system.

· EVAL entries are initiated by the DICOM Gateways to facilitate auto routing of images to remote display workstations.
Note: The EVAL queue is not processed by the BP Queue Processor but may be purged using the Queue Management by Type option.

EVAL queue. A site can set up routing rules that determine if an image meets certain criteria for exporting to external locations. The image can be routed to a remote VistARad workstation for the physician to view. Periodically, entries are purged that accumulate in the EVAL queue.

4.4 Understanding Processing

When the BP Server tasks are set up and the parameters are set to the values determined by the site, you click the Start button to start processing queue (task) entries. The processing steps for a typical JUKEBOX request are described below:

1. When an image is processed by the DICOM Gateway or Clinical Capture workstation, the image file is copied to a RAID share. The VistA record for that image is updated with the RAID share location.

2. The Clinical Workstation application or DICOM image gateway then requests that an image be saved to the jukebox by creating an entry in the JUKEBOX queue file on VistA. The queue entry identifies the file path, the origination of the file and other pertinent data that the Queue Processor will need to successfully complete the processing.

3. When the JUKEBOX queue entry is processed, the image file is copied from the RAID share to the archive device (jukebox) and the queue entry is deleted from the queue file. The queue count for the JUKEBOX queue is decremented to reflect the number of remaining queue entries to be processed.

4.5 Starting/Running the Application

4.5.1 Starting the Application and Analyzing the Activity

1. From the Windows Start > Programs menu, select VistA Imaging Programs > Background Processor > Queue Processor.

2. Log into the application using a valid VistA access and verify code.
Note: The secondary menu option MAG WINDOWS is required for access to the Queue Processor.

The Queue Processor application window opens.

This image depicts the main Background Processor’s window.

3. Click the Start button in the upper right-hand corner.

If the Queue Processor is not properly configured, you will get alert messages. Review the steps in section 2.5 Configuring BP Servers.

4. After one or two minutes, click the Stop button and view the populated fields.
If no queues have entries, only the storage statistics are displayed in the VistA Storage section of the window.

The following example shows a sample output of processed activity. The queues being processed are displayed under the Start button.

This example shows a sample output of processed activity. The queues being processed are displayed under the Start button

Name	Description
VistA Storage
Network Location Name	Name of the entry in the NETWORK LOCATION file
Storage Type	Types of storage: · MAG = Magnetic (RAID share) · WORM-OTG = Write Once Read Many (archive device) · GRP = RAID Group (RAID share group) Note: These types are also defined in the Network Location Properties dialog box.
IEN	Internal Entry Number in the NETWORK LOCATION file for the Storage Type device
Free Space	Disk free space available in megabytes
Disk Size	Disk space capacity in megabytes
Share Path	UNC path of the share
RAID Group	RAID share group name
(Queue Activity box)
Queue	Name of the queue identifying the task being processed
Active	Number of active files to be processed
Failed	Number of files that failed in processing. Failed queues should be checked. For details, see Chapter 8 Troubleshooting.
BP Event Log - {log file location}
Event Time	Date and time of the last run of the log
Process: Queue IEN	Queue type, queue number, and status check info
Process Status	Source and destination of each file transfer, creation, or deletion

4.5.2 Getting Help

You can get help from different sources:

· Queue Processor GUI

Ø Hovering the cursor over the application window and pressing the F1 key

Ø Selecting Help from the menu bar

· Call customer support at the National Helpdesk.

Note: Be sure to have the information shown in the example of the table that follows and a copy of the most recent log files.

Help version window

Name	Description
Version	Software version and build number
C:\Program Files\VistA\Imaging\ BackProc\Magbtm.exe	Location of the Background Processor executable on your hard drive
2067 KB {date}	File size and date of executable
Mag_MakeAbs.exe	Executable and version number of the ABSTRACT queue used to create the abstracts (thumbnails) of images
System Installations	Version and installation date of Imaging patches Note: The latest patch is listed at the bottom.

4.6 Reports

Three types of output are produced to notify users of important occurrences:

Log files
Emails
Screen-generated output

4.6.1 Log Files

New log files are created as HTML files at the beginning of every session. HTML files are viewable, printable, and searchable. By default, the BP Queue Processor log files reside in the C:\Program Files\VistA\Imaging\BackProc\log\BackProc directory. You can access these files by:

· Selecting File > Open Log on the BP Queue Processor menu bar

· Using an internet browser

Note: The log files can be imported into an Excel spreadsheet.

Important: These files should be kept for historical/troubleshooting reasons and added to the tape backup process to safeguard the files. (See Appendix B: Backups in the VistA Imaging System Installation Guide.)

Log File Format

BP Queue Processor log files are archived as HTML files and have the year-month-day and sequence number imbedded in the file name, as shown in the right pane of the window.

$This image depicts the directory path for the Background Processor’s log files. Directory path is C:\Program Files\VistA\Imaging\BackProc\log$

If more than one log file is run on the same day, the system adds a sequence number such as “01” following the date in the file name. For multiple runs on the same day, the highest sequence number is the latest log file run for the day.

The Queue Processor produces multiple log files for a processing run. Each file contains different information.

4.6.1.1 BackProc Log

The BackProc.log file records all activity in the Event Log section in the Queue Processor window.

example of BackProc log

Name	Description
Date/Time	Actual time when the IMAGE file (#2005) was processed
Event_Queue_Ref	Queue name and entry number and status check info
Message/Path	Description of action taken (or statistics for status checks)

4.6.1.2 BP Error Log

The BPError.log file records error conditions with the operating system and Broker.

This is an example of a BPError.log file.

Name	Description
Date/Time	Actual time when the IMAGE file (#2005) was processed
Event_Queue_Ref	Error category
Message/Path	Description of error condition

4.6.2 Email Messages

The following messages, listed in alphabetical order, are generated or triggered by the Queue Processor.

Important: Be sure to add the local Image support staff person to the local MAG SERVER mail group, and at least one pager number in the MEMBERS REMOTE multiple.

4.6.2.1 Ad_Hoc_Image_Site_Usage

This message is sent when the menu option Ad hoc Enterprise Site Report [MAG ENTERPRISE] is used and it has completed gathering information.

Example:

Subj: Ad Hoc Image Site Usage: SALT LAKE CITY^660 [#31177] 10/14/09@15:20

168 lines

From: IMAGPROVIDERONETWOSIX,ONETWOSIX In 'IN' basket. Page 1

------------------------------------------------------------------------

SITE: SALT LAKE CITY^660

Reporting Period: Jul 06, 2009 - Oct 14, 2009

DATE: OCT 14, 2009@15:20:48 EST

DOMAIN: IMGxxxxx.DOMAIN.EXT

2005 ENTRIES: 17805

2006.81 ENTRIES: 5

Production Account: 0

WS DIS VERS: 3.0.59.31^Win XP.5.1.2600^1

WS DIS VERS: 3.0.72.30^Win Server.5.2.3790^1

WS CAP VERS: 3.0.72.30^Win XP.5.1.2600^1

4.6.2.2 Application Process Failure

This message is sent by several of the Imaging applications when the PLACE value cannot be resolved for the image entry. The PLACE value is a valid entry in the IMAGING SITE PARAMETERS file (#2006.1) or a value in the ASSOCIATED INSTITUTION field (#.04) of this file.

Example:

Subj: Application process failure [#846445] 23 Oct 2009 09:45:30 -0400 (EDT)

18 lines

From: <xxx@DETROIT.DOMAIN.EXT>

--------------------------------------------------------------------

SITE: DETROIT.DOMAIN.EXT

DATE: OCT 23, 2009@09:45:30 EDT

Cannot determine 'place' (location, division, institution) for image.

At: GETPLACE+5^MAGBAPI +3 = I 'PLACE,$$MAXREP(10) D

Called From: PLACE+1^MAGBAPI +1 = Q $$GETPLACE(+$O(^MAG(2006.1,"B",IEN,""))

4.6.2.3 Auto_RAID_Group_Purge

This message is sent by the Queue Processor when the following conditions occur:

The Scheduled RAID Advance Group is scheduled and the Auto Purge is set.
The next share in the RAID group reaches the Percent Server Reserve and a purge is automatically started.

Example:

Subj: Auto_RAID_group_purge [#31180] 10/27/09@15:04 2 lines

From: VistA Imaging Auto_RAID_group_purge In 'IN' basket. Page 1 *New*

-----------------------------------------------------------------------

SITE: IMGDEM01.DOMAIN.EXT

DATE: Oct 27, 2009@15:04:37 EST

4.6.2.4 GCC Copy Error

This message is sent during processing when GCC queues have connectivity problems.

Example:

Subj: GCC Copy Error [#31157] 10/07/09@20:36 6 lines

From: VistA Imaging GCC Queue Error In 'IN' basket. Page 1 *New*

--------------------------------------------------------------------

SITE: IMGxxx.DOMAIN.EXT

DATE: Oct 07, 2009@20:36:22 EST

"The GCC queue processor is having difficulty copying files to the network location. The last copy attempt failed 3 times with an error status of : \\VHAxxxx400\GCC24$: Cannot connect to the Export Share. The next notification will occur in 6 hours.

4.6.2.5 Get_Next_RAID_Group_Failure

This message is sent by the Queue Processor when the Scheduled RAID Advance is set and it cannot advance to the next RAID Group perhaps because all the shares in the group are set to READ ONLY or there is a connectivity problem.

Example:

Subj: Get_Next_RAID_Group_failure [#31173] 10/27/09@13:51 4 lines

From: VistA Imaging Get_Next_RAID_Group_failure In 'IN' basket. Page 1 *New*

-----------------------------------------------------------------------

SITE: IMGxxxx.DOMAIN.EXT

DATE: Oct 27, 2009@13:51:46 EST

Production Account: 0

The get next raid group function failed!

4.6.2.6 Image_Cache_Critically_Low

This message is sent by the Queue Processor when it determines that the cache is below the Percent Server Reserve factor and the Auto Purge has not been set.

Example:

Subj: Image Cache Critically Low at [#31158] 10/07/09@21:40 22 lines

From: BACKGROUND,USER I In 'IN' basket. Page 1

----------------------------------------------------------------------

SITE: IMGDEM01.DOMAIN.EXT

DATE: Oct 07, 2009@21:40:01 EST

SENDER: SALT LAKE CITY Imaging Background Processor

Total Cache Free: VistA Imaging RAID storage is Critically Low gigabytes

Total Cache Available: 2131 gigabytes

The Automatic Purge process is NOT configured. The 4 Imaging cache servers will require operator intervention to ensure continued availability. The following MAG SERVER members are being notified:

IMAGPROVIDERONETWOSIX,ONETWOSIX

IMAGPROVIDERONETHREETHREE,ONETHREETHREE

The next notifications will occur in: 0 hours.

4.6.2.7 Image_File_Size_Variance

This message is sent during a purge when a file on the RAID has met the criterion for deletion but the copy of this file on the jukebox is a different size.

Example:

Subj: Image File Size Variance: [#852162] 2 Dec 2009 16:28:45 -0500 (EST)

6 lines

From: Image_File_Size_Variance In 'IN' basket. Page 1 *New*

-------------------------------------------------------------------------------

SITE: IMGxxxx.DOMAIN.EXT

DATE: DEC 02, 2009@16:28:45 EST

DOMAIN: IMGxxxx.DOMAIN.EXT

Filename: False Positive CopySBY00012248164.TIF

VistA Cache Size: 14650

Jukebox Size: 919190

4.6.2.8 INSTALLATION

This message is sent when the KIDS for this patch is installed.

Example:

Subj: KIDS-MAG*3.0*39 INSTALLATION [#853149] 10 Dec 2009 08:34:54 -0500 (EST)

3 lines

From: INSTALLATION In 'IN' basket. Page 1 *New*

PACKAGE INSTALL

SITE: IMGxxxx.DOMAIN.EXT

PACKAGE: IMAGING

VERSION: 3.0

Start time: Dec 10, 2009@08:34:51

Completion time: Dec 10, 2009@08:34:54

Run time: 0:00:03

DATE: 3091210

Installed by: INSTALLER

Install Name: MAG*3.0*39

Distribution Date: 3091005

VistA Imaging V3.0 - Patch 39 - Test 22 10/05/2009 11:16AM ;Created on Oct 05,

2009@11:16:02

4.6.2.9 Monthly_Image_Site_Usage

This message is sent when the monthly site usage report is finished gathering information. At completion, the task is re-queued for the next month.

Example:

Subj: Monthly Image Site Usage: SALT LAKE CITY^660 (Sep 2009) [#31135]

10/01/09@04:01 143 lines

From: IMAGPROVIDERONETWOONEFOUR,ONETWOONEFOUR In 'IN' basket. Page 1

------------------------------------------ ----------------------------

SITE: SALT LAKE CITY^660

Reporting Period: Sep 01, 2009 - Sep 30, 2009

DATE: OCT 01, 2009@04:01:03 EST

DOMAIN: IMGxxxx.DOMAIN.EXT

2005 ENTRIES: 17798

2006.81 ENTRIES: 5

WS DIS VERS: 3.0.59.31^Win XP.5.1.2600^1

WS DIS VERS: 3.0.72.30^Win Server.5.2.3790^1

WS CAP VERS: 3.0.72.30^Win XP.5.1.2600^1

WS VR VERS: 3.0.41.17^Win XP.5.1.2600^2

4.6.2.10 Photo_ID_Action

This message is sent by the Queue Processor when processing a GCC queue that was triggered from a Photo ID image.

Example of the message when the PHOTO-ID COPY entry is not properly defined:

Subj: Photo_I_D_Action [#31190] 10/27/09@08:57 7 lines

From: VistA Imaging PHOTO ID ACTION In 'IN' basket. Page 1 *New*

--------------------------------------------------------------------

SITE: IMGxxxx.DOMAIN.EXT

DATE: Oct 27, 2009@08:57:21 EST

Production Account: 0

The Photo ID protocol in the IMAGE ACTION file (#2005.86) could not resolve the target export location as currently defined.

Update the EXPORT LOCATION field for the PHOTO-ID COPY entry in IMAGE ACTION file.

4.6.2.11 Scheduled_Purge_Failure

This message is sent when the Scheduled Purge does not start at the designated time.

Example:

Subj: Scheduled_Purge_failure [#31195] 10/27/09@12:40 4 lines

From: VistA Imaging MAGQCBP In 'IN' basket. Page 1 *New*

-------------------------------------------------------------------------------

SITE: IMGxxxxx.DOMAIN.EXT

DATE: Oct 27, 2009@12:40:01 EST

The SALT LAKE CITY implementation of VistA Imaging has failed to start the sche

dule Purge activity!

The task is currently assigned to BP Server: ISW-xxxxx-LT

4.6.2.12 Scheduled_RAID_Group_Advance_Failure

This message is sent when the system cannot change to another RAID Group because none of the groups has enough free space.

Example:

Subj: Scheduled_RAID_Group_Advance_failure! [#31783] 04/02/10@03:20 3 lines

From: VistA Imaging MAGQ FS CHNGE In 'IN' basket. Page 1

-------------------------------------------------------------------------------

SITE: IMGDEM01.DOMAIN.EXT

DATE: Apr 02, 2010@03:20:06 EST

The scheduled RAID Group Advance failed!

4.6.2.13 Scheduled_Verifier_Failure

This message is sent when the Scheduled Verifier does not start at the designated time.

Example:

SITE: SALT LAKE.DOMAIN.EXT

DATE: Feb 11, 2010@00:30:04 PST The SALT LAKE HCS implementation of VistA Imaging has failed to start the schedule Verifier activity!

The task is currently assigned to BP Server: VHASLCBP1

4.6.2.14 Site_Report_Task_Was_Restarted

This message is sent by the Monitor Background Processor Activity [MAGQ BPMONITOR] menu option if the monthly Imaging Site Usage report has to be re-tasked.

Example:

Subj: Site_report_task_was_restarted [#31231] 10/27/09@07:13 4 lines

From: VistA Imaging MAGQCBP In 'IN' basket. Page 1 *New*

----------------------------------------------------------------------

SITE: IMGxxxx.DOMAIN.EXT

DATE: Oct 27, 2009@07:13:01 EST

The inactive monthly Imaging Site Usage report task was restarted

The problem was: Inactive

4.6.2.15 VI_BP_Eval_Queue

This message is sent when number of entries on the EVAL queue exceeds a user defined threshold.

Example:

SITE: SALT LAKE.DOMAIN.EXT

DATE: Mar 30, 2010@13:25 EDT The total number of EVAL queues is 9451. Please review the DICOM Gateways to ensure Routing is appropriately setup with the correct destination.

If your site is not using DICOM Gateway for Routing then review the Imaging DICOM Gateway Installation Guide, Section 4.3.

On-Demand Routing will not generate EVAL queues, if your site is doing only On-Demand Routing then the DICOM Gateway parameters are set incorrectly.

Check the following DICOM parameters on all your Gateways:

(On-Demand routing does not require these parameters to be set.)

Will this computer be a Routing Processor? // NO Will this computer be part of a system where 'autorouting' is active? // NO

4.6.2.16 VI_BP_Queue_Processor_Failure

This message is sent by the Monitor Background Process when a user defined threshold for an activity is exceeded.

Example:

Subj: VI_BP_Queue_Processor_failure [#31186] 10/27/09@06:45 6 lines

From: VistA Imaging MAGQCBP In 'IN' basket. Page 1 *New*

---------------------------------------------------------------------

SITE: IMGDEM01.DOMAIN.EXT

DATE: Oct 27, 2009@06:45 EST

VistA Imaging BP Server, ISW-xxxxx-LT has failed to process a JUKEBOX queue for 25 minutes.

The last date/time a queue was processed was on: Oct 26, 2009@11:38:27

Total JUKEBOX queues are: 100.

This BP Queue processor was supporting the VI implementation serving: SALT LAKE CITY

4.6.2.17 “Rescinded” Watermarking Successful

The following is an example of the email message generated when an image associated with a Rescinded Advance Directive is successfully watermarked with the text “Rescinded”.

Subj: Import API Report [#31292] 06/22/11@08:14 8 lines

From: PROVIDER, ONE In 'IN' basket. Page 1

-------------------------------------------------------------------------------

0) 1^1 Image(s) Copied OK. 0 Errors.

1) MAGRSND;3110622.081451.3

2) 31

3) RESCINDED IMAGE FILE^\\SERVER1\IMAGE1$\SLA0\00\00\02\05\SLA00000020542.TIF

The preceding array was generated by

the VistA Imaging Import API while

processing a 'RESCIND' Image action.

Enter message action (in IN basket): Ignore//

4.6.2.18 “Rescinded” Watermarking Failed

The following is an example of the email message generated when an image associated with a Rescinded Advance Directive cannot be watermarked with the text “Rescinded”.

Subj: Import API Report [#31341] 06/23/11@09:52 9 lines

From: PROVIDER, ONE In 'IN' basket. Page 1

-------------------------------------------------------------------------------

0) 0^Image is already Rescinded.

1) Image(1) 0^<error message for Rescind Failure>.

2) Image(1) RESCIND Action is Canceled.

3) Image(1) IEN: 20924

4) TIU Note: 697

The preceding array was generated by

the VistA Imaging Import API while

processing a 'RESCIND' Image action.

Enter message action (in IN basket): Ignore//

4.6.3 Screen-Generated Output

4.6.3.1 Server Size

This window shows the amount of total space, free space and % Server Reserve space for RAID and jukebox shares as well as RAID Groups.

Select View > Server Size from the menu bar to view this window.

Note: This option can be accessed at any time the Queue Processor is running.

This is an example of the Server Size window; it depicts in graphical bar chart the size of the networks share

The VistA Storage area on the Queue Processor GUI can be refreshed with the most current storage utilization statistics for RAID Groups and RAID shares by clicking the buttons Refresh Current Write Group or Refresh All (RAID Shares).

4.6.3.2 JBTOHD Report

When you select View > JBTOHD Report from the menu bar, the following graphic is displayed. This window displays a summary of all the entries in the JBTOHD queue and the file types that will be retrieved for all the entries. You can save this report to the disk with the File menu. The fields in this window are described below.

Select View > JBTOHD Report from the main menu bar to view this window.

This is an example of the JBTOHD report.

Name	Description
Current JBTOHD queue	Number of entries in the JBTOHD queue and the request date/time.
Image Queuer	User who requested the images and title
Number of Queues	Total number of files that will be copied
Number of ABSTRACT	Number of abstract files that will be copied
Number of BIG	Number of BIG files that will be copied
Number of FULL	Number of Full files that will be copied
Patient:	List of patients for the requested images and their patient ID

4.6.3.3 IMPORT Queue Status Report

The IMPORT Queue Status window displays queue, parameter, and log information for IMPORT queue entries (processed or unprocessed). When the entry has not been processed, the window will display the data in the queue entry in VistA and also the parameters that will be used in extracting the data from the remote location. More information will be displayed after the IMPORT queue entry has processed. The window will show the progressive steps of the queue entry processing. It will also show any errors that occur. The field descriptions are described below.

Select View > Import Queue from the main menu bar to view this window.

(Windows Session Tab displayed)

The IMPORT Queue status window displays the Import tracking ID and the 3 different tab views: Windows Session file, Acquisition Session file, and Import Queue file. The example has the Windows Session file tab active.

(Acquisition Session File tab displayed)

This image displays the results on the Application Session file (#2006.041) tab.

Name		Description
Import Tracking ID Lookup		Unique identifier for each IMPORT entry
Import Queue Lookup		IEN for IMPORT queue entry in the IMAGE BACKGROUND QUEUE file (#2006.03). This number is displayed in the Queue Processor GUI in the Process: Queue IEN column (e.g., IMPORT:1234 )
ACQUISITION SESSION file (#2006.041)		Logs all pertinent data when a queue entry is processed
	IEN	IEN for IMPORT queue entry in the IMAGE BACKGROUND QUEUE file (#2006.03).
	QUEUE field (#.01)	Sequence # of events for processing the queue entry
	TRACKING ID field (#.02)	Unique identifier for the IMPORT entry
	ACTIVITY field (#1)	Category of the session output
	TIME field (#2)	Time stamp for processing step
	QUEUE STATUS field (*#3)	Status logged for each processing step
IMAGING WINDOW SESSIONS file (#2006.82)		Displays error information when an attempt to queue an IMPORT failed.
IMPORT QUEUE file (#2006.034)		Displays parameter information that was initiated by the remote source.

Note: If there are conflicts caused by the volume of imports being processed, it may be necessary for the IMPORT queue to hold (pause) and try processing the IMPORT queue again. The IMPORT queue logs this event in the XTMP global and is held there for 30 days.

XTMP example

4.6.3.4 Purge Queue by Type Entries

Occasionally, some queues build to a large number of entries because the queues are not assigned to a BP Server or a setting was made unintentionally. For some queue types, the entries are no longer needed or were erroneously placed on a queue and can be entirely deleted.

One way to display these queue entries is to use the Queue Manager (Edit > Queue Manager). When the queue counts are high for any of the queues, the GUI may take an extended period of time to display the entries while the Queue Processor appears to hang. The Queue Management by Type window, which displays the same information on the queue counts, opens immediately no matter how many entries are in each queue.

In addition to deleting queue entries for a particular queue, you can re-queue all the entries in a particular queue. If specific entries need to be re-queued, use the Queue Manager window.

You can select Active or Failed queue entries, as follows:

Failed Queues = all of the queue types are selectable and their entries can be purged/re-queued.
Active Queues = only the Purge option is available and only for the JBTOHD, GCC, PREFET and EVAL queues. The Requeue option is not available.

Select View > Purge by Queue Type from the main menu bar to view this window.

Queue Mgt by Type window

4.6.3.5 508 Compliance

The purpose of this option is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities who are members of the public seeking information or services from a Federal agency have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.

Select View > 508 Mode from the menu bar to view this option.

Chapter 5 Verifier

=====================================================================

· Application Description

· Setting up

· Tasking

· Understanding Processing

· Starting/Running the application

· Reports

=====================================================================

5.1 Application Description

The Verifier validates the VistA Imaging network file references and consolidates jukebox image files. It is used to identify, and in some cases, correct inconsistencies within the VistA database, as well as identify incorrect image file locations in VistA. Specifically, the Verifier:

Performs multiple patient integrity checks
Sets or clears invalid file location pointers in the database
Checks for mismatches between image file contents and the database
Checks for mismatches between specific fields in the text files and the database
Re-creates missing file types, when possible

5.2 Setting Up the Verifier

The Verifier software needs to be installed on a Server class machine. The Verifier requires a BP Server defined for the server on which it will run (section 2.5.2 Adding a BP Server to the VistA Imaging System). In addition, the Broker port connection needs to be configured. See Appendix A for configuration information.

Check the network connections to the RAID shares and archive device shares to make sure they are online and the Windows account that will be used for logging into the workstation has READ/WRITE permission to those shares.

5.3 Tasking

If the Verifier is to be run on a daily/weekly/monthly schedule, the SCHEDULED VERIFIER task will need to be assigned to the BP Server.

5.4 Understanding Processing

The process is:

You select a range of IENs to be processed.
The Verifier steps through each IEN in VistA and validates the image pointer locations (Full, abstract and BIG types) for both the RAID shares and archive devices (jukebox).
The validation is done by physically checking the share for the existence of each file type. There are two different types of checks:

· When a RAID file is not found, the Verifier clears the appropriate pointer in VistA for that file type.

· If the RAID file is found at the pointer location, then no change is made to the database.

When a file is not found for an archive (jukebox), the Verifier searches all the online jukebox shares for the file.
If the file is found, the archive pointer in VistA is updated to that new location.
If the archive file is found at the pointer location, then no change is made to the database.
The Verifier creates missing files when it finds other files that can be used to create these missing files.
The following table shows the specific file extensions needed to create a particular file type. Those extensions not listed must be resent/recaptured from the source.

Missing file	Create from master
Abstract	· 756 · BIG · BM · BW · DCM · JPG · PAC · TGA · TIF
TGA	· BIG · DCM

Missing file

Create from master

Abstract

· 756

· BIG

· BM

· BW

· DCM

· JPG

· PAC

· TGA

· TIF

TGA

· BIG

· DCM

For sites that use multiple online archive devices (jukeboxes) the process is:

When a file in the set of images is missing and a master file (see table above) is available on the network, the verifier creates the derivative file(s) and will then copy the complete set on the current jukebox.
The pointers are updated in VistA to reflect this location change.
Patient data integrity checks are automatically performed on the IENs as the pointers are being examined and validated. There are 14 integrity checks. Any inconsistencies found are reported.

5.4.1 Reasons for Running the Verifier

The following scenarios have happened at the sites and are stated here as justification for running the Verifier on a regular basis.

1. Each day, images are saved on the VistA Imaging RAID shares and jukebox. There are occasions when an undetected problem occurs and a file in an image set is not copied to the RAID/archive device. The Verifier will report these missing files. If done in a timely manner, missing files can be recaptured/resent from the source before they are removed from those sources.

2. In cases where image storage application did not complete the file creation, the Verifier will clean up the database pointers. For example, when capture events time out prior to the file being copied to the RAID they are automatically deleted by the capture application; this results in an NO ARCHIEVE event. The image entry will be in the IMAGE ARCHIVE (#2005.1) file with no reason for deletion.

3. References are set in patient reports for the images in order to support archiving and viewing. Occasionally, images on a report belong to another patient. The Verifier will detect these inconsistencies and report them.

4. Files are removed from the RAID to free up storage space and files are recalled from the jukebox when they need to be viewed. Pointers are reset/set for each of these studies (100’s of images). The Verifier will detect and possibly repair any inconsistencies.

5. Resolve inconsistencies in the database that can result because of discrepancies between files that interact, manual corrections, network anomalies, power outages, hardware failures, and incomplete database updates.

5.5 Maintenance Operations

Verifier scans can be run any time of the day as there is minimal impact on VistA. They should be run based on the following events:

· Routine scanning of newly acquired images

The Verifier should be run every 1 or 2 weeks to verify new entries in the IMAGE file (#2005). In some cases, if images are missing they can be resent from the modality.

· Periodic maintenance of the VistA Imaging system

The Verifier should be run once a year to verify the entire range of Image Internal Entry Number (IENs) in the IMAGE file (#2005). During the year, many files will be retrieved from the jukebox and pointers updated in the database. Allowing the Scheduled Verifier to run on a regular basis will insure that files on the RAID and the Jukebox can be accurately located.

· Large Image Share population events

There may be occasions where files were not copied and incorrect file pointers set in the database with this large volume of files being moved to the RAID. Running the Verifier over the range of Image IENs that were copied back to the Image shares from the jukebox will insure correct pointers.

· Image share or Jukebox outages

The Verifier should be run after the resolution of any event that interrupted the flow of images to the Jukebox. The Queue Processor will attempt to copy files to the jukebox 3 times. At that point it will indicate failure and begin processing the next entry in the queue. Note that these files ONLY reside on the Image shares and therefore MUST be copied promptly to the jukebox using the Verifier.

5.5.1 Integrity Checks

The Verifier steps through each of the IENs within the range looking for specific types of problems. The following sections describe the integrity checks performed on these files.

5.5.1.1 File Integrity

File location references in the IMAGE file (#2005) are physically checked to determine the existence of the file(s) on their assigned Imaging share(s) and jukebox. If any file (excluding TXT) is missing from the Image shares, the pointer will be cleared in the IMAGE file (#2005) record. If all files are missing on any on-line jukeboxes, the jukebox pointer will be cleared. The Verifier will set the jukebox pointer if any of the files in the set are found on the current or alternate jukebox. The Verifier will also look at the IMAGE AUDIT file (#2005.1) to ensure the file set exists at the location(s) specified in this file.

5.5.1.2 Patient Integrity

Patient-related values in the IMAGE file (#2005) are checked for consistency within the group Image entries and the associated report files.

The following table lists the integrity issues that will prevent their respective images from being displayed. The following integrity error messages will be generated when the image is retrieved for viewing.

Message Generated	Explanation
No Image Ptr in AP	The Clinical Association Report (AP) for this image does not contain an image entry that points back to this image.
GP has no images	The image series does not contain any images. Group Parents (GP) are containers for an Image series. A group parent with NO group objects (GO) is an invalid condition.
Conflicting AP & Image DFNs	The patient file reference (DFN) in the Clinical Association Report (AP) does not match the DFN in the IMAGE file (#2005).
Invalid Image Ptr to AP	The Clinical Association Report (AP has image references that are not in the IMAGE file (#2005).
Conflicting GP and GO DFN	The patient file reference (DFN) in the Group Parent (GP) is not the same as the DFN in the Image entry.
GP & GO AP Mismatch	The Group Parent and Group Object pointer references to a Clinical Association Report (AP) do not match.
GP Missing GO Ptr	The Group Object multiple of the referenced Group Parent does not reference this group object.
No AP Mult Ptr	This Image entry does not have the clinical application (AP) image multiple entry number specified. The IMAGE file (#2005) record is missing the PARENT DATA FILE IMAGE POINTER for a Clinical Association Report (AP).
GO DFN mismatches	Some image file Group Objects have different PATIENT file (#2) references (DFN).
Image entry is structurally abnormal	The normal structure that distinguishes Image entry Group Parents (GP), Group Objects (GO), and Non-Group image (NG) is corrupt.
Missing Group Objects	The Group Parent has Group Object references that are missing.
DFN Mismatches in AP Image Mult	The Clinical Association Report (AP) references a Group Parent that has image files with a PATIENT file (#2) reference (DFN) that is different from the report.

Note: The following integrity issues will not prevent their respective images from being displayed. These are informational messages.

Message Generated	Explanation
No AP Ptr	The IMAGE file (#2005) record is missing the PARENT DATA FILE file (#2005.03) for a Clinical Association Report (AP). This Image does not have the entry in the clinical application (AP) specified.
No AP entry Ptr	This Image does not have the entry in the clinical application (AP) specified. The IMAGE file (#2005) record is missing the PARENT GLOBAL ROOT IEN for a Clinical Association Report (AP).

5.5.1.3 Text File Integrity

When the Check option is selected in the Check Image Text window, the Verifier compares specific fields in the text file with those in the associated IMAGE file (#2005) record in VistA. The following is a list of problems that the Verifier detects. Included in the list is a suggested way of correcting these problems.

· Text file is binary or unreadable.

Correction- Copy the version from the jukebox or get a copy from the backup tapes

· Text file is ASCII but has unprintable characters or truncated.

Correction- Copy the version from the jukebox or get a copy from the backup tapes

· Patients ID (SSN) field in the text file does not match that in VistA.

Correction- Contact the National Help Desk.

The following fields are in the DICOM DATA block (lower section of the text file). These fields are generated by the modality and should not be altered.

· SOP Instance UID field (DICOM- 0008,0018) in the text file does not match the one in VistA. (“PACS” node – PACS UID field (#60) in the IMAGE file (#2005) )

Correction- Most likely the text file has the correct UID. Make the correction in VistA (PACS UID field #60 in the IMAGE file (#2005) to match the DICOM field (0008,0018).

· Study Instance UID field (DICOM- 0020,000D) in the text file does not match the one in VistA. (“PACS” node – PACS UID field (#60) on the PARENT IEN.)

Correction- Most likely the text file has the correct UID. Make the correction in VistA (PACS UID field (#60) in the IMAGE file (#2005) ) to match the DICOM field (0020,000D).

· SOP (DICOM- 0008,0018) and/or Study Instance UID (DICOM- 0020,000D) are/is blank in the text file.

Correction- If these fields are blank and the image is stored in VistA in TGA format, then this crucial information is lost and it will be impossible to reconstitute the DICOM image. Call the National Help Desk.

· Patient ID (SSN) in the top section (DATA1) of the text file does not match the DICOM field (0010,0020) in the bottom section (DICOM DATA).

Correction- This file has already been corrected and needs no further correction if the Patients ID field (SSN) in the top section (DATA1) matches VistA.

5.6 Starting/Running the Verifier

The Verifier can be started as an independent application or can be scheduled to run in the background at prescribed time intervals (See Section 3.5). The following steps describe how to run the Verifier in the foreground:

1. From the Windows Start > Programs menu, select VistA Imaging Programs > Background Processor > Verifier.

2. Log into the application using a valid VistA access and verify code. (The secondary menu option MAG WINDOWS is required for access to the Verifier).

The BP Verifier window opens.

This is an example of the Verifier window.

3. In the Scope box, select one of the following options:

· Range - Type a start and stop IEN. The Verifier will process this range of IENS (inclusively). If the Start IEN is greater than Stop IEN, the Verifier will scan the image records backwards.

· All – Every IEN record in VistA will be processed

· Auto – The Verifier will process IENs from the highest backwards to an IEN that was previously processed.

4. In the Check Image Text box, select one of the following options:

Check - Compare specific fields in the text files on RAID with data contained in the associated IMAGE file (#2005) records in VistA. (Processing time will increase moderately.)
Don’t Check – Do not do any comparison of the text files with VistA.

Note: This is the preferred option as the procedure to correct inconsistencies is under development.

5. Click the Start button to begin processing.
You will see processing activity in the GUI window.

This image depicts the results of a Verifier execution.

Name	Description
Image Shares
IEN	Entry number in the NETWORK LOCATION file (#2005.2)
Network Location	Name of the entry in the NETWORK LOCATION file (#2005.2)
Physical Reference	Network path of this Network Location entry
Scan Controls
Scope	Setting: · Range = Scan records in specified range · All = Scan all records · Auto = Automatically scan newly acquired files after the last scanned record
Check Image Text	Setting: · Check = Compare specific fields in the text files on RAID with data contained in the associated IMAGE file (#2005) records in VistA. · Don’t check = Don’t compare fields above.
Progress	Number of records processed
Range	Setting: · Start = Beginning IEN in range to scan · Stop = Ending IEN in range to scan
Summary
Start Time	Date/Time this Verifier scan was started
Run Time	Total elapsed time the Verifier ran
Total IENs	Number of image file entries processed in this scan
No Refs	Number records with no RAID or archive device (jukebox) location references
Bad VC Refs	The number of IMAGE file (#2005) entries with Image share references that could not be matched to an actual file stored on an image share.
Bad JB Refs	The number of IMAGE file (#2005) entries with jukebox references that could not be matched to an actual file stored on a jukebox.
Alt JB Refs	The number of files found on multiple jukebox share locations is listed. (These are copied to the current jukebox share using the aggregate function).
Size Zeros	The number of zero length files found on the Image shares and archive (jukebox) shares.
Size Zero Deleted	Number of files deleted that had a size of zero. Only image share files will be deleted.
Duplicates	Number of Image entries that are duplicated in the IMAGE file (#2005) and the IMAGE AUDIT file (#2005.1). These images are not viewable because the image files themselves have the same file names and therefore have ambiguous patient and procedure references.
Jukebox Shares box
IEN	Entry number in the NETWORK LOCATION file (#2005.2)
Network Location Name	The name of the entry in the NETWORK LOCATION file (#2005.2)
Physical Reference	Network path of this Network Location entry
Operational Status	Status: · On-line = READ/WRITE access to this share · Off-line = no access to this share
Hash Subdirectory	Setting: · Yes = Directory hashing is used. Files are maintained in a 5-level deep subdirectory structure where no directory will contain more than 100 unique filenames with their various extensions. (Both 8.3 and 14.3 format files are valid) · No = Image files are stored in the top level folder in a flat file structure, which means that files are placed and retrieved from the root directory of the share. Do not use this structure.
Share Availability	Setting: · On-line = Software can access shares on the network. · Off-line = Software cannot access shares on the network.
Activities box
Time	Actual time when the IMAGE file (#2005) was processed
Activity	Description of the action taken
IEN	IMAGE record number currently being processed
File	Filename in the current IMAGE file (#2005) record being processed
JB Full	The DISK & VOLUME, WORM (#2.2) value for the archive (jukebox) share in the IMAGE file (#2005) and\or IMAGE AUDIT file (#2005.1) where Full image is located. Other extensions will be listed here except the BIG file (listed in the JB BIG column).
JB Big	The BIG JUKEBOX PATH (#103) value for the archive (jukebox) share in the IMAGE file (#2005) and\or IMAGE AUDIT file (#2005.1) where BIG image is located. The extensions of all files on the jukebox will be listed
VC Full	The DISK & VOLUME, MAGNETIC (#2) value for the share in the IMAGE file (#2005) and\or IMAGE AUDIT file (#2005.1) where FULL image is located
VC Abstract	The DISK & VOLUME, ABSTRACT (#2.1) value for the share in the IMAGE file (#2005) and\or IMAGE AUDIT file (#2005.1) share where abstract image is located
VC Big	The BIG MAGNETIC PATH (#102) value for the share in the IMAGE file (#2005) and\or IMAGE AUDIT file (#2005.1) where BIG image is located
CWL	Image share that is the current write location. This will change automatically if the AUTO WRITE LOCATION UPDATE option is selected. The check for space is done after 100 Writes to the share or after 20 minutes since the last check, whichever comes first.
JB Path 1	The IEN for the entry in NETWORK LOCATION (#2005.2) file of first alternate jukebox
JB Path 2	The IEN for the entry in NETWORK LOCATION (#2005.2) file of second alternate jukebox
(status bar at bottom)	Parameters for this run are listed.

Note: When the IEN range includes files that have been saved in a flat file structure, there will be a noticeable increase in the time it takes to complete the scan.

The Verifier stops when it has processed all the IENs in the range specified.

6. Click Stop to terminate processing at any time.

When the Verifier run is complete, you can enter a new set of Start/Stop IENs in the SCOPE and start a new run.

5.7 Reports

Two types of reports are produced:

Log files
Emails

5.7.1 Log Files

New log files are created as HTML files each day and each time the Verifier is run. HTML files are viewable, printable, and searchable. By default, they reside in the C:\Program Files\VistA\Imaging\BackProc\log\Verifier directory. You can access these files by:

· File > Open Log on the BP Verifier menu bar

· Internet browser

These log files can be imported into an Excel spreadsheet.

Important: These files should be kept for historical reasons and added to the tape backup storage process to safeguard the files. (See Appendix B: Backups in the VistA Imaging System Installation Guide.)

Log File Format

Verifier log files are archived as HTML files and have the year-month-day and sequence number imbedded in the file name, as shown in the right pane of the window.

$This image displays the directory of the verifier log files. Directory path: C:\Program Files\VistA\Imaging\BackProc|Log\Verifier$

BP Verifier produces the following types of log files.

5.7.1.1 Scan Log File

The Scan log file lists entries with potential file integrity problems. The log records the operational events that take place to correct a particular problem. They are used to determine if and how the Verifier corrected the faulty condition. The IENs that the Verifier could not fix are listed in the ScanError log file. For the complete list of messages, see Output HTML Messages.

Note: No action is required on entries found in the Scan.Log file.

This is an example of the Verifier scan log report.

Name	Description
Date/Time	Actual time when the IMAGE record was processed.
Message	Description of action taken.
IMAGE_PTR	Image record currently being processed including the version/dates/log file names.
FILE_NAME	Filename for the Image record.
FULL_JB_PTR	The DISK & VOLUME, WORM (#2.2) value for the archive (jukebox) share in the IMAGE file (#2005) and\or IMAGE AUDIT file (#2005.1) where FULL image is located. Other extensions will be listed here except the BIG file (listed in the JB BIG column).
BIG_JB_PTR	The BIG JUKEBOX PATH (#103) value for the archive (jukebox) share in the IMAGE file (#2005) and\or IMAGE AUDIT file (#2005.1) where BIG image is located. The extensions of all files on the jukebox will be listed.
FULL_VC_PTR	The DISK & VOLUME, MAGNETIC (#2) value for the share in the IMAGE file (#2005) and\or in IMAGE AUDIT file (#2005.1) where FULL image is located. (Other file extensions on this share are also listed.)
ABS_VC_PTR	The DISK & VOLUME, ABSTRACT (#2.1) value for the share in the IMAGE file (#2005) and\or IMAGE AUDIT file (#2005.1) where abstract image is located. (Other file extensions on this share are also listed.)
BIG_VC_PTR	The BIG MAGNETIC PATH (#102) value for the share in the IMAGE file (#2005) and\or IMAGE AUDIT file (#2005.1) where the BIG image is located.
Current_Write_PTR	Image share that is the current write location. This will change automatically if the AUTO WRITE LOCATION UPDATE option is selected. The check for space is done after 100 Writes to the share or after 20 minutes since the last check, whichever comes first.
JB_ALT_1 (2, 3, …)	Network Location of archive (jukebox). If a site has 2 or more jukeboxes, then the second, third, etc. are the “alternate” jukeboxes.

5.7.1.2 NoArchive Log File

The NoArchive log file contains image file names that are missing on the jukebox and could not be created from existing files and/or could not be found on the RAID. The Verifier examines both the IMAGE file (#2005) and the IMAGE AUDIT file (#2005.1) for missing files. The 2005.1 column shown below indicates those missing files that have been deleted and the IMAGE file (#2005) record has been moved to the IMAGE AUDIT file (#2005.1).

This is an example of the NoArchive scan report.

Name

Description

Filename

Name of the missing file.

2005.1

If the column contains “2005.1”, then the Image has been deleted and the image information is in the IMAGE AUDIT file (#2005.1).

If the column is blank, the file is missing from the RAID and archive storage and must be restored using one of the methods listed above.

Note: When the 2005.1 column is blank, the file is missing and must be recovered from the backup tapes or other means.

These files must be restored using one of the following methods:

· Restore from backup tape(s).

· Resend from the gateway.

· Re-capture on the Capture workstation.

· File restore from platter on the jukebox.

If the missing file cannot be located, the Patient ID information and provided information for these missing field(s) should be sent to the hospital staff persons for their records.

5.7.1.3 ScanError Log File

The ScanError log file lists problems with IENs that could not be corrected. When a Verifier scan is completed, the contents of this file are sent as a mail message to the MAG SERVER mail group.

Note: Action is required to correct any problems listed in this file.

Guidelines on Handling Errors:

The most important columns are FULL_JB_PTR and BIG_JB_PTR, shown below, which display the files that are on the jukebox (there is not always a BIG file with an image).

Important: The FULL, ABS, BIG, and TXT files should reside on the jukebox.

The Message column describes the errors. (See section 8.3.1 Start/Run for the complete list of messages in the Troubleshooting chapter.)
All file types in a set may not be on the image shares as some may have been purged.
If the Check Text option was used, see “Check Text Option Messages”. These are potential problems that need to be corrected.

This is an example of the ScanError log report.

Name	Description
Date/Time	Actual time when the IMAGE record was processed.
Message	Description of problem
IMAGE_PTR	IMAGE record currently being processed
FILE_NAME	Filename for the current IMAGE file (#2005) record being processed
FULL_JB_PTR	The DISK & VOLUME, WORM (#2.2) value for the archive (jukebox) share in the IMAGE file (#2005) and\or IMAGE AUDIT file (#2005.1) where FULL image is located. Other extensions will be listed here except the BIG file. (It is listed in the JB Big column.)
BIG_JB_PTR	The BIG JUKEBOX PATH (#103) value for the archive (jukebox) share in the IMAGE file (#2005) and\or IMAGE AUDIT file (#2005.1) where BIG image is located. The extensions of all files on the archive (jukebox) will be listed.
FULL_VC_PTR	The DISK & VOLUME, MAGNETIC (#2) value for the share in the IMAGE file (#2005) and\or in IMAGE AUDIT file (#2005.1) where FULL image is located. (Other file extensions that are on this share are listed, also.)
ABS_VC_PTR	The DISK & VOLUME, ABSTRACT (#2.1) value for the share in the IMAGE file (#2005) and\or IMAGE AUDIT file (#2005.1) where abstract image is located. (Other file extensions on this share are also listed.)
BIG_VC_PTR	The BIG MAGNETIC PATH (#102) value for the share in the IMAGE file (#2005) and\or IMAGE AUDIT file (#2005.1) where the BIG image is located.
Current_Write_PTR	Image share that is the current write location. This will change automatically if the AUTO WRITE LOCATION UPDATE option is selected. The check for space is done after 100 Writes to the share or after 20 minutes since the last check, whichever comes first.
JB_ALT_1 (2, 3, …)	The IEN for the archive (jukebox) share in the NETWORK LOCATION (#2005.2) file. If a site has 2 or more archive devices (jukeboxes), then the second, third, etc. are the “alternate” archive devices (jukeboxes).

5.7.1.4 DFNError Log File

The DFNError log file displays integrity issues with patient data. The Memo column messages, shown below, are described in checks on Patient Integrity.

Note: Call the National Help Desk for assistance in fixing any of these issues.

This is an example of the DFNError log report.

Name	Description
Image_IEN	IMAGE record currently being processed
Patient_Name_1	Patient name for current IEN
DFN_1	Patient file IEN for current record
SSN_1	Social Security Number for current patient
Patient_Name_2	Patient name in linked Radiology report/TIU Note
DFN_2	IMAGE file (#2005) IEN in linked report
SSN_2	Social Security Number of Patient in linked report
Package	PROCEDURE, field (#6) in IMAGE file (#2005)
Package_IEN	PARENT GLOBAL ROOT, field (#17) in IMAGE file (#2005), (the number in the left column) 3.9: MAIL MESSAGE 63: AUTOPSY (MICROSCOPIC) 63.02: ELECTRON MICROSCOPY 63.08: SURGICAL PATHOLOGY 63.09: CYTOLOGY 63.2: AUTOPSY (GROSS) 74: RADIOLOGY 130: SURGERY 691: ECHOCARDIOGRAM 691.1: CARDIAC CATHETERIZATION 691.5: ELECTROCARDIOGRAPHY 694: HEMATOLOGY 699: ENDOSCOPY 699.5: GENERIC MEDICINE 8925: TIU
Image_Class	Hierarchy in a study (parent, child)
Error_Level	Severity level: 1= highest 2 = high
Memo	Integrity issues to resolve

5.7.2 Emails

The following messages are generated or triggered by the Verifier.

5.7.2.1 Imaging_Integrity_Check message

This message is sent when the Verifier completes a scan. The message identifies the time span involved and a summary of integrity errors.

Example:

Subj: Imaging Integrity Check [#31164] 10/26/09@22:32 6 lines

From: VistA Imaging DFN_Summary In 'IN' basket. Page 1 *New*

-------------------------------------------------------------------------------

SITE: IMGxxxx.DOMAIN.EXT

DATE: Oct 26, 2009@22:32:51 EST

51 entries scanned.

Summary:

2 occurrences of : NO IMAGE PTR IN AP~1 type errors.

Database scan took 0:0:5

5.7.2.2 Imaging_Site_Verification_Issue

This message is sent when there is a network issue that is preventing the Verifier from accessing shares.

Example:

Subj: Imaging Site Verification Issue [#853534]

14 Dec 2009 08:50:04 -0600 (CST) 8 lines

From: <USER.BGP@CENTRAL-ALABAMA.DOMAIN.EXT> In 'VERIFIER' basket. Page 1

*New*

-------------------------------------------------------------------------------

SITE: CENTRAL-ALABAMA.DOMAIN.EXT

DATE: DEC 14, 2009@08:50:04 CST

12/14/2009 8:50:04 AM

The Jukebox share: \\VHACAVIMMJB1\IMAGEJB1$ is not available!

All VistA Imaging Jukebox servers should be fully operational

when operating the BP Verifier!

31271^CB031271.TGA^7.ABS.TXT.BIG.TGA^7^^^^27^^^

when operating the BP Verifier!

5.7.2.3 Verifier_Scan_Error_Log message

This message is sent by the BP Verifier at completion of the scan. The report identifies the image entries in question.

Example:

Subj: Verifier Scan Error log [#31165] 10/26/09@22:32 165 lines

From: VistA Imaging Scan_Errors In 'IN' basket. Page 1 *New*

---------------------------------------------------------------------

SITE: IMGxxx.DOMAIN.EXT

DATE: Oct 26, 2009@22:32:51 EST

10/26/2009 10:32:43 PM^No Full VC Files^21158^QRT00000019369.ASC^^^2^^^74^^^

10/26/2009 10:32:43 PM^No Jukebox Full Files^21158^QRT00000019369.ASC^^^^^^74^^

10/26/2009 10:32:43 PM^Not Certed^21158^QRT00000019369.ASC^^^^^^74^^^

10/26/2009 10:32:43 PM^No Full VC Files^21157^QRT00000019368.BMP^^^2^2^^74^^^

10/26/2009 10:32:43 PM^No ABS file VC Ptr Cleared^21157^QRT00000019368.BMP^^^^^

^74^^^

Chapter 6 Purge

=====================================================================

· Application Description

· Setting up

· Tasking

· Understanding Processing

· Starting/Running the application

· Reports

=====================================================================

6.1 Application Description

Image files are part of the patient’s record and must be preserved for the required number of years. Image files may be kept online indefinitely in long-term storage. However, image files in temporary storage must be purged periodically to provide ongoing free disk space for new images. The primary purpose of the Purge is to delete files in temporary storage in order to maintain a percentage of free disk space at all times. The Purge can be run manually, scheduled or run automatically. An express purge is available to dramatically decrease the time it takes to purge a share.

6.2 Setting Up

The Purge software will need to be installed on a Server class machine. The Purge requires a BP Server defined for the server on which it will run (Section 3). In addition, the Broker port connection needs to be set up (Appendix A)

6.3 Tasking

If the Purge is to be run automatically when a share/RAID Group exceeds the % Server Reserve threshold, the AUTO PURGE task will need to be assigned to the BP Server.

6.4 Understanding Processing

Guidelines:

You should first determine how much free space is needed on the RAID shares for non-interrupted processing of new images.
Once that has been determined, the Purge Parameters need to be set.
You can specify which file date the Purge parameters will use. The Windows date options are:

· Modified

· Created

· Accessed

You should select the Express Purge option as this will minimize the time it takes to delete files from the RAID shares.
You can also select which shares (or all) are to be purged.

Purge Process:

When the purge starts, the application begins at the top of the directory tree on a selected RAID share and traverses to the bottom of the tree before starting on another share.
When the purge finds a file that is a candidate for deletion based on the file date option selected, it first checks to make sure the file is on the archive device (jukebox) and has the same file properties (size, etc):

· If the file exists on the archive, then the file is deleted from the RAID share and its location pointer in VistA is cleared.

· If the file does not exist on the archive device, the JUKEBOX entry is queued where the file will be copied to the jukebox. The file is not deleted and no pointer in VistA is cleared.

3. The purge application then moves onto the next file. This process continues until all the selected RAID shares have been processed at which point, the purge displays a summary page indicating its processing is complete for this session.

6.4.1 Setting Purge Parameters

Typically the Abstract file parameter is set an equivalent of 5 years (in days). These files are small in size and are viewed as thumbnails on the Clinical Display workstations.

Locating images for a patient is much less time consuming when these images are available on RAID versus having to wait for retrievals from the archive (jukebox).

The keep days for the Full and BIG files should be kept reasonably large to start.

Start a test run on one share and determine how much free space is available after the run.
If the free space is adequate, use the current parameters to purge the remaining shares.
If more free space is needed, change the FULL and BIG retention/keep days to a lower number and start another test run on one share.
When the right settings have been found, start the purge on the other shares.

These values can be kept in place until the rate of images per day increases substantially. At that time, the FULL and BIG parameters will have to be decreased to remove more images from the shares.

Some sites have enough RAID storage to keep 5 years of images. These sites need only purge once per year to remove the sixth year's images off the RAID. The Purge Parameters can be set to 5 years (in days) for the Abstract, Full, and BIG files.

Recommendation: VistA Imaging Cache or RAID share devices operate more efficiently when 10 percent of disk capacity is available.

Some degradation occurs as the storage devices fill and files become fragmented. The system is designed to notify the VistA Imaging system manager and the ADPAC when VistA Imaging shares resources have reached a critical level (default is 5% free space remaining). This value is too low for normal workflow. At this point, the Automatic Write Location update option no longer operates.

6.4.2 File Types for Purge

By default, the file extensions (except TXT) in Appendix B are automatically purged from the RAID shares. In order to have the TXT files purged, an entry must be made for “TXT” in the File Types field on the Imaging Site Parameters window on the Queue Processor application (this is set up by the installation).

6.4.3 Purge by Dates

The Purge uses the following Windows file dates. Every file in Windows has these dates set.

Date Created
Date Accessed
Date Modified

Recommendation: Use the Date Modified for most cases.

6.4.4 Purge Options

Express Purge – This option can be used for any of the three types of Purges described below. The algorithm is based on the principle that most files that are deleted during a purge are older files. The newer files remain on the share as they are within the keep dates for the Purge Parameters. The time it takes to traverse through these newer files can be lengthy with no files being deleted in the process. Some sites have a large number of shares and this “dead’ time for purging can be extreme. The Express option causes the Purge to stop the file traversal on a share when the number of consecutive files that have not been deleted is greater than the Purge Rate (measured in file count).

The three ways to initiate a purge are:

· Auto

The application monitors the amount of free space on the current RAID Group and determines if there are multiple RAID Groups. If only one RAID Group exists, when all the shares have reached the high water mark indicated by the % Server Reserve, a purge is initiated on all the shares. If multiple RAID Groups are present and all the shares in the next RAID Group are above the high water mark, the purge on that next RAID Group will start when the free space on the current RAID Group falls below the %Server Reserve times the Purge Factor. The Purge Factor is a whole number and is set to a value that allows enough time for the Purge to complete on the next RAID Group before the application moves the current write location to that group. It is recommended that the Express Purge option be set on the Auto Purge. These parameters are specified on the Imaging Site Parameters window.

Note: A BP Server must be assigned the PURGE task to run the Auto Purge.

· Scheduled

The Purge will run at set intervals over all the RAID shares starting at a specified date/time as specified on the Imaging Site Parameters window.

Note: A BP Server must be assigned the PURGE task to run the Scheduled Purge.

· Manual

User-initiated Purge. You can select one or more RAID shares. The Purge Parameters and Express Purge options apply.

Note: A BP Server does not have to be assigned the PURGE task to run a manual Purge.

6.4.5 Purge Criteria

The following table lists the result codes for the Purge. Each file that is traversed is listed in either the Purge.html or PurgeError.html log file with its corresponding result code (See the Reports section)

Purge.html/PurgeError.html (TGA, ABS, BIG extensions only)
Position	Field		Comments
1	Action		-3 = Foreign file. Not a valid file extension, do not purge -2 = Queued for jukebox copy, do not purge -1 = Do not purge 1 = Purge given normal date criteria + confirmed on jukebox 3 = Purge if file is at alternate network location site else purge & update RAID pointer 5 = Purge if at alternate site, queue jukebox if not on jukebox
2	File Type		0 = no file 1 = ABS 2 = FULL 3 = BIG 4 = Photo ID
3	Status		1 = No 2005 entry. No Purge. 6 = Jukebox pointer set. File on jukebox. RAID pointer incorrect location. Purge if image at other location 7 = Jukebox pointer set. File on jukebox. No RAID pointer set. Found file on RAID. Set RAID pointer. No purge. 8 = Jukebox pointer set. File on jukebox. RAID pointer set. File on RAID. Purge file. 9 = Record not in the IMAGE file (#2005). No Purge. 10 = File extension is not a valid Imaging file extension. No Purge. 14 = Duplicate 2005/2005.1 entry. No Purge 15 = Foreign PLACE. No Purge 16 = Record only in Audit (2005.1) file. No Purge 17 = Jukebox offline. No Purge.
(TXT extension – only)
Position		Field		Comments
1		"AltLastFile"		Last file on the share. No Full, ABS or BIG file present on share. Purge file.

6.5 Starting/Running the Purge

The Purge can be started as an independent application, can be configured to run automatically in the background (see section 3.5.1 Purge Settings), or can be scheduled to run in the background at prescribed time intervals (see section 3.5.1 Purge Settings). The following steps describe how to run the Purge in the foreground:

Note: The Purge Retention Days and Purge By file dates are used by all the options listed below. Set these parameters before any of the Purge options are run / scheduled.

1. From the Windows Start > Programs menu, select VistA Imaging Programs > Background Processor > Purge.

2. Log into the application using a valid VistA access and verify code. (The secondary menu option MAG WINDOWS is required for access to the Verifier).

The Purge application window opens.

This is an example of the Purge window.

3. Select Edit > Select Shares.

The Purge Share Select window displays the shares.

Purge Share Sheet window

4. Highlight the shares to be purged and click OK.

5. Click the Start button.

6. Click OK in the message to confirm the shares to be purged.

This is an example of the confirmation message to start the purge activity.

The window closes and the Purge starts. When the Purge is complete, a summary sheet is displayed.

This is an example of the purge summary results.

Note: You can view the results in a log by selecting File > Open log from the menu bar.

The purge results are displayed by file type in the lower section of the window, along with a purge results summary. The resulting data is described in the table that follows.

Purge results and summary in Purge window

Name	Description
Purged Files – Date Last Accessed	List of files on the current RAID share (highlighted in the Share Processing window) that are deleted because they met the Purge criteria.
Activities
Start Date	Start date of purge
Start Time	Start time of purge
Run Time (hrs: mins: secs:)	Time to complete the purge
Total Files	Number of files checked
Purge Count	Number of files purged
JB Queues	Number of files that were purge candidates, but not found on the archive (jukebox). A JUKEBOX queue entry was created to copy the file to the archive. The file is not deleted.
Purge Criteria: DATE ACCESSED	Date criterion used to determine which files to delete.
IEN Count	Number of unpurged IENs traversed since the last IEN purged on the current share. When the Purge operation is traversing through an IEN range that is rich with purge candidates, this number will be rapidly reset to zero. A continually growing IEN Count indicates that the Purge utility is in a range low in purge candidates. During a manual purge, the user may opt to stop the purge at that point. The IEN Count is used in conjunction with the Express Purge Rate when Express Purge is active.
Purge Parameters
Site File Prefix: DM, IE, QRT	Namespace and multi-namespace names for the site.
Abstract keep days	Purge parameter indicating the time frame for keeping abstract files on the RAID.
Full keep days	Purge parameter indicating the time frame for keeping Full files on the RAID.
Big keep days	Purge parameter indicating the time frame for keeping BIG files on the RAID.
Photo ID keep days	Purge parameter indicating the time frame for keeping Photo ID files on the RAID.
Purge Criteria	Date criterion used to determine which files to purge. Options are Date Modified, Date Created or Date Accessed.
Express Purge	Indicates if the Express Purge feature was used in this purge.
Express Purge Rate	The Express Purge will stop on a share when the IEN Count value reaches this threshold value.
Share Processing
RAID share paths	Location of shares being processed
Original File Counts
Abstract, Full Image, Big, Text, Photo ID, Foreign	Breakdown by file type of original files processed Note: Legend on the right displays the count by file type.
Purged Files
Abstract, Full Image, Big, Text, Photo ID, Foreign	Breakdown by file type of files purged Note: Legend on the right displays the count by file type.

6.6 Reports

Three types of reports are produced to notify you of important occurrences:

Log files
Emails
Screen-generated output

6.6.1 Log Files

New log files are created as HTML files at the beginning of every session. HTML files are viewable, printable, and searchable. By default setting, the BP Purge log files reside in the C:\Program Files\VistA\Imaging\BackProc\log\purge directory. You can access these files by:

· Selecting File > Open Log on the BP Verifier menu bar

· Using an internet browser

They can be imported into an Excel spreadsheet.

Log File Format

Purge log files have the year-month-day and sequence number imbedded in the file name, as shown in the right pane of the window.

$This image displays the directory path for the Purge reports. C:\Program Files\VistA\Imaging\BackProc\log\purge$

If more than one log file is run on the same day, the system adds a sequence number such as “01” following the date in the file name, as shown for the “PurgeError2009_08_18_01.html” file. For multiple runs on the same day, the highest sequence number is the latest log file run for the day.

The Purge run produces two types of log files shown, Purge{date}.html and PurgeError{date}.html.

6.6.1.1 Purge Log File

The Purge.html log file records the current share being purged as well as all of the successful deletions and the reason they were deleted. The following example shows a copy of the purge results.

This is an example of the Purge results recorded.

Name	Description
Date/Time	Date and Time of purge
Event_Type	Displays the final purge criteria for the file listed. (See Purge Criteria section.)
Message	Image file and access, creation, or modified date depending on the criteria

6.6.1.2 PurgeError Log File

The PurgeError.html log file records the current share being purged as well as all of the files that were not deleted and the reason they were not deleted. The following example shows a copy of the purge results.

This is an example of the Purge errors recorded.

Name	Description
Date/Time	Date and Time of purge
Event_Type	Displays the final purge criteria for the file listed. (See Purge Criteria section.)
Message	Image file and access, creation, or modified date depending on the criteria

6.6.2 Emails

The following e-mail messages are generated or triggered by the Purge.

6.6.2.1 Scheduled_Purge_Failure message

This message is sent by the Monitor Background Processor Activity [MAGQ BPMONITOR] menu option to indicate that the Scheduled Purge did not run. The BP Server may not have been assigned the PURGE task, therefore there is a risk that the shares will run out of free space. Run a manual purge, if necessary, until the problem is resolved.

Example of the message when the Purge is scheduled but fails to start:

Subj: Scheduled_Purge_failure [#31195] 10/27/09@12:40 4 lines

From: VistA Imaging MAGQCBP In 'IN' basket. Page 1 *New*

------------------------------------------------------------------

SITE: IMGxxxxx.DOMAIN.EXT

DATE: Oct 27, 2009@12:40:01 EST

The SALT LAKE CITY implementation of VistA Imaging has failed to start the sche

dule Purge activity!

The task is currently assigned to BP Server: ISW-xxxxx-LT

Example of the message when the PURGE task is not assigned to a BP Server:

Subj: Scheduled_Purge_failure [#31199] 10/27/09@12:55 4 lines

From: VistA Imaging MAGQCBP In 'IN' basket. Page 1 *New*

--------------------------------------------------------------

SITE: IMGxxx.DOMAIN.EXT

DATE: Oct 27, 2009@12:55 EST

The SALT LAKE CITY implementation of VistA Imaging has failed to start the schedule Purge activity!

The task is currently assigned to BP Server: Auto Purge is not currently assigned

6.6.3 Screen-Generated Output

When the Purge completes or you click the Stop button, the results are displayed in a summary window. You can print to file to save this data.

6.6.3.1 Purge Results

This is an example of the purge summary results.

Name	Description
[Purge Run Summary]
Start Date	Start date of purge
Start Time	Start time of purge
Run Time	Time to complete the purge (hrs: mins: secs:)
Total Files	Number of files checked
JB Queues	Number of files that were purge candidates, but not found on the archive (jukebox). A JUKEBOX queue entry was created to copy the file to the archive. The file is not deleted.
[Purge Site Parameters]
Site File Prefix: DM, IE, QRT	Namespace and multi-namespace names for the site.
Abstract keep days	Purge parameter indicating the time frame for keeping abstract files on the RAID.
Full keep days	Purge parameter indicating the time frame for keeping Full files on the RAID.
Big keep days	Purge parameter indicating the time frame for keeping BIG files on the RAID.
Purge Criteria: DATE ACCESSED	Date criterion used to determine which files to delete.
Express Purge	Indicates if the Express Purge feature was used in this purge.
Express Purge Term	This value is file count. The purge will stop on a share when it processes this number of files and none have met the purge criteria to be deleted.
[RAID Share Count]
Total Share Files	Total number of files traversed on the shares
Total Abstracts	Total number of .ABS files found
Total Full	Total number of Full files found
Total Big	Total number of .BIG files found
Total Text	Total number of .TXT files found
[Purge File Count]
Total Share Files Deleted	Total number of files deleted on all the shares processed
Purged Abstracts	Total number of .ABS files deleted on all the shares
Purged Full	Total number of Full files deleted on all the shares
Purged Big	Total number of .BIG files deleted on all the shares

Chapter 8 Troubleshooting

=====================================================================

General Startup
Queue Processor
Verifier
Purge

=====================================================================

8.1 General Startup

8.1.1 Network Connection

Check all the online VistA Imaging shares and jukebox shares by one of the following means to determine if the BP has access to the folders/files on the shares. There are several methods to test the connectivity:

1. From the Main BP window, select the View > Server Size option.
The free space should display for each share.

This image is an example of the View sub menus which includes the Server Size option.

2. Using Windows Explorer on the destination device (Image cluster or Windows-based Jukebox server), show the properties of the VistA Imaging shares and jukebox shares.
The VHAxxxIA account that is used to log into the BP Server should have READ/WRITE access to both the shares and folders/files on those shares.

Note: For sites using the Archive Appliance (AA), contact the HP Expert Center.

3. Open a DOS window. At the command prompt type dir \\server\share (the server could be a cluster server or the jukebox server). Traverse down a couple folders under the main level the folders/files should be visible

4. If any of these methods fail, open a DOS window and use the DOS ping command to see if the server is accessible on the network.

5. If the server is accessible, try mapping the share thru Windows Explorer. Explorer will display any error messages. If the server is not accessible, contact the network admin to troubleshoot.

8.1.2 Broker Failures

When the connection to the Broker fails:

· Verify the PORT and Server are correct in the registry

· Close and restart the application.

· Open a DOS window and use the ping command to see if the VistA server is available

· Verify that the listener is running in VistA

· Validate that the Access/Verify codes have not expired.

· Check the security on the Access/Verify account. Make sure:

- The MAG SYSTEM security key is assigned

- The MAG WINDOWS menu option is assigned

8.1.3 Not Enough Server Cache

This message indicates that:

· The share on the server is not accessible. Follow the steps in section 8.1.1 Network Connection to troubleshoot.

· The free space on the Image shares is below the % Server Reserve.

- Disable the Auto Write Location Update option.

- Set the write location manually to a share with cache space available.

- If no share has adequate free space, create a second BP Server and manually launch a Purge (in Chapter 6 Purge) to run on all shares. When the Purge has run and generated free space on a share, set the Write location manually to that share.

8.1.4 Not Enough Process Memory

Close all the applications and reboot the server. If the problem persists, contact the National Helpdesk.

8.1.5 Not Enough Write Cache Available

This message refers to the DiskXtender cache on the jukebox and indicates there is no free space on the jukebox share, or for Archive Appliance sites a possible space issue exists.

· Verify the share is accessible. Follow the steps in section 8.1.1 Network Connection to troubleshoot.

· Click the Extended Drive in DiskXtender to see if there is free space available. Also, use Windows Explorer on the JB server to see if Windows is properly reporting free space.

· Check the Move Group within the DiskXtender application to see if there are platters with available space. If not, add additional optical platters to the Move Group. See the DiskXtender User Manual.

· Run a Drive Scan on the share. See the DiskXtender User Manual.

8.2 Queue Processor

8.2.1 Startup

Message	Explanation	Action
Create Process failed'+ProgramName	A system error occurred staring the process	Log a Remedy ticket
Increment queue_name Ptr^Failed	The QUEUE POINTER (#1) in the IMAGE BACKGROUND QUEUE POINTER file (#2006.031) in VistA could not be updated	On the main BP window, use the Edit > Refresh Queue Counts to correct the current counts. Close the BP and restart the application.
Initialization Failure^Log Files at: C:\Program Files\Vista\Imaging\BackprocLog\BackProc\BPError.log	Log file could not be created	Check permissions on the log folder
RAID groups not properly configured Use the Network Location Manager to reset your RAID groups	An active RAID Group has no online shares	Make sure online RAID Group has online shares
Requeue Failure trying to Requeue:	An attempt to re-queue a failed queue entry failed	Use the Queue Manager and step past the queue entry. Determine the problem with the entry that would not re-queue.
SetTime Handle – Destin: C:\Program Files\Vista\Imaging\BackprocLog\BackProc\BPError.log Access is Denied	Could not write the Access Date on the log file	Check the file permissions on the log folder listed.
The Background Processor client software is version n.n.n.n. VistA Imaging Host system has version m installed. Please update to compatible client and host software. Shutting down the Background Processor...	The client software that is installed does not match the KIDS version installed on VistA.	Install the correction version of the KIDS and client software.
The Patch 39 KIDS install on the VistA host system is required for this Version of the: site name BP Queue Processor	The KIDS file for this most recent patch has not been installed in VistA.	Install the KIDS file on VistA.
The Site parameter context could not be determined. The application will terminate.	The PLACE global is corrupt	Log a Remedy ticket
This server is not yet configured for BP queue task processing!	There is no BP Server name assigned to this server	Create a BP Server through the GUI and assign tasks to it.

8.2.2 Runtime

Message	Explanation	Action
0^Accusoft Control creation error : < error message >	The Import API uses the AccuSoft Image Gear Toolkit to create the watermarked image. If an error occurs during the creation of AccuSoft controls, the error message displays describing the error.	The AccuSoft controls are installed during MAG3.0121 installation. If this error message occurs, contact the VistA Imaging system manager. You may need to reinstall MAG3.0121 to correct AccuSoft ImageGear problems.
0^Image is missing from input data.	The image to be watermarked is not in the Import Queue Data.	Check the IMAGE file (#2005) to see if the data is corrupt.
0^Watermark failure : <error message>	The process of burning the “Rescinded” watermark onto the image file failed.	The AccuSoft ToolKit could not create the watermarked image. Check if the rescinded bitmap exists in the image directory C:\Program Files\vista\Imaging\Bmp\MagRescinded.bmp. You may need to reinstall MAG3.0121 to correct AccuSoft ImageGear problems.
An Abstract for this file is on the Jukebox, a JBTOHD is being queued	ABSTRACT - The abstract pointer on the RAID is empty. The abstract will be copied from the jukebox	None
Could not complete	DELETE - file could not be deleted	Check permissions on RAID share
Could not complete/Requeued	DELETE - file could not be deleted	Check permissions on RAID share
Current RAID Shares^Exception: No RAID group Assigned	The RAID share must be assigned to a RAID Group	On the BP main window, use Edit > Network Location Manager to assign the RAID share(s) to a RAID Group.
False Positive Copy filename(Source), filenames ource filesize, filesize(jukebox)	File sizes on source and destination don’t match. File not copied.	Determine if images are for different patients
File copied was of size zero	IMPORT - The file size is zero	Resend image from import source
File of size zero created then deleted	MAKEABS - file of zero length was created by Mag_MakeAbs.exe. It was deleted.	Log a Remedy ticket
File was not found	IMPORT - file does not exist on the image share	Resend image from import source
filename Source file does not exist.	Could not find source file	Run Verifier to correct VistA pointers
fileshare: Cannot connect to the Export Share.	EXPORT - Cannot map to the remote share	Check for network connectivity. Check permissions..
ForceDirectories failed:	DELETE - could not create directory on jukebox share	Check permissions on jukebox share
Image File type: filename.ext is an Unsupported Format	ABSTRACT - The Full file is not a supported Imaging file type. So the abstract cannot be created.	Examine the "foreign" file and determine if the extension was misnamed.
Jukebox is not available: filepath Volume label	JUKEBOX - the jukebox share is not available	Ping the jukebox server. Check the jukebox share permissions.
Jukebox sourcefile unavailable	JBTOHD - There is no abstract file on the jukebox. The abstract pointer in VistA is not set.	None
JUKEBOX: queue _pointer ^file_extension Not copied	JUKEBOX - Alternate file extension (i.e. .TXT) was not copied	Check file permissions
Login Message^Pausing 3 minutes and will then retry	AUTOLOGIN - could not relog into the Broker	Check for network connectivity.
Login Message^Silent Login attempt failed!	AUTOLOGIN - could not relog into the Broker	Check for network connectivity.
Make AbstractError / abs is already present	ABSTRACT- file already exists at the RAID location specified in VistA	None
Make AbstractError / filename	MAKEABS- the Mag_MakeAbs.exe could not create the abstract file	Log a Remedy ticket
NetConError Using User credentials WIN32_Error	GCC - Could not logon to the remote location with the Username/Password in VistA	Correct the Username/Password for the GCC location in VistA
NetConError,'There is no password associated with this Network Location: share_name	GCC - The password field is empty for this Network Location	Enter a password for this GCC location
No Image file entry was created!	IMPORT - an IEN was not created in the image file	Resend image from import source
No Jukebox sourcefile available / Attempting Abstract Queue	JBTOHD - There is no abstract file on the jukebox. The abstract pointer in VistA is set. The Queue Processor will attempt to make on from the Full or BIG file.	None
No Tracking ID IMPORT failed	IMPORT - unique Tracking ID parameter is missing from IMPORT	Resend image from import source
No valid RAID share found	IMPORT - no RAID pointer is set in VistA for the image	Resend image from import source
Problem renaming log file: filename	Could not rename log file to a versioned copy	Check permissions on the existing folder/files
queue_pointer '^Size Mismatch queue_type copy not overwritten.	File sizes on source and destination don’t match. File not copied.	Determine if images are for different patients
SetFileTime Failed	Could not set Access date on the log file.	None
The jukebox copy: filename does not exist -- attempting a copy...	DELETE -Could not find the file on jukebox shares. Try to copy from RAID shares to jukebox	None
The RAID share is not on-line	IMPORT - The Image share is not available	Check the permissions on the image share indicated
The src_filename to dest_filename copy failed.	EXPORT - file could not be copied	Check for network connectivity. Check permissions.
The VistA cache file: filename not found	DELETE -Could not find the file on RAID shares to delete	None
This Server is not yet configured!	A BP Server has not been associated with this server.	Create a BP Server for this processor
Unable to copy to the Jukebox: Not enough write cache available	JUKEBOX - The jukebox share is not available or is full	Add new platters to the jukebox. Determine why the jukebox share is full. Possibly add new platters to the jukebox.
Zero size queue_type copy NOT overwritten	Zero size file on the destination could not be overwritten	Remove zero size file
No Connection to VISTA	The VistA Access and Verify codes of the user or service account are invalid.	Update the Access and Verify codes on the BP Site parameter window.

8.3 Verifier

8.3.1 Start/Run

Message	Explanation	Action
About to exit without processing: 0	There are no IEN records within the range.	Choose another IEN range
Broker Connection to server could not be established!	VistA RPC Broker is not currently in a listening state OR the application has timed out.	Close the application and restart. Check with the VistA system manager for the status of the Broker listener.
CC:createcontext ("MAG WINDOWS") could not be established!	The user does not have the MAG WINDOWS menu option assigned.	Assign the user this menu option.
lbCacheShare.items.Count < 1: MAGQ SHARES	There are no online, non-router VMC shares.	Use the Queue Processor’s Network Location Manager to check/add the shares.
Invalid Input Range	The From and To values entered in the Range are not correct (e.g. Start: 0 End: 0).	Enter a valid From and To range.
jukebox shares are not setup	The jukebox share(s) are offline or don’t exist in the NETWORK LOCATION file (#2005.2).	Create/Edit the jukebox shares in the Network Location Manager on the Queue Processor.
This workstation is not currently setup as a Background Processor.	There is no BP Server set up for this machine.	Use the option BP Servers on the Queue Processor to register this server.
Verifier client software is version nnn. VistA Imaging Host software is version mmm. Please update to compatible client and host software. Shutting down Verifier...	The version of the KIDS file installed on VistA does not match the executable version on the workstation.	Install the latest KIDS and client software.
VistA shares are not setup	The image share(s) are offline or don’t exist in the NETWORK LOCATION file (#2005.2).	Create/Edit the shares in the Network Location Manager on the Queue Processor.

8.3.2 Output HTML Messages

Message	Explanation	Action
Aggregate JB Copy Error:	Could not copy from alternate jukebox to current jukebox	Check permissions
Abs to JB:	Abstract has been created and copied to the jukebox	None
Aggregate Function - Enabled	Software is enabled to copy files from secondary jukebox, if necessary	None
BIG Aggregate Failed	Could not copy BIG file from secondary jukebox	Check file existence/permissions
Create Process failed	Could not create process on VistA for Verifier	Check Error Trap
Empty FBIG node	"FBIG" node has no pointers set in 2005 record.	Check shares for existence of BIG file. If not found, restore BIG file from backup tapes.
File of size zero created then deleted	Abstract file created of size zero. Then it is deleted. (Likely corruption of BIG and/or TGA file)	None
FULL Aggregate Failed	Could not copy FULL file from secondary jukebox	Check file existence/permissions
FULL Aggregate Failed	Could not copy FULL file from secondary jukebox	Check file existence/permissions
Images JB share is OFF-LINE:	jukebox is offline	Set jukebox back ONLINE
Make AbstractError	Abstract file could not be created from TGA/BIG (BIG/TGA not found or image file corruption).	Check shares for existence of BIG/TGA file. If not found, restore BIG/TGA file from backup tapes.
New Abs to CWL	An abstract file has been created and copied to the current write image share	None
No ABS file VC Ptr Cleared	Abstract file not found on the Image share	None
No ABS file VC Share OFF-Line	Image share is offline at location of abstract file	Set share back online and re-run Verifier
No ABS JB Files	No abstract file found on the jukebox	Check shares for existence of ABS file. If not found, restore ABS file from backup tapes
No Acquisition Site in Image file	The ACQUISITION SITE field #100 in the IMAGE file (#2005) is missing. This is a required field.	Contact IRM Update the field with the proper site ID.
No FULL JB Files	FULL file not found on the jukebox	Check shares for existence of Full file. If not found, restore Full file from backup tapes
No FULL VC Files	FULL file not found on the Image share	None
No jukebox BIG Files	BIG file not found on the jukebox	Check shares for existence of BIG file. If not found, restore BIG file from backup tapes.
No jukebox FULL Files	FULL file not found on the jukebox	Check shares for existence of Full file. If not found, restore Full file from backup tapes.
No Network References	No IMAGE file (#2005) record exists for this image	Re-import image thru the Capture client
No Network References: Archived Image	Image has been archived, resides in the IMAGE AUDIT file (#2005.1)	None
No VC BIG Files	Could not find the BIG file on the image share	None
Not Certed	Could not find/create file type on jukebox	Check shares for existence of BIG file. If not found, restore BIG file from backup tapes.
Problem rename log file:	Permission problem with log file	Set WRITE permissions set on share/folder/file for Windows login account.
Text file Patient ID not in VistA	Could not locate patient ID in VistA	Contact IRM
TXT to BIG VC	Copy TXT file to same share as BIG file	None
TXT to FULL VC	Copy TXT file to same share as FULL file	None
"Check Text" Option Messages
Text File Corruption Error Type 1:	Text file is binary or unreadable	Restore file from jukebox/backup tapes
Cannot determine Text file type:	Foreign text file was not likely generated on the image gateway	Restore file from jukebox/backup tapes
Text File Corruption Error Type 2:	Text file is ASCII but has unprintable characters or truncated	Restore file from jukebox/backup tapes
Text/Image DFN Mismatch:	Patient ID in text file does not match that in VistA	Future utility patch
Text/Image SOP/UID Mismatch	The Series Instance UID in the text file does not match the one in VistA	Future utility patch
Text/Image Study/UID Mismatch	The Study Instance UID in the text file does not match the one in VistA	Future utility patch
Text/Image UID Mismatch	SOP and/or Study UID are/is blank in text file	Future utility patch
Updated Text file	Text file has been edited	Validate file has been copied to the jukebox
No SSN Found	Patient ID field missing in text file	Future utility patch

8.3.3 Integrity Messages on Patient Data

There are integrity issues that will prevent their respective images from being displayed and others that will not impact the viewing. See Appendix C for sample output.

8.3.3.1 Conditions Preventing Viewing

An integrity error message will be generated when the image is retrieved for viewing on these conditions and the patient image will not be viewable until the condition is corrected or the user has the proper key to view these images.

Message	Explanation	Action
No Image Ptr in AP	The Clinical Association Report (AP) for this image does not contain an image entry that points back to this image.	Future utility patch
GP has no images	Image series that does not contain any images. Group Parents (GP) are containers for an Image series. A group parent with NO group objects (GO) is an invalid condition.	Future utility patch
Conflicting AP & Image DFNs	The patient file reference (DFN) in the Clinical Association Report (AP) does not match the DFN in the IMAGE file (#2005).	Future utility patch
Invalid Image Ptr to AP	The Clinical Association Report (AP) has image references that are not in the IMAGE file (#2005).	Future utility patch
Conflicting GP and GO DFN	The patient file reference (DFN) in the Group Parent (GP) is not the same as the DFN in the Image entry.	Future utility patch
GP & GO AP Mismatch	The Group Parent and Group Object pointer references to a Clinical Association Report (AP) do not match.	Future utility patch
GP Missing GO Ptr	The Group Object multiple of the referenced Group Parent does not reference this group object.	Future utility patch
No AP Mult Ptr	This Image entry does not have the clinical application (AP) image multiple entry number specified. The IMAGE file (#2005).record is missing the PARENT DATA FILE IMAGE POINTER (#17) for a Clinical Association Report (AP).	Future utility patch
GO DFN mismatches	Some image file Group Objects have different PATIENT references (DFN).	Future utility patch
Image entry is structurally abnormal	The normal structure that distinguishes Image entry Group Parents (GP), Group Objects (GO), and Non-Group image (NG) is corrupt.	Future utility patch
Missing Group Objects	The Group Parent has Group Object references that are missing.	Future utility patch
DFN Mismatches in AP Image Mult	The Clinical Association Report (AP) references a Group Parent that has image files with a different PATIENT reference (DFN) than the report.	Future utility patch

8.3.3.2 Conditions Allowing Viewing

The following integrity issues will not prevent their respective images from being displayed. These are informational messages.

Message	Explanation	Action
No AP Ptr	The IMAGE file (#2005) record is missing the PARENT DATA FILE# (#16) for a Clinical Association Report (AP). This Image does not have the entry in the clinical application (AP) specified.	Future utility patch
No AP entry Ptr	This Image does not have the entry in the clinical application (AP) specified. The IMAGE file (#2005) record is missing the PARENT GLOBAL ROOT DO (#17) for a Clinical Association Report (AP).	Future utility patch

8.4 Purge

Message	Explanation	Action
Broker Reconnection failed	Auto login after a Broker disconnect failed	Check network. Contact IRM
Create Process failed ProgramName,	Windows failed to create a process.	Reboot the server.
Express Purge Rate limit reached: PurgeRate on share: CurrentShare	The purge terminated on the given share because Express Purge was active and the Purge process exceeded the user defined purge rate.	None
File Delete failure: filename	The file listed could not be deleted.	Check permissions on the share/folder/file
File in use: filename	The log file is in use	Exit from the Purge and restart
File purged: filename. 'The Image file (#2005) was not updated'	The file was deleted on the RAID, but the pointer in VistA could not be updated.	Validate the IEN record exists in VistA.
Findfirst failed filename	The directory traversal failed	Exit from the Purge and restart
Log File Archival reset to: FilePath2 instead of: FilePath1	The logs files are now being stored at another location.	None
Login Message^Broker Reconnection Successful	After a Broker disconnect, the application was able to reconnect to VistA.	None
Login Message^Pausing 3 minutes and will then retry	After a Broker disconnect, the application tries 3 times to reconnect to VistA	None
Login Message^Silent Login attempt failed!	After a Broker disconnect, the application was not able to reconnect to VistA.	Check network connections.
NewCreationDate^SetFileTime Failed filename	Could not set the date of last Accesses on filename	None
Non-Connection related Broker error	Broker disconnected	Check VistA for error trap
NOT Purged criteria: EvalCriteria NOT PURGED-JUKEBOX QUEUED filename date	File was not deleted. See Section 6.4 Purge Criteria.	None
Problem renaming log file filename1 -> filename2	Could not rename log file to versioned log file name	Check permissions.
Purge Criteria: EvalCriteria filename filedate	See Section 6.4 Purge Criteria	None
Purge Criteria: EvalCriteria NOT PURGED filename filedate	File was deleted. See Section 6.4 Purge Criteria	None
Silent Login attempt	Broker was disconnected. Auto login is initiated.	None
Start Date failure	Problem with Date of Last Purge on Scheduled Purge	Contact IRM to clear the record in the Imaging Site Parameter file.

Appendix A: Broker Server Configuration

The BP communicates with the VistA database by using the VistA RPC Broker. The following steps briefly explain the installation of the RPC Broker Client Agent software. For more detailed information, see the RPC Broker Installation Manual.

1. Log in to your workstation as an administrator.

2. Install the RPC Broker client agent software.

3. Run XWB1_xWS.EXE and follow the setup wizard.

4. Answer Yes when given the option of running the Client Agent program on startup.

5. Log in to the workstation as an administrator, start the Registry editor (Start > Run > Regedit) and navigate to HKEY_LOCAL_MACHINE\Software\vista\Broker\Servers.

6. Create a new string value (Edit > New > String Value) and use the remote server name and port number as the name of the value.

Note: Separate the name and the port number with a comma.

This is an example of using RegEdit to create a new Broker connection.

7. Close the Registry Editor.

8. If the server name is not resolved through DNS, open the HOSTS file (located in either WINNT\system32\drivers\etc or WINDOWS\system32\drivers\etc).

9. Add a line to the file that includes the IP address and name of the remote site’s Broker server.

#HOSTS
127.0.0.1Washington
127.0.0.1Baltimore
#END

10. Save and close the HOSTS file.

11. If you set up servers to connect to a server that can be resolved automatically through domain name server (DNS) (e.g. alpha3.domain.ext), no entries are needed in the server’s HOSTS file.

12. Reboot the server and r un the Kernel Broker test program.

RPCTest.exe is a test program distributed and installed on your PC in the C:\Program Files\VISTA\BROKER folder when the Kernel Broker Client Agent software is installed. When executed, it can be used to test the connection to the VistA System. This is valuable in troubleshooting problems with the VistA Imaging System. Please review the Kernel Broker documentation for more information and examples on the test application.

Appendix B: File Formats

The BP Processor can process the following file formats typically used in the VistA system.

File Extension	Description
ABS	A graphics file used to contain abstract data. The file can normally be accessed through the VistA Imaging Clinical Display application.
ASC	A text file containing text in ASCII code. The file can normally be accessed by most text editors on multiple platforms.
AVI	A video file containing compressed data and normally accessed by Windows-based applications.
BIG	An image file containing full diagnostic resolution data normally accessed through the VistA Imaging Clinical Display application.
BMP	An image file containing an uncompressed bitmap of the image. The file is normally accessed through Windows-based applications.
BW	An image file containing an uncompressed or compressed bitmap of the image. The images can be either monochrome or color and are generated by Silicon Graphics Inc equipment. The file can normally be accessed through the VistA Imaging Clinical Display application.
DCM	An image file created using the Digital Imaging and Communications in Medicine (DICOM) format. These files will normally contain both image data and metadata about the patient and the image. The file can be accessed on multiple platforms but can require the use of specialized readers to separate and properly display the image and the metadata.
DOC	A text file containing data, formatting instructions and possibly some image data created by Microsoft Word, WordPerfect or WordStar applications. The file can be accessed by various word processor or text editor applications on multiple platforms.
HTM or HTML	A text file containing both data and Hyper Text Markup Language (HTML) which describes the structure of the data. HTML is usually a set of tags which describe structural information, such as text, paragraph or document formatting information. The file can be accessed through either numerous text editors or browser applications on multiple platforms. When displayed through a browser, the tag information will be used to format the data in the file.
JPG or JPEG	An image file containing a compressed bitmap of the image. The degree of compression can be adjusted during file creation and is performed using algorithms developed by the Joint Photographic Experts Group. This format is a standard image format that can be accessed by numerous applications on multiple platforms.
MP3	An audio file containing encoded digital audio data based on the MPEG-1 Audio Layer 3 standard. The files will normally contain lossy compressed data and is a standard sound format that can be accessed by numerous applications on multiple platforms.
MP4	A multimedia file containing encoded digital audio and video data based on the MPEG-4, part 14 standard. The files can be streamed over the internet and can be accessed by numerous applications on multiple platforms.
MPG or MPEG	A media file based on one of several encoding methodologies created by the Moving Pictures Experts Group. Some of the more common methodologies are: • MPEG-1, or MP3, used for audio data • MPEG-2 used for broadcast quality television • MPEG-4, or MP4, used for video and computer graphics
PAC	An image file used in earlier versions of VistA imaging similar to a TGA file. The file can normally be accessed through the VistA Imaging Clinical Display application. PACS files are files imported through the DICOM Gateway and shown by the Clinical Display workstation.
PDF	A document file containing document text, images, fonts and formatting information developed by Adobe.. Once the document has been created it will retain its format and style across multiple applications and platforms. Numerous applications are available for viewing the file; however a lesser number of applications are available for creating the file.
RTF	A text file containing text and some formatting information developed by Microsoft. The file can normally be accessed by most word processors or text editors on multiple platforms.
TGA	An image file containing uncompressed or lossless compressed raster graphics data developed by Truevision. The file can be accessed through several paint applications on multiple platforms.
TIF or TIFF	An image file containing an uncompressed or lossless compressed bitmap of the image. The degree of compression can be adjusted during file creation. This format is a standard image format that can be accessed by numerous applications on multiple platforms.
TXT	A text file containing data and very limited formatting instructions. The file can be accessed by all text editors and word processors on multiple platforms.
WAV	An audio file normally containing uncompressed waveform data. The file is normally used with Windows based audio applications.

Appendix C: Verifier Integrity Samples

A. Text file is binary or unreadable

This image depicts an unreadable file.

Text file

B. Text file is ASCII, but has unprintable characters or is truncated.

This is an example of an ASCII file.

Text file

C. Patients ID (SSN) field in the text file does not match that in VistA.

o IEN for this sample is 1800

IEN example This is an example of an IEN field in a text file. Patients ID example

Text file

Patients IDs examples circled IEN example

VistA Global

D. SOP Instance UID field in the text file does not match the one in VistA.

This is an example of an SOP instance.

Text File

This is an example of a cross reference of the SOP in a file.

VistA Global

E. Study Instance UID field in the text file does not match the one in VistA.

Study Instance example This is an example of a study instance.

This is an example of a cross reference of a study instance. Text file

Study Instance UID, VistA global

VistA Global (Note the Study Instance UID is found in the parent file.)

F. SOP and/or Study Instance UID are/is blank in the text file..

This is an example of a blank SOP or Study instance.

Text file

G. Patients ID (SSN) in the top section (DATA1) of the text file does not match DICOM- 0010,0020 field in the bottom section (DICOM DATA).

This is an example of Patient ID fields that do not match.

Text file

Glossary

Term	Definition
AA	Acronym for Archive Appliance
Abstract	A “thumbnail” version of an image, which requires less computer processing resources to display than the actual image. Abstract images typically have an *.abs extension. One of the queues of the BP queue processor is also called the ABSTRACT queue.
Aggregate	To gather together as into a single referenced location. The parent term “aggregate function” is triggered by any action that causes a portion of an image set to be copied to the current jukebox location. The aggregate function ensures that the entire image set is copied to the same location.
Archive	Long-term storage of data or images. A jukebox is the most common archive type presently used at sites.
Archive Appliance	A brand of enterprise-level archival storage software
Auto Write update	Process that checks each Image share and designates the share with the most free space as the current write location. The check for space is done after 100 Writes to the share or after 20 minutes since the last check, whichever comes first.
BP	Acronym for the Background Processor in the VistA Imaging System
BPWS	Former term for a Background Processor Workstation, now called a Background Processor Server
Cache	Short name for the VistA Magnetic Cache or VistA Imaging Cache, alternative terms for RAID. See Raid. Contrast with Caché.
Caché	Commercial product name of the software used to install and set up the VistA database. Contrast with Cache.
CBOC	Acronym for community based outpatient clinic
Critical low message	Email to alert key personnel that free space on an Image share has fallen below the %Server Reserve watermark
Current Queue pointer	Queue type specific database reference to the next file copy, create, or destroy request
Current Write location (CWL)	Reference to the network share where images and associated files are stored that are newly acquired or retrieved from the jukebox
DFN	Internal entry number ((IEN)) of a PATIENT file (#2) entry
DICOM	Acronym for Digital Imaging and Communications in Medicine, a protocol for sharing and viewing medical images. DICOM has traditionally been used for radiology images, and recently has been used for images in other specialties such as cardiology, dental, gastrointestinal endoscopy, and ophthalmology.
Directory hashing	Process of storing files in multiple subdirectories based on the filename, as follows: · If hashing is used, files are maintained in a 5-level deep subdirectory structure where no directory will contain more than 100 unique filenames with their various extensions. · If hashing is not used, files are placed and retrieved from the root directory of the share. VistA Imaging recommends using hashing.
File	In the VistA database, the equivalent of a database table, as well as a file in the generic sense.
File types	In VistA Imaging: ABS = Abstract or thumbnail image file BIG = Large image file that takes up a lot of storage space FULL = Full size/full resolution image file TXT = Site-specific installation or setting file
Hash	See Directory Hashing.
HIS	Acronym for hospital information system, which is a comprehensive, integrated information system designed to manage a hospital’s administrative, financial and clinical information related to patient data (electronic patient records)
IEN	Acronym for Internal Entry Number
IMAGE file	File in the VistA database that contains entries of images
IMAGE AUDIT file	File in the VistA database that keeps a record of any image entries that were deleted or missing. Also, used by the Verifier to ensure that a file set exists at the location(s) specified.
Image Set	Includes the FULL/ABS/TXT files and possibly the BIG file
Imaging server	Server used to store the most recently acquired and accessed image files
Internal Entry Number	Unique record number for a specific entry in a FileMan file. Depending on the context, IENs can serve as identifiers for an image set, a single site, or other unique records in files in the VistA database.
IRM	Acronym for Information Resources Management, the Imaging support staff at a VA hospital
Jukebox	Long-term storage device in VistA that holds multiple optical discs or platters and can load and unload them as needed. Also called Archive.
Magnetic cache	Same term as RAID. See RAID.
Namespace	First three characters of the 14-character name given to image files captured at a site. Each VHA facility has its own unique 3-character namespace.
Offline	VistA Imaging shares designation used to isolate shares from auto-write candidacy and the purge function.
Online	Connected to, served by, or available through a system and especially a computer or telecommunications system (as the Internet).
PACS	Acronym for Picture Archiving and Communication System. If a site has integrated a commercially available PACS with VistA Imaging, images from that PACS are treated in a manner similar to images produced by modalities such as a CT or MR.
Purge	One of the three applications in the Background Processor used to process the removal of files from RAID shares when the last access date exceeds the age specification within the local site parameters. The purge process will not delete a file if it cannot locate a copy of that file on the archive. If such a file is detected, purge will create a JUKEBOX queue entry for that file. See also Verifier and Queue Processor.
Queue	A request by the VistA Imaging System to create, move, or delete a clinical image file for the purpose of system efficiency
Queue pointer	Database file reference to the next queue to be processed within the queue file
Queue Processor	One of the three applications in the Background Processor used to handle requests by the VistA Imaging System to manage clinical image files for the purpose of system efficiency. Managing the files involves processing multiple queues (tasks). See also Verifier and Purge.
RAID or RAID shares	Acronym for Redundant Array of Inexpensive Disks, the primary storage area for recently acquired and recently accessed clinical images. Also the term used to identify a specific type of Network Location defined using the Background Processor Queue Manager.
Referenced network files	Image file pointers to the network locations of each of the file types stored within the VistA Imaging System.
Routers	Specific type of Network Location defined using the Background Processor Queue Manager.
RPCs	Acronym for Remote Procedure Calls
RPC Broker	Short name for the VA Kernel RPC Broker, the Client-Server interface component. RPC Broker 1.1 is required for interfacing with the hospital database.
Site Parameters	A set of specifications that is configurable to meet the individual needs of each VistA Imaging System implementation.
UNC	Universal Naming Convention indicated by the format \\SERVER\SHARENAME
Verifier	One of the three applications in the Background Processor used to validate the VistA Imaging network file references in the IMAGE file (#2005) and to consolidate files on the jukebox. See also Purge and Queue Processor.
Veterans Health Information System Technology Architecture	VistA is built on a client-server architecture, which ties together workstations and personal computers with graphical user interfaces at Veterans Health Administration (VHA) facilities, as well as software developed by local medical facility staff.
VIC	Veteran ID card, one of several images that the IMPORT queue can import from external applications
VISN	Veterans Integrated Service Network(s)
VistA	Acronym for Veterans Health Information System Technology Architecture
VistA Imaging Cache	Also called VistA Magnetic Cache, an alternative term for RAID. See RAID. Contrast with Caché.
VistA Imaging shares	Same as VistA Imaging Cache. Contrast with Caché.
VMC	Acronym for VistA Magnetic Cache, an alternative term for RAID. See RAID. Contrast with Caché.
Win32	The set Microsoft Windows operating systems internal function calls which support all operating system activity.
WORM	Acronym for Write Once Read Many.
Write Once Read Many	Once written to the disc, data is only available for reading and cannot be altered. Jukeboxes should be: · WORM-DG for Data General Jukeboxes under OpenNetware · WORM-PDT for Pegasus Jukeboxes · WORM-OTG for OTG Disk Extender Note: WORM-DG and WORM-PDT are for backward compatibility only.

% Free Space DICOM Messages · 21

% Server Reserve · 5, 18, 31, 34, 72, 78, 105, 107, 128

…

…508 Compliance · 83

ABS_VC_PTR · 97, 100

Abstract Files · 30

ABSTRACT queue · 12, 60

Access/Verify codes · 9, 128

Active parameter · 31

Active queue list · 39

Active queue pointer · 39

Active queues · 82

Ad Hoc Enterprise Site Report · 71

Ad Hoc Image Site Usage message · 71

Alt JB Refs · 93

Annotation diagrams · 43

Annotation tool · 51

Application Process Failure message · 71

Applications of the BP Processor · 1

Archive Appliance · 127, 128

ASSOCIATED INSTITUTION field (#.04) · 71

Associated Institutions · 17

Auto option in BP Verifier · 91

Auto Purge · 31, 72

AUTO PURGE queue · 12

Auto Write Location Update · 18

Auto_RAID_Group_Purge message · 72

AutoRouter · 43

Background Processor

applications of · 1

features · 4

VistA Imaging, in · 2

What is? · 1

BackProc log file · 69

Bad JB Refs · 93

Bad VC Refs · 93

Big Files · 30

BIG_JB_PTR · 97, 100

BIG_VC_PTR · 98, 100

BP Server Monitor

configuring · 122

daily monitoring · 125

description · 121

email message sent · 76

monitoring the BP Purge · 126

monitoring the BP Queue Processor · 124

monitoring the BP Verifier · 125

scheduling · 122

BP Servers

adding · 10

assigning tasks · 11

assigning tasks to · 38

configuring · 9

required for processing · 57

server properties · 13

BPError log file · 70

Broker failure · 128

Capture Keys, use · 19

Check Image Text · 91

Check text files · 35, 36

Clinical Association Report (AP) · 88, 89, 136

Compression/decompression · 47

Configuring

BP applications, overall guidelines · 15

mail groups · 24

mail messages · 22

site parameters · 16

Conflicting AP & Image DFNs · 88

Conflicting GP and GO DFN · 89

Current_Write_PTR · 98, 100

CWL · 95

DELETE queue · 12, 62

Deleting queues · See Purging queues

DFN Mismatches in AP Image Mult · 89

DFN_1 · 101

DFN_2 · 101

DFNError log file · 101

Diagram Annotation tool · 51

Diagrams

annotation · 43

in Network Location Manager · 43

storage type · 51

DICOM Gateway

BP Server processing · 63

EVAL queue · 63

full and abstract files · 30

Interface Switch Update · 21

PAC files · 144

Write Location · 21

Domain, in adding mail groups · 25

EKG

in network location · 43

strips for viewing · 43

strips from local and remote MUSE servers · 49

where data is stored · 49

Email messages

Ad Hoc Image Site Usage · 71

Application process failure · 71

Auto_RAID_group_purge · 72

GCC Copy Error · 72

Get_Next_RAID_Group_failure · 72

Image Cache Critically Low · 73

Image_File_Size_Variance · 73

Imaging Integrity Check · 103

Imaging Site Verification Issue · 103

INSTALLATION · 74

listing · 70

Monthly Image Site Usage · 74

Photo ID Action · 75

Scheduled Purge Failure · 75

Scheduled RAID Group Advance Failure · 75

Scheduled Verifier Failure · 76

Site Report Task Was Restarted · 76

Verifier Scan Error log · 104

VI BP Eval Queue · 76

VI BP Queue Processor Failure · 77

Error_Level · 102

EVAL queue · 11, 63, 76, 121

EVAL, task in BP Server Monitor · 121

Excel spreadsheet · 68, 96, 114

Extensions on missing files · 86

F1 key for Help · 66

Failed image or entry · 40

Failed queue list · 39

Failed queues · 82

File types · 19, 143

Full files · 30

FULL_JB_PTR · 97, 100

FULL_VC_PTR · 97, 100

Functional flow of VistA Imaging · 3

GCC

Copy Error message · 72

Generic Carbon Copy field · 17

in Network Location Manager · 43

queue · 12, 62

queue for photo IDs · 55

window · 48

Generic carbon copy · See GCC

Get Next Raid Group Failure message · 72

GO DFN mismatches · 89

GP & GO AP Mismatch · 89

GP has no images · 88

GP Missing GO Ptr · 89

GRP, type of storage · 65

Hardware requirements · 7

Hash subdirectory · 43, 44, 45, 46, 47, 48, 94

Help, getting · 66

HTML files · 68, 96

IEN

count tranversed in Purge · 113

for IMPORT queue · 81

for processing in Verifier · 86

image record currently being processed · 94

in NETWORK LOCATION file · 65

in Process Queue · 66

in record number in Network Location · 51

in Scheduled Verify · 12

in the NETWORK LOCATION file · 92, 93

integrity checks · 88

marked by Offline Image utility · 126

patient data integrity check · 87

range to set in Verifier · 91

record in Network Location · 44

record number in Network Location · 45, 46, 48, 49, 50

text file integrity check · 90

verifying · 87

verifying range · 125

verifying range copied to Image shares · 125

IMAGE AUDIT file

file integrity · 88

IMAGE AUDIT file (#2005.1)

duplicate image entries · 93

Full image · 94

No Archive log file · 98

Image Cache Critically Low message · 73

Image entry is structurally abnormal · 89

IMAGE file (#2005)

file integrity checking · 88

Full image · 94

patient integrity checking · 88, 89

running Verifier · 87

validating network file references · 154

Image File Size Variance message · 73

Image_Class · 102

Image_IEN · 101

IMAGE_PTR · 99

IMAGING SITE PARAMETERS file (#2006.1) · 9, 71

Imaging Site Usage report · 76

IMPORT queue · 12, 61, 79

Import queue properties · 41

Import Queue Security · 17

IMPORT Queue Status report · 79

Installation · See the Background Processor Patch Description

INSTALLATION message · 74

Integrity

checks · 85

image file · 88

patient · 88

text file · 90

Internal Entry Number · See IEN

Invalid Image Ptr to AP · 89

JB Big · 94

JB Full · 94

JB Path 1 · 95

JB Path 2 · 95

JB_ALT_1 · 98

JBTOHD queue · 12, 59

JUKEBOX

in Network Location Manager · 43

queue · 12, 61

Jukebox Write Location · 18

log directory, default · 13

Log files

BackProc · 69

BPError · 70

DFNError · 101

NoArchive · 98

Purge.html · 115

PurgeError.html · 116

Scan Log File · 97

ScanError · 99

specifying location and size on a BP Server · 13

MAG ENTERPRISE · 71

MAG SERVER · 70

MAG SYSTEM security key · 8, 9, 20, 25

MAG WINDOWS secondary menu option · 8, 20, 64

MAG WINDOWS security key · 9

MAG, type of storage · 65

MagBPSetup.exe · 7

Magbtm.exe · 7

MagDexter utility, description of · 6

MAGEVAL · 122

MAGFQ · 122

MagKat utility, description of · 6

MAGMIN · 122

MAGnH · 43

MagPurge.exe · 7

MAGQ BPMONITOR · 76, 122

MAGQ BPMONITOR menu option · 76

MagUtility utility, description of · 6

MagVerifier.exe · 7

Mail groups

adding members · 25

adding remote members · 26

configuring · 24

deleting members · 26

displaying lists of users · 25

domain · 25

guidelines for adding · 25

MAG SERVER · 70

MEMBERS REMOTE · 70

specifying properties · 26

Mail messages · 22

adding names · 23

configuring · 22

displaying lists of users · 22

fields descriptions · 23

notification intervals · 23

removing names · 23

transmission frequency · 23

MEMBERS REMOTE · 70

Memo · 102

Mismatches · 85

Missing files in Verifier · 86

Missing Group Objects · 89

Monthly Image Site Usage message · 74

MUSE

default site number · 19

EKG · 49

locations on EKG tab · 49

remote GE Muse server · 43

server · 49

setting for site location · 17

site # · 49

version # · 49

Namespace · 17

NameSpace, multiple · 19

Network bandwidth · 7

Network configuration · 2

Network connection, troubleshooting · 127

Network Location Manager

adding a new network location · 52

configuring · 43

modifying properties · 53

window · 42

No AP entry Ptr · 89

No AP Mult Ptr · 89

No AP Ptr · 89

No Image Ptr in AP · 88

NoArchive log file · 98

Not enough process memory · 128

Not enough server cache · 128

Not enough write cache available · 128

operational status · 44, 45, 46, 48, 49, 50, 51, 93

Package · 101

Package_IEN · 102

PACS UID · 90

PACS UID field #60 · 90

PARENT DATA FILE file (#2005.03) · 89

Partition, queue · 41

Password, Windows · 20, 47

Patient ID · 90

Patient_Name_1 · 101

Patient_Name_2 · 101

Percent Server Reserve · 73, See % Server Reserve

Permissions

EXPORT share · 8

IMPORT share · 8

READ/WRITE on the domain acct · 8

READ/WRITE on the share/folder/file · 8

Photo ID Action message · 75

Photo IDs · 30, 48, 55, 60, 75, 113

Physical reference · 44, 45, 46, 48, 49, 50, 51, 92, 93

PLACE value · 71

pointer · See Queue partition

PREFET queue · 12, 60

Purge

Auto · 107

auto purge, running · 33

automatic · 32

date criteria, configuring · 32

description · 105

express · 107

express settings · 31

file types purged · 107

manual · 32, 108

processing, understanding · 105

queues · 40

result codes · 108

results output · 118

retention days, configuring · 30

retention times, guidelines for setting · 29

Scheduled · 108

scheduled and express, configuring · 32

scheduled settings · 31

scheduled, running · 33

setting parameters · 106

settings · 29

troubleshooting · 138

What is? · 1

Purge Error log file · 116

Purge Factor · 31, 32, 34

Purge log file · 115

Purge queue by type entries · 82

Purge Rate · 31

Queue Management by Type option · 63

Queue Manager

active/failed status counts · 39

description · 39

priority order · 39

window · 39

Queue Processor

description · 38, 57

setup guidelines · 57

starting the application · 64

tasking · 58

understanding processing · 63

What is? · 1

Queues

ABSTRACT · 60

accessing failed Import Queue properties · 41

active queue pointer · 39

assigning to BP Servers · 11

concept of · 58

corrupted entry · 41

DELETE · 62

EVAL · 63

GCC · 62

IMPORT · 61

JBTOHD · 59

JUKEBOX · 61

PREFET · 60

purging · 40

re-queuing · 40

setting partition · 41

RAID Groups

adding · 54

advance settings · 37

automatic RAID Group advance · 5

current · 17

description · 4

guidelines for setting parameters · 38

guidelines on shares · 4

in Network Location Manager · 43

running the Scheduled RAID Group Advance · 38

setting parameters for RAID Group Advance · 38

Write Location · 17

Range · 91, 92

Rehabilitation Act of 1973 · 83

Reports · See Log File, Emails, and Screen-Generated Output

Re-queuing a failed image · 40

Re-queuing entries to be kept · 82

Retention Days DICOM Messages · 21

Retention Days HL7 – Modality Work Lists · 21

Retention days, configuring · 30

ROUTE.DIC · 43, 46

Router in Network Location Manager · 43

Routing rules file · 43

RPC Broker, configuring · 141

Scan · 91

Scan log file · 97

ScanError log file · 99

Scheduled Purge Failure message · 75, 117

Scheduled RAID Group Advance Failure · 75

Scheduled Verifier Failure message · 76

SCHEDULED VERIFIER task · 85

SCHEDULED VERIFY queue · 12

Screen-generated output

508 Compliance · 83

IMPORT Queue Status · 79

JBTOHD Report · 79

Purge Queue by Type entries · 82

Server Size · 78

Section 508 · 83

Security

Windows · 8

Security keys

MAG SYSTEM · 8, 9, 20

MAG WINDOWS · 9

Server Size, output · 78

Setting up your BP system · 7

Setup requirements · 8

Site

code · 17

configuring parameters · 16

name of remote location · 47

Site Report Task Was Restarted message · 76

Site usage report · 74

Software requirements · 7

SOP · 90

SOP Instance · 90

SSN_1 · 101

SSN_2 · 101

Status counts, active/failed · 39

Storage Type · 65

Study Instance UID · 90

Tape backup · 68

Tasks

ABSTRACT · 60

assigned as queues · 12

assigned to BP Servers · 57

DELETE · 62

EVAL · 63

GCC · 62

IMPORT · 61

JBTOHD · 59

JUKEBOX · 61

PREFET · 60

Timeout VistARad · 19

Timeout Windows Capture · 19

Timeout Windows Display · 19

Transmission frequency, mail messages · 23

Troubleshooting

broker failure · 128

general startup · 127

integrity messages on patient data · 136

network connection · 127

not enough process memory · 128

not enough server cache · 128

not enough write cache available · 128

output HTML messages · 134

Purge · 138

Verifier · 133

UID field · 90

UNC · 46, 48, 49, 51, 65

URLs · 43

in Network Location Manager · 43

storage type · 50

WEB service location · 50

window · 50

User Preference, default · 19

Username, Windows · 20, 47

Variance · 73

VC Abstract · 94

VC Big · 94

VC Full · 94

Verifier

description · 85

integrity checks · 88

integrity samples · 147

maintenance operations · 87

manual · 35

missing files · 86

processing · 86

reasons for running · 87

scheduled, guidelines for setting · 35

scheduling · 36

setting up · 85

settings · 34

starting · 91

tasking · 85

troubleshooting · 133

What is? · 1

VI BP Eval Queue message · 76

VI BP Queue Processor Failure message · 77

VistA Access · 20

VistA Imaging

functional flow · 3

VistA Verify · 20

VistARad Grouping · 18

Watermarking Failed message · 78

Watermarking Successful messsage · 77

WEB service · 50

Windows

BP Verifier · 91

Diagrams · 51

EKG · 49

Event Log · 69

GCC · 48

GO VistA Storage · 78

Imaging Site Parameters · 16

IMPORT Queue Status · 79

JBTOHD Report · 79

Jukebox · 45

Mail Groups · 24

Mail Message Manager · 22

Network Location Manager · 42

Purge / Verifier / RAID Groups · 28

Queue Management by Type · 82

Queue Manager · 39

Queue Processor application · 64

RAID · 43

Routers · 46

URLs · 50

WORM-OTG, type of storage · 65

WORMOTGnH · 43

XTMP global · 81

Date	Patch	Rev	Description
May 2002	Patch 7	1	Updated section 3.1.6.4 “Operational Procedures.”
Apr 2004	Patch 3	2	Updated section 3.1.8.10 and 5.5.7.6 to reflect transition to long file names.
May 2004	Patch 13	3	Expanded and updated Verifier content. Moved Verifier content from Chapter 4 to end of manual. Appendix B absorbed into Chapters 4 (Purge) and 7 (Verifier)
June 2005	Patch 13	4	Expanded and updated Verifier content. Moved Verifier content from the end of initial manual and created a separate manual.
June 2005	Patch 20	5	Updated Background Processor content in this manual. Extracted the entire Chapter 4 Verifier content and created a new manual which contains the extracted content.
Dec 2005	Patch 20	6	Updated Background Processor content in this manual.
Feb 2006	Patch 20	7	Updated sections 5.5.3 thru 5.5.5.1 “VistARad”
May 2006	Patch 20	8	Replaced all “VMC” with “VistA Imaging Shares”.
Mar 2011	Patch 39	9	Revamped content, added new Patch 39 features, merged content from Verifier User Manual. Globally replaced term BP “Workstation” with BP “Server”. 1^st, 2^nd, and 3^rd WPRs completed.
Jan 2012	Patch 121	10	Updated sections 4.1, 4.3, 8.2.2. Added sections 4.6.2.17 and 4.6.2.18. C. Gilbert, H.Suri, L.Scorza

1.5 VistA Imaging Support

2.2 Hardware Requirements

2.3.2 VistA Security

2.3.2.1 Security Keys in VistA

2.5.2 Adding a BP Server to the VistA Imaging System

2.5.4 Removing a BP Server from the VistA Imaging System

3.2.1.1 Administrative Settings

3.2.1.2 Storage Functions Settings

3.2.1.3 Clinical Workstation Settings

3.5.1.1 Guidelines for Setting Retention Days on Files for the Purge

3.5.2 Verifier Settings

3.5.2.3 Running the Scheduled Verifier

3.6.5 Accessing Import Queue Properties

3.7.1.1 RAID Tab

3.7.1.6 URLs Tab

3.7.2 Adding a New Location to Network Location Manager

3.7.5 GCC Queue for PhotoID

4.2 Setup Guidelines

4.5 Starting/Running the Application

4.5.1 Starting the Application and Analyzing the Activity

4.6.2 Email Messages

4.6.3 Screen-Generated Output

4.6.3.2 JBTOHD Report

4.6.3.3 IMPORT Queue Status Report

4.6.3.4 Purge Queue by Type Entries

Chapter 5 Verifier

5.2 Setting Up the Verifier

5.6 Starting/Running the Verifier