ASCEND-HI -- VERSION RELEASE NOTES

Version 2.14.31 (04/10/2007 )

View All Updates

NOTE:  Each customer service request (CSR) addressed by this update is listed separately below along with its resolution information. 

NOTE:  This version of the Ascend-HI program works with the following companion program versions:

AscendHI.DLL - Version 1.1.1356

UpdateHI.EXE - Version 1.1.766 (20061006 <-- This is the last sequential internal update performed by this version)

NOTE: CSR = Customer Service Request.

Here is a list of new features and enhancements

• CSR: 762 -- Request: Add PriorityRef Field to Sig Codes table.  Resolution: Update sequence # 20061005 has been added to the UpdateHI.exe program to add the PriorityRef column to the SigCodes table.  
• CSR: 697 -- Request: The product allows different items with duplicate charge codes to be added to the inventory. When logged in as a multifacility user, changing an inventory item that has the same charge code as others causes a message to appear. 'Would you like to apply this add/edit to multiple facilities?" Answering YES to this message allows the user to select from a list which facilities will have the items with the same charge code updated along with the change. When the user selects all of the facilities for update, all items with the same charge code are updated. This process allows the user to unknowingly incorrectly change items in inventory.  The system should not allow the user to proceed with the addition until the charge code is corrected to a unique code. A “Uniqueness” check should included for charge codes.  Resolution:  It is not an error that the (multifacility) user can perform this operation. In fact, using the same charge code for multiple items in inventory is a common beneficial practice. This 'batch update' based on charge code feature is intended to allow simpler updating of inventory where the same item exists in multiple facilities, and a batch update of all like items is desired. The user can answer NO to the message that asks about applying the edit to multiple facilities. This will prevent the batch update from occurring. A new warning message has been added to alert the user that the charge code is duplicated in other records (listing the records with a duplicate value). Also, the popup message that asks the user about applying the change to multiple facilities has been made more specific, informing the user of the consequence of answering YES to the question. 
• CSR: 690 -- Request: Need to create PARLevel in the SigCodes table.  Resolution:  PARLevel column has been added to the SigCodes table. 
• CSR: 647 -- Request: Need a field to store the default par level for inventory records that can be used to set the par level during order entry.  Resolution:  The UpdateHI.exe program now creates a field to store the default par level in the inventory table records.
• CSR: 646 -- Request: Need to create a field to store the default fill method for inventory records that can be used to set the fill method during order entry.  Resolution:  The UpdateHI.exe program now creates a field to store the default fill method in the inventory table records.
• CSR: 645 -- Request: Need to create a field to store the default order type for inventory records that can be used to set the order type during order entry.  Resolution:  The UpdateHI.exe program now creates a field to store the default order type in the order table records.
• CSR: 632 -- Request:  Compile new Crystal Reports custom DLL with the file name of CRUFLNET.DLL. Keep the existing CRUFLAHI.DLL file. Resolution:  Recompiled the Crystal Reports custom DLL with the file name of CRUFLNET.DLL. Kept the existing CRUFLAHI.DLL file.
  Added code to the UpdateHI.EXE program (in the frmWorkstationUpdate module) that causes this driver to be registered when the Update is run.  This new DLL file will be included in this and future update packages.
