The Health Insurance Portability and Accountability Act of 1996 (HIPAA) mandates that health care organizations must adopt transaction and information security standards to support the electronic exchange of administrative and financial health care data for administrative simplification.

The HIPAA (Health Insurance Portability and Accountability Act of 1996) requires the use of certain standard formats for documentation of medical claims that are related to services and other transactions associated with medical record keeping.

The following table provides the HIPAA form titles and the corresponding form numbers that represent transactions for medical claims related to services and maintaining the medical records.

Addenda schemas use the following naming structure:

HIPAA_Health_Care_Claim_Remittance_Advice.X091.A1.X12.4010.835.1.0.ds.jsn

Definitions of each of the naming structure components:

The ANSI standards reflect generic supersets designed to address a wide range of data exchange requirements. You may decide to define your own "subset" and develop rules that describe the data you submit. If you elect to develop your own schema, be aware that many errors can be traced to schema "version mismatch". It is important that all trading partners agree on the specific version of the schema to be used in transactions. Addenda schemas especially, should be examined to verify version match with all parties involved in the transaction.

Changes to, or customization of the schema must be communicated among and mutually agreed upon by all trading partners prior to "live" data exchange. A customized or modified schema should be verified by each partner to ensure version match at each point of exchange within the trading group. Complete preparation is the key to minimize production errors.

You are provided with a template file that contains the structure for your HIPAA file connections. If your HIPAA file structure is different, you may need to modify the template. To obtain a template file, contact your sales representative. These template files are standard schemas.

The template file is designed to parse source data to generate a target schema. You cannot use this file to parse source data in a map. Instead, perform the following steps to generate a schema from a target connector that you can use in a map.

To connect to an HIPAA source or target file, you must set a schema in the HIPAASchemaFile property.

The following is the HIPAA message schema hierarchy. If you make changes to the default HIPAA schema, make sure you adhere to the HIPAA schema rules defined below to prevent the updated schema from becoming invalid.

(Do not edit) A container of one or more functional groups. The interchange/message container must include a header (ISA) and trailer (IEA). The segments can appear only once in the message. The record type name is always Loop.Function.

(Do not edit) A collection of messages. The functional group container must include a header (GS) and trailer (GE) for the functional group container and must reside inside the interchange enveloping segment. The record type name is always Loop.Function.

(Do not edit) A container of one or more segments and loops; also referred to as a message. The transaction container must include a header (ST) and trailer (SE) for the transaction container, and reside inside of the functional group. The record type name is always Loop.Message.

Defines a group of loops or segments in which only one loop or segment can be selected. The record type name always includes Choice as the prefix. For example, Choice.2000

Repeating data within the message that is mapped to the JSON field. The record type name always includes the Loop prefix. For example, Loop.1000A

A collection of fields that share a particular data type.

Defines a group of elements in a sequence that is mapped to struct_type_ref. Prefixed with C.

The element ID uses the prefix E. For example, E.I12.13.

Below are the steps to create a segment or a loop. You can also add these parts of a schema by duplicating existing parts and making appropriate edits.

The data types that you see under Type for the source or target schema are HIPAA data type names, such as DT, AN, or ID. However, the integration platform reads them as text. To use a DT (DateTime) data type in an expression, treat the data type as text that must be converted to a (DateTime) data type. For more information about converting data types, search for "commonly used functions" in the documentation.

Loading and unloading HIPAA structural information takes a few seconds longer when compared with other connectors. After clicking various lists and choosing HIPAA Health Claim adapter files, you may notice a pause of a few seconds. The status text displays the message "Building tree structure, please wait." Other status messages indicate that schemas are getting built.

This limitation affects HIPAA selections at the following locations:

Connector parts are the fields you configure to connect with a data source or target.

The settings that are available depend on the connector you select.

For a list of all parts for source connectors, see Specifying Connector, Parts, and Properties.

For a list of all parts for target connectors, see Specifying Connector, Parts, and Properties.

You can set the following source (S) and target (T) properties.

The following element separators are supported:

To verify that you are working with valid HIPAA EDI files, check the value of the second record in the file. This should be something like "004010XNNN" where "NNN" is the numeric value that corresponds to the appropriate HIPAA X-code transaction set (for example, "004010X098" for the Professional 837).

The integration platform includes the HIPAA (eDoc) connector for helping to speed the creation, parsing, transformation and integration of HIPAA transactions with existing systems. It provides built-in HIPAA transaction parsing logic and compliant target templates for mapping native data (without the need to modify existing applications). The connector provides a tool to develop and test transactions while maintaining data integrity.

The integration platform offers bi-directional translation of the ANSI ASC X12N 837 Health Care Claims (837) transaction, for professional (x098src-24975746), dental (x097src-24975746) and institutional (x096src-24975746) claims to any format required by existing systems. For incoming transactions, the most complex 837 is automatically parsed into a flat presentation for drag-and-drop mapping of hierarchical EDI elements to native target structures or schemas. For outbound 837 transactions, the integration platform provides empty 837 compliant target structures, stored as templates, for mapping. Rules for reconciling data syntax and semantic differences required by the output are constructed through an event driven programming model coupled with a powerful visual RIFL Script Editor. During the entire map process actual "live" data is used, not the metadata, which eases the design process and provides immediate testing and debugging of the map designs.

A list of HIPAA transaction sets, that includes Guide ID, Guide Description, Primary Trading Partners and Exceptions/Limitations, follows:

270/271: Health Care Eligibility/Benefit Inquiry and Information Response

GUIDE ID: 004010X092

Guide Description: The Health Care Eligibility/Benefit Inquiry and Information Response Implementation Guide describes the use of the Eligibility, Coverage or Benefit Inquiry (270) Version/Release 3070 transaction set and the Eligibility, Coverage, or Benefit Information (271) Version/Release 3070 transaction set for the following business usage:

PRIMARY TRADING PARTNERS: Health care providers, such as hospitals and physicians. Health care payers, such as insurance companies, HMOs, PPOs and state and federal agencies, such as Medicare, Medicaid and CHAMPUS.

EXCEPTIONS/LIMITATIONS: Intended to use for health care eligibility/benefits. It does not provide a history of benefit usage, and is not intended for property and casualty or workers' compensation usage.

To learn about how HIPAA/EDI terminology differs from other data types used in integration tools, see Property Options.

The ISA Interchange Control Header is the first segment in all transaction set files. If this segment does not appear first, or is not exactly 105 bytes, the file is not a valid HIPAA/EDI format.

If you include expressions in your transformation, be sure to include element separators for the segments that are unused (no data in segments that are not required, called optional or situational). This is essential if there are any segments that are required after the unused segment(s). The separators should be used to indicate the location of each segment string. For instance, if you do not have data in the optional NM107 (Name Suffix) segment, you still must put in a placeholder, since there are other segments that are required after the NM107 (Name Suffix) segment.

Optional segments, as the name implies, are not required. Situational segments are also optional, however, they are required if another segment is used that requires the situational segment. Do not use optional/situational segments to reset any flags you have set. If that flagged segment is not used, the flag does not operate as you originally planned. Use flags on required segments only.