ASCEND-HI -- CURRENT VERSION RELEASE NOTES
Version 2.14.90 (5/05/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.1432
UpdateHI.EXE - Version 1.1.824 (20080119 <-- 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.
Update20080116 ' Add "DispensedByRef" field to
"OrdersScheduleTimes" table for tracking who charged a dose.
Update20080117 ' Add various indexes to tables to enhance database query performance.
TABLE (INDEX):
AdjustmentTypes (FacilityRef)
AllergyReactions (FacilityRef)
CatheterBrands (FacilityRef)
ClaimChanges (ClaimRef)
ClaimStatuses (FacilityRef)
ClinicalReviewLookups (FacilityRef)
CMNs (PatientRef)
Distributors (FacilityRef)
ElectronicReceivers (FacilityRef)
FileLinks (FacilityRef)
FileLinks (PatientRef)
InventoryPricing (FacilityRef)
InventoryTransferTypes (FacilityRef)
MARSections (FacilityRef)
OrderChargeMethods (FacilityRef)
PatientTypes (FacilityRef)
Referrals (FacilityRef)
Rooms (WardRef)
SigCodes (SigCodeListRef)
SigCodesLists (FacilityRef)
Suppliers (FacilityRef)
Wards (HospitalRef)
Update20080118 ' Added Doses Dispensed Report SQL
to the SQLSources table.
Update20080119 ' Fixed the Delivery Receipt SQL.
Here is a list of new features and enhancements
CSR: 1877 -- Request: Purging patient does not remove order history from inventory control. When a patient is purged, the order history from inventory control should be removed as well. Resolution: Modified the 'Delete' Subroutine in the Patient class of the AscendHI.dll program. Now, when a patient record is purged, for each order linked to the purged patient, the program deletes all records in the InventoryControl table where the OrderRef value is equal to that order.
CSR: 1859 -- Request: When a changed claim is saved, if the claim has associated ClaimsItems records with a NULL value in the IncentiveFee column, the claim's amount billed and amount due values are incorrectly calculated as zero, and then saved with the claim record. This includes any case where the claim is saved after a change is made to the claim object, such as when responding 'Yes' to a query to lock the claim after receiving a Paid NCPDP response. Resolution: Whenever a changed claim record that has a NULL value in the IncentiveFee column of one of its related ClaimsItems records is saved, the AmountBilled and AmountDue columns of the related Claim record are set to zero. The affect of having a NULL (instead of zero) value included in a mathematical calculation is that the result of the calculation is always zero. To resolve this issue, the AscendHI.dll program was changed to now resolve NULL numeric values to zero before including those values in the mathematical calculation of the AmountBilled and AmountDue values that are placed into the Claims record as a changed claim is being saved.
CSR: 1827 -- Request: Currently,
the Ascend-HI update program (UpdateHI.exe) does not have subroutine-level
error handling in the following routines:
ServerChanges
ImportHCPCSFeeSchedule
ImportHCPCNDCCrosswalk
ImportNDDF
TruncateSQLLog
Need to add local error handling to these routines to assist in
troubleshooting when an error occurs during the update process. Also, when
an error occurs during the updating of the database structure (in the
sequential update routines), the update process needs report the error and
stop the update that point(do not proceed to the next update sequence or go
any further at all with the update process. Resolution:
Added local error handling routines in the following subroutines of the UpdateHI.exe program:
ServerChanges
ImportHCPCSFeeSchedule
ImportHCPCNDCCrosswalk
ImportNDDF
TruncateSQLLog
Additionally, added enhanced messaging to the Update sequence error handling routines. Now, when an error occurs during a sequential update routine, an error message is presented, and the user is informed that the update will not proceed. Additionally, the user is informed that the 'LastUpdated' value in the Defaults table represents the most recently completed error-free update sequence, and that the update sequence following that one is the routine that encountered the error. This was done to decrease troubleshooting time in such instances.
CSR: 1753
-- Request: When
sending ANSI X12 electronic Worker's Compensation claim, the CLM 11 fields
(Related Causes Information) of Loop 2300 should be populated if the user
checked the option in the Claim screen to indicate the reason for treatment
is employment-related, automobile accident-related or other
accident-related. Resolution:
In the X12 class of the AscendHI.dll program, modified the 2300 loop generation code to include (immediately following the CLM 10 segment) the following (based on the entries under the HCFA tab for the claim):
If the checkbox for 'Employment' is checked, then the CLM 11-1 segment is created with a value of 'EM'.
If the 'Employment' checkbox is NOT checked, and the checkbox for 'Auto Accident' is checked, then the CLM 11-1 segment is created with a value of 'AA'. In this case, the CLM 11-4 segment is also created (immediately following the CLM 11-1 segment. The CLM 11-4 segment contains the two character state abbreviation for the accident state selected under the HCFA tab of the claim screen for the claim.
If the 'Employment' checkbox is NOT checked, and the checkbox for 'Auto Accident' is NOT checked, and the checkbox for 'Other Accident' is checked, then the CLM 11-1 segment is created with a value of 'OA'.
CSR: 1039 -- Request: Per ANSI X12 specs, in loop 2300 there are two qualifiers that can be used in the REF segment. Currently only one is used (9F for Referral Number). Ohio Medicaid needs to see both qualifiers in loop 2300. The other qualifier is "G1", which is labeled "Prior Authorization Number". Resolution: The G1 Ref field (Prior Authorization) is now being generated in the 2300 loop of the X12 batch (only when a prior authorization is selected on the claim). The G1 Ref field immediately follows the 9F Ref field in the 2300 loop. Note that the 9F Ref field is still generated containing the Prior Authorization number (only when a prior authorization is selected on the claim).
CSR: 519 -- Request: The 2310A loop in the ANSI/X12/837 batch file is currently being populated with information related to the 'Ordering' Doctor (from the order related to the claim). The ANSI/X12/837 specifaction states that this loop should be populated with the 'Referring' Doctor's information (from the claim itself, as seen on the General tab of the Claim screen). When a client is billing on behalf of another Doctor, the claims are submitted on behalf of the 'Referring' Doctor. Resolution: The code of the X12 class in the AscendHI.dll program was changed to now populate the 2310A loop of the ANSI/X12/837 batch file with the information of the physician selected in the 'Referring Doctor' field under the General tab of the claim screen. Note that the reference value that points to the Referring Doctor is stored in the DoctorRef field in the Claim record.
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
5/01/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