a joint session with asc x12 and caqh core®

A Joint Session with ASC X12 and CAQH CORE®

ASC X12 Transactions + CAQH CORE Operating Rules = HIPAA Administrative Simplification

September 25, 2012

2

Session Learning Objectives

Attendees will be able to: • Understand the respective roles of ASC X12 and CAQH CORE

• Describe the CAQH CORE Operating Rule requirements for the first set of mandated operating rules effective January 2013, i.e. Eligibility for a Health Plan and Healthcare Claim Status

• Explain the key benefits of using healthcare standards and operating rules together

• Outline available resources and guidance for implementing both standards and operating rules through the use of an extensive set of tools provided by ASC X12 and CAQH CORE

3 © 2012 CORE. All rights reserved.

Brief Overview of ASC X12 And CAQH CORE


Multi-stakeholder collaboration of over 130 participating organizations that is developing industry-wide operating rules, built on existing standards, to streamline administrative transactions. CORE® participants maintain eligibility/benefits data for over 150 million lives, or approximately 75% of the commercially insured, plus Medicare and some Medicaid.

An industry utility that replaces multiple health plan paper processes for collecting provider data with a single, electronic, uniform data-collection system (i.e., credentialing). More than 1 million providers self-report their information to UPD and over 650 organizations access the system, including a range of public and private entities.

An objective industry forum for monitoring business efficiency in healthcare. Tracking progress and savings associated with adopting electronic solutions for administrative transactions across the industry.

CAQH® and Its Initiatives


Committee on Operating Rules for Information Exchange

• A multi-stakeholder collaboration established in 2005 • Mission: To build consensus among healthcare industry stakeholders

on a set of operating rules that facilitate administrative interoperability between providers and health plans

– Enable providers to submit transactions from the system of their choice (vendor agnostic) and quickly receive a standardized response

– Facilitate administrative and clinical data integration

• Recognized healthcare operating rule author by NCVHS

CAQH CORE carries out its

mission based on an integrated model

6 © 2012 DISA on behalf of ASC X12. All Rights Reserved

WHO IS ASC X12?

• Chartered and accredited by the American National Standards Institute

(ANSI) more than 30 years ago

• Develops and maintains EDI standards, technical reports, and XML

schemas which drive business processes globally

• ASC X12 membership includes technologists and business process

experts, encompassing many industries

• ASC X12 develops and publishes technical reports (TR3s) which are

commonly called Implementation Guides


WHO IS ASC X12?

• Some of ASC X12s TR3s have been adopted for use under HIPAA and are

commonly referred to as “HIPAA” Implementation Guides

• Current mandated version is 5010

• Visit www.x12.org for more information

http://www.x12.org/


About HIPAA-Adopted Transaction Standards

• HIPAA mandates adoption of standards for electronic healthcare administrative and financial transactions. Most HIPAA-adopted EDI transaction standards are ASC X12 standards o Current mandated version is ASC X12 v5010; mandated as of January 2012 o ASC X12 standards are based on the principle of electronic message exchange between communicating parties o Each ASC X12 EDI message unit is a set of data segments used for a single business transaction o For each standard, ASC X12 Technical Report Type 3 (TR3) specifies: Data segments to be used, segment sequence, whether

segments are mandatory or optional, when segments can be repeated, how loops are structured and used

Current Adopted Standards for HIPAA Transactions

X12 277 Health Care Claim Status Response

X12 834 Benefit Enrollment & Maintenance

X12 820 Health Care Premium Payment

X12 278 Healthcare Services Review Request

X12 837 Health Care Claims or Equivalent Encounter

X12 276 Health Care Claim Status Inquiry

X12 278 Healthcare Services Review Response

X12 270 Eligibility Benefits Inquiry

X12 271 Eligibility Benefits Response

X12 835 Health Care Claim Payment/Advice

Health Plan Sponsor

Health Care Provider

Registration and Referral Management

Billing and Collection

Finance Accounts Receivable

Health Plan

Enrollment/M

ember

ship Managem

ent

Finance and Treasury

Claim Processing

Utilization Review

Health Plan Membership

Financial Institution Financial Institution NACHA CCD+ TRN Trace Segment (Not based on ASC X12 Standards)


An Introduction to Operating Rules


What Are Operating Rules?

• The Patient Protection and Affordable Care Act (ACA) defines operating rules as “the necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard or its implementation specifications”

• They address gaps in standards, help refine the infrastructure that supports electronic data exchange and recognize interdependencies among transactions; they do not duplicate standards

Operating Rules: Key

Components

Transmission standards and

formats, e.g. ASC X12 Standards

Response timing standards

Error resolution Exception processing

Rights and responsibilities of all

parties

Security Liabilities


Why Operating Rules in Healthcare?

• Operating Rules are used in many other industries that have high volume transactions and require interoperability, e.g., ATM, direct deposit, cell phones

• The ACA Section 1104 and CMS regulations sets forth a healthcare operating rule mandate and scope

– Mandated healthcare operating rules build upon a range of standards – healthcare-specific (e.g., ASC X12) and industry-neutral (e.g., OASIS, W3C, ACH CCD+) – and support the national HIT agenda