• CSR: 630 -- Request: Add the ability to create a rs.ttx file from the SQL shown on reports screen (in the SQL tab). This will allow the user to easily type or paste SQL into the box and then create a TTX file to use when developing new reports.  Resolution:  Added a button to the SQL tab of the Reports screen that allows the user to automatically create a rs.ttx file from the SQL contained in the text box on the same tab of the screen .
• CSR: 620 -- Request:  When a user is already logged into the Ascend-HI program, and then clicks on the 'lock' icon to log off, the Password screen appears. If the user clicks on the 'x' button (top right corner of screen) to close the screen, the screen closes, but the Ascend-HI program continues to run.  The same is true if the user clicks the upper left corner of the Password screen and then selects the 'Close' option to close the window.  If the user attempts to log back in (clicks the lock icon), an Error 91 message appears. Some users want to use this method to allow minimizing of the Ascend-HI program screen after logging out to secure the program.  Resolution:  A change was made to the code to cause the 'x' button to act like the cancel button. Now, when the user clicks the 'x' button, the entire application closes. Additionally, a minimize button is now included in the title bar, so the user can click that button and it will cause the entire application to minimize. NOTE: When the application is restored on the screen after this, the Password screen will still be minimized within the application's screen. 
  One other way to minimize the Ascend-HI program window after a log off occurs is to simply simultaneously click on the 'START' (Windows icon) key and the 'D' key of the terminal keyboard. This will immediately put the user at their desktop (with the Ascend-HI program minimized). When the user re-accesses the program, the Password screen will still be visible.
• CSR: 541 -- Request:  Add additional inpatient order type categories for Ascend (.NET) functionality.  Resolution:  The additional inpatient order types were added.
• CSR: 529 -- Request:  Remove SQL from reports source code and add source code statements to retrieve SQL for each report from the database (see related CSR: 514).  Resolution:   The ReportRecordSource subroutine was changed to retrieve the report SQL from the database for all but one of the reports ... they now use a routine to retrieve the report's core SQL from the database (Note that this does not include the 'WHERE' clause). The Patient Account Statement report was not modified under this CSR, but instead is tracked separately in CSR: 576.
• CSR: 528 -- Request: Modify Server Update Logic To Work With Vista Operating System.  Resolution:  Modified the server update logic to work with Vista. ConnectionString was not able to be read from the ADO connection so the code was changed to read it from the workstation settings. This change was necessary for checking if a table exists or if a field exists.
• CSR: 514 -- Request:  For compatibility with Ascend (.NET), the SQL for the Ascend-HI reports needs to be added into the new SQL storage tables (SQLSources, SQLSourceTypes and SQLSourceLinks). This will also make it possible for report SQL to be modified without re-compiling the Ascend-HI executable program.  Resolution:   The UpdateHI.exe program now adds the SQL for each of the reports to the SQL tables of the Ascend-HI database.  See related CSR: 529.
• CSR: 513 -- Request: When calculating the creatinine clearance (ClCr) for a patient, the program should include all three variations of Cockroft-Gault equations.  The “standard” Cockroft-Gault equation used in Ascend-HI is based on ideal body weight among other data. However, the equation should also include the two additional variations in the Cockroft-Gault equations (to handle unusually high and low weights).  Resolution: Equations to handle unusually high and low weights have been added to the Ascend-HI creatinine clearance calculations.
  

Here is a list of things fixed

