SPECIAL FALL EDITION – 15th Edition
Written and Edited by Bruce Clutcher, R.Ph., Senior Consultant, SSG
Can you/should you clear out any existing Rx services from the SM before running the
conversion? Response: Services with the same Service Key (i.e., Department plus Service Code)
cannot already reside on the SM for the conversion to work. Either the services should be
deleted (especially if they are not going to be used) or new services created
with a different Service Key.
Can you clear out and repeat the conversion again closer to Live (to pick up any
updates/changes to the PDM file)? Response: Columbia did a Prod -> Test copy of the SM, then ran the conversion
against Test until the desired results were obtained. If there were any major problems,
all they did was do another Prod -> Test copy of the SM to start over with a
‘fresh’ SM. Once the whole SM was converted, you need to run an NDDF-Update on
INVISION against the SM to ‘QA’. Once assured the SM was correct, you can copy
the SM from Test -> Prod. IS users should be instructed not do any maintenance on Prod
while this conversion is taking place; otherwise, they will lose their changes once the SM
gets copied back from Test -> Prod (unless they performed dual maintenance on both Test
and Prod while this conversion was going on). The only way to rerun the whole conversion
later (e.g., months after the conversion, but prior to Live, to pick up maintenance
performed on the PDM, and assuming the Test and Prod SM have been converted or overlaid
and are therefore in sync) is to delete all PHM services on the SM, perform a Day End,
then run the conversion over again against a fresh PDM report offload. Once the Masterfile
Synchronization project is in place, you should be able to update the SM by performing the
automated maintenance on the PDM.
Where will #DU (dispense units) come from on INVISION (does it get calculated from SM
fields on INVISION, or does it get transferred from SMS Rx)? Response: The interface will bring the #DU inbound into INVISION. CHPPRX51 is
suppressed to not recalculate #DU; however, interface development recommends we set up
Dispense Unit Number, Dispense Unit and the four strength fields on INVISION as if #DU was
going to calculate on its own. This recommendation is in anticipation of any possible
future order entry on INVISION.
The PDM’s Volume Unit is 7ch, but the SM field is only 6ch. Will truncating the PDM
field cause any problems? Response: Columbia ran a DAS report to see if many volume units are greater than
6ch. Only one record was greater than 6ch. The one record was subsequently edited to 6ch.
The PDM’s Package Unit is larger than the SM field. Will truncating the PDM field
cause any problems? Response: Columbia ran a DAS report to see if any PDM Package Units were greater
than the SM size. No record was were found exceeding the SM Package Units size.
The PDM has the capability of having two different CDM # ’s in two
different locations, with fields 601 & 701 valued to Yes. Will the conversion treat
this as two separate entries in the Service Master? Response: Columbia wrote a DAS report to identify drugs that have both fields 601
& 701 valued to Yes. No records were found to be set up this way. However, if the DAS
report had located records with this set-up, maintenance would be performed to break these
out into separate entries in the PDM.
The PDM supports up to 10 allergy codes, the SM only 3. Will eliminating any allergies
over 3 cause a problem? Response: Columbia ran a DAS report to see if many drugs contain more than three
allergies. No records were found with more than three allergies.
C2450 (SM Rx Pharmex Warning Code) only stores three codes. The PDM supports five (D_219
and D_220 for 4 & 5). Is this a problem? Response: Columbia ran a DAS report against the PDM and found several hundred
records with at least D_219 filled in. Since the SM only accommodates up to three codes,
some records will not contain the full complement of Pharmex codes on SMS Pharmacy. This
may not be an issue, since INVISION users rarely take advantage of the codes. This issue
to be even more so with the ‘front end’ processing being the SMS Pharmacy side.
RXPert
Contents