• CAQH’s CORE initiative provides the industry with the necessary operating rules development support to move beyond specific individual trading partner contracts or regional arrangements to national operating rule guidelines


• Healthcare operating rules pair data content and infrastructure operating rules to help data flow consistently in varied settings and with various vendors

Applying CAQH CORE Operating Rules


CAQH CORE Operating Rules: Work in Unison with a Range of Standards

• Operating rules always support standards and are: – Adaptive

• They can facilitate interaction between healthcare and non-healthcare standards

– Flexible • They can achieve administrative simplification before, during and after versions of

a standard are officially adopted

– Iterative in nature • They can help the industry react more quickly to changes in business processes

• ASC X12 is a critical standard development organization (SDO) to administrative-focused operating rules as they help to drive further use and achievement of administrative data content goals to gain ROI for EDI


Foundation of Eligibility Data Content Operating Rules: ASC X12 Standards

ASC X12 Standards

CAQH CORE Operating

Rules

ROI Envisioned by Administrative Simplification

Building on the requirements of the ASC X12 standards and industry neutral standards, CAQH CORE Operating Rules add value as industry stakeholders gain the additional benefits of using a consistent infrastructure to deliver and receive robust and important patient eligibility and benefit data.

ASC X12 270/271 Requirements in v5010 • Eligibility Status (yes/no) • Date • Health Plan Name (if known)

CAQH CORE Rule Requirements • Health Plan Name (if available in responding system) • Patient financials (deductible, co-pay, co-insurance)

– In and out of network variances – Family and individual – Health Plan and benefit variances

• Enhanced Patient Name Verification • Standard use of AAA Error Codes PLUS infrastructure rules to generate data flow: response time, connectivity, system availability


Vision of Administrative Simplification

1. Jack uses his mobile device to log onto Dr. Summa’s, secure website. Jack checks appointment availability, chooses his desired slot, updates his insurance information, and sees that his insurance was verified.

2. Dr. Summa’s practice management system re-verifies Jack’s insurance and determines if there is any secondary coverage.

3. Dr. Summa’s office sends Jack an appointment confirmation email which indicates fee/co-pay.

4. Jack arrives at Dr. Summa’s office and registers. Any changes to his eligibility, benefits and payment requirements are identified and noted in the electronic health record (EHR) system and/or PMS.

5. After examining Jack, Dr. Summa determines that he needs a referral to Dr. Zippa, a cardiologist.

6. Dr. Summa’s EHR submits an electronic referral request and obtains an authorization. Dr. Summa electronically signs the EHR, which creates a real-time transaction to the office billing system which determines if edits are needed.

7. The edited electronic claim is sent to Jack’s health plan with validated diagnosis and procedure coding. The claim is adjudicated and within seconds Dr. Summa’s office receives an electronic payment and remittance advice.

8. At check-out, the office staff explains the charges to Jack, answers questions and accepts his payment. If the claim had been denied, the staff would have worked with Jack and/or Dr. Summa to make necessary corrections and resubmit the corrected claim before Jack left the office.

9. He also receives a message on his mobile device from Dr. Zippa inviting him to make an appointment.

10. Jack receives a monthly email from his health plan summarizing the services he has received from all of his providers. The summary is as easy to read as his credit card bill.

11. Through the use of utilities, standards, operating rules and automated work flow, Jack, Dr. Summa and Dr. Zippa all have experienced reduced costs and increased efficiency and Jack’s quality of care has improved.

Post-Care Pre-Care Care Delivery


The Strategic Business Case for Health Plans

• The CAQH CORE Operating Rules for eligibility/benefits result in an optimization of financial workflows*

• Health plans that adopt the Phase I CAQH CORE Operating Rules have reported: – Increased total electronic eligibility up 33% in one year

• Due to shift towards electronic methods, health plans can handle increased verification volumes with the same staff

– Pairing implementation with organizational-specific eligibility/benefits initiatives yields strong results

• Providers rapidly take advantage of new capabilities, e.g., real-time transactions • Extensive communication to providers, targeted outreach as needed, and collaboration with

vendor partners improve adoption

• Results achieved by Phase I implementing health plans include: – Payback was less than one year (considers only shift from telephone to electronic

verification) • One-time costs of implementation/Phase I CORE Certification $ 542,800 • Annual ongoing costs $ 49,200 • Annual savings due to shift from telephone to electronic $ 2,666,800

– Progress towards having all visits verified • Ratio of verifications to claims Up from .63 to .73

*IBM assessed results achieved by Phase I CAQH CORE Operating Rules early adopters (represents 33 million covered lives and 1.2 million providers)


ACA Section 1104: Mandated Operating Rules


Section 1104 of the ACA (H.R.3590) “…Establishes new requirements for administrative transactions that will improve the utility of the existing HIPAA transactions and reduce administrative costs”

Highlights • Updates initial August 2000 HIPAA regulation for transaction standards and code sets

given landscape has significantly changed, and unnecessary healthcare costs/burden must be removed from the system

