The Accredited Standards Committee X12 (also known as ASC X12) is a standards organization. Chartered by the American National Standards Institute (ANSI) in 1979,[2] it develops and maintains the X12 Electronic data interchange (EDI) and Context Inspired Component Architecture (CICA) standards along with XML schemas which drive business processes globally. The membership of ASC X12 includes technologists and business process experts, encompassing health care, insurance, transportation, finance, government, supply chain and other industries.
EDI standard developed by X12 Committee
X12 = HL7 EDI = FHIR
-
X12C Communications and Controls
-
X12F Finance
-
X12I Transportation
-
X12J Technical Assessment
-
X12M Supply Chain
-
X12N Insurance
-
Reference Model - Type 2 (TR2) A Reference Model that addresses a number of X12 standards as they relate to each other, or to one or more business applications.
-
Implementation Guide - Type 3 (TR3) An Implementation Guide that details implementation of one or more X12 standards for one specific business purpose. Many of X12's implementation guides are available to view in Glass, use the Table of Contents to the left. See the X12 store for other media.
-
Clarification paper - Type 4 (TR4) A Clarification Paper that relates to one or more X12 work products and may also relate to external standards or activities. X12's clarification papers are available to view in Glass, use the Table of Contents to the left.
EDI has been evolving with different versions, revisions and sub-revisions. For example, in the X12 standard EDI format, I started my EDI career with the EDI version 3010. Today, we are working with much higher EDI versions such as 4010, 5010, 5020… It is important to note that within each one of the above versions, different revisions might exist.
Based on ASC X12N Implementation Guide, Version 005010 X222A1 ^vers ^revision
https://standard.x12.org/Home/Default/005010
The Health Insurance Portability and Accountability Act was enacted by the U.S congress in 1996. A key component of HIPAA is the establishment of national standards for electronic health care transactions and national identifiers for providers, health insurance plans and employers.
The HIPAA EDI rule requires that covered entities use the X12N EDI data transmission protocol. The transmission protocol requires covered entities to use specific data code sets. The current code set standard format is referred to ASC X12 Version 5010, or HIPAA 5010.17 нояб. 2020 г.
Used to submit health care claim billing information, encounter information, or both. It can be sent from providers of health care services to payers, either directly or via intermediary billers and claims clearinghouses.
As there are many different business applications for the Health Care claim, there can be slight derivations to cover off claims involving unique claims such as for Institutions, Professionals, Chiropractors, and Dentists etc.
Used to submit retail pharmacy claims to payers by health care professionals who dispense medications, either directly or via intermediary billers and claims clearinghouses.
Can be used to make a payment, send an Explanation of Benefits (EOB) remittance advice, or make a payment and send an EOB remittance advice only from a health insurer to a health care provider either directly or via a financial institution.
Can be used by employers, unions, government agencies, associations or insurance agencies to enroll members to a payer. The payer is a healthcare organization that pays claims, administers insurance or benefit or product. Examples of payers include an insurance company, health care professional (HMO), preferred provider organization (PPO), government agency (Medicaid, Medicare etc.) or any organization that may be contracted by one of these former groups.
A transaction set which can be used to make a premium payment for insurance products. It can be used to order a financial institution to make a payment to a payee.
Used to inquire about the health care benefits and eligibility associated with a subscriber or dependent.
Used to respond to a request inquire about the health care benefits and eligibility associated with a subscriber or dependent.
This transaction set can be used by a provider, recipient of health care products or services or their authorized agent to request the status of a health care claim.
This transaction set can be used by a health care payer or authorized agent to notify a provider, recipient or authorized agent regarding the status of a health care claim or encounter, or to request additional information from the provider regarding a health care claim or encounter. This transaction set is not intended to replace the Health Care Claim Payment/Advice Transaction Set (835) and therefore, is not used for account payment posting. The notification is at a summary or service line detail level. The notification may be solicited or unsolicited.
This transaction set can be used to transmit health care service information, such as subscriber, patient, demographic, diagnosis or treatment data for the purpose of request for review, certification, notification or reporting the outcome of a health care services review.
This transaction set can be used to define the control structures for a set of acknowledgments to indicate the results of the syntactical analysis of the electronically encoded documents. Although it is not specifically named in the HIPAA Legislation or Final Rule, it is necessary for X12 transaction set processing . The encoded documents are the transaction sets, which are grouped in functional groups, used in defining transactions for business data interchange. This standard does not cover the semantic meaning of the information encoded in the transaction sets.
(submitter) -> batch (envelope (transactions)) -> (receiver)
Message structure - https://docs.oracle.com/cd/E19398-01/820-1275/agdaw/index.html
- Transaction Set Directory (message)
- Segment Directory (entities)
- Data Element Dictionary (datatypes)
/tmp/example-837.txt
xsd -> zen
837-Q2A2.xsd -> edi837.edn
edi837 zen schema -> tr prog -> claim schema
batch -> parse -> json -> tr prog -> claim tr prog reverse -> json -> generate -> batch