AMB 400 Flashcards
Procedure Records (EAP):
Nearly all clinical and billing applications use procedure (EAP) records, making the procedure master file one of the most integrated master files in Epic. When placing orders, Epic classifies any order that is not a medication as a procedure (referrals to specialties, imaging, labs, immunizations, etc.).
Overall, procedure records are used for:
1. Placing orders
2. Documenting that a procedure was performed
3. Triggering charges
Due to the wide variety of procedures that exist, there will be a range of records needed to accommodate the procedure build. It is your responsibility to configure, and occasionally build, procedure records as efficiently as possible while ensuring the changes you make impact only the appropriate procedures. This is especially important since procedure records are often shared across teams.
Levels of the Procedure Hierarchy
Procedure build relies on a hierarchy to give procedures the settings they need. A hierarchy is a collection of records organized in a specific order. This order is then defined as specific to general. Settings at more specific levels in the hierarchy override settings at more general levels.
The procedure hierarchy has three levels:
1. Procedure (EAP)
2. Procedure Category (EDP)
3. System Definitions (LSD)
(These are listed from most specific to most general)
Purpose of the Procedure Record (EAP)
Defines unique settings for a procedure.
Purpose of the Procedure Category Record (EDP)
Defines shared settings for a group of related procedures.
Purpose of the System Definitions (LSD)
Defines shared settings on a system wide level.
Settings Controlled by the Procedure Hierarchy
Consists of:
Procedure> Procedure Category> System Definitions
Records in the procedure hierarchy impact defaults, buttons, allowed values, and more!
Default Value: Defines values that are pre-populated in a field.
Item Buttons: Determines the buttons located to the right of a field.
Allowed Values: Determines the available values for a field.
The order composer configuration (OCC) record:
Is an important record for procedure build. It defines the following settings:
- Controlled Items: Defines fields that are required or recommended in an order composer.
- Summary Items: Defines details that appear in the summary sentence in the orders cart.
- Display Items: Defines the fields that appear in an order composer.
Linking the Procedure Hierarchy and OCC Records Together:
OCC records can be linked to any level in the procedure hierarchy. Like other settings in the procedure hierarchy, only the most specific OCC settings will be used. While OCC records can be linked to procedure (EAP) records, it is not common to do so.
If all lab orders should have a default Order Class of “Lab”, where would be the most efficient place to specify that setting?
a. In each lab procedure record.
b. In the procedure category used for all lab procedures.
c. In System Definitions
In the procedure category used for all lab procedures.
If all procedures should have a default Priority of “Routine”, where should you specify that value?
a. In each procedure record.
b. In each procedure category.
c. In System Definitions.
In System Definitions
For each of the following, determine if the setting is made in the procedure hierarchy or the OCC:
a. Available buttons in the order composer: __________________
b. The fields on the left side of the order composer: _______________
c. The details that appear in the summary sentence: ________________
d. Default values for fields in the order composer: ___________________
a. Available buttons in the order composer: Procedural Heirarchy
b. The fields on the left side of the order composer: OCC
c. The details that appear in the summary sentence: OCC
d. Default values for fields in the order composer: Procedural Heirarchy
To properly build records you need to know how they will be used by clinicians. To accomplish this, you need to talk to:
Subject Matter Experts are often providers or other end users who know the real-world contexts of how a record or tool will be used.
Clinical Informaticists have clinical knowledge as well as build knowledge. They can act as a liaison between you and clinicians, ensuring that information and expectations are communicated successfully.
Procedure Order Composer Configuration (In Text)
This screen (clincal administration >management options. View system definitions> procedure scheduling, tasks, page down to Procedure Order Composer Configuration): is where OCC records are linked to System Definitions. OCC records are paired with a context to determine when a certain OCC should be used. This ensures that orders have appropriate display, summary, and controlled items based on the patient encounter or the tool being used.
EpicCare Order Type is used throughout Epic to determine:
How orders should be handled.
Some examples include:
- Order transmittal rules evaluate order type as a property
- Chart Review will sort different orders by order type
- Print groups can change what appears based on order type
- Extensions may use order type to define an action
A user will not be able to sign a procedure unless there is an EpicCare Order Type defined.
Order (ORD) records are created when?
When a clinician signs an order for a Procedure (EAP) or Medication (ERX) in an outpatient order mode
These ORD records store information about an order such as date, authorizing provider, status, class, and more! Procedure orders with a status of normal, future, or standing will generate one or more ORD records to store information about the order and the results.
Normal: Normal status orders generate a single ORD record which is released immediately. That record is referred to as a child order and stores information about the signed order details as well as the results for that order.
Future: Future status orders generate two ORD records: a parent and a child order. Both store details about the order. The child order is an exact replica of the parent order but is capable of storing results for that order.
Standing: Standing status orders will have one parent ORD record and multiple child ORD records. Just like future orders, the child records are where result information is stored.
Parent and child orders are all created simultaneously when an order is signed. Normal status orders are released upon signing and acted upon within the same encounter. Future and standing child orders will either be automatically or manually released for further documentation.
In a procedure category for assay labs, two buttons are set up for Class. However, when users order the iron assay lab, they see four buttons for Class. How is this possible? (Choose one of the following):
a. The four buttons are defined at the System Definitions level.
b. The four buttons are defined in the OCC attached to the procedure.
c. The four buttons are defined at the procedure level.
d. Two of the buttons are coming from the procedure, and the other two are coming from the procedure category.
C: The system searches for details using the procedure hierarchy, so there must be four buttons defined in the iron assay procedure record. As a note, the OCC does NOT control buttons.
There is a lab test with a specified default status. For just this order, you want to hide the Status field in the Order Composer so it cannot be changed by users. How can this be accomplished? (Choose all that apply)
a. Remove the status as an allowed value in the procedure.
b. Create an OCC record that does not include status as a display item.
c. Create an OCC record and set status as a “hidden” item.
d. Link the OCC you created to the procedure.
B and D: Create an OCC record that does not include Status as a display item, and link that OCC to the procedure. Without a display item, Status will not appear to the users.
True or False: The “Additional Order Details” dropdown in an order composer can only be set up in an OCC record that you link to System Definitions.
False. OCCs (with an ordering context of Additional Outpatient Order Details in this instance) can be linked to all three levels of the hierarchy.
True or False: Default status cannot be defined in System Definitions.
True. Default status can only be defined at the procedure or procedure category level.
“Building block” records are:
Additional records needed to complete a procedure’s build.
The purpose of a building block record is to be available for procedures when needed. For example, not all procedures will need a SmartText to provide scheduling instructions or a linked immunization.
Examples:
Question (LQL)
SmartText (ETX)
“Chargeable” Procedure (EAP)
Result Component (LRR)
Immunization (LIM)
Question (LQL) (Building block record)
an be linked to:
Procedure
Procedure Category
Question records that appear within an Order Composer have a type of “order-specific” and can be restricted by patient age, sex, or other criteria.
When different questions are linked to both a procedure and procedure category, the builder can configure whether questions from both levels should appear or if only the procedure’s questions appear.
Question records that appear in the Immunizations activity have a type of “immunization question”.
ie. “What symptoms do you notice when you have a reaction?”, should appear in the Order Composer for all food allergy procedures.
SmartText (ETX) (Building block record)
Can be linked to:
Procedure
Procedure Category
Typically used for instructions and comments.
To use a SmartText for a specific purpose, you must assign it the correct functional type.
“Chargeable” Procedure (EAP) (Building block record)
Can be linked to:
Procedure
A “chargeable” procedure (a procedure whose record purpose is chargeable) is used to file a charge to an account when an order has been performed, such as a procedure, service, or supply order.
Result Component (LRR) (Building block record)
Can be linked to:
Procedure
When a procedure with linked result component records is signed, those components will appear in the Enter/Edit Results activity. This is useful for clinical support staff who document results. Result component records can specify high/low reference ranges and appropriate values.
Immunization (LIM) (Building block record)
Can be linked to:
Procedure
Immunization records are used to document the details of an immunization administration. For an immunization to appear automatically within the Immunization activity, it must be linked to an orderable procedure. Once that procedure is signed, the linked immunization is available.
List some of the “Building Block” records a procedure could use
OCC, SmartText, chargeable EAP, result component, order specific question, etc…
True or False: If questions are linked to a procedure and procedure category, questions from both levels can display to the user.
True
Questions work differently than other items in the procedure hierarchy. If there are questions linked in a procedure and its category, questions from both levels will display to the user. This behavior can be overridden in the procedure record so that only the procedure-level question(s) display.
Questions that appear in an order composer have a type of
order-specific question
Questions that appear in the immunization activity have a type of
immunization question
What determines where a question appears within the order composer
The OCC
(controls display items)
Which of the following “building block” records can only be linked to the procedure level in the procedure hierarchy? (Choose all that apply):
a. “Chargeable” Procedure (EAP)
b. Immunization (LIM)
c. SmartText (ETX)
d. Result Component (LRR)
A, B, and D: These three building block records can’t be linked to a procedure category or system definitions. A SmartText (ETX) can be linked to either the procedure or the procedure category.
True or False: To document a patient-reported immunization, a procedure record must exist.
False - Patient-reported immunizations only need an immunization (LIM) record and can be entered in the immunization activity.
Your users want the question, “Is the patient pregnant?” to appear for all diagnostic imaging tests, when appropriate, based on patient information. What steps should you take to complete this build? (Choose all that apply)
a. Create an order-specific question record with the appropriate question.
b. In the question record enter appropriate restrictions for age and sex.
c. Link the question record to the appropriate procedure category.
d. Verify the “questions” display item is in the OCC impacting the procedures.
A, B, C, and D: An order-specific question record should contain the appropriate question and restrictions. It should be linked to the procedure category impacting the diagnostic imaging orders since it is a group of related procedures. In order for a question to appear in the order composer there must be a “questions” display item in the OCC impacting the procedures.
What is a Preference List
It is list is a collection of records (medications, procedures, diagnoses, etc.) that allow users to easily find and select the entries they most commonly use. Preference lists can be built by builders for the purpose of simplifying or restricting the options that are available to a group of users, or they can be created on-the-fly by individual users that want to have their own list of frequently-used records.
Preference lists are available across Epic’s clinical applications. However, the number and type of available preference lists depends on the application. EpicCare Ambulatory can be configured to use preference lists for:
Medications, procedures, and order panels
Reason for visit codes
Common diagnoses
Level of service codes
Flowsheet templates
Supplies
…and more!
Two Masterfile’s used for building Preference lists:
Preference list Editor (EDP)
Preference list Composer (LPF)
Preference List Editor (EPD)
Lists a collection of non-orderable records.
Does not allow you to override details of the records. An EPD preference list is simply a collection of records.
Examples include reason for visit, common diagnoses, level of service codes, and speed buttons.
The Preference List Editor is used to build preference lists for non-orderable records such as diagnoses, reason for visit, and level of service codes. These preference lists are often used to create a collection of speed buttons. Speed buttons save time, and clicks, and can be created for:
SmartTexts
Reasons for visit
Levels of service
Visit diagnoses
…and more!
Preference List Composer (LPF)
Lists a collection of orderable records.
Allows you to override details of the records. Such as default selections, additional questions that appear in the order-composer, or pre-written comments and instructions.
Examples include medications, procedures, and order panels.
The Preference List Composer is used to build preference lists for orderable items and override the values set in medication and procedure records. Often the same order will be added to a preference list multiple times, with different default values, to saves clinicians time and clicks.
Types of Orders (LPF) Preference Lists
- System preference lists are lists intended for use by groups of users in your facility. System preference lists (LPF) can be specified at any level of the profile (LPR) hierarchy or facility structure. Administrative settings determine what types of preference lists are enabled, how they appear, and how they can be used.
- User preference lists are specific to an individual clinician. A clinician specifies orders that are commonly used. Depending on the clinician’s security and on system settings, users can modify their user preference list from the Preference List Composer or from an order entry activity.
- Frequent Orders preference lists are lists created by the system for individual clinicians when they place an order at least four times with the same order details. These lists will hold up to 100 orders and present clinicians with the orders that they most often sign at their current (EAF) location.
LPF preference lists appear on the Browse, Preference List, and Facility List tabs of the Order and SmartSet Search window. NOT DATABASE
Flowsheet macros
Enable users to complete their flowsheet charting more efficiently by pulling in commonly documented values simultaneously. Macros can be created by the build team, and users can also create their own.
For real-world build, you would consult the clinicians that use this flowsheet to learn the values they most commonly document
Flowsheet Structure
Template (FLO): contain collections of group and row records. In the Flowsheets activity, they display as tabs. You can search within the activity to look up additional templates.
Templates can also be embedded in a navigator section when specified in a section’s navigator configuration (VCN) record. You’ll learn about this in the next chapter.
Group (FLO): are used to organize and collect row records. They help divide the flowsheet into logical sections.
Rows (FLO): are the distinct questions or fields in the flowsheet in which users enter data.
FLO Record Types:
Since groups and rows are both in the FLO master file it is important to define Row Type when creating an FLO record.
Flowsheet Groups have a row type of “Flowsheet Group”.
Flowsheet Rows can have a variety of functional purposes and available features. In ambulatory settings, “Data” is the most common row type and is used for entering discrete information about a patient.
Naming conventions are important! To easily identify if a FLO record is a group or a row, make sure you create records with clear naming conventions.
FLO record prefixes:
‘Group: G
Row: R
A flowsheet row (FLO) with a Row Type of Custom Formula can do mathematical calculations. In training, a custom formula row has been pre-built for you. You just need to add your new row to the formula.
The custom formula can look to row records that have a Value type of Numeric Type or Custom List. For custom list rows, each Value needs a numeral as its Abbreviation.
When writing a Custom Formula, list row record IDs as either {Row ID} or [Row ID]. Using parentheses around a number will only be recognized as a number and not a record ID.
Cascading Flowsheet
Is a flowsheet that hides many more groups and rows that could appear if users needed them! The “trigger row” will un-hide, or cascade, a separate group corresponding to that selection.
To configure cascading, follow two basic steps:
- Set initially hidden groups or rows as Start Removed in the record they are linked to.
- Configure logic in a row record that will trigger when the hidden groups or rows should appear. This row is often referred to as the “trigger row”.
Note: The term “trigger row” is used to refer to a row that contains cascading rules.
Groups that should be hidden will be marked “Start removed”
If you wanted to mark the flowsheet group as “Start Removed”, which record would you open to find that setting?
The template record.
If you wanted to mark the flowsheet row as “Start Removed”, which record would you open to find that setting?
The group record.
Flowsheet Smartlinks
A common clinician request is to include flowsheet data in a note. This data can be pulled into a note using a SmartLink.
Two SmartLinks commonly used pull in flowsheet data are:
.FLOW: Pulls in flowsheet data for specified rows and groups from the current encounter. Displays selected values.
.FLOWABBR: Pulls in flowsheet data for specified rows and groups from the current encounter. Displays selected abbreviated values.
Row type
Defines the purpose for an FLO record.
Some examples include:
Data, Flowsheet Group, Custom Formula, etc…
Value type
Defines the type of information you can enter in a row.
You have a flowsheet that cascades immediately when the criteria is met. Instead, you want a window to appear to verify the assessment you want to add to the flowsheet. How can you accomplish this? (Choose one of the following):
a. Change the cascading Method to “Add without prompting users”.
b. Change the comparison operator to “equals, with prompt”.
c. Change the Abbreviation for the “yes” value in the custom list.
d. Change the cascading Method to “Prompt users”.
D: The cascading method determines how the system reacts when cascading occurs and whether the user is prompted or not.
Advanced Navigator Build
Clinicians in different specialties need to review and document different information during an encounter. As a clinical builder, you can configure navigators to fit the needs of these specialties.
Customizing navigator sections with Navigator Configuration (VCN) records, will show or hide sections with Extension (LPP) records, and the steps needed to create a dual pane navigator.
Navigator Configuration (VCN) Records
They control how a section (within the Navigator LVN (Remember Template/Topic/Section)) record looks and behaves. In many cases, navigator configuration records serve as a “bridge” between the section and another record or activity. In other cases, navigator configuration records can control a section’s behavior, available options, or appearance. Without a VCN, navigator sections have very few configurable option
Navigator Configuration Section Types
Each navigator configuration record has a section type, which determines what configuration options are available. Navigator configuration records can only be linked to sections with a similar type. Here are some examples of common configuration types:
- Flowsheet: Configure a navigator section to display a flowsheet template.
- Print Group Report: Configure a navigator section to display a report that is either expanded or collapsed.
- SmartForm Flowsheets: Configure a navigator section to display a SmartForm (LQF).
- Medication Documentation: Customize options for the Med Documentation section, which is used for medication reconciliation.
- Activity Link: Create “jump to…” sections that take you to other activities in the patient’s chart.
- Meds & Orders: Control the details that appear in the Meds & Orders section based on the specialty.
…and many more!
Embed Flowsheets in a Navigator
Specialties like using flowsheets to collect data specific to their discipline, but asking clinicians to open the Flowsheets activity and search for an appropriate template interrupts their workflow. Using a navigator configuration record, you can link a flowsheet to appear within a navigator section, making the documentation process much smoother.
Duplicate a Navigator Section for Displaying Flowsheets
Epic releases hundreds of standard navigator sections. In many cases these navigator sections are hard coded to behave a certain way. Epic has also created sections that are intended to be duplicated and modified. These Epic released sections have appropriately predefined settings, like the Prog ID and View Path, that are essential for a section to function properly.
Builders who want to create a new section should only do so by duplicating an Epic-released section. This ensures that the Prog ID and View Path is accurate. Avoid editing the Prog ID or View Path unless you work with an Epic Technical Services (TS) staff member.
Topic Level Override
In the previous scenario you created a navigator configuration record and linked it to your section. As a result, all navigators using that section will see the changes configured by that VCN. This is appropriate when all the clinicians using that section want those changes, but what if only some clinicians want those changes?
For example, consider a navigator section used for medication documentation. Most departments that use that section want the same settings for it, so a VCN record with those settings is linked directly to the section. The pediatrics department, however, wants different settings than everyone else. In order to give the pediatrics department the settings they want, without changing the settings for everyone else, a VCN needs to be built and linked to a navigator topic instead of the section.
A VCN linked to topic will override a VCN linked to a section. As long as the pediatrics department has a unique topic that contains the medication section, linking a VCN to that topic will make the change for only them!
CER Rule
Extension records can evaluate information on their own but can link to CER rules for more complex evaluations.
Filter extensions (LPP) are used to make sections appear under certain conditions and will often reference a CER rule to determine the criteria.
Extension Records (LPP)
Extension records with a type of visit navigator filter can be linked to navigator sections to cause them to appear or be hidden.
True or False: VCN records can be linked to a navigator section directly or to the topic that contains that section.
True
Which record can control what displays within a navigator section as well as its behavior? (Choose one of the following)
a. Extension (LPP)
b. Topic (LVN)
c. Rule (CER)
d. Navigator Configuration (VCN)
D: The Navigator Configuration record is used to embed records like flowsheets or reports into a navigator section, as well as change things like button options, button captions, help text, default selections, and more!
What combination of records can be used to determine when a navigator section appears in a patient’s workspace? (Choose all that apply)
a. Extension (LPP)
b. Topic (LVN)
c. Rule (CER)
d. Navigator Configuration (VCN)
A and C: Extension records can be linked to CER Rules to evaluate information and filter navigator sections.
When creating a dual pane navigator, each pane requires at least one ___________. (Choose one of the following)
a. Extension (LPP)
b. Topic (LVN)
c. Rule (CER)
d. Navigator Configuration (VCN)
B: Topic (LVN)
True or False: A navigator configuration record linked to a section will impact all templates using that section, unless it is being overridden by a navigator configuration record linked to a topic.
True
Navigator sections can only link to navigator configuration records of the same ___________. (Choose one of the following)
a. Master file
b. Class
c. Type
d. Value
C: Type determines available screens in a VCN as well as where it can be linked.
SmartSet Structure and Records
SmartSets help clinicians work through common encounters quickly and efficiently by putting multiple items for an encounter in one place. These items include SmartTexts, diagnoses, orders, level of service codes, and more! By using a SmartSet, common encounters take fewer clicks and have fewer documentation errors.
SmartSet Structure - Clinician’s Perspective
From a clinician’s perspective, a SmartSet consists of sections, which contain subsections, which contain selectable items.
SmartSet Records - Builder’s Perspective
From a builder’s perspective, a SmartSet (PRL) contains sections, which link to SmartGroups (OSQ), which link to items.
BestPractice Advisories (LGL)
BestPractice Advisory (LGL) records are used to evaluate data and suggest or restrict SmartSet build. BestPractice Advisory records, or BPAs for short, ensure that clinicians have the appropriate SmartSet build for each unique patient.
Suggest and Restrict a SmartSet
You can increase the usefulness of a smartset by causing them to be suggested or restricted based on information from the encounter at hand.
Ie. Reason for visit diabetes…. smartset suggested is for diabetes
Male child : can not select prenatal smartset
Smart Group
only links items that have a similar purpose
CER Rules
CER rules are records in the CER Masterfile. CER rules evaluate data and return either TRUE or as FALSE. For ambulatory build they commonly evaluate information about the patient and where they are being seen, such as age, reason for visit, lab results, medications, history, department or provider specialty, and more! Note that CER rules are different than workflow engine rules or order transmittal rules.
CER rules are made up of criterions that contain three basic components: properties, operators, and values.
CER component: Property
The data point that is being evaluated. A CER rule can contain multiple properties.
Examples: reason for visit, department, family history.
CER component: Value
The data stored for a given property. Think of it as the “answer” to a property.
Examples: 18, pediatrics, diabetes.
CER component: Operator
The relationship between a property and a value.
Examples: equals, not equals, greater than, less than.
CER component: Criterion
A line within a CER rule consisting of a property, value(s), and operator.