• Requires Department of Health and Human Services (HHS) to appoint a “qualified non-profit entity” to develop a set of operating rules for the conduct of electronic administrative healthcare transactions

• Administrative and financial standards and operating rules must: – Enable the determination of eligibility and financial responsibility for specific services prior to or at

the point of care – Be comprehensive, requiring minimal augmentation by paper or other communications – Provide for timely acknowledgment, response, and status reporting

• HIPAA covered entities and business associates engaging in HIPAA standard transactions on behalf of covered entities must comply

• Health plans must file a statement with HHS confirming compliance; financial penalties for health plans are significant

Administrative Simplification: ACA Section 1104

http://www.gpo.gov/fdsys/pkg/PLAW-111publ148/pdf/PLAW-111publ148.pdf


ACA Mandated Operating Rules Compliance Dates: Required for all HIPAA Covered Entities

NOTE: Operating rules apply to HIPAA covered entities; beyond HIPAA compliance penalties, certification penalties for health plans will apply.

Implement by

January 1, 2013

Operating Rules for: • Eligibility for health plan • Claims status transactions

Implement by

January 1, 2014

Operating Rules for: • Electronic funds transfer (EFT) transactions • Health care payment and remittance advice (ERA)

transactions

Implement by

January 1, 2016

Operating Rules for: • Health claims or equivalent encounter information • Enrollment and disenrollment in a health plan • Health plan premium payments • Referral certification and authorization • Health claims attachments

Compliance Dates for ACA Mandated Operating Rules


Three dates are critical for industry implementation of the first set of ACA mandated Operating Rules There are two types of penalties related to compliance1

ACA Federal Compliance Requirements: Highlights & Key Dates

1 CMS OESS is the authority on the HIPAA and ACA Administrative Simplification provisions and requirements for compliance and enforcement. The CMS website provides information on the ACA compliance, certification, and penalties and enforcement process. 2 According to CMS, regulation detailing the health plan certification process is under development, and they will release details surrounding this process later this year; CAQH CORE will continue to offer its voluntary CORE Certification program and will share lessons learned with CMS as the Federal process is developed. 3 Covered life for which the plan’s data systems are not in compliance; shall be imposed for each day the plan is not in compliance

Key Area HIPAA Mandated Implementation ACA-required Health Plan Certification

Dates First Date

January 1, 2013 Compliance Date

Second Date December 31, 2013

Health Plan Certification Date

Third Date No Later than April 1, 2014 Health Plan Penalty Date

Description

Who: All HIPAA covered entities

Action: Implement CAQH CORE Eligibility & Claim Status Operating Rules

Who: Health plans Action: File statement with HHS certifying that data and information systems are in compliance with the standards and operating rules2

Who: Health plans

Action: HHS will assess penalties against health plans that have failed to meet the ACA compliance requirements for certification and documentation2

Applicable Penalties

Amount: Due to HITECH, penalties for HIPAA non-compliance have increased, now up to $1.5 million per entity per year

Amount: Fee amount equals $1 per covered life3 until certification is complete; penalties for failure to comply cannot exceed on an annual basis an amount equal to $20 per covered life or $40 per covered life for deliberate misrepresentation

http://www.cms.gov/Affordable-Care-Act/04_ComplianceCertificationandPenalties.asp

http://www.cms.gov/enforcement/


• Status: The first set of operating rules has been adopted into Federal regulation

– December 2011, CMS adopted CMS-0032-IFC as a Final Rule; industry implementation efforts underway for the January 1, 2013 effective date

• Adopted Phase I and II CAQH CORE Operating Rules for the Eligibility & Claim Status transactions, except for rule requirements pertaining to Acknowledgements*

• Highlights CORE Certification is voluntary; further defines relationship between standards and operating rules and analysis of ROI from operating rules implementation

• ACA Section 1104 requires all HIPAA covered entities be compliant with applicable HIPAA standards and associated operating rules

Status of Mandated Eligibility & Claim Status Operating Rules: Less Than Four Months Until Compliance Date

*On September 22, 2011, NCVHS issued a letter recommending Acknowledgements be adopted as formally recognized standards and the CAQH CORE Operating Rules for these standards also be recognized.

The complete set of CAQH CORE Eligibility & Claim Status Operating Rules are available free of charge HERE.

http://edocket.access.gpo.gov/2011/pdf/2011-16834.pdf

http://ncvhs.hhs.gov/110922lt3.pdf

http://www.caqh.org/COREv5010.php


Mandated Eligibility & Claim Status Operating Rules: January 1, 2013 Requirements

*NOTE: In the Final Rule for Administrative Simplification: Adoption of Operating Rules for Eligibility for a Health Plan and Health Care Claim Status Transaction, requirements pertaining to use of Acknowledgements are NOT included for adoption. Although HHS is not requiring compliance with any operating rule requirements related to Acknowledgements, the Final Rule does note “we are addressing the important role acknowledgements play in EDI by strongly encouraging the industry to implement the acknowledgement requirements in the CAQH CORE rules we are adopting herein.”

