ASCEND-HI -- CURRENT VERSION RELEASE NOTES
Version 2.14.79 (1/21/2008 )
The online help available for the Ascend-HI program is regularly updated to reflect changes in product features. Please remember to use the help file as a more detailed reference than these release notes.
NOTE: This version of the Ascend-HI program works with the following companion program versions:
AscendHI.DLL - Version 1.1.1416
UpdateHI.EXE - Version 1.1.814 (20071209 <-- This is the last sequential internal update performed by this version)
Here is a list of new database changes
Each new update sequence in the UpdateHI.exe program is listed with a brief note about what it accomplishes. Note that some sequence numbers are skipped.
Update20061229 ' Modified the Order Types and Categories in the OrderTypes and LookupValues
tables.
Update20071127 ' Update the SQL for the FILL LIST report.
Update20071128 ' Update Inventory NDC lookup values in the ReportCriteriaFields table.
Update20071129 ' Update Inventory UniqueId lookup values in the ReportCriteriaFields table.
Update20071130 ' Delete the 'Patient Chart
Label.rpt' from the server and client locations.
Update20071201
' Add Report Criteria as records in the ReportCriteriaFields table.
Update20071202 ' Create SQL WHERE report statements in the db.
Update20071203 ' Add new reports to Security objects.
Update20071204 ' Add Wards as a report filter.
Update20071205 ' Create Pricing Rules lookups.
Update20071206 ' Create new indexes.
Update20071207 ' Create QA Table.
Update20071208 ' Add QA Required Field and UnitId to TPNAttributes.
Update20071209 ' Add SourceOfPayment and InsuranceType lookups to the Lookups table.
Here is a list of new feature enhancements and fixes
CSR: 1567 -- Request: In version 2.14.74 of the Ascend-HI program, the user can create and save orders with a Fill Stop Date beyond Order Stop Date. The program is expected to prevent this from occurring and display a message stating that the Fill Stop cannot be later than Order Stop date. Resolution: The Order form of the Ascend-HI.exe program was modified to insure that the test for the Fill Stop Date is completed in every case, and the message to inform the user of a problem is displayed when the Fill Stop Date is later than the Order Stop Date.
CSR: 1542 -- Request: As reported in CSR 977, version 2.14.43, the Payer screen no longer correctly displays Payer Type in Ascend-HI. Similarly, the Payer report does not show the correct Payer Type value (shows value in box 1 of HCFA instead). The Payer report needs to display the proper Payer Type in the 'TYPE:' field so that users can know which payers need to be updated or corrected for Payer Type. Resolution: Modified code in the payers form and the DisconnectedRecordsets module of the Ascend-HI.exe program to cause the Payer report to properly display the Payer Type in the 'TYPE:' field.
CSR: 1510 -- Request: Revised form 30-1 (RV7 03/07) has a change to the way Metric Quantity is to be printed. Instead of a single field, the field is now split into two parts: the digits before a pre-printed decimal point, and the digits after a pre-printed decimal point. Resolution: Split the Metric Quantity (Quantity in the Crystal Reports file) into 2 separate fields (MetricQuantityDollars and MetricQuantityCents). Each of these fields is now positioned over their respective data entry boxes of the pre-printed form.
CSR: 1490 -- Request: Prospective Clinical Drug Interaction checks are not working properly. NOTE: Clinical Interaction checks done at the time of order entry are properly functioning, and are unaffected by this issue. Resolution: Fixed the Prospective Clinical Checks routines so when checking for prospective clinical interations, the full list is presented.
CSR: 1489 -- Request: Prospective Clinical Checks report geriatric warnings for patients less than 65 years old. Resolution: Changed the calculation to only report geriatric warnings for patients 65 years old or older.
CSR: 1479 -- Request: When creating a receipt, if there is a balance left over, the biller (user) is asked if they want to apply the remaining amount to the secondary payer. If the user clicks the YES button, then a second claim is created for the remaining amount. If the user clicks the Cancel button on the new claim screen, then an adjustment for the remaining amount is posted to the ORIGINAL claim, without a PayerRef (this is interpreted by Ascend-HI software as an adjustment for the Patient). This should not occur. Resolution: In the resolution of CSR: 1426, added a popup window that asks the user to whom the credit should be applied. This causes the adjustment to the original claim to be applied per user preference. If the new ‘copay’ claim is cancelled, an information message appears that informs the user that the adjustment to the original claim remains even though the new copay claim is cancelled. This allows the user to choose whether to manually remove the credit applied in the adjustment. Also, when the new copay claim is displayed, it is now captioned to let the user know that it is the copay claim, rather than the original claim. For example: "New Copay/Secondary Claim for Claim #11 - ClaimRef: 1427".
CSR: 1466 -- Request: An order can be saved with the Prescribing MD field left blank (even though field is marked as required field). Resolution: This is due to a code arrangement issue in the resolution of CSR: 1171. To correct this, The Order.frm's ValidOrder function code was changed so that it no longer interrupts the order validation process.
CSR: 1461 -- Request: Allow users to edit the outgoing NCPDP claim transaction in the Transmit Electronic Claim screen. Save the edited transaction in the Electronic Claims table in the database. Resolution: Changed the EBill form to allow the user to hand-modify the NCPDP transmission message data before an electronic NCPDP transmission is made. The NCPDP transmission log will reflect the version of the NCPDP message that is actually transmitted, regardless of whether the original or an edited version was sent. NOTE: The edits made to the NCPDP transmission do NOT make any changes to any of the sources of the data (Claims, Patient, Orders, etc.). Only the transmission message itself is changed. If the user reselects the same claim to transmit, the original (unedited) NCPDP message is built for transmission.
CSR: 1426 -- Request: When creating a receipt, if there is a balance left over, the biller (user) is asked if they want to apply the leftover amount to the secondary payer. If the user clicks the YES button, then a second claim is created for the remaining amount. Immediately, the user is asked (in a popup message) if they want to apply an adjustment back to the original claim for the difference. If the user clicks the YES button to this message, then an adjustment is posted to the original claim, without a PayerRef (this is interpreted by Ascend-HI software as an adjustment for the Patient). Commonly, the user will want the adjustment posted to the Payer instead of the Patient. In the scenario above, the user is never prompted to choose to where the adjustment should be applied (Payer or Patient). This question should be put to the user before the adjustment is created. Resolution: In the CheckForCopay subroutine of the Common module of the Ascend-HI.exe program, added a popup window that asks the user to whom the credit should be applied (For Payer, the user clicks the YES button; for Patient, the user clicks the NO button). This new message pops up just after the user answers Yes to the popup that asks if they want to apply an adjustment back to the original claim for the difference. Also modified the Claim form's Copay subroutine to populate the status bar at the bottom of the form with more useful information. For example: "ClaimRef: 0, Entered By: Current User, Entered Date: Not Yet Entered, Status: Not Yet Entered".
CSR: 1389 -- Request: DME orders are no longer showing on the Confirm tab of the batch Pending/Confirm/Refill/Print screen. Resolution: In the Pending/Confirm/Refill/Print form, the query that retrieves the orders that need to be confirmed has been changed back to allowing the category 5 (DME Outpatient) orders. Now when the user clicks on the Confirm tab, the DME orders are displayed along with any other order types to which the user has security rights.
CSR:
1388 -- Request: In version 2.14.67,
user gets the message "Your User/group security settings prevent you from working
with this order type. Rx#:Other Medication" when attempting to access
an order to which the user has full rights, as well as rights to All Facilities. Resolution: This is due to the structure of the new security function that checks whether the user is permitted to perform any of the following actions on an order:
Copy
Refill
Discontinue
Un-discontinue
Replace
In the Profile screen form, modified the new security checking function to verify the user's permission (in the user's security record) to access an order that has a category of 'Other Medications'. If so, then the user is allowed to proceed with the action.
CSR: 1220 -- Request: After creating a custom clinical review to generate an intervention message for a single drug (not a drug-drug review), when the drug is included in an order, the custom clinical intervention note is not being triggered (it is not shown in the list of clinical interventions when the order is saved). Resolution: When creating a custom clinical review to generate intervention messages for single drugs (not a drug-drug review), the code was incorrectly posting a -1 (minus one) into the MatchInventoryRef field of the InventoryClinicalReviews table. The value in this field must be a 0 (zero) for the intervention to be triggered when the inventory item is included in an order. Modified the Inventory Form’s code in the cmdClinicalInterventions_Click subroutine to place a value of 0 (zero) instead of -1 (minus one) into the MatchInventoryRef field of the InventoryClinicalReviews table if the user clicks the Cancel button. This results in the clinical intervention being triggered when the inventory item is included in an order.
CSR: 1171 -- Request: Group security settings are supposed to prevent remote site pharmacists from entering orders with Multi-facility Rx counters, but pharmacists are entering new fills and refills with these counters. Resolution: The Orders menu is now modified so that if the user selects the Copy, Refill, Discontinue, Undiscontinue or Replace options in the Orders menu, the program checks to see if the user has security permissions that allow access to the order type (based on its link to an RX Counter in the Order Types form). If the user does NOT have security permission for the RX Counter to which the order type is linked, then a message is presented that informs the user that this action is not allowed. Note that when a user does not have permissions to use an order type, and that order type is the type of order that the user opens, then the order type is displayed in the Order Type dropdown, but the user cannot change the order type in the dropdown. This is to insure that the user can view the type, but not change it. This is an enhancement from the solution released for this CSR in Ascend-HI version 2.14.65.
CSR: 901 -- Request: When a claim is created by one user, and then a second user signs in and creates a secondary claim (copay claim), the program does not record the second user's name in the 'Entered By:' field on the secondary claim. There needs to be a way to track what user created each claim. Resolution: Modified the AscendHI.dll code for the Save routine of the Claim class. Now, when a new claim (including a copay-generated claim) is saved, the EnteredByRef for the new claim will be the user who was logged in when the new claim was saved. For existing claims, when a user saves the claim (even after editing the claim), the EnteredByRef remains unchanged from the user who originally created the claim.
CSR: 606 -- Request: In rare cases, when a lot of users are simultaneously entering orders, the same RX number is being assigned to different orders entered within about 1 second of one another by different users. Resolution: In order to improve the ability to avoid collisions that cause the same RX number to be assigned to different prescriptions, (in the GetNextRXNumber function in the Order class of the AscendHI.dll program) moved the line of code that Writes the RX number to the Defaults table to an earlier execution point. This avoids the delay that occurs when the code searches the existing orders for a duplicate. Once the number is posted to the Defaults table, the search is commenced to identify duplicates. If one is found, the RX number is incremented and the loop is rerun. This occurs until a valid unused RX number is found. During this time, the number that was posted immediately to the Defaults table is found by any other workstations attempting to generate a different order at the same time.
CSR: 434 -- Request: When a user click the Save button on the Referral screen after adding Zip Code, the Zip Code field entry disappears and, if it was previously entered, the State field entry is also empty. Resolution: Modified the subroutine 'txt_Change' in the Referrals form to properly post the Zip Code and State data into the proper object fields.
First Databank Updates
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
3/27/2008
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