A Primer on the HIPAA Eligibility Transaction System
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.
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.
CMS announced through a revised MLN Matters document on April 23 that the access of eligibility data through the Common Working File (CWF) will be discontinued in April 2014. For over 20 years, providers have used terminals or terminal emulation software to connect to the CWF and view eligibility and claims data. Many software applications have been developed that access this system to obtain this information and redistribute it through reports. These processes will need to be modified or abandoned by providers and software developers before they cease to exist.
This presents some potential problems for providers since these systems, although they serve the same purpose; provide somewhat different information and support different technologies for distributing this data. One fundamental difference between the two systems is how the information is structured and accessed.
The CWF is a database of fixed-length records based on common mainframe computer database designs of the 1980s. It contains many years of claim data sent from provider systems to CMS through claims submission to Medicare contractors. This database is accessed through a computer system is referred to as the Fiscal Intermediary Standard System (FISS).
The claims data is summarized for eligibility inquiry and is currently available to providers through mainframe (IBM 3270) terminal screens connected to FISS that are now normally accessed through terminal emulation software on personal computers, commonly referred to as Direct Data Entry (DDE). These screens serve two basic purposes, to view eligibility data/billing history and to view and correct pending claims. The eligibility screens targeted for removal can be identified by four character codes. They are named HIQA, HIQH, ELGA, ELGH, and HUQA. The ability to perform claim updates through DDE will remain after the eligibility screens are removed.
Users must access these patient records individually and navigate to the appropriate screens to view the information. These screens are so old and outdated that many vendors have developed new user interfaces that display the same information through forms that can easily be navigated and display the data in a more advanced and modern user interface. However, the data used in this process is still only available through this mainframe view so these vendors have developed automated background processes for reading the account data through DDE and then redisplaying the data in a more attractive format. In April, the eligibility data will be gone for direct access and for any of these applications designed to redisplay this data through this approach. It is important that all providers understand how they get their eligibility data. If it is coming from DDE and not HETS, they need to make sure they are prepared for the change.
Although the HETS system serves the same purpose as the eligibility portion of DDE, the technology implemented in this approach is completely different. HETS is a transactional computer system that listens for requests for eligibility data (ANSI 270) and when it is received, it replies with the eligibility response (ANSI 271).
HETS does not include a user interface; it simply sends and receives these transactions from authorized submitters. Submitters are entities that have been authorized by CMS to access HETS. These submitters must pass testing and comply with the rules associated with the use of this system. Submitters may or may not provide user interfaces to individually access the eligibility information and display the results. HETS was developed to separate the user interface from the data transfer process. This was necessary since many providers and healthcare system vendors have increasingly incorporated eligibility data in their system as a byproduct of another task, for example, admitting a patient or updating insurance information. These tasks already include the information needed to access Medicare eligibility data without reentry. The data needed to obtain eligibility information is:
Facility NPI
Patient HICN
Patient Last Name
Patient First Name or Patient DOB
Other optional data elements in the ANSI 270 can alter the results received such as the provider type or specific HCPCS codes sent for Part B eligibility data.
Since no user interface is involved, HETS is very fast. Although HETS processes transactions one at a time, it normally provides a response in less than two seconds from when the request is received. HETS does not access CWF data directly like DDE, so unlike DDE it is not down each day when the CWF is updated. HETS is normally available 24/7, currently; they reserve 12 am to 6 am EST on Mondays for scheduled updates and maintenance.
Once a day, the HETS system is updated by four other CMS systems, including the CWF, while the system remains on line. When the updates are finished, the HETS reference database is replaced with the new version with no down time.
Another advantage of HETS is the way the data is structured. Instead of the fixed-length format of the CWF, HETS data is variable. This means that different data can be provided based on the data requested and new data can be introduced without necessarily “breaking” the software used to access existing information. It also means that “extra” data can be reported when available. An example of this is billing history. HETS is designed to report all eligibility data dating back two years, regardless of the amount of data available. In DDE, you only get the last three billing episodes, when a fourth claim is submitted, there is no place to store the information so the available billing periods are “rotated” backward and the new episode is updated in the record and the fourth oldest billing data is lost. HETS will provide all billing history for a patient for the last two years, regardless of how many claims were submitted during that time.
However, what seems at first glance to be an advantage is also a weakness. The CWF retains only three billing periods, but it retains them permanently. This means that as long as a patient has had three or less billing events over a five year period, or longer, all three billing events would be visible through DDE.
This becomes a factor when you need to know billing data over two years old. For example, hospice billing periods are based on the how many previous hospice claims have been created for the patient, even if they were submitted by another provider. Through the HETS system, if a billing period is over two years old, it will not be reported. This data is often available through DDE since it retains the last three billing periods regardless of age. This could present a problem for hospice agencies that will be losing access to this information under these circumstances unless it is addressed by HETS or CMS changes hospice billing requirements.
There are other data elements available through DDE that are not yet available through HETS. These include Date of Last Billing Action (DOLBA) and Date of Earliest Billing Action (DOEBA) for hospice, hospice days used, and the discharge status associated with billing events. However, CMS works closely with standards organizations that regularly report these limitations, like CAQH CORE, and unlike the CWF and DDE, the HETS system is often updated to accommodate these new requirements. CMS states in their announcement notice that by the time that DDE eligibility is retired, HETS will have been modified to include the data elements in FISS that are not yet available in HETS.
Another difference between HETS and DDE is how records are found by users. DDE includes a user interface to find patient records by name. This screen uses search techniques that will return multiple results from a partial name (first six characters of the last name and first character of the first name). HETS assumes that the patient name is obtained from the Medicare card or other accurate documentation. It requires a full and complete last name that is correctly spelled. Incomplete or incorrect information returns a “record not found” result. Multiple results are not returned. Any additional information that is not exactly correct like first name or DOB will also result in a failed match. Most users find this difficult to get used to.
For more information regarding the data available in HETS, download a copy of the “CMS HETS 270/271 5010 Companion Guide”. To learn how to connect to HETS, visit “How to Get Connected – HETS 270/27" or ask your software or Medicare connectivity vendor.
Deanna Loftus is director of regulatory compliance at HEALTHCAREfirst, which provides Web-based management, electronic health record and Medicare claim and eligibility solutions for home health and hospice providers nationwide. Kalon Mitchell is the president of HIPAA transaction vendor MedTranDirect.
CMS announced through a revised MLN Matters document on April 23 that the access of eligibility data through the Common Working File (CWF) will be discontinued in April 2014. For over 20 years, providers have used terminals or terminal emulation software to connect to the CWF and view eligibility and claims data. Many software applications have been developed that access this system to obtain this information and redistribute it through reports. These processes will need to be modified or abandoned by providers and software developers before they cease to exist.
This presents some potential problems for providers since these systems, although they serve the same purpose; provide somewhat different information and support different technologies for distributing this data. One fundamental difference between the two systems is how the information is structured and accessed.
The CWF is a database of fixed-length records based on common mainframe computer database designs of the 1980s. It contains many years of claim data sent from provider systems to CMS through claims submission to Medicare contractors. This database is accessed through a computer system is referred to as the Fiscal Intermediary Standard System (FISS).
The claims data is summarized for eligibility inquiry and is currently available to providers through mainframe (IBM 3270) terminal screens connected to FISS that are now normally accessed through terminal emulation software on personal computers, commonly referred to as Direct Data Entry (DDE). These screens serve two basic purposes, to view eligibility data/billing history and to view and correct pending claims. The eligibility screens targeted for removal can be identified by four character codes. They are named HIQA, HIQH, ELGA, ELGH, and HUQA. The ability to perform claim updates through DDE will remain after the eligibility screens are removed.
Users must access these patient records individually and navigate to the appropriate screens to view the information. These screens are so old and outdated that many vendors have developed new user interfaces that display the same information through forms that can easily be navigated and display the data in a more advanced and modern user interface. However, the data used in this process is still only available through this mainframe view so these vendors have developed automated background processes for reading the account data through DDE and then redisplaying the data in a more attractive format. In April, the eligibility data will be gone for direct access and for any of these applications designed to redisplay this data through this approach. It is important that all providers understand how they get their eligibility data. If it is coming from DDE and not HETS, they need to make sure they are prepared for the change.
Although the HETS system serves the same purpose as the eligibility portion of DDE, the technology implemented in this approach is completely different. HETS is a transactional computer system that listens for requests for eligibility data (ANSI 270) and when it is received, it replies with the eligibility response (ANSI 271).
HETS does not include a user interface; it simply sends and receives these transactions from authorized submitters. Submitters are entities that have been authorized by CMS to access HETS. These submitters must pass testing and comply with the rules associated with the use of this system. Submitters may or may not provide user interfaces to individually access the eligibility information and display the results. HETS was developed to separate the user interface from the data transfer process. This was necessary since many providers and healthcare system vendors have increasingly incorporated eligibility data in their system as a byproduct of another task, for example, admitting a patient or updating insurance information. These tasks already include the information needed to access Medicare eligibility data without reentry. The data needed to obtain eligibility information is:
Facility NPI
Patient HICN
Patient Last Name
Patient First Name or Patient DOB
Other optional data elements in the ANSI 270 can alter the results received such as the provider type or specific HCPCS codes sent for Part B eligibility data.
Since no user interface is involved, HETS is very fast. Although HETS processes transactions one at a time, it normally provides a response in less than two seconds from when the request is received. HETS does not access CWF data directly like DDE, so unlike DDE it is not down each day when the CWF is updated. HETS is normally available 24/7, currently; they reserve 12 am to 6 am EST on Mondays for scheduled updates and maintenance.
Once a day, the HETS system is updated by four other CMS systems, including the CWF, while the system remains on line. When the updates are finished, the HETS reference database is replaced with the new version with no down time.
Another advantage of HETS is the way the data is structured. Instead of the fixed-length format of the CWF, HETS data is variable. This means that different data can be provided based on the data requested and new data can be introduced without necessarily “breaking” the software used to access existing information. It also means that “extra” data can be reported when available. An example of this is billing history. HETS is designed to report all eligibility data dating back two years, regardless of the amount of data available. In DDE, you only get the last three billing episodes, when a fourth claim is submitted, there is no place to store the information so the available billing periods are “rotated” backward and the new episode is updated in the record and the fourth oldest billing data is lost. HETS will provide all billing history for a patient for the last two years, regardless of how many claims were submitted during that time.
However, what seems at first glance to be an advantage is also a weakness. The CWF retains only three billing periods, but it retains them permanently. This means that as long as a patient has had three or less billing events over a five year period, or longer, all three billing events would be visible through DDE.
This becomes a factor when you need to know billing data over two years old. For example, hospice billing periods are based on the how many previous hospice claims have been created for the patient, even if they were submitted by another provider. Through the HETS system, if a billing period is over two years old, it will not be reported. This data is often available through DDE since it retains the last three billing periods regardless of age. This could present a problem for hospice agencies that will be losing access to this information under these circumstances unless it is addressed by HETS or CMS changes hospice billing requirements.
There are other data elements available through DDE that are not yet available through HETS. These include Date of Last Billing Action (DOLBA) and Date of Earliest Billing Action (DOEBA) for hospice, hospice days used, and the discharge status associated with billing events. However, CMS works closely with standards organizations that regularly report these limitations, like CAQH CORE, and unlike the CWF and DDE, the HETS system is often updated to accommodate these new requirements. CMS states in their announcement notice that by the time that DDE eligibility is retired, HETS will have been modified to include the data elements in FISS that are not yet available in HETS.
Another difference between HETS and DDE is how records are found by users. DDE includes a user interface to find patient records by name. This screen uses search techniques that will return multiple results from a partial name (first six characters of the last name and first character of the first name). HETS assumes that the patient name is obtained from the Medicare card or other accurate documentation. It requires a full and complete last name that is correctly spelled. Incomplete or incorrect information returns a “record not found” result. Multiple results are not returned. Any additional information that is not exactly correct like first name or DOB will also result in a failed match. Most users find this difficult to get used to.
For more information regarding the data available in HETS, download a copy of the “CMS HETS 270/271 5010 Companion Guide”. To learn how to connect to HETS, visit “How to Get Connected – HETS 270/27" or ask your software or Medicare connectivity vendor.
Deanna Loftus is director of regulatory compliance at HEALTHCAREfirst, which provides Web-based management, electronic health record and Medicare claim and eligibility solutions for home health and hospice providers nationwide. Kalon Mitchell is the president of HIPAA transaction vendor MedTranDirect.
More for you
Loading data for hdm_tax_topic #care-team-experience...