ASCEND-HI -- CURRENT VERSION RELEASE NOTES

Version 2.14.88 (4/15/2008 )

View All Updates

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.1423 

UpdateHI.EXE - Version 1.1.822 (20080115 <-- 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.  

Update20071210 ' Add Stop Order Notices report SQL and its references to database.
Update20071211 ' Add Charges report SQL and its references to database.
Update20071212 ' Add Accounts Receivables By Patient report SQL and its references to database. Update DiagnosisCodes description in SQLDescriptions table.
Update20071213 ' Add DME Not Returned, Patient Account Status and Patient Mailing Labels reports SQL and their references to database. Delete the form SQLSources any SELECT statements that have a space as the first character.
Update20071214 ' Modify criteria fields for 'Inventory' report. Add column "Comments" to SQLSources table. Add/change lookup values for Orders, OrderTypes, Clinical Reviews and Patients.
Update20071215 ' Add criteria fields into the lookups table for Patients and Payers reports.
Update20071216 ' Add CMN/DME forms to the ClinicalDocumens table. Add CMN/DME questions and answers to the ClinicalDocumensQA table.
Update20071217 ' Add report criteria fields for Rooms reports.
Update20071218 ' Replace some incorrect values in the ClinicalDocumentsQA table.
Update20071219 ' Create report group links for some reports.
Update20071220 ' Add report criteria fields for Inventory reports. Add SQL source for Narcotic Log and Inventory with Invalid NDC reports.
Update20071221 ' Change the stored SQL for the Payers report.

Update20071222 ' Change SQL for Clinical Interventions report and add parameters for report.
Update20071223 ' Add default dates.
Update20071224 ' Update the Charges report SQL.
Update20071225 ' Add incentive fee.

Update20071226 ' Update SQLDescriptions table to set DefaultDateFields to the report name for the Fill List and MAR reports.
Update20071227 ' Add a new WHERE clause for the MAR report.
Update20071228 ' Change the LookupDescription in the LookupValues table for some 'Gram' entries.
Update20071229 ' Create/ index SQLParameters table. Add ' Precision' column to TPNAttributes table. Delete WHERE clauses from SQLSources table for Patient Profile report.
Update20071230 ' Add criteria to ReportCriteriaFields table.
Update20071231 ' Update the TPNAttributes table's OrderUnitId values for some cases.
Update20080101 ' Update the delivery and shipping receipts SQL for Ascend.
Update20080102 ' Add Charge Methods to the report filters.
Update20080103 ' Add Charge Date to the report filters.
Update20080104 ' Add NCPDP Eligibility Clarification Code.
Update20080105 ' Add columns to Claims table: Insured1EligibilityClarificationCode,Insured2EligibilityClarificationCode, Insured3EligibilityClarificationCode.
Update20080106 ' Update values in the Orders table to back-fill patientAdmissionRef for orders where the value is NULL.
Update20080107 ' Add program SQL to SQLSources for OrderWithDeliveryPatientAddress and OrderWithDeliveryShippingAddress. Add Fill List report WHERE clause to SQLSources table.
Update20080108 ' Add "X12 2300 Loop CLM01 01 field: Claim Submitter ID" parameter to the PayerDefaultTypes table and it's options ("Claim Number" and "Patient ID") to the PayerDefaultTypeLookups table.
Update20080109 ' Modify the SQL in the SQLSources table for the Payers report.

Update20080110 ' Add lookup values for the Payers form's HCFA1500 tab.
Update20080112 ' Change the SQL in the SQLSources table for the Patient Access report.
Update20080113 ' Change the SQL in the SQLSources table for the Fill List and Charges reports.
Update20080114 ' CSR: 58 -- Add a new lookup value for the Payers form's HCFA1500 tab HCFA Box 24d dropdown.

Update20080115 ' CSR: 643 & 644 -- Remove the Fill List and MAR report files. 

Here is a list of new feature enhancements and fixes

• CSR: 1803 -- Request:  The ReportRecordSource routine of the Reports form that retrieves Report SQL is not compatible with SQL Server version 2000 and below. An error regarding an open paren '(' occurs when the user enters the Reports form, and each time a report name is highlighted. The same occurs when the Print Preview button is clicked. In every report except Patient Account Statement, the stream of error messages contains the familiar 'There is no recordsource for the xxxxxx report' (xxxxxx is replaced by the selected report's name).  Resolution:  The error is the result of hard-coded SQL in the ReportRecordSource routine of the Reports form that contained: 'SELECT TOP (1) ...'. This works when applied to the SQL Server 2005 database engine. However, the SQL Server 2000 database engine does not accept this format. The SQL has been modified to remove the parentheses that were around the 1 so that this statement works with older database engines.

• CSR: 1796 -- Request:  The warning message "You license is about to expire. It is important that you download an update today." is misspelled. It should read: "Your license is about to expire. It is important that you download an update today." This message appears to the user when the product's license expiration date is 6 or less days from the current date.  Resolution:  The warning message has been changed to "Your license is about to expire. It is important that you download an update today." 

• CSR: 1780 -- Request:  Need to change error handling in DownloadProgramUpdate Subroutine to handle all errors. Currently, it traps only for one specific error. If that specific error occurs, then the code exits the subroutine. Otherwise, the program resumes at the line of code following the one in which the error was detected. All errors that occur in the DownloadProgramUpdate Subroutine should cause an exit from the subroutine rather than a 'resume next' operation.  Resolution:  The DownloadProgramUpdate Subroutine was changed so that all errors that occur in the DownloadProgramUpdate Subroutine cause an exit from the subroutine rather than a 'resume next' operation. 

• CSR: 1778 -- Request:  Add Error Trapping for license and check update routine.  Resolution:  Added Error Trapping for license and check update routine.

• CSR: 1774 -- Request:  Clients who update from an Ascend-HI release preceding version 2.14.31 to either version 2.14.74 or version 2.14.79 will have the SQLSources table mispopulated. The SELECT statements fail to be inserted into the SQLSources table for most reports.  Resolution:  This problem has been corrected in the UpdateHI.exe code's AddSQLSources subroutine. Now, when the client updates from a version older than 2.14.31 to 2.14.85 or higher, the AddSQLSources subroutine first checks whether the the 'SQLSourceLinkRef' column exists in the SQLSources table, and then properly places the report SQL into the SQLSources table based on the result of that check. 

• CSR: 1772 -- Request:  In Ascend-HI version 2.14.79, when a user clicks the View or View Raw Data button to view an entry in the Ebill Transaction Log, an 'Error 6 -  Overflow' message is generated.  When the user clicks OK to the message, the program terminates.  Resolution:  This problem occurs when the claim selected for viewing has a claimref value greater than 32,767. In the cmdView_Click subroutine of the ElectronicTransactions form of the Ascend-HI.exe program, the lClaimRef variable type was changed from Integer to Long, so that it can hold the larger values of the claimref field as the claims table increases in size.

• CSR: 1771 -- Request:  The program hits the database too many times during drug-to-drug interaction checks.  Resolution:  The Order class of the AscendHI.dll program was changed to run the queries against a memory copy of the involved database tables when performing interaction checks, thus reducing the database engine hits to one at the beginning of the process.

• CSR: 1769 -- Request:  Under the Addtional Criteria tab of the Reports screen, there are 4 checkboxes that are used as specific options for the Patient Account Statment report. The labeling and functioning of these options should be changed as described here. One checkbox labeled:'Summarize balances older than 60 days'. One checkbox under the heading: 'Include Only Patients' Checkbox is labeled: 'With a remaining total account balance'. This option causes patient claims to printed only for patients with a balance remaining on their account. Two checkboxes under the heading: 'Include Only Claims' First checkbox is labeled: 'With a remaining claim balance'. This option causes ONLY claims with a claim balance to be printed. Second checkbox is labeled: 'With a remaining patient owed amount'. This option causes ONLY claims with a remaining patient owed amount to be printed.  Resolution:  Under the Addtional Criteria tab of the Reports screen, the bottom three checkboxes were removed and replaced with two groups of two checkboxes for the Patient Account Statement options. The 'Summarize balances older than 60 days' checkbox was left in place.
  Now, the specific options for the Patient Account Statment report are labeled and function as described below.
  One checkbox labeled: 'Summarize balances older than 60 days'. Checking this box causes the report to not show details for claims with balances older than 60 days (no change from previous versions).
  One checkbox under the heading: 'Include Only Patients' 
  The checkbox is labeled: 'With a Total Account Balance'. This option causes patient claims to printed for only patients with a balance remaining on their account.
  Two checkboxes under the heading:'Include Only Claims'
  First checkbox is labeled: 'With a remaining claim balance'. This option causes ONLY claims with a claim balance to be printed. 
  Second checkbox is labeled: 'With a remaining patient owed amount'. This option causes ONLY claims with a remaining patient owed amount to be printed.
  The AccountStatements routine of the Reports form of the Ascend-HI.exe program has been changed. The code that generates the SQL 'WHERE' clause for the Patient Account Statement has been modified to insure that these new options operate as defined. 

• CSR: 1758 -- Request:  In Ascend-HI version 2.14.86, when a user is adding a new item to an order (using the inventory item screen), the inventory items list is not filtering properly.  When a user selects a filter option, the wrong list of items is displayed.  This only occurs if there are inventory groups in use.  Resolution:  Modified the strQual array population code in the Common.FillComboBox routine to account for the DME filtering. 

• CSR: 1735 -- Request:  When viewing the patient profile screen, when the Financials tab is clicked, if the patient has a large number of claims, the amount of time to load the claims onto the tab for viewing can be excessive. In the case where a patient has 700 claims, the screen load can take more than a minute. The speed of loading this tab needs to be improved, since the number of claims on every active patient in the system only increases over time.  Resolution:  Modified the LoadFinancial routine of the Patient Profile screen. Now, the SQL that initially gathers the claims data includes the dates of service for the claim, so that it is no longer necessary to call a separate function to get the dates of service for each claim in a serial manner. This caused the load time of the Financials tab to decrease from 1 minute to 4 seconds when the selected patient has 700 claims.

• CSR: 1713 -- Request:  When a user enters the New Claims (batch bill) screen, as the 'Ready to Bill' tab loads the list of payers/patients on the left of the screen, whenever a payer that has a Payer Name greater than 25 characters is included in the list, an error occurs. Note that the current allowable length of a Payer Name in the Payers table is 50 characters.  Resolution:  This issue was resolved by changing the code in the LoadReadyToBill routine of the New Claims form. The allowable size of the Payer Name in the recordset that holds the value has been increased to allow up to 50 characters. 

• CSR: 1695 -- Request:  Even when a patient that has a valid height in their patient record, The Patient Weight is listed as a possible error on the X12 error page when that patient's claim is included in an X12 E-Bill transmission. In this case, the Patient segement of the X12 is not built. This only occurs when the patient insurance linked to the claim sets the relationship to the insured person as anything but 'Self' (or is left blank).  Resolution:  The X12 object of the AscendHI.dll program was modified to fix this problem. Now, only if the relationship of the patient to the insured person is 'Self' (or blank) AND the patient does not have a valid weight, the potential error will be listed for the X12 transmission and the Patient (PAT) segment is not created. If the patient relationship to the insured person is NOT 'Self' (or blank), the Patient segment is not built.

• CSR: 1689 -- Request:  The Compound Sheet form should include the print date/time in the lower left of the form. Users need to be able to sort the forms by date/time for work flow purposes (First In = First Out).  Resolution:  Modified the Compound Sheet Crystal Reports file to include the print date and time at the lower left corner of the form.

• CSR: 1658 -- Request:  Pumps already marked as In Use and checked out to one patient are having their status get changed to Available (even though no user has manually modified the status.  Resolution:  Modified code in the AscendHI.dll program in the Inventory and Order modules. Also modified code in the Ascend-HI.exe program in the frmDMEMaintenance, frmChanges, frmDMEOrder, Common, frmItem and DisconnectedRecordSets modules.
  The following changes were made relating to DME items:
  Prevent users from using the non-DME order screen to generate a DME item order:
  When a non-DME order screen is used, and the users attempts to add an item to the order, the program no longer allows the user to select DME items as a filter for the list of available inventory items. Also, when a non-DME order is being created, the user can no longer select a filter option to show the DME items on the screen that displays the available inventory items. The DME items do not show in this screen, even when 'No Filter' is selected. This prevents users from using the non-DME order screen to create a DME order with a DME item from inventory.
  Logging of changes:
  When any change related to a DME item’s status or return date is made to an inventory record, the change is saved in memory to the Inventory object, which is then saved. In this way, the changes are logged when the object in memory is saved to the database. The same is now also true for a DME Order and its items. This enables better tracking and troubleshooting of DME item change issues.
  Profile screen:
  When a user right-clicks on a DME order, and then selects ‘Discontinue’, the user is asked for the date to use as the ‘DME Returned Date’. The user is asked separately whether they want to mark the item ‘available’. The program automatically returns the DME item(s) of the order to inventory (the quantity is stock value in the item’s Inventory record is incremented). 
  When the user right-clicks on a discontinued DME order, and then selects ‘Undiscontinue’, the program looks to see the availability the inventory item(s), and if available, removes them from inventory and marks them as ‘In Use’, as well as emptying their ‘DME Returned Date’ field. If any DME item on the order is no longer available (for instance, assigned in the meantime to some other order), the user is informed of the issue, and the order is not undiscontinued.
  DME Order screen:
  Now, when the user changes the status of the order (from within the DME Order screen) to Discontinued, and then clicks the OK button, the software acts the same as if the user had ‘Discontinued’ the order via the Profile screen (described above). 
  Now, when the user changes the status of the order (from within the DME Order screen) to Active, and then clicks the OK button, the software acts the same as if the user had ‘Undiscontinued’ the order via the Profile screen (described above). 
  DME Maintenance screen:
  The DME Maintenance screen now properly filters and displays the DME items, along with their returned date (if any) and status. Now, when a user attempts to make ‘Available’ an item that is already displayed as available, the software does not attempt to change the status. When the user ‘returns’ a DME item using the DME Maintenance screen, the order to which it is linked is automatically discontinued.
  Order Changes Log screen:
  Previously, when a user viewed this log, the displayed activity was limited to the user’s view of their own activity. Now, when a user views this log, all of their own activity. as well as that of all other users who made changes to an order.

• CSR: 1654 -- Request:   There is no option in the product to select which database field to send in the X12 2300 loop, CLM01 field.  The X12/837 specification states: "The number that the submitter transmits in this position is echoed back to the submitter in the 835 and other transactions.  This permits the submitter to use the value in this field as a key in the submitter’s system to match the claim to the payment information returned in the 835 transaction.  The two recommended identifiers are either the Patient Account Number or the Claim Number in the billing submitter’s patient management system.  The developers of this implementation guide strongly recommend that submitters use completely unique numbers for this field for each individual claim."  The field that is currently always being sent in the 837 file by the Ascend-HI program is the patient's account number from the claim record. This number is echoed back on the EOB, but has no value in allowing the user to determine to which specific claim the response EOB is linked.  Recommend providing the user the option of using the Patient ID or the Claim Number in the CLM01 field.  Resolution:  This issue was resolved by adding an X12 setting to the list seen on the Payer screen under the E-Bill X12 tab. The X12 object in the AscendHI.dll was modified to check this setting in order to determine which value to use for the CLM01 field of the 2300 loop. The new setting on the Payer screen under the E-Bill X12 tab is: "X12 2300 Loop CLM01 01 field: Claim Submitter ID"
  This new setting can be left blank or set to 'Patient ID', and that will result in the X12 data containing the Patient ID in the CLM01 field. If the setting is changed to 'Claim Number', then the Claim Number will be placed into the CLM01 field. 

• CSR: 1653 -- Request:  Adding a nursing visit adds a record to the Orders table. The record has the PatientRef, but no RXNumber nor Status. Because the record has no date in the ClaimDate field, the patient shows up in the New Claims screen 'Ready To Bill' list, even though the patient has no actual orders that need billing. The patient's name should not appear in the 'Ready To Bill' list unless actual billable orders exist for the patient.  Resolution:  Changed LoadReadyToBill routine in the New Claims screen to filter out those order records that do not have an RX number and do not have a status value. This eliminates display of order records generated as Nursing Visits and Catheter records (and, therefor won't display those patients who've only got that type of order record). 

• CSR: 1649 -- Request:  In order to remove the need to maintain two separate report SQL storage structures in the database and updates code, The Ascend-HI reports form code must be changed to match the SQL retrieval methods of the Ascend.NET product's report screen.  Resolution:  Modified the Ascend-HI.exe Reports form to retrieve the report SQL using the SQLDescriptions reference, as is done with the Ascend.NET product.

• CSR: 1647 -- Request:  As of May 23, 2008, ANSI X12 claims transmitted for Medicare payers must NOT include legacy IDs (like Medicare number) as part of the 2010AA, 2310A, 2310B, 2420A or 2420E loops.  Resolution:  Modified the X12 object in the AscendHI.dll program to look into the defaults table to determine whether to send the legacy IDs in a MEDICARE X12 transmission. Note that this logic does NOT apply to any claims that are not for a payer with the payer type of 'Medicare'. When the user selects a Medicare claim to e-bill, and chooses the X12 format, the electronic receivers screen pops up to allow the user to select a receiver. A new checkbox is now presented on that screen that allows the user to 'Exclude legacy IDs from X12 transmissions.' If the box is checked, then the legacy IDs for Medicare claims are excluded from the transmissions. The setting for this checkbox is stored in the defaults table (Section ='X12' and Field = 'ExcludeLegacyID') so this setting is remembered each time it is changed. 

• CSR: 1616 -- Request:  The Upsize process (that moves MS Access database information into and SQL Server database) needs to skip recently-added FDB tables.  Recently-added FDB tables do not need to be imported since the import just takes extra time. Those tables should either already be in the SQL Server database, or else the client can run an update after the upsize to get the latest FDB data. Resolution:  The Upsize code has been modified to not import recently-added FDB tables during the process. 

• CSR: 1615 -- Request:  The Upsize process (that moves MS Access database information into and SQL Server database) fails while attempting to populate the Orders table.  Resolution:  A column  named 'Type' exists in the MS Access database Orders table.  Because this field does not exist in SQL Server's version of the Orders table, there was a mismatch of columns between the two tables, so the upsize process failed. Added code to to the Update process to 'skip' this column if it exists in the MS Access Orders table.

• CSR: 1589 -- Request:  If a user accidently runs an old UpdateHI.exe (for either a program update or First Databank update), the update software will update the license expiration date for all facilities with the license expiration date from the old UpdateHI.exe program, even if their license expiration date is currently farther in the future than the one in the old UpdateHI.exe program.  Resolution:  The UpdateHI.exe program's function that sets the license expiration date during an update has been modified to check that the new date is newer than the pre-update date before applying the change. If the existing license expiration date is newer than the new date, then the value is NOT updated to the new date. If the existing license expiration date is older than or equal to the new date, then the value IS updated.

• CSR: 1542 -- Request:  The Payer screen no longer correctly displays Payer Type.  The Payer report also does not show Payer Type. Instead, the Payer report prints the value contained in the 'Box 1' field under the HCFA-1500/UB-92 tab of the Payer screen for that payer.  The Payer report should print the 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 screen 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. Added the PayerTypes.PayerType field to the report’s stored SQL to make it available to the Crystal Report. Modified the Crystal Report file to use the PayerTypes.PayerType field as the source for the payer’s type, rather than the HCFAType description. Added UpdateSequence1221 to the UpdateHI.exe program to modify the stored SQL for the Payer report.

• CSR: 1501 -- Request:  When Primary Payer is set as a required field in the Options screen under the Admission tab, users are still able to enter and save a patient record without entering any payer information. The same issue exists for marking Height as a required field - the patient record can be saved without entering a height value in that field. Resolution:  Changed the Validate routine for the Patient Admission screen to report an empty (or zero value) height when the Height is marked as a required field in the Admission tab of the Options screen for that facility. Also modified the Validate routine to report the lack of a Primary Payer entry for the patient when the Primary Payer checkbox is checked in the Patient Admissions tab of the Options screen for that facility.

• CSR: 1492 -- Request: The TPN calculator undercalculates number of KCal contributed by Lipids. To set up a test:
  (1) Add Intralipid 20% 500ml to inventory.
  (2) Set inventory item Strength = 100gm and Per = 500ml
  (Note, 20% = 20gm/100ml, so 500 ml ==> 100gm)
  (3) Set inventory TPN Group = Lipids
  (4) Set attributes: Calories = 2 KCal/ml
  Lipids = 0.2 Gm/ml
  Non-Protein Calories = 2 KCal/ml
  (5) Create order containing item Intralipid 20% 100gm/500ml
  (Note this is Quantity = 1 for this item)
  (6) On TPN tab, Select [Calculate]
  Results should be: 1000 KCal (e.g 2 KCal/ml x 500 ml)
  100 Gm (e.g. 0.2 Gm/ml x 500 ml)
  The Gm calculation is correct but the KCal calculation for both "Calories", and "Non-protein calories" only comes to 900 when it should be 1000.  Resolution:  When the user alters the Ordered Attribute to be in KCAL (by default the unit will be GM), the calculated amount value is now returned in the form of the unit that was ordered. Previous versions would return the calculated amount in GM (or whatever the default was for the item).

• 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 NCPDPContainer and EBill forms to allow the user to hand-modify the transmission data (after the transmission has been populated, and before an electronic NCPDP transmission is made). Now, if the user checks the 'Preview/Edit Transaction' checkbox, and then clicks the 'Transmit' button on the EBill form, the NCPDPContainer form is displayed. At this point, the unedited transaction is logged into the ClaimsTransactions table as 'Not Sent' (code of 'N' in the TransactionType field). The user can use the NCPDPContainer form to display individual fields in a tree structure, and edit the raw transmission data of the transmission in a scrolling text box. When the user selects 'Save Edited Transaction', the edited version of the transaction is logged into the ClaimsTransactions table as a Sent transmission, and then transmitted. If the user selects 'Don't Save', then the original (unedited) transaction is transmitted. The actual transmitted (edited) message is stored in the table as 'Sent' (TransactionType code of 'S') as soon as the user closes the NCPDPContainer form. 
  The ElectronicTransactions form was modified to sort the list of transactions by LastName, FirstName, ClaimNumber (highest at top), TransactionDate (latest at top) and ElectronicClaimRef (newest at top). This makes it easier to follow the flow of the transactions. The ElectronicTransactions form was also modified to display the transaction type as 'Not Sent' when the code in the TransactionType is 'N'. A checkbox (always starts unchecked) that allows the user to 'Hide Not Sent Transactions'. When this box is clicked (checked), the list is reloaded without the transactions having a TransactionType code of 'N'. Unchecking the box reloads the list with all of the transactions.

• CSR: 1435 -- Request:  Put a 3 of 9 Barcode in the upper right hand corner of the Shipping Receipt report that it would have the Rx Number of the FIRST prescription listed on the report.  Resolution:  Modified the Shipping Receipt.rpt Crystal Reports file to print the bar code, and modified the frmPrintOuts code in the Ascend-HI.exe program to pass the barcode parameter to the Crystal Reports engine when the Shipping Receipt report is run. 
  NOTE: In order for the barcode to print as a barcode, the Free 3 of 9 Extended Regular (TrueType) font must be installed on the printing PC.  This is accomplished by copying the file 'FRE3OF9X.TTF' into the C:\Windows\Fonts folder of the PC.

• 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 secondary 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. If the user selects to apply the credit to the secondary payer, but there is no secondary payer assigned to the claim, a message pops up to let the user choose to apply the credit to the patient, or cancel (not appy the credit at all). 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: 1039 -- Request:  Per ANSI X12 specifications, in loop 2300 there are two qualifiers that can be used in the REF segment. The Ascend-HI product currently only includes one of these ... "9F" (for Referral Number). Ohio Medicaid needs to see both qualifiers in loop 2300.  The second qualifier that needs to be send is "G1" which is labeled in the specification as "Prior Authorization Number".  Resolution:  The "G1" field has been added to the X12 2300 loop just following the "9F" field and just before the "D9" field.  The "G1" field is populated with the Prior Authorization Number value displayed for the PRIMARY payer under the 'Primary Payer' tab of the claims screen for the specific claim being included.  Note that the program does NOT look at the secondary or tertiary payer values for "Prior Authorization Number".  Additionally, two warnings were added to the set of 'potential problems' check for when the claim is being created.  If the claim does NOT have a prior authorization linked to it under the PRIMARY Insurance tab of the claim screen, 'Prior Auth Number' and 'Prior Auth Referral Number' are listed in the potential problems when the claim is being billed via ANSI X12 format. These warnings can be ignored when the prior authorization number is NOT required by the payer to whom the claim is being sent.

• CSR: 644 -- Request:  The Crystal Reports file (FillList.rpt) for the 'Fill List' report needs to be excluded from future releases of Ascend-HI, and the files need to be removed from the client's local and shared folders.  Resolution:  An update sequence (Update20080115) has been added to the UpdateHI program to remove this report file from the Ascend-HI client machines, and this report will no longer be distributed with the Ascend-HI releases starting with version 2.14.85. 

• CSR: 643 -- Request:  The Crystal Reports file (MAR.rpt) for the 'MAR' report needs to be excluded from future releases of Ascend-HI, and the files need to be removed from the client's local and shared folders.  Resolution:  An update sequence (Update20080115) has been added to the UpdateHI program to remove this report file from the Ascend-HI client machines, and this report will no longer be distributed with the Ascend-HI releases starting with version 2.14.85. 

• CSR: 589 -- Request:  A user option should be added to allow the user more flexilibity regarding population of Box 24d of the HCFA-1500 (v1.3) form.  Currently, the user cannot explicitly select an option that causes ONLY the description (preceded by its qualifier) to print in Box 24d.  In all of the currently available options for Box 24d (on the Payer screen under the HCFA-1500/UB-92 tab), whenever the description is printed, the NDC number is also printed.  Resolution:  Modified the Payers screen in the Ascend-HI program. Under the HCFA-1500/UB-92 tab, a new option appears at the bottom of the dropdown list for HCFA Box 24d field. The new option 'With Description' allows the user to explicitly specify this option. Now, the options for HCFA Box 24d act as follows:
  'Default' -- The field is left empty (blank).
  'With Description followed by NDC' -- 'ZZ' qualifier followed by description followed by '   N4' qaulifier followed by NDC number.
  'With NDC' -- 'N4' qaulifier followed by NDC number.
  'With Description' -- 'ZZ' qualifier followed by description.
  NOTE: If a credit has been applied to the claim, the Crystal Reports file code is set to send ONLY the 'ZZ' qualifier followed by the description, regardless of the selection made by the user in the Payers screen for Box 24d.
  Modified the Crystal Reports file for this report to detect the option selected in the Payers screen, and print the values in Box 24d as described above based on the option setting. 

• CSR: 542 -- Request:  The 'Other Meds' edit process is not behaving as expected. (1) When a user tries to edit an existing Other Med entry, if the user does not reselect the name at left side of the screen, the name disappears after the changes are made and saved. For example, if something adding in Notes area; and the user does not first re-select the name at the left side of the screen, the name disappears after the changes are saved.  (2) If the user corrects the name of an item (example: changing from albuterol to proair), the drug name displayed on the screen changes, but any prints of that Other Med (or an edit of the saved record) shows the original drug name -- the change is not made in the database record. Resolution:  This is caused by a click being picked up by the Other Medications Order form when the user double-clicks the order on the Profile screen and their mouse is positioned over the list of drugs on the left side of the Other Medications Order form when it appears. An additional condition has been added to the click routine for the list control on the Other Medications Order form. Now, when a user double-clicks an Other Medications order, regardless of where their mouse is positioned, the item description (name) is no longer blanked out during the process.

• CSR: 459 -- Request:  Electronic claims transaction records (NCPDP format) are currently saved in the database for 30 days.  Most payments do not arrive until 30-60 days after the bill date, and there are often questions about what was transmitted based on the payment received.  If a user needs to review the transmission for a claim payment that was received more that 30 days after the transaction was created, the only way to check is to retransmit the claim (and pay another transmition fee). For that reason, the system should save these records (transmit and response files) for 60 days.  Resolution:  The Ascend-HI product has been hardcoded to retain the NCPDP transmissions in the log for 60 days (changed from the previously hard-coded duration of 30 days).

• CSR: 231 -- Request:  Some new claims created in the system are not visible on Financials tab. Those same claims do show when running the Find Claims function, as well as on some financial reports (such as the Claim Log), but not others (such as the A/R Report). The OriginalClaimRef field is blank in those specific claim records, even though it should be the same value as ClaimRef.  Resolution:  When a new claim is being saved, the OriginalClaimRef is changed in the claims table (set to the value of ClaimRef), but is left at zero in the claim 'object' in memory. If the claim object persists, and the object is re-saved before being destroyed (as occurs in some cases), the OriginalClaimRef is set to zero in the claims table for the claim. Once this occurs, the claim will no longer appear on the patient profile screen under the Financials tab. The Save routine for the Claim object has been changed to also force the OriginalClaimRef to equal the ClaimRef value in the claim in memory (the object). Now, if the claim persists, and is re-saved, the value saved for the OriginalClaimRef in the claim's record of the Claims table will be the same as the claim's ClaimRef value.

• CSR: 164 -- Request:  Running the Patient Account Statement report with the option selected to show only claims with a patient-owed balance (to obtain a list of claims where the patients still owe money), the report still includes claims with a patient-owed balance of zero. Resolution:  Modified the Crystal Reports file for the Patient Account Statement report. Now the report properly calculates the Patient owed balance. Also fixed the issue of an incorrect Patient-Owed value in some claim detail lines. Now calculating the Patient-Owed value by subtracting the amount the patient has paid on the claim (via adjustments and/or receipts) from the amount the patient originally owed on the claim (from the Claims.AmountPatientDue field in the Claims table).  The report still filters out claims with no patient-owed balance when the user selects this option under the "Additional Criteria" tab of the Reports screen prior to running this report.

First Databank Updates

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

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

• HCPC Codes - 11/01/2007