View source for Pimsrn/1

= Overview =

Procedural and legislative changes historically have impacted the way Medical Administration Service completes tasks related to hospital operations.  For version 5.3, this trend has continued.  A number of enhancements, outlined in this overview, relate to needs based on changing VA Policies and Regulations, as well as user requests for enhancements.

NOTE:  There are three routines in the DGI* namespace which should NOT be deleted after the installation of PIMS v5.3.  DGIN, DGINP, and DGINPW are routines that are critical to the normal operation of the software.  Programmers should note that these routines are in the process of being phased out.  In the next release, the above DGI* routines will no longer be supported.

DGIN is being replaced by DGPMHST.

DGINP is being replaced by DGRPDD1.

DGINPW is being replaced by DGPMSTAT.

= Checkout =

The scheduling module has been enhanced to resolve a number of administrative and regulatory data collection needs recently incorporated into the function and duties of Medical Administration Service.  Collection of this data is incorporated into the new checkout functionality.  For the facility to receive workload credit for encounters that occur on or after 10/1/93, it is required to complete this checkout process.

An outpatient encounter can be an appointment, a disposition, or an add/edit stop code.

New functionality is described below.

1.  The capability is provided to document, for each outpatient encounter, whether the treatment provided was for a service-connected condition.  An answer to this question is required in order to receive OPC workload credit.  This question will be asked for all service-connected veterans.
 
2.  For those patients who have (through registration) claimed exposure to Agent Orange, ionizing radiation or environmental contaminants, a provision is provided to document whether the treatment provided was related to Agent Orange, ionizing radiation or environmental contaminants exposure.  An answer to this question is required.

3.  During the checkout process for appointments and dispositions, the ability to add/edit stop codes is provided.  The user will not have to answer the "associated clinic" and "eligibility" prompts, as the system will automatically determine this information.  If the stand-alone option is used, the associated clinic will need to be entered.  Ambulatory procedures data will be collected via entry of a "900" stop code in the same manner as in the previous version.

4.  The ability to make follow-up appointments has been included in the checkout process.  The user will not need to select the clinic or patient for the return appointment.

5.  Provider information may also be asked during the checkout process, depending on the setting of a site-specific parameter.

6.  The ability to collect data related to diagnoses for clinical and billing applications is available.  Like provider information, diagnosis capture is optional.  (At this time, the provider and diagnosis questions are not mandated by Central Office.)

7.  The Appointment Management option has had many new actions added, such as the ability to discharge a patient from a clinic.  The scheduling release notes have detailed information on all the new and changed actions.


= Provider Related Changes =

1.  All places in PIMS where provider is currently prompted will now be prompted for both the Primary Care (Resident) and Attending Physicians.

2.  At the request of several users, sites are able to historically track providers due to the use of a new option that will allow entry of a different provider along with storage of the date and time the change was entered.  Entry of this information will facilitate tracking of provider activity.
 
Gains and Losses Sheet

1.  For some time, the users/sites have been requesting a variation in the way the current Bed Status Report works.  Users have requested a Treating Specialty G&L.  One benefit with this new variation is the proper crediting of workload regarding "boarders", as the credit is to the treating specialty as opposed to a ward location.  This will benefit hospital management, clinicians, utilization review, and billing personnel in tracking treating specialty movement activity along with aggregate statistics.

The Treating Specialty Report (TSR) is a statistical report appended to the traditional G&L.  It will reflect inpatient activity by the actual treating specialty assigned to each patient movement.  As the Bed Status Report (BSR) reflects the bed usage regardless of the treating specialty, the Treating Specialty Report captures the patients actual treating specialty regardless of the physical location.

Input requirements for proper functioning of the TSR include site-specific information that is also date-sensitive.  The application manager/MAS ADPAC must enter or edit the number of patients remaining and patients on absences (PASS, AA, UA, ASIH) as of 9/30/92 to initialize the Treating Specialty Report (TSR), similarly to the way the wards are defined for the Bed Status Report (BSR).  The initialization date also needs to be defined through the ADT System Definition menu.

