Ahlta client file 9.1

1
AHLTA Client File 9 (CF9)
Contents
08 April 2010

2
AHLTA Client File 9
 Priority and Patient Safety Field Reported Defects Addressed
◘ Order Meds module rounding patient weight (Patient Safety)
◘ CHCS Patient Lock Issue
◘ Turn off ACPG’s
◘ Turn off APV’s
◘ CHCS GIS Interface Error Report causing high CPU utilization
◘ Tasking Module fix (will require ICD patch as well)
◘ Tier 1 error when accessing an Encounter with Reminders on
◘ Tier 1 error when accessing OB Summary Module
◘ Users unable to edit Clinical Notes
 Client Version updated in both Registry and AHLTA Config
 Inclusive of Client File 8.0 (CF 9 is cumulative)
 Dependent on AHLTA 3.3

4
A/P Module (Order Meds) Rounding Patient Weight
 Parent Ticket Remedy # 215509 - AHLTA 3.3.3.2 Client File 8.0
 Summary of reported issue: The client is rounding weights in the A/P module (Order
Med). The weight is correct in the Vitals module, but the A/P module (Order Med) is
rounding the weight up or down to the closest kg.
 Root Cause: The local variable “patWeight” was being declared as an integer and used to
store the patient’s weight from the database. However, being stored into an integer value,
anything after the decimal in the weight value was truncated and not displayed correctly at
the top of the Order Meds module in A/P module.
 Resolution: The variable is now a double and can hold decimal values for Patient Weight.
Patient's Weight label (middle of the screen but at the top of the "Order Meds" module) will
now hold decimal places. If a patient's weight is a decimal (i.e. 186.25 lbs) then it will be
labeled as so.
 Expected Outcome of changes in Client File 9.0: The client will display the correct
weight without rounding in both the Vitals module and A/P Order Meds module. If the
weight was input as a decimal, the Patient Weight label should read the decimal weight
that was just input. If the patient's weight is input as an integer with no decimal then it will
read as such in the "Order Meds" module, with no decimal point or trailing zeros.

5
APV Switch
 Based on our testing and analysis – we can disable the APV's by removing the
switch similar to that of the ACPG reminders in Client File 9.0.
 With the APV switch off:
◘ APV clinics will no longer display as a selection for viewing or selecting appointments in AHLTA.
◘ APV appointments created in CHCS will still transmit to the CDR, but there is no way to access or select them in
AHLTA client via the appt list.
◘ Previous APV completed encounters will still display in the previous encounters module, but cannot be selected for
amend or append.
◘ In-Progress/Incomplete APV encounters will no longer be accessible in appointment or current encounters
module, with exception of those APV appointments still waiting for co-signature.
 Recommendation:
◘ Based on our findings ~97% of all APV appointments are not being touched in AHLTA – they have never been
accessed so just remain empty shell appointments taking up space in the incomplete appointments module for
users – these would be candidates for our Category 1 adminclose updates currently being executed.
◘ The remaining ~3% of APV appointments are a combination of cancelled, in progress and complete encounters.
◘ Based on the utilization numbers above and our testing we believe removing the APV switch from the
AHLTA.exe.Config file effectively prevents users from seeing these APV appts in AHLTA since only a limited
number of users are currently utilizing the existing functionality.
◘ Include in the release notes the recommendation that since any incomplete APV appts/encounters would no
longer be accessible, users should complete all APV encounters before updating.
◘ Removing the switch would still allow the site the control - if there are sites that still want to use the functionality, or
even particular providers within the site that want to use it, they can control it workstation by workstation by
manually adding the switch back into the AHLTA.exe.config file.

6
CHCS Patient Lock issue
 Parent Ticket Remedy #20640 - AHLTA 3.3.3.2 Client File 8.0
 Summary of reported issue: Patient locks preventing admittance of patients in CHCS. If a user has
an AHLTA encounter open when they toggle to CHCS to admit a patient they receive an error message
indicating that the patient record is locked preventing the admission.
 Root Cause: The current AHLTA 3.3 client allows for a "keep alive" function between AHLTA and
CHCS. If an AHLTA user has a patient encounter open, the system is automatically keeping the
connection between AHLTA and CHCS order entry open. While the connection is open the patient
record in CHCS is locked in order to prevent confusion between possible inpatient and outpatient
orders. While the record is locked, it is not possible to admit a patient using CHCS.
 Resolution: The AHLTA client already has a time-out mechanism which defaults to 30 minutes but is
configurable through the Snareworks security system. If no user activity takes place within the AHLTA
user interface during that time, the client times out, hides the normal screen and puts up a screen to
allow the user to resume the session. The order entry module was changed so that when this timeout
occurs, if there is a patient selected in CHCS it is released and if there is a connection to CHCS it is
closed. When/if the AHLTA session is resumed, if there had been an order entry connection to CHCS it
is reestablished as it was before the timeout occurred.
 Expected Outcome of changes in Client File 9.0: If a user walks away from an AHLTA client and
leaves an encounter open, the CHCS order entry connection will be closed when the AHLTA client
timeout occurs and CHCS users will be able to admit the patient.

7
CHCS GIS Interface Error Report
 Summary of reported issue: On the CHCS GIS Interface Error Report, there are thousands of pages
