No More Guesswork: Real-Time Eligibility Done Right in Epic Tapestry

Configuring Real-Time Eligibility (RTE) can feel complex—but it doesn’t have to be. In this post, we’ll break it down and focus on the key questions you should be asking. When implemented effectively, RTE in Epic’s Tapestry module can reduce customer service volume, improve provider insight into benefits, and streamline access to care.

Trading Partner records

Trading partner (NTP master file) records in Epic are used to identify external entities with whom you share ANSI standard X12 files. They are particularly important if you exchange files with multiple external entities. You will need a unique trading partner record for each clearinghouse or unique entity that will connect with your system.

Items 100, 110 and 120 uniquely identify a trading partner. When a file is received, the system will look at the envelope information in the ISA segment to determine which trading partner is sending the file, and thereby determine if it should send a reply. Make sure to come to an agreement with each trading partner on what values will be sent in ISA06 and ISA08, as well as GS02 and GS03.

• Item 100: Interchange ID qualifier. ZZ is recommended.
• Item 110: Interchange ID. This field corresponds to incoming ISA06 values, and will be sent in the outgoing (response) ISA08.
• Item 120: Application code. This field corresponds to incoming GS02 values, and will be sent in the outgoing (response) GS03.

The aforementioned items ensure that the sender can connect the inquiry to your response.

If you use an Interconnect connection, items 150 and 160 identify the type of authentication used so it can process the web traffic received.

• Item 150 options:
  • Local: used for internal to Epic inquiries.
  • EMP: used when a username and password will authenticate each inquiry. (Recommended)
  • Windows: used when the windows login provides authentication.
  • LDAP: used when Active Directory connection provides authentication.
• Item 160
  • The Epic user ID. Contact Epic for a recommendation on which specific user record to include in this field.

Interface Profile records

Interface Profile (AIP master file) records tell Epic how to use data from incoming files, and how to format data in outgoing files. Two types of interface profile records are used for organizations who use Interconnect to manage real-time eligibility transactions, one for incoming and one for outgoing. You will need Bridges security to create and make changes to these records.

Incoming AIP 

Core Items:

• Queue: you can use any number. I recommend you match this to the .1 value of the AIP on which it is used.
• Direction: Incoming
• Physical Link: Interconnect
• Kind: Tapestry Incoming Electronic Eligibility Verification – Incoming Request (X12 270)
• Format: X12

Profile Variables:

• 270_REJECT_INDEMNITY_COVERAGE
  • Set to Yes if you don’t want to provide benefit details for plans you don’t manage.
• ENABLE_ANSI999_ACK
  • Set to No if you use Interconnect. Otherwise, the system will generate an ACK message that will create problems with the 271. The only time to use this is if you’re not providing a real-time response.
• GS02_SENDID
  • Trading partner ID in the GS02. This should correspond with the item 120 on the trading partner record.
• GS03_RCVRID
  • Trading partner ID in the GS03. This is the trading partner ID that your trading partner has on file to identify your organization.
• INTF_USER
  • Background user with security to access member eligibility information. Ask Epic for a recommendation. Value should correspond to NTP 160 for the trading partner using this interface.
• LAST_NAME_NORMALIZATION
  • True is recommended for most customers.
• MC_270_FILTER_INACTIVE_MEMBERS
  • Only filter inactive coverages for active members to respond with inactive coverages only when the member has no active coverages to send. If a member recently termed, this setting will let the provider know that the coverage existed but has an issue potentially to be resolved.
• MC_ALLOW_NO_MEMBER_ID
  • Set to Yes if you want inquiries to be able to match to members based solely on demographic information. 
• MC_IDC_RECORD_NO_MEMBER_ID
  • IDC records vary a lot from one customer to the next. Work with Epic and your enrollment team to create a unique IDC that works for your organization’s preferences. For this field specifically, the IDC is only used when you allow inquiries that are missing a member ID.
