Files > IMAGE AUDIT

name
IMAGE AUDIT
number
2005.1
location
^MAG(2005.1,
description
+---------------------------------------------------------------+ | | | Property of the US Government. | | No permission to copy or redistribute this software is given. | | Use of unreleased versions of this software requires the user | | to execute a written test agreement with the VistA Imaging | | Development Office of the Department of Veterans Affairs, | | telephone (301) 734-0100. | | | | The Food and Drug Administration classifies this software as | | a medical device. As such, it may not be changed in any way. | | Modifications to this software may result in an adulterated | | medical device under 21CFR820, the use of which is considered | | to be a violation of US Federal Statutes. | | | +---------------------------------------------------------------+ This file holds data from modified image records of the Image file (2005) and serves as an audit trail for modified images. When image deletion takes place, the image is deleted on the server if it is there, the Parent Report file's pointer to the image file is deleted, the data from the Image file is copied over to this file using the same IEN, and the node in the image file is set to null as it can never be used again. The image residing on the WORM drive cannot be deleted, so it can always be retrieved. This file stores the modified image record from the Image file (2005) and serves as an audit trail for modified images. When image deletion takes place: * The image is deleted on the imaging server (if it is there). * The parent report file's pointer to the image file is deleted. * The data from the image file is copied over to this file using the same IEN. * The node is deleted from the image file. The image residing on the WORM drive cannot be deleted, so it can always be retrieved. The field names and definitions are the same as the Image file (#2005).
applicationGroups
MAG
Fields
#NameLocationTypeDetailsIndexDescription
.001number11.001 NUMBER Field is the Internal Entry Number of the Image File Entry. i.e. "DA" of the Image File entry. Imaging routines and RPC's use the Image DA for lookups. The Image Files associated with this entry are stored on a Networked Image A name for the Image Files is generated from the Image DA, the Extension is appropriate to the Type of Image. i.e. I0014432.JPG
.01object name(+)0;1FREE TEXTBEach object has a natural language name; this usually consists of the patient name, social security number, and object description. This field is automatically defined by the Imaging software.
.05acquisition site(+)100;3POINTER4The 'origin' location is the location where an image is created. For instance, a site like 'St. Louis' may process images for several other locations, such as Topeka, Wichita and Leavenworth. Any reference to a site identifier will return the name of the primary location. For the purpose of finding the 'origin' of images, the more specific sub-site is needed. This field contains the name of this 'sub-site'.
.06export location5;0MULTIPLE2005.11This table contains audit information regarding the export locations of file copies generated by the generic carbon copy (GCC) utility. This utility is used by the Health Eligibility Center functionality.
1fileref0;2FREE TEXTEThis field contains the unique image filename of the image stored on the magnetic server (and the jukebox if you have one). It is always eight characters in length, starting with the facility's 2 character Imaging namespace, with the remaining six characters ranging from 000001 to 999999. The extensions indicate what type of image it is: .BW for Black and White medium resolution (Cath, Path), .TGA for X-ray, .756 for 16-bit namespace, with the remaining six characters ranging from 000001 to set by the Imaging software.
2disk & vol,magnetic0;3POINTER2005.2This field gives the path for the network location of the stored image (i.e. on which server it resides). After a specified time period during which the image is not viewed, the image is deleted from the magnetic server but remains available upon request from the jukebox. It takes slightly longer to display from the jukebox, but if requested, it is moved back to the server until it is no longer being viewed. This field is set automatically by the Imaging software.
2.1disk & volume. - abstract0;4POINTER2005.2This field points to the path of the network storage location for the Image abstract. An abstract is miniature copy of the captured image. If the parent image has not been viewed during the specified time period (if there is a jukebox), this file will be deleted along with the parent image onto the server currently being used to write captured images. This field is automatically set by the Imaging software.
2.2disk & vol.: worm0;5POINTER2005.2This field is a pointer to the Network location file giving the jukebox platter where the image is stored (provided there is a jukebox in the Imaging System). If the jukebox is a WORM, this file can never be deleted.
3object type0;6POINTER2005.02This field is a pointer to the Object Type file (2005.02) which defines the object type of this object, e.g. still image, black & white image, X-ray etc. The image type determines how various actions are performed i.e. how the full resolution image is displayed, or how and when the image abstract is displayed. This field is automatically set by the Imaging software at the time of image capture.
4object group1;0MULTIPLE2005.14The object group is a multiple field pointing back to the Image file (2005.1). Only objects with an object type of GROUP have the object group field defined. These objects can be thought of as the 'parent' of a set of images. Generally, instead of having their own abstract, objects of the GROUP type use the abstract of the first entry in their object group multiple. Sometimes, text will be used in place of the GROUP abstract for speed. Methods for viewing a GROUP object generally allow viewing of all the members of the group, either selectively or altogether. A good example would be a set of thirty CT scan images. Using the integrated view menu option, the tiled display of image abstracts would contain only one abstract for the group. Selecting the group object for viewing provides the user with a tiled display of the abstracts of the individual CT scan images. The user can then identify individual images for full resolution viewing.
5patient0;7POINTER2ACThis field is a pointer to the VistA patient file (#2), and contains the DFN of the patient that the image or object belongs to. The image or object is part of this patient's medical record. This pointer ties the image to the patient and is automatically set by the imaging software.
6procedure0;8FREE TEXTThis field is an abbreviation for the procedure e.g COL for colonoscopy, SUR for surgery, SP for surgical pathology, X-ray for radiology . This field is automatically set by the Imaging software.
7date/time image saved2;1DATE-TIMEThis field is the date and time the image was captured. It is automatically stuffed into the file as 'NOW'. It is not the same as the date and time of the procedure or exam. This field is set automatically by the Imaging software.
8image save by2;2POINTER200This field is a pointer to the New Person file and thus equal to the DUZ of the person who logged in to capture the image. It identifies who captured or saved the image and is automatically stuffed into the image file. An image received via a Multimedia Mail message will not have data in this field.
8.1capture application2;12SET OF CODESC:Capture Workstation
D:DICOM Gateway
I:Import API
Code stored in this field indicates the application that captured this image and created the image entry. This field cannot be edited; it is auto-populated by the "ACA" action index.
9summary object2;3BOOLEAN1:YES
0:NO
This field is used to indicate whether the image or object is to be used as a summary for a group of objects. For example, in a GROUP of images, normally the abstract of the first object in the group multiple is used for the integrated view display. This field allows the user to select a summary image to be used for this purpose. This field is currently not in use.
10short description2;4FREE TEXTThis field allows the user to store a brief, one line description with the image or object record. For images associated with patients, this data is appended to the patient's name and SSN to create the .01 field of the Image file. It is also permanently written on the upper left corner of the image to provide visible identification.
11long description3;0WORD-PROCESSINGThis word processing field allows the user to describe the image at length. The user may only choose to append this long description on selected images - ones which are 'classic' or 'unusual' cases. It can be used to summarize a group of images which have been put together for a conference or consult. It will be used in the future to a greater extent, as options for image capture independent of VistA package are provided.
12last access date0;9DATE-TIMEThis is the date and time the image was last viewed or accessed. Each time an abstract or image is requested for viewing, this field is automatically set with the current date and time. In conjunction with the appropriate site parameter, this field is used for automatic file migration. That is, when an image has not been accessed within the predefined time period, it will be deleted from the magnetic server and will only be accessible from the optical disk jukebox.
13iq0;11BOOLEAN1:YES
This field is set by various integrity checkers in the Imaging software. This field is set if an entry has questionable integrity.
13.5dupe0;12BOOLEAN1:YES
This field is to allow screening of images that have duplicate instances in the archive file and the image file. The intent is to prevent purging of these images on the raid until a utility to store this file on the Jukebox is implemented.
14group parent0;10POINTER2005.1AGPThis field is used for images that are part of a group, for example a CT exam might contain 30 images. This field contains a pointer back to the image file (2005.1), to the object whose type is "GROUP" that points to this object as a member of its group. A pointer to this object will be found in the Object Group multiple of the parent GROUP object.
15procedure/exam date/time2;5DATE-TIMEThis is the date/time of the procedure or the exam. It is obtained from the parent data file, i.e. the date/time of the X-ray exam, the Medical Procedure, the time the Laboratory specimen was obtained from the patient, or the date/time of the Surgical procedure. This often is not the same as the date/time the image was captured. In a long surgical procedure the image capture time may be several hours later than the start of the operation. When a lab specimen is collected from a patient, it may be several days before images are captured from the slide. If images are initially stored on an intermediate media such as X-ray film or video tape, the capture time can be long after the procedure time.
16parent data file#(+)2;6POINTER2005.03The values of fields 16, 17, 18 and 63 are numbers. These numbers are internal entry numbers. Which field corresponds to which internal entry number is explained below. Together, the values of these fields establish a link back to the entry in the "parent" file, that holds the information that describes why the image was collected. The link to the "parent" information is brought about by the combination of the values of fields 16, 17, and, 18, and optionally also field 63. The value of field 16 is a number that indicates the internal entry number of the "parent file" in the VA-FileMan data dictionary. Common parent files are: File Name ==== ==== 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 The records in each of these "parent" files contain a multiple that itemizes the list of images that belong to that record. The field numbers and fixed indexes for those multiples all have the number 2005. The entries within these multiples all have a field that is a pointer back to the image file. The entries in these multiples identify the various images that belong with the record in question. The various parent files each have their own structure, for instance Type Number Form of Root =========== ============ 1 ^RARPT(D0,2005,D1,0)=image... 2 ^MCAR(699,D0,2005,D1,0)=image... 3 ^LR(D0,"SP",D1,2005,D2,0)=image... Depending on the nature of the file structure of the parent file, the imaging software will need either just the value of D0 (type 1 and type 2) to find the correct entry, or the values of D0 as well as D1 (type 3). The values of the fields in the image file correspond to the values of the indices in the parent file as follows: Type Number Field Number and FileMan Index =========== ============================== 1 field 17 = D0, field 18 = D1 2 field 17 = D0, field 18 = D1 3 field 17 = D0, field 63 = D1, field 18 = D2 In the case of type 3, the value of D0 is equal to the value of LRDFN.
17parent global root d02;7NUMERICThe values of fields 16, 17, 18 and 63 are numbers. These numbers are internal entry numbers. Which field corresponds to which internal entry number is explained below. Together, the values of these fields establish a link back to the entry in the "parent" file, that holds the information that describes why the image was collected. The link to the "parent" information is brought about by the combination of the values of fields 16, 17, and, 18, and optionally also field 63. The value of field 16 is a number that indicates the internal entry number of the "parent file" in the VA-FileMan data dictionary. Common parent files are: File Name ==== ==== 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 The records in each of these "parent" files contain a multiple that itemizes the list of images that belong to that record. The field numbers and fixed indexes for those multiples all have the number 2005. The entries within these multiples all have a field that is a pointer back to the image file. The entries in these multiples identify the various images that belong with the record in question. The various parent files each have their own structure, for instance Type Number Form of Root =========== ============ 1 ^RARPT(D0,2005,D1,0)=image... 2 ^MCAR(699,D0,2005,D1,0)=image... 3 ^LR(D0,"SP",D1,2005,D2,0)=image... Depending on the nature of the file structure of the parent file, the imaging software will need either just the value of D0 (type 1 and type 2) to find the correct entry, or the values of D0 as well as D1 (type 3). The values of the fields in the image file correspond to the values of the indices in the parent file as follows: Type Number Field Number and FileMan Index =========== ============================== 1 field 17 = D0, field 18 = D1 2 field 17 = D0, field 18 = D1 3 field 17 = D0, field 63 = D1, field 18 = D2 In the case of type 3, the value of D0 is equal to the value of LRDFN.
18parent data file image pointer2;8NUMERICThe values of fields 16, 17, 18 and 63 are numbers. These numbers are internal entry numbers. Which field corresponds to which internal entry number is explained below. Together, the values of these fields establish a link back to the entry in the "parent" file, that holds the information that describes why the image was collected. The link to the "parent" information is brought about by the combination of the values of fields 16, 17, and, 18, and optionally also field 63. The value of field 16 is a number that indicates the internal entry number of the "parent file" in the VA-FileMan data dictionary. Common parent files are: File Name ==== ==== 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 The records in each of these "parent" files contain a multiple that itemizes the list of images that belong to that record. The field numbers and fixed indexes for those multiples all have the number 2005. The entries within these multiples all have a field that is a pointer back to the image file. The entries in these multiples identify the various images that belong with the record in question. The various parent files each have their own structure, for instance Type Number Form of Root =========== ============ 1 ^RARPT(D0,2005,D1,0)=image... 2 ^MCAR(699,D0,2005,D1,0)=image... 3 ^LR(D0,"SP",D1,2005,D2,0)=image... Depending on the nature of the file structure of the parent file, the imaging software will need either just the value of D0 (type 1 and type 2) to find the correct entry, or the values of D0 as well as D1 (type 3). The values of the fields in the image file correspond to the values of the indices in the parent file as follows: Type Number Field Number and FileMan Index =========== ============================== 1 field 17 = D0, field 18 = D1 2 field 17 = D0, field 18 = D1 3 field 17 = D0, field 63 = D1, field 18 = D2 In the case of type 3, the value of D0 is equal to the value of LRDFN.
19export request status2;9SET OF CODES1:EXPORT REQUESTED
0:EXPORTED
This field is used by Multimedia Mailman when an image needs to be sent to another site. The Imaging software sets the field automatically, after checking its status. After the request is carried out, it will be automatically reset.
30deleted by30;1POINTER200This is the person who deleted the image. It is a pointer to the new person file. The system uses the DUZ variable to set the field.
30.1deleted date30;2DATE-TIMEThis is the date the Image was deleted from the Image File.
30.2deleted reason30;3FREE TEXTThis is the Reason that the Image was deleted.
40package index40;1SET OF CODESRAD:RAD
LAB:LAB
MED:MED
NOTE:NOTE
CP:CP
SUR:SUR
PHOTOID:PHOTOID
NONE:NONE
CONS:CONS
This is an abbreviation of the package that the Image is attached to.
41class index40;2POINTER2005.82The Classification of the Image. CLASS is an index field used for sorting and searching.
42type index40;3POINTER2005.83
43proc/event index40;4POINTER2005.85The PROCEDURE/EVENT of Image. PROCEDURE/EVENT is an index field used for sorting and searching.
44spec/subspec index40;5POINTER2005.84The SPECIALTY/SUBSPECIALTY of Image. SPECIALTY/SUBSPECIALTY is an index field used for sorting and searching.
45origin index40;6SET OF CODESV:VA
N:NON-VA
D:DOD
F:FEE
I:IHS
This field indicates whether this image originated inside or outside of the VA.
50path accession numberPATH;1FREE TEXTThis is the Anatomic Pathology accession number - the identifying number for the slide.
51specimen descriptionPATH;2FREE TEXTThis is the description given to the specimen in the Lab Data file - the information is carried over and stuffed into the Image file.
52specimen#PATH;3NUMERICThis is the specimen number of the slide given in the Lab Data file.
53stainPATH;4FREE TEXTThis is a pointer to the Histological Stain file. It is the stain used in the preparation of the specimen and is input by the pathologist.
54microscopic objectivePATH;5FREE TEXTThis is a pointer to the Microscopic Objective file. It is input by the pathologist and identifies the power of the microscope objective used when capturing the image of the slide.
60pacs uidPACS;1FREE TEXTPThis field is used by the VISTA-PACS interface and is the unique (up to) 64 character image identifier of the PACS image.
61radiology reportPACS;2POINTER74Pointer to radiology report file used by the PACS interface to tie the image to the correct radiology report.
62pacs procedurePACS;3POINTER71This field is used by the CHCP-PACS interface and is a backward pointer to the Radiology Reports file with which this radiological image is associated.
63parent global root d12;10NUMERICThe values of fields 16, 17, 18 and 63 are numbers. These numbers are internal entry numbers. Which field corresponds to which internal entry number is explained below. Together, the values of these fields establish a link back to the entry in the "parent" file, that holds the information that describes why the image was collected. The link to the "parent" information is brought about by the combination of the values of fields 16, 17, and, 18, and optionally also field 63. The value of field 16 is a number that indicates the internal entry number of the "parent file" in the VA-FileMan data dictionary. Common parent files are: File Name ==== ==== 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 The records in each of these "parent" files contain a multiple that itemizes the list of images that belong to that record. The field numbers and fixed indexes for those multiples all have the number 2005. The entries within these multiples all have a field that is a pointer back to the image file. The entries in these multiples identify the various images that belong with the record in question. The various parent files each have their own structure, for instance Type Number Form of Root =========== ============ 1 ^RARPT(D0,2005,D1,0)=image... 2 ^MCAR(699,D0,2005,D1,0)=image... 3 ^LR(D0,"SP",D1,2005,D2,0)=image... Depending on the nature of the file structure of the parent file, the imaging software will need either just the value of D0 (type 1 and type 2) to find the correct entry, or the values of D0 as well as D1 (type 3). The values of the fields in the image file correspond to the values of the indices in the parent file as follows: Type Number Field Number and FileMan Index =========== ============================== 1 field 17 = D0, field 18 = D1 2 field 17 = D0, field 18 = D1 3 field 17 = D0, field 63 = D1, field 18 = D2 In the case of type 3, the value of D0 is equal to the value of LRDFN.
99audit99;0MULTIPLE2005.199This multiple stores previous values of the record fields (audit trail). See the "AUDIT2", "AUDIT40", and "AUDIT100" cross-references for more details.
100descriptive category100;1POINTER2005.81This is mainly for Document Imaging, it further describes the type of document image.
101clinic100;2POINTER44Points to the Hospital location file and will be used mainly for document images. If an image is associated with a patient encounter(visit), this is the clinic they had (will have) the appointment. The appointment date/time is in field #15, PROCEDURE/EXAM DATE/TIME.
102big magnetic pathFBIG;1POINTER2005.2Full file path description for Image file of .BIG file types. This field will indicate on which magnetic server this file resides.
103big jukebox pathFBIG;2POINTER2005.2Full file path on jukebox for images of .BIG file extension. This field will indicate whether this file is located on the Jukebox.
104big file extensionFBIG;3FREE TEXTThis is the Image File Extension (e.g. DCM, BIG).
106routing timestamp4;0MULTIPLE2005.1106This field keeps track of any routing activity.
107acquisition device100;4POINTER2006.04
108tracking id100;5FREE TEXTThis field tracks the packages that are using the Import API. It is an ";" (semicolon) delimited free text field. First piece is the Package ID that performed the Import Second piece is the Internal package identifier.
109create methodMETHOD;1FREE TEXTThis field holds the command that either has created the image(s) or will dynamically access the Image when called from the Display GUI an example is a DLL provided by a COTS product. When the DLL is called, it generates the image.
110document date100;6DATE-TIMEDocument Images can have a separate date, unlike clinical images that are attached to a procedure, and only procedure date is needed.
111routing log6;0MULTIPLE2005.1111
112controlled image100;7BOOLEAN0:NO
1:YES
In the Clinical Display application, the abstract of a controlled image is not shown in the Abstracts or Group Abstracts window. A "canned" bitmap is shown in place of the image. It has a text that states that the image is controlled. controlled images are not displayed until the user explicitly selects the image to be viewed. If the value of this field is 'NO' or the field is empty, then the image is handled "as usual": the actual abstract of the image is shown in the Abstracts and Group Abstracts windows.
112.1controlled dateCOMPUTEDThis field indicates date/time of the most recent change of the image controlled status (see the CONTROLLED IMAGE field (112)).
112.2controlled byCOMPUTEDThis field references the user who made the most recent change of the image controlled status (see the CONTROLLED IMAGE field (112)).
113status100;8SET OF CODES12:Deleted
13:Image Never Existed
Deleted Marks the image as deleted. Image Never Existed There was an Error while copying the Image to the Image Share. The Image entry is deleted and the status is set as Image Never Existed.
113.1status dateCOMPUTEDThis field indicates date/time of the most recent change of the image status (see the STATUS field (113)).
113.2status byCOMPUTEDThis field references the user who made the most recent change of the image status (see the STATUS field (113)).
113.3status reason100;9POINTER2005.88This field indicates the reason for the latest image status change (see the STATUS field (113)).
114number of pages100;10NUMERICThis field stores number of pages in a multi-page document (e.g. multi-page TIFF image).
115.1linked image100;11POINTER2005.1This is a pointer to the rescinded image. For example, when an image is rescinded a new image entry is created and the original is deleted. A link is established between the new image and the rescinded image. The value of the field is the rescinded image.
115.2linked type100;12SET OF CODES1:RESCINDED
This is the type of the image link. For example, when image is rescinded a new image entry is created and the original image is deleted. A link is established between the original and the rescinded image. The value of the LINKED TYPE will be "RESCINDED".
115.3linked date100;13DATE-TIMEThis is the date that the Document/Image was associated with the LINKED IMAGE.
251dicom sop classSOP;1POINTER2006.532The value of this field is a pointer. The pointed to record identifies the DICOM SOP Class that was used to acquire this image.
252new sop instance uidSOP;2FREE TEXTThe value of this field is a string that represents a DICOM UID. The DICOM standard defines the format of a UID: a string containing only digits and periods that does not exceed a length of 64 characters. This field is populated when a corrected version of an image is exported, and the corrections are of such a nature that the image cannot be exported with its original SOP Instance UID. Note that this UID value is assigned by VA software, and thus will always start with the characters "1.2.840.113754.".
253series uidSERIESUID;1FREE TEXTThe value of this field is a DICOM unique identifier for the series to which an image belongs. A DICOM UID looks like a series of digits and periods, is not longer than 64 characters, starts and ends with a digit and never has two consecutive periods.

Referenced by 2 types

  1. IMAGE (2005) -- linked image
  2. IMAGE AUDIT (2005.1) -- group parent, linked image