A PowerPoint overview of the Phase I & II CAQH CORE Rules is available HERE; the complete rule sets are available HERE.

Rules High-Level CAQH CORE Key Requirements

Dat

a C

onte

nt

Eligibility & Benefits

Respond to generic and explicit inquiries for a defined set of 50+ high volume services with: • Health plan name and coverage dates • Static financials (co-pay, co-insurance, base deductibles) • Benefit-specific and base deductible for individual and family • In/Out of network variances • Remaining deductible amounts • Enhanced Patient Identification and Error Reporting requirements

Infr

astr

uctu

re

Eligibility, Benefits &

Claims Status

• Companion Guide – common flow/format • System Availability service levels – minimum 86% availability per calendar week • Real-time and batch turnaround times (e.g., 20 seconds or less for real time and

next day for batch) • Connectivity via Internet and aligned with NHIN direction, e.g., supports plug and

play method (SOAP and digital certificates and clinical/administrative alignment) • Acknowledgements (transactional)*

http://www.cms.gov/Affordable-Care-Act/02_OperatingRulesforHIPAATransactions.asp

http://www.cms.gov/Affordable-Care-Act/02_OperatingRulesforHIPAATransactions.asp

http://www.caqh.org/Reform/IFR_COREPI&IIOverview.PDF

http://www.caqh.org/COREv5010.php


CAQH CORE EFT & ERA Operating Rules: Overview

Rule High-Level Requirements

Dat

a C

onte

nt

Uniform Use of CARCs and RARCs

(835) Rule

• Identifies a minimum set of four CAQH CORE-defined Business Scenarios with a maximum set of CAQH CORE-required code combinations that can be applied to convey details of the claim denial or payment to the provider

Infr

astr

uctu

re

EFT Enrollment Data Rule

• Identifies a maximum set of standard data elements for EFT enrollment • Outlines a straw man template for paper and electronic collection of the data elements • Requires health plan to offer electronic EFT enrollment

ERA Enrollment Data Rule • Similar to EFT Enrollment Data Rule

EFT & ERA Reassociation

(CCD+/835) Rule

• Addresses provider receipt of the CAQH CORE-required Minimum ACH CCD+ Data Elements required for reassociation

• Addresses elapsed time between the sending of the v5010 835 and the CCD+ transactions

• Requirements for resolving late/missing EFT and ERA transactions • Recognition of the role of NACHA Operating Rules for financial institutions

Health Care Claim Payment/Advice

(835) Infrastructure Rule

• Specifies use of the CAQH CORE Master Companion Guide Template for the flow and format of such guides

• Requires entities to support the Phase II CAQH CORE Connectivity Rule • Includes batch Acknowledgement requirements • Defines a dual-delivery (paper/electronic) to facilitate provider transition to electronic

remits

Complete CAQH CORE EFT & ERA Operating Rules Set available HERE.

http://www.caqh.org/ORMandate_EFT.php


• Remaining operating rule mandate will address the following transactions: – Health claims or equivalent encounter information

– Enrollment and disenrollment in a health plan

– Health plan premium payments

– Referral certification and authorization

– Claims attachment

• CAQH CORE is committed to using its open process to develop a set of draft rules for consideration to fulfill the third set of Federally mandated operating rules

Third Set of Mandated Operating Rules: January 2016 Compliance Deadline

http://ncvhs.hhs.gov/120301p7.pdf


Understanding How Operating Rules Build Upon ASC X12 Transaction Standards

Eligibility and Benefits Transaction Processing


Mandated CAQH CORE Eligibility & Claim Status Operating Rules: At a Glance

Rule Types Transactions Rule Areas Rule References

Key Considerations

Data Content Eligibility &

Benefits ASC X12 270/271

Patient Financial Data Content 154 & 260

Data Content Rules apply only to the Eligibility & Benefits transaction

Normalizing Patient Last Name & AAA Error Code Reporting

258 & 259

Infrastructure

Eligibility & Benefits

and Claims Status

ASC X12 270/271 ASC X12 276/277

Response Time & System Availability

155, 156, 157, & 250*

Interdependencies of the CAQH CORE Infrastructure Rules must be considered

during implementation Connectivity 153, 270 & 250*

Companion Guide 152 & 250*

*CAQH CORE Rule 250 applies the CAQH CORE Infrastructure Rules to the ASC X12 276/277 Claims Status transaction.

http://www.caqh.org/pdf/CLEAN5010/154-v5010.pdf














Mandated CAQH CORE Eligibility Operating Rules: Delivering More Patient Financials Supporting ASC X12

• Problem addressed by operating rules - Minimal delivery of eligibility information including variable support for service type requests; limited patient

eligibility and benefits information at the point of service; constrains design of all payer solutions

• CAQH CORE Operating Rules require that health plans and information sources that create a 271 response to a generic 270 inquiry must include:

– The name of the health plan covering the individual (if available within the responding system)

– Provide patient financials for the static financials of co-insurance, co-payment, and deductible, and return the remaining deductible amount; include in-network and out-of-network coverage and financials for required service types codes (STCs)

