Was this helpful?
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).
Note:  When creating a new map (manually or using the Map Wizard) and the target has no schema, DataConnect attempts to create one using the source schema. This is a straightforward process with a single record source to a single record target. The process differs with a multi-record (or hierarchical) source to multi-record target. In this case, DataConnect locates the first “flat” source record type (a record where none of the fields are themselves a record) and uses it to generate a basic schema for the target. Users can then build out the schema.
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.
/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)
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
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: 12/03/2024