Industrial Accidents Division

IAIABC ELECTRONIC PARTNERING AGREEMENT

This form is designed to document agreement on a set of expectations and responses between two entities exchanging data electronically, for the purposes and objectives set out in the agreement. By means of this document, the Sender should be considered as having fulfilled any requirement by the jurisdiction or any related governmental entity for applying for permission to file information electronically. The sample form provided on this Web site already contains certain expectations recommended by the International Association of Industrial Accident Boards and Commissions (IAIABC).

Careful consideration of both demonstrated business needs as well as data availability must be given when establishing data element requirements between trading partners. The IAIABC recommends that data requesters meet with data providers to develop a consensus regarding which data elements should be collected and reported.

IAIABC ELECTRONIC TRADING PARTNER PROFILE

This form is designed to individually document identification and contact information for each trading partner providing data (whether the partner is the Sender, the insuring claims data source, or the receiving jurisdiction). This form will uniquely identify a trading partner. Members of the partnership fill out the form as it pertains to them. The partners then exchange the completed forms.

In the Trading Partner Type section, check all the descriptors that apply to the partner identified in the next section of the form. For example, if the trading partner is a carrier insuring some claims but is also acting as a third-party administrator on other claims, the partner should at least check both “Insurer” and “Third Party Administrator.”

Sender ID: A composite of FEIN (Federal Employer Identification Number of your business entity) and the 9-digit Postal Code (Zip+4) in the trading partner address field will be used to identify a unique trading partner. The Sender ID FEIN and Postal Code should be the same as those that the partner will use as the Sender ID in the Header Record of all of its EDI transmissions.

Contact Information: This section provides the ability to identify individuals within your business entity who can be used as the main contacts for this trading partner agreement. Two types of contacts should be identified: one for business practices and issues, and one for technical issues.

IAIABC ELECTRONIC PARTNERING INSURER ID LIST

This form is designed to document the identities of trading partners using the same third party administrator or other Sender to transmit data electronically to the jurisdiction. In conjunction with an individual and separate IAIABC Electronic Partnering Agreement for each trading partner, by means of this document the Sender should be considered as having fulfilled any requirement by the jurisdiction or any related governmental entity for applying for permission to file information electronically.

The jurisdiction should complete the section labeled ‘To’ and the Sender should complete the remainder of the form. In the table in the lower portion of the form, provide the full Insurer Legal Name, Insurer FEIN, and Jurisdiction Assigned ID (Insurer identification code), if applicable, for each insurer (carrier, selfinsurer, or group-funded pool) for whose claims the Sender will be transmitting data. The jurisdiction must notify the Sender of any discrepancy between the identifying information in the table and the jurisdiction’s present records. This list will be used to reconcile identification tables. It is understood that this list will have entries added or removed from time to time for which an updated report should be sent to the jurisdiction. Attach additional sheets as needed.

IAIABC TRANSMISSION PROFILE

The form is divided into two parts, the Receiver’s Specifications and the Sender’s Response. The Receiver (State/Jurisdiction) completes the Receiver’s Specifications, indicating all the Receiver’s requirements and, where applicable, the supported options from which a Sender (Reporter) can select. Ideally, the Receiver will customize the first page of the form, removing those selections and options that do not apply to their environment. The Receiver then gives the form to the Sender to reference while completing the Sender’s Response. The Sender marks selections where the Receiver provided choices. The Sender then returns this information to the Receiver.

One profile should be completed for each set of transactions with common transmission requirements. For example, one form may be used for 148 and A49 transmission because a given Receiver can only accept flat file format for these report types and can only accept them via Electronic Mailbox "A", while a second form will provide requirements and options that will relate to MED reports, which can only be accepted in ANSI format and via FTP. (See FTP Note below.) Although one profile will satisfy most needs, it should be noted that if transmission parameters vary by transaction types, you could specify those difference by providing more than one profile.

