EPIC MASTER FILE BUILD
By Susan North
Epic is a highly integrated system. The tight integration of the system can add to the challenges of
building the master files so that they work effectively across all applications. Usually, there is an owner
responsible for each of the master files. That owner may only have expertise in one of the Epic
applications, yet will be responsible for building the master file in such a way that it meets the needs of
all of the applications. Epic will provide its model system which is a great starting point. But much work
will need to be done so the build suits the needs of the organization and its own complexities. Here’s a
different approach to consider.
Sometimes it might be easier to abandon what is provided in the model system and start from scratch. Let
us take the procedure master file (EAP) as a case in point. Epic will import CPT, HCPCS and other codes into
your system during system build. This might be satisfactory if there is no need to interface the procedures.
But since the reality is Epic will most likely be interfaced with a lab, it becomes much more complicated.
Attempting to map what is provided in the import to the procedures that are performed by the laboratory is
similar to trying to fit a square peg into a round hole. For example, in the model EAP, there will be one
record for Glucose as there is only one CPT code for Glucose. The lab, however, will likely have more than
one test code that it performs for glucose: fasting, random, postprandial, etc. This will require multiple
records in the EAP. Another challenge is the wording of the CPT items can make it difficult to map the items
to the appropriate procedure on the lab side. The time it takes to accomplish the mapping can be
prohibitive. This is a case where it may be much easier to start from the beginning.
Start with a clean slate and instead import the records from the lab system. It eliminates the need to
try to match the lab procedures to the CPT descriptions, and lessens the amount of work needed with regards
to interfaces. This same methodology can be applied to category lists. Rather than use the lists provided in
the model system, build them so the lists match the interfaced systems. The specimen source category can be
built with the same records that the lab system or HIS utilizes. This eliminates the need to map the Epic
record to the lab record. Interfaces are complicated enough without adding unnecessary mapping and
translation requirements. Continue this approach through the other category lists that support EAP: specimen
type, priorities as additional examples.
EAP build may be assigned to someone from the ambulatory team, and that makes sense since procedures are
clinical. But input from someone from professional billing is required since the master file is shared. This
is where the challenges lie. The ambulatory team is most likely concerned with the procedure being orderable
and performable. The PB team will want to make sure it is chargeable when applicable. So though one person
may be ultimately responsible for the EAP build, it will take a team approach to ensure the build is
complete and works properly across applications.
The Component master file (LRR) may not be given much attention initially, especially if the decision is
made to have components build “on the fly” from the lab interface. This is acceptable; however LRR will
still require additional build if the providers wish to utilize last lab links, best practice alerts and
Results Review. And because Results Review is a rather large build, Epic may steer clients away from having
this be part of the initial build and address it as part of optimization. However, it may be easier to put
the work into the build up front, rather than wait. Obtain a list of all of the components from the lab and
add them to an import spreadsheet as a starting point. Then populate these additional fields on the
spreadsheet: External name, Abbreviation, Base name, Common name, and Reference Ranges for any back office
procedures. There is no need to enter reference ranges for interfaced procedures; the interface will handle
that. MPI type and MPI ID are required items for the interface mapping.
Here are some things to keep in mind while populating the spreadsheet:
- The External name is what displays on reports and in Results Review. Format the name using upper and
lower case to make it more appealing.
- Abbreviations are used in flow sheets. Formatting can be upper and lower case, 10 character limit,
no spaces.
- The Base name is used in the last lab link and best practice alerts. There is a 12 character limit,
must be all upper case, and cannot contain punctuation or spaces.
- The Common name is used by group editor to identify equivalent components, and is required for the
component to display in Results Review. Spaces are allowed but not symbols or punctuation, the character
length limit is 32, and must be all upper case.
- To ensure that equivalent components link properly, assign the same external name, abbreviation,
base name and common name to each record. For example, if there are multiple records for the component
glucose, each one should have the same external name, abbreviation, base and common name. If the LRR is
built correctly up front, then building results review will be a breeze.
Once the LRR master file build is complete, the interface can build additional components “on the fly” as
the lab adds new tests and components. There should be some sort of notification in place though when this
occurs, so the record can be manually updated to include the above mentioned fields. If the record is not
updated, the component will not display properly in Results Review and cannot be pulled in to text using the
last lab link.
Consider the same thought process for other category lists that will likely have records in other
systems. Provider specialties and types for example, can be built in Epic to match what the HIS already
uses. It is much easier to build these category lists for what makes sense for the organization instead of
requiring mapping and translations to occur via the interface, which is the case if the model system is
used. And chances are there will be additional entries needed as well as entries in the model system that
the organization has no use for, so it is likely build will be required anyway.
In conclusion, Epic is an incredible application and the concept of providing a model system certainly
has its merits. However, it is important to consider there are other options for building the system so it
works for each organization’s unique requirements. It is also important to keep in mind the tight
integration of the system. Use a team approach for building the master files so they function properly
across the applications and desired results are achieved for everyone.
If you have any questions, comments or feedback, please feel free to contact me at
snorth@getvitalized.com.