User Guide : Map Connectors : Source and Target Map Connectors : HIPAA
 
Share this page             
HIPAA
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.
HIPAA Structure
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.
HIPAA form Title
Form Number
Health Claims or Equivalent Encounter Information (Dental, Professional, Institutional)
837
Enrollment and Dis-enrollment in a Health Plan
834
Eligibility for a Health Plan
270, 271
Health Care Payment and Remittance Advice
835
Health Plan Premium Payments
820
Health Claim Status
276, 277
Referral Certification and Authorization
278
Coordination of Benefits
837
ASC X12C Implementation Acknowledgment for Health Care Insurance
999
ASC X12C Functional Acknowledgment for Health Care Insurance
997
Interchange Acknowledgment
TA1
Addenda schemas use the following naming structure:
HIPAA_Health_Care_Claim_Remittance_Advice.X091.A1.X12.4010.835.1.0.ds.jsn
Example
Definitions of each of the naming structure components:
Health Care Payment and Remittance Advice—formal document name
X091—HIPAA designation (describes form as HIPAA-compliant)
A1—Addenda designation; implementation guide
X12—ANSI project designation
4010—version of the document
835—form number of the primary schema
Note:  Before July 2003, addenda schemas used a "0.<n>.ds.jsn" naming structure. Later naming structures use a "1.<n>.ds.jsn" convention.
Version Mismatch Errors
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.
Note:  To verify the version of a schema, open the schema in a text editor. Check the header information. In the header, notice the date created and date (last) modified fields. These fields offer a convenient method to determine precise version match.
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.
Schema File Required
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 make changes to a HIPAA template file
1. Import the file into Project Explorer.
2. Open the file in the Schema Editor.
3. Make your changes.
4. Save the file with a different name.
To connect to an HIPAA source or target file, you must set a schema in the HIPAASchemaFile property.
HIPAA Message Hierarchy
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.
Message/Transaction
/download/attachments/24975746/HIPAA%20message%20hierarchy.png?version=1&modificationDate=1487967150731&api=v2
Note:  The schema must include two sections: root_defs that defines the schema structure at the root level and type_defs that defines the record types.
Interchange (ISA -IEA)
(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.
Elements:
name - Required. Identifies the unique identifier for the group.
max_occurs - Optional. Defines the field requirement: 0=optional, 1=required; if min_occurs is 0 and max_occurs is 0, the field is not used.
min_occurs - Identifies the minimum number of times a repeat can occur within a group: 0, 1 (default), unbounded. An unbounded minimum occurrence means multiple functional groups can exist.
sequence - Indicates the position of the loop within the transaction.
rec_type_ref - Identifies the record definition. Examples: ISA, IEA, GS, and GE
Functional Group (GS - GE)
(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.
Elements:
name - Required. Identifies the unique identifier for the message
max_occurs - Optional. Defines the field requirement: 0=optional, 1=required; if min_occurs is 0 and max_occurs is 0, the field is not used.
min_occurs - Optional. Identifies the minimum number of times a repeat can occur within a group: 0, 1 (default), unbounded. An unbounded minimum occurrence means multiple transactions can exist in the group.
rec_type_ref - Identifies the record defintion. Examples: ISA, IEA, GS, and GE.
Transaction (ST - SE)
(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.
Elements:
name - Required. Identifies the unique identifier for the segment or loop.
max_occurs - Optional. Defines the field requirement: 0=optional, 1=required; if min_occurs is 0 and max_occurs is 0, the field is not used.
min_occurs - Optional. Identifies minimum number of times a repeat can occur within a group: 0, 1 (default), unbounded. An unbounded minimum occurrence means multiple functional groups can exist in the transaction.
rec_type_ref - Identifies the record def inti on. Examples: ISA, IEA, GS, and GE.
Choice
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
Elements:
name - Required. Identifies the unique identifier for the group of segments or loops.
recognition_rule - Required. Identifies the recognition rule name.
discriminator_field - Required. The fully qualified name in one of referred record or structure in the Choice group. Uses the format: recordname/field. A forward slash (/) separates the record name and field name. For example, HL.0010/E.735.03
max_occurs - Optional. Defines the field requirement: 0=optional, 1=required; if min_occurs is 0 and max_occurs is 0, the field is not used.
min_occurs - Identifies the minimum number of times a repeat can occur within a group: 0, 1 (default), unbounded. An unbounded minimum occurrence means that multiple function groups can exist.
Loop
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
Elements:
name - Required. Identifies the loop name.
max_occurs - Optional. Defines the field requirement: 0=optional, 1=required; if min_occurs is 0 and max_occurs is 0, the field is not used.
min_occurs - Identifies the minimum number of times a repeat can occur within a group: 0, 1 (default), unbounded. An unbounded minimum occurrence means that multiple function groups can exist.
sequence - Indicates the loop is defined in sequential order.
Segment
A collection of fields that share a particular data type.
Elements:
name - Required. Identifies the unique identifier for the field.
max_occurs - Optional. Defines the field requirement: 0=optional, 1=required; if min_occurs is 0 and max_occurs is 0, the field is not used.
min_occurs - Identifies the minimum number of times a repeat can occur within a group: 0, 1 (default), unbounded. An unbounded minimum occurrence means that multiple funcation groups can exist.
sequence - Indicates the segment is defined in sequential order.
Composite
Defines a group of elements in a sequence that is mapped to struct_type_ref. Prefixed with C.
Elements:
name - Requires. Identifies the unique identifier for the element.
max_occurs - Optional. Defines the field requirement: 0=optional, 1=required; if min_occurs is 0 and max_occurs is 0, the field is not used.
min_occurs - Identifies the minimum number of times a repeat can occur within a group: 0, 1 (default), unbounded. An unbounded minimum occurrence means that multiple funcation groups can exist.
sequence -Indicates the composite is defined in sequential order.
Element
The element ID uses the prefix E. For example, E.I12.13.
Elements:
name - Required. Identifies the unique identifier for the element.
max_occurs - Optional. Defines the field requirement: 0=optional, 1=required; if min_occurs is 0 and max_occurs is 0, the field is not used.
min_occurs - Identifies the minimum number of times a repeat can occur within a group: 0, 1 (default), unbounded. An unbounded minimum occurrence means that multiple funcation groups can exist.
sequence - Indicates the element is defined in sequential order.
type - Indicates the data type for the element: identifier (ID), alphanumeric (AN), date (DT), time (TM), float(R), binary (B), numeric (N0 to Nn, 0…n is the decimal size).
length - Indicates the maximum length for the element: 0, MAX_LONG, and unbounded.
min_length - The minimum length of characters allowed for the field data type.
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.
To add a segment or loop
1. Add a record type.
2. Highlight the new record type that is added to the bottom of the record type list.
3. Select the Properties tab in the console and edit the default name (if necessary) and add a description.
4. Expand the segment group and define the elements.
5. As a best practice to keep the schema organized, drag and drop the segment to the appropriate location in the schema.
6. Switch to Schema View to verify the hierarchy of the schema is what you want.
7. Select the group that you want to associate with the record type.
8. Add a record type reference, which is the pointer to the record type structure.
9. Edit the properties for the record type reference as needed. Make sure you select the new record type as the Reference Record Type.
10. Highlight the schema root name.
11. Click the Recognition Rules tab in the console.
12. Select an existing rule set or add a rule set.
13. (Optional) Provide a description of the rule set.
14. Add one or more rules with descriptions. Define the recognition rules (repeat the following steps for each rule you add):
Select a discriminator field from the list.
Enter the string to be matched in the Value field.
Optional. Select the Case Sensitive option if you want to match the string exactly.
Select the rule from the list to be evaluated if a record does not match this entry.
15. Save the schema.
Connector-Specific Notes
Data Type Display
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.
Building Structural Data
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:
Source or target type
Source or target file
Source or target data browsers
Save Transformation (Save icon or File > Save)]
Property Options
You can set the following source (S) and target (T) properties.
Property
S/T
Description
SchemaFile
ST
Allows you to choose a document schema file (.ds.xml) as a source or target. Used for parsing data and generating a new schema during design time. Select a schema file that contains the schema you want to use.
CodeSetFile
ST
A CodeSet file (.dsc.xml) is automatically generated when you save a document schema in Document Schema Designer. They are stored in the same location as document schemas. CodeSets contain CodeTable values and any date-time masks used in the schema as well as segment qualifiers.
QualifiedFieldNames
Validation
ST
None is the default setting. The following validation methods are available:
Composite/Element – Validate maxuse, requirement, min/max length and default value.
Loop/Segment – Validate maxuse and requirement.
Composite/Element+Loop/Segment – Validate both composite/element and loop segment.
QualifiedFieldNames
ST
Qualified Name is the name path of the parents of the segment in the Schema tree. If QualifiedFieldNames is true, Qualified Name is put before a field name. The default is false.
Skip
S
When the Skip property is set to true, segments that do not match those in the applied schema file are not read. If you are reading large HIPAA files and have many mismatches, parsing time increases. To improve performance, set it to False.
SegmentTerminator
T
A character that terminates a segment. Select a Segment Terminator from the list. The default is CR-LF. For your options, see ElementSeparators.
ElementSeparator
T
Select an element separator from the list. The default is *(002A). For your options, see ElementSeparators.
SubElementSeparator
T
The SubElementSeparator supersedes any values mapped in the ISA segment. Allows overrides of values from the command line or through the API. The default is :(003A). For your options, see ElementSeparators.
RepetitionSeparator
T
Separates multiple occurrences of a field. The default is ^(005E). For your options, see ElementSeparators.
LineWrap
T
Sets the type of line wrap in your source file. The default is None.
Some files may consist of a constant stream of data with no line separators. LineWrap "forces" a temporary line-wrapping behavior. If you attempt to connect to your file and receive parse error messages, change the setting to CR-LF, CR, LF, or LF-CR.
This property is available when the SegmentTerminator property is not set to CR or LF.
WrapLength
T
Sets the length of line wrap in your target file. The default is 80. This property is available when the LineWrap property is not set to None.
Element Separators
The following element separators are supported:
CR-LF
STX (0001)
SOT (0002)
ETX (0003)
EOT (0004)
ENQ (0005)
ACK (0006)
BEL (0007)
BS (0008)
HT (0009)
LF (000A)
VT (000B)
FF (000C)
CR (000D)
SO (000E)
S1 (000F)
DLE (0010)
DC1 (0011)
DC2 (0012)
DC3 (0013)
DC4 (0014)
NAK (0015)
SYN (0016)
ETB (0017)
CAN (0018)
EM (0019)
SUB (001A)
ESC (001B)
FS (001C)
GS (001D)
RS (001E)
US (001F)
SP (0020)
! (0021)
" (0022)
# (0023)
$ (0024)
% (0025)
& (0026)
' (0027)
( (0028)
) (0029)
* (002A)
+ (002B)
, (002C)
- (002D)
. (002E)
/ (002F)
: (003A)
; (003B)
< (003C)
= (003D)
> (003E)
? (003F)
@ (0040)
[ (005B)
\ (005C)
] (005D)
^ (005E) - (the default)
_ (005F)
' (0060)
{ (007B)
| (007C)
} (007D)
~ (007E)
DEL (007F)
Checking the Validity of HIPAA EDI Structures
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).
Example
ISA*00* *00* *30*34-39495350 *30*11-22233344
*000302*1541*U*00401*000000742*0*T*:
GS*HC*TEST-SND*TEST-RCV*20000302*1541*1*X*004010X098
How HIPAA Connectors Can Help
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.
Tip...  You can purchase document schemas for all other HIPAA transaction sets. Please contact your sales representative for more information.
HIPAA Transaction Set Synopsis
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:
Determine if an Information Source organization, such as an insurance company, has a particular subscriber or dependent on file
Determine the details of health care eligibility or benefit information
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.
Other Considerations
To learn about how HIPAA/EDI terminology differs from other data types used in integration tools, see Property Options.
Valid EDI/HIPAA
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.
Separators
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 and Situational Segments
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.