FTP Note: For security reasons, certain information may be provided here in a generic form. Detailed account and encryption-related information should be exchanged only by telephone, certified mail, or bonded courier; this includes information such as user ID and password, encryption bit size (minimum 112 recommended), and that SSL (Secure Sockets Layer) is being used. Authentication of Internet transmissions should be done in one of two ways: by use of digital certificates signed by a formal Certificate Authority, or by a locally managed exchange of certificates by known parties. To ensure nonrepudiation, the system must have an auditable tracking of transfers to/from each trading partner. Go to http://www.hhs.gov/ocr/hipaa/ for further information on issues pertaining to secure exchange of confidential information. Contact the IAIABC for the availability of updated information on recommended security procedures.

RECEIVER'S SPECIFICATIONS

​Receiver Name: The name of the business entity corresponding with the Receiver FEIN. Jurisdiction names should be entered as the State Name and the name of the state Workers' Compensation Agency with no abbreviations.

Date Prepared: Date this form is completed.

Receiver Type: Check all descriptors that apply to appropriately reflect the Receiver's business type. For example, if the trading partner is a Service Bureau acting on behalf of the jurisdiction to compile policy and financial data required by the jurisdiction in which the rating bureau operates, the partner should check both “Jurisdiction” and “Service Bureau.”

Receiver ID: This is a unique identifier consisting of the Receiver’s FEIN and Receiver’s Postal Code. The Receiver Identifier FEIN and Postal Code should be the same as those that the partner will use as the RECEIVER ID in the Header Record of all its EDI transmissions.

