NEW TERRITORY IN RTIF PROCESSING
By Connie Kaufmann
Sometimes an assignment gives one the opportunity to work on a different portion of a familiar product. My
current RTIF PMS project is a feed from EPIC registration to INVISION clinical documentation and
physician/clinician order entry. It requires that current INVISION modifications built into the client’s normal
patient management functions continue to function as they previously have, but through RTIF processing. The
INVISION build is highly customized throughout patient management and order/clinical pathways. Most of the
customizations were added to comply with JCAHO regulations, safety concerns, unique patient population
requirements, etc.
There was little or no documentation to help us determine what or how we could continue performing the needed
processes, because so much of the project had been accomplished by trial and error. Below is a discussion of our
largest hurdles and our solutions.
Generic Profile Builder
Several of the processes we needed to move forward used the Generic Profile Builder. We were unsure of how,
or if, there would be complications in RTIF. To date, we found no issues with this program running or updating
different profiles within the RTIF pathways.
Save and Restores
Since this is an EAD/LCR site, we have utilized the LCR save and restore auda process in our OAS order and
clinical documentation pathways. This processing is different then normal OAS $SVE and $RST command processing.
LCR programs allow you to nest the saves and restores, which you cannot do with the standard OAS commands. This
process is used to cycle through the function in orders, as the order revisions, status changes and comment
entry are manipulated. We were concerned that this might not function properly when we embedded the OAS
pathways processes to run in the RTIF pathway. Yet, the saves and restores work as designed and we have been
able to maintain the functions as needed.
Error Processing
Error processing is handled differently in RTIF. It should be noted, programs and unique error messages
differ when under the RTIF umbrella. This has created the need to modify error message data. One such program
is CHPPO477. When RTIF reads a true E message, there is no way to stop RTIF programs from halting the process.
Interestingly, in a regular pathway, where there are gold forms or screens to display line 24 messages,
processing is not halted. We ran into issues with the “no orders qualify” error E10046. For this problem, we
had help from Siemens staff and found out that we could copy the Model message down and change the Error code
to an Informational code, and the program no longer caused the RTIF abends. In another instance, that process
did not work and we had to change the message to non-display and informational, and then the error would not
cause an abend.
Interface Data Mapping
We use the interface engine to perform many complicated table and record conversations as needed. We have
successfully updated care provider items, auto co-signed orders, changed order status. Additionally, we added
3-field comments to orders, updated 2-fields and 1-fields, performed DVA’s to the Master Patient Index (MPI) in
all transactions via the OAS tcl’s that run under RTIF processing. The only function we have not been able to
do, of course, is stack a gold form.
Our advice is, it pays to try things, never just assume you can not do something.
If you need additional lessons learned in Siemens solution implementations, check our website
www.getvitalized.com and look in our resource center or call us at
610-444-1233.