Identifying supply areas for Epic OpTime

Jon,

I have an IC12 location that I use to pull all of the items for the interface to EPIC. I've called it OPTME because we had Optime first but it goes for the others as well. Anything that needs to be in the interface goes into that location as a nontracked item. I use the first two user fields to add codes as to which balance record needs to be created for the item. (HVII = HVI interventional, CASC = surgicenter, etc). We have Cloverleaf which takes the file we extract from Lawson, massages it into the EPIC format and puts it into EPIC. My codes are turned into the numeric EPIC designation for each balance record needed.

As far as costs, we use a combination of screens to send the calculated each price. On IC11, I have two user fields in play. One where we put the buy UOM (BX, CA, etc) and the other where I put the conversion number (5, 10, 1, whatever). The UOM HAS to match what is on the active vendor agreement - if so, it takes the price that I've loaded into our special IX12 screen and divides it by the conversion. The last special piece that I have is the IX12 screen my IT guys made for me using design studio. It updates the four costs on IC12 with whatever I put there. This allows me to have a cost on non-inventory tracked items in IC12 and therefore something for the interface to divide by.

Michelle

We have an IC12 as well. IT had a script painting qty and price into itemloc nightly. We've since stopped using the IC5xx jobs entirely. We have a sql going to Cloverleaf that's then mapped to Epic. The calculation for unit cost is just part of it. I like the sql much better as I got out of all the user fields and just pulls the data from where it naturally lives.

A gotcha from the early Epic days. If you are not currently populating use identifier on IC11, you may want to start. Optime (and Cupid and Radiant) really needs to know Supply v Implant - they show in completely different areas for the people in the procedure room and have completely separate charting requirements. The Issue Account is related but not 100% the same. Interceed mesh was the biggest issue for us. It charts as an implant but is not reimbursed as such.

Huh...wish I'd known about using Usage Identifier. We use inventory class and I've got the EPIC implant types built into the minor inventory classes so I not only send implant but also the type of implant for them. We are also using a SQL query to pull the data out of Lawson - there were just too many parameters.

Yeah - "But what is it?" is the question that still makes me twitch. We're populating the use identifier and generic instead of GL and minor code.

" " Generic Glove - Is a supply with supply type Glove
"L" Generic Pacer is an implant and the implant type is Pacer

And description 1 is too short and no one can read it, but description 3 is too long so that has to be an alias...

GOOD LUCK, JON.

We send description 1 and 2 together to form a 60 character description for EPIC. (We are in testing for 10x so haven't played with the new D3 yet). The staff hates the combined description just as much if not more because in some of their screens, they only see the first 20 or so characters when selecting the item. We've held firm on standardized descriptions though (noun first, spelled out, then descriptors) because I refuse to junk up my system any more for their items. We are happy to take aliases but they haven't given us any.

Do I sound as bitter in text as I do in my head? Lawson was deemed the "source of truth" for items. The EPIC folk wanted everything in the system, including one time use items to make it easier on their nurses. Today I have close to 10,000 items built just for EPIC - and I'm not certain they are using them.

Ditto to Kat's GOOD LUCK JON!!!

Jon, et al,
I am not sure this will help a lot, but here is how we covered the various points above. To level set, we are on Lawson V9 with hopes of upgrading to V10 by the end of the year. We use EPIC and OPtime.

To start with we created "reference" IC Locations (IC02) that are used to identify items in the ORs at specific sites. The item, therefore, has to be built to the Item Locs (IC12), in order to interface over to EPIC. These are active from a status perspective, but are [currently] not used for transactions. If it isn't obvious, this creates a lot of duplicative work, managing the same items in multiple locations. Before I go into that further...

On the Item Master (IC11) side, we did several things. 1) We use the Sales Major Classes to indicate Supplies versus Implants (blank = "supply", and there are a handful of implant categories). The Sales Minor offers a bit more detail on the Implant type. The Sales Class was easy for us because we were not using it before this. 2) We use the User Field 5 to house the calculated cost of the item at the lowest Supply Chain UoM and the date that the calculation was done. If the "Unit of Use" is smaller than the lowest Supply Chain UoM, we use User Field 4 to house the UoM designation and conversion to the lowest Supply Chain UoM.

