PICIS -MM HL7 Interface

Author
Messages
Chesca
Veteran Member
Posts: 490
Veteran Member

     

    How complex would it be to write our own IC527 out side of Lawson like a PHP program to create the interface to PICIS? Has anyone not use IC527 and used something else instead?

    Kat V
    Veteran Member
    Posts: 1020
    Veteran Member
      We moved from PICIS to Epic but yes, we have our Data Warehouse run a sql to get the information from various fields not in the IC527 and then move the "package" to Cloverleaf which then maps it in HL7 format to Epic.
      Leslie
      Veteran Member
      Posts: 45
      Veteran Member
        Have you replaced the IC527 with a SQL query for getting Lawson to Epic adds/changes? I am on a project team for updating the mapping from Lawson to Epic and am finding that current IC527 is really not working very well.
        Kat V
        Veteran Member
        Posts: 1020
        Veteran Member
          Yes, we have a custom sql to Epic Optime, Cupid and Radiant. Not the IC527.
          Me
          Veteran Member
          Posts: 96
          Veteran Member
            Leslie - we're just starting up with moving to IC527 as well.  I'm curious as to what issues you've run into.  We're currently using IC524.
            Leslie
            Veteran Member
            Posts: 45
            Veteran Member
              The biggest issue seems to be that the fields do not map very well to Epic. We have had complaints of items not updating correctly, and the staff would really like to see the non-chargeable patient supplies (like gloves) down to the usage UOM, rather than the low UOM stored in Lawson, which will take some custom work. Additionally, we have had issues where 2 or more PARs are mapped to a single EAP and so the bin doesn't update correctly (this is procedural, not a problem with the IC527, but still...)

              Kat - was the reasoning behind your change to a custom SQL statement related to the IC527 and it's limitations, or was there another factor that moved you in that direction?
              Kat V
              Veteran Member
              Posts: 1020
              Veteran Member

                SQL over IC524 was mostly what you just mentioned - it's an inventory program and will not pull the non-stock. The high dollar implants are typically bill only and not an inventory item - so you end up either creating false stock - which never moves or gives you errors as "SOH exists for location" when trying to change things etc.

                The IC52x reports put the field they have to the map they have. Things like Generic and Use Identifier along with Added Date got problematic. With the SQL, we control where they look for what and can calculate cost for non-stock and can troubleshoot without an AMS call.

                 

                Edit:  For PICIS specifically we had an issue where they wanted sterile flagged and that is in our IC11 user field and if I recall, they decided it should be a hazard code of some sort.  (It's been several years since we went to Epic - I may be mistaken.)

                Erik G.
                Basic Member
                Posts: 14
                Basic Member
                  When we moved from our old EMR to Epic we also experimented with IC524 but found that because we were using pars to control what data was entering into each Epic module, was not a viable solution. Our issue was it was not picking up the updates made to items. Our head Lawson analyst worked with our interface team to develop a set of SQL queries that are run nightly that pick up data from IC81, IC11 and IC12.
                  Leslie
                  Veteran Member
                  Posts: 45
                  Veteran Member
                    Thanks - this is the direction I would like to recommend to Supply Chain. The current IC527 process just is not working the way we would like it to. We also use PARs to control the data that is going to Epic, and if Supply Chain has not notified the interface team that they need a new PAR mapped to Epic, well, obviously it doesn't update. Also we have had issues where two or more PAR locations are mapped to the same EAP in Epic, so the bin location updates to the last received change, and it isn't always right.
                    Leslie
                    Veteran Member
                    Posts: 45
                    Veteran Member
                      Anybody willing to share their SQL statements? Are you using Cloverleaf for the interface?
                      Leslie
                      Veteran Member
                      Posts: 45
                      Veteran Member
                        Anybody willing to share their SQL statements? Are you using Cloverleaf for the interface?
                        Kat V
                        Veteran Member
                        Posts: 1020
                        Veteran Member

                          I will absolutely share the insanity. :)

                          I wrote the original sql - IT did things to make it HL7 compliant and then put in the reporting services on our data warehouse.  They create an SSIS package that goes through Cloverleaf who makes all sorts of judgements and mapping alterations to produce a flat file saved to the Epic server.

                          Attachments
                          Leslie
                          Veteran Member
                          Posts: 45
                          Veteran Member
                            Thank you, Kat! I really appreciate this!
                            ---