The “Sticky” NOE Problem

MEDTranDirect is a vendor of Medicare connectivity services, including access to the CMS HETS system (HIPAA Eligibility Transaction System) that provides real time eligibility data for healthcare organizations.  The data processed through this system is intended to provide a complete picture of all beneficiary data necessary to determine if payment will be received when healthcare services are provided to Medicare patients.

Late last year, we found a problem in the HETS data where the hospice NOE (Notice of Election) data was only present part of the time when it was processed in the CWF (Common Working File).  We documented this issue and reported it to HETS support.  Their initial response was that this was not a claim and that is why it was not showing up.  This did not make much sense since it did show up at least half of the time.  We resubmitted the problem again in February of this year, their response at that time was that it did not show up because the data was not in the CWF and the problem was with the MACs processing the NOEs and not the HETS system.  This conclusion was also not supported by the data we provided since we gave them screenshots of NOEs entered and accepted in DDE (Direct Data Entry), but were not present in HETS several days later.

Continue reading

Improving the Processing of NOEs and NOTRs for Hospices

As a vendor of eligibility processing services and a NSV (Network Service Vendor) for the Medicare HETS eligibility system, we have a vested interest in the capability of these systems to provide current and valid information. Through the HIPAA transaction for eligibility data (ANSI 270/271), we send requests to these systems for eligibility data for specific patients. Through a real time response, we can provide detailed information about the current status of this patient with the selected payer. This process involves converting the data returned by the payer into a report or entering it into a database.  In this process, we are the “messenger”. The content we provide is completely dependent on the quality of the payer response.

In some cases, these responses can be incomplete or inaccurate.  When this happens, we often get support incidents where providers complain that we are providing incorrect data. Most of the time, they are technically correct, but the issues they present as problems are beyond the ability of these payer systems to accommodate given the way this data is collected.

NOES and NOTRS Continue reading

Embracing Disruption for Growth

As we approach the October deadline for ICD10, you can sense the tension in the industry as the unknown consequences of using this code set move closer to the present as each day passes, or as Snoopy would begin the story, it was a dark and stormy night.

Even the most prepared organizations can only guess what the impact of switching to ICD10 will have on their transaction processing, cash flow, and procedures.  Every organization is linked to others and the disruption caused by this will be felt by everyone.  It can’t be avoided, only mitigated through planning, preparation, and then making adjustments quickly.

Charles M. Schulz, Snoopy
Charles M. Schulz, Snoopy

Continue reading

Stagnation in HIPAA Adoption Rates

A few weeks ago I wrote a short blog about the recently released statistics on the adoption rate of HIPAA transactions compiled by CAQH for the calendar year of 2013. This report is called the 2014 CAQH index and is available through the CAQH web site ( or directly through this link:

This study is actually the second year in a row where they collected this data so in addition to providing adoption rates for 2013, the data for 2012 is available as well along with a measurement of change in the adoption rate of these transactions over a year.

Here are the adoption rates for the two years for the three most common standardized healthcare electronic transactions:

Claim Submission 2012 90.2% 2013 91.8% Change +1.46%
Eligibility 2012 64.7% 2013 65.3% Change +0.6%
Remittance Advice 2013 42.7% 2013 46.4% Change +3.7%

Continue reading

What is the Common Working File?

The term Common Working File (CWF) is about as old as any IT terminology in our industry.  I have used it myself since we began the company in 1986.  Despite our common understanding of this concept, I have to admit that I was not really sure what it was, where it was stored, or how it was maintained.  I decided to do a little research. Here are the results.

The CWF is specific to Medicare.  It is a collection of records maintained on behalf of each Medicare beneficiary that covers these four general areas of information:

Entitlement data

Utilization History

Medicare Secondary Payer (MSP)

Health Maintenance Organization (HMO)

This information is stored in a separate record for each beneficiary for each of these data categories.

Although we think of the CWF as a single database, it is actually comprised of 9 databases called Hosts.  Each beneficiary is assigned to only one host.  This is determined by where the person signs up for their SSA benefits.  Here are the host sites and the states that are assigned to each: 

Continue reading

HETS to add Lifetime Psychiatric Remaining Days

Over the last several months, we have assisted customers in switching to the HETS (HIPAA Eligibility Transaction System) from DDE as customers prepare for the April 2014 elimination of eligibility data.

I have discussed in previous articles about differences between these two systems, how they obtain their information, and how this impacts the ability of certain providers to verify Medicare patient eligibility information.

One item that has been mentioned often by our customers is the Lifetime Psychiatric Remaining Days (LPRD).  This value is available through DDE, but is not returned by CMS through the HETS ANSI 271 response.  We have many customers who use DDE exclusively for the purpose of looking up patients and getting this single value.  We have reported this to the HETS help desk and it appears that they are responding to the problem. Continue reading

HETS to Fix Hospice Prior Benefit Period Identification Issue


Over the last several months, the announcement that CMS was phasing out eligibility information currently available through Direct Data Entry (DDE) next April has driven providers to eligibility reporting solutions using the CMS HIPAA Eligibility Transaction System (HETS).

“HETS to replace Common Working File (CWF) for eligibility inquiries”

“How to Get Connected – HETS 270/271”

The providers and vendors who were early adopters of this technology noticed differences in the data reported through these two systems.  Recently, I co-wrote an article for Health Data Management that described these systems, how they work, and the differences between them.  It is available on our blog or through this link:

“A Primer on the HIPAA Eligibility Transaction System” Continue reading

A Primer on the HIPAA Eligibility Transaction System

As posted on HealthData Management


The HIPAA Eligibility Transaction System, or HETS, was introduced by the Centers for Medicare and Medicaid Services in 2005 to support real-time Medicare eligibility inquiries using the HIPAA ANSI 270 (eligibility request) and ANSI 271 (eligibility response) transactions. Recent announcements by CMS have centered attention on this process since it will soon be the only method of obtaining this information for Medicare patients.

Continue reading

Integrate eligibility inquiry in your software

Beginning April 2013, CMS will start terminating existing DDE screens containing patient eligibility data for all providers. CMS has recommended that providers begin searching for vendors that can deliver access to the HETS (Healthcare Eligibility Transaction System) for delivery of Medicare eligibility and billing history data. Our HETS service can provide this access for you immediately with no development time required by your staff.

Business-to-business (B2B) Eligibility Verification Solution