• Relationship between ASC X12 Standard Transaction and CAQH CORE Operating Rules regarding data content

– The ACS X12 V5010 TR3 highly recommends the return of patient financial data where the CAQH CORE Operating Rules require specific patient financial data to be returned

– CAQH CORE Operating Rules 154 and 260 require the return of patient financial data

– The standard and the operating rules further drive the use of eligibility transaction set as the provider derives extended business benefits during the member/provider interactions

Eligibility Transaction ASC X12 270/271CORE Rule 154 and 260 applies to 51 key services:

Confirm patient benefit coverage and co-pay, in/out of network variances, coinsurance and base deductible information PLUS remaining deductible amounts


• For health plans and information sources: ASC X12 271 response to a generic ASC X12 270 inquiry must include:

– The name of the health plan covering the individual (if available within a responding system)

– Patient financials for base and remaining deductible, co-insurance and co-payment for Service Type Code 30 – Health Plan Coverage and for each of 12 CORE-required service type codes when amounts are different for Health Plan Coverage (STC =30) and including any in/out of network variances

Mandated CAQH CORE Eligibility Operating Rules: Content From Health Plans and Information Sources

1 – Medical Care 35 – Dental Care 33 – Chiropractic 47 – Hospital 48 – Hospital – Inpatient 50 – Hospital – Outpatient 86 – Emergency Services 88 – Pharmacy 98 – Professional (Physician) Visit – Office AL – Vision (Optometry) MH – Mental Health UC – Urgent Care


• Also must support an explicit ASC X12 270 inquiry for 51 CORE–required service type codes; ASC X12 271 response to explicit ASC X12 270 inquiry must include Patient financials for base and remaining deductible, co-insurance and co-payment for each of 51 CORE-required service type codes when amounts are different than for Service Type Code 30 – Health Plan Coverage, plus any in/out of network variances

• 1 – Medical Care • 48 – Hospital – Inpatient • 98 – Professional (Physician) Visit – Office • 2 – Surgical • 50 – Hospital – Outpatient • 99 – Professional (Physician) Visit – Inpatient • 4 – Diagnostic X–Ray • 51 – Hospital – Emergency Accident • A0 – Professional (Physician) Visit – Outpatient • 5 – Diagnostic Lab • 52 – Hospital – Emergency Medical • A3 – Professional (Physician) Visit – Home • 6 – Radiation Therapy • 53 – Hospital – Ambulatory Surgical • A6 – Psychotherapy • 7 – Anesthesia • 62 – MRI/CAT Scan • A7 – Psychiatric Inpatient • 8 – Surgical Assistance • 65 – Newborn Care • A8 – psychiatric Outpatient • 12 – Durable Medical Equipment Purchase • 68 – Well Baby Care • AD – Occupational Therapy • 13 – Facility • 73 – Diagnostic Medical • AE – Physical Medicine • 18 – Durable Medical Equipment Rental • 76 – Dialysis • AF – Speech Therapy • 20 – Second Surgical Opinion • 78 – Chemotherapy • AG – Skilled Nursing Care • 33 – Chiropractic • 80 – Immunizations • AI – Substance Abuse • 35 – Dental Care • 81 – Routine Physical • AL – vision (Optometry) • 40 – Oral Surgery • 82 – Family Planning • BG – Cardiac Rehabilitation • 42 – Home Health Care • 86 – Emergency Services • BH – Pediatric • 45 – Hospice • 88 – Pharmacy • MH – Mental Health • 47 – Hospital • 93 – Podiatry • UC – Urgent Care

Mandated CAQH CORE Eligibility Operating Rules Data Content From Health Plans and Information Sources (cont’d)


• For both generic & explicit ASC X12 270 inquiries, return of patient financial responsibility is discretionary when reporting on these CORE-required service type codes:

• For all responses, if financial responsibility is different for in–network vs. out–of–network, must return both amounts

• High–level rule requirements for providers, provider vendors and information receivers

– Detect and extract all data elements to which this rule applies as returned by the health plan (or information source) in the ASC X12 271

– Display or otherwise make the data appropriately available to the end user without altering the semantic meaning of the ASC X12 271 data content

– 1 – Medical Care – A8 – psychiatric Outpatient – 35 – Dental Care – AI – Substance Abuse – 88 – Pharmacy – AL – Vision (Optometry) – A6 – Psychotherapy – MH – Mental Health – A7 – Psychiatric Inpatient

Mandated CAQH CORE Eligibility Operating Rules Content From Health Plans and Information Sources (cont’d)


Mandated CAQH CORE Eligibility Operating Rules: Normalizing Patient Last Name

• Problem addressed by rule - Transactions may be rejected when last name submitted by the healthcare provider does not

match the last name held by the health plan

• CORE Rule 258 requires health plans to normalize submitted and stored last name before using the submitted and stored last names

– Remove specified suffix and prefix character strings, special characters and punctuation

– If normalized name validated, return ASC X12 271 with CORE-required content

– If normalized name validated but un-normalized names do not match, return last name as stored by health plan and specified INS segment

– If normalized name not validated, return specified AAA code

