HIPAA (eDoc)
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) mandates that the health care organizations must have transaction and information security standards to support the electronic exchange of administrative and financial health care data. The HIPAA eDoc connector supports these standards for reading and writing version 5010 X12 health insurance transaction documents. Actian provides a schema set that adheres to the standard and enables data transformation mapping using Actian DataConnect. For details, contact your sales representative.
The connector and its schema set speed the creation, parsing, transformation, and integration of HIPAA transactions with existing systems. They provide built-in HIPAA transaction parsing logic and compliant target templates for mapping native data (without the need to modify existing applications).
For more information on HIPAA or the standards, see https://www.hhs.gov/hipaa/index.html. For technical information including implementation guides and codesets, see http://www.wpc-edi.com/.
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
where,
• 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: Prior to 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 want to develop your own schema, many errors can occur due to the schema “version mismatch”. Hence, all trading partners must agree on the specific version of the schema to be used in transactions. Addenda schemas must be examined to verify version match with all parties involved in the transaction.
To verify the version of a schema, open the schema in a Text Editor. Check the header information. In the header, note the date created and date (last) modified fields. These fields determine precise version match.
Any schema changes or customizations must be mutually agreed upon by all the trading partners prior to "live" data exchange. A customized or modified schema must be verified by each trading partner to make sure that the version matches at each point of exchange within the trading group.
Schema File Required
You can obtain an HIPAA (eDoc) schema file from HIPAA that contains the structure for your HIPAA (eDoc) file connections. If your HIPAA (eDoc) file structure is different, you may have 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 template file into Project Explorer.
2. Open the file in the Schema Editor.
3. Make your changes.
4. Save the file with a different name in the required project folder.
To connect to a HIPAA source or target file, you must set a schema in the HIPAASchemaFile property.
HIPAA Message Hierarchy
If you make changes to the default HIPAA schema, make sure you adhere to the following HIPAA schema rules to prevent the updated schema from becoming invalid.
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)
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.
Note: Do not edit Interchange (ISA- IEA).
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: Default value
• 1: 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. For examples, ISA, IEA, GS, and GE.
Functional Group (GS - GE)
A collection of messages. The functional group container must include a header (GS) and trailer (GE) and must reside inside the interchange enveloping segment. The record type name is always Loop.Function.
Note: Do not edit Functional Group (GS - GE).
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: Default value
• 1: unbounded
An unbounded minimum occurrence means multiple transactions can exist in the group.
• rec_type_ref - Identifies the record definition. For examples, ISA, IEA, GS, and GE.
Transaction (ST - SE)
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) and reside inside of the functional group. The record type name is always Loop.Message.
Note: Do not edit Functional Group (ST - SE).
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 the minimum number of times a repeat can occur within a group:
• 0: Default value
• 1: unbounded
An unbounded minimum occurrence means multiple functional groups can exist in the transaction.
• rec_type_ref - Identifies the record definition. For examples, ISA, IEA, GS, and GE.
Choice
Defines a group of loops or a group of 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 the 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 - Optional. Identifies the minimum number of times a repeat can occur within a group:
• 0: Default value
• 1: unbounded
An unbounded minimum occurrence means multiple functional groups can exist.
Loop
Repeating data within the message that is mapped to the JSON field. The record type name always contains 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 - Optional. Identifies the minimum number of times a repeat can occur within a group:
• 0: Default value
• 1: unbounded
An unbounded minimum occurrence means multiple functional groups can exist.
• sequence - Indicates the loop is defined in a sequential order.
Segment
A collection of fields that shares 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 - Optional. Identifies the minimum number of times a repeat can occur within a group:
• 0: Default value
• 1: unbounded
An unbounded minimum occurrence means multiple functional groups can exist.
• sequence - Indicates the segment is defined in a 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 - Optional. Identifies the minimum number of times a repeat can occur within a group:
• 0: Default value
• 1: unbounded
An unbounded minimum occurrence means multiple functional groups can exist.
• sequence - Indicates the composite is defined in a 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 - Optional. Identifies the minimum number of times a repeat can occur within a group:
• 0: Default value
• 1: unbounded
An unbounded minimum occurrence means multiple functional groups can exist.
• sequence - Indicates the element is defined in a 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
• unbounded
• min_length - The minimum length of characters allowed for the field data type.
Note: You cannot edit the min_length property using the Schema Editor. To edit this value, open the schema file in JSON Editor and change the value.
Connector-Specific Notes
This section provides information that is specific to the connector.
• Data Type Display - The data types that are displayed under the Type for 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, consider the data type as text that must be converted to a (DateTime) data type.
• Building Structural Data - Loading and unloading HIPAA structural information takes a few seconds longer than the other connectors. After clicking various lists and choosing HIPAA Health Claim adapter files, you may notice a pause for a few seconds. The status text displays the message "Building tree structure, please wait." Other status messages indicate that schemas are being 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)]
Connector Parts
Connector parts are the fields you configure to connect with a data source or target. The fields that are available depend on the connector you select.
For a list of all parts for source connectors, see Specifying Source Connector, Parts, and Properties.
For a list of all parts for target connectors, see Specifying Target Connector, Parts, and Properties.
Property Options
You can specify the following source (S) and target (T) properties:
Property | S/T | Description |
|---|---|---|
Encoding | S/T | To specify encoding for reading source and writing target data, select a code page translation table. The default value is OEM. To use ANSI, select ISO8859-1. For Windows CodePage 1252, select CP1252. |
HIPAASchemaFile | S/T | Used for parsing data and generating a new schema during design time. Select a schema file that contains the schema you want to use. |
Skip | S | If set to true, segments that do not match those in the specified schema file are not read. If you are reading large HIPAA files and have many mismatches, the parsing time increases. To improve performance, set this option to False. |
SegmentTerminator | T | A character that terminates a segment. Select a Segment Terminator from the list. The default is CR-LF. For the options, see Element Separators. |
ElementSeparator | T | Select an element separator from the list. The default is *(002A). For the options, see Element Separators. |
SubElementSeparator | T | 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 the options, see Element Separators. |
RepetitionSeparator | T | Separates multiple occurrences of a field. The default is ^(005E). For the options, see Element Separators. |
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. Note: This property is available when the SegmentTerminator property is not set to CR or LF. |
WrapLength | T | Sets the length of line wrap in the target file. The default is 80. Note: 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 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 value must be similar to "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
*000302*1541*U*00401*000000742*0*T*:
GS*HC*TEST-SND*TEST-RCV*20000302*1541*1*X*004010X098
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, make sure that the element separators are included 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 must 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 must add a placeholder, since there are other segments that are required after the NM107 (Name Suffix) segment.
• Optional and Situational Segments - Optional segments are not required. Situational segments are also optional. However, they are required if another segment is used and that requires the situational segment. Do not use optional or situational segments to reset any flags you have already set. If that flagged segment is not used, the flag does not operate as you originally planned. Use flags on required segments only.
Last modified date: 07/26/2024