David Hallberg

Security Changes Create Queuing Issues

Cerner recently made security changes to Millennium’s Java services and several older servers that might have disabled your system’s ability to automatically replay failed transactions. Unless corrected, caregivers might be losing important clinical information.

The changes involve Millennium’s personnel (prsnl) table, the listing of users who have permission to access applications and modify tables that contain clinical information. Previously, the username “system” was not typically included in this table because this username was created for those doing low-level executables with no need to access clinical applications or view clinical data. It was used to access failed transactions for SCP Entry IDs 105 and 108 (ORM Explode Cont Order and ORM Explode Cont Order Batch) and to replay them. A few months ago Cerner sent out a Millennium Flash announcement saying, essentially, that failed transactions could only be replayed if the username was listed in the prsnl table and, to that end, the “system” username was now included in the prsnl table.

By forcing transactions to be replayed or re-queued by a user listed in this table, Millennium is plugging a gap in its security model. However, contrary to the announcement, most clients don’t have “system” listed in the prsnl table. If you’re one of them, you might find that transactions are failing to be replayed and that some might not post the first time.

“System” is one of three Cerner default usernames. The other two — “cerner” and “systemoe” — are already in the prsnl table, where they need to be. But having this listing is only the first step toward ensuring proper replaying of failed transactions. I worked with two clients in June who had numerous interactive users all properly listed in the prsnl table but whose transactions still were not re-queuing. We discovered that some (hopefully all) Java servers have an extra level of security. Users must be granted access to application 3202004 (java.exe). I suspect that this requirement applies to SCP Entry IDs 105 and 108 as well.

Unfortunately, this access change does not seem to have been widely documented or deployed, so you might be losing some information as you’re waiting on others to put the information into Millennium. Far from being your fault, you just were caught in the switch to the new application security.

What do I recommend? Place the following usernames in the prsnl table and give them access to at least the 3202004 application: system, systemoe, cerner and panthercycler (if you’re a Softek client). Then cycle the CPM Application Authorization servers, SCP Entry IDs 105 and 108, and all of the Java servers (generally SCP Entry IDs 350-374).

Prognosis: Correcting the username listings and Java application access required by the new Millennium security model will allow your failed transactions to replay and will result in improved throughput of clinical transactions. To truly improve system reliability, however, you’ll need to address the underlying problem of why the transactions failed in the first place.