• Relationship Between ASC X12 Standard and CAQH CORE Operating Rules – CORE Rule 258 increases the chance of a subscriber/dependent match at the health plan and therefore

increases the chance of returning benefit and financial data

– The rule also allows for the health plan to inform the provider of the last name stored in their system

Eligibility Transaction v5010 270/271CORE Rule 258

Patient Identification: Normalizing Patient Last Name


• Problem addressed by rule - Lack of specificity and standardized use of ASC X12 AAA error codes; providers unable to

determine which information is missing or incorrect when an eligibility and benefits inquiry does not return a valid match

• CORE Rule 259 requires health plans to return a unique combination of one or more AAA segments along with one or more of the submitted patient identifying data elements in order to communicate the specific errors to the submitter

– The receiver of the ASC X12 271 response is required to detect all error conditions reported and display to the end user text that uniquely describes the specific error conditions and data elements determined to be missing or invalid

• Relationship Between ASC X12 Standard Transaction and CAQH CORE Operating Rules

– Consistent use of ASC X12 AAA Error Codes – Inform providers which data elements are in error so that specific corrections can be made

for future transactions

Mandated CAQH CORE Eligibility Operating Rules: AAA Error Code Reporting Rule

Eligibility Transaction v5010 270/271CORE Rule 259

AAA Error Reporting: Health Plan Eligibility Response


CAQH CORE Industry Support


CAQH CORE Implementation Resources and Tools

• Ensure your organization is ready to comply with the January 1, 2013 mandated Eligibility & Claim Status Operating Rules deadline

– Analysis & Planning Guide for Adopting the CAQH CORE Eligibility & Claim Status Operating Rules: Provides guidance for Project Managers, Business Analysts, System Analysts, Architects, and other project staff to complete systems analysis and planning

– Education Events: CAQH CORE holds frequent, free industry education sessions • Joint WEDI and CAQH CORE Webinar: Be Ready for January 2013 HHS Deadline Implementing

and Testing Mandated Healthcare Operating Rules: Wednesday, 09/26/12, 2 - 3:30 pm ET; register HERE

• CAQH CORE Town Hall Call: Tuesday, 10/30/12, 3 – 4 pm ET; registration information forthcoming

– FAQs: CAQH CORE has a list of FAQs to address typical questions regarding the operating rules; updated FAQs being loaded to website as appropriate given mandates

– Request Process: After reviewing other tools & resources, information requests can be submitted to the CAQH CORE Request Process at [email protected]

• Complete voluntary CORE Certification – Phase I & Phase II CORE Certification Master Test Suites provide guidance on the

stakeholder types to which the rules apply and working with trading partners

– Contact technical experts as needed at [email protected]

http://www.caqh.org/Host/CORE/CAQHCORE_Analysis&PlanningGuide.pdf

http://www.caqh.org/Host/CORE/CAQHCORE_Analysis&PlanningGuide.pdf

http://www.caqh.org/CORE_Education_Events.php

http://www.wedi.org/users_only/meeting/RegistrationFormPublic/edit?meetingId=1FFC600000733&prepop=1

http://www.caqh.org/CORE_faq.php

mailto:[email protected]


http://www.caqh.org/CORE_step_by_step.php

http://www.caqh.org/pdf/CLEAN5010/CORECertificationTestSuite-v5010.pdf

http://www.caqh.org/pdf/CLEAN5010/COREPIITestSuite-v5010.pdf



“Top Ten” Eligibility & Claim Status FAQs

1. What are the Federally mandated CAQH CORE Eligibility & Claim Status Rules requirements for entities to support real time and/or batch processing?

2. What happens when a real time response is not received within the required 20-second window?

3. How is the 20-second response window tracked? 4. Do the CAQH CORE Rules require that I create companion guides if my organization is not

already using them? 5. What is meant by the CAQH CORE Connectivity Rule “safe harbor” requirement? 6. We need to add some new error codes and messages that are not listed in the CAQH CORE

Phase II Connectivity Rule. Is this allowed? 7. What patient financials are health plans required to provide in an ASC X12 271 response to a

ASC X12 270 inquiry? 8. Why are some Service Type Codes (STCs) identified as “discretionary” in CAQH CORE Rule

154 and 260? What information must a health plan return in response to the “discretionary” STCs?

9. How does a health plan identify the correct error condition description to display when multiple error conditions are mapped to the same code?

10. Do the Federally mandated CAQH CORE Operating Rules apply to Direct Data Entry (DDE)?


CAQH CORE Formal Request Process: Key Steps

Step 1: Request Submission

• Primarily through [email protected] email address • Requests also sourced from emails/phone calls to CAQH CORE staff

Step 2: Request Acknowledgement

• CAQH CORE staff emails submitter acknowledging receipt of request and providing an estimated response time

• Response time depends on request type/complexity (5-30 business days) o Types of requests generally: (1) Operating rule clarifications (2) ACA compliance questions (3)

Voluntary CORE Certification inquiries (4) General information requests (links to key resources, updated contact information, etc.)

o Three levels of complexity: low complexity, medium complexity, high complexity