Back to the item identification/interface issue. One of the challenges with the "reference" locations is that they, as you might expect, are not being kept in pristine condition. This leads to scrambling to "attach" an item so that it can be charted and billed. We developed an alternative, "Master" set of items based on the Purchasing Major/Minor classes in the Item Master. This is not perfect either, as there is a lot of extraneous items in the list, but it is more likely to have the items the Clinical folks are looking for. At the moment, both methodologies are in use.

Like Michelle and most everyone has stated, this completely blows up your Item Master numbers because you now are more or less forced to build items on a "just in case" model rather than a "just in time" model. Between Total Joint, Cardiac Rhythm Management, Spine, Trauma and whatever else, our numbers are easily up over 60K. And, of course, now you are having to manage all these "potential" items through the data life cycle.

However, someone I was talking to mentioned that a client of theirs in the Pacific Northwest (I am pretty sure) took a different tact. They built an independent database of items that feeds into Epic. I don't know a great deal of the details related to the database, but I did not get the sense that it was a full Master Data Management (MDM or PIM) hub. I envisioned it as a superset of Lawson built items and all other contracted items. The non-Lawson items would be lightly scrubbed and attributed enough to allow the Clinical staff to bill it the first time and then submit it to be more formally built. The term eludes me at the moment, but I liken it to an offline WIP inventory in a JIT model, used to adjust for variations production.  [As an afterthought, this process could also address those sitautions where an item should be inactive in Lawson but available in Epic.  "Schroedinger's Implant" being both inactive and active at any moment in time.-rs] 
  
This would be a great topic for a "lessons learned" type of conference call someday.

To join the rest, Good Luck!
Red

Hi,

When we started using Epic/OpTime we were on Version 9 and just recently upgraded to Version 10. We use the IC524 file to send our Epic related information to our Cloverleaf interface engine for translation before it is sent to Epic.

To manage the items, we use IC81 Par Locations. In doing so, the system auto creates an IC12 file for those locations. You still have to do some individual location management regarding vendor and purchase from information for non-stock items and UOM info, other than that. There isn't much else you have to maintain at those specific location.

We too use IC11 to indicate if an item is a SUPPLY, IMPLANT or DRESSING. For cost, we load unit cost or lowest unit of cost for all items considered chargeable in PC10. That screen allows us to load the cost and the charge code identified by our revenue cycle team into one location where it's easier to limit errors, however, it does add additional steps for maintaining. PC10 is a little more locked down than the IC11 screen, so it's more difficult to make updates for items regarding charge codes.

We too struggle with the just in case scenario. We use lots of ortho trauma items and have had to create thousands of new Lawson numbers for items that we most likely will not use, but exist an in implant tray so they have the potential of being used. Just in the last 12 months, our ItemMaster has grown from 30k items to 50k active items. Like Red's organization, we focus on both "just in case" and "just in time" items in order to fulfill the clinical documentation and billing needs.

Hope this helps.

John

Reading the thread, looks like most advice is covered, but I'll give you the basics of our setup:
Currently v9 - v10 end of year (hopefuily), use a modfied IC527 -> mapping through Corepoint -> Delivered to Epic Bridges
IC11 is the source of truth INCLUDING HCPCS, Revenue Code and EAP ID (PHS has created correlating charge shells in Epic that are applied to items to determine charge amount) these are stored in user fields currently - looks like v10 has some dedicated fields for this purpose.
Providence has built "Virtual IC12 Locations" (ie - will never have transactions) - these map 1:1 with Epic Inventory Locations. This is maintenance headache, but with a 370,000 item master we had to restrict somewhere.
Pricing is calculated automatically - the majority of our contracts are company participants to virtual locations price out like any other.
Supply and Implant is trickier - Corepoint holds a map between the Lawson Major Inventory Class and either Supply or Implant.
EXCEPTIONS:
Life is good until you associate with a new healthcare system or acquire a new faciltiy that uses a different build of Epic - then things get fun.
We incorporated a system of 5 hospitals that pulled from multiple locations in Epic, and wanted Bin Locations interfaced to Optime for the Pick for Case documents. In that case we used PAR locations that map 1:1 with the Epic Inventory locations, and are prioritized in pick order for each Epic Surgical location. These work fine, but did require being added are participants on Vendor Agreements to price correctly.
** I am always looking for a better way to perform this function - the IC527 produces an ancient HL7 version, and has proven not 100% reliable so we have to drop the indexes monthly to ensure data integrity.
Hope that helps - I'll be an Inforum in NYC for anyone who wants to have a mini-brainstorming sesson on this subject...ROFL!

