Scanning and Archiving Module
Training Manual
Dictionaries
Scanning and Archiving Dictionaries
Table of Contents
Page
General Setup & Parameters
Server/Share Dictionary 5
Applications Storage 7
MRM Print Server 8
MEDITECH SMB User 9
Chart Category Dictionary 10
Chart Subcategory Dictionary 11
MIS Medical Records Form Dictionary 12
Patient Record Scanning
Scan Station Dictionary 21
Scan Access Dictionary 23
MRI ICR Reason Dictionary 25
Archiving Parameters
Medical Archive Management 28
MIS MAM Parameters 30
Enable/Disable TCP Services 31
Forms Queue Status 32
Medical Records Form Source 33
Print Server Dictionary 35
MIS Medical Records Form Dictionary 36
Archive Example in ADM 38
Electronic Chart
Electronic Chart 39
Process Archive 41
Electronic Chart Order Dictionary 42
MRI Access Dictionary 44
Online Coding
MRM Parameters 47
Coder Worklists 49
User Profile Dictionary 50
Coding Standards Dictionary 52
Physician Query Dictionary 53
ABS Patient Class Dictionary 55
Point of Contact Scanning
MIS Medical Records Form Dictionary 59
ADM Customer Defined Screens 61
MIS Insurance Dictionary 64
ADM Process Level Dictionary 65
BAR Option Set Dictionary 66
General Setup and Parameters
What is the purpose of Scanning and Archiving?
The purpose of Scanning and Archiving is to ultimately eliminate the need for the paper chart. For physicians and coders, the paper chart currently provides them with the patient information necessary for clinical decision making and medical reimbursement to take place. Scanning & Archiving will allow physicians, coders, and other members of the hospital staff, to perform their everyday, life saving tasks more efficiently and effectively by placing patient documentation online.
What is the difference between Scanning and Archiving?
Documents that do not originate from MEDITECH's software, or documents that are altered in some way, are SCANNED into the MEDITECH system. An example of an altered document may be physician notation on a MEDITECH generated report. The notation on the report requires that the image be scanned.
Documents that originate from the MEDITECH system and are not altered in any way are examples of ARCHIVED documents. The following applications currently have the ability to archive reports:
1. Abstracting 7. Medical Records
2. Admissions 8. Nursing
3. Emergency Department Management 9. Order Entry
4. Imaging and Therapeutic Services 10. OR Management
5. Laboratory 11. Pharmacy
6. Radiology
Hardware Requirements
· Scan Station PC: Must be running Windows 2000(+) and using Workstation (4.18+) for Magic.
· Scanner: Must be installed with a TWAIN driver. This driver type is the only type MEDITECH supports.
· Storage device: Typically a SAN (an array of disks) which hold the images being Scanned/Archived. There will be shared folders on the SAN which determine where a document is in the scanning process as well as if it has been archived. These forms must remain in a static UNC path once created.
Note: Syntera has developed a solution to keep the UNC path static when switching to new hardware. The site should move older images to a slower machine as the older data will not be accessed as often as the newer images will be.
Server/Share Dictionary
This parameter defines a server and share for the storage of non-MEDITECH files, such as images, as well as MEDITECH files, such as archived reports. The server represents the network name of any device on the network capable of transferring files via SMB protocol (will be changed to AMB in the future). The share is a shared folder set up on the storage device.
There will potentially be three folders defined here: TEMP, PERM, and ARCHIVE.
TEMP Share: Stores the images not yet assigned to Form ID. Any Scan user or Assign Form ID user must have full read/write access to the /TEMP share.
PERM Share: Stores images with an assigned Patient Account and a Form ID.
ARCHIVE Share: Stores the MEDITECH generated .tif images of Archived reports. The archived reports may be stored in the PERM share or the ARCHIVE share. Storing archived reports separately will allow for better monitoring of the space used by scanned vs. archived images. The ARCH share must be defined in a folder directly on the server and not within subfolders. Example: //SERVER/ARCH and NOT //SERVER/SHARES/ARCH.
The Information Systems staff at the hospital will provide the name of the Server (storage device) and the folder on that server where images are stored.
MIS Toolbox→(40) System Dictionaries→(200) Multimedia Storage →(10) Server/Share
Mnemonic: A free text field that describes the Server/Share. It is the mnemonic that is indexed within the applications utilizing this type of storage.
Server/Share: This field holds the actual server name path and shared folder name in the standard naming convention format: \\SERVER\SHARE. (No "/" at the end)
Subfolder Hierarchy: Defines the subfolder hierarchy which further organizes the images within the folder on the Storage Device. We recommend the images are organized by MIS.FAC.APP\DATE as it is easier to remember a facility and application name, then the date (month and year) the document was scanned.
Please note, scanned documents are stored by an incremented counter so selecting ‘None’ at the subfolder hierarchy prompt is not recommended.
The Subfolder Hierarchy field does not apply to Archiving. Archived images are stored by a different order, by the internal unique identifier of the document. As a result of this difference, the subfolder hierarchy should be set to “NONE.”
The MIS.FAC.APP Component single folder name with all of the pieces of the name derived from the application doing the filing. For applications with no facility defined, the folder name will default to MIS.APP.
The choices are to have MIS.FAC.APP by itself, have a DATE subfolder structure beneath the MIS.FAC.APP folder, have a DATE subfolder structure above the MIS.FAC.APP folders, or no subfolder structure whatsoever.
The DATE folder structure is actually a six digit number containing the year and the month, e.g. 200404. This structure subdivides folders monthly for easier manageability.
Note: Once this choice has been entered, it can never be changed
Application Storage Dictionary
The Application Storage Dictionary defines which Application databases will be using storage shares defined in the Server Share dictionary, as well as the purposes of each share..
For MRM, we define the purposes of PERM and TEMP and direct the images to the correct server share for Permanent Storage and Temporary Storage. We make this decision based on which stage of the scanning process the document is in.
For Archiving, we define the MRM application with a purpose of “MRM E”and direct it either to the Permanent share or to the Archiving share (if a specific share is set up for archiving).
For ADM or B/AR, we define the shares with a purpose of “POC,” which will direct the images to the Permanent Share as defined in the Server Share dictionary.
MIS Toolbox→(40) System Dictionaries→(200) Multimedia Storage→(100) Apps Storage
Application: Define the Application you will link to a share for a particular function.
Purpose: Describes what type of function will be performed within this application. The MRM application must define a share for the purposes of “TEMP”, “PERM”, “MRM E” (archiving). The B/AR and ADM applications will only define a purpose of “POC (Point of Contact)”.
Override Facility: If the share needs to be changed for a particular facility, the new share name would be entered in this field.
Date: Determine the date to initiate the change of the share for the highlighted facility. A new share is defined if the SAN uses all the space on a particular disk.
ADM and Billing Applications store POC (Point of Contact) images on the Permanent share only.
The MRM Application must set up a Temporary, Permanent and Archiving (MRM E) share for the storage of its images.
MRM Print Server Dictionary
This dictionary defines the print server that will be used to convert the archived forms into .tif images and burn electronic signatures onto scanned documents. This device must have the MRM Print Service (Windows Based) installed as well as the Meditech Print Driver
MRM→(50) System Management →(70) Dictionaries→(61) Print Server Enter/Edit
Mnemonic: Enter a device on the network. PCL5 data files will be sent to the shared folders on this device from MAM for both archiving and the burning of electronic signatures. **Note** The following shared folders in this dictionary must be defined as a fully shared folder on the print server’s C drive.
Share: This folder is not really used anymore because we have the ability to print locally. This folder was needed before to prep the e-chart for physical printing.
Burnshare: This folder holds an image of the electronic signature image and a path to the permanent image. Once these images are overlaid the electronically signed document will be sent back to permanent storage.
Split Share: Splits out the PCL5 file and generates the .tif file of archived forms.
Printer Mnemonic: The printer defined in this list must be called MEDITECHPRINTER. This printer is the virtual printer that is used to change the PCL5 files to .tif images. The Meditech print driver and printing service must be installed on the Print Server.
**Note**
The MT Print Server Service must be running on the device defined as the mnemonic and will be continuously looking for files placed in the shares. This job will appear in the Control Panel -> Administrative Tools -> Services.
Meditech SMB User
The SMB user has all access permissions to the shared folders defined in the Server/Share dictionary. SMB stands for Server Message Block and is a protocol command. The MRM Print Service uses the SMB username and password to obtain access to the shared folders when moving archived documents or electronically signed scanned images to the appropriate folder(s) on the storage device. The client can send commands (SMB’s) to the server to access shares over the network.
MIS Toolbox→(40) System Dictionaries→(200) Multimedia Storage→(200) SMB User
.
Chart Category
The Electronic Chart's Categories and Subcategories correspond to the separators currently used to organize the current paper chart.
Each form within the Electronic Chart will be assigned to a Category. Categories are the major separating section of the Electronic Chart. A Category is analogous to tab separators on a hospital’s paper chart. The Categories are then further organized (discussed in the subcategory dictionary) to determine the order of the E-chart. A few examples of chart categories are Demographic Data, Cardiology, Laboratory, and Nursing.
MIS→(80) Medical Records Forms Menu→ (61)Chart Category
Description: Please note, the description entered is viewable in the E-chart.
HIM Only: Y/N field which determines whether or not HIM has exclusive access to this category. An example of an “HIM Only” category is for internal forms, such as deficiency cover sheets and authorizations for release, used exclusively by the HIM department.
Last Edited By: The last person to file changes to the category and the date on which these changes were filed.
Chart Subcategory
The Chart Subcategories act to separate and further define the Chart Categories. For example, a likely subcategory of “Nursing” category is “Plan of Care.” In the instance where a category does not need subdivision by subcategories, it is recommended that a generic subcategory of <-> or </> be created. It is necessary to have a subcategory since it is a required field in the Forms Dictionary.
MIS → (80) Medical Records Forms Menu→ (71) Chart Subcategory
Mnemonic: Create a subcategory that is meaningful to the end user. Use a generic subcategory if further division of the Category is not needed.
Description: This description will appear in the E-Chart.
Last Edited By: The last person to file changes to the category and the date on which these changes were filed.
MIS Medical Record Forms Dictionary
The MIS Forms Dictionary is used to define all unique documents used within the hospital, whether generated by Meditech or scanned into the system. Any document that is now in your paper chart that you wish to scan or archive must have an entry within this dictionary. The Forms Dictionary is built and used primarily by the hospital’s HIM (or Medical Records) department. Either the HIM department or a Forms Committee will be responsible for identifying and researching every form that must have an entry within this dictionary.
Note: A facility may have two different forms used for the same purpose, such as two distinct consent forms. Two separate entries do not need to be created in the Forms dictionary for each of these consents as long as they have similar characteristics and purposes.
MIS→(80) Medical Records Forms Menu→(11)Medical Records Form
MIS Medical Record Forms Dictionary (Page1)
Form ID: Enter a unique form mnemonic here. An end-user should be able to determine the form from the mnemonic entered here. An example Form ID might be ADM CONS for an Admission Consent form.
Description: Full description of the form being created. This description should be descriptive as it will be viewable in the electronic chart and in PCI.
Confidential: When forms are displayed on the screen, if a form is flagged as confidential "Y" in this dictionary, the system will check if the user has 'Access To Confidential Data', as defined in the MIS User Dictionary. If the user has access to confidential data, any confidential forms will display. If they do not have access, the confidential forms will not display.
Physician Query Form: Still in development. This enhancement will be further discussed during Applications training.
PCI Description: The description of the form, as it is going to be viewed in PCI.
PCI Category: This field is a lookup into the PCI category dictionary. This field will determine if the form will be sent to PCI
PCI Subcategory: This field is a lookup into the PCI subcategory dictionary.