HIPAA stands for Health Insurance Portability and Accountability Act. The Act was endorsed in 1996 and consist of two components:
- Health Insurance Reform
- The Administrative Simplification Act
The Administrative Simplification Act required the Department of Health and Human Services to establish national standards for electronic health care transactions and national identifiers for providers (NPI), health plans, and employers. The ASC X12N Insurance transaction sets were selected by DHHS as the standard for health EDI.
EDI stands for Electronic Data Interchange and is the computer to computer exchange of business data between two or more entities in a standardized format.
X12N is a healthcare standard for electronic data exchange that the American Standards Committee (ASC) has been charged with developing and maintaining. Currently the following industry standards exist.
- X12C Communication & Controls
- X12F Finance
- X12G Government
- X12I Transportation
- X12M Supply Chain
- X12N Insurance
For the healthcare community the X12N suite of transactions is the standard for data exchange. The primary healthcare X12N transactions include the following:
269
Health Care Benefit Coordination Verification
270
Eligibility, Coverage or Benefit Inquiry
271
Eligibility, Coverage or Benefit
274
Health Care Provider Information
276
Health Care Claim Status Request
277
Health Care Information Status Notification
278
Health Care Services Review Information
834
Benefit Enrollment and Maintenance
835
Health Care Claim Payment/Advice
Each transaction set as identified in What is X12N? has an associated implementation guide (document) which describes the consistent industry usage of that transaction set. The guides for each transaction set can be purchased through the Washington Publishing site at www.wpc-edi.com. Simply put the guides provide instructions on how the transaction should be structured.
Companion Guides are supplemental documents to Implementation Guides that specify specific instructions on how certain elements in a transaction set are to be populated based on the needs of the organization issuing the companion guide. Companion Guides are not to contradict the implementation guides, they are to extend or clarify it based on the needs of the issuing agency. Additional information can be found at CMS Companion Guides
An Atypical Provider according to Federal Register Vol. 65, No 160 page 50315 is a provider who renders services that are not considered healthcare services. Examples include nonemergency transportation, and physical alterations to a persons with disabilities living quarters.
Generally speaking a service is considered an encounter when submitted to the payer for reporting purposes only. Encounter Services (claims) often are rendered under a capitated agreement in which payment is made outside of the delivery of the service as in a standard Fee For Service arrangement. The encounter is proof that the service was rendered. Payers use encounters among other things as part of rate setting measures to determine how future capitated agreements should be priced.
Claims on the other hand contain the same data as an encounter however they are submitted for payment. Claims are generally part of a Fee For Service agreement by which the provider gets paid after the service has been rendered and the claim has been submitted for payment to the payer.
The EDI transaction sets such as the 837 Professional allow for the distinction of a claim and a encounter by indicating a "CH" (Chargeable) or "RP" (Reportable) in the sixth element of the BHT segment.
Additional information on the differences between claims and encounters can be found at: http://www.cms.gov/apps/glossary/default.asp?Letter=C&Language=English http://www.cms.gov/apps/glossary/default.asp?Letter=E&Language=English
From a logical stand point, one could say if my 835 remittance advice file has 100 rows in the file, then I should have posted the equivalent amount of transactions. Hypothetically this makes perfect sense, but in practice it doesn't work well, primarily because the 835 remittance advice like all the other EDI transaction sets contain a looping structure in which the transactions embedded in the file don't map directly to a single line in the file.
So in order to determine that you or your vendor has correctly parsed "ALL" the data from the remittance advice, EDI requires that the data balances at three levels:
- Transaction
- Claim
- Service
To be 100% sure that you've gotten everything, you should ensure that the file balances at all three levels, but in practice if the sum of your paid amounts equals the information provided in segment BPR02 - Total Actual Provider Payment Amount adjusting for any dollars in the Provider Adjustment segment (PLB), you should feel confident that you've captured all the payment information. This check ensures that the file balances at the Transaction level.
So in order to determine that you or your vendor has correctly parsed "ALL" the data from the remittance advice, EDI requires that the data balances at three levels:
- Transaction
- Claim
- Service
To be 100% sure that you've gotten everything, you should ensure that the file balances at all three levels, but in practice if the sum of your paid amounts equals the information provided in segment BPR02 - Total Actual Provider Payment Amount adjusting for any dollars in the Provider Adjustment segement (PLB), you should feel confident that you've captured all the payment information. This check ensures that the file balances at the Transaction level.
PHI stands for Protected Health Information and is any data that is Individually Identifiable Health Information. Individually Identifiable Health information is data that can be linked to a particular person, such as:
- Past, present or future physicals or mental health or condition.
- The provision of health care to the individual.
- Past, present, or future payment for the provision of health care to the individual.
The Center for Medicare & Medicaid provides a definition of PHI at: Protected Health Information
DISCLAIMER: The information provided in this FAQ is based on personal experience through my fifteen years of working in the healthcare industry. DoRight Solutions, Inc. assumes no responsibility therefore. The user of the information agrees that the information is subject to change without notice. DoRight Solutions Inc., assumes no responsibility for the consequences of use of such information, nor for any infringement of third party intellectual property rights which may result from its use. IN NO EVENT SHALL DORIGHT SOLUTIONS, INC. BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR INCIDENTAL DAMAGE RESULTING FROM, ARISING OUT OF OR IN CONNECTION WITH THE USE OF THE INFORMATION.