Step 3: Request Response

• Draft responses complete formal review process by CAQH CORE experts depending on request type/complexity; as noted below, CORE process and coordination with other organizations is critical

Step 4: Request Follow-Up as Necessary

• Requests integrated into rule-development and maintenance processes as appropriate (e.g., development of new CAQH CORE FAQs, potential future operating rule ideas, or CAQH outreach to government or other entities) o Under CORE’s consensus-based process, rule modifications, should they occur, are categorized

as major (e.g., additional requirements) or minor (e.g., changes due to a typo or grammatical error); major changes occur only after the CORE Participants approve, by vote, such modifications



CAQH CORE Request Process

Substantive/Major Change (e.g., Changes to rule

requirements or new rule ideas)

CAQH CORE Evaluation of Request

Source of Requests, e.g.,

• CORE Request Process: [email protected] • Entities completing voluntary CORE

Certification

Types of Requests, e.g.,

• Clarification of rule requirements • Suggestions for new requirements to address additional

transactions, data content, infrastructure, etc.; request to remove or change requirements

• Notice of typographical/grammatical errors • Analyze possible conflict with standard / question on standard

Review of proposed modification through

formal CAQH CORE Rules Development Process

Review of proposed modification by CAQH

CORE staff and adjustment made if appropriate

CORE Voting Membership Ballot: • Requires 60% of membership for quorum • Two-thirds (66.67%) must vote to approve

Non-substantive/Minor Change (e.g., Typographical/grammatical errors,

clarifications or new FAQ)

Review of proposed modification through with

relevant entities (e.g., CMS, ASC X12, NACHA);

modifications made available on CAQH CORE website

Alignment with Federal Efforts (e.g., new versions of standards –

v5010)

Request Received



ASC X12 Resources and Processes


ASC X12’S ROLE IN OPERATING RULES

• The ASC X12 004010X092 (4010 270/271) was the base TR3 used for

the voluntary Phase 1 and Phase 2 Eligibility and Benefit Inquiry and

Response Operating Rules.

• When ASC X12 005010X279 (5010 270/271) was adopted, the Phase 1

and 2 Operating Rules were modified.

© 2012 DISA on behalf of ASC X12. All Rights Reserved



• ASC X12 develops different versions and releases of TR3s; operating

rule requirements may be integrated into a subsequent TR3 version in

which case such requirements are removed from the operating rules

• Specific items named within Operating Rules are not necessarily

incorporated into future TR3s; they are reviewed on a case by case basis

and must be approved at multiple levels before being finalized in a TR3

publication



• There are different paths for requesting revisions, depending on the type

of information that will be revised and the ASC X12 work product that the

information is presented in

• The following slides point you to the starting place for requesting changes

to several types of information


SUBMITTING CHANGE REQUESTS TO ASC X12

You can request a change to any ASC X12 TR3 at

changerequest.x12.org

Alternatively, you can request a change to HIPAA mandated TR3s via the

Data Maintenance Standard Organization DSMO

www.hipaa-dsmo.org

http://changerequest.x12.org/

http://www.hipaa-dsmo.org/



It is not necessary to submit the same request into both the ASC X12 and

DSMO change request systems. A change submitted in either process will

get appropriately routed between the organizations.



Changes to the ASC X12 Standard or an internal code list:

• Submit a Data Maintenance work request or Code Maintenance Request

through the www.X12.org.

http://www.x12.org/



Changes to the External Codes Lists

• ASC X12 does not control the revision processes for the External Code

Sets utilized in the ASC X12 Standards. Contact the owner of an

External Code Set directly for instructions on revisions to that code set.


ASC X12’S INTERPRETATION PROCESS

Technical or Implementation questions may be submitted to ASC X12.

Such a question is called a Request for Interpretation (RFI). Submit an

RFI at:

www.x12.org/x12org/subcommittees/x12rfi.cfm

An RFI and the associated response is reviewed and approved at several

levels before being published as a final ASC X12 interpretation.

http://www.x12.org/x12org/subcommittees/x12rfi.cfm


ELIGIBILITY & BENEFIT INQUIRY/RESPONSE

• ASC X12 270/271

• The 270 can ask a simple question, or ask a complex question:

• Is Jane Doe eligible for service today?

• Are Jane Doe’s benefits different if she’s sick vs. if she’s well?

• Do Jane Doe’s benefits change depending on the Place of Treatment?


ELIGIBILITY & BENEFIT INQUIRY/RESPONSE

• The response information, for example Subscriber/ Dependent demographic

info, may be used for other transactions such as the 837.

• It can also be used to integrate the 271 response with claim submission.

49

L E G A L D I S C L A I M E R

This presentation is for informational purposes only.

• The content should not be construed as legal advice.

• If you have questions regarding:

• ASC X12 transactions or SDO activities, please email [email protected]

• CAQH CORE Operating Rules, please email [email protected]

• Take advantage of the many industry references available at www.x12.org

and www.caqh.org



http://www.x12.org/

http://www.caqh.org/