• MC_PPG_MATCH_BY
  • You can match the employer group (PPG) record by internal ID (PPG item 1), the Alternate ID (PPG item 15), or either.
• MC_RESPONSE_AIP
  • Link to the response interface profile spec you want used to generate response 271 files.
• X12_INCOMING_RESPECT_ACK_REQ
  • ISA14 of the incoming request file indicates whether the trading partner wishes to receive a TA1 acknowledgment. Setting this variable to Yes will respect the value in that data element. Setting it to No will send a TA1 in all cases, which may create problems for the trading partner. Because this can be set on each AIP uniquely, first determine if sending the TA1 will create issues with your trading partner.

Outgoing AIP

Core items:

• Queue: you can use any number. I recommend you match this to the .1 value of the AIP on which it is used.
• Direction: Outgoing
• Physical Link: Interconnect
• Kind: Tapestry Incoming Electronic Eligibility Verification – Outgoing Response (X12 271)
• Format: X12

Profile Variables:

• DEFAULT_HTTP_REACTIONS
  • Set to True if using an Interconnect connection. The default is False.
• GS02_SENDID
  • Trading partner ID in the GS02. This is the trading partner ID that your trading partner has on file to identify your organization. For this interface, you are the sender.
• GS03_RCVRID
  • Trading partner ID in the GS03. This should correspond with the item 120 on the trading partner record. For this interface, the trading partner is the receiver.
• INTF_USER
  • Background user with security to access member eligibility information. Ask Epic for a recommendation. This should not necessarily be the same as the user ID in the incoming interface profile.
• ISA01_AUTHQ
  • Included by default. Set to 00 if you are using Interconnect.
• ISA03_SECQ
  • Included by default. Set to 00 if you are using Interconnect.
• ISA14_ACK
  • Set to 0 if using Interconnect.
• SEND_RIDER_BENEFITS
  • Set to Yes if you use riders and want to include rider-based benefits.

X12 Settings and Message Delimiters

Default settings for message structure and message delimiters should work fine, but if you need to use a custom delimiter based on information in a trading partner’s companion guide, you can set them in this section.

ISA Fields:

• Sender ID qualifier (ISA05): ZZ (Mutually defined) is appropriate when your organization and the trading partner have agreed to use specific values in the ISA segment to identify the sender and receiver of various files.
• Sender ID (ISA06): Enter the trading partner ID used in the profile variable. Setting this value will help ensure that sending and receiving trading partners can identify one another when exchanging files.
• Receiver ID qualifier (ISA07): ZZ (Mutually defined) is appropriate when your organization and the trading partner have agreed to use specific values in the ISA segment to identify the sender and receiver of various files.
• Receiver ID (ISA08): Enter the trading partner ID used in the profile variable. Setting this value will help ensure that sending and receiving trading partners can identify one another when exchanging files.

Background monitor considerations

When you add interface profiles to the background monitor, the system typically sets the communication and filer/event statuses to Running, indicating it’s actively processing inquiries. However, for profiles used by Interconnect for Real-Time Eligibility, you’ll notice both statuses appear as Stopped. This is expected behavior and not a cause for concern—it doesn’t mean the interface isn’t functioning.

Tapestry Profile settings

Related group 50000 in the Tapestry Profile (Text) allows you to link a trading partner record with an interface profile.

• Item 50000: Link the trading partner (NTP) record of the sending trading partner.
• Item 50010: Can usually be left blank. If your organization has more than one interface profile for a single trading partner, you can use this field to specify how to tell the system which one to use based on the receiving trading partner ID. This may be helpful if you use business segmentation.
• Item 50020: Identify the incoming 270 interface profile.

Related group 10065 in the Tapestry Profile (Hyperdrive) allows you to link the incoming ANSI 270 service type code (sent in the EB segment) to the 271 response type. Validate with your organization what service types they want to include in their 271 responses. These will be benefits that are specifically defined in your benefits engine build, typically with the use of variables so you can report cost shares and limits within the 271 response. These are ANSI standard codes. 

Component Group settings