There is a new option, Treating Specialty Inpatient Information, that will facilitate validation of the patients treating specialty.  The ADPAC, Statistical Clerk, or the Medical Information Supervisor designee should run this option validating the information prior to attempting to initialize and/or generate the Treating Specialty Report (TSR).  The Treating Specialty Report requires that you enter specific information for each treating specialty as of midnight on 9/30/92.  This option provides the information to properly initialize the Treating Specialty Report.  When the information has been validated, it should be entered through the Treating Specialty Set-up option.  It is essential that the correct values be entered in order to print the correct FYTD information on the current Treating Specialty Report.

The following is a guide of suggested v5.3 pre-installation procedures for the MAS ADPAC, Statistical Clerk, or Medical Information Supervisor designee needed for the G&L Treating Specialty Report.
 
A.  Print out the following for 9/30/92.

1.  Treating Specialty Inpatient Information Reports
Patient Listing by Ward
Patient Listing by Treating Specialty
Patient Counts by Treating Specialty
2.  G&L Bed Status Report
3.  Historical Inpatient Listing
4.  Absence List

B.  Compare the total number of patients remaining on PASS, AA, UA, and ASIH on the Bed Status Report with the totals on the Historical Inpatient Listing and the Absence List.  If the Bed Status Report totals do not match the totals on the Historical Inpatient Listing and the Absence List, validate the information.

Recalc the G&L.
Reprint BSR.
Redo Step B.

C.  Compare the Patient Listing by Ward with the Historical Inpatient Listing.  Validate the Patient Listing by Ward patients, PASS, AA, UA, ASIH with the Historical Inpatient Listing and the Absence List.

D.  Validate the Patient Listing by Ward and the Patient Listing by Treating Specialty.  Review for any patients with inappropriate treating specialty for their ward location.  If there were any inappropriate individual treating specialties for patients, correct them.

Reprint all Treating Specialty Inpatient Information Reports for 9/30/92.
Redo Step C.

E.  Validate the Patient Counts by Treating Specialty with the totals on the Patient Listing by Treating Specialty for the patients remaining on PASS, AA, UA, and ASIH.

F.  Keep the Patient Counts by Treating Specialty to aid in initializing the Treating Specialty Report through the v5.3 Treating Specialty Set-up option under the ADT System Definition menu.

2.  A bulletin has been added that is sent to a user or a mail group when the Gains & Losses report auto recalculation job starts and finishes.  This will allow the MAS ADPAC or IRM staff member to determine if the recalculation job finished should there be any discrepancies on the Bed Status Report.
 
Incomplete Record Tracking (IRT)

A number of enhancements were requested by the staff in Medical Record departments throughout the country.  All user input has been extremely helpful to the developers and has improved the IRT module significantly.  The enhancements are as follows.

1.  The ability to track all deficiencies in an incomplete record.  The items were taken from VA Form 10 2493, Record Review Checklist.

2.  All IRT records will require association with a hospital division.  The module tracks responsible physician through completion of the record, as with existing deficiencies in the present version.

3.  Greater flexibility in regard to the print options in IRT has been provided.  Examples include the ability to sort by event date, then physician, then type of report, then status, etc.  A type of report that will involve short forms (discharges for admission of less than 48 hours) and any other reports that do not have to be dictated or transcribed is provided.

4.  Record Tracking capabilities have been added to the IRT module.  The initial screen displays the Current Borrower for the records involved.  Current Borrower information is included on the printouts.  This will provide information to physicians and other involved personnel as to the location of the records in question.

5.  The ability to add or change Providers in order to more effectively track them will be available in both the IRT and Bed Control modules.


Patient Treatment File (PTF)

A number of enhancements to the PTF module have been incorporated in this version.  These enhancements are related to both legislative changes and improvements in functionality and data storage.  The enhancements are as follows.
 
