PICIS -MM HL7 Interface

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.

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.

Yes, we have a custom sql to Epic Optime, Cupid and Radiant. Not the IC527.

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.

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?

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.)

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.

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.

Anybody willing to share their SQL statements? Are you using Cloverleaf for the interface?

Anybody willing to share their SQL statements? Are you using Cloverleaf for the interface?

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.

Thank you, Kat! I really appreciate this!