ASCEND-HI -- CURRENT VERSION RELEASE NOTES
Version 2.14.74 (11/14/2007 )
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.1404
Originally packaged with UpdateHI.EXE - Version 1.1.807 (20061228 <-- This is the last sequential internal update performed by this version)
** REPACKAGED with a new version of the Patient Account Statement report on 12/10/2007 @ 2:16 PM.
** REPACKAGED on 12/10/2007 @ 2:16 PM with a new version of the UpdateHI.exe program Version 1.1.810 (20071130 <-- This is the last sequential internal update performed by this version)
** REPACKAGED with a new version of the First Databank files on 12/10/2007 @ 2:16 PM (First Databank data date: 11/29/2007).
** REPACKAGED with a new version of the First Databank files on 1/4/2008 @ 2:08 PM (First Databank data date: 12/27/2007).
** REPACKAGED with a new version of the First Databank files on 2/6/2008 @ 9:17 AM (First Databank data date: 1/31/2008).
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.
Update20061225 ' For various reports, add specific WHERE clauses to SQLSources table.
Update20061226 ' Change the way 'Catheter Types' values are stored in the LookupValues table.
Update20061227 ' Modify the SQL stored in the SQLSources table for the MAR report.
Update20061228 ' Add the 'DelayReason' (TINYINT) column to the Claims table for use with the CMN 03.02 form.
Update20071127 ' Update the SQL for the FILL LIST report.
Update20071128 ' Update Inventory NDC lookup values in the ReportCriteriaFields table.
Update20071129 ' Update Inventory UniqueId lookup values in the ReportCriteriaFields table.
Update20071130 ' Delete the 'Patient Chart Label.rpt' from the server and client locations.
Here is a list of new features and enhancements
CSR: 1381 -- Request: The New Receipt screen needs to have the ability for the user to select for whom the adjustments are being made. Currently, the user selects Payer or Patient on the 'Receipt' (left) side of the screen. This only selects for whom the receipt is posted. The adjustments on the screen are always posted to the patient. What is needed is the ability to select for whom each of the two adjustments on the screen are posted (Payer or Patient). The selection for each of the adjustments should be 'sticky' (remember what its last selection was), so when the user re-opens the screen, the selections are the same as the last time the screen was used. Resolution: The New Receipt screen now provides the ability for the user to select for whom the adjustments are being made. A new dropdown is now presented on the screen for each of the adjustments. This dropdown allows the user to select whether the adjustment is being applied to the patient or the payer.
CSR: 1224 -- Request: The requirements state that a 90 day indicator should be placed in the 2300 loop, CLM segment, and 20th element per 837P specifications. Resolution: The DelayReason field was added to the database in the Claims table. DLL updated to store the field and transmits the field in 837P claims. Ascend-HI will not have a drop down where Ascend .NET will have the lookup values in a drop down on the 'Other' tab in the claim. In Ascend-HI, the user enters a value between 1 and 11. This number should be appended to the CLM segment in Loop 2300 of the claim.
CSR: 1367 -- Request: The Ascend-HI Interface logs every change of a date format, even if the same date is still represented. For example, every time an ADT (admit) message is received through the interface for an existing patient, an entry is added to the patient log of changes (PatientChanges table) showing that the patient's DOB has changed. The entry is logged that the DOB field changed from "6/1/1924" to "1924-06-01" (the same date, but different format). These unnecessary date-related entries need to be prevented. Resolution: The DLL program was changed to normalize dates before attempting to compare them. Now, regardless of the entry format, if a date in the Patient record still represents the original date, then an entry in the Patient's change log is NOT made.
CSR: 1090 -- Request: The First Databank file SPEMMOE1_SPNSH_MONO now has more than 76 bytes in some of the PEMTXTE field entries. This causes a 'Bulk Insert' error during the Ascend-HI FDB update process. The result is that not all of the Spanish Monograph information is properly imported. Resolution: The final solution was to change the Code in the UpdateHI.exe program to define the appropriate 'Code Page' value for the SQL Server engine in the bulk insert statement. This eliminated the need to resize the database fields.
CSR: 1084 -- Request: When a user enters Serum Creatinine in the Patient screen, the prompt box for entering Creatinine clearance has the word 'Calculate' misspelled. Resolution: The word 'Calculate' in the prompt box has been changed to the correct spelling.
CSR: 966 -- Request: The Location designation is not being filled in on all DME orders, so the user cannot run DME reports by location and get a consistent, fully accurate report. Resolution: Modified the LoadOrder subroutine of the DMEOrders form in the Ascend-HI.exe program to pre-assign a value to the new DME order's FacilityLocationRef. If the patient's FacilityLocationRef value is null or zero at the time the DME order is created, then the order will save with a zero in its FacilityLocationRef field. Otherwise, the patient's FacilityLocationRef value is assigned to the order's FacilityLocationRef. In this way, as long as the patient has a location assigned BEFORE the DME order is created, then the DME order record will be saved with the same location.
CSR: 422 -- Request: The facility ID number (Contract number) should appear in any drop-down list where you select the facility ID. Example: When adding Doctors to Ascend while in All Facilities mode, it would be easier (and less prone to user entry errors) to have the facility ID number display in front of the facility name in the dropdown list so the user can easily distinguish between facilities with names that start with similar spellings. Resolution: Modified the Doctors (Physicians) form to populate each row in the list of the facilities selection dropdown with the ID of the facility, followed by its name (just as is done in the facility selection dropdown when logging into a multi-facility environment).
CSR:
168 -- Request: Need the system to recognize and
"act on" start/End dates of listed Insurance. 1) Show only those
Primary active insurance info. 2)"Archive" insurance coverage that
is no longer valid. Resolution: Please see the
solution stated for release 2.14.63. Added a
conditional statement in the BillOrders routine of the Profile form that
sets the value of the 'l' flag (when only one Primary Insurance is available
for a Patient). Previously (in the solution of version 2.14.63), this
value would be left at zero, causing the erroneous presentation of a popup
message, and preventing the billing process from completing when only one
Primary Insurance is available in the Patient Insurance records for the
patient.
Here is a list of things fixed
CSR: 1307 -- Request: Per conversation with NY Medicaid Help Desk staff person (Stephanie), the NCPDP transaction must physically have the EU field (Prior Auth type code) precede the EV field (Prior Auth number). Resolution: Modified the NCPDP transmission code so that it now places the EU field ahead of the EV field.
CSR: 1356 -- Request: The software is not allowing the user to attach a CMN 03.02 form to a claim for electronic transmission. Medicare is not allowing any paper CMN's to be submitted any longer. However, Medicare verified that that they are accepting the CMN 03.02 forms electronically. The product needs to allow the user to send the CMN 03.02 in an electronic transmission, so the user needs to be able to attach the form to a claim. Resolution: The ability to attach the CMN 03.02 form has been added to the Claim screen. The data from the attached form will be included in the electronic transmission of the claim.
CSR: 1316 -- Request: When a user clicks the 'Orders Not Billed' radio
button in the Profile View area of the Profile screen, an error is presented
(Run Time Error 387), and then the program terminates when the user clicks
OK. Resolution: When the user clicks on the 'Orders Not Billed' radio button in the Profile View area of the Profile screen, the Profile form code no longer attempts to mirror the action in the view-filtering selection in the Orders View/Sort menu. This is because the 'Orders Not Billed' view filtering option is NOT available in the Orders View/Sort menu.
Now, when the user clicks on the 'Orders Not Billed' radio button in the Profile View area of the Profile screen, the check marks are removed from the Orders View/Sort menu items 1 - 7 (Active Orders through DME Orders), and the list of orders presented is filtered to the orders that are not billed.
CSR: 1269 -- Request: If no answers for questions 1-7 are provided on the DME 10.03 screen form, when the form is printed, or checked in Print Preview, all options for questions 2, 5, 7 and 9 are circled. This should not occur. Resolution: Modified the DME 10.03 Crystal Reports form code to check for a null value returned for each answer. When a null value is returned, the form now does not circle the answer.
CSR: 1261 -- Request: When running server updates for new clients, the routine that renames and copies the Crystal files into the Crystal directory in the server folder is failing. It creates the Crystal folders correctly, but does not copy the individual files into the Crystal sub-directories. Resolution: The cause of this problem was that a test version of the Update.frm file was unintentionally included in the Update package. The Update.frm file in the Update package has been restored to the production version.
CSR: 1246 -- Request: When in the Patient Profile screen, when a user follows the top menu path to select Orders->Orders View->DME Orders, the orders list view does not change to display only DME orders. Also, the DME 'radio button' selection in the 'Profile View' area of the screen does not automatically get selected. Instead, the Profile View radio button that was already selected remains selected. This is not how it works for all of the other selections in the Orders->Orders View-> submenu. Resolution: In the code for the Orders->Orders View-> submenu, changed the DME selection action to act the same way as the rest of the selections in that submenu. Now, when the user selects Orders->Orders View->DME Orders, the orders list view changes to display only DME orders. Also, the DME 'radio button' selection in the 'Profile View' area of the screen is automatically selected. In release 2.14.66, added code to the 'radio button' group in the 'Profile View' area of the screen. Now, after a user selects the view using the radio buttons, the next time the user pulls down the Orders->Orders View menu, the same view item is checked in the menu when it is displayed. Also added code to insure that the DME check-mark on the pull-down Orders->Orders View menu is cleared properly.
CSR: 1227 -- Request: When attempting to print the 31 Day Mar report, an error is being generated. Resolution: This error is occurring due to the fact that the newest CRUFLNET.DLL program was not included in the release package. The new MAR 31 Day report relies on a custom function only available when the CRUFLNET.DLL is registered. Repackaged the CURRENT and BETA releases of Ascend-HI with the newest version of the CRUFLNET.DLL (version 1.0.0.224, file dated 8/15/2007 11:58 AM). When a client updates again with the new package, the CRUFLNET.DLL will automatically be registered. This eliminates the error.
CSR: 1171 -- Request: Group security
settings are supposed to prevent remote site pharmacists from entering
orders with Multi-facility Rx counters, but these pharmacists are entering
new fills and refills with these counters. Resolution: The Orders menu is now modified so that if the user selects the Copy, Refill, Discontinue,
Un-discontinue or Replace options in the Orders menu, the program checks to see if the user has security permissions that allow access to the order type (based on its link to an RX Counter in the Order Types form). If the user does NOT have security permission for the RX Counter to which the order type is linked, then a message is presented that informs the user that this action is not allowed.
The list of orders that appears under the tabs of the Batch Verify/Pending/Confirm/Refill/Print are now filtered to only those orders with an order type that is not linked to an RX Counter to which the user does not have
permission.
When a user selects an EXISTING order to edit, the list of order types presented in the 'Order Types' drop-down menu is NOT filtered by RX Counter permissions. However, if the user attempts to change the order and save it (or create a new order) with an order type linked to an RX Counter to which the user does not have permission, the action is prevented, and the user is presented a messages indicating that their security permissions prevent the action.
When a user creates a NEW order, the list of order types presented in the 'Order Types' drop-down menu IS filtered by RX Counter permissions. This prevents the user from selecting an order type linked to an RX Counter to which the user does not have permission.
CSR: 1169 -- Request: If no Pricing Rules are set for a Pricing Template (Contract), when that Pricing Template is selected while billing an order (creating a claim), an error occurs. The error states that the database record has been deleted or the end of file (EOF) has been reached. Resolution: When no Pricing Rules are set for a Pricing Template (Contract), and that Pricing Template is selected while billing an order (creating a claim), the LoadClaim function in the Claim form now checks to see first whether the end of the records is reached. If it is, then the program steps over the code that expects to derive the pricing rule reference value from the database, and instead populates the value with a a zero. This eliminates the error.
CSR: 1166 -- Request: Patient Claim Report is printing inaccurate Patient Paid and Patient Balance values when there are patient-specific adjustments applied to the claim. Resolution: The Crystal Reports file for the Patient Claim report was modified to include the patient-specific adjustments in the Patient Paid and Patient Balance fields. A related issue showed up when this solution was implemented. The 'Adjustments' entered in the New Receipts form were posted to the database as records WITHOUT the Payer reference number, even though the user had selected 'Payer' in the dropdown on the form (the receipt information on the form was creating records properly populated with the payer's reference number). This made the records appear as 'Patient' entries, and were being used when calculating the Patient portion of the claim vs. the Payer portion. This has been changed in the New Receipts form. Now, when the user selects 'Payer', both the receipts and adjustments are recorded properly (with the proper Payer reference if the user has selected 'Payer' in the dropdown, or with a Payer reference of zero if the user has selected 'Patient' in the dropdown).
CSR: 1159 -- Request: The DME 484.03 form does not fill in the Length of Need. It also does not circle the answer for Question 2, when the answer is 1 (one). Resolution: Modified the Crystal Reports file for the DME 484.03 form. The form now prints the Length Of Need in months. The form also now prints the circle around the 1 character in the answer to question number 2 if the user selected the 1 option as the answer to the question when editing the screen form.
CSR: 1158 -- Request: NDC-HCPC Import not updating Inventory. Resolution: Corrected the code in the Ascend-HI program to insure that the NDC-HCPC Import properly updates the Inventory.
CSR: 1142 -- Request: Some drug names are treated as SIG codes when entered in SIG areas (Patient Instructions and Doctor Instructions fields in a prescription Order screen). For example, when a user enters the drug name Xopenex in the SIG area of a prescription, the program changes this to "Stop after openex". Using another drug name that starts with the letter "X" (Xeloda) has similar results. This appears to be an issue with drug names that start with the letter "X". Resolution: The code in the Order class of the AscendHI.dll program that interprets SIG codes has been modified. Interpreting ' X' as meaning ' stop after' now requires a space after the letter X in order to apply the interpretation as a SIG code. For example, ' X 7 Days' will be interpreted as 'stop after 7 days', but 'X7 days' would not be expanded. This rule will prevent drug names starting with X from being interpreted and expanded as SIG codes when entered into the Patient Instructions or Doctor Instructions fields in a prescription Order screen.
CSR: 1113 -- Request: When running the Patient Account Statement report, client found that she was getting all of her patient reports when filtering for a specific Patient Status. I tested this on version 2.14.62 and could replicate this issue. Resolution: Added code to handle the filtering of the Patient Account Statements report by Patient Status.
CSR: 1043 -- Request: When the user sets (in the Options screen) box 28 to
show 'Continued Until Last Page', when printing multi-page CMS1500 forms,
the word 'Continued' should print in box 28 for all but the last page of a
multi-page claim. If the claim prints on one page, box 28 shows claim
total. However, when the Batch process is used to print multiple
claims at one time, the word "Continue" prints on all pages but
the last page of the batch print (the last page of each claim in the batch
should have the claim total printed in Box 28). Resolution: Modified the Crystal Reports file for the HCFA 1500 (v1.3)/CMS1500 form. Added code to Box 28 to check for the end of claim condition. Also Added code in the section footer to reset the claim amounts at the end of the claim.
If it IS true that the end of the claim has been reached (and the default settings are set to print 'Continued Until Last Page'), the claim total amount is printed in Box 28. After this is accomplished, the claim amounts are reset to zero.
If it is NOT true that the end of the claim has been reached (and the default settings are set to print 'Continued Until Last Page'), the word "Continued" is printed in Box 28. In this case, the claim amounts continue to
accumulate.
CSR: 1105 -- Request: When sending electronic bills using ANSI X12 format, claims are rejected for not including a Taxonomy Code (PRV segment, 2000A Loop). This occurs when both the Billing Provider and Pay To Providers fields in the Top HCFA tab of the claim are populated. Resolution: Normally, the Pay To Provider field is populated by the user only when it is different than the Billing Provider. In that case, the only place where the PRV segment (Taxonomy code) should be sent is in the 2310A Loop (and this is what the program does in this condition). The AscendHI.dll code was changed to accommodate the case where these two fields are both populated, but with the same value. The X12 class now sends the PRV segment (Taxonomy code) in the 2000A loop if both the Billing Provider and Pay To Provider field are populated in the Top HCFA tab on the claim, and the Pay To Provider is the same as the Billing provider. Note that the Taxonomy code of the Pay To Provider is always included in the 2310A Loop whenever the Pay To Provider is selected, unless it is the same as the Billing Provider.
CSR: 1097 -- Request: Some meds are being dispensed by residents (interns) or nurse practitioners at the teaching hospital and these medical personnel do not have NPIs. Staff at Medicare Region B Help Desk state they will process the ANSI X12 electronic claim if UPIN is sent (which Ascend-HI is doing by default). However, the transaction build logic still sets NM108 field (Identifier) to "XX", meaning NPI, even when NPI field (NM109) is blank, causing a reject for missing NPI. Resolution: Modified the function in the AscendHI.dll's X12 class that generates the X12 NM1 segment. Now the function checks to see that both the ID Qualifier (NM108 field) and ID (NM109) field are present. If either field is empty, the other field is also emptied so that it will not be included in the segment.
CSR: 1093 -- Request: When a user attempts to go into Pricing Contracts (Under Utilities), an error message is generated and the user cannot get into that screen. The error message states: 'Item cannot be found in the collection corresponding to the requested name or ordinal.'. Resolution: The PricingRules class in the AscendHI.dll program was modified to no longer look for the field names that were generating this error.
CSR: 1089 -- Request: When sending claims with a DME 484.3 form attached, the program is not including the 'LQ' (Form Identifier) segment for the DME 484.3 form that is being attached. It is, however, sending the 'FRM' segments for the form. The X12 loop involved is 2440. The LQ element and identifier are missing and are required for the claim to get accepted for Region C. Resolution: Changed the X12 class in the AscendHI.dll program to include the LQ segment that identifies the attached form as '4843' when the DME 484.3 form is attached to the claim. Also modified the code to properly generate data from the DME 484.3 form into additional fields.
CSR: 1086 -- Request: Inventory pricing rules are not working properly. Some items are skipped, and the rules themselves don't appear to be working. Resolution: The problem has been corrected by changing the code in the AscendHI.DLL program. This solution applies to both the Ascend-HI and Ascend .NET product. NOTE: This issue was never exposed to any Ascend-HI users, so this CSR's information will not be included when the release goes to BETA.
CSR: 1068 -- Request: When viewing the Financials in the Patient
Profile screen, the 'Financials' dropdown menu (under the 'View' menu
option), provides the view filtering available for the screen. Currently,
the user can only select one filtering option related to the status of the
claims. Either 'All Claims' can be chosen, or any one of 'ACTIVE (Unlocked)
Claims', 'LOCKED Claims', 'CANCELLED Claims', 'UNPAID Claims' or 'PAID
Claims'. The user should be able to select either 'All Claims' or any
combination of the other filter selections. Selecting 'All Claims' should
show all claims for the selected patient (including CANCELLED claims), and
should automatically deselect all of the other filter options. Selecting any
of the specific filters should automatically uncheck the 'All Claims'
option. Selecting any one or more than one of the specific filters should
immediately make that/those type(s) of claim be visible in the list of
claims. Clicking on an already-checked selection should uncheck the
selection, and immediately remove that type of claim from view in the list
of claims. Resolution: The Ascend-HI.exe program has been
changed so that:
When viewing the Financials in the Patient Profile screen, the 'Financials'
dropdown menu (under the 'View' menu option), provides the view filtering
available for the screen. The user can now select either 'All Claims' or any
combination of the other filter selections. Selecting 'All Claims' shows all
claims for the selected patient (including CANCELLED claims), and
automatically deselects all of the other filter options. Selecting any of
the specific filters automatically un-checks the 'All Claims' option.
Selecting any one or more than one of the specific filters immediately makes
that/those type(s) of claim become visible in the list of claims. Clicking
on an already-checked selection un-checks the selection, and immediately
removes that type of claim from view in the list of claims.
CSR: 1043 -- Request: When the user sets (in the Options screen) box
28 to show 'Continued Until Last Page', when printing multi-page CMS1500
forms, the word 'Continued' should print in box 28 for all but the last page
of a multi-page claim. If the claim prints on one page, box 28 shows
claim total. However, when the Batch process is used to print multiple
claims at one time, the word "Continue" prints on all pages but
the last page of the batch print (the last page of each claim in the batch
should have the claim total printed in Box 28). Resolution:
Modified the Crystal Reports file for the HCFA 1500 (v1.3)/CMS1500 form.
Added code to Box 28 to check for the end of claim condition. Also Added
code in the section footer to reset the claim amounts at the end of the
claim.
If it IS true that the end of the claim has been reached (and the default
settings are set to print 'Continued Until Last Page'), the claim total
amount is printed in Box 28. After this is accomplished, the claim amounts
are reset to zero.
If it is NOT true that the end of the claim has been reached (and the
default settings are set to print 'Continued Until Last Page'), the word
"Continued" is printed in Box 28. In this case, the claim amounts
continue to accumulate.
CSR: 1038 -- Request: Colorado state Narcotics reporting (CURES) is failing because the requirement for 'Refills Authorized' is 2 characters in positions 117 and 118, even if there is less than 10 refills (i.e., use 01 for the value of one). Currently the Ascend-HI program is filling Positions 117 and 118 with the correct number of refills, but is populating position 117 with a single digit and position 118 with a space when the quantity of refills is less than 10. Resolution: Modified the Ascend-HI.exe program (Narcotics Export class) to pad the Refills Authorized field with leading zeros. If a null or zero value is found for the Refills Authorized, then positions 117 and 118 will be "00". If a value >0 and < 10 is found for the Refills Authorized, then position 117 will be filled with the "0", and position 118 will be filled with the "n", where n = the number of refills (0-9). If a value >9 and < 100 is found for the Refills Authorized, then positions 117 and 118 will be filled with the two-digit number of refills (10-99). If a value > 99 is found for the Refills Authorized, then positions 117 and 118 will be filled with "99".
CSR: 1035 -- Request: When attempting to print preview or print the HCFA-1500/CMS-1500 (when using an MS Access database), an error occurs that states there are 'Too many fields defined.' This results in a chain of errors, and an empty form. This error only occurs if the client is using the MS Access database. It does NOT occur when the client is using an SQL server database. Resolution: This is caused by the SQL for the form defining 260 fields in its query string. MS Access restricts the number of fields defined in a query to 255. The SQL has been modified to specify only 255 fields in the query string. This eliminates the error when using MS Access as the database. Note that SQL Server databases do not have this restriction, and therefore would not have generated this error.
CSR:
1018 -- Request: The new CMS1500 (v1.3)/CMS-1500
form has the payer name and address section (at top of form) positioned
differently than the previous versions of the form. This causes the
name and address not to appear properly in envelope windows when clients use
certain windowed envelopes for mailing printed forms to payers. The payer
name and address section (at top of form) has been moved 1/4" to the
left, cutting off the first 3-4 characters of each line. Resolution:
Repositioned the Payer's name/address block at the top of the form using the
same coordinates as were used in the earlier versions of the form. The
block's coordinates are now: X: 3.610, Y:0.250, Height: 0.730, Width: 2.660.
CSR:
1014 -- Request: When working in an order's
screen, when the user clicks on the Patient Instructions or Doctor
Instructions field, tabbing out of the field inappropriately forces all of
the text in the text box to upper case. Resolution:
The change to upper-case of the Patient Instructions and Doctor Instructions
of an order was due to a new comparison function in the SIG codes routine of
the AscendHI.dll program. The code was changed to return the (non-SIG code)
text to its original case after the comparison is completed.
CSR: 1012 -- Request: When printing some custom reports, Errors are
encountered.
(1) -2147217900 Description: Line 1: Incorrect syntax near 'tablename';
Location: clsPrinterDefaults_OpenReport. (NOTE: 'tablename' is the name of one of the tables used for
the report).
(2)Error 3704 Operation is not allowed when the object is closed; Location:
clsPrinterDefaults_OpenReport.
(3)There are no records to print in this report. Resolution:
Modified the code to handle ORDER BY clause in a custom report's '.SQL'
file. The code had been altered a few months back to filter on multiple
facilities but had not been run against a test report with a custom order by
clause.
CSR: 1007 -- Request: When a user sets the option in Pricing Rule to create a per diem charge line for each day on the claim, no per diem charge line is created for the final day of the fill date range. A per diem charge line for the final day of the fill date range should be included in the claim. Resolution: Modified the CalculatePrice subroutine in the Claim form of the Ascend-HI.exe program. Changed the part of the routine that adds per-diem charge lines for each date of service. The routine now includes the Fill Stop date when adding per-diem charge lines to a claim.
CSR: 993 -- Request: Previously, the Home Health Agency report had a blank line between entries, making the report easier to read. The current version has no blank lines between entries, and is therefore more difficult to read. Resolution: Modified the Crystal Reports file for the Home Health Agency report to once again include a blank line between entries.
CSR: 974 -- Request: The Patient Account Statement report needs to include both County (local) and State taxes added together. Currently, only the county tax is being printed in the Tax row. Resolution: Modified the SQL (in the Ascend-HI.exe program) for the Patient Account Statement report to sum the state and local (county) taxes into the single tax field before it is passed to the Crystal Reports engine. The value printed in the Tax row for each claim in the Patient Account Statement is now the sum of the state and local taxes.
CSR: 921 -- Request: When a user
attempts to delete a received item from a Purchase Order, a message is
presented asking if the user wants to update Inventory Control. However, if
the item on that lot has been dispensed (meaning that lot appears on an
order), the system does not delete the item from Inventory control, though
it appears the deletion did occur. There needs to be some kind of message
stating that the deletion cannot occur since the item has been dispensed.
See also related CSRs 621 and 629. Resolution: The code of the Purchase Order form has been changed to first check whether the PO item has any quantity received before honoring the user's request to delete a PO item. If so, then the user is presented a message stating that the PO item cannot be deleted because at least some quantity of it has been received.
Additionally, if any order item references the PO item, then the user is presented a message stating that the PO item cannot be deleted because an it is referenced by an order item.
If conditions do allow the PO item to be deleted, its record in the Inventory Control table is
deleted.
CSR:
791 -- Request: At the bottom of the MAR 31 day
report, there is an area for listing the allergies and diagnosis.
However, the allergies and diagnoses (from the patient's profile) are not
populating on the report. Resolution: The report SQL
and Crystal Report file have been modified to populate the diagnoses and
allergies from the patient's profile information in the database.
CSR: 629 -- Request: If an item on a Purchase Order was marked as received in error, and that item is then removed (deleted) from the PO, the Inventory Control entry is removed from Inventory, but the Quantity On Hand is not recalculated (decreased). Resolution: First, the solutions were implemented for CSRs 621 and 921. The result of that implementation is that a Purchase Order item can not be deleted unless the received amount for that item is equal to zero. When the user changes the received amount on a PO item and then saves that item, the AscendHI.DLL code changes the value of the Inventory Item's quantity on hand (QOH). The AscendHI.DLL code was modified to allow a quantity of zero to be used in the QOH calculation (this was previously not the case). Now, if the user sets the quantity received on a PO item to zero from some previous higher value, the previous higher value will be deducted from the Inventory Item's QOH. Since a PO item cannot be deleted now unless its quantity received is zero, when the user deletes the item, the math has already been done on the Inventory item's QOH before the deletion occurs.
CSR: 621 -- Request: Deleting an entire Purchase Order (where one or more items on the PO have been received) does not modify the Inventory's Quantity On Hand field, nor does it remove the Inventory Control record(s) for the item(s) on the PO. Resolution: The code of the Purchase Orders form has been changed to first check whether the PO has any items received before honoring the user's request to delete a PO. If so, then the user is presented a message stating that the PO cannot be deleted because items within it have been received. Additionally, if any order item references an item within the PO, then the user is presented a message stating that the PO cannot be deleted because an item within it is referenced by an order item. If conditions do allow the PO item to be deleted, and any records exist in the Inventory Control table that link to the PO, the user is now given the option in a message whether to delete the associated Inventory Control records. See related solutions for CSRs 629 and 921.
CSR: 504 -- Request: A user is able to edit an existing Common Order record and is able to rename an existing Common Order group name when logged in with a user ID that has View Only rights to Common Orders. A user with View Only rights should not be able to edit or change any records. Resolution: To prevent the view-only user from editing the Common Order Group names, the code was changed to disable the 'Edit Group' button on the Common Orders screen when a view-only user accesses the Common Orders screen. To prevent the view-only user from editing a Common Order (but allowing the user to view the Common Order), the code was changed to disable the editable items on the Order screen when a view-only user accesses the Order screen via the Common Orders screen by double-clicking on the Common Order name in the list.
CSR: 503 -- Request: A user is able to add a new Inventory record (using the Copy button in the Inventory screen) when logged in with a user ID that has View Only rights to Inventory. A user with View Only rights should not be able to add any Inventory records. Resolution: Modified the Inventory form in the Ascend-HI.exe program to disable the Copy button when the user has view-only rights to Inventory (in the user's security settings).
CSR:
456 -- Request: Client called to report not
seeing any Drug-Drug interaction messages even after entering drugs on one
patient that should have forced the display of such a message. Resolution:
The Order class in the AscendHI.dll program was changed to resolve this
issue.
CSR: 448 -- Request: When 5 allergies are entered, the first three are displayed on profile, along with the word "more", but when 4 allergies are entered, only 3 appear in the display, but there is no word "more" to alert the user to the presence of the 4th allergy. Resolution: The DiplayProfile routine of the Patient Profile form was modified to display the word 'more ...' when 4 or more allergies are listed for the patient (since there is space to display only the first three allergies on the form).
CSR: 307 -- Request: The user is able to filter the MAR 31 day report by location, however, the report does not print the location, patient care area or room/bed #. Resolution: The issue of the patient care area or room/bed # not printing on the MAR 31 day report has been corrected by modifying the SQL for the report.
CSR: 168 -- Request: Need the system to recognize and "act on" start/End dates of listed Insurance. 1) Show only those Primary active insurance info. 2)"Archive" insurance coverage that is no longer valid. Resolution: Modified the program to have a setting under the billing tab of the Options screen that determines whether to warn the user of uninsured orders when billing (based on the selected Primary Insurance for the claim). If the flag is set to NOT warn, then the insurance effective dates are ignored. If the flag is set to warn, when the selected primary insurance does not cover the FILL START dates of ALL of the orders being billed, a warning message appears that allows the user to cancel the billing, or to bill anyway. When more than one Primary insurance is assigned to the patient, a list is displayed that allows the user to select one of them for the claim. Note that this list now also displays the Effective dates of each insurance listed.
CSR: 164 -- Request: When running the Patient Account Statement report with the option set to show only claims with a patient owed balance, claims are included where the patient balance is zero. Resolution: Modified the Crystal Reports file for the Patient Account Statement report. Now the report properly calculates the Patient owed balance. The report now 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. See also CSRs 161 and 1166 for related solutions.
CSR: 161 -- Request: When a patient-specific adjustment is entered, that amount does not
decrement the "Patient Portion" amount, and it should. This
causes the data displayed on the Financial tab to be incorrect, as well as
report data. Resolution: Modified the Ascend-HI.exe program. The Displayed lines
under the Financials tab of the Patient Profile screen are changed in
appearance as follows:
. When a Claim row is displayed, the value appearing
in the 'Patient Portion' column is pulled directly from the
Claims.AmountPatientDue field for that claim. The
Claims.AmountPatientDue field for each claim is preserved (neither
decremented nor incremented by patient adjustments or receipts). Note
that the Claims.AmountPatientDue field is displayed in the individual Claim
screen (in the lower right corner, labeled: "Total Patient
Portion:").
. When a receipt row is displayed, the phrase
'Receipt', instead of appearing in the 'Dates of Service' column, appears in
the Payer column as shown in the examples below:
Receipt: Patient Paid: Check # 4444 If the receipt is for a patient, the patient's
name is not displayed, just 'Patient'.
Receipt: Medicare Paid: Check # 5555 If the receipt is for a payer, the payer's name is
displayed, i.e. Medicare.
. When an adjustment row is displayed, the phrase
'Adjustment for ' appears in the Payer column as shown in the examples
below:
Adjustment
for Patient - Type: Write Off
If the adjustment is for a patient (the type can vary).
The patient's name is not displayed, just 'Patient'.
Adjustment
for Medicare - Type: Contract Discount If the adjustment is for a payer (the type can vary),
the payer's name is displayed, i.e. Medicare.
. When a row showing an adjustment or receipt for a
patient is displayed, the amount of the receipt or adjustment appears in the
Patient Portion column of the row as, for example: -$5.34 (a negative amount).
. When a row showing an adjustment or receipt for a
patient is displayed, the paid or adjusted amount is subtracted from the
value displayed in the Patient Portion column of the Claim Balance row for
that claim.
. When a row showing an adjustment or receipt for a
patient is displayed, the paid or adjusted amount is subtracted from the
value displayed in the Patient Portion column of the Account Balance row for
that claim.
CSR: 157 -- Request: Hold orders have not been dispensed, and should not show in the Batch Confirm screen. It is confusing for users who confirm orders on a daily or weekly basis. Resolution: Please see resolution for related CSR: 150.
CSR: 150 -- Request: Need to filter out orders that are on hold from appearing on the confirm batch screen. Resolution: Added to the SQL's WHERE statement when Tab 3 (Confirm) is selected by the user. When Tab 3 (Confirm) is selected, the SQL WHERE statement now includes the phrase: " AND Orders.Status<>'H' ". This causes orders that are in Hold status to not be included in the displayed list of orders. Please also see related CSR: 157.
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
11/29/2007
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