1.  Improvement of the consistency edits in PTF have been accomplished by including all Austin Automation Center (AAC) PTF field edit checks in the module.  The current AAC PTF field checks are defined in the Processing Logic Specifications, version 4.3, authored by the AAC.  These edit checks are performed immediately after successful completion of the current PTF edit checks during the close out step (when the user tries to close the record).  The actual record that is transmitted to the AAC is created at this point.  The additional checks will analyze the record actually being transmitted so that the number of records rejected by the AAC will be minimized.  In addition, the List Manager has been utilized to provide a list of errors discovered during the Austin edit process.  An output that resembles the EAL (Error Analysis Listing) provided to the field by the AAC may be generated by PTF users in order to list all errors encountered.  An enhancement to this output is the description of each error along with the associated error code.  With these enhancements, the coder can thoroughly diagnose any problems with the record in question, correct any errors encountered, and continue with the Load/Edit process without leaving the Load/Edit PTF Data option.  The new field edit checks have been included in the Validity Check of PTF Record option which is found in the Utilities menu.

2.  One enhancement related to legislative changes is the ability to document whether any bed section movement <501> screen is related to Agent Orange, ionizing radiation, or environmental contaminants.  If any movement has been designated as related to AO/IR/EC, then the record and its associated treatment(s) will be considered related to AO/IR/EC.  The questions and responses on the <501> screens are transmitted to Austin in both the <501> and the <701> record.

3.  Another addition to the functionality of the <501> screen in terms of suicide indicator relates to identification of whether the patient had a self-inflicted wound (intentional self-injury) versus a suicide attempt.  This code is entered when the system prompts for a suicide indicator on the <501> screen.

4.  A major PTF enhancement in version 5.3 is the functionality associated with the ability to archive and purge PTF records.  This process involves four distinct steps.  The first step entails generating a list of all PTF records designated for archiving and purging for the selected date range.  The second step involves review of the generated list.  The option responsible for the review step will provide a report of records that should be omitted from the archiving/purging process.  An option used to untag or deselect individual records will also be included at this point.  Records that may have potential problems during the archiving/purging process will be identified here.  The third step involves the actual archiving of the PTF record(s).  The fourth and last step involves the actual purging of records.  All records identified will be purged.  Records that were not first successfully archived cannot be purged.
 
Means Test

1.  Collection of Means Test data is now mandatory for those NSC veterans claiming Agent Orange or ionizing radiation exposure.  The user is able to enter this information in the same manner, via Means Test options, as for other NSC veterans.  Veterans claiming AO/IR exposure will no longer be exempted from the Means Test.

2.  The Means Test screening will be done in both ADT and Scheduling.  This will create new Means Tests, with the status of REQUIRED, on patients whose Means Test is greater than 365 days old.

3.  During both the check in and the checkout process, the Means Test Status will be displayed when using the Appointment Management option.

4.  Four new outputs related to Means Test information are provided in this release.  One option will list all those active patients who have stated that they do not agree to pay the Means Test deductible.  A patient is defined as being active if he or she has had any patient activity (in terms of dispositions, clinic appointments, scheduled admissions, or inpatient movements) within a user-specified date parameter.  A second output produces a listing of patients that either presently require a Means Test or will require a Means Test at their next appointment.  A third output will generate a listing of patients that have had a Means Test entered in a current year, but were categorized with the prior year's MT thresholds.  This would occur if the new MT thresholds for the current year were not available.  The fourth output will produce a listing of review dates of patients who have been designated as hardship cases.


Registration

1.  Users have requested the ability to enter and edit data to the RATED INCOMPETENT? field.  This has been provided via a prompt within the Load/Edit Patient Data option.  It is located on Screen #7 of the option display.  Previously, this was accomplished through use of an option in the AMIE package.

2.  A single entry for Aid & Attendance/Housebound/VA Pension/VA Disability income amounts will replace present ones in the current version.