Service type codes

The connection between Profile settings and the benefits configured in the Benefits Engine is established through item 410 in the Component Group (CMG) master file. This mapping is customizable and varies by organization—giving you flexibility in how benefit information is returned during eligibility inquiries.

There are two primary approaches to this configuration:

Option 1: Integrated CMGs

This approach uses the same component groups for both adjudication and benefit display, each configured with defined service types.

When to use it: Required if you’re using riders, since any component group included in a rider’s benefit package must align with adjudication configuration.

Pros:

• Ensures alignment between adjudication logic and benefit display formulas.
• Reduces risk of discrepancies between what’s shown to users and what’s actually adjudicated.

Cons:

• Requires more complex adjudication table setup.
• Harder to keep in sync with display (CMD) configuration.

Option 2: Non-integrated CMGs

This method uses separate component groups and adjudication tables specifically for benefit display, distinct from those used in actual adjudication.

When to use it: Useful when you’re not using riders and prefer greater control over display organization.

Pros:

• Easier to manage and QA using naming and numbering conventions.
• Cleaner separation between display and adjudication logic.

Cons:

• Increases risk of misalignment between what’s displayed and what’s adjudicated.
• Requires careful updates in both places when benefits change.

Note: Regardless of approach, maintain clear documentation and workflow discipline. Both are valid—choose what works best for your team’s structure and your customer’s needs.

Special Consideration: Rider-Based Benefits

When a 270 eligibility inquiry is received, Epic will only consider a component group a match if it includes a procedure component, even if a service type is present.

If you’re not using riders and choose the non-integrated approach, you can simply add an “all procedures” component to each CMG used for display. This works well.

If you are using riders, avoid using a display-only component group with an “all procedures” component—this will cause Epic to match everything to the rider, skipping evaluation of regular benefit packages.

Recommendation: Always use integrated CMGs for rider benefit packages. They’re typically smaller and easier to manage, and this prevents unintentional overrides.

Display Names

Display names appear in:

• Adjudication review
• 271 eligibility responses
• Benefit inquiries
• MyChart and TapestryLink

Tips: 

• Analysts often prefer to omit display names so they can view the record names directly.
• Members and end users, however, benefit from clear, friendly names—ideally aligned with the language in official documents like a Summary of Benefits or Evidence of Coverage.

Work closely with your customer to ensure names strike the right balance: descriptive, readable, and aligned with benefit documentation.

Custom display adjudication formulas

Adjudication formulas (CMA master file) are used to calculate cost shares and can become complex—especially with limits (e.g., one copay per vendor per service date).

To avoid confusing end users:

• Use detailed formulas for adjudication logic.
• Create simplified display versions for benefit display and ANSI 271 responses.

Integrated CMG Approach:

• Adjudication tables (CML) will contain separate rows for calculation and display.
• Place adjudication rows above display rows and mark them as “exclude from display” in item 210.
• Use item 200 to specify the formula used in the display row.

Non-Integrated CMG Approach:

• Use completely separate tables and formulas for display.
• No need to manage mixed rows within a single table.

Whichever approach you choose, creating dedicated display formulas improves clarity and ensures users receive understandable benefit information.

Need a hand with Real-Time Eligibility in Epic Tapestry?

Canopii’s experts can help you untangle the complexities of benefits configuration and set up Real-Time Eligibility to reduce customer service call volume while ensuring HIPAA-compliant ANSI X12 exchanges.

Reach out anytime—we’re here to support you.

---

Peer Reviewer – Ryan Berg, EMPA
Ryan Berg is a Senior Epic Consultant and Certified Tapestry analyst with a strong background in managed care and eligibility functionality. Ryan has supported multiple institutions in adopting Epic’s RTE capabilities—configuring service-type mappings, fine-tuning adjudication logic, and ensuring seamless ANSI X12 interfaces. His peer review on this article leverages practical insights from rolling out RTE across diverse payer-provider environments and refining eligibility responses for improved care access.