ASCEND-HI -- CURRENT VERSION RELEASE NOTES
Version 2.14.110 (12/24/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: References are provided that show each CSR (CSR = Customer Service Request) related to a released version.
NOTE: This version of the Ascend-HI program works with the following companion program versions:
AscendHI.DLL - Version 1.2.172
UpdateHI.EXE
- Version 1.1.842 (20080423 <-- This is the last
sequential internal update performed by this version)
NOTE: This update was repackaged with the latest First Databank files on 02/09/2009 11:18 AM.
NOTE: This update was repackaged with the latest First Databank files on 03/05/2009 11:11 AM.
NOTE: This update was repackaged with a new product expiration date on 03/18/2009 02:06 PM.
New UpdateHI.EXE - Version 1.1.847 (20080423 <-- This is the last sequential internal update performed by this version)
NOTE: This update was repackaged with the latest First Databank files on 04/06/2009 01:27 PM.
NOTE: This update was repackaged with the latest First Databank files on 05/05/2009 04:31 PM.
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.
Update20080415
' Add the StartingBag field to the Inpatient IV Label SQL ("OrderWithDoses").
Update20080416 ' Add Column "Name" to PatientAddresses"; Change SQL for 'Inventory With Hepatic Impairment' and 'Inventory With Renal Impairment'; Add
these reports as security objects.
Update20080417 ' CSR: 2537 -- Change SQL for the 30-1/30-4 forms.
Update20080418 ' Add "Order Info" SQL to
SQLSources table. Add security object for "Order Info" SQL. Update20080419
' Add "Email" Column to the "Doctors"
table. Add "TPNType" Column to the "OrdersItems" table.
Update20080420 ' CSR: 2545 -- Delete the Inpatient IV Label report file. This didn't work in Update Sequence 20080414. Update20080421 ' Add
"SerumCreatinine", "Patient Serum Creatinine" and "CreatinineClearance", "Patient Creatinine Clearance" criteria for Patients report.
Update20080422 ' CSR: 2671 -- Change the SELECT and WHERE clauses for the Unbilled Orders report.
Update20080423 ' Delete some rows from the ReportCriteriaFields table.
Here is a list of new report file changes
This release Includes the newest version of:
Inpatient IV Label.rpt -- ' Delete the Inpatient IV Label report file. This didn't work in Update Sequence
20080414 (see CSR: 2545).
Shipping
Receipt.rpt --
File
date is 11/14/2008 4:45 PM (See CSR 2486).
Return Receipt.rpt -- File
date is 11/14/2008 4:47 PM (See CSR 2486).
Here is a list of new features and enhancements
CSR:
2636 -- Request: While
performing updates, if the SQL Server database engine is unable to perform
individual record inserts into the DiagnosisCodes table fast enough to keep
pace with the repeated requests made during the ICD9 import process, a
message pops up stating:
"It appears that a connection time-out has occured. This can occur with
very large data table imports performed accross the network. Click Yes to
try again. Click No to skip the rest of the ICD9 Codes import and resume
with the remainder of this update."
When the user clicks the OK button on this message, the same message appears
again. This is repeating at least several times during each attempt to
import the ICD9 codes. If the user clicks the NO button on the
message, then the update resumes without finishing the ICD9 import, but the
file date in the Defaults table for the table is updated anyway (incorrectly
indicating that the ICD9 code import completed).
Resolution:
In the UpdateHI.exe program, added a line of code that runs just prior to the presentation of the warning message. This line pauses the code for 5 seconds to give the SQL Server database engine time to process its full buffer before the message is displayed. This should reduce the number of times that the user must click the OK button. Additionally, the file date is no longer updated in the Defaults table until the ICD9 codes import is completed. If the user encounters the warning message, and then clicks the NO button, the program will not repopulate the file date for the RFMLINM0_ICD9CM_NAME, thereby indicating that the ICD9 codes import was NOT completed. Finally, if the user chooses to NOT proceed with a 'slow' ICD9 import, after clicking the NO to the message, another message appears that informs the user how many records were imported into the table, and that the FDB file will NOT be deleted and the Defaults table entry for that file will NOT have its date changed.
CSR: 2405 -- Request: In order
to send a corrected claim (correction to paid claim, when payment was wrong
amount) via ANSI X12 format, the 2300 loop (claim-level) must contain:
-- A value of 7 ('Replacement of Prior Claim') in in the CLM05.03 field.
-- A REF segment, where REF01 = F8 and REF02 contains the ICN/DCN that was
assigned by the payer to the ORIGINAL claim that is being corrected. Resolution:
In the AscendHI.dll program, modified the X12N class. In the Add2300Loop routine, added code that includes a REF segment with an ID of 'F8' and a field value of the ICN/DCN assigned by the original payer of the claim. This REF segment is only included if there is a value in the 'Box 22' field under the claim-level 'HCFA' tab of the claim screen. The 'Box 22' field contains the ICN/DCN assigned by the original payer of the claim. This is the value that will be used to populate the value in the new REF F8 segment in the 2300 loop.
For a successful resubmission, the 'Bill Frequency' of the claim must be set to a value of 7 (resubmission/replacement of prior claim). The 'Bill Frequency' value is set under the claim-level 'Other' tab of the claim screen. If the 'Bill Frequency' of the claim has a value of 7, and the 'Box 22' field is empty, a problem with the claim "Original Claim ICN/DCN for resubmission" is logged. If the 'Bill Frequency' of the claim has a value other than 7, and the 'Box 22' field is NOT empty, a problem with the claim "CLM05.03 Frequency code <> 7" is logged.
CSR: 2401 -- Request: Change PMP (Cures) narcotics reporting format for NY State to meet with ASAP 2007 (version 4) standards. Resolution: Changed the NarcoticsExport module in the Ascend-HI.exe program. Now, on the Narcotics Export screen, the user can select which ASAP version (1,3 or 4) that will be used for the export.
Here is a list of things fixed
CSR: 2710 -- Request: X12 Bill Loop 2440 not being created when a CMN/DIF form is attached to a claim. Resolution: To fix this issue, the X12N class of the Ascend-HI.dll program was modified. The call to Add2440Loop routine (this creates the 2440 loop) had been temporarily commented out for development testing. Un-commented out the call to the Add2440Loop routine in the Add2310dLoop routine. Also, changed the way the bolIncludeCMN variable is passed to the Add2400Loop routine. It is now passed 'by ref', so that when the Add2440Loop routine is finally called, it can see the ‘true’ or ‘false’ value established in the Add2400Loop routine.
CSR: 2696 -- Request: Customers who use SQL Server 7 as their database engine can have invalid new Rx Numbers generated by the GetNextRxNumber routine of the Order class in the AscendHI.dll program. Resolution: The cause of this appears to be that SQL Server 7 does not work with a 0-based SubString position. When the SubString function of the SQL passed to the SQL Server 7 engine is 1-based, it returns a valid value. SubString 0 and 1 both return the same value with SQL Server 2000 and SQL Server 2005. There is a compatibilty switch that affects the SUBSTRING function but it is not clear is that switch applies to the starting position. Microsoft was moving away from 1 based indexes and having everything 0 based so this issue appears to be the result of a change made by Microsoft between SQL Server 7 and SQL Server 2000.
CSR: 2681 -- Request: Customers submitting claims via Emdeon receive a reject for 'NPI on Ordering Provider Name' in the dispensing fee line of X12 Loop 2420E. When using the Dispensing Fee pricing rule, Ascend-HI does not pull in the Ordering Provider's NPI of X12 Loop 2420E. The program needs to include a default to link the ordering Provider's NPI. Resolution: Condition for checking NPI setting was only checking for Ordering Provider, and was not checking for the Claim Doctor. The program now checks both providers.
CSR: 2623 -- Request: Claim Totals: Claim screen may incorrectly report allowable balance. On a copay claim where credits have been applied to the original claim, if the copay claim has an allowable balance, the balance may not show correctly in the lower right side of the claims edit screen. Resolution: Changed the claim screen to properly display the correct balance if the copay claim has a balance.
CSR: 2622 -- Request: New Receipt/Adjustment Can Incorrectly Report Allowable Balance. When posting a new receipt/adjustment, the claim's allowable balance does not take into account any previous receipts/adjustments whereas the billed balance does. Resolution: The receipt/adjustment process has been changed, and now the claim's allowable balance takes into account any previous receipts/adjustments.
CSR: 2610 -- Request: The X12 batch output includes a G5 segment in 2310A loop when there is no 'pay-to provider' for a claim. The 2310A segment is not supposed to ever contain the G5 segment. Resolution: The Add2310BLoop routine of the X12N module of the AscendHI.dll program was changed. What was happening was that the 2310A loop was generated correctly, but when the 2310B loop (next to be created after the 2310A loop) code found that there was no 'pay-to provider' for the claim, it did not create the NM1 for the 2310B loop. However, since the G5 segment generation code was outside the check for the 'pay-to provider', the G5 segment was generated regardless. This made it appear (in the X12 batch text) that the G5 was being generated for the 2310A loop, when in fact it was being created erroneously as a part of the 2310B loop. The G5 segment generation code has been moved inside the check for the presence of a 'pay-to provider' for the claim. Now, when there is no 'pay-to provider' for the claim, the G5 segment is no longer generated for the 2310B loop.
CSR: 2545 -- Request: Remove the Inpatient IV Label.RPT file from Ascend-HI update packages. Resolution:
Starting with Ascend-HI version 2.14.105, this report has been removed from the
update package. In the UpdateHI.exe program, added the new update sequence 20080420. This sequence code now properly deletes the file in the three target locations:
1. The <server share folder>\Update folder (with filename 'OrdersInpatient IV Label.RPT').
2. The <server share folder>\Crystal\Orders folder (with the filename 'Inpatient IV Label.RPT').
3. The <application folder>\Crystal\Orders folder (with the filename 'Inpatient IV Label.RPT').
CSR: 2486 -- Request: Need to limit the Shipping Notes box under the Shipping Information tab of the Patient screen to a maximum of 35 lines of text. When the Shipping Notes box has over 35 lines of text, there is too much data to print on the first page of the Return Receipt and Shipping Receipt forms. If the condition of over 35 lines of test is true, Crystal will throw an error stating "The page size was not large enough to format the contents of an object in the report." Resolution: Changed the Patient screen's Shipping Information tab. Added a warning note that if the shipping notes generate printed text of more than 31 lines, the remainder of the text will be truncated on the Shipping Receipt and Return Receipt labels. Also, changed the Shipping Receipt and Return Receipt labels' Crystal Reports files. In each, limited the number of lines to which the shipping notes field can expand to 31. This prevents the error that displays otherwise when the shipping notes generate too many lines of printed text.
CSR:
2404 -- Request: Update fails to insert records at a row
level if there are no permissions set up for performing a bulk insert.
Before the 2.14.102 update, if the SQL Server user did not have access to
the share directory to bulk insert the FDB files into the database, the
update would throw a message that it would take more time to complete the
update and continue inserting FDB records at a row level.
This is not the case as of the update to Ascend-HI version 2.14.102. If
there are no permissions to the share from the bulk insert, then the program
now throws an error that says that the user does not have permissions to do
bulk inserts and stops the import of the named file. The update
process continues, but throws additional messages for every table that it
tries to bulk insert, instead to inserting into the database on a row by row
level. Resolution:
In the UpdateHI.exe program, FirstDatabank module, ImportNDDFFile routine, added an error trap for the word 'BULK' as a catch-all in case the SQL Server error message is not an exact match to known bulk insert errors (as was the case here). It appears that different specific versions of SQL Server have slightly varying messages for the same error.
CSR:
1874 -- Request: User is unable to download update from within
the Ascend-HI program (Utilities/Update process). When the user is prompted
to update, based on new current version being available on the web site, and
answered OK to message "There is a new program update available for
download from the Hann's On Software website. Would you like to download
this update?", the download times out. The process appears to proceed
normally for about 10 min, then completes with the error message "It
appears that the update did not download successfully."
Resolution:
The 'It appears that the update did not download successfully' message was displayed because the number of bytes counted as received during the download was less than the expected quantity. The expected quantity is provided in the header information received in the transmission from the server.
Since 1 Kbyte less data was counted than was expected, it appears likely that a 1 Kbyte packet was lost in the process. The fact that the downloaded file size was also exactly 1 Kbyte smaller than the one on the originating server further supports this likelyhood.
This packet loss can be caused by any of the various computers, routers, switches and network hubs involved with the transfer.
As an interim solution, the popup message that warns the user of an unsuccessful download now also displays the number of expected bytes as well as the number of bytes received. This will allow customer support staff to do a 'screen shot' of the message to gather this information.
Additionally, another error-handling routine is now included in the First Databank module. This routine traps errors that are reported by the Internet object during the transfer of the file. If an error occurs during the transfer, a message pops up that informs the user that the Internet connection had a problem during the download, and to please try again later. The message states the number of expected bytes, as well as the number received to that point. It also says that if the same message repeats each attempt, to contact their local technical support. It also states that the user can use an Internet browser to log into the website and download the file that way. This error is logged into the errors table before the user is returned to the Ascend-HI Profile screen.
These changes should allow the support staff to better collect the conditions of the failure should this occur again.
CSR: 445 -- Request: The Facilities tab on the Reports screen is not refreshed when switching facilities in the program. When a user selects the Switch Facility option within the Ascend-HI program to change to a new facility, and then opens the Reports screen, the prior facility is still checked under the Facilities tab of the Reports screen. Resolution: Added a block of code in the LogIntoFacility function of the Profile screen to reset the Reports screen facilities list based on the facility into which the user is currently logged. Note that, with this solution the user can now leave the Reports screen open when switching between facilities, and the Report screen's facilities list will still change its settings to match with the facility into which the user is now logged.
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 upper right-hand side of the
ABOUT screen, the date is displayed as: First Databank Current as of
4/30/2009
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