IC527 Item Interface

We use it here to generate files to interface to our Cerner SurgiNet module. I had to write a custom Perl script to meet our needs, though.

Actually my documentation has CD3, Seq 25 as HCI-PRICE which equates to HCCHRGITEM table - field PRICE, and our HCCHRGITEM table does have info in it.

OK, I finally see what you have been saying all along. The file produced by IC527 has purchase price in it, not the Patient price. I've opened a case with Lawson on the same subject. Maybe if enough people are complaining, it will get fixed.

The version we were running in Prod on 12/1/05 was pulling the correct patient cost, the new version fixing the manufacturer problem (CTP38620) is pulling purchase cost instead.

Steve and all:
The case I opened up with Lawson, the tech is seeing the same thing as we are, so she wrote up a patch request.

Case will be held with PT # 154789

CTP to fix released just today... 40987

Hey, following up on this whole thread... Anyone know of an EASY way to run the IC527 job (by location) and ALSO split the files into 1,000 item max??
say if there are 4,375 items in the file for one location, to create 5 different files?

Thinking off the top of my head, I would suggest writing a pre-processor/wrapper program that splits the HL7 file by location, and then creates separate canonically-named files with < 1000 items in each file (e.g. HL7_LOC1.001, HL7_LOC1.002, etc.). The wrapper program could then create job records and submit the job (for each file) using 900-CREATE-AND-SUBMIT-JOB. Not necessarily "EASY", but is anything??

Greg,

Thanks for the updates, I guess I hadn't scrolled down far enough to notice that there were replies to this thread.

As you know, GSC did provide a patch to the IC527 process to correct the issue, and to put IC527 "in line" with other IC52X jobs.

This caused another problem for us: in the IC527 documentation (article id: 74456), the CD2, field 16 data is supposed to be pulled from ITL-AVERAGE-COST <- the average cost field from the item location (IC12) record. The data that is retrieved and the routine they use to retrieve this information is documented in KB article 525489, and is as follows:



In the Item location file:
PREFER-BIN, SOH-QTY, LEADTIME-DAYS, CHARGEABLE-FL, TRACKING-FL, LAST-ISSUE-DT, ACTIVE-STATUS, UOM. If the item location is inventory tracked, then if AVERAGE-COST is greater than zeroes, test it. If the item location is not inventory tracked, then if the replenishment location exists and its AVERAGE-COST is greater than zeroes, test it. If still no cost is arrived at, then if a requesting location exists and its AVERAGE-COST is greater than zeroes, test it. If still no cost is arrived at, test the LAST-REC-COST from the original item location.



Well, with CTP # 41209, they changed the routine used to the PO Cost Routine, which populates the field with the default purchase UOM cost instead of the each/unit average cost. Unfortunately, this doesn't work for me, as we use the IC527 to populate our OR clinical system with item cost information. So when we take a look at the cost of a procedure (in the OR system) that uses one pack or piece of suture, I'm now looking at the price of a box of 12 or 36 sutures, etc...

GSC has stated that this is the way it is intended to function (now), so I'm back to getting in touch with my client account manager to escalate the issue, or rewrite the interface from scratch...

Greg - just out of curiosity, are you wanting to split this file up do your Cerner system can handle the files?

We use GE's ORMIS (formerly iPath), and they've requested the same thing, basically...when I delete the WORK file, I send across ~5000 items, and their interface program chokes on the file and times out.

I'm pressing that issue with GE, calling it sloppy programming...if it can handle 500 items, it should handle 5,000 items too :)

Steve: Yes, we (apparently) need to split the file up (and convert it to a more IC526 format file) so that our Cerner system can handle it. I agree with you, that the fault is shoddy programming on their part, but I figure it will be much faster for me to write a shell script or perl program to process the file than to wait for Cerner to fix their system. We've been told to split ours at 1,000 items... and that currently is creating about 11 files per week.
I've got a perl program that I run against the output IC527WK file that does almost everything it needs to do.

I'm no perl programmer, but was able to figure out how to write what we needed... with the exception of just ONE thing. I'm attempting to have the whole thing automated by the end of next month!!! Wish me luck!

Just a follow-up: We have been able to make the interface work now. It was a combination of a perl program and a shell script on the Lawson side of things, but it all seems to be working now.