As seen in other industries, healthcare operating rules working in unison with transaction processing standards will address a full range of requirements needed to complete an evolving and industry-shared vision

Administrative Simplification: The Future

51

Question & Answer


Appendix


ASC X12 Change Process – Overall Flow Change Request and Impact Analysis Processes

Initi

al S

cree

ning

TGA/

WG

2W

orkg

roup

(s)

Exte

rnal

to

TGA/

WG

2Su

bmis

sion

Ø TGA/WG1 reviews Change Request

Ø Opt In

TGA/WG1:Ø Assigns to Primary WGØ CC:s TGA/WG2 cochairsØ Change database Admin

Change DB Admin:Ø Enters the CR into OnlyConnectØ Coordinates Communication to

the submitter directly or through TGA/WG1

Requests come from WGs as:Ø Part of a WG DiscussionØ A Written RequestØ A Result of an RFI

TGA/WG1:Ø Returns the

completed response to DSMO

TGA/WG1:Ø Submits a

Change Request into the DSMO

Ø Reviews Ø Enough Information? Ø Accepted?

Ø ReviewØ Complete Impact

AnalysisØ Confirm/Change

Primary WGØ Prioritizes

Ø Change to Standard?

Ø External Impact?

Ø All WG completed

Ø Close the CR

Primary Workgroup:Ø Coordinates discussion within their WGØ Coordinates discussion with all WGs

that opted in on CRØ Once solution/agreement is met, will

close the CR (review complete)

Workgroup(s):Ø If WG opted in, Will discuss

with WG membersØ Participate in multi-WG

discussions coordinated by primary WG

Ø DM Created

X12 Groups:Ø TASØ PRBØ Other Task

Groups

Ø DSMO

Ø Submitter Completes DSMO

NoTGA/WG1

informs DSMO

Y Y Y N N

TGA/WG2Notifies

TGA/WG1

Y

Ø • A submitter can be an organization, an individual, public comment, DSMO or WG representative.

Ø • Organizations may include SCO, CMS, HHS, AHA, AMA, ADA, etc.

Y


ASC X12 Change Processes – Data Maintenance User (thru Subcommittee or

independently)Submits New DM to DISA

X12 Ballot (Regular, Re-ballot )

DISA holds DMs untilTAS’ next Interim meeting

PRB Reviews Process

TAS Reviews DMs1

TAS Recommends for ballot

TAS Refers toSubcommittee

Sub-Committee(s)3

• Reviews DM• Assures work is

completed• Notifies TAS

Disposition of DM

TAS • Reviews Ballot Results • Replies to voter

comments

TAS determines Non-Substantive changes

TAS determines Substantive changes

Returns to PRB

TAS determines no changes required, recommends for

Publication

Disposition of DM Ballot

TAS holds Open Forum for Continuing Disapprovals

Disposition of Rebuttal BallotContinuing Disapprovals Less then 10%

Disapproval

DISA Returns DM to

User

X12 Rebuttal Ballot

Disposition of Open Forum Modifications / Revisions Comments resolved

PRB ReviewsProcess

1TAS review New DM at interim and Referred DM at Standing Meeting)2When a DM is returned to TAS by PRB, TAS determines the appropriate next steps and forwards to the group for fixing the problem.3A DM may be referred, shared, to one or more Subcommittees. Shared DM’s are coordinated by One Subcommittee and reviewed by all Subcommittees indicating an interest in the work.

TASNotifies DISA

TG/WG change processes are followed

as appropriate.

Disposition of PRB

PRB Approves Process

PRB notifies TAS2 That Process not

Approved

Disposition of PRB


PRB notifies TAS That Process not

Approved

DISAPUBLISHES


ASC X12 Change Process - Code Maintenance Request

A CMR may be submitted by anyone using the CMR form

on the X12 web site.

DISA • Holds CMR”s until the

next X12 member comment period opens prior to the next TAS meeting.

• Advises the voting population of ASC X12 via Email the opening of a 21 day member comment period.

• Places CMR’s on TAS Agenda

TAS Reviews CMR’s at the Next Full TAS Meeting

TAS Recommends for Publication

Refer toSubcommitteeDispostion of CMR

1Shared CMR’s are coordinated by One Subcommittee and reviewed by all Subcommittees indicating an interest in the work.

A CMR number is assigned and the submitter receives a

confirmation

PRB Reviews Process

Disposition of PRB


PRB notifies TAS2 That Process not

Approved

DISA Returns CMR to submitter with TAS Comments

Sub-Committee(s)1

• Reviews DM• Assures work is

completed• Notifies TAS

TG/WG change processes are followed

as appropriate.

TAS • Does not approved - on

technical merit.• Request is returned with

comments to DISA.

DISAPUBLISHES

The CMR tool is only used for a simple code addition. The proposed code can point to an existing Code Source.

The submitter prepares and submits the CMR according to instructions on the ASC X12 Website: http://www.x12.org/x12org/X12Standards/CMR/SubmitterInformation.cfm

http://www.x12.org/x12org/X12Standards/CMR/SubmitterInformation.cfm



a joint session with asc x12 and caqh core®

Documents