3.  The prompt for requesting medical records via the Record Tracking package during use of the Register a Patient option is available in the beginning of the Registration process.
 
4.  Data entered into the CLAIM FOLDER LOCATION field on Screen #7 of the Load/Edit Patient Data option conforms to a specific format in order to interface properly with the AMIE package.  It is no longer a free text entry.

5.  With this release, new consistency edits for SSN boundaries have been added.  This will insure that social security numbers outside the valid ranges (as specified by the Social Security Administration) will be rejected.

6.  Additional questions concerning Persian Gulf Theater service have been  included in the Registration process.  Some of the questions will include dates of service, whether or not the veteran is claiming exposure to environmental contaminants, and if so, the date they registered and their date of exam for that exposure.

7.  The ability to print a Health Summary report, Outpatient Drug Profile, or Pharmacy Action Profile along with the VA Form 10 10 will be provided.  A site parameter will allow the facility to make this enhancement available, if desired.  This will provide the emergency care physician the ability to review current medications, past admissions, clinic visits, ancillary test results, etc.


Beneficiary Travel

1.  The Distance Enter/Edit option and associated entries has been modified in order to provide the ability to have multiple entries for departure and destination locations.  This is in response to user requests that different distances be allowed from a single departure point to divisions or satellite clinics in different locations. This will provide a major improvement in the way the Beneficiary Travel module works for those facilities who are multidivisional.

2.  The Claim Enter/Edit option has also been modified to accommodate the need to allow different distances from the departure point to multiple divisions or satellite clinics as mentioned above.

3.  The current "Additional Information" prompt, which requires a YES/NO response, has been replaced with an "Additional Information/Remarks" prompt that is free text in nature.  This enables BT Supervisors to enter remarks for those cases where claim departure locations are outside the facility's treatment area.

4.  Mileage for claim entries will check the zip code in the BENEFICIARY TRAVEL DISTANCE file first, then the name of a city or town.  This accommodates specific departure areas within a city or town.  It will help facilitate the resolution of abbreviated, inconsistently spelled, and identically named cities or towns in different states.
 
Other ADT Enhancements

1.  Users are able to add attending and primary physicians during use of the Discharge a Patient option.  The ability to enter these physicians will also work in conjunction with the Incomplete Records Tracking (IRT) module.

2.  Event Driven Reporting v1.5 was recently released in the EDR namespace.  This software will now become part of PIMS v5.3 in the VAFED namespace.  Along with the old functionality in EDR v1.5, there will be added functionality to capture outpatient events.  A protocol is placed on the PIMS outpatient event driver which will collect all outpatient events.  This information will then be bundled into an HL7 message and sent to the central system.

All the ZIP CODE fields in the PATIENT file will have an associated ZIP+4 field.  These fields will accept either 5 or 9-digit numerics.  The current 5-digit field will remain intact for those ancillary packages currently editing these fields (Pharmacy, Fee Basis, AMIE, HINQ, PDX, Social Work Service, Integrated Billing, and any site specific [local] modification templates that may exist).  This will allow for the continued use of any input and output templates that utilize the ZIP CODE fields currently in the PATIENT File.

The computer-generated VAF 10-10, Application for Medical Benefits, will be modified to include the printing of the new ZIP+4 fields.

All registration screens and the Patient Inquiry Screen will be updated to allow viewing of the ZIP+4 entries.

All scheduling letters will be modified to print the new ZIP+4 fields for mail-out purposes.

When users of those ancillary packages, enter/edit the current 5-digit zip code fields, the corresponding ZIP+4 fields will be automatically updated to equal the 5-digit fields.  Non-PIMS users, however, will not be able to enter/edit the last four digits of the 9-digit zip code field or be able to view it within their respective package menu options until such time as their software is modified.  If a PIMS user enters a 9-digit zip code into the PATIENT file through Registration, it will remain intact UNLESS a non-PIMS user modifies the first five digits of the zip code through an ancillary package.  In this case, the last four digits that were originally entered by the PIMS user will be erased and the correct/new 5-digit code will appear.

