NCPDP CMS-0032-IFC Recommendations

Page 7

September 1, 2011

Centers for Medicare & Medicaid Services

Department of Health and Human Services

Attention: CMS-0032-IFC

P.O. Box 8013

Baltimore, MD 21244-8013

RE: CMS-0032-IFC

Dear CMS;

The National Council for Prescription Drug Programs (NCPDP) submits the following comments regarding the Adoption of Operating Rules for Eligibility for a Health Plan and Health Care Claim Status Transactions.

NCPDP is a not-for-profit ANSI-accredited Standards Development Organization consisting of more than 1,600 members who represent drug manufacturers, chain and independent pharmacies, drug wholesalers, insurers, mail order prescription drug companies, claims processors, pharmacy benefit managers, physician services organizations, prescription drug providers, software vendors, telecommunication vendors, service organizations, government agencies and other parties interested in electronic standardization within the retail pharmacy services sector of the health care industry.

Recommendation Summary:

NCPDP recommends the IFR clearly state an exclusion for electronic prescribing’s use of the ASC X12 270/271. The retail pharmacy industry uses this transaction.
“Table 2. Could an Operating Rule Conflict with a Standard” needs to be corrected and clarified.
Operating rules must not modify the situations contained in the implementation specifications. The “situationality” cited in the IFR must be corrected.
NCPDP recommends that the Phase I CORE 153: Eligibility and Benefits Connectivity Rule, version 1.1.0, March 2011 and the Phase II CORE 270: Connectivity Rule, version 2.2.0, March 2011 be removed from the regulation.
By naming the entire CORE document, other CAQH CORE requirements such as a CORE Enforcement Policy, Guiding Principles, Conformance, HIPAA Attestation, and Pledges are therefore included. NCPDP recommends that all of these requirements need to be explicitly stated as not mandated.
NCPDP realizes that the regulation must be effective 01/01/2013, but recommends 01/01/2014 as the date for industry compliance.
NCPDP disagrees that the only burden will be a conversion to a companion guide template. There will be an additional burden for health plans, providers, clearinghouses, and vendors to analyze, code, test, and implement the changes needed to the transaction sets made by the operating rules.

See attached recommendation detail.

NCPDP appreciates the opportunity to work with the Office of E-Health Standards and Services (OESS). Please contact us if you have questions or require further clarification.

For over 30 years NCPDP has been committed to furthering the electronic exchange of information between healthcare stakeholders. NCPDP Telecommunication Standard is the standard used for eligibility, claims processing, reporting, and other functions in the pharmacy services industry as named in HIPAA. The NCPDP SCRIPT Standard, Telecommunication Standard, and the Formulary and Benefit Standard are the standards in use in electronic prescribing as named in MMA.

Thank you for the opportunity to provide input.

For direct inquiries or questions related to this letter, please contact

Lynne Gilbertson

VP, Standards Development

NCPDP

Direct:

1803 Longview Drive

Mt Juliet, TN 37122

P: (615) 754-0445

Sincerely,

Lee Ann C. Stember

President

National Council for Prescription Drug Programs (NCPDP)

9240 E. Raintree Drive

Scottsdale, AZ 85260

(480) 477-1000 x 108

cc: NCPDP Board of Trustees

Recommendation Detail:

I. Background

Table 1. Current Adopted Standards for HIPAA Transactions (p 40459)

NCPDP recommendation:

The table denotes “NCPDP 5.1 and D.0 Retail pharmacy drug claims (telecommunication and batch standards)”.

The table does not list NCPDP Batch Version 1.2 which supports Telecommunication Standard Implementation Guide Version D.0 and Version 5.1. We request that this be added.

B. Operating Rules Mandated by the Affordable Care Act (p 40460)

“The role of operating rules is to support the adopted standards for health care transactions in order to foster and enhance uniform use of the adopted standards and implementation guides across the health care industry. Standards and operating rules overlap in their functions to increase uniformity, but differ in their purposes. While standards are mainly concerned with the content transmitted in a transaction, operating rules provide for the method of how the information should be transmitted, as well as the elimination of certain situationality in the use of data content contained in the standards. Situationality refers to the fact that many transaction requirements only apply if the situation is presented. For example, in the 271 eligibility response transaction, the health plan name is only required when a specific plan name exists for the plan for which the individual has coverage.

Operating rules augment the standards in the following three important ways:

§ They contain additional requirements that help implement the standard for a transaction in a more consistent manner across health plans. For example, when a provider currently sends an eligibility for a health plan inquiry to a health plan, the standard allows responses ranging from a simple "yes" or "no", to the inclusion of a complete range of information. The operating rule requires the health plan to return patient eligibility and financial responsibility for a specified list of service type codes including, but not limited to, dental, vision, medical, hospital inpatient, and emergency care. This requirement ensures that a provider, who submits the same inquiry to multiple payers, receives a consistent response for an eligibility for a health plan inquiry. This reduces the number of customized transactions when dealing with multiple health plans, thus saving both time and money.

§ They address ambiguous or conditional requirements in the standard and clarify when to use or not use certain data elements or code values. For example, the standard may leave it to the discretion of the health plan whether or not to return the health plan's name in a particular field, creating the possibility of inconsistency in health plan responses. An operating rule may require that the health plan name always be returned and that it always be returned in one particular specified manner. This encourages uniformity and alleviates the problem of providers receiving inconsistent information.

• They specify how trading partners, including providers, should communicate with each other and exchange patient information, with the goal of eliminating connectivity inconsistencies. Currently, individual health plans specify the transmission methods they expect each of their trading partners, including providers, to use for electronic transactions. Mandating one uniform method decreases the amount of work and inconsistencies providers experience when dealing with multiple payers with differing transmission methods.”

NCPDP recommendation:

The rule should be changed to state that operating rules must not be allowed to modify the situations contained in the implementation specifications. If the situation needs to be modified to accommodate the industry’s business requirements, the impacted entities need to submit a change request to the appropriate SDO to modify or eliminate the situation. Per the Patient Protection and Affordable Care Act (hereafter referred to as the Affordable Care Act (ACA) definition which HHS is adopting, operating rules are not defined in the standard or implementation specification.

Operating rules must not duplicate, contradict, or further restrict the format, content or usage requirements of any electronic transaction defined by an SDO standard and associated implementation guide. Such operating rules shall not impose further restrictions on the electronic transactions as defined in the associated implementation guide published by an SDO.

NCPDP agrees that reducing the number of transmission methods can reduce the amount of work and inconsistencies during implementation. NCPDP has demonstrated for pharmacy and electronic prescribing that via recommendations/guidance in implementation specifications, FAQs, payer templates, guidance documents, etc that the industry does develop consensus-based processes that improve implementation and adoption.

The pharmacy and electronic prescribing industry do not agree that operating rules should stipulate transmission standards. Billions of transactions occur each year in these industries due to trading partners agreeing to using one of the limited methods of transmission that are available. Further, this could limit innovation by requiring operating rules first address transmission. Of all the barriers to increased exchange of data, transmission methods are one small piece of implementation.

II. Provisions of the Interim Final Rule with Comment Period

A. Definition of Operating Rules (p 40461)

“If a business rule or guideline is necessary for the electronic exchange of information, it must also be one that is ‘‘not defined by’’ a HIPAA standard or its implementation specifications in order to meet the definition of an operating rule. We consider a business rule or guideline that does not duplicate what is in the standard to be one that is not defined by the standard. Business rules and guidelines that duplicate what is in the standard are not operating rules under our interpretation.”

NCPDP recommendation:

NCPDP agrees that “Business rules and guidelines that duplicate what is in the standard are not operating rules under our interpretation”. NCPDP finds the statement “We consider a business rule or guideline that does not duplicate what is in the standard to be one that is not defined by the standard” confusing. Operating rules must not duplicate, contradict, or further restrict the format, content or usage requirements of any electronic transaction defined by an SDO standard and associated implementation guide.Operating rules should only be created to clarify implementation instructions within the bounds of the implementation guide rules.

NCPDP offers below, first the original table from the regulation, then the original table with comments on each row. Finally, we offer a modified table that reflects applicable rows, with more accurate statements.

TABLE 2. COULD AN OPERATING RULE CONFLICT WITH A STANDARD? (p 40462)

“Table 2 illustrates what we consider to be a conflict by presenting hypothetical scenarios that illustrate when an operating rule could or could not conflict with a standard.”

TABLE 2. COULD AN OPERATING RULE CONFLICT WITH A STANDARD? (Original Table)

Statement in the
Standard / Statement in
the Operating
Rule / Does the Operating
Rule's Statement
Conflict with the
Standard's
Statement? / Justification
"X is recommended." / "X is "required." / No / It is possible for an entity to comply with both the standard and the operating rule.
"X is not required." / "X is required." / No / It is possible for an entity to comply with both the standard and the operating rule.
"X cannot be required." / "X is required." / Yes / It is impossible for an entity to comply with both the standard and the operating rule.
"X is required." / "X is required." / No / It is possible for an entity to comply with both the standard and the operating rule.
(However, to the extent that the statement in the operating rule duplicates the statement in the standard, the operating rule statement would not be considered an operating rule.)
X is at the discretion of
person #1. Person #2 cannot require it." / "X is required." / No / It is possible for an entity to comply with both the standard and the operating rule.
"X is required." / "X is required, so is Y." / No / It is possible for an entity to comply with both the standard and the operating rule.
"X is required. No other
can be required." / "X is required, so is Y." / Yes / It is impossible for an entity to comply with both the standard and the operating rule.

NCPDP recommendation:

According to the definition in the legislation as well as the definition being adopted - Operating rules are not defined by the standard or implementation spec.” If a data element is situational in the implementation guide, an operating rule cannot make it required.

In column 1, the regulation should use the exact phrases that are contained in the standard and implementation specification. Column 2 should then contain the phrases that CORE uses.

The table oversimplifies situations that cannot be simplified in this manner. Later, we offer what a modified table should state.

TABLE 2. COULD AN OPERATING RULE CONFLICT WITH A STANDARD? (Commented Table)

Statement in the
Standard / Statement in
the Operating
Rule / Does the Operating
Rule's Statement
Conflict with the
Standard's
Statement? / Justification / NCPDP Comment
"X is recommended." / "X is "required." / NoYes / It is possible for an entity to comply with both the standard and the operating rule. / NCPDP does not agree that column 3 is “No”. The operating rule cannot force a requirement that the standard does not support.
A standard might recommend a situational use because not every entity has a business case to require the use. For example for Medicare Part D Eligibility to the Facilitator:
It is recommended that when a pharmacy has multiple eligibility periods to check, the Eligibility inquiry should be from the oldest date of service forward. For example, if the current date is Ø2/Ø1/2ØØ7, and the pharmacy needs to verify eligibility for past claims of 11/22/2ØØ6, 12/15/2ØØ6, and Ø2/Ø1/2ØØ7, the first eligibility verification is submitted with a Date of Service of 11/22/2ØØ6.
The operating rule cannot then require something that cannot be performed by every entity.
Or the standard might recommend general procedures.
It is recommended that provider software not allow a reversed prescription to be deleted from the pharmacy system without first receiving a response from the processor related to the reversal.
The operating rule cannot then require something that the standard has determined is a recommendation.
Any statement in the operating rule would be built upon the standard’s situation with an if/when statement offering more guidance.
Recommendations are accompanied with if/when guidance. The operating rule has to stay within that if/when guidance; the operating rule cannot force a simple “is required”.
"X is not required." / "X is required." / No / It is possible for an entity to comply with both the standard and the operating rule. / This is not a good example. The standard would state situational or optional or not used. We do not believe there is an example of a standard that states “is not required” without some further clarification.
We do not agree with the third column “No” - The operating rule cannot override the standard.
"X cannot be required." / "X is required." / Yes / It is impossible for an entity to comply with both the standard and the operating rule. / Although NCPDP agrees that this is a conflict, this is not a good example. The standard would state situational or optional or not used. We do not believe there is an example of a standard that states “cannot be required” without some further clarification.
We agree the operating rule cannot override the standard.
"X is required." / "X is required." / No / It is possible for an entity to comply with both the standard and the operating rule.
(However, to the extent that the statement in the operating rule duplicates the statement in the standard, the operating
rule statement would not be considered an operating rule.) / While there is a “However” noted in the fourth column, this is not a true example of an operating rule.
NCPDP agrees in this case there is no need for an operating rule. Duplication of information contained in the standard does not constitute an operating rule.
This example causes confusion by being present and should be eliminated.
X is at the discretion of
person #1. Person #2 cannot require it." / "X is required." / No / It is possible for an entity to comply with both the standard and the operating rule. / This is not a valid example. Person 1 and 2 concepts are not used in the industry.
If X is sent, the receiver is to ignore if they do not need, per HIPAA references.[1]
The operating rule cannot require something that the standard places within situational or optional requirements.
"X is required." / "X is required, so is Y." / No / It is possible for an entity to comply with both the standard and the operating rule. / This is not a valid example. Y cannot be required unless the standard supports this connection, and that means there is no need for the operating rule.
"X is required. No other
can be required." / "X is required, so is Y." / Yes / It is impossible for an entity to comply with both the standard and the operating rule. / This is not a valid example.
We agree this is a conflict. The operating rule cannot override the standard.

TABLE 2. COULD AN OPERATING RULE CONFLICT WITH A STANDARD? (Modified Table)