| # | Name | Location | Type | Details | Index | Description |
|---|---|---|---|---|---|---|
| .001 | number | 11 | .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 | |||
| .01 | object name(+) | 0;1 | FREE TEXT | B | Each 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. | |
| .05 | acquisition site(+) | 100;3 | POINTER | 4 | The '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'. | |
| .06 | export location | 5;0 | MULTIPLE | 2005.01 | This 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. | |
| 1 | fileref | 0;2 | FREE TEXT | This field contains the unique image filename of the image stored on the Vista Imaging file servers. It is either 12 or 18 characters long. It contains three elements: the facility's Imaging Namespace, from the Current Namespace field (#.02) of the IMAGING SITE PARAMETERS file (#2006.1), the Image IEN, and padded with zeros if needed, and the extension that indicates the format of the image. Supported formats are stored in the IMAGE FILE TYPES (#2005.021) file. This field is automatically set by the Imaging software. | ||
| 2 | disk & volume, magnetic | 0;3 | POINTER | 2005.2 | This 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.1 | disk & volume, abstract | 0;4 | POINTER | 2005.2 | This field points to the path of the network storage location for the image abstract. An abstract is a 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 file. Should the abstract be requested for viewing, it will be copied back onto the server currently being used to write captured images. This field is automatically set by the Imaging software. | |
| 2.2 | disk & volume, worm | 0;5 | POINTER | 2005.2 | This 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 it is a WORM, this file can never be deleted. | |
| 3 | object type | 0;6 | POINTER | 2005.02 | This 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. | |
| 4 | object group | 1;0 | MULTIPLE | 2005.04 | The object group is a multiple field pointing back to the Image file (2005). 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. | |
| 5 | patient | 0;7 | POINTER | 2 | AC | This 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. |
| 6 | procedure | 0;8 | FREE TEXT | This 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. | ||
| 7 | date/time image saved | 2;1 | DATE-TIME | This 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. | ||
| 8 | image save by | 2;2 | POINTER | 200 | This 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.1 | capture application | 2;12 | SET OF CODES | C: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. | |
| 9 | summary object | 2;3 | BOOLEAN | 1: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. | |
| 10 | short description | 2;4 | FREE TEXT | This 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. | ||
| 11 | long description | 3;0 | WORD-PROCESSING | This 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 - those 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 packages) are provided. | ||
| 12 | last access date | 0;9 | DATE-TIME | This 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. | ||
| 13 | iq | 0;11 | BOOLEAN | 1:YES | AIQ | This indicates that this image entry has questionable integrity. |
| 13.5 | dupe | 0;12 | BOOLEAN | 1: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. | |
| 14 | group parent | 0;10 | POINTER | 2005 | This 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), 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. | |
| 15 | procedure/exam date/time | 2;5 | DATE-TIME | This 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. | ||
| 16 | parent data file# | 2;6 | POINTER | 2005.03 | The 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. | |
| 17 | parent global root d0 | 2;7 | NUMERIC | The 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. | ||
| 18 | parent data file image pointer | 2;8 | NUMERIC | The 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. | ||
| 19 | export request status | 2;9 | SET OF CODES | 1: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. | |
| 30 | deleted by | 30;1 | POINTER | 200 | This 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.1 | deleted date | 30;2 | DATE-TIME | This is the date the Image was deleted from the Image File. | ||
| 30.2 | deleted reason | 30;3 | FREE TEXT | This is the Reason that the Image was deleted. | ||
| 40 | package index | 40;1 | SET OF CODES | RAD: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. | |
| 41 | class index | 40;2 | POINTER | 2005.82 | The Classification of the Image. CLASS is an index field used for sorting and searching. | |
| 42 | type index | 40;3 | POINTER | 2005.83 | The TYPE of Image. TYPE is an index field used for sorting and searching. | |
| 43 | proc/event index | 40;4 | POINTER | 2005.85 | The PROCEDURE/EVENT of Image. PROCEDURE/EVENT is an index field used for sorting and searching. | |
| 44 | spec/subspec index | 40;5 | POINTER | 2005.84 | The SPECIALTY/SUBSPECIALTY of Image. SPECIALTY/SUBSPECIALTY is an index field used for sorting and searching. | |
| 45 | origin index | 40;6 | SET OF CODES | V:VA N:NON-VA D:DOD F:FEE I:IHS | This field indicates whether this image originated inside or outside of VA. | |
| 50 | path accession number | PATH;1 | FREE TEXT | This is the Anatomic Pathology accession number - the identifying number for the slide. | ||
| 51 | specimen description | PATH;2 | FREE TEXT | This is the description given to the specimen in the Lab Data file - the information is carried over and stuffed into the Image file. | ||
| 52 | specimen# | PATH;3 | NUMERIC | This is the specimen number of the slide given in the Lab Data file. | ||
| 53 | stain | PATH;4 | FREE TEXT | Free text description of the Histological Stain. It is the stain used in the preparation of the specimen and is chosen by the pathologist from the Histological Stain file list. | ||
| 54 | microscopic objective | PATH;5 | FREE TEXT | Free text description of the Microscopic Objective selected by the pathologist. It identifies the power of the microscope objective used when capturing the image of the slide. | ||
| 60 | pacs uid | PACS;1 | FREE TEXT | P | This field is used by the VISTA-PACS interface and is the unique (up to) 64 character image identifier of the PACS image. | |
| 61 | radiology report | PACS;2 | POINTER | 74 | Pointer to Radiology Report file used by the PACS interface to tie the image to the correct radiology report. | |
| 62 | pacs procedure | PACS;3 | POINTER | 71 | This field is used by the VistA-PACS interface and is a backwards pointer to the Radiology Reports file with which this radiological image is associated. | |
| 63 | parent global root d1 | 2;10 | NUMERIC | The 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. | ||
| 64 | parent association date | 2;11 | DATE-TIME | This is the Date that the Document/Image was associated with the Parent Data File. Field # 16 | ||
| 99 | audit | 99;0 | MULTIPLE | 2005.099 | This multiple stores previous values of the record fields (audit trail). See the "AUDIT2", "AUDIT40", and "AUDIT100" cross-references for more details. | |
| 100 | descriptive category | 100;1 | POINTER | 2005.81 | This is mainly for Document Imaging, it further describes the type of document image. | |
| 101 | clinic | 100;2 | POINTER | 44 | Points 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. | |
| 102 | big magnetic path | FBIG;1 | POINTER | 2005.2 | Full file path description for Image file of .BIG file types. This field will indicate on which magnetic server this file resides. | |
| 103 | big jukebox path | FBIG;2 | POINTER | 2005.2 | Full file path on jukebox for images of .BIG file extension. This field will indicate whether this file is located on the Jukebox. | |
| 104 | big file extension | FBIG;3 | FREE TEXT | This is the Image File Extension (e.g. DCM, BIG). | ||
| 106 | routing timestamp | 4;0 | MULTIPLE | 2005.0106 | This field keeps track of any routing activity. | |
| 107 | acquisition device | 100;4 | POINTER | 2006.04 | ||
| 108 | tracking id | 100;5 | FREE TEXT | ATRKID | This 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 | |
| 109 | create method | METHOD;1 | FREE TEXT | This 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. | ||
| 110 | document date | 100;6 | DATE-TIME | Document Images can have a separate date, unlike clinical images that are attached to a procedure, and only procedure date is needed. | ||
| 111 | routing log | 6;0 | MULTIPLE | 2005.0111 | ||
| 112 | controlled image | 100;7 | BOOLEAN | 0: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.1 | controlled date | COMPUTED | This field indicates date/time of the most recent change of the image controlled status (see the CONTROLLED IMAGE field (112)). | |||
| 112.2 | controlled by | COMPUTED | This field references the user who made the most recent change of the image controlled status (see the CONTROLLED IMAGE field (112)). | |||
| 113 | status(+) | 100;8 | SET OF CODES | 1:Viewable 2:QA Reviewed 10:In Progress 11:Needs Review 12:Deleted 13:Image Never Existed | Viewable By default, all images are viewable, and images with no status are considered viewable. QA Reviewed A user has viewed the image and verified that the patient identifier and values of index fields are correct for this image. In Progress When capturing image groups, this status will indicate that the images are being added to the group of images. When the process is complete, the status will change to Viewable. Needs Review Indicates that value(s) of the index fields or patient identifier have been found to be incorrect. VistA Imaging Display application will block images with this status from being viewed. The Image Edit utility can be used to modify the incorrect values of the index fields. 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.1 | status date | COMPUTED | This field indicates date/time of the most recent change of the image status (see the STATUS field (113)). | |||
| 113.2 | status by | COMPUTED | This field references the user who made the most recent change of the image status (see the STATUS field (113)). | |||
| 113.3 | status reason | 100;9 | POINTER | 2005.88 | This field indicates the reason for the latest image status change (see the STATUS field (113)). | |
| 114 | number of pages | 100;10 | NUMERIC | This field stores number of pages in a multi-page document (e.g. multi-page TIFF image). | ||
| 115.1 | linked image | 100;11 | POINTER | 2005.1 | This 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.2 | linked type | 100;12 | SET OF CODES | 1:RESCINDED | This is the type of the image link. For example, when 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 LINKED TYPE will be "RESCINDED". | |
| 115.3 | linked date | 100;13 | DATE-TIME | This is the date that the Document/Image was associated with the LINKED IMAGE. | ||
| 210 | presentation state | 210;0 | MULTIPLE | 2005.05 | Image Presentation state data stored below; this is free-text in XML format. Annotations are included in this data. | |
| 251 | dicom sop class | SOP;1 | POINTER | 2006.532 | The value of this field is a pointer. The pointed to record identifies the DICOM SOP Class that was used to acquire this image. | |
| 252 | new sop instance uid | SOP;2 | FREE TEXT | The 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.". | ||
| 253 | series uid | SERIESUID;1 | FREE TEXT | The 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. |