ASCEND-HI -- VERSION RELEASE NOTES

Version 2.14.21 (02/21/2007 )

View All Updates

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

Here is a list of new features and enhancements

• CSR: 505 -- Request:  The actions of discontinuing orders and putting orders on hold are not generating queued messages in the outbound interfaces table.  Resolution:  Changes have been made to the DLL to cause generation of a message into the interface queue when an order is discontinued or put on hold.
• CSR: 498 -- Request:  Changes need to be added to the DLL and HI Update program to keep the database compatible with the Ascend (.NET) product.  Resolution:  Changes have been added to the DLL and HI Update program.
• CSR: 462 -- Request: For more efficient client support and software analysis, there needs to be a tab on the Reports window that allows the user to view the actual SQL of a report.  Resolution:  Added the 'SQL Command' tab to the Reports window. When the user clicks on this tab, all of the SQL for the report will show up in a text box. This SQL can be copied and pasted, so for support techs or users who desire to send a copy of the SQL to the development team, this tab can be used to capture or view the SQL.  NOTE: BEFORE the additional criteria's 'WHERE CLAUSE' can be viewed in this tab, the user must FIRST click the Print Preview button (that loads the additional criteria into the query, and then it is visible in the SQL Command tab's text box). This is very convenient when trying to view the SQL prior to the addition of the WHERE CLAUSE.
• CSR: 442 -- Request: When billing Humana PDP (Medicare Part D), Humana is requesting that fields C7 and DI be a two digit fields. The Ascend-HI product is currently sending one (1) digit for each of the fields, when only one digit is necessary (i.e., the value is less than 10).  Resolution: A change was made to the NCPDP class of the DLL for Ascend-HI. For NCPDP transmissions, the changed code adds a leading zero when there is only one character in the 307 C7 field. If there are already 2 or more characters in the field, no additional zero is added. The same was also done for the 418 DI field.
• CSR: 418 -- Request:  A recent change modified the way the program treats Refills Authorized. In this enhancement, if the Refills Authorized field is blank on an order, the software automatically fills the CURES record field with a zero.  The program's internal edit process causes a message to display on the Narcotics Export Errors report (stating that "Refills Authorized is missing"). Since the Refills Authorized field is now auto-filled, this edit is no longer needed.  Resolution:  The internal edit has been removed.
• CSR: 412 -- Request: State of Ohio requires value in PLN04 field to determine Payer type.  Resolution: Added a new table to the database to accommodate the payer types mapping, and this is now linked to the patient's (first) primary payer for orders that relate to that patient. In the Payer screen for each payer, the payer type must be selected, or else two zeros (00) will populate the PLN04 field of the cures report for that payer.  If a payer type is selected for the payer, the type is mapped to a numeric value that will be included as required in the cures reporting. NOTE:  As of this writing, only the state of Ohio requires this field to be included in the CURES report transmission, so only when the facility address is in the state of Ohio is the PLN04 field included in the CURES report transmission.
• CSR: 405 -- Request: Some payers do not put the patient's copay amount in the CopayAmount field of the e-bill response. At least some payers return the patient's copay amount in the PatientPayAmount field. The user needs to be able to (for each payer) select which field of the e-bill response will contain the patient's copay amount.  Resolution: The Payers screen (inside the NCPDP frame, under the Electronic Billing tab) now has a dropdown list that allows the user to choose (for the selected payer) which field of the e-bill response will contain the patient's copay amount. The default is the CopayAmount field. Existing payers will not need editing if the default value is correct. 
• CSR: 374 -- Request:  Do not display the Active Directory related fields in the Security screen (users).  The functionality related to Active Directory will not be implemented until the Ascend product (.NET version) is released.  Resolution:  The fields related to Active Directory are no longer displayed on the Security screen.
• CSR: 318 -- Request: Technician is prompted to select which pharmacist will verify his/her orders at the time s/he enters the order. At a facility where there are a number of pharmacists, and whomever has time will verify orders ( it is not one specific person), a technician can select any verifier's name, just to get past the prompt.  It is possible that a different pharmacist than the one selected by the technician will actually verify their order.  However, the system is not updating the order record with the actual verifier, just leaving initials of the person who was selected by the technician.  Resolution:  This solution includes adding an option in the system defaults that allows the user to select one of three types of Order Verification methods. The default method does not ask the user to name the person who will verify the order, and does not store the verifier's name in the order until the order is manually verified at a later time. This resolves the initial request that the actual verifying pharmacist's name is not reflected on the order.  When the pharmacist verifies an unverified order, their own name (initials) will be linked to the order.  The second method requires the user to select the name of the person who will verify the order, but does not require the verifier to enter their password to authorize the assignment as verifier. The last (third) method requires the user to select the name of the person who will verify the order, and does require the verifier to enter their password to authorize the assignment as verifier.  Note that it is still true that users (such as a pharmacist) can be configured to not require others to verify their orders, but rather their own name is automatically stored as the verifier in NEW orders they create, or INACTIVE orders on which they click 'OK'.  Users who are required to have someone verify their orders can also still have all new orders generated by them automatically be marked as INACTIVE (these options are in the security settings for the user).  Also, when either of the last two order verification methods is chosen, each time the technician tries to create a new order, or a new refill, the window pops up that asks who will be verifying the order.  This window has the option 'Don't ask me anymore during this session' available.  If the user checks this box, then the window will NOT pop up for each new order (for the remainder of this user's login session).  When this is done, the verifier chosen in the window will be placed into each new order without the user being asked again.  If no verifier is chosen by the user, then no verifier name is attached to the order. 
• CSR: 299 -- Request:  When a user selects the payer for a claim (in the 'Payer' dropdown list under the Primary Insurance, Secondary Insurance or Tertiary Insurance tabs of the Claim window), the '<Patient>' option is displayed and chosen, and when the claim is displayed in the patient's profile screen under the 'Financials' tab, it shows 'Patient' as the payer.  When a user desires to run the Accounts Receivable report, the 'Payer' drop down list in the Reports window does not contain an entry called '<Patient>'.  The user expects the '<Patient>' option to be available in the 'Payer' dropdown list under the 'Criteria' tab of the Reports window, for filtering the report to include only those claims that have the patient as a payer.  Resolution:  In all claims where the selected payer was '<Patient>', the PayerRef value is 0 (zero) for the claim.  To filter the report to only those claims where the patient is the payer, the user selects '<All Payers>' for the report, and can then place the text 'AND Claims.PayerRef=0' into the 'Where Clause' text box under the 'Additional Criteria/Format' tab of the Reports window.
• CSR: 232 -- Request:  The following labels and reports are not printing the correct facility information for the "central" pharmacy when an order is assigned to a multi-facility counter is used: Delivery label, Syringe label, Factor label, Supply label, Drug Education form.  Resolution: NOTE: The Delivery Label cannot be modified to include the central facility information, because the label is only linked to the patient, and not any orders. This means that the program does not know from what counter the delivery contents came, and thereby cannot know whether to print central facility information. In this case, the facility to which the patient is assigned is the only facility information that will be printed.
  The Crystal Reports files for the Factor label, Supply label, Drug Education form and Syringe label have been changed to evaluate whether the left-hand 5 characters of the issuing counter are 'MULTI' (not case-sensitive), and if so, including only the central facility information. Otherwise, the local facility information is included instead.
  A note regarding the Syringe Label options:
  Whenever the ‘Include facility name’ option is set to ‘N’, then the Label Header is printed in its place. 
  If the Label Header is blank, then the line is not printed at all.
  When Include facility name = Y and Include facility address = Y, then the facility name appears on the first line, and the following lines include the facility address, followed by the rest of the label information.
  When Include facility name = Y and Include facility address = N, then the facility name appears on the first line, and the following lines include the rest of the label information. The address is not printed following the facility name.
  When Include facility name = N and Include facility address = Y, If the Label Header is not blank, then it appears on the first line, and the following lines include facility address, followed by the rest of the label information. If the Label Header is blank, then the facility address lines print, starting at the very top of the label, followed by the rest of the label information. The facility name is not printed.
  When Include facility name = N and Include facility address = N, If the Label Header is not blank, then it appears on the first line, and the following lines include the rest of the label information. If the Label Header is blank, then the rest of the label information is printed starting at the very top of the label. Neither the facility name nor the facility address is printed.
• CSR: 227 -- Request:  In the Pricing Rules window, the labeling of a field as 'Minimum' is ambiguous.  The meaning and proper use of the field is not clear.  Resolution:  This field is intended as a PER-UNIT minimum (i.e., charge 150% of AWP or $1 per unit, whichever is greater for this item). It does NOT apply at a 'line item' level. In other words, using the example above, if a quantity of 100 of the item is used in a single line of an order, then the total charge for that line will be $100.00. This is the way the feature is designed to work. Changed the caption on the field in the Pricing Rules window to indicate that this is a per-UNIT minimum price.
• CSR: 171 -- Request: Add an option to print the RX number only, and not print the medication name on Delivery Receipt report. This prevents anyone outside the pharmacy from knowing which delivery packages have narcotics.  Resolution:  Added a new 'Shipping Receipt' report for orders. The new report has the same format as the Delivery Receipt report (with an added feature of showing the refill number after the RX number), but without the drug/order description. This new Shipping Receipt is for placement on the outside of a shipping package. The existing Delivery Receipt report can be placed inside the package, so the drug/order description information is viewable only by the intended recipient.

Here is a list of things fixed

• CSR: 497 -- Request:  Multiple copies of the Patient Chart Label are being printed even when the user specifies just one copy.  Resolution:  The printing of multiple pages for this report is due to the fact that the new SQL for the report is causing the report to have more than one detail line, whereas the earlier SQL only ever generated one detail line, and therefore only one page. Modified the Crystal Reports file for this label. Created a 'group' header with the same information as the detail lines, and suppressed the detail lines so only one page is created for the report.
• CSR: 495 -- Request: The Syringe Label is printing the address all on one line, instead of on 2 lines as was done prior to release 2.14.18.  Resolution: The Crystal Reports file for the Syringe Label was modified to properly print the facility address on 2 separate lines (street address on the first line and then the City, State and Zip on the second line.
• CSR: 493 -- Request: The HCFA-1500 (v1.3) form does not properly populate boxes 32 and 32a. Box 32 should contain the servicing facility name and address (without punctuation), but currently prints the address with punctuation. Also, depending on which option is selected in the Payers window (under the 'HCFA-1500/UB-92' tab) for Box 32, the form prints different servicing facilities (options are: Do Not Print, Patient Location and Patient address). Regardless of which is selected, the HCFA-1500 (v1.3) report does not print an NPI for the facility into Box 32a.  Resolution: The HCFA-1500 (v1.3) now properly populate boxes 32 and 32a. Box 32 contains the servicing facility name and address without punctuation. Also, depending on which option is selected in the Payers window (under the 'HCFA-1500/UB-92' tab) for Box 32, the form still prints different servicing facilities. The options now include the new fourth option 'Service Facility Location (for v1.3)'. Selecting this option causes Box 32 to be populated with the name and address of the facility with which the claim is associated. Regardless of which is selected (except for the 'Do Not Print' option), the HCFA-1500 (v1.3) report now prints the NPI for the facility to which the claim is associated into Box 32a. Note that there is no NPI related to the Patient or Patient location, so the facility to which the claim is associated is used. If the 'Do Not Print' option is selected, Box 32 is left blank, as is Box 32a.
• CSR: 486 -- Request: Claims (NCPDP format) are being rejected due to no Prescriber ID in the record. The payer is set up to send NPI as prescriber ID, and the prescriber (MD) does have the NPI properly set, but the NPI is not being sent on the electronic transmission.  Resolution:  The software for creating this segment was placing the facility's NPI into this field (instead of the prescribing doctor's NPI). Since the facility had not been set up with an NPI, then the field was blank. The software has been changed to include the prescribing doctor's NPI instead of the facility's NPI.
• CSR: 485 -- Request: An Error 5 occurs when, under 'Other' tab of Facilities window, the Edit Facilities button is clicked. Clicking OK to the error message allows the user to progress into the edit without further error.  Resolution: This error was corrected by properly referencing an object under the 'Other' tab when attempting to set the focus for the window.
• CSR: 469 -- Request: On the new HCFA-1500(v1.3) form, the description of a line item does not print in the gray area above each line item in section 24. Also, the modifiers for the HCPC codes in column D of section 24 are not printing properly. If 2 or more 2-digit modifiers are entered as space separated groups in the claim window under the HCFA tab (at the bottom of the screen), i.e. AA BB CC, the second modifier characters contain a space between them, resulting in the printing of AA B B CC instead of AA BB CC.  Resolution: The original HCFA-1500 form printed the description under the data under column D of section 24 of the form. In the new form, the Crystal Reports file has been modified to print the description in the gray area above the data for each detail line. In the bottom half of the detail line, under column D, the HCPC code is printed along with the modifiers (now properly parsed and spaced).
• CSR: 468 -- Request:  When printing a pre-made HCFA-1500 (v1.3) form ... the bottom portion of the printed output does not line up exactly with the actual rows of the pre-made forms. In each detail line after the first detail row, the printed rows appear more and more above their expected print positions. By the time the 6th detail row is printed, the row's characters are well into the 'grayed-out' area of the row (where the text should not be printing). The row containing boxes 25-29 actually prints in the text area of the 6th detail line. The printed entries below that row are also elevated in the boxes where they should be printing.  Resolution:  Modified the Crystal Reports file to re-size the detail lines (1 through 6) so that the alignment of the detail lines corresponds to the alignment of these lines on the pre-printed HCFA-1500 (v1.3) form. 
• CSR: 466 -- Request:  When an NCPDP transmission is sent, after the response is received and viewed, an error window is popped up that states that an ERROR 91 occurred in the ReadResponse module of the program. Clearing the error causes it to reappear. After the error message is displayed four times, the error window no longer shows up and the user is returned to the program.  Resolution:  This error 91 was due to a coding error that failed to properly name an object. The object name is now properly referenced, so the error 91 no longer appears. The reason it had appeared 4 times in a row was that the code in which the error resided was accessed 4 times during the act of processing the response.
• CSR: 455 -- This CSR is essentially a duplicate of CSR 454.  Please refer to the description for CSR 454 below. 
• CSR: 454 -- Request: Fewer patients show on the Patient Census report (when run for 'Active Patients') than are currently active. Resolution:  The problem was that the algorithm that detects which tables are used in the report SQL command did not detect a table name due to characters on either side of the table name text. The facility filter-type determination algorithm for the reports has been enhanced to more robustly detect the table names included in the report's SQL command.  Please see related CSR 444 below.
• CSR: 444 -- Request: The On-Call Patient List report is not filtering correctly. When the filter is set to only show patients from a single facility, the report still includes the patients from all of the facilities.  Resolution:  The problem was that the algorithm that detects which tables are used in the report SQL command did not detect a table name due to characters on either side of the table name text. The facility filter-type determination algorithm for the reports has been enhanced to more robustly detect the table names included in the report's SQL command.
• CSR: 441 -- Request: In some dropdown menus that use the new menu-populating functions internal to Ascend-HI, the displayed option descriptions are cut off due to a limit on the number of characters of the description to 50. This limit exists in the field characteristics assigned in the Ascend-HI database.  Resolution:  Modified the LookupValues table in the database to allow for up to 100 characters in the LookupDescription column. Also modified the UpdateHI.exe common code functions to handle the 100-character storage in the field. 
• CSR: 430 -- Request: In the "Financial Daily Activity - Summary" report, if a Receipt item is included in a calculation, the report could not find all of the receipt information, so the report fails to complete.  Resolution:  Modified the Crystal Reports file for the " Financial Daily Activity - Summary" report to select the correct field source for receipt information, so all of the receipt information is found and the report completes properly.
• CSR: 429 -- Request: The Drug Education form does not currently show the facility name.  Resolution: The code in the Crystal Reports file for the Drug Education form was changed to show the facility name.
• CSR: 427 -- Request:  In some cases, when a user clicks on the address hyperlink on the profile screen for a patient (to get connected to MapQuest and view the map for that address), the map is not displayed.  Instead, the user is presented with a screen for international addresses and a query as to what country to search.  Resolution:  The # sign and lack of a required comma in the address entry is causing a problem for MapQuest. When a map is initially requested by the Ascend-HI program, a different request format is used than when the user opens MapQuest and then types in an address for a map search. The MapQuest expectation in the former case requires that there be no # sign included, and that a comma exist after a street address and before the 'apartment' or 'suite' number.  The Ascend-HI program allows the user place a # sign into an address. Now, when that address is passed to MapQuest for a map request, the address is automatically reformatted to comply with the MapQuest expectations for this type of transmission. 
• CSR: 420 -- Request: When canceling an order, the waste amount of a drug was put back into the inventory lot and quantity on hand twice when the particular inventory item was marked as "Dispense As Whole Unit".  Resolution:  Code has been modified so that the waste is only added back once when an order is cancelled and the inventory item was marked as "Dispense As Whole Unit". 
• CSR: 413 -- Request: When in a patient's profile, selecting either the "Verify Inactive Orders" or "Batch Pending/Confirm/Refill/Print" option in the Orders Menu brings up the Verify Orders screen. The list of orders that initially appears in the Print tab or the Verify Orders tab continues to appear while switching between tabs until the "Refill" tab is clicked. No list shows in the Refill tab, and from that point on, the list no longer appears under the Verify Orders and Print tabs. Closing the window and reopening it causes the list to reappear under the Verify Orders and Print tabs.  Resolution:  Modified the Verify Orders screen. Each time the form is opened, the date range fields are cleared, and only the Refill tab will auto-populate the date without the user specifically filling in dates. On all the other tabs, when a user enters a date, the form remembers the dates used in that tab, and reinstates the values to the date range fields when the tab is clicked on again. This only applies until the form is closed. 
• CSR: 406 -- Request:  A new California rule states that pharmacies must report weekly, not monthly, as of 2007.  When adding new narcotics orders to system on 01/11/2007, but not filling them until 01/15/2007, the weekly CURES report (filtered to the dates of 01/08/2007 to 01/12/2007) shows the new orders in the transmission file.  This occurs even though the orders were not filled until after 01/12/2007.  The process appears to select orders based on Entered Date. Also, the Entered Date is the date being reported in the "Fill Date" field of the CURES transaction record.  The selection process, and the Fill Date field, should be based on the order Fill Start Date and not on Entered Date.  Resolution:  Updated the code that creates the CURES report to use Fill Start Date instead of Entered Date for both the 'Fill Date' of the CURES report as well as for the date selection criteria for the CURES report.
• CSR: 393 -- Request: Box 33a on the new HCFA-1500 (v1.3) form is printing  the Insurance Provider Number from the Payer record into box 33a, instead of the Billing Provider's National Provider Identifier (NPI) per the specifications.  Resolution:  The Ascend-HI SQL code and the Crystal Reports file have been modified so that now Box 33 now contains the name and address of the Billing Provider selected under the 'HCFA' tab of the claim window, and Box 33a contains the NPI of the Billing Provider selected under the 'HCFA' tab of the claim window. If no Billing Provider is selected, Box 33 will contain the name and address of the facility to which the claim is associated, and Box 33a will contain the NPI of the facility to which the claim is associated.
• CSR: 392 -- Request: When printing multiple pages on the new HCFA-1500 (v1.3), column 24i extends down to the bottom of the page.  This only happens on multiple page reports.  Resolution: The Crystal Report file for the HCFA-1500 (v1.3) form has been modified to prevent column 24i's lines from extending beyond the bottom horizontal line of the report page when more than one page is generated in the report.
• CSR: 376 -- Request: When submitting batches to Medicare, batches are rejected for leading zeros in loop 2400 Sv1-02. (the Total Price field in the claim). Resolution: This only applied to amounts less than $1. The code has been changed to remove the leading 0 from the dollar amount column to the left of the decimal so that, for example, $0.55 will now be represented as .55 in the field. 
• CSR: 370 -- Request:  Earlier HCFA-1500 form versions had option to allow the order description to be printed in the detail lines of section 24. This is a payer-specific option for field 24d.  Some payers still expect to see the order description in the new HCFA-1500 (v1.3) form.  Resolution:  Please refer to the solution for CSR 469 above.  These two CSRs are essentially identical in resolution.
• CSR: 362 -- Request: On the Cost Of Goods report, not all of the "Retail amount" numbers are being included.  Items with $0 Cost are not showing any amount in the Retail column of this report even when there is a Retail amount in the Inventory record for the item.  Resolution:  Modified the Cost Of Goods Crystal Reports file and the Ascend-HI SQL code.  Added a new column ("Lot Cost") and renamed the previously-titled "Cost" heading to "Inventory Cost".  Also added a new column ("Actual Cost") that prints the actual cost basis for the item (from either the Lot cost , InventoryPricingChanges table cost or Inventory table cost value).  Now all of the Lot Cost, Inventory Cost and Actual cost values can be seen side by side in the report, and summary calculations are done for each column.  Added a line above the item grouping subtotals, and 'bolded' the patient subtotals for easier viewing.  An explanation of the data sources used for each column is now printed at the end of the report to avoid confusion.  Also added null-value handling in the Crystal Report file so that values are no longer dropped from the report if a null value exists in a field used for calculations. 
• CSR: 360 -- Request: Patient copay amount is failing to post to orders when a claim is billed, even when the patient copay amount is returned by the payer in the correct field.  Resolution:   Changed a Boolean flag value setting in the code that reads the e-bill response, so now the code always checks for the copay value and posts it to the correct order record.  Now, when the payer returns a patient copay value, the e-billing screen will pop up a message that asks the user "Would you like to update the orders related to this claim to reflect the Copay Amount amount?".  The message contains a list of the order reference numbers and the amounts that will be placed into each order's copay value, as well as what already exists in the copay value for the order.  If the user selects "Yes", then the Orders table is updated, otherwise the existing values in the CopayAmount field of the related orders are left as they are.  Note that this is a different message than the one that asks about updating "the Patient portion of the Claim".  See also CSR 405 (above, under the new features and enhancements heading) for a related enhancement.
• CSR: 324 -- Request: The patient copay amount is not being stored for each order. The impact of this is that it makes it impossible to show copay amounts on labels or reports related to orders.  Resolution:  Added a field (CopayAmount) to the Orders table of the database to provide a place to store the patient's copay for each order. Modified the e-billing module to populate the appropriate orders' CopayAmount field based on the copay values returned in the billing transaction.  Please also refer to related CSR 360 (above). 
• CSR: 265 -- Request:  A custom report asks for the same parameter multiple times when that parameter is used multiple times in the SQL file related to the report.  Resolution: Modified the custom report code to not ask for user input when gathering non-user-parameter data. This eliminates the multiple occurrences of the pop-up screen that asks for the parameter values. Also modified the code to handle multiple instances of the same parameter in a single SQL file for a custom report without requesting the same parameter from the user multiple times. 
• CSR: 256 -- Request:  When moving from one facility to the next, the required fields for order entry are carried over and are effective in this new facility, however the actual required fields in this new facility are not being used.  The required fields for admission (from the previous facility) were "carried over" as required fields in the new facility. This problem appears when the users switches facilities, and then immediately does the admission of a patient, as is typically the practice.  Resolution:  Some default values were not being cleared when the facility was switched. Changed code to clear all default values and reset them to the new facility values when the user switches facilities. 
• CSR: 230 -- Request:  The Cost of Goods report incorrectly captures the cost history of the supplies reported upon in some cases. The logic of the report does not always properly reflect lot/price history.  Resolution:  The Cost of Goods report has been changed to reflect the actual cost of acquisition (by Lot, or if none then by Inventory cost). Please also refer to related CSR 362 (above).
• CSR: 55 -- This CSR is essentially a duplicate of CSR 256.  Please refer to the description for CSR 256 above. 

First Databank Updates

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

NOTE: 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 02/01/2007

HCPC Codes

• HCPC Codes - 01/15/2007