displayed for errors coming from the CHCSII_APP_SERVER LOGON processes. This causes high
CPU utilization on the A node which affects performance of other processes. It can also fill up the error
trap and global which could potentially cause a CHCS outage.
 311Invalid user access/verify code
 319DEFAULT DIVISION DOES NOT MATCH ALLOWABLE DIVISIONS
 310CACHE down" ! Text for CACHE NOT RUNNING
 315CACHE Error" ! Text for CACHE failed to run
 317Connections not accepted at this time"
 313Max number of client connections
 314Connection not made to master node
 320Default division inactive
 Root Cause: When the CHCS order entry login fails, the AHLTA client continuously tries to reconnect
to CHCS which causes thousands of the above related errors to be generated in the CHCS GIS
Interface error report.
 Resolution: The AHLTA client order entry module was changed so that when a CHCS order entry
login fails after a successful TCP/IP connection to the CHCS port, the user will be informed of the
cause of the failure and the client will close the TCP/IP connection and will make no further attempts to
log in to CHCS order entry during that AHLTA session.
 Expected Outcome of changes in Client File 9.0: If the request is rejected by CHCS, the AHLTA
client will make at most one failed attempt to log in to CHCS order entry during a single AHLTA
session. This will eliminate reported issue. If we are able to connect to CHCS order entry, but the
actual login fails for any reason (reference above CHCS GIS interface errors), AHLTA will let the user
know the exact problem and won't try again for the rest of that AHLTA session.

8
Tasking Module
 Summary of reported issue:
◘ When a task is created by a user and assigned to a different user, the assignee of the
task cannot document in the task. However, the creator of the task can still go in and
document in the task even though the task was created for a different user.
 Root Cause: The issue was caused by the security check only validating the creators
NCID had security rights to edit the Task.
 Resolution: The change was to modify the security check for either the submitter or the
assignee depending on whom was logged in.
 Expected Outcome of changes in Client File 9.0:
◘ The user assigned the task by another user will now be able to edit the task fields and
save the changes. All fields are now editable with exception of Note History.

9
Tier 1 Error when Accessing an Encounter with Reminders On
 Parent Ticket Remedy # 70415 - AHLTA 3.3.3.2 Client File 8.0
 Summary of reported issue: A specific Tier 1 error is responsible for 11% of
the Tier 1 errors generated Enterprise wide. This specific error was introduced in
3.3 with the implementation of the Clinical Practice Guidelines and can occur
when an Encounter is open with the Reminders pop-up modal active.
◘ Error Number: -2147418105
◘ Description: Automation error The callee (server [not server application]) is
not available and disappeared; all connections are invalid. The call may have
executed.
◘ Location: Reminders.Reminders.Initialize
 Root Cause: The root cause is still under investigation.
 Resolution: While the root cause is not known the error will be mitigated by
turning off the CPG switch.
 Expected Outcome of changes in Client File 9.0: The user should no longer
see this and several other similar Reminders errors

10
Tier 1 Error in OB Summary
 Summary of reported issue: User are unable to use the OB Module in 3.3.3.2 CF 8.0 due
to Tier 1 errors. When users launch the module it takes up to five minutes to load and once
loaded the following error is displayed and the module shuts down and returns the user
back to the appointment module or at times kicks the user out of AHLTA.
◘ Error Number: 5
◘ Description: Invalid procedure call or argument
◘ Location: OBSummary. in Problems.mobjHistoriesCallback_Completed
 Root Cause: The issue is that there were two threads that were stepping on each other--
i.e. there was no thread synchronization. So basically, one thread was removing and then
after that the other thread would try to retrieve, but problems was no longer there.
Therefore the code crashed because it was returning a NULL object back to the VB6 code.
 Resolution: The fix was to use a SyncLock around the two functions so only one thread at
a time can access the code. So one thread will access GetFamilyHistories and the other
thread will wait at the start of GetProblems until GetFamilyHistories is finished or vice
versa depending on which thread gets the SyncLock first.
 Expected Outcome of changes in Client File 9.0: The user should now see no error and
problems in the OBSummary module should display

11
Users Unable to Edit Clinical Notes
 Summary of reported issue: Users cannot get the EDIT button in Clinical Notes folder to
work/be enabled when they make an entry in the Clinical Notes folder – the edit button is
grayed out.
 Root Cause: The function needs to be modified – currently it compares user names to the
logged in user defaulting to a binary compare using the StrComp function. This design
does not take into consideration if the user object is in upper case while the value being
compares is in mixed case. Before comparing the values using the StrComp function the
values should be set to the same case so the comparison will return a 0 if they are indeed
the same name.
 Resolution: In the StrComp function, each string being compared is first converted to
UpperCase using the Ucase function, and then compared so as to prevent comparison
conflicts due to potentially different type cases.
 Expected Outcome of changes in Client File 9.0: Clinical notes are now able to be
edited and will not error even if the logged in user name does not match the same type
case as the user object string.

Ahlta client file 9.1

More Related Content

Similar to Ahlta client file 9.1 (20)

More from doctorcorcoran (10)

Recently uploaded (20)

Ahlta client file 9.1

Editor's Notes