IC527 Item Interface

Sort:
You are not authorized to post a reply.
Author
Messages
Steve Williams
Basic Member
Posts: 7
Basic Member
    Do any users here use IC527 to generate an item master report, or any of the other IC52X reports?

    I'm right now in a slightly heated email exchange with GSC, due to the fact that our IC527 reports have the purchase UOM price inserted into the "Patient Charge" field (CD3, field 25). We don't have or use the PC module at all, and the database element that this information is supposed to come from is empty - actually, the whole table is empty (PCCHRGITEM). None of the KB articles or the IC527 HL7 spec can remotely explain this behavior.

    I can't seem to convince the GSC person that this is NOT how the application is supposed to function...and it's worth noting that it's only been doing this for the last 3 months (we were slow to catch it). I've had no recent MSPs or CPTs that have any relevance to that form (altho we've had others), so I'm convinced it's a flaw.

    I guess I'm looking to see if anyone else uses this form, or have any experience with any of the HL7 Item Master interface forms...
    Greg Moeller
    Veteran Member
    Posts: 1498
    Veteran Member
      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.
      Greg Moeller
      Veteran Member
      Posts: 1498
      Veteran Member
        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.
        Greg Moeller
        Veteran Member
        Posts: 1498
        Veteran Member
          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.
          Greg Moeller
          Veteran Member
          Posts: 1498
          Veteran Member
            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.
            Greg Moeller
            Veteran Member
            Posts: 1498
            Veteran Member
              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
              Greg Moeller
              Veteran Member
              Posts: 1498
              Veteran Member
                CTP to fix released just today... 40987
                Greg Moeller
                Veteran Member
                Posts: 1498
                Veteran Member
                  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?
                  John Henley
                  Senior Member
                  Posts: 3348
                  Senior Member
                    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??
                    Thanks for using the LawsonGuru.com forums!
                    John
                    Steve Williams
                    Basic Member
                    Posts: 7
                    Basic Member
                      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...

                      Steve Williams
                      Basic Member
                      Posts: 7
                      Basic Member
                        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 :)
                        Greg Moeller
                        Veteran Member
                        Posts: 1498
                        Veteran Member
                          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!
                          Greg Moeller
                          Veteran Member
                          Posts: 1498
                          Veteran Member
                            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.
                            You are not authorized to post a reply.