Six months from the mandated install date of the PIMS v5.3 (10/1/93), a second patch (approximately 3/1/94) will institute a mandated use of the new ZIP+4 fields. This will give everyone time to review and edit all input and output templates that may exist.
 
We felt that taking this phased-in project approach would give the medical centers ample time to adopt procedures for populating the new ZIP+4 fields, as well as not placing any mandates or deadlines on Medical Administration Service to have their current patient data base in compliance.  We have spoken to the FIRMAC about this approach.  It was agreed that by giving the sites a head start for populating the fields, giving them six months to modify any existing local templates or routines that utilize the current 5-digit fields, and giving the ancillary DHCP packages six 
months to convert to the new format for future releases, would be beneficial to all.  


Event Driven Reporting (EDR)

EDR relies on the MAS Movement Event Driver and the MAS Appointment Event Driver software to determine when an admission, discharge, transfer movement (or cancellation of one of these movements) or outpatient event occurs.  This is the same software that Order Entry/Results Reporting and other DHCP packages use to determine when inpatient movement events occur.  For the release of PTF records, EDR relies on a cross-reference in the PTF RELEASE file.

When one of the events occurs, the EDR software is invoked.  The EDR software captures the event data and stores it in the PIMS EDR EVENT file (#391.51).  Once every twenty-four hours, a background EDR process (VAFED EDR PROCESS EVENTS) that is scheduled to run daily is invoked.  This process interfaces with the DHCP Health Level Seven (HL7) package to convert the event data in the PIMS EDR EVENT file into a series of HL7 messages using the HL7 protocol.  These HL7 messages are then loaded into one or more MailMan messages and sent to the appropriate addressee at the central system.

The following data related to each inpatient movement is captured.

*	Patient Name
*	Patient ID
*	Patient Date of Birth
*	Event Date/Time
*	Patient Class (Inpatient)
*	Patient Location (Ward-Room-Bed)
*	Attending Physician (Name and ID)
*	Treating Specialty
*	Unique Visit Number
*	Ward Service
*	Admission Date/Time
*	Source of Admission (Only applicable to admission movement)
*	Servicing Facility
 
At the time a PTF record is released, the preceding data is captured, along with the following additional data.

*	Type of PTF Record (Census or PTF)
*	Type of Discharge
*	Place of Discharge
*	Diagnosis Coding Method (ICD9)
*	Type of Diagnosis (Final)
*	Discharge Diagnoses

The following data related to each outpatient movement is captured.

*	Event Date
*	Facility Number
*	Clinic Stop Code
*	Provider
*	Diagnosis
*	CPT Codes
*	Patient ID (internal and external)
*	Patient Name
*	Patient Date of Birth
*	Patient SSN

Each event (admission, discharge, transfer, PTF release, outpatient) results in the capture and transmission (through MailMan) of approximately 350 characters of data on average.  The data is captured and stored in the PIMS EDR EVENT file at the local site for approximately 24 hours.  Once the data is transmitted, it is auto-matically purged from the PIMS EDR EVENT file.  The number of inpatient events at a local site (and therefore the amount of data captured and transmitted) will be small.  The amount of outpatient information captured will be moderate.  The mail messages that are built may be purged approximately twenty-four hours after they are sent (once acknowledgment messages are received).  Therefore, additional disk space consumed should be minimal.

The impact on CPU cycles when the data is captured and stored in the PIMS EDR EVENT file should be small but significant.  The impact on CPU cycles will be more significant when the data is converted to HL7 messages, compiled into MailMan messages, and transmitted.  Since this process is accomplished by a background task, the task may be scheduled to run when it will have the least impact.

For further information concerning EDR and the data that it transmits, see the
PIMS v5.3 Technical Manual, appendices B, C, D.