Thank you all for your input and all the "good lucks". Very helpful.

I am creating a sql script to pull the data. I wasn’t confident that any of the IC5xx jobs would pull all the data we need. We’re currently on v9 but v10 is in the testing phase with go-live September 16th. Go-live for Epic is in April 2017 but interface testing is supposed to be completed by October. So I’m building the supply file using v10 tables.

I did take the Usage Identifier field into consideration to populate the supply type (implant vs supply). There’s no “supply” in the drop down though but I suppose if it’s not “implant” then Epic can assume it’s a non-implant supply. Are those drop down selections modifiable? Our Revenue Director also wants Lawson to supply a “patient friendly” description for billing. I like the idea of using the Sales Class field for this, were not currently using this either.

I really don’t like the idea of creating IC02/IC12 records for each supply use area. As Red said, it would create duplicative work. I’d be more inclined to use the IC12 user fields as Michelle stated to identify which balance record the supply should be applied to. But what if the supply is used in multiple locations? Kat mentioned “Generic Glove” earlier in the thread. That’s a supply that’s used everywhere.

ITEMLOC.LOCATION to identify the facility, for instance: MID for Midland
Then ICITLUF.ITL_USR_FLD_01 = SURG for Surgery; ICITLUF.ITL_USR_FLD_02 = CATH for Cath Lab/Interventional, ICITLUF.ITL_USR_FLD_03 = DRAD for Diagnostic Radiology, etc.?


Ha! “Schroedinger's Implant", I like it.

Just to add to the ITEM LOC.LOCATION chain of thought - here's how I break it out when there are multiple places that use them. I only have the one main location but we have many different clinical areas within that might need to access the item.

User Field 1: ORP^DASC^DHC^HVII^HVIC^HVIE^HVII
User Field 2: CASC^HRHC

Etc... that limits the number of user fields I have to give up at any one time. Each one of those four digit codes represents a balance record in EPIC that would be created for the supply or implant.

Michelle

Nice idea, I'll use that.

ooo... IC56 item attributes might work as well... I'd love to get out of the IC12 business.

I never really understood how to set up or use attributes. Are they really that useful?

I like them as they are a "create your own flag" that shows up on sql to query. I've used them to flag things for VAT projects and we created a field for brandname and one to house the ticket number the initial item request came in on.

But the appeal to me for Epic is that IC56 is it's own screen with it's own security rights. I can absolutely give it out and let Epic change/upload to it. If they want an item, they can go load it.

Not sure if anyone saw my question buried in my earlier post but are the Usage Identifier field selections modifiable? How did Infor come up with these? Drugs AND Pharmacy- why?

 

We asked and were told no - nothing that isn't select value is modifiable. Careful with the drug/pharmacy flag - it does things to Epic.

Sorry, Jon. I did see the question but missed answering.
I do not believe that they are editable. I wanted to use this field, in conjunction with the UNSPSC to refine our GL Code assignments in a different project. I was told they were not accessible. I always found Drugs, Narcotics and Pharmacy to be ambiguous, and I wanted to add about five items to the list. I suppose it is possible to customize the list directly in the program library. I do not think this field is referenced anywhere else, which would minimize the downstream affect.
Have fun,
Red

I thought as much. We'll probably just assign Implant for implants and otherwise leave it blank.

Don't know your timeline for Xi - but at Inforum I was told that Attributes might not be available "as such" on Item master. So I'll be sticking with IC12s for Epic for now.

Good morning
We are implementing EPIC at our hospital and I need to know how the inventory items need to be set up in Lawson. Is Epic pulling from the IC12 inventory locations in Lawson? I was asked to combine 3 of the OR departments into one location, but each of those OR Departments have different Cost Centers. When setting up inventory locations in Lawson we have to put a cost center in IC02.
Has anyone else come across this issue if so how did you resolve it?
I need to set up three different locations:
The OR locations
The CathLab location (which will include IR)
The non-procedural items
Any help would be greatly appreciated.