• CSR: 704 -- Request:  There are unnecessary entries in the OrderChanges table due to an error in the order change logging code. These need to be cleaned out of the table. Resolution:  Modified the UpdateHI.exe program to remove the records where the only difference is the format of the date stored in a field. This cleanup is a one-time occurrence.
• CSR: 703 -- Request: When changing the status from Active to Discontinued or Discontinued back to Active, the AscendHI.DLL is not logging the OrderRef number in the OrderChanges table.  Resolution:  Changed AscendHI.DLL code to insure that the OrderRef value is always saved in OrderChanges table entries. 
• CSR: 691 -- Request: When an internally-handled error message is generated by the Ascend-HI application, the version of the running application should be displayed in the error window for ease of troubleshooting. This way, when a user captures a screen shot of the error, the Hann's On Software support team will know immediately which version of the product is encountering the issue.  Resolution:  The RecordError function in the Common module of the software was modified to always display the product and version in the title bar of the error message window. 
• CSR: 639 -- Request: When working in a common order, an Error 5 occurs when the user presses the Enter key while the cursor is on a blank line in the comments text box.  Resolution:  The common order has its 'Therapies' dropdown control disabled. A special routine handles the case in the comments text box when the user presses the Enter key while the cursor is on a blank line. This routine was attempting to force the focus to the Therapies dropdown control, but since this control was disabled, an Error 5 occurs. This special routine no longer attempts to force the focus to the Therapies dropdown control. Instead, it now 'tabs' to the next available control. 
• CSR: 609 -- Request: Previously in the Security screen, if a Technician's option setting for 'Orders need to be Verified' and 'New orders will be inactive' were checked, the Tech was still able to REFILL orders, and those orders would be created with an ACTIVE status.  Now any orders refilled by a technician (with these security options set) are created with a status of INACTIVE.  The program needs to create all refills with an ACTIVE status when created, even by a technician.  Resolution:  The refill action has been changed back to forcing the status of the new refill order to be 'Active'. 
• CSR: 540 -- Request:  When a held order is released from Hold and changed to Active, the release is not being flagged in Pyxis.  Resolution:  Corrected this so that now, when an order is released from 'Hold' status, the event information is being passed to the Pyxis system.
• CSR: 532 -- Request: Inventory and Lot quantity on hand (QOH) values are not being correctly updated when an order changes status.  Resolution:  See resolution for related CSR: 319. 
• CSR: 375 -- Request: When making a change to date fields in an order, the changes are not being recorded as changes in the Order Log (OrderChanges table) for the order.  Resolution:  Modified LogChanges routine in the Order class object to properly distinguish the same date in different forms when comparing order records and determining whether a change should be logged. 
• CSR: 319 -- Request: Inventory and Lot quantity on hand (QOH) values are not being correctly updated when an order changes status.  Resolution:
  A change was made to the AscendHI.DLL that addresses this issue. Now a matrix of inventory quantity actions determines whether the inventory and Lot QOH values are incremented or decremented, depending on the initial and final status of the order when edited. The new algorithm uses the following Logic:
  Each order status has one of two possible inventory actions associated with it (Decrement inventory and Increment inventory).
  1. If an order status changes from a decrementing to a non-decrementing status, Items in the order are returned to inventory.
  2. If an order status changes from a non-decrementing to a decrementing status, Items in the order are removed from inventory.
  3. If an order status starts and remains in a decrementing status, Items in the order are returned to inventory (based on the pre-edited values stored in the database for the order), and then removed again from inventory (based on the changed order's data).
  4. If an order status starts and remains in a non-decrementing status, the inventory item quantities are NOT changed.
  5. If an order is Replaced, the replaced items have their inventory quantities decremented.
  This CSR is essentially duplicated in related CSR:532. 
  The statuses below show whether they are 'Decrementing' or 'Incrementing' states.
  

  Active	D
  Inactive	D
  Hold	I
  Pending	I
  Cancelled	I
  Replaced (auto-created by ‘Replacing’ an existing order)	D
  Discontinued	I

  
  

First Databank Updates

• AWP Pricing Update - 03/29/2007
• Patient Education Monographs (English) - 03/29/2007
• Patient Education Monographs (Spanish) - 03/29/2007
• Drug-Drug Interactions - 03/29/2007
• Drug-Disease Contraindications - 03/29/2007
• Drug-Food Interactions - 03/29/2007
• Duplicate Therapy Checking - 03/29/2007
• Geriatric Precautions - 03/29/2007
• Lactation Precautions - 03/29/2007
• Min/Max Adult Daily Dose - 03/29/2007
• Pediatric Precautions - 03/29/2007
• Pregnancy Precautions - 03/29/2007

To determine the date of the First Databank files currently installed into your database, follow the steps of:

1. Click on the HELP option of the main menu of the Ascend-HI screen.  From the pull-down menu that appears, Select the 'About Ascend-HI' option to activate the ABOUT screen.
2. On the right-hand side of the ABOUT screen, the date is displayed as:  First Databank Current as of 03/29/2007

NOTE:  If a more current version of the First Databank files has been received by Hann's On Software since this release, you can go to the Hann's On Software website and perform a First Databank update that updates your Ascend-HI to the most current First Databank files.

HCPC Codes

• HCPC Codes - 01/15/2007