​​Transaction Information: This section identifies all the transaction sets/report types described within the profile along with any options the Receiver can provide to the Sender for each transaction set. Both the IAIABC and ANSI designators and Transaction Sets are provided (e.g., MED/837, where "MED" is the IAIABC designator and "837" is the ANSI designator). Refer to the Release-Version Guidelines on the IAIABC website (http://www.iaiabc.org/EDI/EDI_Release-Version_Guidelines_3-26-04.pdf) for further explanation.

• ​​Releases/Version: If the Receiver can accept a flat file for a given transaction set, specify the release and version number(s) supported by the Receiver. Multiple releases and versions may be supported per transaction set within the Receiver’s environment. The Sender will specify a single © IAIABC 2004 release/version per transaction set on the Sender’s portion of the form. The IAIABC recommends that the trading partners agree on the most current release/version that both partners can support.
• ​​Version: If the Receiver can accept an ANSI transmission for a given transaction set, specify the version number(s) supported by the Receiver. Multiple versions may be supported per transaction set within the Receiver’s environment. The Sender will specify a single version per transaction set on the Sender’s portion of the form. The IAIABC recommends that the trading partners agree on the most current version that both partners can support.
• ​​Mode (EDI/Paper/None): For each Transaction Set ID, specify which of the following acknowledgment options the Receiver supports: electronic, paper, and/or none. The IAIABC recommends usage of the electronic mode because the intent of EDI is to eliminate transmission of data by paper, and because full data interchange occurs only when two-way electronic communication is established.
• ​​Production Response Period: Specify the time limit within which the Receiver shall generate, and the Sender may expect to receive, an acknowledgment for each listed transaction set.

​​Transmission Frequencies for this Profile: All frequencies that the Receiver will accept transmissions for the transaction sets identified within this profile are specified here. Frequencies that the Receiver cannot support should be removed from the list.

• ​​Daily: If the Receiver will accept transmissions on any and all calendar days of the week, check this option. For other than the daily transmission frequency, choose one of the other options below. Note: For FROI/SROI processing, Receivers are encouraged to accept daily and transmit acknowledgments daily to avoid processing delays and sequencing problems inherent in the correction process.
• Weekly - Select Day: If the Receiver supports weekly options, specify here all calendar days of the week that the Receiver will accept transmissions. If the Receiver will accept transmissions on all days, it should choose the Daily option above.
• Monthly - Select Day (1-31): If the Receiver supports monthly options, specify here all calendar days of the month that the Receiver will accept transmissions (if at least one day of each week in the month, choose Weekly option above). Use the Monthly option also if the Receiver accepts biweekly transmissions.
• Other: If frequencies of transmission the Receiver supports do not fit one of the categories above, specify here the precise criteria by which Senders will understand when transmissions will be accepted. 
• ​​Transmission Cut-Off Time: Specify here the time of day up until which transmissions will be accepted for the processing cycle specified above (e.g., daily, weekly, or monthly). Be sure to specify the time zone.

​​Jurisdiction Approved Transmission Methods: This section specifies information about the vehicles to be used to transmit report information between the Receiver and the Sender.

Electronic Mailbox(es): If one or more Networks can be used to exchange data, specify here all available electronic mailboxes to which data can be transmitted. Separate mailboxes may be used for transmitting test versus production data.

Network: The name of the Network on which the electronic data can be accessed.

• ​​Mailbox Acct ID: The name of the Receiver's mailbox on the specified Network.
• User ID: The identifier of the Receiver entity to the Network.
• ​​Message Class: If this Network allows "slots" in the mailbox (message classification “pigeonholes”), specify the slot to be used by a given Sender when transmitting its information to the Receiver. Note: Most Networks do not have their systems configured to allow use of a Message Class. If the Network and Receiver both allow usage of this specification, the Receiver should clearly spell out the conditions under which Message Class use is allowed, to avoid confusion and prevent misuse.

​JURISDICTION APPROVED VENDOR SOFTWARE

​​The jurisdiction designates all EDI software such as translators, transmitters, or FTP utilities that are installed, tested and are in production to send and receive EDI transmissions.

​File Transfer Protocol (FTP): This section is to be used if files are available on an FTP site maintained by the Receiver.

• IP Address/URL: Enter the Receiver’s Internet address, using a Uniform Resource Locator (URL) format.
• User ID: Specify the logon name or indicate how the logon name will be communicated if additional security is desired.
• Security Protocol: Specify the security protocol options the Receiver supports to be followed in downloading and/or uploading from/to the FTP site. The IAIABC recommends the use of Secure Socket Layer (SSL).
• Certificates: Specify required certificate usage policies when using Secure Socket Layer (SSL).
• Auditing: The IAIABC recommends non-repudiation where the system must have an auditable tracking of transfers to and from each trading partner.
• Encryption Level: Specify the minimum level of transmission encryption to be used in downloading and/or uploading from/to the FTP site. The IAIABC recommends at least 112 bit encryption.

​​Flat File Record Delimiter: If the Receiver supports a flat file format, specify the character used to physically indicate the end of a record, such as carriage return (CR) or carriage return line feed (CRLF).

ANSI Information: This section provides information needed to exchange ANSI formatted transmission data, if the Receiver supports ANSI transmissions.

• Segment Terminator: Specify the character used as a segment terminator.
• Data Element Separator: Specify the character used as a data element separator.
• Sub-Element Separator:  Specify the character used as a sub-element separator.
• ISA Information Sender/Receiver Qualifier: The ANSI ID Code Qualifier as specified in an ISA segment. Separate Qualifiers are provided to exchange Test and Production data, if needed
• ISA Information Sender/Receiver ID: The ID Code that corresponds with the ANSI Sender/Receiver Qualifier (ANSI ID Code Qualifier) as specified in an ISA segment. Separate Sender/Receiver ID’s are provided to exchange Test and Production data, if needed.

​​SENDER'S RESPONSE

Return This Page To: Receiver Name is transferred from the Receiver's Specifications portion of the Transmission Profile to this section. The Receiver’s fax number, address, and e-mail address of the main contact are also included here. The Receiver should provide this information in preprinted form.

Date Prepared: Date this form completed.

Sender Legal Name: The name of the business entity that will be transmitting detailed workers’ compensation data to the Receiver. This should be the same name that appears on the IAIABC Electronic Trading Partner Profile. The name of the Sender, whether Insurer, Self-Insurer, Third Party Administrator, or other Sender, should be entered as the full legal name of the entity, with no abbreviations. The named Sender shall include all other companies within the company named and authorized to write workers’ compensation insurance or to provide insurance-related services within the named state.

Sender Type: Check all descriptors that apply to appropriately reflect the Sender's business type. For example, if the Sender is a carrier insuring some claims but is also acting as a third party administrator on other claims, the Sender should at least check both “Insurer” and “Third Party Administrator”.

Sender ID: This is a unique identifier consisting of the Sender’s FEIN and Sender’s Postal Code. The Sender FEIN and Postal Code should be the same as those the partner will use as the Sender ID in the Header Record of all its EDI transmissions.

​​Transaction Information: This section identifies the file format that the Sender will use to transmit the transaction sets/report types required or accepted by the Receiver as described within this profile. Also identified are any options provided by the Receiver that are chosen by the Sender for each transaction set. Both the IAIABC and ANSI designators and Transaction Sets are provided (e.g., MED/837, where "MED" is the IAIABC designator and "837" is the ANSI designator).

• Release/Version: If the Receiver can accept a flat file for a given transaction set, specify the release/version number(s) supported by the Receiver. Multiple releases/versions may be supported per transaction set within the Receiver’s environment. The Sender will specify a single release/version per transaction set on the Sender’s portion of the form. The IAIABC recommends that the trading partners agree on the most current releases/versions that both partners can support.
• Version: If the Receiver can accept an ANSI transmission for a given transaction set, specify the version number(s) supported by the Receiver. Multiple versions may be supported per transaction set within the Receiver’s environment. The Sender will specify a single version per transaction set on the Sender’s portion of the form. The IAIABC recommends that the trading partners agree on the most current version that both partners can support.
• Projected # Per Transmission: This is the Sender’s estimate of the average number of detail records for a given Transaction Set ID that it will send to the Receiver in a single transmission. This information will be useful to the Receiver for planning purposes.

Transmission Frequency: The Sender will specify which one frequency option, from the choices provided by the Receiver, the Sender will use to transmit data. Note: For FROI/SROI processing, the Sender is encouraged to transmit daily and receive acknowledgments daily to avoid processing delays and sequencing problems inherent in the correction process.

Selected Transmission Method: Check the appropriate media option the Sender will use to transmit data and complete the appropriate profile.

​​Network: The Sender specifies the Network it will use to transmit data to the Receiver. Separate mailbox information is provided for production versus test transmissions.

• Mailbox Acct ID: The name of the sender's mailbox on the specified network.
• User ID: The identifier of the sender entity to the network.
• ​​Message Class: If this Network allows "slots" in the mailbox (message classification “pigeonholes”), specify the slot to be used by a given Receiver when transmitting their information to the Sender. Note: Most Networks do not have their systems configured to allow use of a Message Class. If the Network and Receiver both allow usage of this specification, the Receiver should clearly spell out the conditions under which Message Class use is allowed, to avoid confusion and prevent misuse.

VENDOR NAME AND VENDOR SOFTWARE

​​The sender designates which EDI software such as translators, transmitters, or FTP utility will be used to send and receive EDI transmissions.

File Transfer Protocol (FTP): This section is to be used if files are available on an FTP site maintained by the Receiver.

• ​​IP Address/URL: Enter the Receiver’s Internet address using a Uniform Resource Locator (URL) format.
• User ID: Specify the logon name or indicate how the logon name will be communicated if additional security is desired.
• Security Protocol: Specify the security protocol options the Receiver supports to be followed in downloading and/or uploading from/to the FTP site. The IAIABC recommends the use of Secure Socket Layer (SSL).
• ​​Certificates: Specify required certificate usage policies when using Secure Socket Layer (SSL).
• ​​Auditing: The IAIABC recommends non-repudiation where the system must have an auditable tracking of transfers to and from each trading partner.
• ​​Encryption Level: Specify the minimum level of transmission encryption to be used in downloading and/or uploading from/to the FTP site. The IAIABC recommends at least 112 bit encryption.